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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 132275

Article: 132275
Subject: Re: synthesis...
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Tue, 20 May 2008 11:46:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-05-20, Kolja Sulimma <ksulimma@googlemail.com> wrote:
> Don't confuse architecture and coding.
> The parallel linear adder chain will cost exactly the same hardware
> when coded with or without the for loop.

Of course, and I believe I wrote in my original post that a for
loop will simply be unrolled. My example was merely meant to
illustrate that it is very easy to write a for loop which will
be extremely expensive in hardware even though it is only a couple
of lines of code. This is why we recommend students to avoid
for-loops in our introductory courses, it is too easy to try to
program instead of designing hardware. If you don't use a for loop
you will immediately figure out that something is not right with
your design as you are going to write 512 individual additions...

However, since you seem to have some experience with synthesizers
that support wait statements I have a question for you: How should
you implement a synchronous reset if you have a process like the
following?

always begin

   always @(posedge clk);
   // This is the state I want to end up with at reset time
   bar <= 0;

   always @(posedge clk);
   bar <= bar + 1;

   always @(posedge clk);
   bar <= bar + 1;

   always @(posedge clk);
   bar <= bar + 1;
end


/Andreas

Article: 132276
Subject: Re: synthesis...
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Tue, 20 May 2008 06:17:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 20 Mai, 05:04, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:

> This is going to be hugely expensive in terms of hardware to
> implement as you will end up with 512 adders and force your
> memory to be implemented using flip-flops instead of a blockram.
> In this case it is probably a much better idea to write a small
> state machine to sum the values. It will take around 512 clock
> cycles unless you do something clever like reading several values
> at a time, but the footprint will be much more reasonable.

Don't confuse architecture and coding.
The parallel linear adder chain will cost exactly the same hardware
when coded with or without the for loop.

The same is true for the serial version (for synthesizers that
support
wait statements in for loops).

The decision whether to build a single cycle or multi cycle hardware
has nothing to do with for loops.

Kolja Sulimma

Article: 132277
Subject: Re: HELP: a Funny asynchronous input design
From: Aiken <aikenpang@gmail.com>
Date: Tue, 20 May 2008 06:55:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote:
>
> > input: Asynchronous, non-fix width, non-fix frequeny(but equal or
> > smaller than 30 Mhz), something like random fast signal coming in.
> > System clock is only 40MHz,
>
> > What can I latch the "rising" edge of the input and synchronize it and
> > don't get into big trouble of Metastability?
> > Since the input freq is very near the System clock and Asynchronous
> > don't have a clock signal coming in.
> > is it possible that connecting the input signal directly to FF clock
> > then following with a negative clk edge FF then positive clk edge FF?
> > will it make any trouble and how to solve it?
>
> Synchronizing a 30 MHz signal with a roughly 40 MHz clock will
> generate an uncontrollable extra metastable delay of a few ns
> occasionally.
> But an extra 4 ns only once per many thousand years, statistically.
> You really do not have to worry about metastability.
> At ten times higher frequencies, you would run into problems...
> Se my Xilinx appnote XAPP094...
> Peter Alfke

My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean
that the min time different between two signal will be =( 1/30Mhz). In
income signal don't have a clock domain, it just "Happen".

Article: 132278
Subject: Re: HELP: a Funny asynchronous input design
From: Gabor <gabor@alacron.com>
Date: Tue, 20 May 2008 07:04:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 9:55 am, Aiken <aikenp...@gmail.com> wrote:
> On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
> > On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote:
>
> > > input: Asynchronous, non-fix width, non-fix frequeny(but equal or
> > > smaller than 30 Mhz), something like random fast signal coming in.
> > > System clock is only 40MHz,
>
> > > What can I latch the "rising" edge of the input and synchronize it and
> > > don't get into big trouble of Metastability?
> > > Since the input freq is very near the System clock and Asynchronous
> > > don't have a clock signal coming in.
> > > is it possible that connecting the input signal directly to FF clock
> > > then following with a negative clk edge FF then positive clk edge FF?
> > > will it make any trouble and how to solve it?
>
> > Synchronizing a 30 MHz signal with a roughly 40 MHz clock will
> > generate an uncontrollable extra metastable delay of a few ns
> > occasionally.
> > But an extra 4 ns only once per many thousand years, statistically.
> > You really do not have to worry about metastability.
> > At ten times higher frequencies, you would run into problems...
> > Se my Xilinx appnote XAPP094...
> > Peter Alfke
>
> My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean
> that the min time different between two signal will be =( 1/30Mhz). In
> income signal don't have a clock domain, it just "Happen".

