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
XESS Corp. has released more material for the "FPGA Workout II" text.
Two new chapters have been added:
+ Data Acquisition using the EPX780 FPGA
Shows how to use the EPX780 FPGA to do digital-to-analog
and analog-to-digital conversions and how to interface it
to single-chip DACs and ADCs.
+ Microcontroller + FPGA Design Addendum
A set of simple design examples that demonstrate how
to use XESS Corp.'s new epX31. The epX31 combines an
EPX780 FPGA with an 8031 microcontroller, and these examples
show how to make the microcontroller and FPGA work in
cooperation to solve problems.
The DOS-based hypertext of "FPGA Workout II" can be downloaded
from ftp.vnet.net. Go to directory pub/users/xess/FPGA_Workout_II.
There are currently seven chapters covering the following topics:
+ detailed architecture of the EPX780 FPGA
+ syntax manual for the PLDasm HDL
+ JTAG fundamentals and use with the EPX780
+ a configuration circuit for the EPX780
+ buffered UART communications with the EPX780
+ data acquisition using the EPX780
+ microcontroller + FPGA design addendum
--
|| Dave Van den Bout -- XESS Corp. ||
|| 2608 Sweetgum Dr., Apex, NC 27502 ||
|| (919) 387-0076 FAX:(919) 387-1302 ||
|| devb@xess.com devb@vnet.net ||
Article: 3326Richard J. Auletta wrote: > > Has anyone used the Xilinx XACT 6.0 tools with Windows NT or > run Cypress Warp 2 or 3 tools (with Workview Office) with Windows NT? Peter Alfke from will probably respond in short order (is that him barreling down behind me?), but I'll get my two cents' worth in... Windows NT protects everybody and everything from the primitive hardware. That is its mission (or, the *means* to its mission) as a crash-resistant operating system. You want to talk to the parallel port directly so you can say "hi" to your dongle? HA! Forget it! What did you say? You want to talk directly to the video board in 1024x768 mode? BUZZ OFF, INFIDEL!! Having said that, there is a whole new set of "drivers" or DLLs which permit dongle-type copy protection under NT, but ViewLogic and maybe OrCad are the first ones out with their software so enabled. Xilinx and Lucent (ATT Orca) are working on their releases, but as far as I know they aren't ready yet. By the way, ViewLogic figures that if you're gonna run their SW on NT, then you must be working for a big rich company, and they're gonna charge you $5750 for basic schematic capture (including 1st year of SW support). If you run the exact same SW under W95, they'll only charge you $2300. I think that they are either undercharging for the W95 license, or they are overcharging for the NT privileges. Onward, ORCAD! Their new CAPTURE package starts at $995 (with libraries) and runs under either W95 or NT. It looks real good, check it out! Regards, Bob Elkind ************************************************************************** Bob Elkind email:eteam@aracnet.com CIS:72022,21 7118 SW Lee Road part-time fax number:503.357.9001 Gaston, OR 97119 cell:503.709.1985 home:503.359.4903 ******** Video processing, R&D, ASIC, FPGA design consulting *************Article: 3327
Sounds like you have used up all your interconnects. I have had register-intensive designs (XC3064) which were 98% utilised and routed fine (with old 1991 software) and I have had designs which were about 70% utilised which only their latest place/route s/w would route, and only just about at that. I would imagine VHDL generates lots of random logic, which is not very good for register-rich FPGAs like Xilinx. Peter.Article: 3328
I just finished the logic design for an Altera MAX9560RC240-20 CPLD, but the project doesn't fit. According to the report file, the design uses 182 out of 191 pins and 485 of the 560 logic cells so a fit may be possible. The problem is that the compiler gives no hint what causes the fitting failure. I only get the message Error: Project doesn't fit The report file refers to the Error Summary section which shall give detailed error information, but is empty. So I have no idea what causes the failure. I tried changing some synthesis options (e.g soft buffer insertion ON, advanced fitter settings), but that didn't help Has anybody experienced a situation like this before and my suggest how it may be overcome? How good are my chances to make the project fit by detailed floor-planning? Thanks for help, Andre' Klindworth - speaking for TRINAMIC Electronic System Design GmbH i.G. -- --------------------------------------------------------------------------- Andre' Klindworth Universitaet Hamburg, FB Informatik klindwor@informatik.uni-hamburg.de Vogt-Koelln-Str.30, D-22527 Hamburg http://tech-www.informatik.uni-hamburg.de/Personal/klindwor/Klindworth.htmlArticle: 3329
In article <peter-1305961134150001@appsmac-1.xilinx.com>, Peter Alfke <peter@xilinx.com> wrote: > >Xilinx sells ³Foundation Base² for US$ 995, a ³shrink-wrapped² complete >package without a dongel (!). It has a Schematic Editor and Gate-level >Simulator. Design Manager, Flow Engine, Timing Aanalyzer, Hardware >debugger and PROM File Formatter are all included. >The package supports low-complexity FPGAs ( up to and including XC3042, >XC4003, XC5204) and all XC7300 and XC9500 CPLD. >XABEL is also included, but it requires a dongel. > >For US$ 500 more, VHDL Synthesis and XBLOX are added to the package. > >Prices in the UK and in NZ should be roughly equivalent. > Is this the same as the "Aldec Foundation standard software system" part number XC-DS-FND-STD-PC1-C for which the list price is UKP 3319.38 ? (The educational price I was quoted is significantly lower than this.) I believe the above system supports all Xilinx devices, not just the smaller ones. I have seen a demo, and was very impressed. I will probably order a copy, BUT I would like clarification of the dongle issue. Will the version I quoted (or the VHDL version XC-DS-FND-STV-PC1-C) work without a dongle apart from the ABEL component. This is important to me because most of the time I work with dismantled PCs(often without printer port to free up an extra expansion slot) and dongles are a BIG pain. John WallikerArticle: 3330
Eric Ryherd wrote: > > Anyone have experience with Exemplar and Xilinx 4013s where it > was only 80% utlilized but wouldn't route? > In synopsys language, I think I need to increase the "porocity" > of the design. I have other designs that are 90% and route, but > for some reason this one is real bad. > > The design in nearly completely random logic. only 42 DFFs. > I've tried all of the settings in Xilinx PPR, various seeds, max > place & route effort... I even tried PPR on some of > the less than optimal netlists from Exemplar. But still > won't route. > > Any options that might help??? > > We'll use the 4020 if we have too, but they're hard to get... > > The design is in VHDL. IOs are locked (don't get on my case here!!! > unlocking the IOs only goes from about 200 to 100 unroutes). > > I tried synthesizing with another synthesizer but it came up with 105% > utilization... Don't use the "ungroup" switch or command - that causes a very dense circuit which is nearly impossible to route. Try to use hierarchy, and maintain it throughout the compile. Maybe try structuring and multiple-output minimization to share logic elements (you get less logic). Or, alternatively, try the flatten feature, and see what that buys you. I was having similar problems with a 5215 design. Now that I'm routing, though, I can't seem to get acceptable timing. I found that the timing is incredibly placement sensitive, and PPR is not very good at placement, even with a high level of effort. You may be forced to use the floorplanner to come up with a more routable placement, and use the resulting LCA as a guidefile. This is not a pretty option, due to possible iterations of this step due to design changes, though. A major problem that I see is that to do a synthesis followed by a place and route takes about 6 hours for my design. That is too low a frequency to try playing with different options. I currently have a Xilinx AE helping me out to try to improve my timing. You may want to see if you can get similar help. Pat ________________________________________________________________________ Patrick McCabe | AT&T Paradyne mccabe@eng.paradyne.com | 8545 126th Ave. N., M/S LG133 Ph: 813/530-8776 FAX: 813/532-5244 | Largo, FL 34649-2826 ________________________________________________________________________ "Just because something doesn't do what you planned it to do doesn't mean it's useless." -- Thomas Edison. ________________________________________________________________________Article: 3331
As a part the finalizing PhD we are in Norway assigned a subject 14 days in
advance. In two weeks we shall collect available research publications and
give an overview of the subject for the Ph.D. committee. I have been
assigned the very interesting subject "Evolvable Hardware".
For this topic, partial programmable FPGAs are of main interest.
A. Thompson at Univ. of Sussex has evolved an oscillator on the new Xilinx
XC6200. Except for him I haven't heard about any other person evolving FPGA
configuration, that is the cells configuration is evolved by genetic
algorithm and not a human designer. I would like to know about other
researchers doing these kinds of experiments. Further, is there any other
devices than XC6200 or Atmel AT6000 which are partial reconfigurable?
Please email me as soon as possible and I will summarize to this newsgroup.
-Jim
Jim Toerresen # E-mail: jimtoer@idt.unit.no
Dept. of Computer Systems and Telematics # Tel: +47-73594458 (office)
The Norwegian Institute of Technology # Tel: +47-73886676 (home)
N-7034 Trondheim, NORWAY # Fax: +47-73594466 (office)
--
Jim Toerresen # E-mail: jimtoer@idt.unit.no
Dept. of Computer Systems and Telematics # Tel: +47-73594458 (office)
The Norwegian Institute of Technology # Tel: +47-73886676 (home)
N-7034 Trondheim, NORWAY # Fax: +47-73594466 (office)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The world is like a book, and if you never %
% leave home you only read one page. %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Article: 3332flxchen@diig.dlink.com.tw (Felix K.C. CHEN) wrote: >Dear Friends, >I got different synthesis results using Exemplar on the same logic but >with different default statements. At least in my example, >style 2 seems better than style 1 (I set constraint in area). >But I am not sure if it is a golden rule of coding style for >synthesis. Could any one say something about it? > (style 1) > when S0 => > case (event1 & event2) is > when "00" => > state <= S1; > when "01" => > state <= S2; > when others => > null; -- I suppose that it implies state <= S0; > end case; > when ........ IActually, this implies state <= state, which is different than state <= s0, thus the slightly different logic. I.E. if the events are not 00 or 01, then state remains unchanged, or in HW terms state <= state; The golden rule I always use is: When in doubt, code it out. If you aren't sure about what logic a particular syntax will code, then break it down into a simplier syntax you do know about and move on. That being said, you will find different tools are more efficient with some structures than with others. You''ll just have to use your tools and look at the logic it generates to figure this out (and yes, it can be painful). Steve Allen ASIC Design Consultant Clay Hill Engineering (www.ultranet.com/~allen) http://www.ultranet.com/~allen (My Pgp Public key available here)Article: 3333
In article <31973371.9233661@news.dial.pipex.com>
ft63@dial.pipex.com "Peter" writes:
"I have often looked at the AMD and Lattice parts. While their tools
"are indeed cheap, I ask myself "will these tools still be supported in
"a few years' time?". In the case of win3.x tools, the answer has to be
""no", because few people will still be running win3.x then, and
"American firms are generally very quick to dump "legacy" environments.
"So one ends up keeping an old PC in the corner somewhere, in case you
"have to revisit that project sometime in the future.
"
"But for someone with a very small budget, and more time to play
"around, these parts are probably the ideal solution.
"
You're doing AMD a great disservice here. They have always pioneered
low-cost software. Their current MACH-XL3 is an AMD-locked version
of MINC's PLDesignerXL software, which is also resold by Cadence,
Mentor and others. It's not about to go away or be unsupported.
MACH-XL 3 already runs under Windows 95. I believe the entry level
is under $500.
David Pashley
Article: 3334Jim Toerresen wrote: > > As a part the finalizing PhD we are in Norway assigned a subject 14 days in > advance. In two weeks we shall collect available research publications and > give an overview of the subject for the Ph.D. committee. I have been > assigned the very interesting subject "Evolvable Hardware". > > For this topic, partial programmable FPGAs are of main interest. > A. Thompson at Univ. of Sussex has evolved an oscillator on the new Xilinx > XC6200. Except for him I haven't heard about any other person evolving FPGA > configuration, that is the cells configuration is evolved by genetic > algorithm and not a human designer. I would like to know about other > researchers doing these kinds of experiments. Further, is there any other > devices than XC6200 or Atmel AT6000 which are partial reconfigurable? > > Please email me as soon as possible and I will summarize to this newsgroup. I think I heard that the Pilkington architecture (Motorola MPA) is partially reconfigurable. I could be wrong though! Regards, ScottArticle: 3335
Eric Ryherd wrote: > > Hi, > > Anyone have experience with Exemplar and Xilinx 4013s where it > was only 80% utlilized but wouldn't route? > In synopsys language, I think I need to increase the "porocity" > of the design. I have other designs that are 90% and route, but > for some reason this one is real bad. > ^^^^^^^^^^^^^^^ > The real problem here is that you have absolutely no feedback on what is hanging up the router. If PPR was to print the signal names which were failing to route, you could manually fix the problem, or at least have enough information to give up. I usually find that locating the major data path elements will make a "routable" design actually route. If the design is pretty much placed by the user, 4013s should route in an hour or less. I have never used the Xilinx floor planner, but it should allow you to get a handle on the design. If you don't have it, graph paper, pencil and eraser work fine. One way to get some feedback as to what is causing the problem is to look at the XDELAY file. Poorly routing signals will have large delays and many stages of buffering. Anything over 10 ns is suspicious. Always look at your routed design in XACT, just to get an idea of what you have really built. It can suprise you. Use the net highlighter to get a sense of the connectivity. It may be hard to believe, but even the simplist hand placement of the datapath elements will outperform the automatic placement tools. Place the datapath elements in adjacent columns and align the bits. Leave 2-4 rows of CLBs as a buffer for random logic between the IOBs and the datapath elements, and between rows of datapath logic. Always place bit 0 at the bottom. By datapath elements I mean logic which operates on words, as opposed to bits. If the design contains tristate lines, place every TBUF by hand. The auto placer does seem to do a fair job on really random spagetti logic such as (1hot) state machines and control, however (or at least as well as I can do by hand). Usually just locating the data paths will take a 5 hour 100 no route design to a 45 minute routed design. I'm just guessing but I'll bet the design has a lot of muxes, and these are causing the problem. If so, these are the best candidates for placement. If you do have muxes, you might consider using the tristate lines as muxes. Make sure your counters are using the hardware carry logic instead of gates. Make sure you are using Xilinx SRAM instead of synthesized RAM from logic. Use RPMs (Rlationally Places Macros)which have good local connectivity. Use 1 Hot state machines instead of encoded state machines. These suggestions probably won't apply to your problem, but they might be of general interest to others with routing problems. - BradArticle: 3336
Can anybody suggest me some good introductory book? Is there a FAQ on FPGA's?Article: 3337
>Sorry for the commercial, but I had to refute those obsolete postings. On the contrary, it is good to see vendors actually reading these messages, and (hopefully) taking note of any comments. Would you say you are a good contact about the latest situation on Xilinx products, in which case I will add you to my address book? Peter.Article: 3338
In article <4n9jbj@news-ipg.umds.ac.uk>, jrw@ipg.umds.ac.uk (J.Walliker) wrote: > Is this the same as the "Aldec Foundation standard software system" > part number XC-DS-FND-STD-PC1-C for which the list price is > UKP 3319.38 ? (The educational price I was quoted is significantly > lower than this.) I believe the above system supports all Xilinx > devices, not just the smaller ones. I have seen a demo, and > was very impressed. Well, here is the whole story: Yes, a good part of this software is Aldec-based, and you are not alone in being impressed by it. Foundation software comes in 5 flavors, and I had mentioned only one of them. The lowest-priced system, at US$ 495 supports only CPLDs. The "Foundation Base" system, at US$ 995 is the one I mentioned in my previous posting. It supports the lowerend FPGAs and all Xilinx CPLDs. "Foundation Base VHDL" adds Synthesis and X-BLOX for US$ 500 more. "Foundation Standard" at US$4995 supports all Xilinx devices, includes floorplanner, XACT desgn editor, but leaves out Synthesis, and it requires a dongel. "Foundation Standard VHDL" at US$ 5995 adds VHDL synthesis. All of these are "shrink-wrapped" complete solutions. They run on PCs under Windows v3.1. Versions for Win95 and Windows NT will be introduced later this year. End of sales talk. Peter Alfke, Xilinx ApplicationsArticle: 3339
Peter Alfke wrote:
>
> End of sales talk.
A guy asks for freeware/shareware and you're giving price quotes from US$
500-6000. Sheesh.
Unfortunately, I cannot offer a complete solution either. There is a glimmer
of hope, though. Alliance, a VHDL synthesis suite from the CAO-VLSI team at
MASI in France, can produce an XNF file, and it is free under the GPL.
Alliance runs on SunOS, Ultrix, and Linux, and you may be able to build it on
other Unixen.
Detes:
support e-mail : cao-vlsi@masi.ibp.fr
Users Mailing-list : alliance@masi.ibp.fr
ftp sites : ftp.ibp.fr /ibp/softs/masi/alliance (prefered)
: cao-vlsi.ibp.fr /pub/alliance
You still need place and route software to get to an LCA file and something
like makebits to get to a useable bitstream. Perhaps someone else knows of a
cheap/free way of doing the back-end stuff. Before you post, remember that
cheap in this context probably means cheap enough for hobby work. Not cheap
enough to get your boss to buy it for you. ;-)
--
Jeff Ebert
ebert@pobox.com
Article: 3340In article <DrCJ1M.FtI@alchemy.chem.utoronto.ca>, fbures@alchemy.chem.utoronto.ca (Frank Bures) writes... >In <4n26vb$jhv@news.mel.aone.net.au>, dgibson@microconsultants.com (David Gibson) writes: >>Steve Dewey <Steve@s-dewey.demon.co.uk> wrote: >> >> >>>Looking at the market, the Orcad PLD 386+ pld complier is the only one we can >>>afford. We already have Orcad schematic capture and PCB tools. >> >>>Does anyone out there have experience of this programable logic compiler ? >>>Can anyone compare it with other generic tools on the market? We do not want >>>to be tied into a single device vendor, but we might have to rethink if no one >>>is able to put in a good word for Orcad. >> >>Steve, we bought Orcad PLD 3-4 years ago. I found it very useful, and >>for the specific project we wanted it for it was very valuable. >> >>However, my experience is based only on programming smaller chips, >>specifically PEEL18CV8. How well Ordcad works on larger chips I cannot >>say. My main complaint about the one I bought is that it is a DOS >>package which will not run in a Win3.1x DOS window. It also *demanded* >>a non-Microsoft memory manager (I have Quemm 386) which makes the >>setup of my computer very precarious (i.e. I daren't change anything). >>If the version you are looking at is non-windows, be prepared to lock >>a machine in the past with it. (I could be off the mark here, as I've >>not kept my Orcad upgraded. I also *resent* buying a DOS product for >>over $3000 then being told some months later it is going to cost a >>bundle to convert to Win) > >OrCAD SDT, PCB and PLD 386+ run very well in a DOS session of OS/2. Absolutely >no problems as fas as the OS environment is concerned. > OrCAD SDT, PCB and PLD 386+ also run fine in a DOS session under Windows 95. You must have the newer OrCAD releases that use the PharLap DOS extender. >From what I have heard, the older releases using the Rational Systems DOS extender will not run in a DOS box under Windows 3x or 95. Daniel Lang dbl@hydra0.caltech.eduArticle: 3341
In article <3196EC89.20F@acte.no>, r@acte.no writes... >Peter wrote: > >> This is very bad, and sounds like some mid-1980s crappy DOS extender >> program. I have a 1994 version of SDT/386 which runs fine in a win3.x >> DOS box, regardless of memory manager (full screen only of course, >> being 1024x768 graphical) but not under NT. And who will be running >> 3.x in a few years' time? But I am very happy with this DOS product. >> It will always run, under DOS, long after win3.x is gone. > >Of course, it now doesn't work in the DOS mode of Windows 95. So, if you buy the >DOS version of OrCAD, expect it to fail if you upgrade your operating system. >Also, expect a lot of trouble with high-resolution display drivers if you plan >to use them. > The newer versions of SDT/PCB 386 using the Phar Lap DOS extender do run in the DOS mode of Windows 95 (full screen). The older versions used the Rational Systems DOS extender which does not run (from what I have heard) under Windows 3x or 95. Daniel Lang dbl@hydra0.caltech.eduArticle: 3342
Peter Alfke (peter@xilinx.com) wrote: : In article <4n9jbj@news-ipg.umds.ac.uk>, jrw@ipg.umds.ac.uk (J.Walliker) wrote: : : > Is this the same as the "Aldec Foundation standard software system" : > part number XC-DS-FND-STD-PC1-C for which the list price is : > UKP 3319.38 ? (The educational price I was quoted is significantly : > lower than this.) I believe the above system supports all Xilinx : > devices, not just the smaller ones. I have seen a demo, and : > was very impressed. : : Well, here is the whole story: : Yes, a good part of this software is Aldec-based, and you are not alone in : being impressed by it. : : Foundation software comes in 5 flavors, and I had mentioned only one of them. : : The lowest-priced system, at US$ 495 supports only CPLDs. : The "Foundation Base" system, at US$ 995 is the one I mentioned in my : previous posting. It supports the lowerend FPGAs and all Xilinx CPLDs. : "Foundation Base VHDL" adds Synthesis and X-BLOX for US$ 500 more. : "Foundation Standard" at US$4995 supports all Xilinx devices, includes : floorplanner, XACT desgn editor, but leaves out Synthesis, and it requires : a dongel. : "Foundation Standard VHDL" at US$ 5995 adds VHDL synthesis. : : All of these are "shrink-wrapped" complete solutions. : They run on PCs under Windows v3.1. : Versions for Win95 and Windows NT will be introduced later this year. : : End of sales talk. Please think about porting to other architectures by using some cross-development substitut for the windows libraries, e.g Willows Twin. See http://www.willows.com -- Uwe Bonnes bon@elektron.ikp.physik.th-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 3343
[ As always, to encourage debate and getting more feedback from fellow
engineers, here's a copy of "The Great ESDA Shootout" as it appeared in
Integrated System Design magazine two months ago in the April '96 issue.
(A lot of foreigners and academics can't get ISD magazine.) Check out
"comp.lang.verilog" or "comp.lang.vhdl" if you want to get the Verilog
or VHDL testbenches that were part of this shootout. - John ]
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / "The Great ESDA Shootout"
_] [_
by John Cooley
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Like clockwork, every few days or so I get requests out of the blue from
an engineer asking for the inside dirt on some EDA tool he's thinking of
buying. Usually it's not a problem because either I have personal
experiences to share or know what others are saying about various tools.
The one true blind spot has been in the ESDA industry. That is, other than
wildly varying stories from a mish-mash of early tool adopters and what
the ESDA marketeers have been claiming, there's been no real hard data on
these funky graphical-entry and so-called high level design tools like
Summit's Visual HDL, i-Logix's ExpressV, Mentor's System Architect, and
Speed's SpeedChart. When the people who run HP's Design SuperCon phoned
asking: "Is there any industry wide question that might make for an
interesting contest at our conference?", I knew doing a public ESDA
benchmark would fit the bill nicely. Hence the Great ESDA Shootout was born.
DESIGNING THE CONTEST
---------------------
Vividly remembering how much scrutiny last year's controversial Verilog vs.
VHDL contest went under, I wanted to do my best to create a contest that
was a fair comparision of ESDA tools. That is, I didn't want to create
a problem that intrinsically knocked out half of the ESDA vendors because
their tools couldn't handle, say, datapaths or counters too well. To find
out what would be fair for them, I phoned up each ESDA vendor, told them
I couldn't disclose exactly what would or would not be the problem to
solve in this 90 minute benchmark, and asked: "But, if you had your druthers,
what would you definitely want to see and not see in this shootout?"
Very quickly I had converged on the idea that the contest should consist of
hand-coding ASIC designers and ESDA vendors simultaneously working on the
same problem and we'd be comparing how long it took to intially enter a
design, how long it took to ECO a design, and finally the synthesis quality
of the generated/hand-coded Verilog or VHDL. I'd provide easy to use
diagnostic testbenchs at each stage for the contestants to use in both
Verilog and VHDL. Since chip operating speed is the big headache for 99.9%
of ASIC design in the commercial world, I decided the "winner" of this
benchmark would be the one whose design synthesized to the fastest speed.
Not wanting to deal with being accused of providing a Synopsys synthesis
script that wasn't optimal for a certain ESDA company's output, I decided to
let the ESDA companies put anyone on their design teams (like, for example,
a consulting Synopsys synthesis expert if needed) for any part of the
contest. For target technology, I chose LSI's 300K because it's a robust
library and a good typical large CMOS ASIC technology.
All I had to do then was fine tune the contest design problem by going
through an iterative process of calling the ESDA vendors out of the blue to
ask specific questions about their tools. "Can you handle concurrent state
machines? How about asynchronous resets? Mixed Mealy/Moore? Random
combinational logic? Up/down counters? Do you generate both Verilog and
VHDL? What flavor VHDL? Is is synthesizable?" Eventually I settled on
three concurrent state machines with asynchronous resets as shown bellow.
[ FOR CORRECT VIEWING OF THESE DIAGRAMS USE A MONOSPACED FONT. ]
reset = 1
--------. .-----------------------------------.
| | |
V V |
b = 1 ------ b = 0 |
.-----| 0000 |----------------. |
| ------ | |
V | |
c = 000 ------ | |
.---->| 0001 |-----. | |
| ------ | | |
| V V |
------ ------ ------ |
| 0010 | | 0011 |----------->| 0101 | |
------ ------ c != 101 ------ |
^ | | c = 011 |
| | V |
| ------ | ------ |
a = 0 '-----| 0100 |<----' | 0110 | |
& b = 1 ------ c = 101 ------ |
| | |
'-------. .------------------' |
a = 1 | | |
| | |
V V |
b = 1 ------ b = 0 |
.-----| 1000 |----------------. |
| ------ | |
V | |
c = 000 ------ | |
.---->| 1001 |-----. | |
| ------ | | |
| V V |
------ ------ ------ |
| 1010 | | 1011 |----------->| 1101 | |
------ ------ c != 101 ------ |
^ | | c = 011 |
| | V |
| ------ | ------ |
a = 0 '-----| 1100 |<----' | 1110 | |
& b = 1 ------ c = 101 ------ |
| | |
'-------. .------------------' |
a = 1 | | |
V V |
------ |
| 1111 |---------------------------------'
------
"state"
reset = 1 reset = 1
| |
V V
---- d = 1 ---- e = 1
.------->| 00 |------. .------->| 00 |------.
| ---- | | ---- |
| ^ V | ^ V
| | ---- | | ----
| d = 1 | | 01 | | e = 1 | | 01 |
| | ---- | | ----
| ---- | | ---- |
| | 10 |<-----' | | 10 |<-----'
| ---- state = 1000 | ---- state = 0000
| | | |
| d = 0 | | e = 0 |
| V | V
| ---- | ----
'--------| 10 | '--------| 10 |
---- ----
"dstate" "estate"
fig 1.) Three concurrent state machines ( "state", "dstate", and "estate")
as the original design entry problem. Note: the transition from
01 to 10 in "dstate" and "estate" depends on the current state
value of "state".
=====================================================================
estate f g | h
-------------------------------------
01 0 1 | 1
otherwise X X | 0
state f g | i
-------------------------------------
0101 0 1 | 1
1010 0 1 | 1
otherwise X X | 0
fig 2.) Asynchronous outputs based on the current state of "state" and
"estate". "f" and "g" are asynchnous inputs; "h" and "i" are
asynchronous outputs.
PLEASE NOTE: If you're going to try this contest on your own you're supposed
to finished the original design shown in figures 1 & 2 BEFORE even looking
at the ECO version of the design here bellow in figure 3! (No fair
cheating!) Also, because of ASCII limitations its kind of hard to highlight
stuff. That is, during the contest these changes were shown with a
florescent green marker making it far more obvious what had changed and
what hadn't changed. You just can't do this in ASCII! (Sorry!)
[ FOR CORRECT VIEWING OF THESE DIAGRAMS USE A MONOSPACED FONT. ]
reset = 1
%%%%%%%%%.
|
V
%%%%%%
.---%%%%%%%%------% 0010 |<--%%%%%--.
| %%%%%% |
V |
b = 1 ------ b = 0 |
.-----| 0000 |------------------------. |
| ------ | |
V %%%%%% | |
------ %% e = 0 %% .%%-->| 0111 % | |
.---->| 0001 |-----. % %%%%%% | |
% ------ | % % | %
% V % V | %
% ------ % ------ | %
% | 0011 |%%%%%%' | 0101 |<--' %
% ------ c != 101 ------ %
% | | c = 011 %
% | V %
%%%% % ------ | ------ %
% a = 0 '-----| 0100 |<----' | 0110 | %
% & b = 1 ------ c = 101 ------ |
% & c = 000 | | |
%%%%%%%%%%%% '-------. .------------------' |
a = 1 | | |
| | |
V V |
b = 1 ------ b = 0 |
.-----| 1000 |----------------. |
| ------ | |
V | |
c = 000 ------ %% d = 1 %% | |
.---->| 1001 |-----. | |
| ------ | | |
| V V %
------ ------ c != 101 ------ %
| 1010 | | 1011 |%%%%%. | 1101 | %
------ ------ % ------ %
^ | % | c = 011 %
| | % V %
| ------ | % ------ %
a = 0 '-----| 1100 |<----' '----->| 1110 | %
& b = 1 ------ c = 101 ------ |
| | |
'-------. .------------------' |
a = 1 | | |
V V |
------ |
| 1111 |------%%%%%%%%%%%%%%%%%%---------'
------
"state"
reset = 1
|
V
---- %% b = 0 %% ---- e = 1
.------->| 00 |------. .------->| 00 |------.
| ---- | | ---- |
| % V | ^ V
| %%% % ---- | | ----
| %b = 1 % | 01 | | e = 1 | | 01 |
| %%% V ---- | | ----
| ---- | | ---- |
| | 10 | % | | 10 |<-----' %%%%
| ---- % state = 1000 | ---- state = 0010%
| | % | | %%%%%%%%%%
| d = 0 | % | e = 0 |
| V % | V
| ---- % | ----
'--------| 10 |<---%%' '--------| 10 |<--%%%%%%---
---- ---- reset = 1
"dstate" "estate"
fig 3.) Three concurrent state machines ( "state", "dstate", and "estate")
as the ECO-ed design problem. NOTE: All changes from figure 1
are highlighted with "%%%".
FEAR AND LOATHING
-----------------
Oh, brother, little did I know what a hornet's nest I was stirring up with
the probing questions. Escalade bailed out claiming they weren't ported
to HP's yet, but they could compete if they could use a SUN workstation
(which ain't going to happen at an HP conference!) Upon hearing this, many
of Escalade's competitors laughed saying: "They've been on HP's for 18
months; they're just wimping out." Vista Technologies said they were out of
the ESDA business and into the hardware/software co-design business instead.
ViewLogic politely declined and later I heard a rumor it was because most of
the people who knew anything about ViewFSM had left the company. Synopsys
wanted me change the contest problem into some sort of vague behavioral form
so their Behavioral Compiler could win the day by cleverly juggling states.
(Sorry, this isn't a behavioral synthesis benchmark, it's a graphical entry
and simulation benchmark.) I also got to go through three long days of
negotiations with Synopsys to get the use of Design Compiler. "There won't
be any other synthesis tools used in this contest? This isn't a thinly
disguised synthesis benchmark is it? We don't allow that you know." At the
same time I was being beaten up by the Synplicity people who wanted to enter
their synthesis tool into the contest.
Mentor Graphics put me through the most hell by insisting that I rewrite the
VHDL testbench (twice) in an extremely generic form because they wanted to
use their non-standard QuickVHDL. They tried to get me to permit them to use
their Autologics II synthesis tool. (Sorry, this was an ESDA benchmark; not
a synthesis benchmark.) I found out they were secretly trying to talk all
the other ESDA vendors into boycotting the competition and, to top it off,
they dropped out of the contest the four days before it was going to happen!
Fed up, I called their CEO, Wally Rhines, told him that it appears that fear
and paranoia by his ESDA group was going to make his company conspicously
absent from an industry wide benchmark. Wally, not pleased, said: "Hmmm....
That's not the philosophy I'm trying to foster here. Winning or losing a
benchmark is completely different than running away from one. You can't be
a player if you don't compete. I'll see what I can do." (Two days later,
Mentor was back into the contest.)
OPENING NIGHTMARES
------------------
Beyond the crisis of getting 40 workstations up, running and fully networked
together at the Santa Clara Convention center, it was a logistics nightmare
getting 14 major EDA products from 9 different vendors installed. Because
only the AE's from each vendor were the only people who knew anything about
installing their own software, it was a mob scene of people loading tapes,
tweaking stuff, overwriting ".cshrc" files and then hashing it out with the
other vendors who later on overwrote the ".cshrc" file again! Fierce duals
over licence servers, environment variables and disk space constantly broke
out. It got pretty scary when 10 minutes before the contest began we still
weren't certain if we'd have Synopsys Design Compiler, critical for this
contest, up and running on all the machines. The contest came within 2
minutes of becoming a Synplicity synthesis based!
Also, like a fool, the night before the contest I thought I'd be a clever boy
by doing some last minute changes on the design problem. This meant changes
to the test vectors, too. When done, I egotistically thought: "Finished in
just a few hours doing it in both Verilog and VHDL! Damn, I'm good!" It
was during the opening part of the actual competition where I got to
personally relearn how God likes to enforce his "Pride Commith Before The
Fall" rule for people who suffer from occassional bouts of bigheadedness like
myself. I had just explained what the design problem and was showing the
contestants the template that they were to put their designs in (so they
could run in the testbench) when suddenly someone chirped up that the port
list for the template and the testbench instantiation of it were very
different. Yikes! I forgot to update the template lastnight! AAAAAAH!
So, I got to go through 40 highly embarassing minutes in front of 30 miffed
contestants and 80 or so wispering onlookers, as I nervously fix both the
Verilog and VHDL testbenches before we could officially start the contest.
(OK, God, I got the message!) Just to make sure I learned my lesson, midway
through an easily corrected typo was discovered in the design data sheet.
(Two states were mistakenly shown to have had the same state assignment
"0110" yet in real life one was "0110" and the other was "0111". Easily
corrected but scary!)
WINNERS AND LOSERS
------------------
After the personally embarrassing start to the contest, the rest went fairly
well from my point of view and somewhat mixed from other people's point of
view (depending on how they were doing.) We got the normal attrition rate
of having three engineers panic and walk out once the contest started.
Knowledge Based Systems was the only ESDA vendor who said they were coming,
installed their software, and then failed to have a team at the competition.
Turns out the guy who installed the software had to present a paper during
the competition and the rest of their team was away doing a customer
benchmark.
Original Design Time ECO Design Time Gate Level Timing (nsec)
-------------------- --------------- ------------------------
22:14 Rich Weber/SGI 7 Summit Design 1.77 Hoai Tran/Symbios
26:57 Brian Korguth/TI 11 Hoai Tran/Symbios 2.09 i-Logix
32:54 Summit Design 12 Mike Moody/TI 2.31 Speed Electronic
40:45 Greg Ward/Nortel 13 Rich Weber/SGI 2.46 Rich Weber/SGI
50:25 Hoai Tran/Symbios 15 Speed Electronic 2.58 Kurt Baty/ind.
51:51 Kurt Baty/ind. 15 Greg Ward/Nortel 2.61 John Gilbert/Moto
52:47 Kam Kittrell/TI 16 Kam Kittrell/TI 2.63 Greg Ward/Nortel
57:00 John Gilbert/Moto 18 John Gilbert/Moto 2.94 Bob Painter/ind.
59:52 Mike Moody/TI 20 Brian Korguth/TI 3.16 Brian Korguth/TI
62:51 i-Logix 22 Bob Painter/ind. 3.23 Summit Design (VHDL)
74:32 Speed Electronics 28 Kurt Baty/ind. 3.38 Kam Kittrell/TI
147:30 Bob Painter/ind. 35 i-Logix 3.41 Summit Design (Verilog)
167:24 Mentor Graphics 43 Mentor Graphics 4.25 Mentor Graphics
fig. 4) Original design entry, Engineering Change Order (ECO) and
synthesis results for each contestant. (Design and ECO
times are in units of minutes.)
Overall, 13 out of the 17 design teams completed the contest successfully
with 9 of these being hand coders. There were only two VHDL based hand
coders in the contest: Nortel's Greg Ward (who ranked midway overall in the
competition) and one of the failed-to-completely-finish people; otherwise
everyone used Verilog. One guy, an independent consultant named Bob
Painter, struck me as kind of odd because he seemed to be spending
an awful lot of time reading a Verilog design article that he had clipped
from "ASIC & EDA" magazine. He also was asking me quite a few questions
about how to use "vi". It turned out that he had never used Verilog, "vi"
or synthesis before, yet, after 147 minutes (going way beyond the contest's
90 minute time limit) he managed to successfully create functionally correct
Verilog with ECO's and synthesized it such that it ranked overall right
behind Greg Ward, the sole successful VHDL based designer! Afterwards I
dubbed Bob Painter as the "Miracle Man" because I was so impressed with his
courage to go into a public design competition without knowing the tools and
then toughing it out to completion. Whoa!
MENTOR GRAPHICS
---------------
I was surprized at the beginning of the contest to not only see the Mentor
Graphics team but also their CEO, Wally Rhines, standing there to provide
"moral support." It's not every day you see the CEO of a 2,000 person
company showing up at a highly technical function! (And I couldn't help but
wonder what it was like to be on the Mentor team nervously trying to
create and synthesize a design while your boss's boss's boss's boss's boss
was watching you.) once the contest got going in earnest, though, Wally
left. Ninety minutes later, when the contest was supposed to have been
completed, Wally came back and hung around for the remaining extra 77 minutes
it took his team to finish the competition, though. It was really sad.
Overall, Mentor got blown away. They came in absolute dead last in every
catagory: design entry time, ECO time and synthesis results. Even "Miracle
Man" Bob Painter, the guy who had never used Verilog or "vi" or Design
Compiler, readily beat Mentor! It was sad.
Post competition interviews yielded that some pilot error in their overall
methodology hurt them plus some flaws in System Architect itself. Instead
of exporting their created design's VHDL and then running the testbench
independently of System Architect, they reported spending 45 minutes
struggling to get the testbench into System Architect. Other pilot error
was misinterpreting some of the specs and using the pre-ECO test vectors on
the post-ECO design causing all sorts of chaos. Three of the System
Architect specific problems were the overhead of having to create context
diagrams and user-defined enumerated types; having to find a workaround
because "state", a reserved word for them, was used in the contest testbench,
and System Architect is designed to handle and manage all the massive
complexities of large, top-down designs instead of tiny state minutes.
That is, they felt they would have kicked butt if the contest consisted
of juggling 100 different state machines with large imported blocks of VHDL
and 14 levels of hierarchy like what we find in real design projects. (The
problem is, it's hard enough to get people to compete in a 90 minute contest,
trying to get them to do it for three weeks is a bit much to ask!)
I-LOGIX
-------
One of the major frustrations I had with running the contest was as the judge
I had to force myself to not stop people from doing obviously stupid things
because they didn't plan for ECO's. When I explained the initial design
problem to the contestants, I pointed out the symetry between the top half
and botton half of the 15 state FSM in figure 1. The i-Logix team liked this
so much they reimplemented it as one 8 state FSM plus one register keeping
track of when they were in the top half or bottom half of the original
specified 15 state FSM. This was quick, clever and very much a mistake for
them because when the ECO's came in (figure 3), the top half and bottom half
were no longer symetric meaning they had to redo their whole design! Their
VP of Engineering, a good friend, ripped into me with full anger shouting
"But you specifically pointed out this symetry at the beginning of the
contest!!! This is unfair!" while one of his Apps Engineers was
simultaneously wispering to me: "Ignore him! He doesn't mean that. It's OK.
We're OK. He doesn't mean that."
Later on, when i-Logix came in with the best synthesized results for an
ESDA vendor and in second place overall, the i-Logix VP was too happy to
be concerned. "OK. So you got us by specifying the design in a tricky
way. What counts is that we blew everyone away with our final results after
redoing the design three times! We won! We won! We won!" (I chuckled
and reminded him how he contracted me two years ago to help him change how
i-Logix was writing out it's Verilog and VHDL. This was because his
customers were howling that i-Logix generated code was synthesizing to big
fat, slow gate level designs.)
SUMMIT DESIGN
-------------
Other than one hand-coder using Synplicity's special language based editor
and one other speed typing hand-coder using "vi", Summit Design cleaned
house in the design entry and ECO part of the design contest. Why I say
this is that during the design entry part of the contest they had a core
dump because there wasn't enough swap space to simultaneously run their
tool and Synopsys Design Analyzer thus scewing up their initial design
entry time. The ECO time proudly speaks for itself, giving them a full
50 minutes to run Design Compiler. And that was their downfall.
What happened was pilot error using Synopsys managed to transmorgrofy their
nice single piece of source VHDL into three subparts that couldn't be
reglued back together because of VHDL's strong type checking and the use
of the type "buffer" on the subpart's ports. Essentially, they got caught
trying to be too clever using Synopsys and it bit them bigtime. They
realized later on that if they had used Verilog instead (which doesn't have
strong type checking) they wouldn't have been bitten using Synopsys. As
judge, to get their synthesis results I took their machine generated source
code and did only a single default Synopsys compile on it.
SPEED ELECTRONICS
-----------------
The Speed team approached the design by making three completely separate
concurrent state machine in anticipation of upcoming ECO's plus knowing it
would give them better results in synthesis (which is what I specified as
being the most important criteria for this contest.) This meant a hit on
their design entry and ECO time, but they didn't care because they felt
they'd win with better synthesizable final code.
And VHDL bit them, too! Again, it was the port type "buffer" that got them
because their tool converted it to type "inout" which consequently caused
their code to choke in the testbenches that were expecting port type
"buffer" instead of type "inout"! In retrospect their VP of Engineering
said: "We should have used Verilog because we wouldn't have run into stupid
type checking problems. Also, we're going to fix that automatic "buffer"
to "inout" type conversion bug the moment we get back to the office."
The other clever approach was that they used Synopsys's FSM Compiler. You've
got to understand that as the guy who runs the E-mail Synopsys Users Group,
for years the entire customer base has been badmouthing FSM Compiler so much
that none of the experienced users use it any more. To most of the customer
base it's seen as one of those bogus features that don't really work. Well,
to my and Kurt Baty's (who helped in the post contest analysis) surprize,
the winner (Hoai Tran of Symbios Logic) and the third place team (Speed
Electronics) had used FSM Compiler instead of plain old Design Compiler that
99% of the planet is using. Even Richard Weber of SGI (the guy who was using
Synplicity's language based editor to enter the design so quickly) who had
a liesurely 55 minutes to use Design Compiler for a variety of multiple
synthesis runs still only landed forth place overall. What this tells me is
that perhaps it's time that I and the rest of the Synopsys user community
took another look at FSM Compiler...
BANANA CURVES
-------------
One of the first lessons that any synthesis student is taught in using
Synopsys is the gate area to design performance banana curve. That is,
if you synthesize a design to be small, chances are it'll fairly slow;
if you synthesize a design to be fast, chances are it'll have a large
gate count. Figure 4 illustrates this point. Because the judging
criteria for this contest was that whoever produces Verilog or VHDL that
synthesizes to the fastest design wins, all of the ESDA Vendors have been
making wild claims that if they had more time in the contest to synthesize
their designs they would have done exponentially better. But, looking
at the data with Kurt Baty after the contest, we were surprized to find
that all the ESDA generated code followed one banana curve while virtually
all of the hand crafted Verilog or VHDL design followed another, far better
banana curve. Kurt summarized with: "In my mind, this calls into serious
question whether the ESDA generated code could ever synthesize to a faster
design. Your starting point on the banana curve has a huge impact on how
far you can move on it. I don't think Mentor's slow 4.25 nsec design could
be synthesized to Hoai Tran's hot 1.77 nsec design. It's much easier to move
to a better speed going up the flat hand-code banana curve than the steeper
ESDA code banana curve." After fitting the second order polynomial to match
each banana curve we saw in the data and then linearly projecting to Hoai
Tran's 490 gate hand-coded time of 1.77 nsec, we estimated that if ESDA
generated code could be synthesized the same speed, it would be around 1041
gates.
ONLY MENTOR WAS WOUNDED
-----------------------
The week following the Great ESDA Shootout, EE Times ran an article titled
"ESDA Wounded During Shootout." Although I agree most of the written article,
I disagree with its title and what it implies. Looking at the results of
the contest clearly tells me that ESDA tools are definitely up to snuff for
some types of designs. In synthesizable results, two out of the top three
contenders were ESDA vendors (i-Logix and Speed Electronics). Summit didn't
do well in synthesis because it tried to be too clever and got lost as a
result. For initial design entry time, Summit and Synplicity's language
based editor ranked in the top three; Speed Electronics and i-Logix got
caught up VHDL traps and misunderstanding the spec respectively. For ECO
time, Summit kicked butt and Speed Electronic did well even after getting
caught on VHDL type checking traps. i-Logix did a complete redesign during
that time!
The only ESDA company that got hurt was Mentor Graphics because they took a
distant last place in every catagory -- even compared to a guy who has never
even used Verilog, synthesis or "vi" before! But they had serious pilot
error and a few nasty workarounds to find like dealing with "state" being a
reserved word for them. Also, having your CEO looking over you during a
contest might turn your typing fingers to cigars and your brain to mush.
At the post contest panel discussion when polled, 12 engineers said they
won't consider the use of ESDA tools for their projects, 8 said they would,
and 28 said they're interested in language based editor's like Synplicity's.
Also some hand coders in the audience said this problem was handed to the
ESDA Vendors on a silver platter in its bubble chart form and not something
you had to do a lot of design thinking on, but I disagreed because I wanted
to measure ESDA tools performance, not the ability to figure out a tricky
state machine from a vague word description. Overall I think this contest
validated that ESDA tools can do as good, if not better than most hand coding
designers for small state machines. But it's just one data point.
E-mail me what *you* think about this so I can put in my next column!
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 4374 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 3344
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / Verilog Testbenches for The Great ESDA Shootout
_] [_
by John Cooley
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Here's a copy of the two testbenches plus vector files for those who want
to try for themselves the Great ESDA Shootout from the recent HP Design
SuperCon. To get the details of the contest, read the current issue of
"Integrated System Design" magazine (it's in the April '96 issue which was
mailed out to readers last week.)
To run the first testbench:
UNIX>verilog machine3.v tester3.v -i vector_file3.vec
To run the Post-ECO testbench:
UNIX>verilog machine4.v tester4.v -i vector_file4.vec
For those who try this contest at home: I'd like to hear how you do!
For those who don't try but want to comment on the Shootout after reading
about it, I'd like to hear what you have to say, too!
- John Cooley
the ESNUG guy
----------- template.v ---------------------------------------------------
module machine (a, b, c, state, clock, reset, d, e, dstate, estate, f, g, h, i);
input a, b, d, e, clock, reset, f, g;
input [0:2] c;
output h, i;
output [0:3] state;
reg [0:3] state;
output [0:1] dstate, estate;
reg [0:1] dstate, estate;
// put your design in here and relabel the file "machine3.v" !!!!
endmodule
----------- tester3.v ----------------------------------------------------
//
// "tester3.v" -- the Verilog testbench for use at the HP Design Supercon's
// Great ESDA Shootout for testing "machine3.v" using "vector_file3.vec"
//
module tester ();
reg a, b, d, e, clock, reset, f, g;
reg [0:2] c;
wire h, i;
wire [0:3] state;
wire [0:1] dstate, estate;
reg [0:19] t_vec;
reg [0:9] george_out;
reg [0:19] test_vectors [0:46];
integer int;
// load up the 45 20-bit test vectors & test the design
initial
begin
$readmemb("vector_file3.vec", test_vectors);
reset = 1'b0;
@(negedge clock);
for (int = 0; int < 47 ; int = int + 1)
begin
t_vec = test_vectors[int];
{a, b, c, d, e, f, g} = {t_vec[0:4], t_vec[10:11], t_vec[16:17]};
reset = t_vec[9];
@(negedge clock);
george_out = { state, dstate, estate, h, i };
if ( {t_vec[5:8], t_vec[12:15], t_vec[18:19]} == george_out )
begin
$display("\t\t INPUTS BEFORE posedge CLOCK reset = %b", reset);
$display("\t\t were: a = %b", a, " b = %b ", b, " c = %b ", c);
$display("\t\t d = %b", d, " e = %b ", e, " f = %b ", f, " g = %b ", g);
$display("\t\t AFTER posedge CLOCK: state = %b", state, " dstate = %b", dstate,
" estate = %b", estate, " h = %b ", h, " i = %b ", i);
$display("\t Cool! Just what I expected! \t\t Sim Time = %t", $time, "\n");
end
else
begin
$display("\n\t ****** BAD NEWS, DUDE! ***********");
$display("\t\t INPUTS BEFORE posedge CLOCK reset = %b", reset);
$display("\t\t were: a = %b", a, " b = %b ", b, " c = %b ", c);
$display("\t\t d = %b", d, " e = %b ", e, " f = %b ", f, " g = %b ", g);
$display("\t\t AFTER posedge CLOCK: state = %b", state, " dstate = %b", dstate,
" estate = %b", estate, " h = %b ", h, " i = %b ", i);
$display("\t\t I EXPECTED: state = %b", t_vec[5:8], " dstate = %b", t_vec[12:13],
" estate = %b", t_vec[14:15], " h = %b ", t_vec[18], " i = %b ", t_vec[19]);
$display("\n\t ... check your state flow, dude. \t\t Sim Time = %t", $time, "\n");
$finish;
end
end
$display("\n ###### CONGRATS! -- THIS IS A FUNCTIONALLY CORRECT DESIGN!!!! ###### \n\n");
$finish;
end
// create clock
initial clock = 1'b0;
always #50 clock = !clock;
// instantiate design to be tested
machine george (a, b, c, state, clock, reset, d, e, dstate, estate, f, g, h, i);
endmodule
----------- vector_file3.vec ---------------------------------------------
X0XXX00001XX00000000
X0111010100100001001
XX000010100100001100
XX010010101001011001
XX01101100XX01010000
XXXXX10000XX01010000
XXXXX00001XX00000000
X1XXX000100100000000
X0XXX001101001010110
XX10101000XX01011000
01XXX00100XX01010000
XX11100100XX01011100
XX00000010XX01010110
XXXXX00110XX01010000
XX01101010XX01011001
XXXXX00001XX00000100
X1XXX000101001010000
XXXXX00110XX01010000
XX10101000XX01010000
11XXX10000XX01010000
X0XXX11010XX10010000
XX000110100X11010000
XX01111100XX00010000
XXXXX111100X00010000
XXXXX000001X01010000
X0XXX01010XX01100000
XX01101100X101110000
XXXXX10000XX01000000
X1XXX10010X010010000
XXXXX101101X00010000
XX101110000X00010000
00XXX110001X01010000
01XXX10100XX01011001
XX10010100XX01010110
XX00010010XX01010000
XXXXX10110XX01010000
XX10111000XX01010000
1XXXX11110XX01010000
XXXXX00000XX01010000
X0XXX01010XX01100000
XX01101100X001000000
XXXXX10000X101000000
X1XXX100100010010000
XXXXX101101X00010000
XX011110101X01010000
XXXXX00001XX00000000
XXXXX00001XX00000000
----------- tester4.v ----------------------------------------------------
//
// "tester4.v" -- the Verilog testbench for use at the HP Design
// Supercon's Great ESDA Shootout for testing the *post-ECO*
// "machine4.v" using "vector_file4.vec"
//
module tester ();
reg a, b, d, e, clock, reset, f, g;
reg [0:2] c;
wire h, i;
wire [0:3] state;
wire [0:1] dstate, estate;
reg [0:19] t_vec;
reg [0:9] george_out;
reg [0:19] test_vectors [0:44];
integer int;
// load up the 45 20-bit test vectors & test the design
initial
begin
$readmemb("vector_file4.vec", test_vectors);
reset = 1'b0;
@(negedge clock);
for (int = 0; int < 45 ; int = int + 1)
begin
t_vec = test_vectors[int];
{a, b, c, d, e, f, g} = {t_vec[0:4], t_vec[10:11], t_vec[16:17]};
reset = t_vec[9];
@(negedge clock);
george_out = { state, dstate, estate, h, i };
if ( {t_vec[5:8], t_vec[12:15], t_vec[18:19]} == george_out )
begin
$display("\t\t INPUTS BEFORE posedge CLOCK reset = %b", reset);
$display("\t\t were: a = %b", a, " b = %b ", b, " c = %b ", c);
$display("\t\t d = %b", d, " e = %b ", e, " f = %b ", f, " g = %b ", g);
$display("\t\t AFTER posedge CLOCK: state = %b", state, " dstate = %b", dstate,
" estate = %b", estate, " h = %b ", h, " i = %b ", i);
$display("\t Cool! Just what I expected! \t\t Sim Time = %t", $time, "\n");
end
else
begin
$display("\n\t ****** BAD NEWS, DUDE! ***********");
$display("\t\t INPUTS BEFORE posedge CLOCK reset = %b", reset);
$display("\t\t were: a = %b", a, " b = %b ", b, " c = %b ", c);
$display("\t\t d = %b", d, " e = %b ", e, " f = %b ", f, " g = %b ", g);
$display("\t\t AFTER posedge CLOCK: state = %b", state, " dstate = %b", dstate,
" estate = %b", estate, " h = %b ", h, " i = %b ", i);
$display("\t\t I EXPECTED: state = %b", t_vec[5:8], " dstate = %b", t_vec[12:13],
" estate = %b", t_vec[14:15], " h = %b ", t_vec[18], " i = %b ", t_vec[19]);
$display("\n\t ... check your state flow, dude. \t\t Sim Time = %t", $time, "\n");
$finish;
end
end
$display("\n ###### CONGRATS! -- THIS IS A *Post-ECO* CORRECT DESIGN!!!! ###### \n\n");
$finish;
end
// create clock
initial clock = 1'b0;
always #50 clock = !clock;
// instantiate design to be tested
machine george (a, b, c, state, clock, reset, d, e, dstate, estate, f, g, h, i);
endmodule
----------- vector_file4.vec ---------------------------------------------
XXXXX00101XX00110000
X0XXX00000XX01000000
X1XXX00010X101000000
XXXXX00010X101001100
XXXXX00110X001010110
XX10101000XX01011000
1XXXX10000XX01010110
X1XXX10010XX11011100
XXXXX100100X00010000
X1XXX101101X10011100
X1101110001X10011000
01XXX101001X10011001
XX101101000X11010000
XX00010010XX00011000
X0XXX100100X01011000
XXXXX101101X01011000
XX01111100XX01011000
XXXXX11110XX01011000
XXXXX00100XX01011000
XXXXX00000XX01100100
X1XXX00010X001000100
XXXXX00110X001011000
XX10101000XX01011000
0111001000XX01011000
0000001000XX01011000
0101001000XX01011000
0100000010XX01011000
XXXXX00110X001011000
XX10001110XX01011000
XXXXX01010XX01011001
XX11001010XX01010000
XX01101100XX01011000
XXXXX10000XX01011000
X0XXX11010XX11011000
XX10011010XX00011000
X001111100XX01011000
XXXXX11110XX01011000
XXXXX00100XX01011000
XXXXX00000XX01101000
X0XXX01010X101111001
XXXXX00101XX00111000
XXXXX00101XX00111000
XXXXX00101XX00111000
XXXXX00101XX00111000
XXXXX00101XX00111000
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 4126 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 3345
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / VHDL Testbenches for The Great ESDA Shootout
_] [_
by John Cooley
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Here's a copy of the two testbenches plus vector files for those who want
to try for themselves the Great ESDA Shootout from the recent HP Design
SuperCon. To get the details of the contest, read the current issue of
"Integrated System Design" magazine (it's in the April '96 issue which was
mailed out to readers last week.)
To run the first testbench using Cadence Leapfrog:
UNIX>cv -m machine3.vhd tester3.vhd
UNIX>ev -m work.tester:foo
UNIX>sv -b -run work.tester:foo
To run the Post-ECO testbench:
UNIX>cv -m machine4.vhd tester4.vhd
UNIX>ev -m work.tester:foo
UNIX>sv -b -run work.tester:foo
For those who try this contest at home: I'd like to hear how you do!
For those who don't try but want to comment on the Shootout after reading
about it, I'd like to hear what you have to say, too!
- John Cooley
the ESNUG guy
----------- template.vhd -------------------------------------------------
library ieee, std;
use std.textio.all;
use ieee.std_logic_1164.all;
entity machine is
port ( a, b : in std_logic;
c : in std_logic_vector(0 to 2);
state : buffer std_logic_vector(0 to 3);
clock : in std_logic;
reset : in std_logic;
d, e : in std_logic;
dstate : buffer std_logic_vector(0 to 1);
estate : buffer std_logic_vector(0 to 1);
f, g : in std_logic;
h, i : out std_logic);
end machine;
architecture gooby of machine is
begin
-- Put your design in here and relabel it "machine3.vhd" !!!!!
end gooby;
----------- tester3.vhd --------------------------------------------------
--
-- "tester3.vhd" -- the VHDL testbench for use at the HP Design Supercon's
-- Great ESDA Shootout for testing "machine3.vhd" using "vector_file3.vec"
--
library ieee, std;
use std.textio.all;
use ieee.std_logic_1164.all;
-- use work.all;
entity tester is
end tester;
architecture foo of tester is
function stdvc_2_str (inp : std_logic_vector ) return string is
variable temp : string(1 to inp'right+1);
begin
for i in inp'range loop
if (inp(i) = '1' ) then
temp(i+1) := '1';
elsif (inp(i) = '0' ) then
temp(i+1) := '0';
else
temp(i+1) := 'X';
end if;
end loop;
return temp;
end;
function str_2_stdvc (inp : string ) return std_logic_vector is
variable temp : std_logic_vector(0 to inp'right-1);
begin
for i in inp'range loop
if (inp(i) = '1' ) then
temp(i-1) := '1';
elsif (inp(i) = '0' ) then
temp(i-1) := '0';
else
temp(i-1) := 'X';
end if;
end loop;
return temp;
end;
function std_2_str (inp : std_logic ) return string is
variable temp : string(1 to 1);
begin
if (inp = '1' ) then
temp(1) := '1';
elsif (inp = '0' ) then
temp(1) := '0';
else
temp(1) := 'X';
end if;
return temp;
end;
component machine
port ( a, b : in std_logic;
c : in std_logic_vector(0 to 2);
state : buffer std_logic_vector(0 to 3);
clock : in std_logic;
reset : in std_logic;
d, e : in std_logic;
dstate : buffer std_logic_vector(0 to 1);
estate : buffer std_logic_vector(0 to 1);
f, g : in std_logic;
h, i : out std_logic);
end component;
for all : machine use entity work.machine(gooby);
signal a, b : std_logic := 'X';
signal c : std_logic_vector(0 to 2) := "XXX";
signal state : std_logic_vector(0 to 3) := "XXXX";
signal clock : std_logic := 'X';
signal reset : std_logic := 'X';
signal d, e : std_logic := 'X';
signal dstate : std_logic_vector(0 to 1) := "XX";
signal estate : std_logic_vector(0 to 1) := "XX";
signal f, g : std_logic := 'X';
signal h, i : std_logic := 'X';
signal done : std_logic := '0';
begin
process
file test_vectors : text is in "vector_file3.vec";
variable t_vec_line : line;
variable t_vec_str : string(1 to 20);
variable t_vec : std_logic_vector(0 to 19);
variable george_out : std_logic_vector(0 to 9);
variable george_expected : std_logic_vector(0 to 9);
variable tmp_state : std_logic_vector(0 to 3);
variable tmp_dstate : std_logic_vector(0 to 1);
variable tmp_estate : std_logic_vector(0 to 1);
variable tmp_h, tmp_i : std_logic;
variable fileline : line;
begin
reset <= '0';
wait until clock = '0' and clock'event;
while (not endfile(test_vectors)) loop
readline (test_vectors, t_vec_line);
read (t_vec_line, t_vec_str);
t_vec := str_2_stdvc(t_vec_str);
a <= t_vec(0);
b <= t_vec(1);
c <= t_vec(2 to 4);
d <= t_vec(10);
e <= t_vec(11);
f <= t_vec(16);
g <= t_vec(17);
tmp_state := t_vec(5 to 8);
tmp_dstate := t_vec(12 to 13);
tmp_estate := t_vec(14 to 15);
tmp_h := t_vec(18);
tmp_i := t_vec(19);
reset <= t_vec(9);
wait until clock = '0' and clock'event;
george_out := ( state & dstate & estate & h & i);
george_expected := ( t_vec(5 to 8) & t_vec(12 to 15) & t_vec(18 to 19));
if ( george_expected = george_out ) then
assert false
report
" INPUTS BEFORE positive edge of CLOCK reset = " &
std_2_str(reset) & lf &
" were: a = " & std_2_str(a) & " b = " & std_2_str(b) & " c = " &
stdvc_2_str(c) & lf &
" d = " & std_2_str(d) & " e = " & std_2_str(e) &
" f = " & std_2_str(f) & " g = " & std_2_str(g) & lf &
" AFTER positive edge of CLOCK: state = " & stdvc_2_str(state) &
" dstate = " & stdvc_2_str(dstate) & " estate = " &
stdvc_2_str(estate) & " h = " & std_2_str(h) & " i = " & std_2_str(i) & lf &
" Cool! Just what I expected! " & lf
severity note;
else
assert false
report
"************** BAD NEWS, DUDE! *************" & lf &
" INPUTS BEFORE positive edge of CLOCK reset = " &
std_2_str(reset) & lf &
" were: a = " & std_2_str(a) & " b = " & std_2_str(b) &
" c = " &
stdvc_2_str(c) & lf &
" d = " & std_2_str(d) & " e = " & std_2_str(e) &
" f = " & std_2_str(f) & " g = " & std_2_str(g) & lf &
" AFTER positive edge of CLOCK: state = " & stdvc_2_str(state) &
" dstate = " & stdvc_2_str(dstate) & " estate = " &
stdvc_2_str(estate) & " h = " & std_2_str(h) & " i = " &
std_2_str(i) & lf &
" I EXPECTED: state = " &
stdvc_2_str(tmp_state) &
" dstate = " & stdvc_2_str(tmp_dstate) &
" estate = " & stdvc_2_str(tmp_estate) &
" h = " & std_2_str(tmp_h) &
" i = " & std_2_str(tmp_i) & lf &
" ... check your state flow, dude. " & lf
severity failure;
done <= '1';
end if;
end loop;
assert false
report lf & lf &
" ###### CONGRATS! -- THIS IS A FUNCTIONALLY CORRECT DESIGN!!!! ###### "
& lf & lf
severity failure;
done <= '1';
end process;
process -- clock generation
begin
while ( done = '0' ) loop
clock <= '1';
wait for 50 ns;
clock <= '0';
wait for 50 ns;
end loop;
end process; -- clock generation
george : machine
port map ( a, b, c , state, clock, reset, d, e, dstate, estate, f, g, h, i);
end foo;
----------- vector_file3.vec ---------------------------------------------
X0XXX00001XX00000000
X0111010100100001001
XX000010100100001100
XX010010101001011001
XX01101100XX01010000
XXXXX10000XX01010000
XXXXX00001XX00000000
X1XXX000100100000000
X0XXX001101001010110
XX10101000XX01011000
01XXX00100XX01010000
XX11100100XX01011100
XX00000010XX01010110
XXXXX00110XX01010000
XX01101010XX01011001
XXXXX00001XX00000100
X1XXX000101001010000
XXXXX00110XX01010000
XX10101000XX01010000
11XXX10000XX01010000
X0XXX11010XX10010000
XX000110100X11010000
XX01111100XX00010000
XXXXX111100X00010000
XXXXX000001X01010000
X0XXX01010XX01100000
XX01101100X101110000
XXXXX10000XX01000000
X1XXX10010X010010000
XXXXX101101X00010000
XX101110000X00010000
00XXX110001X01010000
01XXX10100XX01011001
XX10010100XX01010110
XX00010010XX01010000
XXXXX10110XX01010000
XX10111000XX01010000
1XXXX11110XX01010000
XXXXX00000XX01010000
X0XXX01010XX01100000
XX01101100X001000000
XXXXX10000X101000000
X1XXX100100010010000
XXXXX101101X00010000
XX011110101X01010000
XXXXX00001XX00000000
XXXXX00001XX00000000
XXXXX00001XX00000000
XXXXX00001XX00000000
XXXXX00001XX00000000
XXXXX00001XX00000000
----------- tester4.vhd --------------------------------------------------
--
-- "tester4.vhd" -- the VHDL testbench for use at the HP Design
-- Supercon's Great ESDA Shootout for testing the *post-ECO*
-- "machine4.vhd" using "vector_file4.vec"
--
library ieee, std;
use std.textio.all;
use ieee.std_logic_1164.all;
-- use work.all;
entity tester is
end tester;
architecture foo of tester is
function stdvc_2_str (inp : std_logic_vector ) return string is
variable temp : string(1 to inp'right+1);
begin
for i in inp'range loop
if (inp(i) = '1' ) then
temp(i+1) := '1';
elsif (inp(i) = '0' ) then
temp(i+1) := '0';
else
temp(i+1) := 'X';
end if;
end loop;
return temp;
end;
function str_2_stdvc (inp : string ) return std_logic_vector is
variable temp : std_logic_vector(0 to inp'right-1);
begin
for i in inp'range loop
if (inp(i) = '1' ) then
temp(i-1) := '1';
elsif (inp(i) = '0' ) then
temp(i-1) := '0';
else
temp(i-1) := 'X';
end if;
end loop;
return temp;
end;
function std_2_str (inp : std_logic ) return string is
variable temp : string(1 to 1);
begin
if (inp = '1' ) then
temp(1) := '1';
elsif (inp = '0' ) then
temp(1) := '0';
else
temp(1) := 'X';
end if;
return temp;
end;
component machine
port ( a, b : in std_logic;
c : in std_logic_vector(0 to 2);
state : buffer std_logic_vector(0 to 3);
clock : in std_logic;
reset : in std_logic;
d, e : in std_logic;
dstate : buffer std_logic_vector(0 to 1);
estate : buffer std_logic_vector(0 to 1);
f, g : in std_logic;
h, i : out std_logic);
end component;
for all : machine use entity work.machine(gooby);
signal a, b : std_logic := 'X';
signal c : std_logic_vector(0 to 2) := "XXX";
signal state : std_logic_vector(0 to 3) := "XXXX";
signal clock : std_logic := 'X';
signal reset : std_logic := 'X';
signal d, e : std_logic := 'X';
signal dstate : std_logic_vector(0 to 1) := "XX";
signal estate : std_logic_vector(0 to 1) := "XX";
signal f, g : std_logic := 'X';
signal h, i : std_logic := 'X';
signal done : std_logic := '0';
begin
process
file test_vectors : text is in "vector_file4.vec";
variable t_vec_line : line;
variable t_vec_str : string(1 to 20);
variable t_vec : std_logic_vector(0 to 19);
variable george_out : std_logic_vector(0 to 9);
variable george_expected : std_logic_vector(0 to 9);
variable tmp_state : std_logic_vector(0 to 3);
variable tmp_dstate : std_logic_vector(0 to 1);
variable tmp_estate : std_logic_vector(0 to 1);
variable tmp_h, tmp_i : std_logic;
variable fileline : line;
begin
reset <= '0';
wait until clock = '0' and clock'event;
while (not endfile(test_vectors)) loop
readline (test_vectors, t_vec_line);
read (t_vec_line, t_vec_str);
t_vec := str_2_stdvc(t_vec_str);
a <= t_vec(0);
b <= t_vec(1);
c <= t_vec(2 to 4);
d <= t_vec(10);
e <= t_vec(11);
f <= t_vec(16);
g <= t_vec(17);
tmp_state := t_vec(5 to 8);
tmp_dstate := t_vec(12 to 13);
tmp_estate := t_vec(14 to 15);
tmp_h := t_vec(18);
tmp_i := t_vec(19);
reset <= t_vec(9);
wait until clock = '0' and clock'event;
george_out := ( state & dstate & estate & h & i);
george_expected := ( t_vec(5 to 8) & t_vec(12 to 15) & t_vec(18 to 19));
if ( george_expected = george_out ) then
assert false
report
" INPUTS BEFORE positive edge of CLOCK reset = " &
std_2_str(reset) & lf &
" were: a = " & std_2_str(a) & " b = " & std_2_str(b) & " c = " &
stdvc_2_str(c) & lf &
" d = " & std_2_str(d) & " e = " & std_2_str(e) &
" f = " & std_2_str(f) & " g = " & std_2_str(g) & lf &
" AFTER positive edge of CLOCK: state = " & stdvc_2_str(state) &
" dstate = " & stdvc_2_str(dstate) & " estate = " &
stdvc_2_str(estate) & " h = " & std_2_str(h) & " i = " & std_2_str(i) & lf &
" Cool! Just what I expected! " & lf
severity note;
else
assert false
report
"************** BAD NEWS, DUDE! *************" & lf &
" INPUTS BEFORE positive edge of CLOCK reset = " &
std_2_str(reset) & lf &
" were: a = " & std_2_str(a) & " b = " & std_2_str(b) &
" c = " &
stdvc_2_str(c) & lf &
" d = " & std_2_str(d) & " e = " & std_2_str(e) &
" f = " & std_2_str(f) & " g = " & std_2_str(g) & lf &
" AFTER positive edge of CLOCK: state = " & stdvc_2_str(state) &
" dstate = " & stdvc_2_str(dstate) & " estate = " &
stdvc_2_str(estate) & " h = " & std_2_str(h) & " i = " &
std_2_str(i) & lf &
" I EXPECTED: state = " &
stdvc_2_str(tmp_state) &
" dstate = " & stdvc_2_str(tmp_dstate) &
" estate = " & stdvc_2_str(tmp_estate) &
" h = " & std_2_str(tmp_h) &
" i = " & std_2_str(tmp_i) & lf &
" ... check your state flow, dude. " & lf
severity failure;
done <= '1';
end if;
end loop;
assert false
report lf & lf &
" ###### CONGRATS! -- THIS IS A *Post-ECO* CORRECT DESIGN!!!! ###### "
& lf & lf
severity failure;
done <= '1';
end process;
process -- clock generation
begin
while ( done = '0' ) loop
clock <= '1';
wait for 50 ns;
clock <= '0';
wait for 50 ns;
end loop;
end process; -- clock generation
george : machine
port map ( a, b, c , state, clock, reset, d, e, dstate, estate, f, g, h, i);
end foo;
----------- vector_file4.vec ---------------------------------------------
XXXXX00101XX00110000
X0XXX00000XX01000000
X1XXX00010X101000000
XXXXX00010X101001100
XXXXX00110X001010110
XX10101000XX01011000
1XXXX10000XX01010110
X1XXX10010XX11011100
XXXXX100100X00010000
X1XXX101101X10011100
X1101110001X10011000
01XXX101001X10011001
XX101101000X11010000
XX00010010XX00011000
X0XXX100100X01011000
XXXXX101101X01011000
XX01111100XX01011000
XXXXX11110XX01011000
XXXXX00100XX01011000
XXXXX00000XX01100100
X1XXX00010X001000100
XXXXX00110X001011000
XX10101000XX01011000
0111001000XX01011000
0000001000XX01011000
0101001000XX01011000
0100000010XX01011000
XXXXX00110X001011000
XX10001110XX01011000
XXXXX01010XX01011001
XX11001010XX01010000
XX01101100XX01011000
XXXXX10000XX01011000
X0XXX11010XX11011000
XX10011010XX00011000
X001111100XX01011000
XXXXX11110XX01011000
XXXXX00100XX01011000
XXXXX00000XX01101000
X0XXX01010X101111001
XXXXX00101XX00111000
XXXXX00101XX00111000
XXXXX00101XX00111000
XXXXX00101XX00111000
XXXXX00101XX00111000
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 4126 other
users dealt with it ? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
Article: 3346
Dear friends,
I want to make the VHDL synthesizer (Synopsys's Design compiler
or Galileo's Logic Explorer) infer multiplexor. I do not want
to use design ware (or modgen) in component instantiation
style. Can any one tell me is there any difference in the
results of synthesis between the two codes:
process(SEL, INP_A, INP_B, INP_C, INP_D) -- INPs is 32 bit bus each
begin
case SEL
when "00" =>
OUTP <= INP_A;
when "01" =>
OUTP <= INP_B;
when "10" =>
OUTP <= INP_C;
when others =>
OUTP <= INP_D;
end case;
end process;
with SEL select
OUTP <= INP_A when "00",
INP_B when "01",
INP_C when "10",
INP_D when others;
As I know that most FPGA vendors provide multiplexor hard macro
up to 4->1, I do not know how smart synthesizer can be for
inferring multiplex functions with input number larger than 4?
Any comment?
By the way, from my experience, Exemplar's Galileo seems not infer
MX4 macro for the codes above when targeting Actel DX32000.
The evidence is that the synthesis gate count is much
larger than (32 * MX4 + possible fan-out buffers for SEL).
Perhaps I have made mistakes, but I am really frustrated.
Regards,
Felix K.C. CHEN
--
---------------------------------
Felix, Kuan-chih CHEN (³¯ «a §Ó)
Associate Project Manager
System Product Division
D-Link Co., Hsin-chu, Taiwan
Email: flxchen@diig.dlink.com.tw
Machines and tools are only as
good as the people who use it.
---------------------------------
Article: 3347
Got a question for the guru's here...
A project I am working on takes some C code, translates it
to VHDL, and is supposed to implement the function on a
FPGA chip.
I have an assortment of Altera hardware, max+plus, and the
programming unit.
I also have some C to HDL converters however for Xilinx and
possilby an Altera 8000 chip.
What I'd like to do, just to test and see if the C to HDL
conversion works is be able to put the FPGA chip either on
an IBM PC based ISA, PCI, or even an independent "breadboard"
arrangement.
Yup, have called the companies, called their sales offices,
and even scoured the web pages and books for information however
it's scanty on the subject.
Has anyone out there who has actually done anything similar please
let me know how you did it? Your experience, contacts, and directions
on where possibly a good kit to use would be so valuable. I've been
searching for months for info on how to actually go about and do this
without much luck, scratching my head quite a bit, and gasping at the
Xilinx "plug and play" implementation <grin>.
Desperate Student in the Midwest who needs to graduate with this, running
out of time! If you can point me in the right direction, you are a god!
Thanks :)
Aaron
Article: 3348Jeffrey Ebert wrote: > > Peter Alfke wrote: > > > > End of sales talk. > > A guy asks for freeware/shareware and you're giving price quotes from US$ > 500-6000. Sheesh. As there appears to be no freeware/shareware software to place and route Xilinx parts (or Altera parts, or AT&T parts or Actel parts or QuickLogic parts or Atmel parts or ...), I see nothing wrong with Peter informing the fellow about the range of price points for Xilinx tools. Regards, ScottArticle: 3349
rauletta@erebor.cudenver.edu (Richard J. Auletta) wrote: >Has anyone used the Xilinx XACT 6.0 tools with Windows NT or >run Cypress Warp 2 or 3 tools (with Workview Office) with Windows NT? > >Any experiences or warnings welcome :) > >TIA > >-Rich Auletta > University of Colorado Denver > Have you checked out the Altera Max+Plus2 tool? MP2 is Windows 95 and Windows NT compatible right out of the box. Nice GUI interface as well. Regards...Grason
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