Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 40950

Article: 40950
Subject: Re: How do I simulate two separate designs simutaneously in ModelSim
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 18 Mar 2002 20:17:52 -0600
Links: << >>  << T >>  << A >>
I solved the problem by instantiating both designs, and run them
alongside in a new top module, but I will remember that there are other
ways to compare waveform results.
When I was reading ModelSim's User Guide, I believe I read a section
that mentioned about VCD, but didn't want to spend a lot of time
learning more things because I wanted to quickly compare results.
I know not willing to learn new design approaches is fatal in
engineering, but for the time being, I wanted to compare waveform
results quickly because I am still at the the implementation stage of a
design, and not at the verification stage of a design yet.
Yes, when I reach the verification stage of my design, I will definitely
try to learn new verification methods, so that I can test my design
effectively.
Although I am sure some people don't like my "quick fix" type of
approach to testing.



Thanks,



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Steve Meyer wrote:
> 
> One way to do the comparing is to add the P1364 standard dumpvars
> feature by adding call "$dumpvars" to the design source (preferably at time
> 0 or if you do not want to compare results until a given time, at the at
> that time).  The first simulation will write verilog.dump file. After
> simulation runs, copy file to other name and run model to compare again
> with added $dumpvars.  Then just use diff command to compare results.
> It turns out that a given simulator will produce identical dumpvars file
> providing wire declarations in two designs are same.  This does not help
> much in isolating differences.  If you want to compare results from
> different related designs or two different simulators, you need simple
> program to compare dumpvars files.  You can purchase fancy ones or you
> can write one quite easily yourself.
> 
> Another standard P1364 approach is to use vpi_ and add value change call backs
> (vpiValueChange) to signals of interest and have value change call back
> routine just print time stamp and new value.  You can then use various
> unix tools to compare results.
> /Steve
> 
> 
> --
> Steve Meyer                             Phone: (612) 371-2023
> Pragmatic C Software Corp.              email: sjmeyer@pragmatic-c.com
> 520 Marquette Ave. So., Suite 900
> Minneapolis, MN 55402

Article: 40951
Subject: Re: [Virtex 2] DCM: "Factory_JF" option box in FPGA editor question
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 18 Mar 2002 20:36:39 -0600
Links: << >>  << T >>  << A >>
If ordinary users are discouraged from using this Factory_JF feature in
Virtex-II, how about Virtex/Virtex-E/Spartan-II/Spartan-IIE's ability to
add some extra delay on the global clock buffer?
I believe in bitgen, the user can add extra delay on the global clock
buffer to get some extra setup time, but the problem I have is that the
feature is sort of secret, and only Xilinx knows how to use it.
The default value of that feature in bitgen I believe is 11111 (probably
a binary value).
My guess is that the value 11111 puts the least amount of global clock
buffer delay, and the value 00000 puts the greatest amount of global
clock buffer delay.
Beyond that, I have no idea how the thing works, but putting too much
delay on the global clock buffer will affect Tco, so my guess is that
typically people who use it pick a value somewhere in between that.
Or looking at it differently, changing one of the bit to 0 (like
changing 11111 to 11011) puts certain amount of delay, and more the bits
that are zero (like 10011 or 10001), more the delay on the global clock
buffer.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 40952
Subject: Re: How do I simulate two separate designs simutaneously in ModelSim XE?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 18 Mar 2002 21:21:50 -0600
Links: << >>  << T >>  << A >>
Other people recommended instantiating two designs in one top module,
and run both of them from a top module.
I guess your idea will be to XOR the outputs coming from the two modules
to see when they won't match.
I guess that is possible in theory, but I rather see both waveforms
untouched myself.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Muzaffer Kal wrote:
> 
> 
> You don't need to run two instances. Just instantiate both designs in
> a test bench and xor the outputs.
> 
> Muzaffer Kal
>

