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
Bryan, it's been a while since I've done this (about 18 months), but I ended up doing it for pretty much the same reasons you did. I ran out of clock inputs for some logic that had to take clocks from outside and I wanted precisely repeatable timing for a bunch of asynchronous busses that came on to the chip. So I built the clock domain transfer circuitry into a hard macro and placed it near each input bus. Here's some notes: (1) As soon as you say "hard macro", you're going to exceed Xilinx's ability to support you. You're on your own. (2) The tools tend to blow up if you make too large a hard macro, or if you put too much routing on one. I only route the clocks. (3) I don't try to get hard macros to specify clocks to IOBs. Instead, I choose to bring the external clocks into pins that are within about 5 CLBs of the where I bring the data pins in. It just turns out that the router handles that particular clock combination with some grace. (4) The FPGA editor has gotten more and more difficult to use as time has gone on. XACT was far better. And yes, routing in hard macros is a pain in the butt. I'll write some notes as I walk through a hard macro routing problem: (a) From the "File" menu I open the "Main Properties" menu. (b) I turn off "Stub_Trimming", "AutomaticRouting", "EnhancedManual Routing", and "DelayBased Routing", then press "Apply" and "Close". (c) I turn off the "RatsNest" button because all the uncompleted Data paths will drive me nuts. (d) On the "List1" window, I get rid of "All Components" and replace it with "All Nets" (e) I select the clock I want to route and press the "hilite" button. (f) When I want to see where I can route to and that kind of stuff, I turn off the "Routes" button in the tool bar. That makes all the routes invisible (except the stuff I hilited), because the problem with the tool is that you can't select a segment of an even partially routed net without selecting the whole net. (g) When I see the next segment that I want to route the net to, I select that segment and hilite it too. (By the way, you can add buttons that allow you to hilite in different colors. This is very useful, and is found in the Xilinx documentation for FPGA Editor, but I'm assuming you haven't specialized your FPGA Editor to do this stuff.) (h) I can now route a single segment at a time by selecting the "from" segment with the left mouse button, holding down the "shift" key, selecting the "to" segment with the left mouse button, releasing the "shift" key, and then pressing the "route" button on the right hand panel. This actually works, believe it or not. The secret is that in order to properly manipulate routes, you have to turn off the visibility for routed lines. Where this gets stupid is when you try to route a bunch of stuff for something that is critical for route usage. You basically have to turn on visibility of routed stuff, hilite your intended route, then turn off route visiblity in order to make it happen. Enjoy. Carl -- Posted from firewall.terabeam.com [216.137.15.2] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 37751
Hi, > What kind of tricks is Xilinx using in their > LogiCORE PCI other than the special IRDY and > TRDY pin? Does anyone know? No tricks are employed. I would prefer to think we use careful and deliberate logic design. The special logic resource to which you refer is only required for 66 MHz designs in devices pre-dating Virtex-II. There you go, EricArticle: 37752
"Carl Brannen" <carl.brannen@terabeam.com> writes: >No question that messing around with the carries is going to slow >down a barrel shifter. It's been a very long time since I used one > (okay, it was actually a "funnel shifter", but I hate that term, >so I call them all barrel shifters). I just got the one that uses >the carries to effectively fit a 3 to 1 mux into a LUT to place and >route correctly. It uses 38 LUTs to do a two stage >shift of 0 to 8 bits (i.e. a 9-bit barrel shift) on a 16-bit input. >It's very efficient when you need a power of 3 shift size. >You get a 9-bit shift with only 2 stages of logic instead >of the usual 4. I'll post it to the thread in a minute. It would seem that you could use it for an 8 bit shift, as part of a larger binary barrel shifter. Two would do 64, for example. Otherwise, one use for barrel shifters is floating point normalization. IBM used a base 16, instead of base 2, floating point in S/360, S/370, through the beginning of ESA/390. I believe one reason for base 16 floating point is the reduced need for shift logic. I think that for floating point in FPGA's, where barrel shifting is relatively more expensive, base 16 should be considered. -- glenArticle: 37753
Austin Franklin wrote: > > > > ALWAYS > > > > > > > >>want my designs to use IOB flip flops if possible. It seems to me > that > > > > > > > That's what you get for using Design Mangler...er...Manager ;-) > > > > > > heh. I find that make does a fair job of managing builds. But then, I > > > always did find CLIs more user friendly than GUIs. > > > > > > Even if you invoke map from the commandline or means other than through > > > DM, packing flops into I/Os is not done unless the -pr flag is supplied. > > > So I suppose DM is following the defaults of map. > > > > > > M. Ramirez's question still holds good -- is there ever a reason not to > > > pack flops into IOBs? > > > > > > > I think that packing registers is not the default map option because the > > expectation is that registers will have IOB=TRUE|FALSE attributes applied > to > > them by the front end tool. This attribute takes precedence over the -pr > map > > switch and allows for individual control of registers. > > > > Regards, > > Bret Wade > > Xilinx Product Applications > > Bret, > > I don't know that that is true. Even if Synplicity has that checked, the > Xilinx tools STILL need the "-pr b" to be added to the mapper from what I > remember. > > Regards, > > Austin Austin, Using the IOB=TRUE attribute does take precedence and there is no need to also use the "-pr b" switch. Likewise, using "-pr b" will not override an IOB=FALSE attribute. Regards, BretArticle: 37754
"S. Ramirez" wrote: > "Bret Wade" <bret.wade@xilinx.com> wrote in message > news:3C20D7F1.4AB91218@xilinx.com... > > I think that packing registers is not the default map option because the > > expectation is that registers will have IOB=TRUE|FALSE attributes applied > to > > them by the front end tool. This attribute takes precedence over the -pr > map > > switch and allows for individual control of registers. > > > > Regards, > > Bret Wade > > Xilinx Product Applications > > Bret, > Every company where I have worked, we've never used the above mentioned > attribute. > Simon Ramirez Simon, Okay, but you could use the IOB attribute and then there would be no worries about whether you've set the Map options correctly. Regards, BretArticle: 37755
This is a multi-part message in MIME format. --------------53BA433C8C085CCD7947E925 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Miller wrote: > > I apply a set of multi-cycle constraints to a module and it works > > fine, both timing analyzer and timing simulation. Then I incorporate > > this module and a larger design and apply the the same constraints > > again. This time timing analyzer reports is OK but the timing sim is > > wrong. Any idea to solve the problem? > > How is the timing simulation wrong? Since you don't say, I will make a > guess: is your timed simulation model is being generated without the > "-xon false" flag to ngd2vhdl? > > Without that flag, ngd2vhdl propagates X's through flops whose inputs > don't meet timing requirements. ngd2vhdl doesn't know that that path > has a multicycle constraint on it, and may be flagging problems that > aren't real. I would not suggest using the -xon false switch or disabling X-propgagtion in this case. If the said datapath is truely multi-cycle and the output does have no effect on the circuit, then a timing violation and 'X' output on the register should also have no effect on the simulation. Disabling X-propagation is generally only useful when you know you have asynchronous data clocked by a synchronous element. To answer the original question, if an input changes in the setup/hold window of an enabled register, then a timing violation will fire. This is a physical property of the register whether you care about that data or not and the simultor is alerting you to that. If you are running the simulation and a timing violation occurs (without disabling X-propagation) and the simulation output still looks fine, then you can most likely ignore the warning messages. If you are starting to see X's pop up everywhere in your simulation and the simulation output is failing, then I would question whether or not that truely is a multi-cycle path. -- Brian > > > -- > David Miller, BCMS (Hons) | When something disturbs you, it isn't the > Endace Measurement Systems | thing that disturbs you; rather, it is > Mobile: +64-21-704-djm | your judgement of it, and you have the > Fax: +64-21-304-djm | power to change that. -- Marcus Aurelius --------------53BA433C8C085CCD7947E925 Content-Type: text/x-vcard; charset=us-ascii; name="brian.philofsky.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Philofsky Content-Disposition: attachment; filename="brian.philofsky.vcf" begin:vcard n:Philofsky;Brian x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:brian.philofsky@xilinx.com fn:Brian Philofsky end:vcard --------------53BA433C8C085CCD7947E925--Article: 37756
We are running into a bizarre problem with Virtex configuration. We're using an XCV300-BG352, Xilinx IMPACT software, version 4.1, SelectMAP configuration mode, MultiLINX cable. Our design has several control lines to set the direction of a bunch of *external* buffers (i.e. chips outside the Virtex itself). If I try to run a configuration with our design, the configuration fails with a "DONE pin did not go high" message. However, if I go into FPGA Editor and explicitly tristate the output buffers in the IOB's for the control lines (the internal buffers, not the external ones), by setting TRIMUX to a hard-wired 1, the configuration succeeds. Of course this does no good for our design because then the control lines are always tristated, but it does indicate the nature of the problem. From this behavior, it would seem that the most likely possibility is that in spite of the Xilinx documentation, GTS is being deasserted before DONE is asserted, because in theory, with GTS asserted, *all* IOB's are tristated. I've played around with different settings for DONE_cycle and GTS_cycle in bitgen, none of which has had any effect. Is the Xilinx software in fact in error, and GTS is deasserted before done? Any workarounds for this problem if this is the case? The other possibility is that to either the Virtex chip or the Impact software, the DONE pin is not the indicator that the configuration has completed successfully, and some other step is required which itself requires that Virtex I/O lines remain quiescent. Is this the actual truth, and in so what sort of fixes could apply? Am I missing any other possibilities? This is a frustrating issue that is blocking our development. Has anyone else run into this? Many thanks for your help. Alex Rast arast@qwest.net arast@inficom.comArticle: 37757
--------------ACDD2FC2ABB263783632B461 Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 8bit Peter Alfke wrote: > What if you have to drive 5-V that has a CMOS input threshold of up to 3.5 V. > Then you need a pull-up resistor to the 5 V, and you should configure the > XC4005 output as "open collector" ( really: open drian ). That costs you speed, > since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which creates a > 100 ns delay time constant. > There is a simple and clever way around that, and I can send you the circuit > description on Monday when I am back at work. Here is the "simple and clever circuit" description and the whole, somewhat long-winded explanation, first published 3 years ago. Today the 3 ns rise-time is more like 1 ns... XC4000XL Driving 5-V CMOS Inputs The XC4000XL devices use 3.3 V supply, but tolerate 5 V on their I/O pins. They can drive 5-V TTL-level inputs directly. For driving 5-V CMOS-level inputs, a pull-up resistor to 5 V is required, and the XC4000XL output must be 3-stated when High. (If the output were to remain active High, the pull-up resistor would fight the <50 Ohm output transistor, and the output voltage would be only 100 mV above the Vcc of 3.3 V.) The required output structure is commonly called ěopen collectorî or, more correctly, ěopen drain,î and this function is easily generated inside the chip by driving the Data and the active-Low Output Enable signal of the output block together. The external Low-to-High transition is then driven only by the pull-up resistor. A 470 Ohm pull-up resistor to 5 V and a 50 pF load capacitance create a 0.4-to-4.5 V rise time of >40 ns. For a faster rise time, drive the internal active-Low Output Enable signal not directly from the internal data signal, but from a 2-input AND gate driven by the internal data signal AND the input signal that comes back from the same device output pin. On the rising edge, this assures that the output pull-up transistor is active for most of the rise time, resulting in a shorter output delay. The important part of the rise time, from 0.4 to 3.0V, is reduced dramatically, from 20 ns to 3 ns. Watch out for ringing, it might pull the signal down again. In most cases, the fast active edge gets you through the CMOS threshold and the propagation delay is then <3 ns. At worst, the additional pull-up from the resistor is still needed to reach the threshold voltage reliably, but you still saved at least 15 ns. This idea originated with our European FAEs (Ken Chapman and Nick Sawyer). We recently performed experiments to verify the claim. It works splendidly. Peter Alfke, Xilinx Applications --------------ACDD2FC2ABB263783632B461 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <br>Peter Alfke wrote: <blockquote TYPE=CITE>What if you have to drive 5-V that has a CMOS input threshold of up to 3.5 V. <br>Then you need a pull-up resistor to the 5 V, and you should configure the <br>XC4005 output as "open collector" ( really: open drian ). That costs you speed, <br>since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which creates a <br>100 ns delay time constant. <br>There is a simple and clever way around that, and I can send you the circuit <br>description on Monday when I am back at work.</blockquote> Here is the "simple and clever circuit" description and the whole, somewhat long-winded explanation, first published 3 years ago. <br>Today the 3 ns rise-time is more like 1 ns... <br> <h2> XC4000XL Driving 5-V CMOS Inputs</h2> The XC4000XL devices use 3.3 V supply, but tolerate 5 V on their I/O <br> pins. They can drive 5-V TTL-level inputs directly. For driving 5-V <br> CMOS-level inputs, a pull-up resistor to 5 V is required, and the <br> XC4000XL output must be 3-stated when High. <br> <br> (If the output were to remain active High, the pull-up resistor would <br> fight the <50 Ohm output transistor, and the output voltage would be <br> only 100 mV above the Vcc of 3.3 V.) <p> The required output structure is commonly called “open collector” or, <br> more correctly, “open drain,” and this function is easily generated <br> inside the chip by driving the Data and the active-Low Output Enable <br> signal of the output block together. The external Low-to-High <br> transition is then driven only by the pull-up resistor. A 470 Ohm pull-up <br> resistor to 5 V and a 50 pF load capacitance create a 0.4-to-4.5 V rise <br> time of >40 ns. <p> For a faster rise time, drive the internal active-Low Output Enable <br> signal not directly from the internal data signal, but from a 2-input <br> AND gate driven by the internal data signal AND the input signal that <br> comes back from the same device output pin. On the rising edge, this <br> assures that the output pull-up transistor is active for most of the rise <br> time, resulting in a shorter output delay. The important part of the rise <br> time, from 0.4 to 3.0V, is reduced dramatically, from 20 ns to 3 ns. <br> Watch out for ringing, it might pull the signal down again. <p> In most cases, the fast active edge gets you through the CMOS <br> threshold and the propagation delay is then <3 ns. At worst, the <br> additional pull-up from the resistor is still needed to reach the <br> threshold voltage reliably, but you still saved at least 15 ns. <br> <br> This idea originated with our European FAEs (Ken Chapman and Nick <br> Sawyer). We recently performed experiments to verify the claim. It <br> works splendidly. <br>Peter Alfke, Xilinx Applications <p> <br> </html> --------------ACDD2FC2ABB263783632B461--Article: 37758
Download http://members.spinn.net/~padudle/vl_symgen.exe and execute it in a dos command window. If you run it with no parameters it will return with instructions or use this example. vl_symgen compiled_design.pad sym/compiled_design.1 -- Pete Dudley Arroyo Grande Systems "Peter Fenn" <Peter.Fenn@avnet.com> wrote in message news:ee73c6a.-1@WebX.sUN8CHnE... > Spartan-IIE: I am urgently looking for a (board-level) schematic symbol (preferably ORCAD or VIEWLOGIC) for an XC2S100E-6FT256C Xilinx FPGA. Is anyone in a position to help on this? > -Thanks in advance :-)Article: 37759
On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters <andy@exponentmedia.nospam.com> wrote: >Stephen Byrne wrote: > >> I originally posted this yesterday on google groups, but I'm not seeing it >> on my home news server. In case it is not visible to all, I'm reposting. >> >> Hello All, >> >> My company is currently comparing 66MHz PCI core solutions from Xilinx >> and Altera, as well as debating using a home-spun core. One issue >> I've come upon is the PCI requirement for a MAX clock-to-out time of 6 >> ns and MIN clock-to-out time of 2 ns. Both the Xilinx ISE and Altera >> Quartus II tools seem very helpful in supplying MAX (worst-case) Tco >> times, but I don't see any info on best-case times. Apparently the >> SDF files for back-annotated timing sim have the same worst-case >> numbers repeated 3 times, resulting in the same simulation regardless >> of case selection. My question is: how is anyone (FPGA vendors >> included) guaranteeing a MIN Tco of 2 ns across all conditions and >> parts if the design tools don't even yield that information? > > >You like to live dangerously if you depend on best-case timing information. What's the alternative? Bob Perlman Cambrian Design WorksArticle: 37760
shawn chen wrote: > > Hi, > > I am debugging an Altera FPGA board with old "byteblaster" > interface on board ( Just a 74HC244 ). Now I have only > Maxplus II baseLine software which support only "byteblasterMV". > The circuit of "byteblasterMV" added some pull up resistors, > and also other slight difference. > > Problem : When program with JTAG chain through "byteblasterMV" mode, > MaxplusII can't detect the device on board (An EPC2L20 ). > > Question: > 1. Should I change the circuit on board to "byteblasterMV"? > (I mean cut some wire, add some resistors). It wouldn't hurt to try it...Article: 37761
"Bret Wade" <bret.wade@xilinx.com> wrote in message news:3C2128F1.68274384@xilinx.com... > > > Austin Franklin wrote: > > > > > > ALWAYS > > > > > > > > > >>want my designs to use IOB flip flops if possible. It seems to me > > that > > > > > > > > > That's what you get for using Design Mangler...er...Manager ;-) > > > > > > > > heh. I find that make does a fair job of managing builds. But then, I > > > > always did find CLIs more user friendly than GUIs. > > > > > > > > Even if you invoke map from the commandline or means other than through > > > > DM, packing flops into I/Os is not done unless the -pr flag is supplied. > > > > So I suppose DM is following the defaults of map. > > > > > > > > M. Ramirez's question still holds good -- is there ever a reason not to > > > > pack flops into IOBs? > > > > > > > > > > I think that packing registers is not the default map option because the > > > expectation is that registers will have IOB=TRUE|FALSE attributes applied > > to > > > them by the front end tool. This attribute takes precedence over the -pr > > map > > > switch and allows for individual control of registers. > > > > > > Regards, > > > Bret Wade > > > Xilinx Product Applications > > > > Bret, > > > > I don't know that that is true. Even if Synplicity has that checked, the > > Xilinx tools STILL need the "-pr b" to be added to the mapper from what I > > remember. > > > > Regards, > > > > Austin > > Austin, > > Using the IOB=TRUE attribute does take precedence and there is no need to also > use the "-pr b" switch. Likewise, using "-pr b" will not override an IOB=FALSE > attribute. > > Regards, > Bret Bret, Where are you assigning these attributes? You said in the "front end tools", yet Synplcity has an "syn_useioff" that doesn't appear to matter...you still need the "-pr b" in the mapper. According to the Synplicity docs, there is no "iob" attribute... Are you talking about in a constraint file? That's really got nothing to do with the synthesis front end tools... AustinArticle: 37762
> > > I think that packing registers is not the default map option because the > > > expectation is that registers will have IOB=TRUE|FALSE attributes applied > > to > > > them by the front end tool. This attribute takes precedence over the -pr > > map > > > switch and allows for individual control of registers. > > > > > > Regards, > > > Bret Wade > > > Xilinx Product Applications > > > > Bret, > > Every company where I have worked, we've never used the above mentioned > > attribute. > > Simon Ramirez > > Simon, > > Okay, but you could use the IOB attribute and then there would be no worries > about whether you've set the Map options correctly. > > Regards, > Bret Or...you could use the "-pr b" map option, and never worry if you set the IOB attribute correctly! Sorry, I couldn't resist ;-)Article: 37763
Is there a better way than Xilinx's Trace to get an estimate of how fast a design will run, especially when there are multiple clocks? It'd be nice to have a trace program that gives a max speed for all clocks in a design. For example, I tested an 8:64 demux today that uses 1:2 DDRs in it's initial stage. I successfully ran it without errors with 900 Mbps data inputs (450 Mhz clock) which is above the official spec of the chip. The Trace program estimated a top clock of 162 MHz. :-\ Would it help to TIG all the lower clock stuff? Maybe give them all a common prefix or suffix and just have something like "NET *_slowclk TIG;" Nice chip, though, Xilinx. I could actually sneak it up to 1 Gbps (500 MHz clock) before it started to flake out. I hand placed all the high speed FFs with LOC constraints. You can accomplish amazing things if you don't leave too much up to the place and route tools. ;-) -- - Quiet Desperation - "The mass of men lead lives of quiet desperation." -- Henry David ThoreauArticle: 37764
> The most important errata from the errata sheet for the DCM is to reset > it after the part is configured and the clocks are running after a delay. I am waiting for my FAE to get me a copy of this errata sheet. > The recommendation is to wait 500 ms at room temp (longer if cold), to > assert RST for a short period (say 100 us or less -- as it stops all of You are bang on the money. I wrote code to strobe the DCMs reset for 1us after about 600ms after config, and it worked first time, every time. Thank you very much! Now that I understand the problem, I can write a DCM monitor that checks the status bits and applies reset in the appropriate way. I'd like to ask one more thing: when I am doing clock mirroring/board level deskewing, should the feedback path from the IOB to the FB input on the DCM go through a BUFG or not? My original design lacked such a BUFG, but the reference code from XAPP262 does have one. With that BUFG present, a warning is issued concerning an "unknown feedback loop". -- David Miller, BCMS (Hons) | When something disturbs you, it isn't the Endace Measurement Systems | thing that disturbs you; rather, it is Mobile: +64-21-704-djm | your judgement of it, and you have the Fax: +64-21-304-djm | power to change that. -- Marcus AureliusArticle: 37765
Yup, and those glue on pentium heatsinks with the fans on them come in handy
for some of those high clock high density designs.
Quiet Desperation wrote:
> Is there a better way than Xilinx's Trace to get an estimate of how
> fast a design will run, especially when there are multiple clocks? It'd
> be nice to have a trace program that gives a max speed for all clocks
> in a design.
>
> For example, I tested an 8:64 demux today that uses 1:2 DDRs in it's
> initial stage. I successfully ran it without errors with 900 Mbps data
> inputs (450 Mhz clock) which is above the official spec of the chip.
> The Trace program estimated a top clock of 162 MHz. :-\
>
> Would it help to TIG all the lower clock stuff? Maybe give them all a
> common prefix or suffix and just have something like "NET *_slowclk
> TIG;"
>
> Nice chip, though, Xilinx. I could actually sneak it up to 1 Gbps (500
> MHz clock) before it started to flake out. I hand placed all the high
> speed FFs with LOC constraints. You can accomplish amazing things if
> you don't leave too much up to the place and route tools. ;-)
>
> --
> - Quiet Desperation -
> "The mass of men lead lives of quiet desperation." -- Henry David Thoreau
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 37766
Those suffixes are the speed grade. The parts are graded as they come
through test and "binned" according to their performance scores and the
relative demand for the various speed grades. This way the vendor can
sell the faster parts at a higher premium. For the virtex families, the
higher the number, the higher the performance. In the 4K families, it
went the other way with the smaller numbers indicating faster parts.
Better is a relative term. If you need the speed, then the faster parts
are 'better'. If you need to keep your costs down, then the slower parts
are 'better' because they are significantly cheaper.
Antonio wrote:
> Some hardware question on FPGA :
>
> 1) What's the difference between a part with speed -3 and another with
> speed -4 , the number is the number of metal layers ??
>
> 2) I read data sheet of Virtex and Virtex E, I didn't found really
> much difference, can you explain me which is better and why ??
>
> Thanks
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 37767The Virtex-E just has more BlockRAM available, IIRC... JoshP "Ray Andraka" <ray@andraka.com> wrote in message news:3C216F7E.76102A77@andraka.com... > Those suffixes are the speed grade. The parts are graded as they come > through test and "binned" according to their performance scores and the > relative demand for the various speed grades. This way the vendor can > sell the faster parts at a higher premium. For the virtex families, the > higher the number, the higher the performance. In the 4K families, it > went the other way with the smaller numbers indicating faster parts. > > Better is a relative term. If you need the speed, then the faster parts > are 'better'. If you need to keep your costs down, then the slower parts > are 'better' because they are significantly cheaper. > > Antonio wrote: > > > Some hardware question on FPGA : > > > > 1) What's the difference between a part with speed -3 and another with > > speed -4 , the number is the number of metal layers ?? > > > > 2) I read data sheet of Virtex and Virtex E, I didn't found really > > much difference, can you explain me which is better and why ?? > > > > Thanks > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 37768
Peter Alfke wrote: > > Peter Alfke wrote: > >> What if you have to drive 5-V that has a CMOS input threshold of up >> to 3.5 V. >> Then you need a pull-up resistor to the 5 V, and you should >> configure the >> XC4005 output as "open collector" ( really: open drian ). That costs >> you speed, >> since you now have a 1 kilohm pull-up and a, say, 100 pF lad, which >> creates a >> 100 ns delay time constant. >> There is a simple and clever way around that, and I can send you the >> circuit >> description on Monday when I am back at work. > > Here is the "simple and clever circuit" description and the whole, > somewhat long-winded explanation, first published 3 years ago. > Today the 3 ns rise-time is more like 1 ns... I've used this trick several times over the years and can confirm that it works a treat. In fact its so nice that I've often wondered why no one has defined it as a standard output structure we might call FO/D = Fast-OpenDrain.Article: 37769
Steve Underwood wrote: > I think that depends on the type of degree. Wouldn't finding a way to > get someone else to do the hard work for you be considered reasonable > grounds for being awarded an MBA? > Only if you made sure you got paid & they didn't.Article: 37770
Andy Peters wrote: > S. Ramirez wrote: > > > I don't know about you guys and gals and pals, but everytime I do a > > design, without exception, I ALWAYS go into the Xilinx Design Manager > > Design --> Optiions --> Implementation Edit Options and select and select > > "Inputs and Outputs" for Pack I/O Registers/Latches into IOBs for. I ALWAYS > > want my designs to use IOB flip flops if possible. It seems to me that the > > default "Off" is a waste of these flip flops. Does anyone here every turn > > this off? > > Simon, > > Amen. > > ---a I think I've figured out how these things happen & how the obvious default of ``-pr b'' deosn't happen. It goes like this 1. New feature (pack IOB FFs) gets designed into prototype s/w. 2. s/w engineer, not confident that its not going to crash something in some obscure & difficult to find way, defaults it to off. 3. Fully intending. once testing is complete, to change the default to the sensible one. 4. Manger comes along & asks ``Is new feature complete and working''. 5. Engineer, naively, says ``yes''. 6. Manager releases new s/w + associated docs. ... Some time later ... 7. User complains of stupid default value. 8. engineer agrees, changes it, and then gets told ``You can't do that, its now in the manual''. Swap h/w for s/w and all the above is based on personal experience.Article: 37771
This is a multi-part message in MIME format. --------------2C82A415C276A9315F20A65E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim, 4.1i and above. Dave Tim wrote: > "David Hawke" <dhawke@...inx.com> wrote > > > Also for everyone here, you might also want to try the Directed Routing > > constraint (which appends it to the ucf or ncf file) Tools > Directed Routing > > cst.... > > I guess "Tools > Directed Routing cst" is not to be > confused with "Tools > DRC" :) > > Which revision of FPGA Editor for DirectedRoutingCst ? --------------2C82A415C276A9315F20A65E Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:;David Hawke tel;cell:(44) 778 875 5002 tel;fax:(44) 1291 621 541 tel;home:(44) 1291 621 655 tel;work:(44) 870 7350 517 x-mozilla-html:FALSE org:Xilinx UK;Northern European Sales version:2.1 email;internet:dhawke@xilinx.com title:Xilinx Field Applications Engineer adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom fn:David Hawke end:vcard --------------2C82A415C276A9315F20A65E--Article: 37772
In article <3C21AE6D.97C9691C@algor.co.uk>, Rick Filipkiewicz
<rick@algor.co.uk> writes
>> Here is the "simple and clever circuit" description
[snip]
>
>I've used this trick several times over the years and can confirm that
>it works a treat.
>
>In fact its so nice that I've often wondered why no one has defined it
>as a standard output structure we might call FO/D = Fast-OpenDrain.
Traditional 8051 microcontrollers have a related trick, with the
active pull-up enabled for just one clock cycle when the output
transitions from low to high. Not as nice as the Xilinx idea,
but it works on unidirectional outputs too.
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 37773pete dudley wrote: > Download http://members.spinn.net/~padudle/vl_symgen.exe and execute it in a > dos command window. If you run it with no parameters it will return with > instructions or use this example. > > vl_symgen compiled_design.pad sym/compiled_design.1 > > -- > Pete Dudley > > Arroyo Grande Systems > > "Peter Fenn" <Peter.Fenn@avnet.com> wrote in message > news:ee73c6a.-1@WebX.sUN8CHnE... > > Spartan-IIE: I am urgently looking for a (board-level) schematic symbol > (preferably ORCAD or VIEWLOGIC) for an XC2S100E-6FT256C Xilinx FPGA. Is > anyone in a position to help on this? > > -Thanks in advance :-) We have a very similar thing for VeriBest (now owned by Mentor) schems. In some form or another we have been auto-generating schems. from pinout files since we moved to CPLDs from PALs. For the original versions we did use a ``canned'' part placed on a primitive schem with wires connected to all the part pins and the wires had temp names related to the parts pin names. Then used a tool that came with the schem editor to rename the wires that were "live" and delete the rest. This auto-schem was hidden in a hierarchy block. We can now contruct the whole thing from the ground up using schem editor's list of symbols which includes, for a ViretxE part, 8 ``bank'' symbols, a power block, and a configuration block.Article: 37774
"Bret Wade" <bret.wade@xilinx.com> wrote in message
news:3C212A10.D5E82114@xilinx.com...
> Simon,
>
> Okay, but you could use the IOB attribute and then there would be no
worries
> about whether you've set the Map options correctly.
>
> Regards,
> Bret
Bret,
This is just a suggestion from a user point of view -- change the
default. Then we wouldn't be having this discussion.
Simon
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