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 70025

Article: 70025
Subject: Re: Driving fpga pin out over long cable
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 28 May 2004 08:03:41 +1200
Links: << >>  << T >>  << A >>
sanpab@eis.uva.es wrote:

> Peter Alfke <peter@xilinx.com> wrote in message news:<40B38A28.FDBF2E3F@xilinx.com>...
> 
>>Here is another suggestion:
>>Normally transmit a clock that is 30% High, 70% Low, but at the
>>synchronization moment, change one time to 70% High, 30%Low.
>>In the receiver, use the DLL to generate 50% duty cycle (the DLL is
>>always triggered on the rising clock edge). Then use the falling output
>>edge from the DLL to clock the incoming clock level into a flip-flop.
>>This flip-flop will be High for just one clock cycle.
>>This idea is similar to the "missing clock pulse synchronization"
>>mentioned before, but avoids its problems...
>>BTW: You must dc-couple the clock for this suggestion !
>>Peter Alfke, Xilinx Applications.
> 
> 
> Great solution, Peter. Some years ago I used this scheme to
> communicate two systems ... until I change to Manchester ;-).
> 
> Anyway, has someone thought that the signal needs about 250 ns (25
> clock cycles at 100 MHz) to fly from one board to the others. 50m are
> 50m, and light speed is light speed.

Yes, but the OP did say the cable lengths were equal ?


Gabor Szakacs wrote:
 > To go one step further with Peter's idea, you can AC couple if instead
 > of sending an occasional "pulse" (one cycle of 70% high) you send a
 > "square wave" of say 50 cycles of 30% high followed by 50 cycles of 70%
 > high.  This gives you synchronizing events at each edge of the wave and
 > keeps the DC balance over the period of 1uS.

This is how TV frame sync pulses are sent, and is a good idea.
-jg


Article: 70026
Subject: Re: What can I do if my chip can't meet timing?
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Thu, 27 May 2004 16:38:10 -0500
Links: << >>  << T >>  << A >>


Kelvin wrote:

>The original author tested the RTL on a Virtex2...Now I am still
>V2 but I need to split the chip into RX & TX and compile them in
>partial reconfigurable mode...In full V2 chip compilation, it satisfied
>timing at 24.5ns...in partial compilation, timing is 25~26ns...
>
>I am aware partial reconfigurable compilation introduces long wire
>delays...Since the interface signals between RX/TX are registered,
>so I don't have effictive control over the offset delays...
>
>TX/RX(with FFT) shares FFT & trigonormetric functions, which
>contain critical paths...
>
>  
>
I think this is the key, here.  If you have the space, you may need to 
duplicate
these shared functions, giving place/route the freedom to put these 
resources
close to where they are needed, rather than having one or the other sections
(RX or TX) having to reach all the way across the chip to get to them.

If you don't have the space to duplicate these functions, then you have 
a big
problem.  If there's a faster speed grade of the chip, that might help.

Jon


Article: 70027
Subject: Re: Driving fpga pin out over long cable
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 27 May 2004 18:35:44 -0700
Links: << >>  << T >>  << A >>
That's  a lot of wasted overhead time, and I threw in the warning about
the need for dc coupling as a afterthought. Why would anybody use ac coupling?

Regarding the train of  25 to 30 pulses travelling together on the
cable: That's fine, if you terminated the far end properly !