Article: 40953
Subject: Re: All Digital PLL for locking DDS to input clock
From: eric.jacobsen@ieee.org (Eric Jacobsen)
Date: Tue, 19 Mar 2002 04:25:37 GMT
Links: << >>  << T >>  << A >>
On Mon, 18 Mar 2002 19:01:30 GMT, "Kevin Neilson"
<kevin_neilson@removethis-yahoo.com> wrote:

>I've built an NCO and all digital PLL.  The NCO operates at the rate of
>sample_clk, and the digital PLL adjusts the NCO phase increment so the NCO
>output, theta, represents the angle of a vector spinning at some ratio M/N
>times another clock, data_clk.  Theta is used as the input for an sine
>lookup to produce symbol_clk.  So the relationship of the clocks is:
>
>symbol_clk = M/N * data_clk
>
>The phase relationship is not important.  Both symbol_clk and sample_clk can
>change frequencies, so the all-digital PLL must continuously track and
>change the frequency of symbol_clk so maintain the above relationship.
>
> Everything seems to be working well, but I want to optimize everything to
>increase the spectral purity of symbol_clk.  I would like to know how much
>precision I need for the NCO, how to trade off lock time and spectral
>purity, and over how long a period I should calculate the frequency error.
>Also, should the frequency error be a function of the number of complete
>rotations of theta, or also of the fractional part of theta?  Do I need to
>dither the least-significant bits of theta?  I have searched, but can find
>little information about such loops.  Anyone know of a source of good info?
>
>-Kevin

Kevin,

First, thanks for an explicit and clear description of what you're
doing and what your questions are.  An excellent first step in getting
something useful out of this group.

If you're actually phase locking the output symbol_clk to data_clk,
then the frequency relationship will be fixed, so I'm not sure what
you're really after when asking about the frequency error.   There
isn't one in a PLL, since the "lock" is between the output and the
reference.   If there _is_ an error, then you're experiencing cycle
slips somewhere, which is a solvable problem.

Dithering the LSBs of the NCO phase increment register can help reduce
the spurious signals in the output, but if you're output is clean
enough for your application then there's no need to bother.   These
are the usual tradeoffs with this sort of architecture, though, so
that is a pertinent question.