Still what Peter seems to suggest is that you can just sample
the asynchronous input with your 40 MHz clock and don't worry
about metastability.  In fact you could sample on both clock
edges and still have a very small chance of seeing a metastable
event at those frequencies.  Just be sure that there is only
one point of sampling on the input signal.  The output of that
single sampling flip-flop can then be used within the design.
Adding one more stage after the sampling flip-flop can improve
your metastability tolerance in two ways.

1) The second flip-flop would receive the sample flip-flop input
after a complete cycle without LUT delays.  This increases the
length of a metastable event required to upset the second
stage.

2) Having a single second point of sampling prevents logic
upsets caused by different loads sampling the metastable
vs. post-metastable state of the first sampling flop.

Article: 132279
Subject: Re: synthesis...
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 20 May 2008 08:26:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
fazulu deen wrote:
> hai,
>
> I learned from the Xilinx manual that for,while do statements are
> synthesized in XST..
>
> I would like to know how these statements(for,while,do while) are
> implemented as logic design(EDIF and constraints) in FPGA device?? .
>
> Though FOR loop is synthesizable , it is always advised that FOR loops
> are not to be used in RTL coding. This is because it consumes lot of
> resources (like area etc)whether XST will not optimize it before
> targetting to FPGA device???
>
> As wait() is not supported for synthesis wat should i use instead of
> wait()??
>
> regards,
> faz

One key point with these loops is that the conditionals that define
how much to loop are typically only supported for constants.  Trying
to do a for loop with a vector controlling your max value will
probably only bring synthesis errors.  Using parameters or other
constant values allow you to use these loops without the synthesis
complaints.

- John_H

Article: 132280
Subject: Re: Stratix IV Announced
From: austin <austin@xilinx.com>
Date: Tue, 20 May 2008 08:26:54 -0700
Links: << >>  << T >>  << A >>
Joseph,

Why bother?  Only because all of the 'other' solutions actually exist,
where H4 is a hyper-active sales pitch for an untested capability that
hasn't even been taped out yet...

Imagine all those Altera customers who designed in the Stratix III GX:
all dressed up, and nowhere to go.


Using FPGAs is all about reducing risk.  Converting the FPGA to an ASIC
(structured or otherwise) is all about reducing costs.

No risk: Virtex 5, today, available

Lower Cost: Virtex 5 EasyPath(tm) devices, guaranteed to work, because
they are IDENTICAL to the FPGA

Austin

Article: 132281
Subject: Re: I cannot find how to map a "record type" in my ucf file.
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Tue, 20 May 2008 09:38:29 -0600
Links: << >>  << T >>  << A >>
KJ wrote:
> On May 19, 2:38 pm, Pablo <pbantu...@gmail.com> wrote:
>> this is my code:
>>
>> entity Top_Module is
>>         port (
>>                 o_DSP0          : out     MyRecordType
>>               );
>> end Top_Module;
>>
>> whe o_DSP0 is:
>>
>> type MyRecordType is record
>>                 int4            : std_logic;
>>                 int5            : std_logic;
>>                 int6            : std_logic;
>>                 int7            : std_logic;
>>         end record;
>>
>> ---------------
>>
>> How is o_DSP0 declared in ucf file?
> 
> Most likely the 'o_DSP0' signal will get synthesized to a 'flattened'
> set of names like 'o_DSP0_int4', 'o_DSP0_int5', etc.  Check the output
> of your synthesis result to find out how the record type signal
> elements got renamed.
> 
> KJ
I tried this recently and had that result:  I had wanted the signal 
names "int4", "int5", etc., but got the "flattened" names.  -Kevin

