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
Hul Tytus <htytus@iglou1.iglou.com> wrote: : Anyone know of a SCSI-1 host adapter for the PC ISA buss for which a : listing of the control & data ports and their functions is available? Guess you should take a look at Fujitsu's offerings with online docs: http://www.fujitsumicro.com/products/network/iointer.html : Thanks -- Hul @@htytus@iglou.com@@ -- Geir Frode Raanes Omega Verksted, NTNU geirfrs@invalid. e d . n t n u . n oArticle: 8076
From several discussions going on in the comp.arch.fpga group it seems that implementing a Target/Initiator PCI bus interface with FPGA's is very difficult. I have also been told that choosing the right ASIC solution (AMCC, PLX, etc.) is not easy too. For this reason I would like to collect designers' opinion on specific custom ASIC chips and post a summary, hoping there is enough interest. thanks in adavnce -Arrigo -- Arrigo Benedetti o e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 < > phone: (626) 395-3695 Pasadena, CA 91125 / \ fax: (626) 795-8649Article: 8077
Victor Levandovsky wrote: > > I`m looking for a State Machine > basics material in Internet. > > Could you help me, please? There is a very good series of articles on state machine design at: http://www.summit-design.com/products/vcd/center/page01.html -- Alasdair Maclean, Development Engineer, GEC Marconi Electro-Optics Ltd., GNET: 709-5711; Tel: +44 (0)131 343 5711 Fax: +44 (0)131 343 5050 Email: <mailto:alasdair.maclean@gecm.com>Article: 8078
Mark de Wit wrote:
>
> Hi people,
>
> I'm looking for dynamically reprogrammable FPGA's, like the Xilinx XC6200
> series. I need to be able to manipulate individual cells and routing
> during run-time. Also, I'm looking to maximise the number of I/O pins. Is
> the XC6200 the only viable option for me?
>
A few years ago, Xilinx made a lot of noise about many new FPGA product
lines, then they quietly never followed through in producing several of
them. Isn't the xc6200 series one of those families?
--
=====================================================================
William Lenihan lenihan3we@earthlink.net
"The greatest barrier to communication is the delusion that
it has already occurred." -- Peter Cummings
=====================================================================
Article: 8079Dear Atmel users, if there are any out there, I have been using a oneshot design for about 2 years without giving it much consideration. It consist of two D flipflops, an Inverter, and an AN2 gate. I -> AN2 -> ^ ^ ->FD ->FD It takes up 4 cells, is fairly flexible in configuration. It goes positive for one clock cycle on a rising edge. It may glitch, I haven't the equipment to really tell. Anybody got any new ideas? Brad SmallridgeArticle: 8080
Brad Smallridge wrote:
>
> Dear Atmel users, if there are any out there,
>
> I have been using a oneshot design for about 2 years
> without giving it much consideration. It consist of
> two D flipflops, an Inverter, and an AN2 gate.
>
> I -> AN2 ->
> ^ ^
> ->FD ->FD
>
> It takes up 4 cells, is fairly flexible in configuration.
> It goes positive for one clock cycle on a rising edge.
> It may glitch, I haven't the equipment to really tell.
> Anybody got any new ideas?
well,
while i've used many a counter based one-shot in designs, the
easiest one i've used only requires one flip/flop. the 'd' input is tied
to vcc, or may be used as an enable. the clock input is the trigger. the
'q' is routed to one of the i/o pins, and the 'reset' is also handled
this way. connect a cap from the 'reset' pin to ground, and connect a
resistor from 'q' pin to the 'reset' pin. also place a 1n4148 type diode
in parallel to the resistor, cathode to the 'q' pin, and anode to the
'reset' pin.
of course this is not a retriggerable type one shot, but you can
implement it in anything, even a 16v8, and replacing the resistor with a
pot makes it adjustable. if your worried about accuaracy due to
variations in the threshold voltage of the 'reset' pin, there are tricks
to implement a schmitt trigger using a couple resistors, and output
pins....
its a shame we get into such a digital mind set that we forget how
cost effective, and elegant it is to add some passives to programmable
logic to implement some desighs.
_______________________________________________________________________
Bob Engle rengle@ix.netcom.com
Embedded Solutions
Orlando, Florida FPGA and MPU contract engineering
_______________________________________________________________________
"I will not be pushed, filed, stamped, indexed, briefed, de-briefed
or numbered. My life is my own...." The Prisoner
_______________________________________________________________________
Article: 8081I have to write a paper about FPGA and I know nothing about it Please help send sites papers anythingArticle: 8082
Reda Roushdy El-Masry <reda.el-masry@usa.net> writes:
>I have to write a paper about FPGA and I know nothing about it
>Please help
>send sites
>papers
>anything
Quite an interesting position to be in. Check out web sites for
the following companies. They have FGPA, EPLDs, PALs, etc..
Xilinx
Lucent
Altera
AMD (now I think Vantis is their FPGA daughter)
Cypress
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 8083
Hi,
I'm using Synopsys in school and want to use the Xilinx Logiblox. How can
simulate them? Currently I create them with the M1 software on a Windows
machine and export the edn file. This file I include in Synopsys which
runs on a Unix machine. I tell Synopsys not to touch these files. That
should work fine, but also causes some trouble. It seems to me that the
Logiblox are not implemented at all. Simulation I can do currently only
after mapping an routing with the M1 tool.
Can somebody point me to information about this subject.
Thank you very much in advance,
Jens
--------------------------------------------------------
Jens-Peter Kaps, Cryptography and Computer Security Lab
ECE Department, Worcester Polytechnic Institute, USA
Phone: (508) 831-5757; Fax: (508) 831-5491
--------------------------------------------------------
Article: 8084What is the difference between CPLD and FPGA ? Thanks -- Jean-Paul RICAUD jpricaud@club-internet.frArticle: 8085
The links to http://www.optimagic.com/faq.html#What_Kinds and http://www.optimagic.com/comparison.html on The Programmable Logic Jump Station should help answer your question. You may find other material on The Programmable Logic Jump Station of interest. It can be found at http://www.optimagic.com. ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Jean-Paul Ricaud wrote in message <01bcf2ee$c10b1b00$e4679ec2@club-internet.club-internet.fr>... >What is the difference between CPLD and FPGA ? > >Thanks >-- > >Jean-Paul RICAUD >jpricaud@club-internet.fr >Article: 8086
You may find some information for your paper on The Programmable Logic Jump Station at http://www.optimagic.com . It's a fairly comprehensive set of links to other relative sites. Some of the more basic information is under development on the Frequently-Asked Questions page (http://www.optimagic.com/faq.html). ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Reda Roushdy El-Masry wrote in message <346F601B.CF18C1E3@usa.net>... >I have to write a paper about FPGA and I know nothing about it >Please help >send sites >papers >anything > > >Article: 8087
Brad Smallridge wrote: > > Dear Atmel users, if there are any out there, > > I have been using a oneshot design for about 2 years > without giving it much consideration. It consist of > two D flipflops, an Inverter, and an AN2 gate. > > I -> AN2 -> > ^ ^ > ->FD ->FD > > It takes up 4 cells, is fairly flexible in configuration. > It goes positive for one clock cycle on a rising edge. > It may glitch, I haven't the equipment to really tell. > > Anybody got any new ideas? > > Brad Smallridge Works for me, except it pulses on a falling edge! I got a macro in my library called fedet (falling edge detect) that is essentially what you got there. Registering the incoming signal as you do does a reasonable job synchronizing it in the atmel. (the metastability window is very short). If you are dealing with a synchronous signal you can ditch the left flop unless it helps in keeping the clock rate up (pipelining the wires works wonders in the AT6k for those of you not familiar). If it is async, it may be a good idea to put a second flop on the input to decrease the probability of ametastable upset. You can get to two cells (w/o the input sync ff) if you use an FDN and an AN2, with the added benefit of the input being capable of either color or a bus input. +---+ +---+ ->|FDN|-red->|AN2|->red or blue | |-blu->| | +---+ +---+ I assumed you are looking for a rising edge detect, not a one-shot multivibrator in the classic sense. SOmeone posted a follow-up recommending using external passives which I certainly don't advocate. First, use of monostable multivibrators in digital design is sloppy and imprecise (you wind up being subject to analog tolerances, more difficult debug, higher parts count and unreliable operation). Using the clock as a logic input as he suggests also raises your susceptability to noise. The asynchronous nature of such a design also greatly complicates your timing analyses and will probably result in very placement sensitive design in an FPGA (especially in the AT6K). In the case of the Atmel AT6K, his scheme wastes the registers in a whole column (56 cells in a AT6005, 80 in an AT6010), since each column has a shared reset and clock, not to mention using several i/o pins which could probably be put to better use. The schmitt trigger trick he mentioned is useful in a pinch, but it is not as good as a purpose designed schmtt trigger (the trick is to use a pair of resistors and an output driven by the input on your device. the resistors form a voltage divider that shifts the input threshold depending on the level of the feedback leg). For those not familiar with the AT6K line, it is an SRAM based FPGA containing an array of fine grain logic cells (56x56 for AT6005, 80x80 for the At6010). Each cell is basically a half adder with a flip flop on the sum output and some simple gating to permit function as a multiplexer or some simple 2 or 3 input functions. Each cell has direct connections to each of the four nearest neighbors (NSEW) and connections to a local bus network grid. The bus segments run 8 cells and connect to the sext segment through a repeater. Careful design in these parts will yield clock rates to around 125 MHz (been there done that...see the high performance bit serial paper on my website). -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 8088
You'll find a paper, "FPGA and CPLD Architectures: A Tutorial", at: http://www.vcc.com/papers/brown.pdf / Jonas Thor Reda Roushdy El-Masry wrote: > I have to write a paper about FPGA and I know nothing about it > Please help > send sites > papers > anythingArticle: 8089
CALL FOR PAPERS
1998 International Symposium on Physical Design (ISPD-98)
April 6-8, 1998, Embassy Suites Hotel, Monterey, CA
Sponsored by ACM SIGDA in cooperation with
IEEE Circuits and Systems Society and IEEE Computer Society
The International Symposium on Physical Design provides a forum to exchange
ideas and promote research on critical areas related to the physical design
of VLSI systems. All aspects of physical design, from interactions with
behavior- and logic-level synthesis, to back-end performance analysis and
verification, are within the scope of the Symposium. Target domains include
semi-custom and full-custom IC, MCM and FPGA based systems. The ACM/SIGDA
Physical Design Workshop evolved into this Symposium last year and was very
well-attended. Following its six predecessors, the 1998 symposium will
highlight key new directions and leading-edge theoretical and experimental
contributions to the field. Accepted papers will be published by the ACM Press
in the Symposium proceedings. Topics of interest include but are not limited to:
Management of design data and constraints
Interactions with behavior-level synthesis flows
Interactions with logic-level (re-)synthesis flows
Analysis and management of power dissipation
Techniques for high-performance design
Floorplanning and building-block assembly
Estimation and point-tool modeling
Partitioning, placement and routing
Special structures for clock, power, or test
Compaction and layout verification
Performance analysis and physical verification
Physical design for manufacturability and yield
Mixed-signal and system-level issues
Physical design in parallel, distributed and Web environments
IMPORTANT DATES: Submission deadline December 5, 1997
Acceptance notification January 26, 1998
Camera-ready paper due February 23, 1998
SUBMISSION OF PAPERS:
Authors should submit full-length, original, unpublished papers (maximum 20
pages double spaced) along with an abstract of at most 200 words and contact
author information (name, street/mailing address, telephone/fax, e-mail).
Previously published papers or papers submitted for publication to other
conferences/journals will not be considered. Electronic submission via
uuencoded e-mail is encouraged and is the preferred submission mode. Please
email a single postscript file, formatted for 8 1/2" x 11" paper, compressed
with Unix "compress" or "gzip" to
ispd98@cs.utexas.edu
Alternatively, you may send ten (10) hardcopies of the paper to:
Prof. D.F. Wong, Technical Program Chair, ISPD-98
University of Texas at Austin, Department of Computer Sciences,
Austin, TX 78712, USA
SYMPOSIUM INFORMATION:
To obtain information regarding the Symposium or to be added to the Symposium
mailing list, please send e-mail to ispd98@ee.iastate.edu. The ISPD web page
is at http://www.ee.iastate.edu/~ispd98
SYMPOSIUM ORGANIZATION:
General Chair: M. Sarrafzadeh (Northwestern)
Past Chair: A. Kahng (UCLA)
Steering Committee: J. Cohoon (Virginia), S. DasGupta (IBM),
M. Marek-Sadowska (UCSB), B. Preas (Xerox),
E. Yoffa (IBM)
Program Committee: M. Alexander (WA State) C.-K. Cheng (UCSD)
J. Cong (UCLA) W. Dai (UC Santa Cruz)
J. Fishburn (Lucent) D. D. Hill (Synopsys)
J. A. G. Jess (Eindhoven) L. Jones (Motorola)
S. Kang (Illinois) Y.-L. Lin (Tsing Hua)
M. Pedram (USC) R. Rutenbar (CMU)
C. Sechen (Washington) M. Wiesel (Intel)
D. F. Wong (Texas), Chair T. Yoshimura (NEC)
Publication Chair: D. D. Hill (Synopsys)
Panel Chair: N. Sherwani (Intel)
Local Chair: R.-S. Tsay (Axis Systems)
Publicity Chair: S. Sapatnekar (Minnesota)
Treasurer: S. Souvannavong
Article: 8090I posted a copy of the article "Modern Digital Design for the Radio Amateur" in my homepage at the following - http://members.aol.com/johnw39038/index.htm It is from the December issue of the American Radio Relay League's technical publication, QEX. It details an Altera FPGA designed using VHDL and synthesized with Synopsys. It is a fairly simple DDS & display controller application & is meant mostly for beginners in VHDL & FPGA technology. Have fun... J.W. ======================================================== John Wiseman Senior Researcher Hitachi America, Ltd., Digital Media Systems Laboratory Princeton, NJ Email: johnw@dmsl.hitachi.com Voice: (609)-520-0071 ext. 18 Fax: (609)-520-8953 Amateur Radio: KE3QG ========================================================Article: 8091
On Sun, 16 Nov 1997 16:33:42 -0500, Jens-Peter Kaps <kaps@wpi.edu> wrote: >Hi, > >I'm using Synopsys in school and want to use the Xilinx Logiblox. How can >simulate them? Currently I create them with the M1 software on a Windows >machine and export the edn file. This file I include in Synopsys which >runs on a Unix machine. I tell Synopsys not to touch these files. That >should work fine, but also causes some trouble. It seems to me that the >Logiblox are not implemented at all. Simulation I can do currently only >after mapping an routing with the M1 tool. > >Can somebody point me to information about this subject. > When you run Logiblox, you need to tell it to create a simulation model (that may be the default.) I'm using VHDL, and it nicely generates a behavioural model for the RAMs I am using. You need to have those models in your search path. Note: these models are not for synthesis by Synopsys. The .ngo files that Logiblox generates are the input to the M1 tools. Jason P.S. You might also want to check out Xilinx's web site for help. There is loads of information, some of which might even relate to to your question. :-] >Thank you very much in advance, > > Jens > > -------------------------------------------------------- > Jens-Peter Kaps, Cryptography and Computer Security Lab > ECE Department, Worcester Polytechnic Institute, USA > Phone: (508) 831-5757; Fax: (508) 831-5491 > -------------------------------------------------------- >Article: 8092
Hi, We have an opportunity for an individual who has done some complex Circuit Board/FPGA design to work at a place where cutting edge technology is the norm, and one of the very best design staffs in the country awaits. This position is for someone who has between 3-10 years of high performance custom circuit design under his/her belt. You will be working on some of the "neatest" projects you've ever seen, and will become a stellar hardware designer for your efforts. Some of the "buzz": We are looking for High Speed Digital Designers, having some experience with PLD's, FPGA's (ASICS), complex designs (nothing simple at this place), understands timings, etc... Not a person who still needs a lot of instruction, we are hoping to find an individual who can stand alone and bring a project in from scratch to production. This is a great company! Our guarantee is this: If you go in and chat with these people, you WILL want to work there, especially if you can do this type of work. They are located on the North side of Chicago, near Skokie or Evanston, just off the Kennedy. Salary will be very nice, they're not cheap, as they're looking for the best we can bring in. Please E-mail or Fax us at: Hunter International E-mail: cleaner@starnetinc.com Fax: (815)356-9225 Thanks, Dave...Article: 8093
Hi, We're Hunter International, and we are currently looking for qualified DSP based Engineering Professionals from a broad variety of disciplines. Our client is one of, if not THE, best firms you could be associated with in the Northern California area. This beautiful firm, located in the Silicon Valley, is simply at the top of it's class with opportunities and care for it's employees. The benefits are second to none, and the technology is stellar, so you can't go wrong. There is even a fully functioning Health Club built into the premises! We absolutely guarantee that you will be thrilled with this firm if you are qualified! PLEASE note before you read further: This company is a publicly held, incredibly successful firm, BUT, because of certain clients, they do require the ability to secure a Secret Clearance. This means citizenship of you, and your direct family to Mother and Father, if they are still living. Because of this, the candidate pool becomes thin. So if you are qualified, AND can get clearance, you will be received with enthusiasm and given the 'red carpet' treatment, as they need engineers in a big way! In an effort to help with the massive growth they are experiencing, we need to find Engineers who fall into the areas of expertise listed below. The descriptions are intentionally brief, and this is because the amount of available jobs are more than you could read through in a single post. All jobs are new positions, not vacancies. Software Engineers: *Experience developing Real-Time, software intensive projects using Ada, C, C++, in a UNIX, NT, and/or VMS environment. *Requirements definition, preliminary/detailed design code/unit testing and software integration. *Familiarity with OO methodologies, signal processing, telecommunications, distributed systems, GUI builders, reusable software, relational data bases and automated test tools. *Looking for a BS/MS, CS or Math, or equivalent. Experience much more important than degree! DSP Engineers: *Lead, or be a part of, a multi-functional team working on digital/ DSP/communications subsystems utilizing state of the art design/analysis tools/techniques and modern packaging. Responsibilities may include: Participate in architectural and design trades, generate hardware and software specifications, simulate/evaluate DSP algorithm, design digital circuits used in standard and custom interfaces and micro-processor based designs, design high speed digital logic, develop/code DSP firmware, implement custom DSP hardware using PLD/FPGA, and test and integrate the hardware in the subsystem. *Languages: C or C++ in a UNIX environment, with knowledge of Windows NT a plus. Also, knowledge of high speed digital logic, Modem/PLL Datacom products, embedded control firmware, custom DSP hardware implementation, ASIC design and methodology a plus. Hardware Engineer: *Serve as Technical Leader for small to medium sized projects. Coordinate technical efforts of small engineering project teams. *Perform high level system design. Develop algorithms for key communication functions. Define architecture for state of the art communication products. *MSEE with emphasis on Communications theory and DSP. Minimum of 5 years of related experience. Experience with SPW, Xilinx, and Viewlogic design tools. Please also consider that we need Systems Engineers, Intelligence Engineers, a variety of Systems Administrators, and Directors also. The descriptions above are only general! There are multiple openings in every area, and the expertise varies from position to position, so please don't hesitate should you feel there might be a match! Again, this IS a fantastic company! You will not be wasting your time if you decide to respond, and ALL qualified candidates WILL be responded to very quickly. Thank you for making it this far, and we hope to hear from you soon! Contact us at: Hunter International Fax: (815)356-9225, or, cleaner@starnetinc.com Our thanks in advance, Dave Steiger...Article: 8094
I have a numbers of FPGA designs which are being implemented with full VHDL synthesis. I am currently targeting Xilinx XC4000EX and XL parts and have a testbed to simulate the designs. The problem is that I have to reference the Xilinx library for some pull-up resistor models which ends up tying the testbed to Xilinx. These FPGAs will be migrated to ASICs and the technology and simulator will change once, if not twice. I have tried a couple failed ideas for the resolution function for a single pin pull-up. Can a single-pin pull-up model be written in VHDL? If so, does anyone have such a model or know where I can find one. For now I have switched to a simple multi-input gate to represent the pull-up. For uni-directional tri-states (like the DTACK signal on a 68K) this works fine, however, for bi-directional busses this "cheat" won't work. Any ideas? ToddArticle: 8095
[ Apparently the perinnial Verilog vs. VHDL discussions have heated up
again in the hardware design newsgroups because I'm being "pelted"
again by people wanting copies of this and the follow-up article to
it. Rather than remailing it, I'm reposting it here. - John ]
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / The Unexpected Results From A Hardware Design Contest:
_] [_ Verilog Won & VHDL Lost? -- You Be The Judge!
by John Cooley, the ESNUG guy
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
I knew I hit a nerve. Usually when I publish a candid review of a particular
conference or EDA product I typically see around 85 replies in my e-mail "in"
box. Buried in my review of the recent Synopsys Users Group meeting, I very
tersely reported that 8 out of the 9 Verilog designers managed to complete
the conference's design contest yet *none* of the 5 VHDL designers could. I
apologized for the terseness and promised to do a detailed report on the
design contest at a later date. Since publishing this, my e-mail "in" box
has become a veritable Verilog/VHDL Beirut filling up with 169 replies! Once
word leaked that the detailed contest write-up was going to be published in
the DAC issue of "Integrated System Design" (formerly "ASIC & EDA" magazine),
I started getting phone calls from the chairman of VHDL International,
Mahendra Jain, and from the president of Open Verilog International, Bill
Fuchs. A small army of hired gun spin doctors (otherwise know as PR agents)
followed with more phone calls. I went ballistic when VHDL columnist Larry
Saunders had approached the Editor-in-Chief of ISD for an advanced copy of my
design contest report. He felt I was "going to do a hatchet job on VHDL" and
wanted to write a rebuttal that would follow my article... and all this was
happening before I had even written *one* damned word of the article!
Because I'm an independent consultant who makes his living training and
working *both* HDL's, I'd rather not go through a VHDL Salem witch trial
where I'm publically accused of being secretly in league with the Devil to
promote Verilog, thank you. Instead I'm going present *everything* that
happened at the Design Contest, warts and all, and let *you* judge! At the
end of court evidence, I'll ask you, the jury, to write an e-mail reply which
I can publish in my column in the follow-up "Integrated System Design".
The Unexpected Results
----------------------
Contestants were given 90 minutes using either Verilog or VHDL to create a
gate netlist for the fastest fully synchronous loadable 9-bit increment-by-3
decrement-by-5 up/down counter that generated even parity, carry and borrow.
Of the 9 Verilog designers in the contest, only 1 didn't get to a final gate
level netlist because he tried to code a look-ahead parity generator. Of the
8 remaining, 3 had netlists that missed on functional test vectors. The 5
Verilog designers who got fully functional gate-level designs were:
Larry Fiedler NVidea 3.90 nsec 1147 gates
Steve Golson Trilobyte Systems 4.30 nsec 1909 gates
Howard Landman HaL Computer 5.49 nsec 1495 gates
Mark Papamarcos EDA Associates 5.97 nsec 1180 gates
Ed Paluch Paluch & Assoc. 7.85 nsec 1514 gates
The surprize was that, during the same time, *none* of 5 VHDL designers in
the contest managed to produce any gate level designs.
Not VHDL Newbies vs. Verilog Pro's
----------------------------------
The first reaction I get from the VHDL bigots (who weren't at the competition)
is: "Well, this is obviously a case where Verilog veterans whipped some VHDL
newbies. Big deal." Well, they're partially right. Many of those Verilog
designers are damned good at what they do -- but so are the VHDL designers!
I've known Prasad Paranjpe of LSI Logic for years. He has taught and still
teaches VHDL with synthesis classes at U.C. Santa Cruz University Extention
in the heart of Silicon Valley. He was VP of the Silicon Valley VHDL Local
Users Group. He's been a full time ASIC designer since 1987 and has designed
*real* ASIC's since 1990 using VHDL & Synopsys since rev 1.3c. Prasad's home
e-mail address is "vhdl@ix.netcom.com" and his home phone is (XXX) XXX-VHDL.
ASIC designer Jan Decaluwe has a history of contributing insightful VHDL and
synthesis posts to ESNUG while at Alcatel and later as a founder of Easics,
a European ASIC design house. (Their company motto: "Easics - The VHDL
Design Company".) Another LSI Logic/VHDL contestant, Vikram Shrivastava, has
used the VHDL/Synopsys design approach since 1992. These guys aren't newbies!
Creating The Contest
--------------------
I followed a double blind approach to putting together this design contest.
That is, not only did I have Larry Saunders (a well known VHDL columnist)
and Yatin Trivedi (a well known Verilog columnist), both of Seva Technologies
comment on the design contest -- unknown to them I had Ken Nelsen (a VHDL
oriented Methodology Manager from Synopsys) and Jeff Flieder (a Verilog based
designer from Ford Microelectronics) also help check the design contest for
any conceptual or implementation flaws.
My initial concern in creating the contest was to not have a situation where
the Synopsys Design Compiler could quickly complete the design by just
placing down a DesignWare part. Yet, I didn't want to have contestants
trying (and failing) to design some fruity, off-the-wall thingy that no one
truely understood. Hence, I was restricted to "standard" designs that all
engineers knew -- but with odd parameters thrown in to keep DesignWare out
of the picture. Instead of a simple up/down counter, I asked for an up-by-3
and down-by-5 counter. Instead of 8 bits, everything was 9 bits.
recycled COUNT_OUT [8:0]
o---------------<---------------<-------------------o
| |
V |
------------- -------- |
DATA_IN -->-| up-by-3 |->-----carry----->-| D Q |->- CARRY_OUT |
[8:0] | down-by-5 |->-----borrow---->-| D Q |->- BORROW_OUT |
| | | | |
UP -->-| logic | | | |
DOWN -->-| |-o------->---------| D[8:0] | |
------------- | new_count [8:0] | Q[8:0] |->-o---->------o
| | | |
o------<-----o CLOCK ---|> | o->- COUNT_OUT
| -------- [8:0]
new_count [8:0] | -----------
| | even | --------
o-->-| parity |->-parity-->-| D Q |->- PARITY_OUT
| generator | (1 bit) | |
----------- o--|> |
| --------
CLOCK ----o
Fig.1) Basic block diagram outlining design's functionality
The even PARITY, CARRY and BORROW requirements were thrown in to give the
contestants some space to make significant architectural trade-offs that
could mean the difference between winning and losing.
The counter loaded when the UP and DOWN were both "low", and held its state
when UP and DOWN were "high" -- exactly opposite to what 99% of the world's
loadable counters traditionally do.
UP DOWN DATA_IN | COUNT_OUT
-----------------------------------------
0 0 valid | load DATA_IN
0 1 don't care | (Q - 5)
1 0 don't care | (Q + 3)
1 1 don't care | Q unchanged
Fig. 2) Loading and up/down counting specifications. All I/O events
happen on the rising edge of CLOCK.
To spice things up a bit further, I chose to use the LSI Logic 300K ASIC
library because wire loading & wire delay is a significant factor in this
technology. Having the "home library" advantage, one saavy VHDL designer,
Prasad Paranjpe of LSI Logic, cleverly asked if the default wire loading
model was required (he wanted to use a zero wire load model to save in
timing!) I replied: "Nice try. Yes, the default wire model is required."
To let the focus be on design and not verification, contestants were given
equivalent Verilog and VHDL testbenches provided by Yatin Trivedi & Larry
Saunder's Seva Technologies. These testbenches threw the same 18 vectors at
the Verilog/VHDL source code the contestants were creating and if it passed,
for contest purposes, their design was judged "functionally correct."
For VHDL, contestants had their choice of Synopsys VSS 3.2b and/or Cadence
Leapfrog VHDL 2.1.4; for Verilog, contestants had their choice of Cadence
Verilog-XL 2.1.2 or Chronologic VCS 2.3.2 plus their respective Verilog/VHDL
design environments. (The CEO of Model Technology Inc., Bob Hunter, was too
paranoid about the possiblity of Synopsys employees seeing his VHDL to allow
it in the contest.) LCB 300K rev 3.1A.1.1.101 was the LSI Logic library.
I had a concern that some designers might not know that an XOR reduction tree
is how one generates parity -- but Larry, Yatin, Ken & Jeff all agreed that
any engineer not knowing this shouldn't be helped to win a design contest.
As a last minute hint, I put in every contestant's directory an "xor.readme"
file that named the two XOR gates available in LSI 300K library (EO and EO3)
plus their drive strengths and port lists.
To be friendly synthesis-wise, I let the designers keep the unrealistic
Synopsys default setting of all inputs having infinite input drive strength
and all outputs were driving zero loads.
The contest took place in three sessions over the same day. To keep things
equal, my guiding philosophy throughout these sessions was to conscientiously
*not* fix/improve *anything* between sessions -- no matter how frustrating!
After all that was said & done, Larry & Yatin thought that the design contest
would be too easy while Ken & Jeff thought it would have just about the right
amount of complexity. I asked all four if they saw any Verilog or VHDL
specific "gotchas" with the contest; all four categorically said "no."
Murphy's Law
------------
Once the contest began, Murphy's Law -- "that which can go wrong, will go
wrong" -- prevailed. Because we couldn't get the SUN and HP workstations
until a terrifying 3 days before the contest, I lived through a nightmare
domino effect on getting all the Verilog, VHDL, Synopsys and LSI libraries
in and installed. Nobody could cut keys for the software until the machine
ID's were known -- and this wasn't until 2 days before the contest! (As it
was, I had to drop the HP machines because most of the EDA vendors couldn't
cut software keys for HP machines as fast as they could for SUN workstations.)
The LSI 300K Libraries didn't arrive until an hour before the contest began.
The Seva guys found and fixed a bug in the Verilog testbench (that didn't
exist in the VHDL testbench) some 15 minutes before the constest began.
Some 50 minutes into the first design session, one engineer's machine
crashed -- which also happened to be the licence server for all the Verilog
simulation software! (Luckily, by this time all the Verilog designers were
deep into the synthesis stage.) Unfortunately, the poor designer who had his
machine crash couldn't be allowed to redo the contest in a following session
because of his prior knowlege of the design problem. This machine was
rebooted and used solely as a licence server for the rest of the contest.
The logistics nightmare once again reared its ugly head when two designers
innocently asked: "John, where are your Synopsys manuals?" Inside I screamed
to myself: "OhMyGod! OhMyGod! OhMyGod!"; outside I calmly replied: "There are
no manuals for any software here. You have to use the online docs available."
More little gremlins danced in my head when I realized that six of the eight
data books that the LSI lib person brought weren't for the *exact* LCB 300K
library we were using -- these data books would be critical for anyone trying
to hand build an XOR reduction tree -- and one Verilog contestant had just
spent ten precious minutes reading a misleading data book! (There were two
LCB 300K, one LCA 300K and five LEA 300K databooks.) Verilog designer Howard
Landman of HaL Computer noted: "I probably wasted 15 minutes trying to work
through this before giving up and just coding functional parity -- although
I used parentheses in hopes of Synopsys using 3-input XOR gates."
Then, just as things couldn't get worst, everyone got to discover that when
Synopsys's Design Compiler runs for the first time in a new account -- it
takes a good 10 to 15 minutes to build your very own personal DesignWare
cache. Verilog contestant Ed Paluch, a consultant, noted: "I thought that
first synthesis run building [expletive deleted] DesignWare caches would
*never* end! It felt like days!"
Although, in my opinion, none of these headaches compromised the integrity of
the contest, at the time I had to continually remind myself: "To keep things
equal, I can *not* fix nor improve *anything* no matter how frustrating."
Judging The Results
-------------------
Because I didn't want to be in the business of judging source code *intent*,
all judging was based solely on whether the gate level passed the previously
described 18 test vectors. Once done, the design was read into the Synopsys
Design Compiler and all constraints were removed. Then I applied the command
"clocks_at 0, 6, 12 clock" and then took the longest path as determined by
"report_timing -path full -delay max -max_paths 12" as the final basis for
comparing designs -- determining that Verilog designer Larry Fiedler of
NVidia won with a 1147 gate design timed at 3.90 nsec.
reg [9:0] cnt_up, cnt_dn; reg [8:0] count_nxt;
always @(posedge clock)
begin
cnt_dn = count_out - 3'b 101; // synopsys label add_dn
cnt_up = count_out + 2'b 11; // synopsys label add_up
case ({up,down})
2'b 00 : count_nxt = data_in;
2'b 01 : count_nxt = cnt_dn;
2'b 10 : count_nxt = cnt_up;
2'b 11 : count_nxt = 9'bX; // SPEC NOT MET HERE!!!
default : count_nxt = 9'bX; // avoiding ambiguity traps
endcase
parity_out <= ^count_nxt;
carry_out <= up & cnt_up[9];
borrow_out <= down & cnt_dn[9];
count_out <= count_nxt;
end
Fig. 3) The winning Verilog source code. (Note that it failed to meet
the spec of holding its state when UP and DOWN were both high.)
Since judging was open to any and all who wanted to be there, Kurt Baty, a
Verilog contestant and well respected design consultant, registered a vocal
double surprize because he knew his design was of comparable speed but had
failed to pass the 18 test vectors. (Kurt's a good friend -- I really
enjoyed harassing him over this discovery -- especially since he had bragged
to so many people on how he was going to win this contest!) An on the spot
investigation yielded that Kurt had accidently saved the wrong design in the
final minute of the contest. Even further investigation then also yielded
that the 18 test vectors didn't cover exactly all the counter's specified
conditions. Larry's "winning" gate level Verilog based design had failed to
meet the spec of holding its state when UP and DOWN were high -- even though
his design had successfully passed the 18 test vectors!
If human visual inspection of the Verilog/VHDL source code to subjectively
check for places where the test vectors might have missed was part of the
judging criteria, Verilog designer Steve Golson would have won. Once again,
I had to reiterate that all designs which passed the testbench vectors were
considered "functionally correct" by definition.
What The Contestants Thought
----------------------------
Despite NASA VHDL designer Jeff Solomon's "I didn't like the idea of taking
the traditional concept of counters and warping it to make a contest design
problem", the remaining twelve contestants really liked the architectural
flexiblity of the up-by-3/down-by-5, 9 bit, loadable, synchronous counter
with even party, carry and borrow. Verilog designer Mark Papamarcos summed
up the majority opinion with: "I think that the problem was pretty well
devised. There was a potential resource sharing problem, some opportunities
to schedule some logic to evaluate concurrently with other logic, etc. When
I first saw it, I thought it would be very easy to implement and I would have
lots of time to tune. I also noticed the 2 and 3-input XOR's in the top-level
directory, figured that it might be somehow relevant, but quickly dismissed
any clever ideas when I ran into problems getting the vectors to match."
Eleven of contestants were tempted by the apparent correlation between known
parity and the adding/subtracting of odd numbers. Only one Verilog designer,
Oren Rubinstein of Hewlett-Packard Canada, committed to this strategy but ran
way out of time. Once home, Kurt Baty helped Oren conceptually finish his
design while Prasad Paranjpe helped with the final synthesis. It took about
7 hours brain time and 8 hours coding/sim/synth time (15 hours total) to get
a final design of 3.05 nsec & 1988 gates. Observing it took 10x the original
estimated 1.5 hours to get a 22% improvement in speed, Oren commented: "Like
real life, it's impossible to create accurate engineering design schedules."
Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of
Easics, both complained of having to deal with type conversions in VHDL.
Prasad confessed: "I can't believe I got caught on a simple typing error.
I used IEEE std_logic_arith, which requires use of unsigned & signed subtypes,
instead of std_logic_unsigned." Jan agreed and added: "I ran into a problem
with VHDL or VSS (I'm still not sure.) This case statement doesn't analyze:
"subtype two_bits is unsigned(1 downto 0); case two_bits'(up & down)..." But
what worked was: "case two_bits'(up, down)..." Finally I solved this problem
by assigning the concatenation first to a auxiliary variable."
Verilog competitor Steve Golson outlined the first-get-a-working-design-and-
then-tweak-it-in-synthesis strategy that most of the Verilog contestants
pursued with: "As I recall I had some stupid typos which held me up; also I
had difficulty with parity and carry/borrow. Once I had a correctly
functioning baseline design, I began modifying it for optimal synthesis.
My basic idea was to split the design into four separate modules: the adder,
the 4:1 MUXes, the XOR logic (parity and carry/borrow), and the top counter
module which contains only the flops and instances of the other three modules.
My strategy was to first compile the three (purely combinational) submodules
individually. I used a simple "max_delay 0 all_outputs()" constraint on each
of them. The top-level module got the proper clock constraint. Then
"dont_touch" these designs, and compile the top counter module (this just
builds the flops). Then to clean up I did an "ungroup -all" followed by a
"compile -incremental" (which shaved almost 1 nsec off my critical path.)"
Typos and panic hurt the performance of a lot of contestants. Verilog
designer Daryoosh Khalilollahi of National Semiconductor said: "I thought
I would not be able to finish it on time, but I just made it. I lost some
time because I would get a Verilog syntax error that turned up because I had
one extra file in my Verilog "include" file (verilog -f include) which was
not needed." Also, Verilog designer Howard Landman of Hal Computers never
realized he had put both a complete behavioral *and* a complete hand
instanced parity tree in his source Verilog. (Synopsys Design Compiler just
optimized one of Howard's dual parity trees away!)
On average, each Verilog designer managed to get two to five synthesis runs
completed before running out of time. Only two VHDL designers, Jeff Solomon
and Jan Decaluwe, managed to start (but not complete) one synthesis run. In
both cases I disqualified them from the contest for not making the deadline
but let their synthesis runs attempt to finish. Jan arrived a little late so
we gave Jan's run some added time before disqualifying him. His unfinished
run had to be killed after 21 minutes because another group of contestants
were arriving. (Incidently, I had accidently given the third session an
extra 6 design minutes because of a goof on my part. No Verilog designers
were in this session but VHDL designers Jeff Solomon, Prasad Paranjpe, Vikram
Shrivastava plus Ravi Srinivasan of Texus Instruments all benefited from this
mistake.) Since Jeff was in the last session, I gave him all the time needed
for his run to complete. After an additional 17 minutes (total) he produced
a gate level design that timed out to 15.52 nsec. After a total of 28 more
minutes he got the timing down to 4.46 nsec but his design didn't pass
functional vectors. He had an error somewhere in his VHDL source code.
Failed Verilog designer Kurt Baty closed with: "John, I look forward to next
year's design contest in whatever form or flavor it takes, and a chance to
redeem my honor."
Closing Arguments To The Jury
-----------------------------
Closing aurguments the VHDL bigots may make in this trial might be: "What 14
engineers do isn't statistically significant. Even the guy who ran this
design contest admitted all sorts of last minute goofs with it. You had a
workstation crash, no manuals & misleading LSI databooks. The test vectors
were incomplete. One key VHDL designer ran into a Synopsys VHDL simulator
bug after arriving late to his session. The Verilog design which won this
contest didn't even meet the spec completely! In addition, this contest
wasn't put together to be a referendum on whether Verilog or VHDL is the
better language to design in -- hence it may miss some major issues."
The Verilog bigots might close with: "No engineers work under the contrived
conditions one may want for an ideal comparision of Verilog & VHDL. Fourteen
engineers may or may not be statistally significant, but where there's smoke,
there's fire. I saw all the classical problems engineers encounter in day to
day designing here. We've all dealt with workstation crashes, bad revision
control, bugs in tools, poor planning and incomplete testing. It's because
of these realities I think this design contest was *perfect* to determine how
each HDL measures up in real life. And Verilog won hands down!"
The jury's veridict will be seen in the next "Integrated System Design".
You The Jury...
---------------
You the jury are now asked to please take ten minutes to think about what
you have just read and, in 150 words or less, send your thoughts to me at
"jcooley@world.std.com". Please don't send me "VHDL sucks." or "Verilog
must die!!!" -- but personal experiences and/or observations that add to
the discussion. It's OK to have strong/violent opinions, just back them with
something more than hot air. (Since I don't want to be in the business of
chasing down permissions, my default setting is *whatever* you send me is
completely publishable. If you wish to send me letters with a mix of
publishable and non-publishable material CLEARLY indicate which is which.)
I will not only be reprinting replied letters, I'll also be publishing stats
on how many people had reported each type of specific opinion/experience.
- John Cooley
Part Time EDA Consumer Advocate
Full Time ASIC, FPGA & EDA Design Consultant
P.S. In replying, please indicate your job, your company, whether you use
Verilog or VHDL, why, and for how long. Also, please DO NOT copy
this article back to me -- I know why you're replying! :^)
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 3349 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: 8096
[ Apparently the perinnial Verilog vs. VHDL discussions have heated up
again in the hardware design newsgroups because I'm being "pelted"
again by people wanting copies of this and the preceeding article to
it. Rather than remailing it, I'm reposting it here. - John ]
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / RORSCHACH TESTING 273 ENGINEERS
_] [_ WITH THE VERILOG/VHDL CONTEST
by John Cooley
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
In March '95, at the annual Synopsys Users Group meeting, a 90 minute ASIC
design contest was held. Using either Verilog or VHDL the 14 contestants
were to create a gate netlist for the fastest fully synchronous loadable
9-bit increment-by-3 decrement-by-5 up/down counter that generated even
parity, carry and borrow.
Of the 9 Verilog designers in the contest, only 1 didn't get to a final gate
level netlist because he tried to code a look-ahead parity generator. Of the
8 remaining, 3 had netlists that missed on functional test vectors leaving 5
Verilog designers who got fully functional gate-level designs. The surprize
was that, during the same time, *none* of 5 VHDL designers in the contest
managed to produce any gate level designs.
In the July issue of "Integrated System Design", I published a very detailed
write-up of the contest. As a sort of industry-wide Rorschach test, I asked
the readers to e-mail me their background, their vote for whether Verilog or
VHDL "won", and the open-ended question of why they thought the way they did.
Here's what 273 ASIC design engineers were thinking...
DEMOGRAPHICS A total of 317 letters were recieved but only 273 were counted;
88 VHDL-only, 76 Verilog-only, 66 bilinguals, and 43 unknown language users.
None of the following people's opinions were tabulated: 19 asking only for
the contest's test suites, 17 people employed by EDA vendors, 3 university
Computer Science types, a chemistry professor, an EE PhD candidate seeking
permission to translate the design contest into Estonian, 3 EDA sales
pitches and one "Christ is Coming Soon!" letter. Four ESDA vendors wrote
for the contest specs making great claims in the process but were never
heard from again after getting them.
PAYBACK TIME Because of all the time and energy some the EDA sales staffs
put into pushing VHDL onto engineers happy with Verilog, this contest seemed
to be a clarion call for Verilog customers (14 to be exact) to tell me the
shenannigans they suffered at the hands of these EDA vendors. Synopsys, Inc.
topped the perpetrator list because they had a Verilog/VHDL synthesis tool
but only a VHDL simulator (VSS) to go with it. Hence, their sales staff was
quite motivated to creatively work overtime promoting VHDL over Verilog.
> When I worked at HP Roseville, I remember taking my first Synopsys training
> class. The instructor from Synopsys kept telling us that we were making a
> grave mistake using Verilog and that EVERYONE who was anyone was using
> VHDL. (I actually was worried at the time we had chosen the wrong
> language, and that he was really unbiased. As I look back it is obvious
> that he was probably a VSS VHDL salesman and did Design Compiler training
> on the side.) I'm glad we chose Verilog, especially when teaching new
> engineers and when getting our SW/FW folks (who eat/sleep/breathe "C") to
> understand the HDL I have written. I would really encourage any new HDL
> designer to choose Verilog rather than VHDL, since it is much easier to
> learn, use and eventually master.
>
> - Scott C. Petler
> Next Level Communications, Inc.
I laughed out loud when I saw this next letter. At the Synopsys Users Group
meeting three years ago, the HP Boise Laserjet VHDL "success" story was a
main event. And recently, Synopsys even used it in a major ad campaign
promoting VHDL with synthesis in all the trade journals!
> I have spent most of my design life (last 4 years) working on VHDL designs.
> Recently, I have been forced into the Verilog camp by a vendor. My initial
> concerns that Verilog would not have the functionality that I needed have
> been proven wrong. Verilog does what I need better - and the simulators
> are faster than VHDL simulators.
>
> Since VHDL was driven mostly by the government which has no interest in the
> productivity of the designers, it is not surprising to see your results
> from the contest. VHDL syntax hinders progress and does not improve the
> robustness or quality of the design. The behavioral compilers, not VHDL,
> make the most sense for doing even more sophisticated design work.
>
> Please don't make be go back to VHDL!
>
> - Robert Rust
> Hewlett Packard Boise Printer Division
HOW TO NOT LIE WITH STATISTICS To my surprize, hardly anyone (2 VHDL-only
users) tried to say this was statistically insignificant, but 4 (5%) VHDL-
only, 5 (7%) Verilog-only, 3 (5%) bilinguals, 3 (18%) EDA vendors, and one
(25%) professor thought is was mathematically kosher.
> One question that you have the VHDL bigots make in this "trial" can be
> completely refuted: the results are statistically significant as the term
> is usually defined. To say a result is statistically significant, you
> show that it was very unlikely to be achieved by chance. Given: 9 Verilog
> designers and 5 VHDL designers, choose 8 winners at random. What is the
> chance that they will all be Verilog designers?
>
> Answer: (9/14)*(8/13)*(7/12)*(6/11)*(5/10)*(4/9)*(3/8)*(2/7)
> = 0.002997
> = 1/333.7
>
> So there is one chance in 333.7 that this result is purely by chance. We
> can't argue that this result isn't statistically significant given this
> figure. This is a greater than 99% confidence level. If we take one VHDL
> designer out (the one who suffered from the VHDL simulator bug), we get
> (9*8*...2)/(13*12*...6) or 1/143.
FROM THE FOUNDRY Rather than risk losing any business or possibly angering
customers, six ASIC foundry and three FPGA vendors wrote carefully balanced
replies that said effectively: "Whatever the customer wants is right." One
former foundry person wrote on condition of anonimity:
> In a previous life, I worked as an onsite applications engineer for an ASIC
> vendor. The customer that I supported was developing 17 ASIC's for a large
> program. The customer chose to develop some of the designs in VHDL and
> others in Verilog. All were synthesized using Synopsys. The smallest
> design was 15K gates, the largest was 100K gates. I interviewed the design
> teams to gather some interesting statistics. Conclusions were:
>
> 1) Designs done in Verilog were, without fail, completed faster than
> those done in VHDL. (In terms of gates/manweek.)
>
> 2) Adding designers to VHDL and Verilog based designs SLOWED the
> gates/manweek metric, but adding designers to VHDL-based designs
> had a greater negative impact. (Probably due to data-typing issues.)
>
> 3) Single or dual-person design teams out performed all others.
>
> The designers (80) were of various experience levels, working in groups of
> 2 to 10. From end of specification to final signoff, the highest
> performancing was a Verilog team at 1500 gates/manweek, the lowest was a
> VHDL team with 8 gates/manweek!
VHDL'S STRATEGIC RETREAT In the engineering press and on the Internet prior
to the Verilog/VHDL Design Contest, the VHDL bigots managed to create an
image that the only problem their language of choice had was in convincing
the ASIC foundries to provide VHDL libraries. Hence, the big media presence
of "VHDL Initiative Towards ASIC Libraries" (VITAL). With the Design Contest
results 39 (44%) VHDL-only, 4 (5%) Verilog-only, 19 (29%) bilinguals, and 14
(33%) unknown language users conceded that Verilog "wins" in low level gate
type designing, but VHDL "wins" in higher level abstract designing. That is,
VHDL is retreating from gate level design to "own" high level design. (Just
weeks before the Design Contest, VHDL proponents were openly claiming VHDL
was just as good at gate level ASIC design as Verilog was.)
> I've successfully used both languages, think that the results of the
> contest are directly correlated to the structure of the languages. It
> exactly mirror my experiences. Given this, I still prefer VHDL. My first
> design was with Verilog and on the first day (after I'd taken the Synopsys
> Verilog class) I was able to write useable code that was simulatable and
> synthesizable. I found the language relatively simple and easy to use, and
> thus easy to produce results with. When I changed jobs I started using
> VHDL and have produced several large chips with it. It took me more than a
> week to get my first VHDL code to compile, not to mention simulate. At
> first I couldn't stand VHDL, but as time went by I found that it's more
> structured, verbose and abstract from actual hardware. Although harder
> to learn and easier to mess up, it's valuable on large projects.
>
> - Sean Atsatt
> Seagate
TESTING MORE IMPORTANT For some engineers testing was more important than
other issues: 14 (16%) VHDL-only and 9 (12%) Verilog-only stated that their
chosen HDL was best for this; 9 (14%) bilinguals and 4 (9%) unknowns liked
VHDL on testing; 8 (12%) bilinguals and 1 unknown preferred Verilog.
> It's clear from the contest that Verilog can get you to a netlist faster
> than VHDL - period end of story. BUT my experience has shown that the
> amount of time to generate a netlist is small in comparison to the over
> all ASIC design schedule. Verification (i.e. test bench generation) makes
> up most of the ASIC design schedules I put together. Verilog's C-like
> structure provides a very flexiable environment which integrates very
> smoothly into most test bench solutions. In addition, focusing on test
> benchs illuminates one of Verilog's best features: the PLI. I don't
> believe VHDL provides a PLI counterpart. Without a PLI many of the
> third part tools that I rely on, such as Signalscan, would not be available.
> At GI we have made use of Verilog's PLI for many tasks ranging from memory
> efficient input stimulus handling to automated test vector generation.
>
> - Rick Price
> General Instrument Corp
EXPERIENCE QUESTIONS Quite a number of VHDL proponents raised the issue that
the VHDL contestants might not be experienced with the tools they had at hand
or in ASIC design itself. (No one questioned the experience of the Verilog
contestants because all but one got to gates.) The VHDL contestants used
Synopsys for synthesis and had a choice of Cadence and Synopsys for VHDL.
What follows are the sizes of all the ASIC's and FPGA's the VHDL contestants
have designed plus what EDA tools they've used.
TABLE 1) ASIC, FPGA & TOOL EXPERIENCE OF VHDL COMPETITORS
----------------------------------------------------------------------------
Ravi Srinivasan ASIC's: 60K, 115K partial ASIC's: 30K, 45K FPGA's: 0
Texas Instr. Tools: Synopsys VHDL & Design Compiler, Aida, Verilog-XL
Jan DeCalwe ASIC's: 60K, 22K, 65K, 35K, 83K FPGA's 3K, 6K, 4K, 2K
Easics, Ltd. Tools: Synopsys VHDL & Design Compiler, Actel P&R, Altera
MaxPlusII, Verilog-XL
Jeff Solomon ASIC's: 125K (schm.) partial 55K FPGA's: 2K, 6K, 10K
NASA Goddard Tools: Synopsys VHDL & Design Compiler, Concept/Valid,
Cadence LWB RapidSim, LSI CMDE
Prasad Paranjpe ASIC's: 17K, 20K, 50K, 30K partial ASIC's: >5 FPGA's: 0
LSI Logic Tools: Synopsys VHDL & Design Compiler, Vantage, LeapFrog,
Verilog-XL, IKOS, MTI, LSI CMDE
Vikram Shrivastava partial ASIC's: lots of synthesis/static timing/CMDE
LSI Logic Tools: Synopsys VHDL & Design Compiler, Verilog-XL, CMDE
---------------------------------------------------------------------------
The Verilog based contestants had similar tool and ASIC design experiance.
One noteable exception was Howard Landman of HaL Computers. In his 15 years
of CAD management experience Landman has never designed a single ASIC, yet,
using Verilog he managed to take third place in the design competition!
FAIRNESS: Of those 44 (16%) engineers who commented on fairness, 6 (2%)
(all VHDL-only's) felt the contest was "rigged" in Verilog's favor (because
they felt it was too low level) while the remaining 38 (14%) overall
designers saw it as honorable.
> Even before I read the "Closing Arguments to the Jury..." I was thinking
> that this design contest was perfect because it showed exactly what
> engineers are up against - tools are late, support is incomplete and/or
> inexact, workstations crash inexplicably, testing is incomplete, etc. The
> only thing missing was a change in the specification 10 minutes before the
> end of the contest. Cool contest - thanks for all the work.
>
> - Richard Schmidt
> Exabyte
Two engineers felt that Steve Golson should have won because his design met
the design spec while Larry's didn't -- but this error wasn't caught by the
faulty test suite.
> Steve Golson is the winner. Clearly stated in the spec: "11" - Q holds
> state. The inability of your testbench designers to adequately test the
> design should not be held against Steve (or should I say assist Larry).
> The bottom line must be that the design is functionally accurate.
>
> - Michael Fitzsimmons
> Motorola
TYPE WARS: The most controversial topic was whether strong typing is a good
thing or a bad thing. Some VHDL-proponents felt it was VHDL's core strength,
while other VHDL-proponents saw strong typing as an increadable annoyance!
Those who knew VHDL had very strong opinions on this. Of the bilinguals,
19 (29%) hated strong typing, 6 (9%) loved it, 6 (9%) noted it but couldn't
decide. Of the VHDL-onlys, the breakout was 13 (15%) hate, 17 (19%) love,
10 (11%) noted but couldn't decide. Of Verilog-onlys and unknowns, 7 (5%)
hated, 4 (3%) loved, 6 (4%) noted but couldn't decide.
> I thought the contest was a good one and I'm not seriously surprised by the
> results. I think the difference is in the nature of the languages,
> particularly the strong typing of VHDL, which at least one of your entrants
> had trouble with. VHDL forces you to think carefully about datatypes; if
> the design is simple logic, then this is a liability in terms of quick
> design time. VHDL has a better chance of producing a correct design if
> there is a mix of signal types, because you are forced to make sure they
> all convert correctly. C++ versus C is an analogy, the strong class
> binding of C++ objects can make for extra work up front making sure the
> types match up. In the long run, the design is more robust and easier to
> maintain because of it. I'm an IC designer who has used both - I'd use
> either one in real life, but I think verilog has the edge in quick draw
> contests.
>
> - Steve McChrystal
> Siemens Components Inc.
IOWA STATE UNIVERSITY It appears that the Design Contest's results have even
been verified by academia. What I liked about this unintentional validation
is that it's not 90 minutes. That is, there was all sorts of time for the
designers to do what they wanted. (I've recieved over 100 letters total
starting with: "Your results didn't surprize me one bit!" If they were from
the VHDL oriented I got explanations that VHDL tools took longer to run, VHDL
was more verbose, and needed more intial time to get results. If they were
from the Verilog oriented, I got explainations that Verilog was essentially
C with wires, registers, built in flexable HW data types, concurrency and "it
should naturally win.")
> Actually, an interesting look at VHDL vs. Verilog was accidentally done in
> our graduate level logic synthesis course. We recently got Synopsys Design
> Compiler, Synopsys VHDL and Cadence Verilog-XL. While The rest of the
> class did their projects in VHDL, my lab partner and I did ours in Verilog.
> (We learned Verilog on our own; unlike my VHDL classmates, we had no class
> lectures, no T/A help, no professoral help.)
>
> The results of this were overwhelmingly in favor of Verilog as a tool to
> teach HDLs. Our final project, a 7500 gate, 35nsec RISC processor was ~25
> pages of Verilog. The VHDL people all ended up rushing near the end to
> just make something which worked and could be synthesized. Several groups
> failed at this altogether! (Whereas our project grew so large in
> functionality, our only problem was finding a workstation which had enough
> memory to handle the synthesis of the top level design.)
>
> The general comments in talking to the other students was they spent a
> majority of their timing fighting VHDL/Synopsys. We spent a majority of
> our time doing design work, and optimization.
>
> - Jeff Echtenkamp
> Iowa State University
BILINGUAL JUDGEMENTS The opinions I value the most are those of the bi-
linguals because they know both sides of the story. Of the bilinguals, 39
(59%) personally preferred Verilog overall, 16 (24%) were HDL neutral,
6 (9%) personally preferred VHDL, and 5 (8%) didn't comment on this.
> My transition from VHDL to Verilog came about 2 years back when I worked
> on a design which was about 45K gates. I learned Verilog as the ASIC
> Vendor we worked with was only comfortable doing a final signoff in Verilog
> rather than VHDL. With the flavor of both the languages, here are my
> comments:
>
> 1) VHDL is a good structured HIGH level language but I feel Verilog is
> closer to actual hardware which is being designed.
>
> 2) As far as behavioral goes, I rank VHDL at par with Verilog, but when
> it comes to RTL, I consider Verilog has the edge over VHDL as far as
> the time to market ( i.e. meeting the design schedule is concerned.)
>
> As far as the contest goes, I think verilog has again proved the point.
> Yes, with VHDL you can achieve the same target but at the cost of design
> time and support. In the present industry, time to market a product is
> the key to success. If a particular market window is missed, the ASIC and
> the man-months spent on it are a sheer waste. I strongly feel that given
> the choice and the design time I would opt for Verilog.
>
> - Subhodip Ghosh
> Western Digital Corp.
DON'T SHOOT THE MESSENGER! I'd like to close with the observation that this
design contest wasn't designed to be a referendum on Verilog vs. VHDL, but
it accidently became this. I was swamped with e-mail from both the Verilog
*and* VHDL camps *both* saying that Verilog won in this contest. Judging the
contest overall 175 (64%) felt "Verilog won", 16 (6%) felt "VHDL won", 48
(18%) felt "inconclusive" and 36 (13%) never voted! Along party lines, 70
(92%) Verilog-onlys voted "Verilog won" and 39 (44%) VHDL-only's did either
an "inconclusive" or "no vote."
> I am in the defense industry, and therefore we went right to VHDL when we
> switched to designing ASICs using HDLs. I have never learned Verilog. I
> have always thought the extremely tight typing in VHDL caused a lot of
> inefficiencies, and my guess is that this had a major effect in the contest
> results. Your contest seemed very fair to me. I would call Verilog the
> obvious winner.
>
> - Jim Levie
> Northrop Grumman
Yes, quite a few VHDL-only EDA companies like Synopsys, Mentor, Zycad, IKOS,
Model Tech, and ViewLogic have suddenly been working to either buy or
develope Verilog products for their customers. I don't see them leaving the
VHDL business, though. In my own consulting practice I've just finished a
Verilog ASIC for one customer and am now writing VHDL training material for
another. For the next few years I feel being fully Verilog/VHDL bilingual,
just like most EDA companies, is the wave of the future.
- John Cooley
part-time EDA Consumer Advocate
full-time contract ASIC/FPGA designer
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how 3881 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: 8097Hi, I am placing an 100.000 gates design in an Xilinx 4085XL. Obviously the fpga isn't big enough for that. So I have to split up the design in, say 4 parts. How can I give Synopsys commands to compile my design in 4 subdesigns? Any idea's? Please let me know ! Best Regards, Arjen Helder Pijnenburg B.V.Article: 8098
Check out CircuitOnline..Searchable directory of services designed for the electronics/semiconductor design and manufacturing: http://www.circuitonline.com CAD Tools, IC Design Services, VLSI Research, FPGA, Maegacells, Assembly, Board, Wafer Processing....Article: 8099
Markus Leberecht wrote:
>
> Hi all!
>
> We are currently planning to do an FPGA design that is loaded with
> registers to all of which a processer would need read and possibly
> write access. We therefore came up with the idea of using a
> reconfigurable device with a memory-like CPU interface (like the
> XC6200) since it would provide us for free with all the datapaths to
> access the registers. Using a regular FPGA, it seems that we would
> just waste too much space for the "little functionality" of accessing
> the registers. Is this reasoning correct or are there regular (non-
> reconfigurable, that is) FPGA families that are better suited to this
> kind of design with maybe a higher density?
>
I'm a little confused as to what you're saying.
1) FPGAs are register intensive
2) The XC6200 is a regular (ie reconfigurable device) which
is designed to interface to a CPU.
3) Most FPGAs are reconfigurable with the exception of Atmel
which are write once.
In a regular FPGA you can't access each register for read and write
in a manner you are eluding to. The FPGA has hardwired registers
which are connected through an SRAM based interconnect matrix
which is programmed. In an FPGA the registers must be connected
to the outside world (pins) through programable connections
within the device. By default the registers are not connected to
the pins. You could "program" the fpga to connect groups of the
registers to the CPU bus but this would take many reconfigurations
as there are way more registers than pins. The "datapaths to
access the registers" that you refer to is through the programming
ports on the FPGA. This allows you to write to the programmable
connections (rather than the registers). This process is similar
to the function of an hour glass in that the program fills the
FPGA in a predetermined sequence - the connections can not be
reached independantly (yet).
The port you are probably interested in is the boundary scan port.
(I encourage you to refer to Boundary Scan and BIST literature).
This allows you to run a pattern through all the registers in a
device (not limited to FPGAs) to check the integrety of the
device.
> Related to this, if we were going to use reconfigurable devices, does
> anyone know of a good and seamless VHDL design flow for them? The
> problem here is, for simulation you'd need a model of the internal
> datapaths of the FPGA (those used for reconfiguration), and the
The "compilers" from the FPGA manufacturers contain the timing info
for delay through a register cell and the delay of the programmable
interconnect. You can use these tools to generate a timing annotated
VHDL netlist which you can simulate to verify performance.
> synthesis tool would have to be able to interface to them in a way
> that would make it possible to signal external read/write accesses to
> the internal synthesized logic.
>
The synthesis tools (which include the compilers e.g Xilinx M1 and
Altera Maxplus2) generate the bit pattern required to program the
FPGA (as described above) from the VHDL code.
> Overall, the question is: What's better, using a regular highest-density
> FPGA and designing the datapaths on your own (with a proven design flow),
> or using a reconfigurable device with given datapaths (and possibly a
> dubious design flow)?
>
To this I can only answer huhh???
Regular FPGAs are reconfigurable.
Synthesis tools "design" the path through the pins to the registers and
can be integrated into your design flow.
Reconfigurable FPGAs are reconfigurable and thus have no "given"
datapaths.
Hope this confuses^W helps.
Tim.
--
Strong words softly spoken.
My opinions != Nortel's opinion.
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