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
This is a multi-part message in MIME format. --------------F121DD58A9540E134A83E3F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ray Andraka wrote: > Yep, just about when the full-up foundation hits v3.1. Coincidence? I don't think > so. Actually, Xilinx has to transfer the Student Edition CDROM contents to Prentice Hall months before the books are released so there is time to replicate and package them (remember that these are book publishers who think in timescales of years). Xilinx has to base the Student Edition version on the current production release at the time. I think that's why the release is 2.1 and not 3.1. > > > Anna Acevedo wrote: > > > The 2.1i Xilinx Student Edition will be available for the start of the Fall > > semester > > You should be able to order it from www.amazon.com or www.xess.com by > > mid August. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || --------------F121DD58A9540E134A83E3F5 Content-Type: text/x-vcard; charset=us-ascii; name="devb.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave Vanden Bout Content-Disposition: attachment; filename="devb.vcf" begin:vcard n:Vanden Bout;Dave tel;fax:(919) 387-1302 tel;work:(919) 387-0076 x-mozilla-html:FALSE url:http://www.xess.com org:XESS Corp. adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA version:2.1 email;internet:devb@xess.com title:FPGA Product Manager x-mozilla-cpt:;-16464 fn:Dave Vanden Bout end:vcard --------------F121DD58A9540E134A83E3F5--Article: 24051
In article <397BD337.648F@designtools.co.nz>, jim.granville@designtools.co.nz wrote: > Tom Vrankar wrote: > > > > Does any JEDEC to VHDL converter exist to allow me to quickly migrate old > > circuit card designs based on rafts of 22V10s in DIPs to a single large FPGA? > > Either freeware or from a FPGA vendor? I've researched it enough to know I > > could do it, but figured it was so obvious someone else must've already done > > it, though I don't see it mentioned in any FAQs I've found. > > How many 22V10's ? > > There are two things you'll need : > - The Equations for each 22V10, ideally source, or rev-eng > there are various older pgms that do JED2EQN National Semiconductor's Opal Jr. (discontinued in 1995), which contains the JED2EQN utility, can be found at: ftp://ftp.armory.com/pub/user/rstevew/GAL/opaljr21.zip > - The PCB netlist(s), for interconnect of the 22V10. > > If there are a lot of 22V10's ( dozens ), the PCB netlist may be > more of a problem :-) > > Conversion to Altera AHDL, or ABEL might be easier, as they are closer > to the equation formats that come out of the jed 'dis-assemblers'. Also CUPL > > As a 22V10 is closer to a CPLD block, ( typ 36V16) than a FPGA, you > might also look at CPLD targets - it does depend on total register > count, over 25-50 22V10's and you are more into FPGA territory. > > - jg > I agree. We like the Xilinx XC9500 family. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24052
I doubt that can be the only reason. Why can't they put in a coupon and accept some shipping and handling charge to upgrade the included software to a version which will be available before the book actually gets published? Pratip Mukherjee pratipm@hotmail.com In article <397CBB64.7FA65C2C@xess.com>, Dave Vanden Bout <devb@xess.com> wrote: >This is a multi-part message in MIME format. >--------------F121DD58A9540E134A83E3F5 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Ray Andraka wrote: > >> Yep, just about when the full-up foundation hits v3.1. Coincidence? I don't > think >> so. > >Actually, Xilinx has to transfer the Student Edition CDROM contents to Prentice > Hall months before the books are released so there is time to replicate and > package them (remember that these are book publishers who think in timescales > of years). Xilinx has to base the Student Edition version on the current > production release at the time. I think that's why the release is 2.1 and not > 3.1. > >> >> >> Anna Acevedo wrote: >> >> > The 2.1i Xilinx Student Edition will be available for the start of the Fall >> > semester >> > You should be able to order it from www.amazon.com or www.xess.com by >> > mid August. >Article: 24053
Virtex is quite capable of higher clock rates. Perhaps a faster master clock may make more sense: First you can get pretty close to the individual clocks using a simple DPLL. That alone probably justify a higer rate clock. By running at the higher clock you might also have the opportunity for sharing logic between ports or decreasing the widths of your data paths (actually, I guess they are serial already, aren't they). A high rate clock lets you transfer the data at each port into the FPGA whilst synchronizing it. A simpler implementation, since you are using Virtex would be to take advantage of the dual port block RAMs for the FIFOs. If you use a virtex EM, you got lots of them to work with. Michael Schmid wrote: > Jonas Thor wrote: > ? > ? Hi, > ? > ? Hello! > ? > ? We have an interesting problem, 17 clocks that are not synchronized. > ? We are going to prototype an 8 port Ethernet (10 Mbit) switch in a > ? Virtex 1000. There's one tx-clock and one rx-clock for each interface > ? and there is a global clock which we will set to 10Mhz. The tx are rx > ? clocks are 2.5 MHz. The reason why the global clock will only be at 10 > ? MHz is simply because we want to make the design more challenging, > ? since a low clock rate makes the queing and buffering handling more > ? difficult. I should say that I work at a university, so we are allowed > ? to make things more difficult than they really are ;) > ? > ? Anyway our first problem is to synch the data from the 8 ports to the > ? global clock. Since we have 17 clocks we are out of global clock > ? routing. My first idea would be to have 16 16-bit deep asynch fifos > ? implemented in CLBs. Each port would have one rx fifo and one tx fifo > ? and the fifos should be placed as close to the port as possible. The > ? fifo would be based on Peter Alfkes appnote (XAPP051 I believe). > ? > ? However the problem here, as I see it, is to make sure that the skew > ? between the port data rx and tx clocks are minimal. > ? > ? Any comments about the suggested solution? Some other approach that > ? migth be better? I have never worked with a Virtex device before. > ? Previous work has been with the XC4000 and these have different clock > ? distributing resources compared the Virtex series. > ? > ? Jonas Thor > ? NoSpamthor@sm.luth.seNoSpam - remove the obvious when replying > ? Lulea University of Technology > ? Sweden > > Hi Jonas, > > What about this: > > 2.5MHz is not very fast, so You can use > your 10MHz clock as the one and only > global clock for all the things you do. > I.e. if an input signal is high, you > have 4 cycles to get it. All of your > rx_clock's are 2 cycles long high (they > should be???), this allows you following > code: > > process ... > if(clk'EVENT) and (clk='1') then > if(rx_clk='1') then > reg_input ?= rx_data; > else > reg_input ?= reg_input; > end if; > end if; > ... > > Look in the 10Mbit-PHY Databook. There > You will find exakt specifications about > the timings (i.e. high/low-times of your > rx_clocks). They will help you to find a > suitable global clock. Maybe 20MHz are > better, I don't know. > So You have one global clock clk and a > registered input reg_input. > > Michael > > mlschmid@iis.fhg.de -- -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 or http://www.fpga-guru.comArticle: 24054
Stephen Lohning wrote:
> Yes create your self a small sdf file with the particular instances that are known
> to
> exibit async behaviour and change them to have 0 setup hold.
> Carry this out after your first annatotion has been done. If you have a lot of them
> you can even write a perl program to create the sdf for you.
> If you are really sensible you will append _Meta or something similar so you can
> find
> them all at one. If not it is just an iterative process to find all the async flops.
>
> Then go and give the designer/coders a big kick up the behind because on large
> design it makes verification really difficult.
> Stephen
>
> PS. This process works with NC-verilog
I'm guessing here but I assume that the X's are being triggered in the FF modules whan a
violation causes the notifier output of the timing checks to toggle. This is normally
used by a simulation model to set FF outputs to `X' where they will stay until the next
clock edge. Therefore the crudest trick is to disable the all notifiers. In Verilog-XL
type simulators there's a command line flag something like +no_notifier. The next level
is to turn them off in the FF's concerned by using a ``force'' statement in the top
level testbench:
initial begin
force <hierarch inst name>.notifier = 0;
end
I combine this with modifying the SDF to increase the delays on these FFs. The final
trick is to use a special model for async FFs. Its here that the various FPGA & ASIC
vendors need a kick up the !!! This situation is so common that they should provide such
models as a standard part of their sim libraries. Its a little tricky to do since such
a model has to behave normally until there's a violation. When there is one it should go
to `X' for a while and then randomly settle to 1 or 0. Its awkward since it breaks the
simple-minded SDF backannotation used in most model libs.
Article: 24055Hi, Ray, Thanks for your reply. I was read the Xilinx Virtex databook again, all I can found about the routing for BlockRAM is a simply description "The Virtex Block SelectRAM also includes dedicated routing to provide an efficient interface with both CLBs and other Block SelectRAMs.", and there are not any detail information can be found to these word. I'm really care that if I don't use any BlockRAM, should the "dedicated routing" can be used by others CLBs as a pass routing interconnect. In the other word, are there some GRM around the BlockRAM? If so, does their still enabled while BlockRAM don't used? Regards, Channing In article <397C7F43.D2CED34F@andraka.com>, Ray Andraka <ray@andraka.com> wrote: > The routing is not really shared. You should look carefully at the VIrtex > routing structure to understand it. It can't be adequately described in > the number of words appropriate for a ng post. If you have the xilinx > tools, open up the chip editor for a new design using a virtex 50. From > there you will be able to see how the routing, and in particular the BRAM > routing is done. The BRAMs can be found on the right and left edges of > the die image. > > channing@21cn.com wrote: > > > Hi, all, > > > > Does anyone know if the BlockRAMs in Xilinx Spartan II/Virtex/Virtex-E > > series have their dedicate routing resources, or their share the > > routing resources with other CLBs ? > > > > Any help will be appreciated. > > > > Channing > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > -- > -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 or http://www.fpga-guru.com > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24056
Hi I started with a new project with a Spartan-II from Xilinx. I can't understand the functionality of these two pins: I/O, IRDY I/O, TRDY I didn't find any explanation in the datasheet about this two pins. can anybody help me. thanks Leumann RobertArticle: 24057
Hey. I'm getting the following error using Foundation Express: -- Dpm :Warning: A MUX_OP was not inferred for the case Dpm: in routine LARA line 155 in file "<filename" because it's branching factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383) -- I couldn't find this in the Xilinx Support web page anywhere. Any guesses? Thanks! -Kent ------------ Kent Orthner korthner at hotmal dot comArticle: 24058
I don't understand, why is every newsgroup on the net not completely swamped with everyone on the planet posting, after all were not fools this clearly isn't a scam!. Hang on a minute, why haven't I done it? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24059
Yes, you are right. I don't know what they are for. I assumed that they were a hold over from either the Spartan or the Virtex chips, but they don't appear in the documentation for either. I guess you may need to contact Xilinx about these. Leumann Robert wrote: > > Hi > I started with a new project with a Spartan-II from Xilinx. I can't > understand > the functionality of these two pins: > I/O, IRDY > I/O, TRDY > I didn't find any explanation in the datasheet about this two pins. > can anybody help me. > > thanks > > Leumann Robert -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24060
In a Xilinx FPGA, you have the luxury of internal tristate busses. From this you can buid a delay locked loop. I will e-mail you a block diagram separately. I have never had the chance to implement this, but have been thinking about it for years.Article: 24061
Has anyone had any problems moving from Fndtn 2.1i to Fndtn 3.1i?Article: 24062
IRDY and TRDY happen to also be names for PCI handshake lines. Specifically the lines that typically have trouble with timing. I'd assume that there is some dedicated logic to help implement PCI and the xilinxCore PCI implementation uses them specifically. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:397D9EBE.54B27115@yahoo.com... > Yes, you are right. I don't know what they are for. I assumed that they > were a hold over from either the Spartan or the Virtex chips, but they > don't appear in the documentation for either. I guess you may need to > contact Xilinx about these. > > > Leumann Robert wrote: > > > > Hi > > I started with a new project with a Spartan-II from Xilinx. I can't > > understand > > the functionality of these two pins: > > I/O, IRDY > > I/O, TRDY > > I didn't find any explanation in the datasheet about this two pins. > > can anybody help me. > > > > thanks > > > > Leumann Robert > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 24063
In article <8lhv84$hou$1@noao.edu>,
Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote:
>So, who's gonna work in the Starbucks where you get your $5 latte every
>morning?
Your teenage kids of course.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 24064These pins are general purpose I/O pins, and you can use them like any other I/O pin. They also connect to some dedicated logic that is used to support a PCI interface, if you are using Xilinx's PCI IP core. These PCI signals are very difficult to meet timing, and the dedicated logic (just a few gates worth) helps the IP core over that problem. If you are not using the core, the pins become available as general I/O. You can see the dedicated logic in the Xilinx chip editor, where most architectural mysteries are revealed. Philip Freidin Leumann Robert <robert.leumann@3vision.com> wrote: >I started with a new project with a Spartan-II from Xilinx. I can't >understand >the functionality of these two pins: >I/O, IRDY >I/O, TRDYArticle: 24065
K.Orthner writes: >I'm getting the following error using Foundation Express: > >Dpm :Warning: A MUX_OP was not inferred for the case >Dpm: in routine LARA line 155 in file "<filename" because it's branching >factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383) It is a warning (not an error!) from Synopsys FPGA-Express. It tells you that a certain logic is not implemented as a multiplexer but as 'normal' logic. You can ignore this statement. If you are a 'power-user' you might want to optimize the structure of your VHDL-code. What surprises me is the factor of 1048576. Do you have a _huge_ combinational block there ??? Regards, Marco ----------------------------------------------------------------- Marco Winzker, Liesegang electronics www.liesegang-electronics.com As always speaking only for myselfArticle: 24066
rickman <spamgoeshere4@yahoo.com> writes: (snip about counting CLB in different FPGAs) >Gate counts are the most worthless numbers I know of. It is alot like >the MHz rating of processors. I have *NO* idea of how to compare a >PowerPC processor at 600 MHz to a Pentium at 600 MHz. The one thing I am >sure of is that they are not the same! So I am also sure that a 50 K >gate Xilinx part is nothing like a 50 K gate Lucent part. But if I am >not using block RAM, I do know that I can get the same design to fit in >two parts that have the same number of LUTs (or at least close). But at least gate count have a standard meaning. I don't know the details of Lucent, but I would expect different CLB to fit different problems differently. If someone has an ASIC or other design with a certain number of 'gates' and wants to know which FPGA it might fit in, gates are it. But again, different designs will fit a different number of 'gates' in a given FPGA. The Xilinx carry logic adds to the difficulty, when comparing against FPGA that doesn't have it, for arithmetic based logic. The added complication is marketing departments that want as large a number as they can possibly justify. It is likely that they use a different design than yours when computing the numbers. I don't think CLB count is any better than gate count. -- glenArticle: 24067
Hello All, Does anyone have a strong opinion about the IBM/Xilinx alliance to put Virtex II logic on the same die with an IBM PPC core? Are a lot of you guys putting high performance microcontrollers on the same board as big fpga designs? Just curious. http://www.xilinx.com/prs_rls/ibmpartner.htm -- Pete Dudley Arroyo Grande SystemsArticle: 24068
I stand (sit) corrected. I should have made myself more clear. Yes, it's a warning, not an error. Yes, my design place-and-routes fine, it seems. (Havent tested it yet.) And, no, I don't have a huge combinational block, which is the odd thing. I have about 20 fairly simple states, with about half of them doig nothing but cusking up a clock cycle before going on to the next state. Which makes me wonder what Synopsys *thinks* I have there? -Kent > >Dpm :Warning: A MUX_OP was not inferred for the case > >Dpm: in routine LARA line 155 in file "<filename" because it's branching > >factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383) > > It is a warning (not an error!) from Synopsys FPGA-Express. > It tells you that a certain logic is not implemented as a multiplexer > but as 'normal' logic. You can ignore this statement. > If you are a 'power-user' you might want to optimize the > structure of your VHDL-code. > > What surprises me is the factor of 1048576. Do you have a _huge_ > combinational block there ??? ------------ Kent OrthnerArticle: 24069
No. The block RAMs connect to a set of vertical lines that are separate from the ones used by the adjacent column. Those long lines have pips that allow it to connect to the horizontal single length lines of the adjacent column that would normally connect to the next column, as well as to the horizontal hex and long lines. This should give you plenty of flexibility in routing them, and it doesn't take anything away from the CLBs. channing@my-deja.com wrote: > Hi, Ray, > > Thanks for your reply. > > I was read the Xilinx Virtex databook again, all I can found about the > routing for BlockRAM is a simply description "The Virtex Block > SelectRAM also includes dedicated routing to provide an efficient > interface with both CLBs and other Block SelectRAMs.", and there are > not any detail information can be found to these word. I'm really care > that if I don't use any BlockRAM, should the "dedicated routing" can be > used by others CLBs as a pass routing interconnect. > > In the other word, are there some GRM around the BlockRAM? If so, does > their still enabled while BlockRAM don't used? > > Regards, > > Channing > > In article ?397C7F43.D2CED34F@andraka.com?, > Ray Andraka ?ray@andraka.com? wrote: > ? The routing is not really shared. You should look carefully at the > VIrtex > ? routing structure to understand it. It can't be adequately described > in > ? the number of words appropriate for a ng post. If you have the xilinx > ? tools, open up the chip editor for a new design using a virtex 50. > From > ? there you will be able to see how the routing, and in particular the > BRAM > ? routing is done. The BRAMs can be found on the right and left edges > of > ? the die image. > ? > ? channing@21cn.com wrote: > ? > ? ? Hi, all, > ? ? > ? ? Does anyone know if the BlockRAMs in Xilinx Spartan > II/Virtex/Virtex-E > ? ? series have their dedicate routing resources, or their share the > ? ? routing resources with other CLBs ? > ? ? > ? ? Any help will be appreciated. > ? ? > ? ? Channing > ? ? > ? ? Sent via Deja.com http://www.deja.com/ > ? ? Before you buy. > ? > ? -- > ? -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 or http://www.fpga-guru.com > ? > ? > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -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 or http://www.fpga-guru.comArticle: 24070
For practical purposes these are just regular I/O. They happen to have a few gates of dedicated logic attached to them to support the xilinx PCI core, as the IRDY and TRDY signals have very stringent timing requirements that are difficult to meet with the regular logic. You can see them in the editor. You can't get to them using the regular tool flow; you can only use them by creating an EPIC macro and instantiating it. Unless you are doing a PCI interface, you don't need to concern yourself with the special mode (it is essentially not accessible anyway). Leumann Robert wrote: > Hi > I started with a new project with a Spartan-II from Xilinx. I can't > understand > the functionality of these two pins: > I/O, IRDY > I/O, TRDY > I didn't find any explanation in the datasheet about this two pins. > can anybody help me. > > thanks > > Leumann Robert -- -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 or http://www.fpga-guru.comArticle: 24071
Ex Fry's employees?
Joseph H Allen wrote:
> In article ?8lhv84$hou$1@noao.edu?,
> Andy Peters ?apeters.Nospam@nospam.noao.edu.nospam? wrote:
>
> ?So, who's gonna work in the Starbucks where you get your $5 latte every
> ?morning?
>
> Your teenage kids of course.
>
> --
> /* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3?(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p?1659?79:0:p?158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
--
-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 or http://www.fpga-guru.com
Article: 24072Gates depends on implementation. If your design is an adder implemented entirely of nand gates and implemented that way in the FPGA, it's going to take a bunch more resources than one that uses the dedicated carry chain. ASIC designs generally do not map well into FPGAs without extensive changes. That is part of the reason FPGAs have gotten a rap for being "slow". LUTs is an accurate measure of the raw logic resource, but you need to take into account how the extra features will fit into your design. For DSP designs, the carry chain implementation and the ability to create compact delay queues figures prominently in favor of the Xilinx architectures even though the Altera parts might have a larger number of LUTs. glen herrmannsfeldt wrote: > rickman ?spamgoeshere4@yahoo.com? writes: > > (snip about counting CLB in different FPGAs) > > ?Gate counts are the most worthless numbers I know of. It is alot like > ?the MHz rating of processors. I have *NO* idea of how to compare a > ?PowerPC processor at 600 MHz to a Pentium at 600 MHz. The one thing I am > ?sure of is that they are not the same! So I am also sure that a 50 K > ?gate Xilinx part is nothing like a 50 K gate Lucent part. But if I am > ?not using block RAM, I do know that I can get the same design to fit in > ?two parts that have the same number of LUTs (or at least close). > > But at least gate count have a standard meaning. I don't know the details > of Lucent, but I would expect different CLB to fit different problems > differently. If someone has an ASIC or other design with a certain > number of 'gates' and wants to know which FPGA it might fit in, gates > are it. But again, different designs will fit a different number of > 'gates' in a given FPGA. The Xilinx carry logic adds to the difficulty, > when comparing against FPGA that doesn't have it, for arithmetic based > logic. > > The added complication is marketing departments that want as large a > number as they can possibly justify. It is likely that they use a > different design than yours when computing the numbers. I don't think > CLB count is any better than gate count. > > -- glen -- -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 or http://www.fpga-guru.comArticle: 24073
glen herrmannsfeldt wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > (snip about counting CLB in different FPGAs) > > >Gate counts are the most worthless numbers I know of. It is alot like > >the MHz rating of processors. I have *NO* idea of how to compare a > >PowerPC processor at 600 MHz to a Pentium at 600 MHz. The one thing I am > >sure of is that they are not the same! So I am also sure that a 50 K > >gate Xilinx part is nothing like a 50 K gate Lucent part. But if I am > >not using block RAM, I do know that I can get the same design to fit in > >two parts that have the same number of LUTs (or at least close). > > But at least gate count have a standard meaning. I don't know the details > of Lucent, but I would expect different CLB to fit different problems > differently. If someone has an ASIC or other design with a certain > number of 'gates' and wants to know which FPGA it might fit in, gates > are it. But again, different designs will fit a different number of > 'gates' in a given FPGA. The Xilinx carry logic adds to the difficulty, > when comparing against FPGA that doesn't have it, for arithmetic based > logic. > > The added complication is marketing departments that want as large a > number as they can possibly justify. It is likely that they use a > different design than yours when computing the numbers. I don't think > CLB count is any better than gate count. > > -- glen If I can be somewhat flippant at the risk of being rude... what have you been smoking???? Gate counts have virtually no meaning at all in evaluating the fit of a design into a part. Even within a single vendor's product line the gate count has very little meaning. When a part consists of a single homogenious sea of CLB's or gate or whatever the FPGA is composed of, then you can make at least some guess of how useful the design units translate into gates. But the newer parts contain a multitude of different types of units which may or may not be useful in any given design. Even if you can use all of the different functional blocks, you are not likely to use them in the fixed ratio that you find in a given part. The Xilinx Virtex parts contain CLBs with LUTs and FFs along with block RAM. What are the chances that you will use exactly 1 FF per 4 input LUT? What are the chances that you will use all 4 inputs on every LUT? What are the chances that you will use all of the block RAM as well? The gate count depends on you using all of these diverse entities in the correct ratio. This does not even take into account the inflation figure that is applied to punch up the gate counts for marketing purposes. This is why I want to use something that I understand, the 4 input LUT. This is the basic unit of logic that I have learned to think of when I do my logic design. If they start using a 5 input LUT as the basic logic element I will have to go back to school! -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24074
Any chance that you are using one-hot encoding? I found that Express will use all of your FF outputs to decode each state even when you tell it you are one-hot encoded. I forget how I got around the problem, but it generated a huge amount of logic in my FSM. Pick a simple state, like one of the ones where you are just waiting one clock cycle and moving on. In the EDIF file, analyze the logic feeding this FF. I bet you find an N input AND function being implemented where N is the number of states in your one-hot FSM. In one case I got N-1 FFs as it used the all zeros case as a state!!! If you look at one of your more complex states with multiple transtions into it, that you get such a mess of logic that you have a hard time analyzing it! I seem to remember that I had to separate the FFs generated from the logic by putting them in separate processes. But this was a year ago and I am not sure. "K.Orthner" wrote: > > I stand (sit) corrected. I should have made myself more clear. > > Yes, it's a warning, not an error. Yes, my design place-and-routes fine, it > seems. (Havent tested it yet.) > > And, no, I don't have a huge combinational block, which is the odd thing. I > have about 20 fairly simple states, with about half of them doig nothing but > cusking up a clock cycle before going on to the next state. > > Which makes me wonder what Synopsys *thinks* I have there? > > -Kent > > > >Dpm :Warning: A MUX_OP was not inferred for the case > > >Dpm: in routine LARA line 155 in file "<filename" because it's > branching > > >factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383) > > > > It is a warning (not an error!) from Synopsys FPGA-Express. > > It tells you that a certain logic is not implemented as a multiplexer > > but as 'normal' logic. You can ignore this statement. > > If you are a 'power-user' you might want to optimize the > > structure of your VHDL-code. > > > > What surprises me is the factor of 1048576. Do you have a _huge_ > > combinational block there ??? > > ------------ > Kent Orthner -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.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