Peter Alfke
===============
Gabor Szakacs wrote:
> 
> To go one step further with Peter's idea, you can AC couple if instead
> of sending an occasional "pulse" (one cycle of 70% high) you send a
> "square wave" of say 50 cycles of 30% high followed by 50 cycles of 70%
> high.  This gives you synchronizing events at each edge of the wave and
> keeps the DC balance over the period of 1uS.
> Peter Alfke <peter@xilinx.com> wrote in message news:<40B38A28.FDBF2E3F@xilinx.com>...
> > Here is another suggestion:
> > Normally transmit a clock that is 30% High, 70% Low, but at the
> > synchronization moment, change one time to 70% High, 30%Low.
> > In the receiver, use the DLL to generate 50% duty cycle (the DLL is
> > always triggered on the rising clock edge). Then use the falling output
> > edge from the DLL to clock the incoming clock level into a flip-flop.
> > This flip-flop will be High for just one clock cycle.
> > This idea is similar to the "missing clock pulse synchronization"
> > mentioned before, but avoids its problems...
> > BTW: You must dc-couple the clock for this suggestion !
> > Peter Alfke, Xilinx Applications.
> > =====================================
> > John_H wrote:
> > >
> > > How about this weird idea:  Don't send a pulse, send an edge.  Your
> > > attenuation might provide a little phase shift but it would be pretty easy
> > > to alter the phase to match the clocks.  Rather than a smeared pulse with
> > > low high-level amplitudes, you get a full transition with a consistent 50%
> > > point.
> > >
> > > "Tom Derham" <uceeted@ucl.ac.uk> wrote in message
> > > news:xtvsc.1724$hu1.16883825@news-text.cableinet.net...
> > > > I am using 3 Xilinx SpartanIIE boards, each loaded with a similar design
> > > > running with a 100MHz master clock.  This clock is derived from a single
> > > > source and distributed to each board so they are synchronised.  The boards
> > > > are postioned about 50m apart.
> > > >
> > > > I need to synchronise events on the boards, but occasionally sending a
> > > > single pulse (say 10ns long) from the output pin of one of the FPGAs to
> >  the
> > > > other boards, to allow them to synchronise internal timers.  I need to
> >  make
> > > > sure that the pulse arrives at the other two boards at the same time so
> >  that
> > > > it is 'recognised' on the same rising edge of the reference clock in each
> > > > case, so that the boards synchronise together.
> > > >
> > > > Clearly the attenuation of any 50m length of cable is such that I cannot
> > > > connect them directly, but nor do I want the complexity of converting the
> > > > pulse to optical fibre and back again.
> > > > For the distribution of the reference clock I am using National CLC005/012
> > > > driver and equaliser chipset over UTP, using equal length wires so as to
> >  not
> > > > introduce propagation skew.  For practical reasons I can't use the same
> > > > cable for sending this event pulse, and ideally would like a simple,
> >  elegant
> > > > solution.
> > > > I was just wondering if anyone had done anything similar before... if not,
> >  I
> > > > have a back-up plan using more of the National drivers, but I thought they
> > > > might be a sledgehammer to crack a nut - and am unsure what levels of skew
> > > > they may introduce themselves... jitter is not so important because the
> > > > event is resynced at the receiving fpga, as long as the total difference
> >  in
> > > > edge is less than half of the reference clock cycle (so 5ns).
> > > >
> > > > Thank you in advance for any ideas....
> > > >
> > > >

Article: 70028
Subject: Re: Driving fpga pin out over long cable
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 28 May 2004 13:43:41 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> That's  a lot of wasted overhead time, and I threw in the warning about
> the need for dc coupling as a afterthought. Why would anybody use ac coupling?
> 
> Regarding the train of  25 to 30 pulses travelling together on the
> cable: That's fine, if you terminated the far end properly !

ac coupling could allow improved ground tolerance ?.
The 50m is pushing LVDS common mode a little.

ac coupling would have minor effects, if the rolloff was right.
- a handfull of skewed clocks would pass OK.
  What COULD be important, is the general LPF actions of longish
cables, and the eye distortions that causes.
  Perhaps merit in a couplet of 30/70/70/30 as a minimal disturbance 
sync scheme ( no nett low frequency content) ?
  Because it uses a common clock, and can define a start edge
explicitly, this sync-on-clock scheme can deliver an order of
magnitude improvement over the OPs first jitter target, so it
pays to think just how good it can get.

-jg


Article: 70029
Subject: Re: What can I do if my chip can't meet timing?
From: "Kelvin" <student@nowhere.com>
Date: Fri, 28 May 2004 10:09:34 +0800
Links: << >>  << T >>  << A >>
unfortunately I have no space to duplicate the shared modules that is why I
am a little
worried now.

I think I still have a few variables to play with, for example the
Synplicity, floorplanning,
yeah thanks, speed grade etc.

Best Regards,
Kelvin




"Jon Elson" <jmelson@artsci.wustl.edu> wrote in message
news:40B65FC2.3040900@artsci.wustl.edu...
>
>
> Kelvin wrote:
>
> >The original author tested the RTL on a Virtex2...Now I am still
> >V2 but I need to split the chip into RX & TX and compile them in
> >partial reconfigurable mode...In full V2 chip compilation, it satisfied
> >timing at 24.5ns...in partial compilation, timing is 25~26ns...
> >
> >I am aware partial reconfigurable compilation introduces long wire
> >delays...Since the interface signals between RX/TX are registered,
> >so I don't have effictive control over the offset delays...
> >
> >TX/RX(with FFT) shares FFT & trigonormetric functions, which
> >contain critical paths...
> >
> >
> >
> I think this is the key, here.  If you have the space, you may need to
> duplicate
> these shared functions, giving place/route the freedom to put these
> resources
> close to where they are needed, rather than having one or the other
sections
> (RX or TX) having to reach all the way across the chip to get to them.
>
> If you don't have the space to duplicate these functions, then you have
> a big
> problem.  If there's a faster speed grade of the chip, that might help.
>
> Jon
>



