Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. -jgArticle: 70026
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. JonArticle: 70027
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
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. -jgArticle: 70029
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
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 ThomasArticle: 70031
"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. --ChuckArticle: 70032
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! ratArticle: 70033
Got my lesson again...Acrobat - sign is hex 96...Text file - is 2D... But ultraedit treats two codes the same... KElvinArticle: 70034
>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
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 ToolsArticle: 70036
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 ToolsArticle: 70037
> 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.orgArticle: 70038
"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 TomArticle: 70039
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 DammesArticle: 70040
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. SarahArticle: 70041
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.comArticle: 70042
Here's a design using 640x480 VGA. http://www.fpga4fun.com/PongGame.htmlArticle: 70043
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 TreselerArticle: 70044
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 TreselerArticle: 70045
>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
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 TreselerArticle: 70047
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 TreselerArticle: 70048
"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. HendraArticle: 70049
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:
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