Article: 132282
Subject: Re: HELP: a Funny asynchronous input design
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 20 May 2008 08:42:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 7:04=A0am, Gabor <ga...@alacron.com> wrote:
> On May 20, 9:55 am, Aiken <aikenp...@gmail.com> wrote:
>
>
>
> > On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote:
>
> > > > input: Asynchronous, non-fix width, non-fix frequeny(but equal or
> > > > smaller than 30 Mhz), something like random fast signal coming in.
> > > > System clock is only 40MHz,
>
> > > > What can I latch the "rising" edge of the input and synchronize it a=
nd
> > > > don't get into big trouble of Metastability?
> > > > Since the input freq is very near the System clock and Asynchronous
> > > > don't have a clock signal coming in.
> > > > is it possible that connecting the input signal directly to FF clock=

> > > > then following with a negative clk edge FF then positive clk edge FF=
?
> > > > will it make any trouble and how to solve it?
>
> > > Synchronizing a 30 MHz signal with a roughly 40 MHz clock will
> > > generate an uncontrollable extra metastable delay of a few ns
> > > occasionally.
> > > But an extra 4 ns only once per many thousand years, statistically.
> > > You really do not have to worry about metastability.
> > > At ten times higher frequencies, you would run into problems...
> > > Se my Xilinx appnote XAPP094...
> > > Peter Alfke
>
> > My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean
> > that the min time different between two signal will be =3D( 1/30Mhz). In=

> > income signal don't have a clock domain, it just "Happen".
>
> Still what Peter seems to suggest is that you can just sample
> the asynchronous input with your 40 MHz clock and don't worry
> about metastability. =A0In fact you could sample on both clock
> edges and still have a very small chance of seeing a metastable
> event at those frequencies. =A0Just be sure that there is only
> one point of sampling on the input signal. =A0The output of that
> single sampling flip-flop can then be used within the design.
> Adding one more stage after the sampling flip-flop can improve
> your metastability tolerance in two ways.
>
> 1) The second flip-flop would receive the sample flip-flop input
> after a complete cycle without LUT delays. =A0This increases the
> length of a metastable event required to upset the second
> stage.
>
> 2) Having a single second point of sampling prevents logic
> upsets caused by different loads sampling the metastable
> vs. post-metastable state of the first sampling flop.

Yes, Gabor, we agree. This is a non-problem, as long as the usual
precautions are being observed.
Peter Alfke

Article: 132283
Subject: Re: my Spartan-4 wishlist
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Tue, 20 May 2008 15:48:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
PFC <lists@peufeu.com> wrote:
> On Mon, 03 Mar 2008 20:40:07 +0100, Antti <Antti.Lukats@googlemail.com>  
> wrote:

> > here it is:
> >
...


>         Here's mine :


>      - PQ208 : put thermal pad below connected to GND, remove all GND pins  
>  from package ; put other smaller "thermal pads" for the power supplies 
>  and get rid of the supply pins, you get 50 more IO on the package.

National did someting like that for the DP83847

...

And keep 3.3V IO capability!
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 132284
Subject: Re: Stratix IV Announced
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 20 May 2008 09:49:41 -0700
Links: << >>  << T >>  << A >>
Joseph wrote:

> They've also released Hardcopy-IV, including serdes and PCI-e.
> Why bother with ASICs...

austin wrote:
> Joseph,
> Why bother?  Only because all of the 'other' solutions actually exist,

I believe Joseph said,
    "Why bother with ASICs"
not "Why bother with Xilinx"

> where H4 is a hyper-active sales pitch for an untested capability that
> hasn't even been taped out yet...

Let he who is without sin,
cast the first stone.

        -- Mike Treseler

Article: 132285
Subject: Instantiating an lpm dcfifo in Verilog
From: "jjlindula@hotmail.com" <jjlindula@hotmail.com>
Date: Tue, 20 May 2008 10:02:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello, I know many will say this is not an appropriate group to post
such a question, but I wasn't getting any response on the Verilog
group, so please let me apologize. I am new to Verilog and need some
help instantiating a lpm dcfifo in my code. Here is what I have so
far:

 FIFIN   :       lpm_fifo_dc WITH (LPM_WIDTH = 64, LPM_NUMWORDS = 64,
LPM_WIDTHU = 9, RDSYNC_DELAYPIPE = 3, WRSYNC_DELAYPIPE = 3);

FIFIN.aclr                      = (!rstn);
FIFIN.wrclock           = (clk);
FIFIN.wrreq                     = (wr_fiforeq);
FIFIN.data[31..0]       = (dma_wrdata);
FIFIN.rdclock           = (clk);
FIFIN.rdreq                     = (dma1_rddata);
FIFIN.q                     = (rd_fiforeq);


