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
On 15 Oct 1996, Thomas Kobler wrote: > Hello! > > I would like to ask if anybody had success in using the Xilinx > xchecker cable and xchecker.exe V5.1 od V5.2 under Windows > NT3.51 to download a LCA? > > To me it keeps crashing or it ignoring the download cable almost > every time. > > Any hints? > HI, I find when using 4nt xchecker runs less well than when when in the ordinary command window. I was advised by Xilinx that a machine with windows95 or dos is advisable when using xchecker. -- Jim ____________________________________________________________________ Jim Burns Research Assistant Phone +44 141 339 8855 x2069 Department of Computing Science Fax +44 141 330 4913 The University of Glasgow Email jim@dcs.gla.ac.uk Scotland Url http://www.dcs.gla.ac.uk/~jim G12 8QQ ____________________________________________________________________Article: 4376
> Agreed 100%. Unfortunately, it is very difficult to work with both > tools. I don't know any vendor that provides good integration between > schematic entry and an HDL ( I still prefer to write state machines > using HDL and not schematic). I seem to remember that the old DOS Viewlogic (unrestricted edition was $28000 here in the UK) had the ability to mix schematic and VHDL entry. You either opened a Viewdraw window, or opened a VHDL (text editor, basically) window - and that was it! I have avoided these massive costs by using CUPL (configured for the "VIRTUAL" device) for any state-machine blocks, outputting to PALASM format, converting this to XNF using PDS2XNF & XNFOPT, and for good measure using Viewgen to produce a schematic from this. Do a batch file for this, and that's all. Mixing schematic and state-machine modules is quite easy this way. The generated schematic is good for impressing people :) Of course, these are old tools, long unsupported. Nowadays this sort of capability would cost a small fortune. Peter.Article: 4377
In article <WrG8vAAAfgYyEwQ$@rhizik.demon.co.uk>, John Vickers <john@rhizik.demon.co.uk> writes: > Hi. > I'm looking for a small PLD (preferably with 16V8 fusemap) > which will operate over this supply range. Speed could > be anyhing. 35ns would be fine. > > Does anyone make such a device ? > > The power comes from a battery-backed (3.6VNiMh) supply, > which is 5V when the box is powered up, and 3.6-4.3V > when running off the battery. I do not know of a part that meets _ALL_ of the above, but some are close. Philips list at P3C18V8Z, but this is rated at 3.6V MAX, and is OTP Atmel have a ATF16V8CZ, just out, but this resets at appx 3.8V They have a ATF16LV8CZ part number, I assume will be 2.7V-6V ( as are their FLASH Controllers ) when released. Some suppliers have a 'sleep' pin4, for pin controlled power down, to preserve speed - but you have to drive this pin from your system. PLD vendors in general are slow to see PLD's in the same Vcc arena as microcontrollers. You also need to watch Icc-Vin specs, and very few have hysteresis, if chasing the uA region standby's. Let me know if you find a part that is 3-5V, Z rated, and available . hopethis helps - jim ===== Mandeno Granville FAX +64 9 6301 720, 128 Grange Rd Auckland 3 NZ ====== * Developers and suppliers of HDL PLD applications libraries * * for Microcontroller expansion and interface. * * x51 C, Pascal & Modula-2 Compilers, Simulators, Emulators & FLASH Pgmrs * * Contact : Jim Granville . Email above. * > A 4.8V NiCad/NiMh battery would be rather inconvenient: > e.g. need to supply 6V for charging. > -- > John Vickers Tel: +44 1223 560129 > Hardware / Software Person Fax: +44 1223 563698 > The Magic Board Company john@rhizik.demon.co.ukArticle: 4378
I am wondering how multipliers (and other complex arithmetic operations) are usually implemented on Xilinx FPGAs. Are there any libraries containing more complex arithmetic units than just adders? Is synthesis from VHDL an efficient alternative? Thanks, Reto -- Reto Zimmermann Integrated Systems Laboratory zimmi@iis.ee.ethz.ch Swiss Federal Institute of Technology http://www.iis.ee.ethz.ch/~zimmi/ Zurich, SwitzerlandArticle: 4379
Reto Zimmermann <zimmi@iis.ee.ethz.ch> wrote in article <326C9D46.167EB0E7@iis.ee.ethz.ch> :
>
>I am wondering how multipliers (and other complex arithmetic operations)
>are usually implemented on Xilinx FPGAs. Are there any libraries
>containing more complex arithmetic units than just adders? Is synthesis
>from VHDL an efficient alternative?
>
>Thanks, Reto
>
Xilinx has a very good application note on this, using partial products.
Chech www.xilinx.com. I'm sure it's there somewhere.
-Matt
Article: 4380> Synthesis is a deterministic process! True, but what is determined is not always knows, and can change with different revisisons of the compiler, and from vendor to vendor. > In In IEEE Standard Logic 1164 there is a dontcare value and in > HDLs there is something like 'others' or 'default' statements ... I have seen HDL code that should have been reduced to simple logic take up half of a chip...and it has taken weeks for the designer to figure out how to, if it can be done at all, get the synthesizer to generate 'good' (subjective) code. > HDL has nothing to do with floorplanning, you have to floorplan a schematic > and a HDL design. The point was that with HDLs you don't have consistent or intellegible naming of resources, and this makes floorplanning very difficult. > This one of the big advantage of HDLs. > With one HDL DEscription I can do a FPGA from XILINX, ACTEL or what you want > AND an ASIC. The only thing you need is the appropriate setup file > and the technology libs. But only one HDL description. True in most cases. The problem is since FPGAs are a course grained architecture, and have special device dependent features, what you have written to take advantage of one FPGAs architecture, may cause you problems with another. I have never known of anyone, my self included, who has been able to easily migrate from one technology to another using an HDL. Luckily, 99% of designs never really do... > > and require very little library work to add a new device. You > >may save time writing with HDL up front, but if it is for a fast/dense > >design, you will spend a great amount of time massaging it, rewriting it, > > Why? When the counter will get bigger i have to change only a generic . > Is this a great amount? I was referring to resource utilization and timing. Again, it can be a guessing game as to what the HDL will compile down to, and the consistency between revisions and vendors of HDL compilers. > > >I have some clients who I told them they would only have to pay me what I > >save them. For one, I converted their VHDL to schematics, went down two > >part sizes, and two speed grades, saving $46 per board, and the volume is > >in the thousands! > > I bet, optimization of the VHDL to better VHDL had saved more than $46! May be I should have sent the job to you and we could have split the difference! Not for FPGAs. Given todays VHDL compilers, (my experience is with Viewlogic, Synopsis and Exemplar VHDL compilers for FPGAs), not one of them is nearly as good as a schematic can be for best speed and resource utilization. VHDL is good if you don't care how big your part is, and if you have a lower speed design. I am using it for two clients now, and they are happy with this restriction. I have two clients that if the design were done in VHDL, the design wouldn't work. Having done over 60 IC designs, using HDLs and schematics, for both ASICs and FPGAs these are my experiences, for others results may vary! Experience is a good thing for forming strong opinions.... I like these HDL discussions.... Austin Franklin darkroom@ix.netcom.comArticle: 4381
> I seem to remember that the old DOS Viewlogic (unrestricted edition > was $28000 here in the UK) had the ability to mix schematic and VHDL > entry. You either opened a Viewdraw window, or opened a VHDL (text > editor, basically) window - and that was it! Xilinx has offered a Windows version of Viewlogic with the Xilinx libraries only for 1K! I think that's pretty good...I don't know how much extra VHDL would have been... You could use XABEL instead of VHDL for an extra $700 or so...and that integrated nicely, except you couldn't simulate until you compiled the design to LCA then lca to xnf'd, then xnf to wir...etc. A bit of work, but none the less, it worked fine. Not until recently has Viewlogic offered a good FPGA VHDL compiler in their tools. In the past, you had to buy someone elses...like Synopsis (some large amount of money) and run it on a 'workstation'.Article: 4382
Hey everybody out there.... I'm searching after a Demoboard for Flex8000 devices. Altera says that there aren't exist any Board, but what about third party developper? It should have access to all I/O-Pins, configuration Port (Byteblaster) and/or space for an EEPROM (e.g. EPC1213PC8) also Voltageregulator ... I planned to use the EPF8636ALC84-4 (PLCC package) first. Does anybody know something about this? Thanx in advance Domi **************************************************************** * Fachhochschule Dortmund * * Fachbereich 6 / Telcom * * Dipl.-Ing. Dominik Lenz * * Sonnenstrasse 171 * * 44137 Dortmund * * Germany * * email: fnt003@zx2.hrz.uni-dortmund.de * ****************************************************************Article: 4383
Xilinx devices have I/O that are 3-stated with a weak pull-up during configuration. Detail can be found in the Xilinx Data Book (Acrobat PDF format): http://www.xilinx.com/partinfo/xa_issue.pdf Marc Baker XilinxArticle: 4384
Let me explain a bit more, to show that we at Xilinx really put some thought into this issue: Before and during configuration, the HDL ( High during configuration ) output is active High, and LDC is active Low. but all outputs that are not involved in driving the configuration ( which ones are depends on the configuration mode ) are 3-stated with an internal weak pull-up transistor in the 30 to 100 kilohm range. At the end of configuration, the user has the option of making the FPGA "come alive" in one of several ways. The completion of configuration is indicated by the DONE pin going High, but outputs can be activated either one configuration clock period before, or one period after DONE going High. Similarily, the internal reset that held all flip-flops and latches in the reset state during configuration, can be released one clock period before or one clock period after DONE goes High. Thus the outputs can be activated while the internal logic is still held in a reset state, or - with the other option - the internal logic can be released and allowed to stabilize, before the outputs are being activated. It's all under your control. XC4000 and XC5200 have even more elaborate options, where the "waking up" can be synchronized not to the configuration clock, but to the user's syetem clock ( assuming they are differnt). As an additional precaution against ground bounce caused by a lot of outputs being activated simultaneously at the end of configuration, we made sure that, at that moment only, ALLl outputs are slew-rate limited. See page 13-33 of the 1996 Xilinx data book, now on the web. Peter Alfke, Xilinx ApplicationsArticle: 4385
HC16BGND is an advanced programmer’s interface that helps you to develop, test, and refine your assembly language programs for MOTOROLA’s 68HC16 microcontrollers. The key features include: - Run under MS Windows - Interface through PC’s parallel port - Motorola suggested 10 pin target connector - Download and debug HC16 assembly language program in S19 or HEX format - trace through your code by step through or step over - set up to 100 breakpoints - On-screen editing of register and data memory - On-fly assembly of instruction using mnemonics in program memory - Open infinite Register, Program, and Data windows - Exchange data through Windows clipboard - Easy to use. Just click on the menu with left mouse or click on the windows’ area. Everything is self-explained - Convenient and easy to install due to its parallel port interface. You can use laptop to do an on-site demonstration of you products - Low cost - 30 day money back guarantee and one year product warranty For more information or need a demo program, see http://users.why.net/wctech/hc16bgnd.htm, or FTP to FTP.WHY.NET/FTP/PUB/USERS/WCTECH, or send email to WCTECH@WHY.NET Larry ChenArticle: 4386
In article <01bbc02a$7f96cf90$207079c0@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes: >From: "Austin Franklin" <darkroom@ix.netcom.com> >Subject: Re: VHDL for Xilinx designs? >Date: 22 Oct 1996 15:04:30 GMT >> I seem to remember that the old DOS Viewlogic (unrestricted edition >> was $28000 here in the UK) had the ability to mix schematic and VHDL >> entry. You either opened a Viewdraw window, or opened a VHDL (text >> editor, basically) window - and that was it! >Xilinx has offered a Windows version of Viewlogic with the Xilinx libraries >only for 1K! I think that's pretty good...I don't know how much extra VHDL >would have been... You could use XABEL instead of VHDL for an extra $700 >or so...and that integrated nicely, except you couldn't simulate until you >compiled the design to LCA then lca to xnf'd, then xnf to wir...etc. A bit >of work, but none the less, it worked fine. >Not until recently has Viewlogic offered a good FPGA VHDL compiler in their >tools. In the past, you had to buy someone elses...like Synopsis (some >large amount of money) and run it on a 'workstation'. Whoa!! Time out! I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix HDL and schematic but their VHDL compiler is so bad that I can't recommend using it to anyone. We recently tossed our Viewlogic VHDL into the scrap bin and ponied up the considerable sum (around $50k) for Synopsys tools because we were having so much trouble with the Viewlogic tools. The Viewlogic reps were not in the least suprised when we told them what we were doing and in fact proceeded to tell us how well their simulation tools integrated with Synopsys. So, as the saying goes, "you get what you pay for". The Viewlogic tools cost about 60% of what Synopsys costs but we lost far more than that in lost productivity and missed deadlines.Article: 4387
Andreas Wehr wrote: > >Second is controlability. It is much harder to floorplan an HDL design. > >Much harder... I find that floorplanning is the real key to resource > >utilization and speed, especially for FPGAs. > > HDL has nothing to do with floorplanning, you have to floorplan a schematic > and a HDL design. The statement was that it was easier to floorplan using schematic than HDL I for think that to be true. Certainly it needs > >and require very little library work to add a new device. You > >may save time writing with HDL up front, but if it is for a fast/dense > >design, you will spend a great amount of time massaging it, rewriting it, > > Why? When the counter will get bigger i have to change only a generic . > Is this a great amount? > > >I have some clients who I told them they would only have to pay me what I > >save them. For one, I converted their VHDL to schematics, went down two > >part sizes, and two speed grades, saving $46 per board, and the volume is > >in the thousands! > > I bet, optimization of the VHDL to better VHDL had saved more than $46! Personally I belive that for many instances schematic is at least as good as a HDL. I tend to think that your above statement would loose you your money! Given that you know nothing about either a) the design or b) the parts used. Surley the thing about HDLs is that they are, largely, device independent and allow short development times (particulaly if a good library is used). This gives rapid time to market -> more money for company. Going in and doing optimisations later be it using HDL or schematic can save you significant costs as shown above. But if the market hadn't been captured initially these saving might be worth nothing as there may no longer be a market. This is why the interlectual property (IP) market is taking off. It should however be noted with respect to this that many IP vendors provide different HDL models for a) different target technologies and b) different synthesis tools. The reason? Because HDLs have to be written taking into account both these facts to produce optimal results. It's very easy state that HDLs are great for everything and I tend to agree they are essential for lots of things, but don't fall into the trap of beliving that they produce excellent results with no effort. Schematic still has advantages in the hands of a skilled engineers in some applications. I usually find it easier to visulise things in schematic rather than text but I'd rather design large state machines in a HDL. I'm sitting here designing full custom layout at the moment I would challenge anyone to produce faster more compact designs using soley a HDL. I would also challenge anyone to design a 1 million transistor chip (in a sensible time frame! that works first time. It's horses for courses. It's somwhat nieve to claim that any one technique is the answer to all your problems Furthermore remember VHDL isn't the only HDL. Most asic vendors use verilog as they're golden simulator, those which sign off in VHDL often convert to verilog and simulate with say Cadence verilog XL before they will fab a device. VHDL does however seem to be the HDL of choice for FPGAs JohnArticle: 4388
Thanks for the updated techdoc reference. I had almost given up on NT 4.0 and XACT. I must admit that Xilinx seems to be very slow in making an NT release when most of the EDA industry seems to be rushing towards NT with open arms. David Dye wrote: > > Actually there is a much more complete solution found in the Xilinx > Solutions Database: > http://www.xilinx.com/techdocs/902.htm > > There are more steps to be done than just installing the Rainport > driver. Following > these steps should get people running with the DOS version (5.2.1) of > the XACTstep > software in either Windows NT 3.51 or 4.0. This solution worked fine for me using NT 4.0 and XACT 5.2.1. A few things are still not working - most annoyingly - xde refuses to load a design. It starts up but crashes while reading the design file, it actually crashes the display adapter driver(and thus NT) if I specify a vesa graphics mode. Of course few of the windows tools do anything useful, which was as expected... One thing puzzled me though - xdelay and makebits uses almost 3 minutes each to process a small 5202 design. In dos or windows 95 it only took a few seconds(<10) to run the same design through those tools. (my machine is a 166 pentium w/32M ram) In fact 2/3's of the total run time for this little design was spent in those two tools??. > > david. > > David Dye > Technical Applications Engineer > Xilinx, Inc., San Jose, CA > ph> (408) 879-5370 > email> david.dye@xilinx.com Geir Ertzaas | email: ge@tandberg.no Dev. Engineer | phone: +47 67 11 62 88 Tandberg Television AS | Ph. Pedersensv. 20 | N-1324 Lysaker | Norway |Article: 4389
tim_hubberstey@mindlink.bc.ca (Tim Hubberstey) wrote: > >I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix HDL >and schematic but their VHDL compiler is so bad that I can't recommend using >it to anyone. We recently tossed our Viewlogic VHDL into the scrap bin and >ponied up the considerable sum (around $50k) for Synopsys tools because we >were having so much trouble with the Viewlogic tools. The Viewlogic reps were >not in the least suprised when we told them what we were doing and in fact >proceeded to tell us how well their simulation tools integrated with Synopsys. > >So, as the saying goes, "you get what you pay for". The Viewlogic tools cost >about 60% of what Synopsys costs but we lost far more than that in lost >productivity and missed deadlines. I'm going to concur with Tim here. In fact, I've got some stronger statements about the whole process. I've done programming with ORCA as well as Xilinx parts. I recently (some 8 months ago) finished off a major project using VHDL tools under Mentor Graphics and Synopsys. The designs were fairly complex state machines with tons of random logic and 50-60 VHDL files apiece. I was underwhelmed with the process of design, simulation, and production. Possibly because I was stuck with fixing a complex design left in the lurch by another developer it took an exceedingly long time to get the parts working properly. However, there were tools issues that just blew me away on just >>how bad<< they were. Synopsys. I found that the tool and hierarchical VHDL minimization did not get along well at all. The design I had was running at a relatively high speed. If one minimized the individual VHDL subcircuits in Synopsys, Synopsys and the ORCA libraries insisted upon sticking additional buffers in between the the various hierarchies in the design - yeah, back to back inverters on leads with one load. This did the timing no good. Sometimes it would go so far as to use the inverted signal to drive other CLBs, making it impossible to fix by hand routing/renaming the offending leads in NeoCAD. The eventual solution was to forget about minimizing the individual logic blocks, but rather flatten the whole design and minimizing it in one stroke. Since the minimization routines use random numbers to drive the process, each compile was a crap shoot as to whether that design, after place and route in NeoCAD, would have good timing. Remember that I said that it was a complex design? How about three-day run times? Pretty sad when you're on the critical path for a project. And I wasn't anywhere near 80% fill. In a previous life I designed a few Xilinx parts directly using XACT. NeoCAD's interface to the ORCA (and, as far as I know, to Xilinx parts) looks much the same. It isn't standard, but it is direct; if one wants a low prop delay on a lead, one can put it there. If I had had the whole above mess to do over again, I would probably have done it directly in NeoCAD. It would have taken me longer to get the initial design phase done; on the other hand, I wouldn't be staring at 30-hour place and route times every time a bug got fixed. (And >>that<< was on a SPARC 20!). My considered opinion is that the Synopsys tool I used at the time was highly optimized for custom VLSI and less so for CLB-based FPGA's. I believe that for nice, regular structures (interrupt registers; data flow paths, etc) and small designs these tools can do a good job; but for serious logic garbage collection and multiple complex state machines staying away from VHDL and using a >>good<< schematic editor (directly into the CLB's, of course) or a low level editor like XACT or NeoCAD may be a better way to go. Of course this all falls flat on its face if one is planning to go, after an initial debug/production run, to custom logic. There (from the advertising/propaganda I've heard) VHDL seems to have a better chance. Ken Becker Lucent TechnologiesArticle: 4390
>I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix HDL >and schematic but their VHDL compiler is so bad that I can't recommend using >it to anyone. I'm not recommending the Viewlogic VHDL tools, at least the old stuff for FPGA development...you're right, it didn't work for FPGA's well at all. But none the less, you can still use any VHDL compiler (or any HDL compiler) that outputs a .xnf file to add HDL to your Viewdraw FPGA schematics. Viewlogic has a real good simulation environment, and if you use their VHDL for functional models (like a PCI bus transactor, DRAM etc., external to the chip support circuitry) it integrates very well into their schematic/simulation environment. Viewlogic does have a new VHDL compiler out specifically for FPGAs. Exemplar does too... so do a few other companies. I agree, Synopsys has been the best to date, but my guess is you don't have to spend Synopsys's greedy 50k for a halfway decent VHDL for FPGAs now. I have the Exemplar tools, and they are not bad, I would put them on par with the Synopsys tools, and they are only 3.5k. Austin Franklin darkroom@ix.netcom.comArticle: 4391
Hi, In article 207079c0@drt1, "Austin Franklin" <darkroom@ix.netcom.com> writes: >I have seen HDL code that should have been reduced to simple logic take up >half of a chip...and it has taken weeks for the designer to figure out how >to, if it can be done at all, get the synthesizer to generate 'good' >(subjective) code. some time ago I had the same problem (garbage in garbage out), but since I use some guide lines (from great HDL books) how to describe state machines, counter, muxes...with HDL, the problem is gone away. >True in most cases. The problem is since FPGAs are a course grained >architecture, and have special device dependent features, what you have >written to take advantage of one FPGAs architecture, may cause you problems >with another. I have never known of anyone, my self included, who has been >able to easily migrate from one technology to another using an HDL. >Luckily, 99% of designs never really do... In less than 1% of your designs migrate from an FPGA to an ASIC? >> I bet, optimization of the VHDL to better VHDL had saved more than $46! > >May be I should have sent the job to you and we could have split the >difference! >Not for FPGAs. Given todays VHDL compilers, (my experience is with >Viewlogic, Synopsis and Exemplar VHDL compilers for FPGAs), not one of them >is nearly as good as a schematic can be for best speed and resource >utilization. VHDL is good if you don't care how big your part is, and if >you have a lower speed design. I am using it for two clients now, and they >are happy with this restriction. I have two clients that if the design >were done in VHDL, the design wouldn't work. My opinion is that a new revision or redesigns is done much more easier with VHDL or Verilog than with a schematic. Personally I use HDLs and I hope all competitors use schematics and they are happy with it. ;-) best regards, AndreasArticle: 4392
In article <01bbbed7$2597ebe0$2da8b8cd@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes: >A number of problems exist with HDLs in general. One is you don't know >exactly what the code is going to compile down to... Kind of like the Yes you do. It is deterministic. Specially if you do know how to code in VHDL, and the differences between each of the constructs. >proccessors with lots of memory (ASICs), but for a small slow micro (FPGAs) >it's not as good. In an HDL, a case statement can become this really obese >thing checking for every possible condition for each branch... Not if you know how to code the case statement. Sometimes, the best approach is to have a combination of IF statements with embedded case statements which the compiler can optimize. Also, you can use the '-' for don't care, except that not all simulators know how to handle it. > I certainly >believe you can do pretty well with some finely crafted HDL code, if you >know exactly what it is going to compile down to. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Agreed, and that is my entire point. See below. > >Second is controlability. It is much harder to floorplan an HDL design. >Much harder... I find that floorplanning is the real key to resource >utilization and speed, especially for FPGAs. Floorplanning is needed independent of the design entry method. If you want to be efficient, then you have to floorplan. Period. If your VHDL code is done in a hierarchical manner, then floorplaning is rather trivial, as you can place the blocks one at a time. If on the other hand, you have a flat one process-does-all code, or a collection of concurrent statements, ala min-term form, then I would expect the same level of difficultiness in floorplaning that you would have if it had been done in a flat schematic entry. > >Personally, I like to mix both...but schematics is really the way to go for >the best speed and resource utilization. I do schematics with my own I disagree. For example, we had an engineer work in a design which he designed in schematic form. He selected a XC4010 which he hand placed, and hand routed(yeah, he was an idiot). The design contained a 16x16 ram file, a 32x16 ROM look-up table, 6 16 bit timers, 4 8 bit timers, and master/slave interfaces to two busses, one of them VME, the second an i960 bus. Bottom line is that I looked at the schematic, laughed at it, since once it was downloaded into the Xistink, it wouldn't run and crashed the i960 and VME. Instead of fixing a screwed up schematic, I coded the entire thing in VHDL. Under this scenario, I had fixed pins to deal with, since the design was already built. I was able to simulate, not only the Xistink, but the entire board in our VHDL simulator, debug my code, synthesize it and have it running in 4 days. In addition, it fit, operated at higher frequency than the original designer had accomplished, and added some functionality which was missing from the original design. Now, our company has a VHDL code description of the design, which other engineers can read and under- stand without a painful search through 14 pages of schematics, and when we go through a re-spin of the PCB, I'll float the pins and let the floorplanning be even better, with a definite improvement in speed and better utilization of the CLBs (for instance, the timers couldn't be CLA because of the original pin assignments forced a massive routing crossing). BTW, the original designer is no longer with us, and he had claimed to be a Xilinx guru, which even the local Xilinx FAE concurred. :-) >libraries of n bit registers, tbufs, counters, muxes. They are device >independent, and require very little library work to add a new device. You The code on the above example can be retargetted to any FPGA, either ALTERA, ACTEL, or ORCA, without any recoding other than the ROM block, which is a minor submodule. >I have some clients who I told them they would only have to pay me what I >save them. For one, I converted their VHDL to schematics, went down two >part sizes, and two speed grades, saving $46 per board, and the volume is >in the thousands! I bet you that it was rather trivial to convert the VHDL to schematic. In addition, if you indeed saved that much space and size, then I would have to say that the original VHDL code was poor and the designer didn't know the task in hand nor the VHDL environment. Also, the quality of the synthesis affects the utilitization of the FPGA. Not all VHDL compilers are created equal. I spent months benchmarking all of the VHDL compilers out there. In the end, we settled for Exemplar, which beat all of the others in our benchmarks. In that lapse of time, I saw three revisions of Viewlogic (both on PCs and Sun workstations), Synario, Synplicity, Warped, other re-encarnations of Metamore VHDL compiler, and two revs of Exemplar Galileo. Our company also has a Synopsis design environment for ASIC development, so we have the cadillac, so they say :-). Before I designed a 175K gates ASIC, I was a schematic kind of guy, but since then I've seen the light :-). Hope this posting balances the discussion. ErasmoArticle: 4393
Fellow Mentor/Xilinx users, Has anyone been using B.2 with the Xilinx XACT 5.2.1 design kit? We're currently at A.4 and are contemplating a move to B.2. This would allow us to take advantage of Autologic II's improved Xilinx synth capabilities in our mixed VHDL/schematic process. I'm curious if B.2 schematics present a problem for XACT? The Xilinx line apparently is that only A.4 is "officially" supported, although I'm aware of some Xilinx engineers who are using B.1 internally. Thanks in advance, -- _______________________________________________________________________ Lance Gin "off the keyboard Delco Systems - GM Hughes Electronics over the bridge, OFC: 805.961.7567 FAX: 805.961.7739 through the gateway, C43LYG@dso.hac.com nothing but NET!" _______________________________________________________________________Article: 4394
Hello All, What suggestions do people have out there for a starter FPGA development kit/EVM/EVB? Ideally, I'd like something that I can program FPGA ICs to use in future single-chip designs. Being a student means I can't afford anything big. I just want something to play and discover with. Any donations of old equipment will be accepted with pleasure. :-) Andrew. -- Andrew Plumb, VE3SLG. E-mail: Tekmage@io.org 3app@qlink.queensu.ca WWW: http://www.io.org/~tekmage/ Traversing digital oceans astride an analog dolphin...Article: 4395
> Yes you do. It is deterministic. Specially if you do know how to code in > VHDL, and the differences between each of the constructs. I agree it is deterministic, meaning it will compile down to the same logic every time if given the SAME inputs....but...how do you know what that logic is going to be? Different compilers compile down to different logic. Since you don't know what it is going to compile down to, you don't know if it's good or bad...With a schematic, what you see is what you get... > Not if you know how to code the case statement. Sometimes, the best approach > is to have a combination of IF statements with embedded case statements > which the compiler can optimize. Also, you can use the '-' for don't > care, except that not all simulators know how to handle it. I agree too. But how do you know what the compiler is going to do with the case statement, since different compilers will generate different results with the same VHDL code... > Floorplanning is needed independent of the design entry method. Agreed, but with VHDL, you don't get intellegible names out of the code. Also, when you change the design, the names change too. At least that's the experience I have had. There is a way around that....and when we do VHDL for designs, or our clients do, we do the design so it will give us consistent naming. > >Personally, I like to mix both...but schematics is really the way to go for > >the best speed and resource utilization. > > I disagree. For example, we had an engineer work in a design which he > designed in schematic form. He selected a XC4010 which he hand placed, and > hand routed(yeah, he was an idiot). The design contained a 16x16 ram file, > a 32x16 ROM look-up table, 6 16 bit timers, 4 8 bit timers, and master/slave > interfaces to two busses, one of them VME, the second an i960 bus. Bottom > line is that I looked at the schematic, laughed at it, since once it > was downloaded into the Xistink, it wouldn't run and crashed the i960 and > VME. Instead of fixing a screwed up schematic, I coded the entire thing > in VHDL. Under this scenario, I had fixed pins to deal with, since the > design was already built. I was able to simulate, not only the Xistink, but > the entire board in our VHDL simulator, debug my code, synthesize it and > have it running in 4 days. In addition, it fit, operated at higher frequency > than the original designer had accomplished, and added some functionality > which was missing from the original design. Now, our company has a VHDL > code description of the design, which other engineers can read and under- > stand without a painful search through 14 pages of schematics, and when > we go through a re-spin of the PCB, I'll float the pins and let the > floorplanning be even better, with a definite improvement in speed and > better utilization of the CLBs (for instance, the timers couldn't be > CLA because of the original pin assignments forced a massive routing > crossing). BTW, the original designer is no longer with us, and he > had claimed to be a Xilinx guru, which even the local Xilinx FAE > concurred. :-) There are a lot of self proclaimed Xilinx gurus out there, and self proclaimed gurus in general, but a bad engineer, with any tool, VHDL or schematic, is going to get bad results. I spend half my life cleaning up other peoples bad engineering, and the other half doing what I believe to be good engineering from scratch (I don't get much sleep...). The real truth is you have to know the device and the tools in order to do a good job. BTW, who was this guru? (email, not in group please) >Also, the quality of the > synthesis affects the utilitization of the FPGA. Not all VHDL compilers > are created equal. Agreed, >I spent months benchmarking all of the > VHDL compilers out there. In the end, we settled for Exemplar, which > beat all of the others in our benchmarks. In that lapse of time, I saw > three revisions of Viewlogic (both on PCs and Sun workstations), Synario, > Synplicity, Warped, other re-encarnations of Metamore VHDL compiler, and > two revs of Exemplar Galileo. Our company also has a Synopsis design > environment for ASIC development, so we have the cadillac, so they say :-). > Before I designed a 175K gates ASIC, I was a schematic kind of guy, but > since then I've seen the light :-). Glad to hear that, I just got the Galileo tools, and look forward to trying them. I have Synopsys too, and that has been the best so far....I get my tools free cause I do work for some of these EDA and ASIC companies...but the high price of Synopsys has been very prohibitive to most people. The Exemplar tools seem to be more reasonably priced. P.S. - don't get blinded! (sic) I do agree that good design and understanding, whether using VHDL or schematics, or whatever, will lead to better results. The tools for VHDL for FPGAs have been pretty poor until recently. The EDA vendors have done a good job making their tools work with FPGAs recently. I do believe that today, you can do a pretty good (near minimum resource utilization, and somewhat fast timing) design with VHDL. Previously, VHDL used to cap out at 10Mhz (in a Xilinx 4k). Today, because of better VHDL compilers, and faster parts, you can get 25+Mhz out of it. I still don't think, nor have I seen, anyone be able to get near 33Mhz out of VHDL in a Xilinx 4k FPGA. I also think that data path in schematics (there is no optimization in data path...) is far better than in VHDL because you can see it. You don't have to sift through pages and pages of code to figure it out. This appears to have been the liveliest discussion in this newsgroup....It's like the Mac is better than PC thing.... Austin Franklin darkroom@ix.netcom.comArticle: 4396
In article <01bbc0f2$ad72c860$76c220cc@drt1> "Austin Franklin" <darkroom@ix.netcom.com> writes: >From: "Austin Franklin" <darkroom@ix.netcom.com> >Subject: Re: VHDL for Xilinx designs? >Date: 23 Oct 1996 14:57:22 GMT >>I'm sorry but I have to speak up here. Viewlogic _does_ allow you to mix >HDL >>and schematic but their VHDL compiler is so bad that I can't recommend >using >>it to anyone. [snip] >Viewlogic does have a new VHDL compiler out specifically for FPGAs. >Exemplar does too... so do a few other companies. I agree, Synopsys has >been the best to date, but my guess is you don't have to spend Synopsys's >greedy 50k for a halfway decent VHDL for FPGAs now. I have the Exemplar >tools, and they are not bad, I would put them on par with the Synopsys >tools, and they are only 3.5k. >Austin Franklin >darkroom@ix.netcom.com We _were_ using the latest Viewlogic synthesizer, v6.0.3 under Unix and while it is a vast improvement over the previous (nearly unusable) v5.3 stuff, it is still a far cry from being a serious tool.Article: 4397
Austin Franklin <darkroom@ix.netcom.com> wrote in article
<01bbbefd$7414e3b0$a1cab7c7@drt1>...
> There are two C -> Xilinx netlisters I know of, and I am curious if
anyone
> has any experience with them, or any others.
>
> The first I know of is called NLC, developed by Christian Iseli at the
> System Logic Lab of the Federal Polytechnical School of Lausanne,
> Switzerland. The second I know of was developed by the networking group
of
> Digital in California.
>
> Thanks,
>
> Austin Franklin
> darkroom@ix.netcom.com
Certainly Digital has one.
I have my own tool, called CNets, which emits XC4000 XNF. It is a set of
classes which extend C++ with user defined types to describe nets, buses
(vector of nets), and gate expressions. There are also functions to emit
primitives such as flip-flops, SRAMs, TBUFs, IBUFs, etc. My processor
designs are specified in CNets.
I wrote CNets for three reasons.
* I was growing old drawing and labeling 32-bit datapath elements in
ViewLogic
* the DOS WorkView tools didn't seem to work very well under Win95 or NT,
and I loathe DOS
* I couldn't afford Verilog or VHDL tools, and neither could other people
(computer engineering hobbyists) with whom I wish(ed) to share my tools
In retrospect, and particularly in light of recent discussions about doing
Xilinx designs using VHDL, CNets, though primitive, has turned out to be
quite a pleasant design environment -- the best of both worlds.
Like schematic capture, all primitive instantiations, placements, and other
constraints, are explicit (if you wish). No "pushing on a rope" to get the
design you have in mind through the HDL synthesis tool. Floorplanning
datapaths is a breeze. And since I tend to do my own "mental technology
mapping" (of gates into LUTs), by default CNets automatically emits FMAPs
for 2-4 input logic functions.
Like HDLs, CNets is based on a programming language, therefore it is easy
to have functions, loops, conditionals, variable-width structures,
lookup-tables, conditional emission of logic, etc. Best of all, CNets
designs recompile, relink, run, and emit the new XNF, ready for place and
route, in less than ten seconds. Wait another 30 minutes for PPR and
you're done. :-) Also, for users familiar with C++, CNets should be more
familiar than Verilog or VHDL.
To give you a feel for CNets, attached below are some examples of code from
one of my designs. Keep in mind this was a first cut, a quick hack, to get
my darn designs going.
This past summer I started CNets, version 2, in Java -- "JHDL" if you will.
Key new features included better support for design 'modules' and a
cycle-based simulator. Unfortunately, I didn't finish this project. I may
yet try again this fall in my copious spare time.
Cheers,
Jan Gray
Redmond, WA
lfsr_div emits lfsr counters to divide by arbitrary n. It is similar to an
XBLOX counter with style LFSR. The first half of the function determines
how many bits are in 'n', what the lfsr shift register bits 'w' look like
after 'n' clockings. The second half of the function actually emits an
n-bit shift register, whose input is the xnor of certain taps off the shift
register. The formal arguments are
out -- the net which is true after n clockings of the LFSR counter
ce -- the counter clock enable
reset -- if true, reset the counter on next clock edge
n -- the divisor
// emit an lfsr counter and decoder to divide by n
//
// See "Efficient Shift Registers, LFSR Counters, and
// Long Pseudo-Random Sequence Generators", Peter Alfke,
// Xilinx App Note, Aug. 1995
//
void lfsr_div(Net out, Net ce, Net reset, unsigned n) {
Env e;
e.setModule(out.getName());
// choose appropriate width counter
static unsigned taps[32][4] = {
{ 0 }, { 0 }, { 0 }, { 3, 2 },
{ 4, 3 }, { 5, 3 }, { 6, 5 }, { 7, 6 },
{ 8, 6, 5, 4 }, { 9, 5 }, { 10, 7 }, { 11, 9 },
{ 12, 6, 4, 1 }, { 13, 4, 3, 1 }, { 14, 5, 3, 1 }, { 15, 14 },
{ 16, 15, 13, 4 }, { 17, 14 }, { 18, 11 }, { 19, 6, 2, 1 },
{ 20, 17 }, { 21, 19 }, { 22, 21 }, { 23, 18 },
{ 24, 23, 22, 17 }, { 25, 22 }, { 26, 6, 2, 1 }, { 27, 5, 2, 1 },
{ 28, 25 }, { 29, 27 }, { 30, 6, 4, 1, }, { 31, 28 }
};
check(n <= (1 << 30));
for (unsigned bits = 1; n >= (1U << bits); bits++)
;
check((1U << (bits-1)) <= n && n < (1U << bits));
// determine bit pattern of terminal state (after n-1 clockings of lfsr)
unsigned w = 0;
for (unsigned i = 1; i < n; i++) {
unsigned in = 0;
for (unsigned j = 0; j < 4 && taps[bits][j]; j++)
in ^= (w >> (taps[bits][j]) - 1) & 1;
w = ((w << 1) & ((1 << bits) - 1)) ^ !in;
check(w != 0);
}
// emit shift register and gates to compare to terminal state
bus(lfsr, bits+1);
out = lfsr(bits,1) == w;
lfsr[0] = gnd;
net(lfsr_in) = xnor(lfsr[taps[bits][0]], lfsr[taps[bits][1]],
lfsr[taps[bits][2]], lfsr[taps[bits][3]]);
net(lfsr_reset) = out | reset;
ff(lfsr[1], lfsr_in & ~lfsr_reset, ce);
for (i = 2; i <= bits; i++)
ff(lfsr[i], lfsr[i-1] & ~lfsr_reset, ce);
}
Some of the trickier constructions:
out = lfsr(bits,1) == w;
-- drive 'out' with an AND gate which is true when the bits lfsr[bits:1]
match the bit pattern in the integer 'constant' w.
net(lfsr_in) = xnor(lfsr[taps[bits][0]], lfsr[taps[bits][1]],
lfsr[taps[bits][2]], lfsr[taps[bits][3]]);
-- drive <out>/lfsr_in with the XNOR of up to four taps off the shift
register.
ff(lfsr[i], lfsr[i-1] & ~lfsr_reset, ce);
-- emit a flip-flop whose D input is the AND of lfsr[i-1] and NOT
lfsr_reset, whose clock enable is 'ce', whose Q output is lfsr[i].
This next piece of code defines a 'cbit'-bit pipelined RISC datapath.
Sorry for the sparse comments. This is *not* what I would consider
production code! You may wish to visit
http://www3.sympatico.ca/jsgray/sld020.htm to see what this does.
....
for (i = 0; i < cbit; i++) {
unsigned r = rowForBit(i);
unsigned t = 1 + even(i);
// instruction register
ff(ir[i], mem.d[i], c.irce, _, loc(r,colIR));
// PC incrementer and MAR (memory address register)
m2(marmux[i], pcincr[i], adder[i], c.addersel, loc(r,colMMAR));
if (i >= 2)
ff(pc[i], marmux[i], c.pcce, _, loc(r,colPC));
ff(mem.ad[i], marmux[i], c.marce, _, loc(r,colMAR));
tbuf(res[i], pc[i], c.pct, tloc(r,colPCT,t));
if (i >= 2 && even(i))
inc2(pcincr[i+1], pcincr[i], pccin[i+2], pccin[i+1], pc[i+1], pc[i],
pccin[i], loc(r,colPCIncr));
// result bus and write back
ff(wb[i], res[i], c.wbce, _, loc(r,colWB));
// register file, A and B operand buses
ram(rfa[i], wb[i], c.rna, c.awe, loc(r, colRFA+odd(i)));
m2(ma[i], rfa[i], res[i], c.forward, loc(r,colMA));
ff(a[i], ma[i], c.ace, _, loc(r,colA));
ram(rfb[i], wb[i], c.rnb, c.bwe, loc(r, colRFB+odd(i)));
ff(dout[i], rfb[i], c.doutce, _, loc(r, colRFB+odd(i)));
m2(mb[i], rfb[i], ir[i<cbitImm ? i : cbitImm-1], c.immed, loc(r,colMB));
ff(b[i], mb[i], c.bce, _, loc(r,colB));
// ALU
if (even(i))
addsub2(adder[i+1], adder[i], cin[i+2], cin[i+1], a[i+1], a[i], b[i+1],
b[i], cin[i], c.add, loc(r,colAdder));
tbuf(res[i], adder[i], c.addert, tloc(r,colAdderT,t));
::lu(lu[i], a[i], b[i], c.lu1, c.lu0, loc(r,colLU));
tbuf(res[i], lu[i], c.lut, tloc(r,colLUT,t));
// shifter: shift/rotate left and right 1, 2, and 4 bits
// tbuf(res[i], (i >= 4) ? a[i-4] : rola[cbit-4+i], c.shl4t,
tloc(r,colShiftT ,t));
tbuf(res[i], (i >= 2) ? a[i-2] : rola[cbit-2+i], c.shl2t,
tloc(r,colShiftT ,t));
tbuf(res[i], (i >= 1) ? a[i-1] : rola[cbit-1+i], c.shl1t,
tloc(r,colShiftT+1,t));
tbuf(res[i], (i < cbit-1) ? a[i+1] : rora[1-cbit+i], c.shr1t,
tloc(r,colShiftT+2,t));
tbuf(res[i], (i < cbit-2) ? a[i+2] : rora[2-cbit+i], c.shr2t,
tloc(r,colShiftT+3,t));
// tbuf(res[i], (i < cbit-4) ? a[i+4] : rora[4-cbit+i], c.shr4t,
tloc(r,colShiftT+5,t));
// data in
tbuf(res[i], mem.d[i], (i < 8) ? c.dinbytet : (i < 16) ? c.dinhalft :
c.dinwordt, tloc(r,colDinT,t));
// zero/sign extension
if (i < 8)
;
else if (i < 16)
tbuf(res[i], c.halfsex, c.halfsext, tloc(r,colExtT,t));
else
tbuf(res[i], c.wordsex, c.wordsext, tloc(r,colExtT,t));
// data out
tbuf(res[i], dout[i], c.doutt, tloc(r,colDoutT,t));
tbuf(mem.d[i], res[i], (i < 8) ? mem.doutbytet : (i < 16) ? mem.douthalft
: mem.doutwordt, tloc(r,colDBusDoutT,t));
}
Things to note here.
* c.XXX are control signals from the "control unit" module
* mem.XXX are memory datapath signals from the "on-chip memory bus" module
* some elements are commented out -- try commenting out parts of your
schematic sometime.
* constraints -- the optional calls to 'loc()' and 'tloc()' apply placement
constraints, forcing elements to certain (row,col) positions; the various
colXXX are just enum constants, so it is easy to refloorplan things; note
no rloc()s yet!
Article: 4398In article <01bbc02a$7f96cf90$207079c0@drt1>, "Austin Franklin" <darkroom@ix.netcom.com> wrote: >> I seem to remember that the old DOS Viewlogic (unrestricted edition >> was $28000 here in the UK) had the ability to mix schematic and VHDL >> entry ... Data IO offers a product called Synario that runs under Windows. It is an integrated environment that will allow you to target a number of FPGA/EPLD's including Xilinx. It will allow you to mix schematic, VHDL, ABEL and graphical state machine entry. If you do include VHDL input, you are restricted to using a VHDL simulator; otherwise you can choose between Verilog and VHDL simulation (both functional and timing).Article: 4399
Dear all, Could any one please advise me about the most compact and fastest implementation / algorithm of 16 bit-integer-multiplier. I intend to use the Xilinx XC4000 series or the Altera Flex10K. Many thanks ! Regards Tendy ERG Telecommunications, Australia tthe@aesprodata.com.au
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