Article: 70030
Subject: Tool to help detecting race conditions with asych inputs?
From: usenet_10@stanka-web.de (Thomas Stanka)
Date: 27 May 2004 23:50:12 -0700
Links: << >>  << T >>  << A >>
Hello,

do you know any tool, that would help detecting race conditions due to
asynchronous inputs?

I had a design with asynchronous inputs. I inspected the rtl code to
ensure, the asynch inputs would only be used if they are stable with
respect to the specification. Unfortunately I missed a line, where an
asynchronous input release an synchron reset. The synthesis generated
a race condition which lead to disfunction of the design. After
founding the problem it was very easy to see the failure in the
netlist. But it seem to me very hard to detect the problem without
knowing that it would happen, because whether timing analysis (maybe
not propper done) nor equivalence checking nor gate level simulation
failed.

Are there tools, that would help in such cases? I don't like the idea
to spend hours and days inspecting netlists for asynchronous inputs I
use to ensure, that this failure won't happen a second time.

I know, that it would be best to avoid asych. inputs by inserting
registers, but I have some designs with hard area constraints and
other designs with timing constraints that didn't permit the use of
registers for all inputs.

bye Thomas

Article: 70031
Subject: Re: Altium FPGA board
From: "Chuck McManis" <devnull@mcmanis.com>
Date: Fri, 28 May 2004 07:03:59 GMT
Links: << >>  << T >>  << A >>
"Rene Tschaggelar" <none@none.net> wrote in message
news:40b4e313$0$718$5402220f@news.sunrise.ch...

> No, no, I didn't misread.
> The more modern compilers come with an IDE, including programmer that
> download the code and the data and even allow to debug the code on
> target. This likely won't work anymore, as the integration likely does
> not go this far. And the ADC is missing of course too.
>
> I doubt the AVR core is from Atmel itself, rather from some guys who
> took the pain of assembling an AVR act-alike. Atmel is of course
> interested in selling their own chips.

Then we are talking about two different things. Atmel part number AT94K05 is
an Atmel AVR core that is surrounded by an FPGA. It is sold by Atmel and all
the standard IDE's and tools work with the AVR core which, unless Atmel is
really stupid, is the exact same core they use in their other chips. The
evaluation kit number is STK594 and it plugs into the STK501 base. The part
number on this demo board is the AT94K05.

> Atmel is of course interested in selling their own chips.

This IS thier own chip.

--Chuck



Article: 70032
Subject: how can I merge 66mhz pci clock to 33mhz clock?
From: "rat" <rattt@col.edu.cn>
Date: Fri, 28 May 2004 15:11:03 +0800
Links: << >>  << T >>  << A >>
Hi,
  I want to design a pci target chip in cpld, and I want it work both in
66mhz and 33mhz pci environment, how can I translate 66mhz pci clock in
33mhz clock in the chip? thanks! I have try 2-bit counter but it seems that
the delay between newlock and original clock posedge is large..
  Thanks a lot!

rat



Article: 70033
Subject: Yawn...Cannot copy Acrobat Reader -write_timing_constraints YES directly into .xst file...
From: "Kelvin" <student@nowhere.com>
Date: Fri, 28 May 2004 15:38:53 +0800
Links: << >>  << T >>  << A >>
Got my lesson again...Acrobat - sign is hex 96...Text file - is 2D...
But ultraedit treats two codes the same...

KElvin







Article: 70034
Subject: Re: Tool to help detecting race conditions with asych inputs?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 28 May 2004 03:25:41 -0500
Links: << >>  << T >>  << A >>
>do you know any tool, that would help detecting race conditions due to
>asynchronous inputs?

One clean approach is to run all external async inputs through
the standard 2-FF synchronizer.  Then they are synchronous and
normal tools will work.

The key tool for that is a pair of eyeballs.  Scan the source
code and make sure that the only place an async inputs go is into
the synchronizers.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 70035
Subject: Re: How to generate a 320x200 VGA signal?
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Fri, 28 May 2004 15:45:30 +0700
Links: << >>  << T >>  << A >>
Paul Marciano wrote:

> Hi.  I'd like to build an 80s-style display controller, but I want to
> output the image to a VGA monitor.

[SNIP]

> Thanks,
> Paul.


Take a look at the VGA controller at www.opencores.org.

Regards,
rudi               
========================================================
   ASICS.ws   ::: Solutions for your ASIC/FPGA needs :::
..............::: FPGAs * Full Custom ICs * IP Cores :::
FREE IP Cores -> http://www.asics.ws/  <- FREE EDA Tools

Article: 70036
Subject: Re: www.opencores.org ???
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Fri, 28 May 2004 15:51:40 +0700
Links: << >>  << T >>  << A >>
Gabor Szakacs wrote:

> James <james@zavoo.com> wrote in message
> news:<rTPsc.3570$L8.1433@fe2.columbus.rr.com>...
>> mikegw wrote:
>> > Anyone know what happed to this site?  It has been off the air for a
>> > few days now.
>> > 
>> > Mike
>> > 
>> > 
>> Try a mirror:
>> http://opencores.nnytech.net/projects.cgi/web/opencores/mirrors
> The mirror works, but site still has some links to www.opencores.org
> which don't :(


www.opencores.org is back on-line !

Regards,
rudi               
========================================================
   ASICS.ws   ::: Solutions for your ASIC/FPGA needs :::
..............::: FPGAs * Full Custom ICs * IP Cores :::
FREE IP Cores -> http://www.asics.ws/  <- FREE EDA Tools

Article: 70037
Subject: Re: Trying to build simple demo using XPS and XC2VP20
From: "Antti Lukats" <antti@case2000.com>
Date: Fri, 28 May 2004 04:47:30 -0700
Links: << >>  << T >>  << A >>
> Error:PACK:1195 ppc405_1/ppc405_1/PPC405_i has no output pin.
>
> ppc405_1 is the wrapper for the second cpu (the first being ppc405_0).
>
> I have no idea what this means. Can anyone point out to me the error of
> my ways here? Thus far I've not managed to complete the tutorial, so feel
> slightly foolish :)

dummy modules should have at least one output pin or they will be optimized
away or produce error.

just add dummy output, and make sure the dummy signal is actually used i.e.
make sure the load is not optimized away,
just route a constant GND to some unused IO as example.

not sure if it helps in your case, but it helps to bypass the error "no
output"

we are forced to use this technology sometimes when using chipscope cores,
they have only inputs!
(outputs are hidden as they go tho bscan primitive only)

Antti
xilinx.openchip.org



Article: 70038
Subject: Re: Driving fpga pin out over long cable
From: "Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk>
Date: Fri, 28 May 2004 13:39:29 +0100
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:APwtc.4324$FN.454262@news02.tsnz.net...
> ac coupling would have minor effects, if the rolloff was right.
> - a handfull of skewed clocks would pass OK.
>   What COULD be important, is the general LPF actions of longish
> cables, and the eye distortions that causes.
>   Perhaps merit in a couplet of 30/70/70/30 as a minimal disturbance
> sync scheme ( no nett low frequency content) ?
>   Because it uses a common clock, and can define a start edge
> explicitly, this sync-on-clock scheme can deliver an order of
> magnitude improvement over the OPs first jitter target, so it
> pays to think just how good it can get.

Some great thoughts and information, thank you!

Unfortunately I don't have much control over the master clock - it is
derived from an OCXO, goes through a power splitter, then is sent down the
cables using the Natsemi chipset (provides active equalisation at the
receiver based on high frequency content from which it can approximate the
cable length and hence the equalisation curve required).  This clock must be
as low phase noise as possible because it is also used to clock other
components (e.g. ADC), and a clock derived from an FPGA (over which I could
have control) would have much worse jitter.

I like the idea of level sensing rather than edge sensing as the events are
only occasional - it just means that the threshold crossing should be stable
and occur during the same clock cycle at each board.
To that end, the TI M-LVDS chips look a good bet - high drive level, low
impedance.
They do however specify a ground voltage difference of less than 1V.
I can connect the grounds of the power supplies for each board together so
that should provide a fairly low impedance path.. I will try it out and
report back to the group.

Many thanks for your help
Tom





Article: 70039
Subject: Xilinx System Generator
From: "Timo Dammes" <timo.dammes@gmx.de>
Date: Fri, 28 May 2004 15:39:51 +0200
Links: << >>  << T >>  << A >>
Hello

I'd like to use Xilinx System Generator (Matlab Simulink tool) to configure
a Xilinx fpga : (Spartan 2,  Xc2s200) for a practical course at university.