If anyone has some examples of instantiating a lpm function within
Verilog I would greatly appreciate your help.

Thanks,
joe

Article: 132286
Subject: Re: HELP: a Funny asynchronous input design
From: Aiken <aikenpang@gmail.com>
Date: Tue, 20 May 2008 10:15:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 11:42 am, Peter Alfke <pe...@xilinx.com> wrote:
> On May 20, 7:04 am, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On May 20, 9:55 am, Aiken <aikenp...@gmail.com> wrote:
>
> > > On May 19, 11:24 pm, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > On May 19, 3:10 pm, Aiken <aikenp...@gmail.com> wrote:
>
> > > > > input: Asynchronous, non-fix width, non-fix frequeny(but equal or
> > > > > smaller than 30 Mhz), something like random fast signal coming in.
> > > > > System clock is only 40MHz,
>
> > > > > What can I latch the "rising" edge of the input and synchronize it and
> > > > > don't get into big trouble of Metastability?
> > > > > Since the input freq is very near the System clock and Asynchronous
> > > > > don't have a clock signal coming in.
> > > > > is it possible that connecting the input signal directly to FF clock
> > > > > then following with a negative clk edge FF then positive clk edge FF?
> > > > > will it make any trouble and how to solve it?
>
> > > > Synchronizing a 30 MHz signal with a roughly 40 MHz clock will
> > > > generate an uncontrollable extra metastable delay of a few ns
> > > > occasionally.
> > > > But an extra 4 ns only once per many thousand years, statistically.
> > > > You really do not have to worry about metastability.
> > > > At ten times higher frequencies, you would run into problems...
> > > > Se my Xilinx appnote XAPP094...
> > > > Peter Alfke
>
> > > My situation is that ....the "30MHz" doesn't mean it is 30MHz, it mean
> > > that the min time different between two signal will be =( 1/30Mhz). In
> > > income signal don't have a clock domain, it just "Happen".
>
> > Still what Peter seems to suggest is that you can just sample
> > the asynchronous input with your 40 MHz clock and don't worry
> > about metastability.  In fact you could sample on both clock
> > edges and still have a very small chance of seeing a metastable
> > event at those frequencies.  Just be sure that there is only
> > one point of sampling on the input signal.  The output of that
> > single sampling flip-flop can then be used within the design.
> > Adding one more stage after the sampling flip-flop can improve
> > your metastability tolerance in two ways.
>
> > 1) The second flip-flop would receive the sample flip-flop input
> > after a complete cycle without LUT delays.  This increases the
> > length of a metastable event required to upset the second
> > stage.
>
> > 2) Having a single second point of sampling prevents logic
> > upsets caused by different loads sampling the metastable
> > vs. post-metastable state of the first sampling flop.
>
> Yes, Gabor, we agree. This is a non-problem, as long as the usual
> precautions are being observed.
> Peter Alfke

thanks

Article: 132287
Subject: Re: my Spartan-4 wishlist
From: PFC <lists@peufeu.com>
Date: Tue, 20 May 2008 20:40:43 +0200
Links: << >>  << T >>  << A >>

>>      - PQ208 : put thermal pad below connected to GND, remove all GND  
>> pins
>>  from package ; put other smaller "thermal pads" for the power supplies
>>  and get rid of the supply pins, you get 50 more IO on the package.
>
> National did someting like that for the DP83847

	Hey, this is a cool package, no pin wasting for power supplies, I like  
it... (plus it probably has better signal integrity). And no pins, which  
means no bent pins like on PQ208 !

> And keep 3.3V IO capability!

	Well, definitely !


Article: 132288
Subject: How do I optimize filter coefficient bit length and signal bit length?
From: "From Sweden" <sw@sw.se>
Date: Tue, 20 May 2008 21:04:50 +0200
Links: << >>  << T >>  << A >>
Hello all

I have made an 8 channel 500kHz low pass IIR-filter in VHDL. The filter uses 
32 bits for it's coefficients and 32 bits for it's internal signals.

The filter doesn't give the same DC-gain for small vs. large input signals. 
I suspect the internal truncation of the intermediate sums and states 
effects this.

But today I thought about increasing the bits for the signal and decreasing 
the bits for the coefficients. I tried it out and the filter gave better 
gain over different input signal levels.