Qualcomm and ADI have both published some very good app notes on
NCO/DDS implementations over the years, so you may look around for
those if you haven't already.   I think there are some other links
around that could probably be found with suitable keywords in google
(I don't have any directly handy).   Perhaps some others will chime in
with useful references.


Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org

Article: 40954
Subject: Re: All Digital PLL for locking DDS to input clock
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Tue, 19 Mar 2002 05:03:27 GMT
Links: << >>  << T >>  << A >>
> Kevin,
>
> First, thanks for an explicit and clear description of what you're
> doing and what your questions are.  An excellent first step in getting
> something useful out of this group.
>
> If you're actually phase locking the output symbol_clk to data_clk,
> then the frequency relationship will be fixed, so I'm not sure what
> you're really after when asking about the frequency error.   There
> isn't one in a PLL, since the "lock" is between the output and the
> reference.   If there _is_ an error, then you're experiencing cycle
> slips somewhere, which is a solvable problem.
>
> Dithering the LSBs of the NCO phase increment register can help reduce
> the spurious signals in the output, but if you're output is clean
> enough for your application then there's no need to bother.   These
> are the usual tradeoffs with this sort of architecture, though, so
> that is a pertinent question.
>
> Qualcomm and ADI have both published some very good app notes on
> NCO/DDS implementations over the years, so you may look around for
> those if you haven't already.   I think there are some other links
> around that could probably be found with suitable keywords in google
> (I don't have any directly handy).   Perhaps some others will chime in
> with useful references.
>
>
> Eric Jacobsen
> Minister of Algorithms, Intel Corp.

Eric,
By "frequency error" I just mean the feedback signal.  Basically, I count
how many times
the vector theta revolves in N periods of data_clk, and then I subtract this
from M to yield
the "error".  This feedback signal is multiplied by a gain value and then
added to the phase
incrment that controls the NCO frequency.

One thing I'm trying to figure out is the effect of using a ratio of
(S*M)/(S*N), which is the same
ratio, but with top and bottom multiplied by S.  This decreases the loop
gain, but does it add
precision?
-Kevin



Article: 40955
Subject: XESS parallel cable
From: John Williams <j2.williams@qut.edu.au>
Date: Tue, 19 Mar 2002 15:07:23 +1000
Links: << >>  << T >>  << A >>
hi folks,

I've trolled google and the XESS web pages but no luck, so here goes.

The XESS parallel prorgamming cable - what are the connections?  IT's a
DB25-DB25 - is it a simple pass-through (I hope) or something a bit omre
tricky?

I've got an old XESS XS40 board but the cable is lost in the mists of
time.

any help greatly appreciated.

Thanks,

John

Article: 40956
Subject: Webpack + XC4000
From: John Williams <j2.williams@qut.edu.au>
Date: Tue, 19 Mar 2002 15:49:13 +1000
Links: << >>  << T >>  << A >>
hi again,

Snag number 1 - Xilinx Webpack does not appear to support the XC4010E
that is on my Xess board.  any helpful advice?

Thanks,

John

Article: 40957
Subject: Xilinx : Altera pin compatibility
From: "Greg Otto" <gotto@usbrobotics.com>
Date: Mon, 18 Mar 2002 21:51:48 -0800
Links: << >>  << T >>  << A >>
Are there any Xilinx Spartan FPGAs that are pin compatible with Altera 10k50v-208 parts ?  I designed a board initially with the 10k50v parts, but I have had so many problems with Altera, so I would like to drop a Xilinx device on the pads instead.  Is there any hope, or am I stuck forever with Altera ?

Article: 40958
Subject: Re: High speed clock routing
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 19 Mar 2002 01:29:07 -0500
Links: << >>  << T >>  << A >>
I tried downloading the Hyperlynx demo and found that it won't let you
do anything at all useful.  I can enter my own data, but I can't
simulate it.  I can simulate and example file, but I can't change
anything to try to fix problems, or it won't simulate again.  This would
appear to be a very useless demo.  It is not demoing anything except the
installation, which did go very smoothly.  

Isn't this the tool that you said we could do simple things with?  I
thought the main limitation was that data could not be saved or
printed?  


Austin Lesea wrote:
> 
> Rick,
> 
> Use the fast/strong IBIS corner, and that covers the worst case for
> process/voltage/temperature.
> 
> The capactances don't matter all that much (convince yourself by changing them,
> and you will see that the results don't change much at all).
> 
> The claim of IBIS simulator vendors is that it saves all of the PCB spins to fix
> SI, and they are right.  The sims are not that fussy, and all you need to be sure
> of are the parts and their models, and the PCB impedance and the lengths.
> 
> Input models are not fussy either, hence my use of VII for all inputs is probably
> +/- 10% of the real measured result.  All CMOS inputs look pretty much the same.
> 
> If you have wide buses, then crosstalk is important, and you need a little more
> detail for the geometry.
> 
> Austin
> 
> rickman wrote:
> 
> > Thanks for your comments John.
> >
> > I guess I am a little green with clocks above 50 MHz.  I was expecting
> > runs this short to be pretty simple and not to have to do too much to
> > make it work.  But with the input from Austin and yourself as well as
> > some others, I do at least plan to take a first pass at a simulation.
> > My main concern is that you have to know a lot of details about the
> > board to run a USEFUL simulation.  I have learned a lot from reading
> > some of Bob Pease's articles and I fully realize that a simulation won't
> > do me a lick of good if I don't make all the right assumptions.
> >
> > I have been working on a very tightly packed switching power supply
> > while I am doing the digital stuff and I am finding that I can make it
> > look pretty feasible if I make THESE assumptions and I can make it look
> > pretty impossible if I make THOSE assumptions.  I think we won't really
> > know how well it will work until we fire it up on the final board
> > layout.  I expect that we will see the same sort of thing with this
> > clock design.
> >
> > I did consider using a zero delay buffer.  But this board is very tight
> > for space and I have a hard time justifying it with 1.5 inch traces.
> > But if the simulation shows a problem, of course we will do what we have
> > to.
> >
> > The SDRAM and SBSRAM are 4 pF input cap max, the FPGA says 8 pF max.
> > This is another difference between the simulation Austin did and what I
> > have.  He seems to have used all VII inputs with 10 pF capacitance.
> >
> > It is also not clear to me if the simulations are being done with
> > typical values or worst case values.  If typ values are used, then I
> > don't see how the results have any meaning at all.
> >
> > Rick Collins
> >
> > John_H wrote:
> > >
> > > 85 ps per inch works for free space.  A better approximation would be 170 ps
> > > per inch for internal traces where the relative permitivity of about 4 for
> > > FR4 material at high frequency gives a good approximation (sqrt(4) for
> > > scaling to free space).  The outside traces are a bit faster because they're
> > > propagating through a combination of air and FR4 - I don't have the numbers
> > > handy for those speeds.
> > >
> > > You're right about the stackup being important - the trace widths and plane
> > > spacings need to be well specified by you to get the board house to provide
> > > impedances that won't over/undershoot.  A little mistermination is fine -
> > > the mid-transition reversals are what kills;  those can occur when the
> > > driver sees a low impedance for much of the risetime but gets the reflection
> > > coming back before the clock's out of the transition region.  There's the
> > > beauty of SI - this general info gets applied.
> > >
> > > With everything close and distributed capacitance throughout, you could get
> > > smooth transitions with the star configuration, but it's dependent on the
> > > drivers and input capacitance.
> > >
> > > Are independent clocks from the FPGA something you want to avoid?  "Zero
> > > delay buffers" are part of the clock management's best application.  It's
> > > often better from a debug standpoint to have access to individual
> > > terminations if things go desperately wrong.
> > >
> > > rickman wrote:
> > >
> > > > Austin, thanks for the simulation.
> > > >
> > > > This looks like great data.  But I am not sure if you were trying to
> > > > help by doing my simulation for me, or if you were just trying to show
> > > > what the tool can do.
> > > >
> > > > I am not clear about what this is simulating.  Obviously you used the
> > > > daisy chain model, but how do you know what to use as a trace impedance
> > > > and where did the delays come from?  The preliminary layout I am using
> > > > has the following delays in the daisy chain case, assuming 100pS per
> > > > inch.  Is that a valid assumption?
> > > >
> > > > DSP to FPGA       100pS
> > > > FPGA to SDRAM1     50pS
> > > > SDRAM1 to SDRAM2   50pS
> > > > SDRAM2 to SBSRAM  100pS
> > > >
> > > > Don't I need to caclulate the trace impedance from the PCB design
> > > > rules?  The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8
> > > > layers with a total thickness of 0.062".  Of course, I can use wider
> > > > traces for the clock and control which layer they are on.
> > > >
> > > > I would expect these four loads to behave much better than the five
> > > > loads with 200+ pS delays.
> > > >
> > > > If you were just trying to demonstate the tool, that's fine.  But if you
> > > > were trying to simulate my case, these are the data that should be
> > > > used.
> > > >
> > > > When I am done my other work today, I will try downloading the software
> > > > and giving it a try this weekend or next week.
> >
> > ...snip...
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 40959
Subject: A petition for Synplify's new fature (FPGA synthesis tool)
From: synp_petition@usa.net (Aki Niimura)
Date: 18 Mar 2002 22:53:18 -0800
Links: << >>  << T >>  << A >>
Dear Fellow FPGA designers,

I would like to have your feedbacks / supports.

Synplicity has released Synplify 7.0.x with lots of enhancements
last November. One of the enhancements is called "Tri-state push thru"
feature.

The following are excerpts from e-mails from Synplicity
explaining how the feature works:

> For example in the verilog code
>
> assign data = en ? data_in : 1'bz;
> always @(posedge clk)
> begin
> q_out = data;
> end
>
> will be implemented with tristate after the q_out flipflop currently ( 7.02
> ) to match simulation. The tristate will be implemented
> before the q_out flip flop with the switch ( 6.2.4 behavior).

> In 6.2.4 we didn't perform Tri-state push through across boundaries
> as like every other Synthesis tool on the market.  We (and many
> of our customers) deemed this logically incorrect.  We enabled
> Tri-state push thru in 7.0, but some of our customers requested
> a 'compatibility' switch so that our results matched our competition,
> hence the switch in 7.1.
> This switch fixes what we consider to be bad logic and was a
> definite requirement from our customers.

Simply saying, Synplify 7.x will implement the logic differently from
the RTL code you have specified to prevent simulation from causing
a mismatch.

I have noticed this new feature because my design becomes 30% larger
and yet slower when I resynthesized my existing design using Synplify
7.0.2.

With this feature:  1086LUTs (30.2MHz)  <<-- default in Synplify 7.x
W/o this feature :   833LUTs (31.8MHz)

My design uses tri-state gates to implement a multiplexer with
a large number of inputs efficiently which is a widely used
FPGA technique. I hand-crafted the multiplexer such that speed
and logic size are both satisfied.
Synplify 7.x will implement the multiplexer using LUTs and put
a tri-state gate after the LUTs. (tri-state gate is pushed-thru)

I thought this feature was creating more harms than goods.
Not only because I'm getting inferior results but also I feel
the synthesis tool should deliver the exact logic which the input
RTL code specified. (Otherwise, FPGA designers can not control
how the logic is laid out.)

Note: Synplify 7.1 has a switch to select this feature. However
this feature is always turned on by default.

However, the response I got from Synplicity is quite different
from what I had imagined. After many e-mail exchanges,
Synplicity has notified me their conclusion:

> We still strongly feel that disabling the Tri-state push thru by
> default would hurt too many of our customers - who specifically
> demanded this feature.  We have accommodated for those customers
> who prefer the legacy implementation by adding the switch.
>
> We have several test designs with test-benches which clearly
> show RTL / simulation mismatches with this switch disabled.
>
> Our senior management strongly believes this decision is correct
> and in-line with our policy of correct logic implementation.

Unfortunately, their conclusion is completely opposite to my
understanding.  I'm still not convinced that such logic mapping
is correct.

Since Synplify is #1 in the FPGA synthesis market, a huge number
of engineers in the world are using Synplify to design FPGAs.

I would like to ask everyone about this new feature of
Synplify 7.x. If you feel this feature is incorrect and
dangerous (or support Synplicity's arguments), please
send me an e-mail. I will present all e-mails I receive
to Synplicity (both for and against).

Feedback / support to : synp_petition@usa.net

I will post the update when I have something to report.

Thank you for your attention.
Hope I can hear from many of you.
You can forward this to any other newsgroups or your friends
to get more feedbacks.

Sincerely yours,
Aki Niimura - being a Synplify user since 1999

P/S I have created a Web site to list feedbacks I receive.
http://www.petition-synplify.0catch.com

Article: 40960
Subject: simple Free FPGA tool
From: "Jimmy Zhang" <zhengyu@attbi.com>
Date: Tue, 19 Mar 2002 08:10:32 GMT
Links: << >>  << T >>  << A >>
Is anyone aware of any freestuff available?



Article: 40961
Subject: Xilinx JTAG Cables
From: William Lenihan <lenihan3we@earthlink.net>
Date: Tue, 19 Mar 2002 08:27:24 GMT
Links: << >>  << T >>  << A >>

Subject: Parallel Cable III/IV

These JTAG pods have attachments called "flying leads", where end
#1 is a fixed connector to plug into the pod (i.e., JTAG row of pins)
and
end #2 is the actual flying leads to connect to the target hardware.

That's great for prototype & engineering development, but for
production, the actual
flying leads @ end #2 can easily be mis-placed by technicians on the
assembly
line.

Is there any readily available, fixed-connection cables (and mating
sockets) for the Xilinx-programming-pod-2-target-hardware connection?
Or is that some tooling that every customer just has to make on their
own
w/ catalog parts from Newark, Digi-Key, etc., ?



--
==============================
William Lenihan
lenihan3we@earthlink.net
==============================



Article: 40962
Subject: constrain
From: wreg <sdafj@ierjg.zklxv>
Date: Tue, 19 Mar 2002 01:23:25 -0800
Links: << >>  << T >>  << A >>
i think it is useless adding constrain(eg.clock/input delay/output delay) in the logic synthesis stage.because it doesn't include any delay timing.it should only be added in the P&R stage(clock/setup/offset/in/out...).
amn't I?

Article: 40963
Subject: state machine coding style
From: wreg <sdafj@ierjg.zklxv>
Date: Tue, 19 Mar 2002 01:30:17 -0800
Links: << >>  << T >>  << A >>
usually,i write state machine according the following style.
isn't it?
************************************
`define  Present_Crs_State                                                 4:1
`define  C_Idle                                                            1
`define  C_Rxdv                                                            2
`define  C_Wait                                                            3
`define  C_Togg                                                            4
//restore signal state machine
assign           State_Rxdv          =          Present_Crs_State[`C_Rxdv];
assign           State_Wait          =          Present_Crs_State[`C_Wait];
assign           State_Togg          =          Present_Crs_State[`C_Togg];
     
always @(posedge RefClk50 or negedge Rst_N )
begin
if                 (!Rst_N) 
           Present_Crs_State         <=         4'b0001;
else
           Present_Crs_State         <=         Next_Crs_State;
end  
always @                   (                    Present_Crs_State or 
                                                Crsdv
									)
begin
              Next_Crs_State          =         4'b0000 ;
 case                 (1'b1)                                                                            //synopsys parallel_case full_case
  Present_Crs_State[`C_Idle]:                                       
	begin
    if  (Crsdv&&!Rx_Disable)
     Next_Crs_State[`C_Rxdv]          =         1;
	 else
	  Next_Crs_State[`C_Idle]          =         1;
 	end
  Present_Crs_State[`C_Rxdv]: 
   begin
    if               (Crsdv)
	  Next_Crs_State[`C_Rxdv]          =         1;
	 else
	  Next_Crs_State[`C_Wait]          =         1;
   end
  Present_Crs_State[`C_Wait]: 
   begin
	 if               (Crsdv)
     Next_Crs_State[`C_Togg]          =         1;
	 else
	  Next_Crs_State[`C_Idle]          =         1;
	end
  Present_Crs_State[`C_Togg]: 
   begin
	 if               (Crsdv) 
	  Next_Crs_State[`C_Idle]          =         1;
	 else
	  Next_Crs_State[`C_Wait]          =         1;
	end
  default:
     Next_Crs_State[`C_Idle]          =         1;
 endcase
end

Article: 40964
Subject: Re: XST duplicates unnecessary IOB OE FFs
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 19 Mar 2002 03:34:18 -0600
Links: << >>  << T >>  << A >>
hamish@cloud.net.au wrote:
> 
> Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
> >        I guess the XST is not the only synthesis tool that has this
> > problem.
> 
> I wouldn't say it's a problem. Generally speaking it is a helpful
> thing for it to do. It makes the code look better if you only have
> a single output enable signal, rather than manually creating N of them.
> 
> It's a fact of life that if you want something different from the
> obvious behaviour, you have to fight the tools for it. The tool thinks
> it is optimising the design for you. But the tools just aren't very
> good at optimising really high speed stuff.
> 

        It is not a bug, but what XST is doing is different than what I
want it to do.
That alone makes it a problem, but I have to admit that it is not a huge
issue in 33MHz PCI.
Yes, having only one OE FF for the 32-bit bus as opposed to having to
duplicate an OE FF 32 times may make the code look better, but in my
opinion, duplicating it 32 times manually is not a big problem since,
"ad_Port_OE <= 1'b0;" is only changing to "ad_Port_OE[31:0] <=
32'h00000000;".
I personally can live with such an inconvenience, but I cannot live with
inconvenience of the synthesis tool going against my will, and
duplicating an OE FF 32 times.
I think XST has to "trust" the user a little more, and not guess what
the user is trying to do.



> A while back I was having trouble getting a design routed, so I started
> fiddling with the manual fan-out control. I changed the value and looked
> at the tool's speed estimate. I found an optimal value according to
> the tool -- but the optimal value at route time was different again.
> So I don't pay too much attention to the estimated clock speeds.
> 
> The automatically duplicated signals are only half as effective as
> they could be due to register ordering performed by Xilinx MAP.
> The synth tool companies need to do something to work around this
> ASAP. In the longer term, Xilinx urgently needs to provide an
> attribute that can be applied to signals to disable this behaviour.
> 
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>


        Are you talking about synthesis tool's estimated frequency?
I guess in a large design, knowing the estimated frequency at synthesis
stage makes sense because I am told that P&R can take awful long time,
but in my case, I find XST's frequency and setup time estimate pretty
much meaningless, so I go ahead and P&R the design with the lowest
possible P&R effort only once to save time.
In a PCI IP core, setup time is the key, and what determines the setup
time is levels of LUT, so after P&R, I go read the timing report to see
how many levels of LUT XST generated.




Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 40965
Subject: Unused I/Os + External Clock on Virtex II
From: "Philippe Robert" <PhilippeR@sundance.com>
Date: Tue, 19 Mar 2002 09:35:15 -0000
Links: << >>  << T >>  << A >>
Hi there,

I am designing a general I/O board with a Virtex II (xcv2V3000 to 8000) and
some memory. I have about 100 spare pins. I have read on the newsgroups
sometime ago that it was good to connect them to ground an to assign a value
to each of them.
Did anybody went through this problem yet ?


Also, an external clock will be connected directly to the FPGA. The range is
0-200 MHz. I assume it requires a input filter between the connector and the
FPGA. I thought about a low pass filter with a cut frequency of 200 MHz.
Does it sound good ?


Thanks.
Philippe.



Article: 40966
Subject: Power Tie in Spartan IIE
From: Dave.Haynes@sia-mce.co.uk (Dave Haynes)
Date: 19 Mar 2002 01:43:45 -0800
Links: << >>  << T >>  << A >>
Hi,

 I'm using LeonardoSpectrum v2002a to synthesise to EDIF. P&R is with
Xilinx Webpack 4.1WP3.x. Target device is Spartan IIE (XC2S200E).

 A couple of pins need to be tied high, and this is achieved in the
EDIF by connecting to port P of a VCC component. This happens from
within a hierarchical block.

 The P&R leaves the pin unconnected and floating. I've checked this
with the floorplanner. Should I be using a different name for the
power net, or is this likely to be a problem with hierarchical EDIF?

 Anybody got any suggestions?

                Cheers,

                               Dave.

Article: 40967
Subject: FIFO general question
From: dottavio@ised.it (Antonio)
Date: 19 Mar 2002 01:48:07 -0800
Links: << >>  << T >>  << A >>
I can't understand how a FIFO could work well if it is writed with an
high data rate and it's read with a low data rate, from my point of
view, reallt soon it became full and all the data that continue to be
writed into the FIFO will put away the first data, where's my
conceptual error ??

Antonio

Article: 40968
Subject: Re: FIFO general question
From: Nicolas Matringe <nicolas.matringe@ipricot.com>
Date: Tue, 19 Mar 2002 10:59:48 +0100
Links: << >>  << T >>  << A >>
Antonio wrote:
> 
> I can't understand how a FIFO could work well if it is writed
> with an high data rate and it's read with a low data rate, from
> my point of view, reallt soon it became full and all the data
> that continue to be writed into the FIFO will put away the first
> data, where's my conceptual error ??

Hi
There's no error: what goes in must go out and if it doesn't go out fast enough
it'll be overwritten. It's much more useful the other way round: data come in
slower *on average* than they go out. Think of bursts of data (high
instantaneous bit rate)

-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 02      http://www.IPricot.com/

Article: 40969
Subject: Re: FIFO general question
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 19 Mar 2002 10:02:46 GMT
Links: << >>  << T >>  << A >>


Antonio wrote:
> 
> I can't understand how a FIFO could work well if it is writed with an
> high data rate and it's read with a low data rate, from my point of
> view, reallt soon it became full and all the data that continue to be
> writed into the FIFO will put away the first data, where's my
> conceptual error ??

No error. If the fifo gets full, you need to stop filling it.

Article: 40970
Subject: DDS in an FPGA
From: mister_mot@hotmail.com (Mot)
Date: 19 Mar 2002 03:24:13 -0800
Links: << >>  << T >>  << A >>
Does any of you know some sites where I can view examples of DDS
inplemented in an FPGA?

thx mot

Article: 40971
Subject: Re: simple Free FPGA tool
From: Jacky Renaux <renaux.jacky@wanadoo.fr>
Date: 19 Mar 2002 11:44:03 GMT
Links: << >>  << T >>  << A >>

Try  
http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack
the free package is very powerfull , be sure you have a large disk space 
and fast internet download access.

regards 

-- 
Use our news server 'news.foorum.com' from anywhere.
More details at: http://nnrpinfo.go.foorum.com/

Article: 40972
Subject: Re: DDS in an FPGA
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Tue, 19 Mar 2002 20:00:38 +0800
Links: << >>  << T >>  << A >>
You can browse through www.andraka.com. He has something on CORDIC used in
direct digital frequency synthesis. Does DDS mean direct digital synthesis?

--
Email: qijun@okigrp.com.sg
"Mot" <mister_mot@hotmail.com> wrote in message
news:a75cd014.0203190324.46563ed6@posting.google.com...
> Does any of you know some sites where I can view examples of DDS
> inplemented in an FPGA?
>
> thx mot



Article: 40973
Subject: Re: XESS parallel cable
From: Dave Vanden Bout <devb@xess.com>
Date: Tue, 19 Mar 2002 08:18:05 -0500
Links: << >>  << T >>  << A >>
John Williams wrote:

> hi folks,
>
> I've trolled google and the XESS web pages but no luck, so here goes.
>
> The XESS parallel prorgamming cable - what are the connections?  IT's a
> DB25-DB25 - is it a simple pass-through (I hope) or something a bit omre
> tricky?

It is a simple pass-through cable.

Questions like this can be sent to help@xess.com or submit the form at
http://www.xess.com/help.html.



>
>
> I've got an old XESS XS40 board but the cable is lost in the mists of
> time.
>
> any help greatly appreciated.
>
> Thanks,
>
> John




--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 303-2883 ||
|| devb@xess.com           2501-B Ten-Ten Road      (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 303-2884 ||



Article: 40974
Subject: Re: Webpack + XC4000
From: Dave Vanden Bout <devb@xess.com>
Date: Tue, 19 Mar 2002 08:19:32 -0500
Links: << >>  << T >>  << A >>
John Williams wrote:

> hi again,
>
> Snag number 1 - Xilinx Webpack does not appear to support the XC4010E
> that is on my Xess board.  any helpful advice?

You could buy the Xilinx Student Edition 2.1i for $55.00.  It supports
the XC4000E and XC4000XL series.

Or you could buy an XSA-100 Board that is supported by WebPACK and has
the same form factor as the XS40 Board.


>
>
> Thanks,
>
> John




--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 303-2883 ||
|| devb@xess.com           2501-B Ten-Ten Road      (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 303-2884 ||





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search