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
John, I still do not think that this would work. And if it did, it would still be a precarious thing, with no re-enforcement. Bite the bullet, and strap an extra connection between the chips... Peter AlfkeArticle: 83976
ALuPin@web.de wrote: > Do you mean that it is impossible to use external synchronous data in a > state machine without resynchronization ? Why? > You have to know your design AND external device perfectly + assign the proper constraints + verify that they're met by STA. It's usually tricky since you won't catch problems at RTL simulation, and very likely not in timing sim either, so this pushes the discovery of problem at a very late stage of the design, hoping not too late... Nothing is impossible, some ways are just more dangerous than others. Bert CuzeauArticle: 83977
Hi, I think the way ECS works is that it writes out a netlist of your schematic in an HDL using instantiated primitives from the UNISIM library. Then, the design is actually synthesized by XST before it heads into MAP and PAR. By default, XST does not "optimize" instantiated primitives. You can override this option, I think it is called "optimize_primitives" and you'd set it to "yes". Consult the online help system to find the specific name of the option. If you have trouble finding it, file a case with the Xilinx customer support team and they will help you find it. Eric "Gunter Knittel" <knittel@gris.uni-tuebingen.de> wrote in message news:d5kgh4$m6u$1@newsserv.zdv.uni-tuebingen.de... > Hi Folks, > > I'm using ECS (yes, I know...). Now, ECS forces one to insert > a buffer whenever one wants to rename a bus. I have done so. > I was stunned to see that buffer appear in the routed design - > as a LUT with D=A1! > I'm sure I can get rid of it using the proper XST or PAR options, > but I don't know which. > Can anybody help? > > Thanks a lot > Gunter > >Article: 83978
Look at http://www.xilinx.com/products/virtex4/capabilities/selectio.htm#chipsync and http://www.xilinx.com/products/design_resources/conn_central/resource/ssio_resources.htm for discussions on the 1 Gbit/s/pin Virtex-4 differential I/O and you may get a better feel for the margins you can get in your design. If all your LVDS are at the same clock rate, the DCM skews shouldn't be a problem and could easily be registered back to the slower domain if the skews were an issue. Xilinx went to great lengths to make the Virtex-4 I/O capable of some pretty high speeds without taxing the designer. <fastgreen2000@yahoo.com> wrote in message news:1115750937.589232.47940@f14g2000cwb.googlegroups.com... > I'm about to use Virtex 4, and wonder if this is achievable. All > literature seems to indicate that it is, but I'd like hear what others > think and perhaps point out where I need to be careful in the design. > > I'd be receiving an LVDS clock pair @ 360Mhz, running part of the > internal logic at 360. This internal logic includes DSP48 slices (but > need to be pipelined in the fabric since I need more than 48-bit 'C' > input for adder). Preliminary testing indicates that it can go above > 360 with light user intervention. One thing I'm cautious about is, the > rest of logic runs much slower, at 90Mhz. Initially was thinking of > using /4 version, but Peter Alfke's post regarding added skews due to > loading differences in DCM outputs is making me think about it > carefully. > > For otuput, I'd be using ODDR to multiplex 360 Mhz logic, to send the > data out at 360Mhz DDR (so the data can look like 360Mhz 'clock'). > Data is LVDS, so is the forwarded LVDS clock pair @ 360Mhz. The > receiving device will use both edges of the forwarded 360 Mhz clock to > sample the data. Clock to output delay is not good, 3+ ns, but since > the clock will be forwarded and will incur effectively the same delay > as data (other than IOB-IOB clk skew), as long as I send out 180 deg > version of internal 360 clock using ODDR, it should be ok. Not sure > what kind of SI issue there will be, however. > > I have an option of running it at 180Mhz if 360 is risky. External > device will be different. Am I playing too safe by going to 180? Will > 360 be a challenge? > > I'd appreciate feedback.Article: 83979
"fastgreen2", your design looks just right for the Virtex-4 capabilities. Keep the pc-board data skew reasonable. You can use a DCM to divide the clock, or you can go with the CE scheme, whatever you prefer. Should work with a reasonable amount of attention to detail. Peter Alfke, Xilinx Applications (I passed this by several experts...)Article: 83980
"The multiply by 4 in the DCM, divide by 10 in the fabric" has the advantage that it is insensitive to the incoming 10 MHz duty cycle. And you can even get a perfect 50% output duty cycle if you do the divide-by-10 the right way around. Peter Alfke, Xilinx ApplicationsArticle: 83981
"John_H" <johnhandwork@mail.com> wrote in message news:fyage.14$p%5.114@news-west.eli.net... > Look at > http://www.xilinx.com/products/virtex4/capabilities/selectio.htm#chipsync > and > > http://www.xilinx.com/products/design_resources/conn_central/resource/ssio_resources.htm > > for discussions on the 1 Gbit/s/pin Virtex-4 differential I/O and you may > get a better feel for the margins you can get in your design. > > If all your LVDS are at the same clock rate, the DCM skews shouldn't be a > problem and could easily be registered back to the slower domain if the > skews were an issue. > > Xilinx went to great lengths to make the Virtex-4 I/O capable of some pretty > high speeds without taxing the designer. > > You might also like to look at this link. http://www.altera.com/products/devices/stratix2/utilities/st2-signal_integrity.html?f=tchio&k=g3 Altera claims their parts have a better LVDS 'eye' because they have superior (i.e. less) pin capacitance. The capacitance gives a lot of ISI. I've been bitten by Xilinx FPGA pin capacitance before, albeit in a slightly different situation. I guess it's the inevitable consequence of trying to fit every possible I/O standard onto every pin. If I'm reading the page properly, Altera mitigate this by having different sets of pins which are capable of different I/O standards. Separate 'Rocket I/Os' also solve this problem. Of course, the OP's data rate is significantly lower than the rate shown in the link, so should be no problem! ;-) Cheers, Syms.Article: 83982
"Symon" <symon_brewer@hotmail.com> wrote in message news:42813fd3_2@x-privat.org... <snip> > You might also like to look at this link. > http://www.altera.com/products/devices/stratix2/utilities/st2-signal_integrity.html?f=tchio&k=g3 > > Altera claims their parts have a better LVDS 'eye' because they have > superior (i.e. less) pin capacitance. The capacitance gives a lot of ISI. <snip> But doesn't the Altera information use external LVDS terminations and monitor external to the part rather than internal terminations and the eye seen by the receiver? By looking outside the package that has an embedded differential termination, isn't the data skewed?Article: 83983
"Symon" <symon_brewer@hotmail.com> wrote in message news:4281198e$1_2@x-privat.org... > > > > - And how do you make the enable signal go on the global clock net? > > > You ask someone from Xilinx! I've not yet started my V4 design. I just > remembered that from the marketing spiel we had. > Cheers, Syms. > Hmmm, I might have given you a bum steer there. I just looked at the FPGA editor view of V4 and it seems there's NOT a path from the GBUFs to the CLB CE. You can control a CE pin on the GBUF, but that's about as useful as a chocolate teapot in this case. Sorry about that, Syms.Article: 83984
"John_H" <johnhandwork@mail.com> wrote in message news:OZbge.15$p%5.117@news-west.eli.net... > "Symon" <symon_brewer@hotmail.com> wrote in message > news:42813fd3_2@x-privat.org... > > <snip> > > > You might also like to look at this link. > > > http://www.altera.com/products/devices/stratix2/utilities/st2-signal_integrity.html?f=tchio&k=g3 > > > > Altera claims their parts have a better LVDS 'eye' because they have > > superior (i.e. less) pin capacitance. The capacitance gives a lot of ISI. > > <snip> > > But doesn't the Altera information use external LVDS terminations and > monitor external to the part rather than internal terminations and the eye > seen by the receiver? By looking outside the package that has an embedded > differential termination, isn't the data skewed? > > I don't think so John. I think the whole white paper is based on a simulation using the published Xilinx IBIS files. The terminations are simulated as being on-chip. The Figure 1. in this document:- http://www.altera.com/literature/wp/signal-integrity_s2-v4.pdf is in the mind of an IBIS simulator, I guess. So, there are no physical measurements. Their data doesn't surprise me; 12.5pF of pin capacitance will really screw with inter-symbol interference at Gbit rates. Best, Syms.Article: 83985
Not another how-to question. I got app notes and opinions coming out my ears already. I was just wondering if it was impossible to have maintained the 3.3V LVDS and LVPECL stuff for another couple of generations. The 3.3V LVPECL is still pretty much widely used. On Semi, for example, is only now getting some of 2.5V stuff out there. Some only say 2.5V online and there's no mention of it in the data sheet when you download it. My problem is trying to design new plug-in cards to existing units with 3.3V LVPECL. I'd like to use Virtex4 chixps because they are far cheaper right now than the Virtex-2 chips. For eample, Avnet quotes $3K on the LX100 and $9K on the 2V8000! I've also got situations where the data rates are such that I'm Real Unhappy putting a resistor network into the path, especially since I have a connector already involved in the impedance discontinuity landscape. So I was just wondering: is my current grief for a greater good? ;-)Article: 83986
In article <geedneaXzs35YOLfRVn_vg@giganews.com>, leonardopsantos <leonardopsantos@gmail-dot-com.no-spam.invalid> wrote: >Hello All: > I have a succes story about ISE 7.1i and Mandrake 10.1, with the >usual hassle of library linking and installing openmotif. Can you give us any hints about what you had to do to get ISE 7.1i running under Mandrake? I can run it but it's very slow - did you have to patch the kernel? PHilArticle: 83987
"Quiet Desperation" <nospam@nospam.com> wrote in message news:100520051719304493%nospam@nospam.com... > Not another how-to question. I got app notes and opinions coming out my > ears already. > > I was just wondering if it was impossible to have maintained the 3.3V > LVDS and LVPECL stuff for another couple of generations. The 3.3V > LVPECL is still pretty much widely used. On Semi, for example, is only > now getting some of 2.5V stuff out there. Some only say 2.5V online and > there's no mention of it in the data sheet when you download it. > > My problem is trying to design new plug-in cards to existing units with > 3.3V LVPECL. I'd like to use Virtex4 chixps because they are far > cheaper right now than the Virtex-2 chips. For eample, Avnet quotes $3K > on the LX100 and $9K on the 2V8000! > > I've also got situations where the data rates are such that I'm Real > Unhappy putting a resistor network into the path, especially since I > have a connector already involved in the impedance discontinuity > landscape. > > So I was just wondering: is my current grief for a greater good? ;-) > PECL is bad because the outputs aren't matched to the line. Check one of your wax smeared app notes and look at the output structure. LVDS and now, (even better), CML outputs fix that and can run much faster with better SI. That's why things are changing, and OnSemi and Micrel are making some great parts. As for no more HowTo, you might wanna stop reading now! The Xilinx differential inputs have enormous common mode range, I'd be surprised if you couldn't make that work somehow. Agreed you might need to AC couple the outputs if you're afraid of resistors. ;-) Check out this (yet another app note) to fix the DC! http://www.sigcon.com/Pubs/news/5_5.htm Remember, if it was easy, anyone could do it, and we'd all be paid peanuts! Cheers, Syms.Article: 83988
Symon, I am suprised at you. Their white paper clearly shows the simualtion is done with the external termination, and not the internal one. Use the internal one, and the capacitance does not matter (do the sim yourself if you do not believe me). Of course, you really should use the LVDS where it is specified. If you want 1.3 Gbs, use our MGTs .... oh, I forgot, then do not have 2-GX parts .... The fact that their LVDS works up to 1.3 Gbs in simulation is nice, but can it be used in a real application on a real board? We have our ML450 Network Board for V4 to demonstrate 1 Gbs DDR interfaces, and it works just fine. Ask your FAE for a demo, or go online and buy the board. Austin Symon wrote: > "John_H" <johnhandwork@mail.com> wrote in message > news:OZbge.15$p%5.117@news-west.eli.net... > >>"Symon" <symon_brewer@hotmail.com> wrote in message >>news:42813fd3_2@x-privat.org... >> >><snip> >> >>>You might also like to look at this link. >>> >> > http://www.altera.com/products/devices/stratix2/utilities/st2-signal_integrity.html?f=tchio&k=g3 > >>>Altera claims their parts have a better LVDS 'eye' because they have >>>superior (i.e. less) pin capacitance. The capacitance gives a lot of > > ISI. > >><snip> >> >>But doesn't the Altera information use external LVDS terminations and >>monitor external to the part rather than internal terminations and the eye >>seen by the receiver? By looking outside the package that has an embedded >>differential termination, isn't the data skewed? >> >> > > I don't think so John. I think the whole white paper is based on a > simulation using the published Xilinx IBIS files. The terminations are > simulated as being on-chip. The Figure 1. in this document:- > http://www.altera.com/literature/wp/signal-integrity_s2-v4.pdf > is in the mind of an IBIS simulator, I guess. So, there are no physical > measurements. > Their data doesn't surprise me; 12.5pF of pin capacitance will really screw > with inter-symbol interference at Gbit rates. > Best, Syms. > >Article: 83989
I was in a similar situation and was able to get a guidance document from Altera that indicated how much performance was lost/gained from processing, voltage and temperature. They won't guarantee the numbers. But be careful since you've got no room for changes that increas the delays. georgeArticle: 83990
johnp wrote: > Peter - > > Thanks for the feedback. As I noted in my original posting, I can > cleanly stop the input clock to the DCM, assert the DCM reset, > then cleanly re-enable the clock. Since I am using the > CLKIN_DIVIDE_BY_2 mode, my question is if that "input" > divider on the DCM gets reset by the DCM RST pin or not. If > it is reset by the RST pin, then all the DCMs in my system should > be able to be "in-sync". Howdy John, Looking back over your posting(s), you don't explictly say that the clock inside of the FPGA has to be phase aligned with the clock outside. If that's the case, you don't need the DCM: You could probably use your reset to control how a logic based FF initializes. The FF and the routing to and from it could be locked down so it doesn't vary between all the FPGA's. If you do need the internal clock to be phase aligned with the external, you could route the output of the FF divider to a DCM which has a phase offset dialed in (that you'll have to come up with manually). Not optimal, but with correct attention to timing constraints, I think it could work. MarcArticle: 83991
Austin, > > Use the internal one, and the capacitance does not matter > (do the sim yourself if you do not believe me). > Quoting Symon's last response [1] to such a misleading, incomplete, and inaccurate claim: >> >>Total bollocks >> And, just recently, some other Austin from Xilinx wrote [2]: >> >>Placing the cap at the receiver is really bad from a signal >>integrity standpoint: it makes for a huge reflection >> Exactly the point I was trying to make a couple years back, with which you disagreed so virulently. Rather than repeat my explanation of why high input C is bad, just re-read [3]. [ I agree that if the cap is right at the receiver in a point-point connection, all it will see is the filtered edge on the initial transition; but ignoring the aftereffects of that massive reflection is foolhardy. ] > > We have our ML450 Network Board for V4 to demonstrate 1 Gbs DDR > interfaces, and it works just fine. > The last time you said that, I asked [4]: >> Where in Xilinx's V4 documentation might one find these pictures >>and eye diagrams, including real world vs. simulated waveforms at >>the driver, receiver, and points in between ? Also from that thread, I suggested some other measurements to make on your "A vs. X" test platform: >> Since you have that spiffy board at hand, I'd love to see >> plots of the following: >> >> A) X vs. A ICCO for the "Hammer Test" at several toggle rates >> >> B1) X vs. A waveforms for a high speed single ended standard (xSTL) >> B2) X vs. A ICCO for a high speed single ended standard (xSTL) >> >> C1) X vs. A waveforms for 1 Gbps differential LVDS >> C2) X vs. A ICCO for 1 Gbps differential LVDS >> >> D) X vs. A differential TDR input waveforms into a DT termination >> at 100, 200, 500 ps input edge rates When might we see some published data on those, particularly items C & D? Brian [1] http://groups-beta.google.com/group/comp.arch.fpga/msg/a6252d7a3566ea3f?hl=en [2] http://groups-beta.google.com/group/comp.arch.fpga/msg/7ef4d001e4d8ff65?hl=en [3] http://groups-beta.google.com/group/comp.arch.fpga/msg/a044806f313848e6?hl=en [4] http://groups-beta.google.com/group/comp.arch.fpga/msg/3619e923a589ef59?hl=enArticle: 83992
In that case use a faster device.. it'll be cheaper in the long run Simon <alanmyler@yahoo.com> wrote in message news:1115716178.386922.146570@o13g2000cwo.googlegroups.com... > The situation is that my design isn't meeting the default worst case > timing. However, the device isn't going to heat up to 85C in operation, > I estimate it'll hit 55C max., so I'm simply looking for some way of > assuring myself that it'll meet the timing constraints under this less > harsh operating environment. > > Alan >Article: 83993
Bob Perlman wrote: > On Sat, 07 May 2005 16:05:13 GMT, Jeff Cunningham <jcc@sover.net> > wrote: > > >>>>>Bob Perlman wrote: >>>>>1) Do you use capacitors on digital lines? >>>>>2) Do you use analog one-shots in your designs? >>>>> >>>>>Ray Andraka wrote: >>>>>3) do you connect logic outputs to clock inputs (or do you use gated >>>>> clocks)? >>>>> >>>>>Symon Brewer wrote: >>>>>4) Have you had any bugs that 'fixed themselves' without you knowing >>>>>why? >>>>> (They always come back!) >>>>>5) Any unterminated digital lines going off board and/or longer than >>>>>c.15cm? >>>>> >>>>>Philip Freidin wrote: >>>>>6) Do you have any pet theories on how to fix metastables? >>>>> >>>>>7) Do you use the async set and reset pins on FFs for other than >>>>> system initialization? >>>>> >> >>Thomas Rudloff wrote: >> >>>8) Do you use pull up resistors on fast CMOS busses that require less >>>than 10ns/V rise / fall time? >> >>9) In what situations might it be acceptable knowingly violate worst >>case timing specs? 10) Do you ever use LUTs as delay elements to change interface timings? JeremyArticle: 83994
For that you need to check the DRAM manufacturer... sometimes its not the clock thats so important.. but the time delays.. so at 200MHz you might find it 5-5-5 but 3-3-3 at 133MHz Simon "Benjamin Menküc" <benjamin@menkuec.de> wrote in message news:d5qrsu$jid$01$1@news.t-online.com... > Hi, > > I talked to Digilent on the phone. They didn't know exactly how fast the > ram can go. > > Here is what I find in the users guide of the board: > > These memory modules are designed for a maximum clock frequency of at > least 133 MHz > and have a CAS latency of 2.5 (18.8 ns). The PLB Double Data Rate > Synchronous DRAM > Controller supports CAS latencies of two or three clock cycles. > If the memory system is to operate at 100 MHz, then set the CAS latency > parameter in the > controller design to 2 (20 ns). If full speed (133MHz) memory operation > is required, then > set the CAS latency parameter in the controller design to 3 (22.6 ns). > > What I don't understand is, whether the 133 MHz is the maximum clock or > not. Can it run 200 MHz as well? > > regards, > BenjaminArticle: 83995
"austin" <austin@xilinx.com> wrote in message news:d5rp06$8034@cliff.xsj.xilinx.com... > Symon, > > I am suprised at you. Their white paper clearly shows the simualtion is > done with the external termination, and not the internal one. > Hmmm, so why do they say in Table 1. "Virtex-4 IBIS Models do Not Have Package Information"? How can they simulate the V4 package parasitics without this? Are you saying they're up to no good? It'd be interesting to see the Xilinx simulation from V4 LVDS output to V4 LVDS input. > > Use the internal one, and the capacitance does not matter (do the sim > yourself if you do not believe me). > I disagree. The Cpin of course limits the rise time at the pin. But also, and maybe worse, the capacitor at the input reflects a whole bunch of energy back down the T-line. The bigger the cap, the more energy is reflected. Some of this energy comes back again to the receiver after hitting the Cpin at the Tx end of the T-line. This causes inter-symbol interference. (Were you running your sim with a perfectly source terminated transmitter?) > > Of course, you really should use the LVDS where it is specified. If you > want 1.3 Gbs, use our MGTs .... oh, I forgot, then do not have 2-GX parts > .... > Stop changing the subject! You should be a politician! ;-) I did say your Rocket I/Os were a solution! And I bet they don't have 12.5pF of capacitance. > > The fact that their LVDS works up to 1.3 Gbs in simulation is nice, but > can it be used in a real application on a real board? > I'm pretty sure you're agreed IBIS simulations are a good idea. Works in simulation, should work in real life, right? > > We have our ML450 Network Board for V4 to demonstrate 1 Gbs DDR > interfaces, and it works just fine. Ask your FAE for a demo, or go online > and buy the board. > > Austin > Yep, Xilinx make great parts. They'd be even better with less Cpin though... Bloody customers want it all! ;-) Cheers, Syms.Article: 83996
A while back, searching for technologies more adapted to creating a microprocessor with a customized instruction set, I came across the web site for Elixent. They have a chip which contains a microprocessor, plus a fabric, something like an FPGA, but in which the cells are not simple gates or look-up tables, but instead ALUs. Also, NEC and other companies have 'reconfigurable computing' chips with many small computers of a sort. Are there other kinds of software-customizable chips out there that are very different from an FPGA? John Savard http://www.quadibloc.com/index.html _________________________________________ Usenet Zone Free Binaries Usenet Server More than 120,000 groups Unlimited download http://www.usenetzone.com to open accountArticle: 83997
>Are there other kinds of software-customizable chips out there that are >very different from an FPGA? ROMs? PALs? Old fart time... See if you can find a data sheet for the AMD 2901 or 29116. The 2901 was a 4 bit ALU slice. The 29116 was 4 of them in one package. They were a great breakthrough for building microcoded machines. For those not familiar with that technology, back in the 70s-80s, it was common to build CPUs by building a faster microcoded machine that actually implemented the "real" instructions. The Alto from Xerox PARC is a good example. (pre 2901. It used '181s, I think. Memory might be foggy by now.) The ones I'm familiar with used a wide instruction word to simplify decoding. Each instruction included a next-instruction address. There was no adder on the PC register. Branching was by ORing bits into the bottom of the next-PC, often with a pipeline dalay stage to make life more "interesting" for the microcoder. -- 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: 83998
Benjamin Menküc <benjamin@menkuec.de> writes: > Hi Martin, > > do You store an entire frame in the fpga ram, or just one line and > keep the DVI and Display LVDS synchronized using the variable hsync > period of the LCD? > Whole frames - we do overlay graphics on the image we captured. > Do You do any image processing in the fpga, overshooting or scaling? > Yep, lots of that, although not specifically overshooting (whatever that is) or scaling. And we provide lots of peripherals for the DSP: CAN, LIN, UARTs, I2C, even turning some LEDs on and off :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 83999
Hi, my ACTEL FPGA design shows significant problems. A bit that is feed in a FIFO will set more than one flipflop. The flipflops a feed by the same clock but it seem that there is a setup/hold problem. Some signals shows glitches (even between flipflops of a FIFO) ???? This is synchonous design! Does anybody know how to fix this problems ? rupert
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