Now I wonder how I should optimize the coefficient and signal bit lengths to 
get the best result?


Article: 132289
Subject: Re: bizarre state machine behavior
From: Jon Elson <elson@wustl.edu>
Date: Tue, 20 May 2008 14:22:25 -0500
Links: << >>  << T >>  << A >>


Jeff Cunningham wrote:
> Rob Gaddi wrote:
> 
>> Jon Elson wrote:
>>
>>  > <snip>
>>
>>> the whole thing is synchronous, running at 40 MHz on a Spartan 2E, 
>>> except a couple external inputs such as the "inputa" above.
>>
>>  > <snip>
>>
>> That right there could be your problem.  If those inputs aren't 
>> synchronous then you could get into some trouble if they change just 
>> before a clock edge happens.  Some of your state machine flops get the 
>> new message, some get the old one, and you've magically got an illegal 
>> state.
>>
>> Can you register those signals for a clock before you use them?
> 
> 
> In addition to registering all inputs, you also should make sure that 
> the state machine is initialized with a synchronous reset after your 
> DLLs have locked.
No DLLs, just a plain single clock.  The state machine and all other 
hardware
does initialize perfectly.

As for registering the inputs, that DOES seem to be the right thing to 
do, but the binary-coded state version works fine without.  Also, the 
clock rates on this are so low, it seems that this malfunction is 
happening too frequently.  I hadn't thought about the possibility of 
there being multiple gating paths from the syntax

if state = x then
   if inputa = '1' then
     state <= y;

to the actual flip-flops of signal "state", but I can see how that would
synthesize to such a condition.  A pretty narrow window for this to 
happen, but certainly conceivable.

Thanks, I will do the extra registering of the asynch inputs on the next 
rev of this!

Jon


Article: 132290
Subject: Re: How do I optimize filter coefficient bit length and signal bit
From: robert bristow-johnson <rbj@audioimagination.com>
Date: Tue, 20 May 2008 12:55:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 3:04 pm, "From Sweden" <s...@sw.se> wrote:
> Hello all
>
> I have made an 8 channel 500kHz low pass IIR-filter in VHDL. The filter uses
> 32 bits for it's coefficients and 32 bits for it's internal signals.
>
> The filter doesn't give the same DC-gain for small vs. large input signals.
> I suspect the internal truncation of the intermediate sums and states
> effects this.
>
> But today I thought about increasing the bits for the signal and decreasing
> the bits for the coefficients. I tried it out and the filter gave better
> gain over different input signal levels.
>
> Now I wonder how I should optimize the coefficient and signal bit lengths to
> get the best result?

32 bits oughta be enough for nearly any application.  a quantization
error of 1 part outa 4 bizillion?  i mean, holy crap!!!

the consequences of quantizing coefficients is different from
quantizing the signal (or some internal intermediate signal).

quantizing coefficients means that the filter you get is not precisely
the one that you designed.  the poles and zeros didn't go exactly to
where you wanted them to go.  but with 32-bits it should easily be
close enough.  how the coefs map to the poles and zeros depends on the
filter topology.  what topology are you using?  Direct Form 1 or
Direct Form 2 or Lattice or Normalized Ladder or some other?  (i think
there is a Gold-Rader form, there's a bunch of them, some of which
have an internal All-pass filter that the rest of the thing is built
around.  i am a partisan for the Direct Form 1 in fixed-point
applications.)  what you do, is solve for the pole and zero loci as a
function of the coefs (that get quantized) and see what effect the
coef quantization has on the pole/zero locus.  but dividing each of
two dimensions of the unit circle up into 4 bizillion slices should be
more than good enough.

consequences of quantizing the signal can range from a additive noise
model (if the signal amplitude is much, much larger than the
quantization level) to all sorts of nasties (harmonic distortion,
limit cycles).  triangular PDF additive dither of 2 LSB amplitude is
sufficient to get rid of that stuff.  i would think that at 32 bits,
simple 1st-order noise shaping (with a zero at DC) would suffice if
you got 32 bit words (no dither necessary).   this particular error or
noise shaping requires one extra state in the DF1 and has been called
"fraction saving" and Randy Yates has written about it recently in the
IEEE Sig Proc magazine.

really, 32 bit words oughta be good enough.

r b-j