If anyone has experiences with System Generator :
Is it possible to access the memory of the fpga with a block ? I wrote a c++
program that transfers data (i.e. a picture) to the fpga's memory. Then I'd
like the System Generator schematic to read that data, work with it and
write it back to the memory. Is that possible with the "single port ram"
block ?

Does anyone already have an example program ?

Regards,
Timo Dammes



Article: 70040
Subject: how to random generate packet for Ethernet MAC(802.3) with verilog in testbench ?
From: sarahshen2003@yahoo.ca (sarah)
Date: 28 May 2004 08:23:36 -0700
Links: << >>  << T >>  << A >>
Hi,

Does anybody know how to random generate packet for Ethernet
MAC(802.3) with verilog in testbench ? How to do testbench for
WISHBONE bus?

Thanks.

Sarah

Article: 70041
Subject: VHDL test bench in Quartus
From: Pratip Mukherjee <pkm11@hotmail.com>
Date: Fri, 28 May 2004 18:02:59 GMT
Links: << >>  << T >>  << A >>
Is it possible to write a test bench using VHDL in Quartus? When I tried I 
got an error message telling me that wait <n> construct is not supported. 
Is that true or am I making some mistake? Is there any way, may be using 
tcl, I can simulate a VHDL like test bench? Testbench using waveforms just 
does not work for me.
Thanks.

Pratip Mukherjee
pratipm.remove_this@hotmail.com

Article: 70042
Subject: Re: How to generate a 320x200 VGA signal?
From: "Jean Nicolle" <j.nicolle@sbcglobal.net>
Date: Fri, 28 May 2004 19:21:49 GMT
Links: << >>  << T >>  << A >>
Here's a design using 640x480 VGA.
http://www.fpga4fun.com/PongGame.html



Article: 70043
Subject: Re: VHDL test bench in Quartus
From: mike_treseler@comcast.net (Mike Treseler)
Date: 28 May 2004 14:40:34 -0700
Links: << >>  << T >>  << A >>
Pratip Mukherjee <pkm11@hotmail.com> wrote in message news:<Xns94F78EDBFB5E2PratipMukherjee51@216.148.227.77>...

> Is it possible to write a test bench using VHDL in Quartus?

No. Use modelsim or sonata.

 -- Mike Treseler

Article: 70044
Subject: Re: Tool to help detecting race conditions with asych inputs?
From: mike_treseler@comcast.net (Mike Treseler)
Date: 28 May 2004 15:26:05 -0700
Links: << >>  << T >>  << A >>
usenet_10@stanka-web.de (Thomas Stanka) wrote in message news:<ef424d2c.0405272250.ba032e@posting.google.com>...
> Hello,
> 
> do you know any tool, that would help detecting race conditions due to
> asynchronous inputs?

No. That would difficult problem even if you were
given all the gate and route delay ranges.

> I had a design with asynchronous inputs. I inspected the rtl code to
> ensure, the asynch inputs would only be used if they are stable with
> respect to the specification. Unfortunately I missed a line, where an
> asynchronous input release an synchron reset. The synthesis generated
> a race condition which lead to disfunction of the design. After
> founding the problem it was very easy to see the failure in the
> netlist.

You found the source of one race condition. 
There are no doubt others that will introduce themselves
over time, temperature, state and input variations.

>  I don't like the idea
> to spend hours and days inspecting netlists for asynchronous inputs I
> use to ensure, that this failure won't happen a second time.

I don't either. Consider doing whatever is necessary
synchronize all the inputs to the system clock.

> I know, that it would be best to avoid asych. inputs by inserting
> registers,

That's it.

>  but I have some designs with hard area constraints and
> other designs with timing constraints that didn't permit the use of
> registers for all inputs.

That is an engineering problem. 
There are always alternatives.

  -- Mike Treseler

Article: 70045
Subject: Re: Tool to help detecting race conditions with asych inputs?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 28 May 2004 22:15:15 -0500
Links: << >>  << T >>  << A >>
>I had a design with asynchronous inputs. I inspected the rtl code to
>ensure, the asynch inputs would only be used if they are stable with
>respect to the specification.

Thinking about this some more...

What does that actually mean?  If a signal is asynchronous (relative
to some other clock/signal) how/when can it be stable?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 70046
Subject: Re: how to random generate packet for Ethernet MAC(802.3) with verilog in testbench ?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 29 May 2004 12:28:53 -0700
Links: << >>  << T >>  << A >>
Sarah wrote:

> Does anybody know how to random generate packet for Ethernet
> MAC(802.3) with verilog in testbench ? How to do testbench for
> WISHBONE bus?

Yes, I expect that many people could and that you could too.
Sound like an excellent class project.

http://groups.google.com/groups?q=generate+ethernet+packet

 -- Mike Treseler


Article: 70047
Subject: Re: Tool to help detecting race conditions with asych inputs?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 29 May 2004 13:00:21 -0700
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> What does that actually mean?  If a signal is asynchronous (relative
> to some other clock/signal) how/when can it be stable?

Stable phase could mean the signal has 
already been properly synchronized.

But a "stable" signal transition could also 
occur exactly at the active clock edge.

 --Mike Treseler


Article: 70048
Subject: Re: Propogation delays and setup times
From: "Hendra Gunawan" <u1000393@email.sjsu.edu>
Date: Sat, 29 May 2004 15:10:41 -0700
Links: << >>  << T >>  << A >>

"LC Geldenhuys" <lcgeldenhuysNOSPAM@mecalc.co.za> wrote in message
news:kkmbb0tq1di62deu2i1utmg9a80obnsdqc@4ax.com...
> Hi,
>
> I have a number of address lines feeding into a combinatorial address
> decoder, the output of which is clocked twice before being used in my
> state machine. It could happen that, due to different propagation
> delays on the address bus, the first flop clocks an incorrect 'valid'
> address selected. In the next clock period the address lines will have
> settled and the correct address will be decoded and either selected or
> not.

I don't think there should be any problem. Your Synthesis / Place and Route
tool should be able to determine the delay of your address decoder. And if
your address decoder happen to be the longest combinational logic delay in
your system, the tool should be able to report back to the user that the
system can run at a clock rate that doesn't run faster than the delay of
your address decoder.

Hendra



Article: 70049
Subject: Re: Propogation delays and setup times
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 30 May 2004 01:11:09 GMT
Links: << >>  << T >>  << A >>
On Thu, 27 May 2004 14:19:18 +0200, LC Geldenhuys <lcgeldenhuysNOSPAM@mecalc.co.za> wrote:
>Hi,
>
>I have a number of address lines feeding into a combinatorial address
>decoder, the output of which is clocked twice before being used in my
>state machine.

On the right track here, but since you are dealing with multiple
signals changing (the address bus) the transition from one decode
value to another is not going to be monotonic, and so you may get
a rapid sequence of transitions prior to a final stable value.

>It could happen that, due to different propagation
>delays on the address bus, the first flop clocks an incorrect 'valid'
>address selected. In the next clock period the address lines will have
>settled and the correct address will be decoded and either selected or
>not.

Right. This is quite a likely outcome. While the double register you
are using is normally associated with dealing with metastables, you
are dealing with something that happens far more often, a race
condition between the various address lines, and your multiple
decoded outputs.

As an aside, multiple synchronizers, based on the same base signal
set (the address in your case) is a bad scheme anyway, as synchronizers
always have a +/- 1 cycle uncertainty in their resolving function.
A better architecture is to synchronize the source signals, then do
the decode in the synchronous domain. You still need to deal with
the variable delays (address stable time of each address line) of
the inputs to your synchronizer. I'm comming to that soon.

>Apart from checking for two (or more?) consecutive 'valid' pulses,
>what else can I do to avoid or mitigate this problem?

This is the heart of your problem. Even looking at the 'valid'
pulses may not be enough, as there is still the problem of
metastability, and there are scenarios where you may two
'valid' decodes that overlap. I.E. a decode of 4XXX and CXXX
might look like this:

4XXX   00001100000
CXXX   00000111111

Unless the system has been really poorly designed, there should be
a signal that says either that the address has changed, or that the
address is valid.

Here is what a robust system might look like:

Address changes.
Address valid signal goes high.
The address valid signal goes through 2 stage synchronizer (just 2 FFs)
When the address valid signal is seen out of the second FF, a
 register is loaded with the address (We know it has been stable for
 at least 2 clocks, so it is safe to clock into a register.
The decode is done in the synchronous domain.

If the decode is known to be faster than 2 clock cycles, then the
 decode could be in the address bus domain, and the register that
 is clocked when the address valid signal comes out of the second
 FF, could be the output of the decoders.

If you dont' have either the address valid signal, or the address
does not stay stable for at least 2 cycles, then you have some real
tough problems to solve.

>Regards,
>  Lourens


Philip



===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM



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