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
eml@riverside-machines.com.NOSPAM wrote in message <38354f68.18149846@news.dial.pipex.com>... >On Thu, 18 Nov 1999 09:23:09 -0700, "Andy Peters" ><apeters.Nospam@nospam.noao.edu.nospam> wrote: > >>No, neither tedious or unnecessary. And it is right. When I write code >>that's supposed to end up as a flipflop, I always include an async reset >>that uses the GSR. That takes care of the power-on reset. If a flip has to >>be (re)set any time other than at power-up, I use a synchronous reset. > >Or power-on preset, of course - try doing that without an explicit GSR >signal. FPGA Express apparently can do that without instantiating a startup block. OK, maybe it doesn't work in Virtex but it works in an XLA part. I just checked an XLA design in FPGA Editor. Active-low write enable output pin. the code is written the usual way; the reset clause sets write_l to '1'. Looking at the IOB in FPGA Editor, GSR goes into a selector that drives the flop's async set. The display for CLBs doesn't explicitly call out the GSR but each flop has a pair of check boxes, one labelled SET, the other RESET. One might assume that the flop is either set or reset upon assertion of GSR, but is that right? In any case, a power-on (GSR) preset seems to check the "SET" box. -- a ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu "Creation Science" is oxymoronic.Article: 18876
Rick Filipkiewicz wrote in message <38354936.AB596951@algor.co.uk>... > > >Andy Peters wrote: > >> You should check out the SDRAM data sheets at Micron's web site. They're >> large (50 pages) but you really need to understand how the parts work before >> attempting a design with them. They're not necessarily difficult, just >> idiosyncratic. > >On the same site Micron also have some nice Verilog & VHDL simulation models of >their SDRAMs that might also help in understanding some of the more obscure >timing parameters. got' em; that's why we bought the Micron parts. -- ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu "Creation Science" is oxymoronic.Article: 18877
In Max+Plus II, with the Compiler Window active, I believe you can go into the Processing menu and enable "Optimize Timing in SNF". This should reduce the file sizes. If you migrate to APEX and use the new Quartus SW, the .vo and .sdo should also be much smaller due to new netlist structure. Ying In article <8146re$nl7@netline.jpl.nasa.gov>, Edwin Grigorian <edwin.grigorian@jpl.nasa.gov> wrote: >I have had similar sized '.vo' (verilog) and '.sdo' files with a 93% full >10K200E (low IO count) and was able to successfully do post Place & Route >simulations with Modelsim. Simulations do take quite some time to complete >if your testbench uses up many cycles. > >Edwin Grigorian >JPL > >Rick Filipkiewicz <rick@algor.co.uk> wrote in message >news:382AA865.C202FD66@algor.co.uk... >> >> >> giuseppe giachella wrote: >> >> > After placing and routing my design on an Altera Flex 10KA250, Maxplus2 >> > created two output files .vho and .sdo in order to start >> > a postlayout simulation. These two files have a dimension of 16 MB >> > each. It is almost impossible for me to compile such a vhdl and load >> > an sdf file so big (I have tried using Modelsim and VSS). >> > >> > Is there anyone who succeeded in simulating files so big ? >> > >> > What should I expect if I migrate my design an a APEX or VIRTEX >> > (they contain much more gates than a Flex 10KA250) ? >> > >> >> One approach would be to use a perl script to split the postroute netlist >> into separate pieces and compile them seprately into a library. >> Alternatively if VHDL makes that difficult and you have the co-simulation >> version of ModelSim you could output the netlist in the more compact & >easy >> to split Verilog form. >> >> For my postlayout Virtex XCV300 simulation I get an 8MB Verilog >netlist+8MB >> SDF and ModelSim [5.3aPE] handles this with no problems, takes just under >2 >> minutes to compile - 450MHz P-II + 512MBytes. >> >> > >Article: 18878
An anonymous poster (via Rickman) wrote: > I have picked the Lucent ORCA FPGAs for the board I am currently > building due to IO count, part cost and support. I have noticed that > there are not many people discussing these devices in this newsgroup, > which I assume is because there are not a lot of people using them. Can > I ask why Xilinx parts are preferred over the Lucent devices? Other than > inertia, why did you pick the Xilinx devices? I started using the Orca parts many years ago after buying Neocad which, at the time, supported both Xilinx and Orca parts. I found that the Orca parts had better performance, more pins, and were cheaper. I think that is still true today for Orca 2x series parts vs. Xilinx 4x. The two big architectural advantages that Orca 2x has are: FE-Mux into each flip flop can be used in many cases as an extra logic input. Large numbers of tristate lines running vertically and horizontally. (There are 2 Tbufs per LUT in the orca part). However, the OR2x lacks I/O flip flops and also doesn't have a carry structure as flexible as the X4K chips. The Orca 3T series has made some improvements over the OR2x. It now has I/O Flip-Flops. It's carry structure appears to be more flexible, but the software doesn't suport it. (Xilinx has gone the other way, and made theirs less flexible). Lucent also added a flip-flop to the carry chain, making it more efficient for pipelined arithmetic, and for implementing the 5-bit counters needed to address their 32-word RAMS. The OR3T has only 1 Tbuf per LUT, but still has horizontal and vertical tristate lines as well as horizontal and vertical carry chains. (Virtex has only vertical carry chains and horizontal tristate lines. It has 0.5 Tbuf per LUT.) Lucent has also improved its memory architecture. It uses 2 LUTS to implement a 32x1 dual-port memory, while Virtex loses a factor of 2 by using 2 Luts to make a 16x1 dual-port RAM. Even with its apparent architectural advantages, the OR3T part doesn't do as well as Virtex parts for the designs that I've tested. It appears that the synthesis software (Leonardo Spectrum) does a much better job for Virtex parts than for OR3T parts. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 18879
husby@fnal.gov (Don Husby) wrote: > An anonymous poster (via Rickman) wrote: oops. I misread the Rickman's message. He was the original poster, and not posting for someone else. Sorry. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 18880
Greetings; I'm getting my feet wet with Virtex, after having used the 4000 series for a few years. In the past, I've always stayed away from manually instantiating components, mostly because the code is less readable and portable. This has worked well with the 4000 parts when it comes to automatic inference of the startup block and usage of flip-flops in the I/O blocks. Now that I've started working with Virtex, neither of these works as it once did. I've read the application notes on the Xilinx site concerning the startup block and Synplify (the synthesis tool I'm using). Answer #4034 makes it clear that the startup block won't be instantiated automatically by this tool under any circumstances (even when force GSR is turned on???). http://www.xilinx.com/techdocs/4034.htm Moving on to the bigger problem... Top-level signals which are registered (either inputs or outputs) aren't being clocked in the pad. I've checked this using the FPGA editor. The pads are only being used as IBUF or OBUF. The registering of the signal occurs inside a CLB. What I want, and what used to happen automatically, is for the register to reside in the pad. Fast clock to output delays depend on this. Any helpful suggestions on how to get the registers moved into the pads would be greatly appreciated. I prefer not to resort to manual instantiation of any components. Best regards, Jamie SandersonArticle: 18881
use map -pr b Josh Jamie Sanderson wrote: > > Greetings; > > I'm getting my feet wet with Virtex, after having used the 4000 series for a > few years. > > In the past, I've always stayed away from manually instantiating components, > mostly because the code is less readable and portable. This has worked well > with the 4000 parts when it comes to automatic inference of the startup > block and usage of flip-flops in the I/O blocks. Now that I've started > working with Virtex, neither of these works as it once did. > > I've read the application notes on the Xilinx site concerning the startup > block and Synplify (the synthesis tool I'm using). Answer #4034 makes it > clear that the startup block won't be instantiated automatically by this > tool under any circumstances (even when force GSR is turned on???). > > http://www.xilinx.com/techdocs/4034.htm > > Moving on to the bigger problem... Top-level signals which are registered > (either inputs or outputs) aren't being clocked in the pad. I've checked > this using the FPGA editor. The pads are only being used as IBUF or OBUF. > The registering of the signal occurs inside a CLB. What I want, and what > used to happen automatically, is for the register to reside in the pad. Fast > clock to output delays depend on this. > > Any helpful suggestions on how to get the registers moved into the pads > would be greatly appreciated. I prefer not to resort to manual instantiation > of any components. > > Best regards, > Jamie SandersonArticle: 18882
Hi - On Fri, 19 Nov 1999 17:31:19 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >Greetings; > >I'm getting my feet wet with Virtex, after having used the 4000 series for a >few years. > >In the past, I've always stayed away from manually instantiating components, >mostly because the code is less readable and portable. This has worked well >with the 4000 parts when it comes to automatic inference of the startup >block and usage of flip-flops in the I/O blocks. Now that I've started >working with Virtex, neither of these works as it once did. > >I've read the application notes on the Xilinx site concerning the startup >block and Synplify (the synthesis tool I'm using). Answer #4034 makes it >clear that the startup block won't be instantiated automatically by this >tool under any circumstances (even when force GSR is turned on???). > >http://www.xilinx.com/techdocs/4034.htm > >Moving on to the bigger problem... Top-level signals which are registered >(either inputs or outputs) aren't being clocked in the pad. I've checked >this using the FPGA editor. The pads are only being used as IBUF or OBUF. >The registering of the signal occurs inside a CLB. What I want, and what >used to happen automatically, is for the register to reside in the pad. Fast >clock to output delays depend on this. I encountered the same problem when synthesizing Verilog-based Virtex designs with Synplicity. When running map, include the -pr b switch on the command line. (I'm not sure what to do if you run Design Manager, since I never use it.) For more information on this switch, refer to the map section of the Development System Reference Guide. Take care, Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 18883
Hi Jaimie, In the Design Manager look under the <Design><Options:Implementation: Edit Options..> dialog under the <Optimize and Map> tab and set the 'Pack I/O Registers/Latches into IOBs for:' to 'Inputs and Outputs'. Then, if you are using Foundation/Alliance 2.1, download the latest service pack and install it (good thing the weekend is coming-up :-). This last step will, among other things, insure that inverters in the IOBs will remain inverters... grrr! Hope this helps, ++Simon Goble (Remove the '_' in the return address to reply) On Fri, 19 Nov 1999 17:31:19 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >Greetings; > >I'm getting my feet wet with Virtex, after having used the 4000 series for a >few years. > >In the past, I've always stayed away from manually instantiating components, >mostly because the code is less readable and portable. This has worked well >with the 4000 parts when it comes to automatic inference of the startup >block and usage of flip-flops in the I/O blocks. Now that I've started >working with Virtex, neither of these works as it once did. > >I've read the application notes on the Xilinx site concerning the startup >block and Synplify (the synthesis tool I'm using). Answer #4034 makes it >clear that the startup block won't be instantiated automatically by this >tool under any circumstances (even when force GSR is turned on???). > >http://www.xilinx.com/techdocs/4034.htm > >Moving on to the bigger problem... Top-level signals which are registered >(either inputs or outputs) aren't being clocked in the pad. I've checked >this using the FPGA editor. The pads are only being used as IBUF or OBUF. >The registering of the signal occurs inside a CLB. What I want, and what >used to happen automatically, is for the register to reside in the pad. Fast >clock to output delays depend on this. > >Any helpful suggestions on how to get the registers moved into the pads >would be greatly appreciated. I prefer not to resort to manual instantiation >of any components. > >Best regards, >Jamie Sanderson > >Article: 18884
Hi Jaimie, In the Design Manager look under the <Design><Options:Implementation: Edit Options..> dialog under the <Optimize and Map> tab and set the 'Pack I/O Registers/Latches into IOBs for:' to 'Inputs and Outputs'. Then, if you are using Foundation/Alliance 2.1, download the latest service pack and install it (good thing the weekend is coming-up :-). This last step will, among other things, insure that inverters in the IOBs will remain inverters... grrr! Hope this helps, ++Simon Goble (Remove the '_' in the return address to reply) On Fri, 19 Nov 1999 17:31:19 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >Greetings; > >I'm getting my feet wet with Virtex, after having used the 4000 series for a >few years. > >In the past, I've always stayed away from manually instantiating components, >mostly because the code is less readable and portable. This has worked well >with the 4000 parts when it comes to automatic inference of the startup >block and usage of flip-flops in the I/O blocks. Now that I've started >working with Virtex, neither of these works as it once did. > >I've read the application notes on the Xilinx site concerning the startup >block and Synplify (the synthesis tool I'm using). Answer #4034 makes it >clear that the startup block won't be instantiated automatically by this >tool under any circumstances (even when force GSR is turned on???). > >http://www.xilinx.com/techdocs/4034.htm > >Moving on to the bigger problem... Top-level signals which are registered >(either inputs or outputs) aren't being clocked in the pad. I've checked >this using the FPGA editor. The pads are only being used as IBUF or OBUF. >The registering of the signal occurs inside a CLB. What I want, and what >used to happen automatically, is for the register to reside in the pad. Fast >clock to output delays depend on this. > >Any helpful suggestions on how to get the registers moved into the pads >would be greatly appreciated. I prefer not to resort to manual instantiation >of any components. > >Best regards, >Jamie Sanderson > >Article: 18885
Hello! We are evaluating the above two Synthesis tools for our FPGA and ASIC design. Anybody who has used these tools could you please answer following question. Which one would be better of the two. Please note that our design will be 250K+ gates. And FPGA would be Xilinx's virtex device. Thanks Best Regards, Abdul Rafeeq. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18886
On Fri, 19 Nov 1999 18:10:35 +0100, Luis Yanes <melus@esi.us.spamno.es> wrote: |I was just wondering if for the larger parts would worth to compress |the bitstream, trading configuration file size by configuration speed, |decompressing on the fly. | |The .bit files compress about 50% with zip or other archiver. | |73's de Luis Luis, I just browsed a .RBT file for an XCS20 design we're currently using, and it's mostly 1's, generally in long runs. So some fast and simple compression/decompression algorithm should be possible... might be useful in a situation with big FPGAs and limited storage. John ----------------- "If anybody ever marries you, it will be for the pleasure of hearing you talk piffle," said Harriet, severely.Article: 18887
I am contemplating using FPGA Compiler II Altera Edition with an "Apex" device or FPGA Express and a "Virtex" on an upcoming project. The original source code is for an ASIC synthesized with Design Compiler. The goal is to implement the FPGA version with as few changes to the source as possible and to accurately reflect the ASIC functionality. Has anyone compared the output of these two tools? Any other comments about either? How about their handling of synthesis hints and scripts from design compiler? The design is intended to be an ASIC emulator to allow me to shake out the design and give the s/w folks real hardware in system to play with while I ready the final tape for fab. It's not particularly fast (<25 MHz) for most of it although a small portion of the design runs at 2x that. -- Andrew Dyer <adyer@enteractDOTcom> Where do you want to go today? Nevermind, you're coming with us.Article: 18888
I have a Virtex design, I just wanted to add a damn pin to, and for the life of me, even following the documentation..I just can't get it to work. I want to add the SR pin of a CLB to an existing net...and it asks me for the name of the net...and I type it, and it says it already exists...which is true...but duh, it's what I want. Also, I tried editing the equations in the CLB, and I can put in 0 or 1, but not F4 ANYTHING but 0 or 1. Is this tool just sadly broken, or just too obtuse for a somewhat intelligent 12 year Xilinx veteran to use? I never had this kind of difficulty with the non-NeoCAD based editor... Any help would be appreciated!Article: 18889
Has anyone out there found a way to do a power on initialize in simulation for the Virtex ff primitives with the sync set/reset? I've successfully used FDC's instead of FD's and FDCE's instead of FDE's and driven the async reset with an ROC component for FF's that don't need the direct sync set/reset, but that won't work for the FDR or FDS primitives. Oh, why instantiate primitives you ask? It's because I'm putting together some hand placed macros for pieces I use alot --things like filter slices and such that I really don't want to hand place in the floorplanner every time they are instantiated. In these cases, the careful and floorplanning gives a performance boost from 93 MHz to 154 MHz in a -4 part. Andy Peters wrote: > Austin Franklin wrote in message <01bf3240$f071f880$207079c0@drt1>... > > >It shouldn't be any different to do reset 'correctly' for an HDL design or > >a schematic design, so I will ignore any problems that may exist with using > >HDLs. This is an architecture issue, not a tool issue. > > Well, you can instantiate the GSR if you like, or you can let the tool do it > for you. Me? I prefer to let the tool instantiate GSR. Makes the code a > bit more portable, too, but that's a detail. > > >How can you say intentionally adding a reset to EVERY flop in the design is > >not tedious? Adding code to every instance of a flip flop in the design is > >certainly extra work. > > Not, not really. Writing: > > flop : process (clk, reset) > begin > if reset = '1' then > blah <= '0'; > > is not too difficult. In fact, emacs conveniently does it for me. It also > has the major advantage of letting the simulation match the reality (i.e., > at the beginning of time, all flops are reset), and I don't have to deal > with the xilinx simulation models. My test benches assert that reset line > at the beginning of time, and never after that. It's only for power-on > reset. > > It might be more difficult (read: time-consuming, tedious) in a schematic to > have to connect the reset net to the async set/reset of every flop; placing > the startup symbol relieves you of that necessity. Then again, you've gotta > hook up the clock signal to every flop. > > >How is it necessary? If the GSR resets every flop, and is on a global > >dedicated net that doesn't even take up any resources (that can be used for > >something else), and meets timing and operational requirements? > > If you write the code as above, and make sure that all of the flops have an > async reset signal in the sensitivity list, any tool worth a damn at the end > of 1999 should infer GSR, which is what we want. FPGA Express and > Synplicity do. In fact, if you screw up and forget to reset one of the > flops, FPGA Express complains and says that it won't infer GSR. So, of > course it's a PITA to go through the reports and find the flops that you > forgot to reset, but I usually find those sorts of mistakes in pre-synthesis > simulation. There tends to be big Us or Xs and red lines in the wave window > until the flop is explicitly set or cleared. > > >What are you talking about power on reset? You don't have to do anything > >for power on reset, it is inherent in the configuration process. The data > >sheet says (and I quote): > > Yup, read it many times. I know that the startup sequence after powerup > asserts GSR and resets all of the flipflops that it's connected to. > However, for simulation convenience, it's nice to have a signal the test > bench can assert for power-on reset. > > >Now, on creating a 'special' net for use as a reset (instead of using the > >inherent GSR). The Virtex spec says the delay from GSR to XQ/YQ is under > >10ns. You say you assert your RESET to the part synchronously, so as long > >as your clock frequency is not > 100MHz, you will not have any problems > >using the dedicated global reset, and therefore, is unnecessary to do it > >using non-dedicated resources in this regard. > > Perhaps I wasn't clear. By "synchronous reset," I meant something like a > counter's synchronous clear signal that is generated by some other logic. I > don't mean that the sync reset is intended to reset the entire chip. > > For instance, > > count : process (clk, reset) is > begin > if reset = '1' then > counter <= 0; -- reset asserted at beginning of time > elsif rising_edge(clk) then > if clear = '1' then > counter <= 0; -- sync "clear" asserted by other logic > elsif enable = '1' then > counter <= counter + 1 > end if; > end if; > end process count; > > Clearly, the counter's "clear" signal must meet timing, as does the "enable" > signal, and the counter itself. Perhaps calling the "clear" signal a reset > is a misnomer, even though it's function is to reset a bunch of flipflops. > > >If you have an asynchronous reset, then all bets are off with either > >method, no matter how low your RESET delay and/or skew is inside your part, > >you stand a chance of having some of the chip come out of RESET on a > >different clock edge...so you have to design accordingly, which is not too > >tough to do, but still does not warrant not using the GSR. > > > > >So, it would also appear that using anything aside from the dedicated GSR > >would not give you any benefit (except under very specific conditions), and > >therefore, at least for my designs, unnecessary. And given the extra > >resources it would use, I would also call it 'wrong'. > > Again, my async (GSR) reset is only used at power-up; all other flops are > set or reset synchronously as required by the design. > > >I would appreciate it if you would post some 'facts' as to WHY creating > >your own RESET signal, instead of using the dedicated GSR RESET signal, is > >somehow beneficial. > > Facts are above, counselor. > > -- > ----------------------------------------- > Andy Peters > Sr Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) noao \dot\ edu > > "Creation Science" is oxymoronic. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18890
I tried compiling my 25K(FPGA)gates with FPGA express and had Synplicity do it with Symplify. It was compiled into XC4020XLA and XCV50. Timing requirement was 40MHz. It was a classic "logic" design with big 1-hot state machines, a big internal 3-state bus, a bunch of ram registers, counters, an incrementer, etc. No big arithmetic elements. Symplify produced a little faster (44MHz Vs 40MHz) but noticeably larger design than FPGA express. I haven't really gone back to try to figure out why it was larger, I just decided I wouldn't buy Symplify at this time. In addition, my code uncovered some Symplify bugs. (but in all fairness, there were some Synopsys work-arounds included also). Synplicity people said that their tool generally gave faster designs at the expense of some size. For me the difference was 80% of an XCV50 Virtex for FPGA Express Vs 116% for Symplify (wouldn't fit). They gave no further explanation, and no suggestions about how to make it get better area results. You need to recognize that Synopsys has come a long ways since some of the evaluations that people talk about here (but the GUI still and always will suck). But all of the tools have their limitations and stress-points. I guarantee that whatever tool you choose, if you are really picky about your results, you will be pissed at some point. For example, Symplicity (at some point in the past) wouldn't deal well with greater than 12 state 1-hot machines, and Synopsys (at some point, and maybe still) decided they would change one of the states to a 0-hot state caus' they felt like it. Many people would never notice since they passed functional vectors. If by some chance you are happy with the results, just wait for the next upgrade. Bruce arafeeq@my-deja.com wrote in message <814ql5$i5m$1@nnrp1.deja.com>... >Hello! > >We are evaluating the above two Synthesis tools for our FPGA and ASIC >design. Anybody who has used these tools could you please answer >following question. > >Which one would be better of the two. Please note that our design will >be 250K+ gates. And FPGA would be Xilinx's virtex device. > > >Thanks >Best Regards, > >Abdul Rafeeq. > > >Sent via Deja.com http://www.deja.com/ >Before you buy.Article: 18891
I just downloaded an FTP manager called Gozilla. It's free, and it implements the FTP restart capability. Has a lot of cool features, but restart and free are my favorites. I haven't used it to download a service pack yet, so I'm not sure if Xilinx will allow restart. Anyway, just trying to help bruceArticle: 18892
OK, let's set the record straight: A full-featured TCP/IP stack has been done in an FGPA. A pair of Xilinx 4044's, actually. It was built on a PCI card; the processor could send an entire web page to the card, then essentially say "go", and the FPGA's would do _all_ the rest; ACKs, retries, etc. There was no CPU core. The design still exists, and would probably be for sale to the right parties; just don't expect it to be anywhere near 'cheap'. Probably on the same scale as an ARM IP license. Sorry I can't say more; I signed an NDA before I worked on it. Dirk Bruere wrote: > > Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk> wrote in message > news:m2ogctdoqy.fsf@pcep-jamie.cern.ch... > > Austin Franklin writes: > > > You can not implement a TCP/IP stack in just a PLD, there simply aren't > > > enough gates, so you must not mean PLD, but something else...possibly > > > microprocessor, FPGA. > > > > I heard it's been done on an FPGA, and not an especially large one either. > > Not without a CPU core, AFAIK. > > DirkArticle: 18893
Download the xc9500.zip from http://www.xilinx.com/support/sw_bsdl.htm. The zip-file contains also the xc9536_v2.bsd that you have to copy into the appropriate directory of the Xilinx Foundation Software. I`m sure it will work. heinrich.fArticle: 18894
<snip> >curious about how common a problem this is. Is VHDL synthesis generally worse >than old ABEL/CUPL/Palasm synthesis? >Or is it just that little PLDs are so unsexy that no-one bothers much >developing the tools? Graham, I suspect that this is an Orcadism. Some years ago Orcad was held in high regard, with a widely used product of good quality. In the last 5 years, since the belated introduction of their Windows product line, I've lost all faith in their ability to deliver a useable piece of software, despite the fact that their hearts may be in the right place. Perhaps sooner or later they may get their act together. I haven't used version 9. Version 7.1, which you refer to, I found to be a complete disaster. You could post your code, and I could run it through Exemplar, Synplify, or Maxplus, and I'm sure it would come out fine. Certainly as good as Abel. I don't do much PLD stuff, but I do have a little 5032 design that is written in behavioural VHDL and synthesizes great with Synplify. It really is too bad about Orcad. In the last days of DOS, they ruled! Tom Meagher Houston TX Graham Seaman wrote in message <382df594@ant.wmin.ac.uk>... >I wrote: >: > I have a little behavioural VHDL FSM which analyzes ok; when I try to >: build >: > it Orcad Express generates an error message telling me I have too many >: > product terms for a couple of rows. On inspecting the vhdl netlist >: > its generated, there are actually not many PTs in the expressions >: > its complaining about - well within the powers of a 22V10! >: > Is there a common user error which could generate this? Or is this >: > a known problem for which a patch is available? (I have v. 7.1) >: > >: > Thanks for any advice, >: > >: > Graham Seaman >: > > >OK, I found the problem (with some help ;-). The error message itself >is misleading: its actually complaining because the registers used for >state bits in an FSM haven't been assigned pins [so ANY PTs would be too many >in this case]. This is because I went from a behavioural (case-statement) >style design for the FSM, and as far as I can see means that I can't use >this style of design for state machines going into PLDs and have to revert >to hand minimisation. Since this must be one of the most common applications >for PLDs, and since IIRC even ABEL used to be able to handle this, I'm now >curious about how common a problem this is. Is VHDL synthesis generally worse >than old ABEL/CUPL/Palasm synthesis? >Or is it just that little PLDs are so unsexy that no-one bothers much >developing the tools? > >Graham > >Article: 18895
Hi Jamie, Try using port attributes in your VHDL code. The following constructs work with Synplify targeting Virtex: attribute xc_pullup : boolean; attribute xc_pulldown : boolean; attribute xc_fast : boolean; attribute xc_ioff : boolean; attribute xc_pullup of <PortName> : signal is true; attribute xc_pulldown of <PortName> : signal is true; attribute xc_fast of <PortName> : signal is true; attribute xc_ioff of <PortName> : signal is true; Replace <PortName> with the port name of your choice. You should insert these lines in your top entity definition, after the port list but before "end <EntityName>;". The Xilinx place&route tools also have an option for allowing FFs in the IOBs that must be turned on (I think it is off by default). Catalin Baetoniu Jamie Sanderson wrote: > Greetings; > > I'm getting my feet wet with Virtex, after having used the 4000 series for a > few years. > > In the past, I've always stayed away from manually instantiating components, > mostly because the code is less readable and portable. This has worked well > with the 4000 parts when it comes to automatic inference of the startup > block and usage of flip-flops in the I/O blocks. Now that I've started > working with Virtex, neither of these works as it once did. > ...Article: 18896
Hi Austin, First use File/Main Properties to turn the Edit Mode to Read Write (it is Read Only by default). Then zoom in to your CLB (Ctrl-Right Click - and by the way zoom out is Shift-Ctrl-Right Click!) and select your CLB pin. Then find your net in the All Nets List (you can sort them by name) and Shith-Click to select it (if you just Click the pin will be deselected). Press the add button and wait. Then wait some more and when you least expect it your pin will be connected to that net. Of course, you must first configure the CLB pin and then add it to the net, otherwise it will just give you an error. You can also add multiple pins to a net this way (using Shift-Click). Now for the CLB equation problem. Select the CLB, press the editblock button and in the Block Editor window the F= toolbar button. Edit Feqn and Geqn and press the Save Changes and Closes Window toolbar button. It works for me. By the way, what I have described is valid for the M2.1i FPGA Editor, the M1.5i EPIC Design Editor, of NeoCAD origin, although similar is a different beast (which never realy worked). The M2.1i version is a complete rewrite and crashes less. I agree that the user interface is a bit strange. Catalin Baetoniu Austin Franklin wrote: > I have a Virtex design, I just wanted to add a damn pin to, and for the > life of me, even following the documentation..I just can't get it to work. > I want to add the SR pin of a CLB to an existing net...and it asks me for > the name of the net...and I type it, and it says it already exists...which > is true...but duh, it's what I want. > > Also, I tried editing the equations in the CLB, and I can put in 0 or 1, > but not F4 ANYTHING but 0 or 1. > > Is this tool just sadly broken, or just too obtuse for a somewhat > intelligent 12 year Xilinx veteran to use? I never had this kind of > difficulty with the non-NeoCAD based editor... > > Any help would be appreciated!Article: 18897
<email@inter.net> wrote in message news:38363B84.74B@inter.net... > OK, let's set the record straight: > > A full-featured TCP/IP stack has been done in an FGPA. A pair of Xilinx > 4044's, actually. > > It was built on a PCI card; the processor could send an entire web page > to the card, then essentially say "go", and the FPGA's would do _all_ > the rest; ACKs, retries, etc. There was no CPU core. > > The design still exists, and would probably be for sale to the right > parties; just don't expect it to be anywhere near 'cheap'. Probably on > the same scale as an ARM IP license. > > Sorry I can't say more; I signed an NDA before I worked on it. > Well, another lost opportunity for both of us. My port of TCP/IP is now in production with thousands being made. I would rather have just bought the stack in chip form and interfaced it like a normal IC. DirkArticle: 18898
Austin Franklin wrote: > > I have a Virtex design, I just wanted to add a damn pin to, and for the > life of me, even following the documentation..I just can't get it to work. > I want to add the SR pin of a CLB to an existing net...and it asks me for > the name of the net...and I type it, and it says it already exists...which > is true...but duh, it's what I want. > > Also, I tried editing the equations in the CLB, and I can put in 0 or 1, > but not F4 ANYTHING but 0 or 1. > > Is this tool just sadly broken, or just too obtuse for a somewhat > intelligent 12 year Xilinx veteran to use? I never had this kind of > difficulty with the non-NeoCAD based editor... > > Any help would be appreciated! I think Catalin gave you some good advice. I believe the procedure you were using will let you add the pin to a new net. Since the net you typed exists, it would not clobber the existing net. The tool was protecting you from yourself... AND being very obtuse. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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: 18899
Don Husby wrote: > > An anonymous poster (via Rickman) wrote: > > I have picked the Lucent ORCA FPGAs for the board I am currently > > building due to IO count, part cost and support. I have noticed that > > there are not many people discussing these devices in this newsgroup, > > which I assume is because there are not a lot of people using them. Can > > I ask why Xilinx parts are preferred over the Lucent devices? Other than > > inertia, why did you pick the Xilinx devices? > > I started using the Orca parts many years ago after buying Neocad which, > at the time, supported both Xilinx and Orca parts. I found that the Orca > parts had better performance, more pins, and were cheaper. I think that > is still true today for Orca 2x series parts vs. Xilinx 4x. > > The two big architectural advantages that Orca 2x has are: > FE-Mux into each flip flop can be used in many cases as an extra logic input. > Large numbers of tristate lines running vertically and horizontally. > (There are 2 Tbufs per LUT in the orca part). > > However, the OR2x lacks I/O flip flops and also doesn't have a carry > structure as flexible as the X4K chips. > > The Orca 3T series has made some improvements over the OR2x. > It now has I/O Flip-Flops. It's carry structure appears to be more > flexible, but the software doesn't suport it. (Xilinx has gone the other > way, and made theirs less flexible). Lucent also added a flip-flop to the > carry chain, making it more efficient for pipelined arithmetic, and for > implementing the 5-bit counters needed to address their 32-word RAMS. > > The OR3T has only 1 Tbuf per LUT, but still has horizontal and vertical > tristate lines as well as horizontal and vertical carry chains. (Virtex > has only vertical carry chains and horizontal tristate lines. It has 0.5 > Tbuf per LUT.) > > Lucent has also improved its memory architecture. It uses 2 LUTS to > implement a 32x1 dual-port memory, while Virtex loses a factor of 2 by > using 2 Luts to make a 16x1 dual-port RAM. > > Even with its apparent architectural advantages, the OR3T part doesn't do > as well as Virtex parts for the designs that I've tested. It appears that > the synthesis software (Leonardo Spectrum) does a much better job for > Virtex parts than for OR3T parts. > > -- > Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby > Fermi National Accelerator Lab Phone: 630-840-3668 > Batavia, IL 60510 Fax: 630-840-5406 Thanks for the info. I used the Lucent parts when they first came out. The software was just short of unusable and they quickly dropped their inhouse package and made Neocad the factory supplied software. But I was done by then and never got around to working with the Neocad SW much. I think you have a good handle on much of the architecture. The IO FFs are not just there, but they will support 0 hold time (without adding delays) if you use the special clock pins. This is a big improvement in the faster systems being used today. The 2T family was designed at a time when speeds were much slower and the 0 hold time was not such an issue. So a little extra delay getting to the FFs from the pins didn't seem to be such a big deal. I am not clear about saying the software doesn't support the "flexible" carry chain. I have done a bit of testing with counters and such and found that I can place them not only vertical or horizontal, but around corners! The only requirement for carry chains is to keep the PLCs adjacent. I assume that you mean the synthesis software doesn't use this feature? The poorer results of the synthesis wrt Xilinx designs is likely to be a SW issue as you say. But I am using schematic for now. I just can't see the real merits of HDL for much other than FSM work and that is where I have the most trouble with an HDL! For now, I am very happy with the Lucent parts. I got 221 IOs in a 256 BGA package which is more than any of the Xilinx parts. The Xilinx Virtex part (comparable to the OR3T parts) only gives 180 IOs in the 256 pin package!!! I don't know what happened with this part from Xilinx, but they missed the pin count boat on this one. But then they have a new 280 pin CSP (they don't like me calling it a BGA ;) that should give even more IOs in a smaller space and still be routable with decent PCB design rules! But they only have it in the low end series so far. So for the forseeable future I will be working with the Lucent parts. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. 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