Article: 132291
Subject: Re: bizarre state machine behavior
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 20 May 2008 12:57:03 -0700
Links: << >>  << T >>  << A >>
Jon Elson wrote:

> As for registering the inputs, 
> that DOES seem to be the right thing to do, 

It is.

> but the binary-coded state version works fine without.

So far, but wait a while.
The temperature may change.

> Also, the
> clock rates on this are so low, it seems that this malfunction is
> happening too frequently.

It's the the frequency *difference*
that sweeps the setup times
and throws the race the wrong way.

      -- Mike Treseler

Article: 132292
Subject: Re: bizarre state machine behavior
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 21 May 2008 08:58:30 +1200
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> 
> No DLLs, just a plain single clock.  The state machine and all other 
> hardware
> does initialize perfectly.
> 
> As for registering the inputs, that DOES seem to be the right thing to 
> do, but the binary-coded state version works fine without.  

That may have more to do with the implicit ELSE handling.
ie One State engine locks solid, the other will recover
in a few clocks (which means you may not notice, or have not
yet noticed the effects!)

Even with input registering, you should cover ALL states,
(including the 'illegal' ones) in your state code.


> Also, the 
> clock rates on this are so low, it seems that this malfunction is 
> happening too frequently. 

Can you clarify 'too frequently' ?
With a 25ns clock, a couple of IPs and 5 choices, lets
take a nice round 100ns IP sample rate. (10MHz)

An aperture effect of 1ns would be hit 1:100, or average 10us.

A more likely 100ps aperture, would hit 1:1000, or
average 100us, or 10,000 times a second. (assumes random hits)

Take your true IP sample rate, and reported timing skews, and
get a more accurate prediction.

>  I hadn't thought about the possibility of 
> there being multiple gating paths from the syntax
> 
> if state = x then
>   if inputa = '1' then
>     state <= y;
> 
> to the actual flip-flops of signal "state", but I can see how that would
> synthesize to such a condition.  A pretty narrow window for this to 
> happen, but certainly conceivable.
> 
> Thanks, I will do the extra registering of the asynch inputs on the next 
> rev of this!


There could be a case for the tools to
a) Warn on async state conditions
b) Warn that illegal/ELSE options are not covered


-jg


Article: 132293
Subject: Re: Instantiating an lpm dcfifo in Verilog
From: "jjlindula@hotmail.com" <jjlindula@hotmail.com>
Date: Tue, 20 May 2008 15:41:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 10:02 am, "jjlind...@hotmail.com" <jjlind...@hotmail.com>
wrote:
> Hello, I know many will say this is not an appropriate group to post
> such a question, but I wasn't getting any response on the Verilog
> group, so please let me apologize. I am new to Verilog and need some
> help instantiating a lpm dcfifo in my code. Here is what I have so
> far:
>
>  FIFIN   :       lpm_fifo_dc WITH (LPM_WIDTH = 64, LPM_NUMWORDS = 64,
> LPM_WIDTHU = 9, RDSYNC_DELAYPIPE = 3, WRSYNC_DELAYPIPE = 3);
>
> FIFIN.aclr                      = (!rstn);
> FIFIN.wrclock           = (clk);
> FIFIN.wrreq                     = (wr_fiforeq);
> FIFIN.data[31..0]       = (dma_wrdata);
> FIFIN.rdclock           = (clk);
> FIFIN.rdreq                     = (dma1_rddata);
> FIFIN.q                     = (rd_fiforeq);
>
> If anyone has some examples of instantiating a lpm function within
> Verilog I would greatly appreciate your help.
>
> Thanks,
> joe

Hello, I believe this works:

	dcfifo # (
		.intended_device_family ( "Stratix II GX"),
		.lpm_hint ( "MAXIMIZE_SPEED=5,"),
		.lpm_numwords ( 64),
		.lpm_showahead ( "OFF"),
		.lpm_type ( "dcfifo"),
		.lpm_width ( 64),
		.lpm_widthu ( 6),
		.overflow_checking ( "ON"),
		.rdsync_delaypipe ( 4),
		.underflow_checking ( "ON"),
		.use_eab ( "ON"),
		.write_aclr_synch ( "OFF"),
		.wrsync_delaypipe ( 4)
		)

		dcfifo_component (
				.wrclk (wrclk),
				.rdreq (rdreq),
				.aclr (aclr),
				.rdclk (rdclk),
				.wrreq (wrreq),
				.data (data),
				.wrusedw (sub_wire0),
				.q (sub_wire1),
				.rdusedw (sub_wire2)
				// synopsys translate_off
				,
				.rdempty (),
				.rdfull (),
				.wrempty (),
				.wrfull ()
				// synopsys translate_on
				);



Article: 132294
Subject: Re: bizarre state machine behavior
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 21 May 2008 00:23:07 +0100
Links: << >>  << T >>  << A >>
"Jon Elson" <elson@wustl.edu> wrote in message 
news:483324F1.4030005@wustl.edu...
>
> As for registering the inputs, that DOES seem to be the right thing to do, 
> but the binary-coded state version works fine without.
Hi Jon,
You do realise that every build can have different timing? If you're saying 
DOES because of your P&R results, you MAYBE mistaken.
HTH., Syms. 



Article: 132295
Subject: Re: 2-bit Pseudo Random Number Generator
From: Jeff Cunningham <jcc@sover.net>
Date: Tue, 20 May 2008 23:40:20 -0400
Links: << >>  << T >>  << A >>
Symon wrote:
> "Jeff Cunningham" <jcc@sover.net> wrote in message 
> news:483200e3$0$11170$4d3efbfe@news.sover.net...
>> Clemens wrote:
>>
>>> A different seed for each power-up would have been nice.
>> Here's a method I've used for this in the past:
>>
>> Create a ring oscillator that can be stopped by some other bit. The ring 
>> oscillator drives a 2-bit ripple counter.
>>
>> Once the FPGA clock starts up, count off say 1 second's worth pulses of 
>> your high speed system clock and then disable the ring oscillator. The 
>> ripple counter will now have your 4-bit random value.
>>
>> This method relies on slight differences in the ring osc rate due to 
>> heating, etc. to add up over 1 second at startup. You might need to 
>> experiment with adding buffers (and make sure the tools don't remove them) 
>> and such to make sure the ring osc rate is not too high.
>>
>> -Jeff
> 
> Hi Jeff,
> 
> I've heard that ring oscillators can phase lock to other clocks on the same 
> die. What did you find? I came across  this link that gives some insights 
> into the pitfalls.
> http://warmcat.com/_wp/

Hi Syms,

To generate one number at startup it seemed to work fine, though I admit 
I didn't subject it to statistical analysis beyond just looking a a 
bunch of samples. I actually used it to create a GUID that would be 
stored in flash the first time the product was ever turned on. The goal 
was that no two devices would have the same number. It seemed to work 
well for that. Maybe not a good technique for crypto.

Interesting web site though.

-Jeff

Article: 132296
Subject: Re: bizarre state machine behavior
From: Jeff Cunningham <jcc@sover.net>
Date: Tue, 20 May 2008 23:55:05 -0400
Links: << >>  << T >>  << A >>
Jon Elson wrote:

>> In addition to registering all inputs, you also should make sure that 
>> the state machine is initialized with a synchronous reset after your 
>> DLLs have locked.
> No DLLs, just a plain single clock.  The state machine and all other 
> hardware
> does initialize perfectly.

Just be aware that even without DLLs to worry about, the internal reset 
is asynchronous and can cause problems if the state bits see it go away 
on different clock pulses, i.e. it is another asynchronous input to your 
state machine. I generally always do something like this:

signal resetv: std_logic_vector(2 downto 0) := "000";

process(clk)
begin
   if rising_edge(clk)
     resetv <= resetv(1 downto 0) & 1;
   end if;
end process;

state_machine_reset <= not resetv(2);

-Jeff

Article: 132297
Subject: Re: Stratix IV Announced
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Wed, 21 May 2008 08:17:07 +0300
Links: << >>  << T >>  << A >>
austin wrote:
> Joseph,
> 
> Imagine all those Altera customers who designed in the Stratix III GX:
> all dressed up, and nowhere to go.

Maybe Altera also shares roadmaps like you do to bigger customers, and
those designers maybe do not exist... Imagine all those V4FX designers
who wanted working fast tranceivers.

I would say all vendors offer surprises to customers who are using
leading edge devices.

> Lower Cost: Virtex 5 EasyPath(tm) devices, guaranteed to work, because
> they are IDENTICAL to the FPGA

My opinion is that EasyPath is the worst of the two worlds. It has
limitations in flexibility, and the possibilities with price are
not that great because it is the same silicon. Better to have either
the full flexibility which costs or then the lowest possible cost
with no flexibility.

--Kim

Article: 132298
Subject: Re: XILINX Ethernet MAC (URGENT...)
From: vikram <vikram788@gmail.com>
Date: Tue, 20 May 2008 22:19:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 5:44=A0pm, morphiend <morphi...@gmail.com> wrote:
> On May 19, 1:35 am, vikram <vikram...@gmail.com> wrote:> hello,
>
> > I am trying to interface between my pc (windows) and a Xilinx
> > Virtex2Pro board using ethernet. i am told i require Xilinx PLB
> > Ethernet MAC ip core. i must admit i am very new to such work, forgive
> > my blatantness.... i would like to know:
>
> > 1) What exactly do i get in the Xilinx Ethernet MAC ip core? (design
> > files etc?)
>
> You get the unlocked CoreGen core. In other words, you could generate
> the core from CoreGen and use it however. Or, you'll be able to use it
> directly in EDK. Of course, since you're referring to the V2Pro,
> you're also referring to the Softcore MAC. This provides a full MAC
> capable of performing 10/100 communication. Starting with EDK 9.2, the
> OPB version of the core has been released for 'free' (included w/ the
> purchase of EDK 9.2).
>
> > 2) Using XPS (EDK 9.1) and ISE 9.1, how do i integrate it into an
> > existing project?
>
> It will appear as an unlocked core in the High-Speed communications
> category of the EDK core list in any of your projects.
>
> > 3) the ethernet is just a part of the project.... i only need to
> > transfer data between my pc and the board.... should the MAC be a part
> > of the board?
>
> Well, Ethernet is split into multiple parts. The first part is the PHY
> or the physical communication. This provides the lowest layer to which
> the data is transmitted. This device is responsible for conversion
> from a Media-Independent Interface (R/S/G/MII) to the physical layer:
> copper/fiber/etc. The next layer up is the MAC: Media Access Control.
> This provides the conversion from your real data into a Media-
> Independent Interface (R/S/G/MII). So unless you're going to build
> your own MAC and design it to meet all of the IEEE specs for whatever
> MII you use, then YES you need it.
>
> > 4) do i have to use an embedded processor (microblaze/powerpc) to
> > integrate the MAC?
>
> No, but depending on what you're doing you may want to have processor
> perform the work. It's possible to create devices that just take/put
> streams with solely logic and state machines. But if you want to start
> handling TCP traffic or anything higher-layer (HTTP/FTP) or more
> complicated you will probably want a processor and software to handle
> it. But that's my $0.02.
>
> -- Mike

dear Mike

thanks for the prompt response. the board i'm using has an on-board
PHY.
>You get the unlocked CoreGen core. In other words, you could generate
   the core from CoreGen and use it.

once i have the generated MAC core, do i just add it to my existing
project to 'use' it?
or, from EDK, do i add it as a peripheral ("import peripheral") to my
existing project?

thanks again
vikram

Article: 132299
Subject: Re: Stratix IV Announced
From: Peter Alfke <alfke@sbcglobal.net>
Date: Tue, 20 May 2008 23:07:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 10:17=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> austin wrote:
> > Joseph,
>
> > Imagine all those Altera customers who designed in the Stratix III GX:
> > all dressed up, and nowhere to go.
>
> Maybe Altera also shares roadmaps like you do to bigger customers, and
> those designers maybe do not exist... Imagine all those V4FX designers
> who wanted working fast tranceivers.
>
> I would say all vendors offer surprises to customers who are using
> leading edge devices.
>
> > Lower Cost: Virtex 5 EasyPath(tm) devices, guaranteed to work, because
> > they are IDENTICAL to the FPGA
>
> My opinion is that EasyPath is the worst of the two worlds. It has
> limitations in flexibility, and the possibilities with price are
> not that great because it is the same silicon. Better to have either
> the full flexibility which costs or then the lowest possible cost
> with no flexibility.
>
> --Kim

Let's not turn this into a marketing slugfest.
It does not take a genius to figure out why Altera was forced to
embark on such a risky gamble...
"We live in interesting times"
Peter Alfke



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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