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
hi,
I am in a Xilinx xc4013 design with auto logic II
I try to use a .cfg file when adding global buffers .
the format I use is as specified in mentor books
clk BUFGP
clk1 BUFGP
etc.
using this format I get an error message :
> # opt custom "xi_global_ins_del_top all io.cfg insert"
For 122 ports:
No IO buffers to delete
subscript: list index out of range 1
# cur library work
Closing unreferenced file io.cfg
# cur cell work rasreg1_5ns
does anybod have any idea what is the problem ????
thanks in advance
--
Maya Reuveni Tel: 972-9-986976
Manager of Hardware Department Fax: 972-9-986980
HaTaasiya 9, Raanana 43100, Israel. E-mail: maya@asp.co.il
Article: 2551
In article <DKFo2M.sL@world.std.com> suzanne@world.std.com (suzanne M southworth) writes:
> I would suggest that you pick Verilog and I think everyone would agree
> that it is an easier tool to use. Try to find a one day Verilog vs.VHDL
> class from a consultant and then you will see for yourself why everyone
> is using Verilog.
Sorry, in the US this might be the case, but in Europe nearly everybody is
using VHDL. (Japan also has a preference towards VHDL)
I can agree that Verilog is the easier one, but this does not mean that
it is the best one.
This is the same as a BASIC programmer which says to his C colleague
that BASIC is better because it is easier.
Regards,
(I do not speak for my company, only for myself)
___________ Peter Cnudde
_\ /_ Alcatel Bell Telephone
\ \ALCATEL/ / Switching Systems Division
\ \ BELL/ / Microelectronics Design Center
\ \ / /
\ \ / / F. Wellesplein 1, B-2018 Antwerp
\ Y / BELGIUM
\|/ e-mail : cnuddep@sh.bel.alcatel.be
* Phone : (32/3) 240 82 18
Fax : (32/3) 240 99 47
Article: 2552
larrycam@ix.netcom.com (Larry Cameron) writes:
: cool beans! how about making it free for the taking at the vhdl.org site?
: just a thought...
Guess.. not.. he's working for a commercial company... so.. they want
to make some money out of it.
Loek.
--
,------------------------.
/ Let's make chips better! \
\ _______,----------------'
_ |/ Loek Frederiks
oo\ Philips Semiconductors
(__)\ _ CIC Nijmegen, Digital Audio Group
\ \ .' `. AO 1.036, Gerstweg 2
\ \ / \ 6534 AE Nijmegen
\ '" \ The Netherlands
. ( ) \
'-| )__| :. \ E-mail: frederik@nyhp03.serigate.philips.nl
| | | | \ '. Phone: (+31 24 353) 35 07
c__; c__; '-..'>.__ Fax: (+31 24 353) 21 23
Article: 2553In article <4budc1$llq@mksrv1.dseg.ti.com>, rjmyers@ti.com says... > >I'm having problems with using "bibuf" primitives on an Actel schematic >simulation. In the design that I'm trying to simulate, I have valid data >going to the "D" pins and can see either a "1" or "0" on the "E" pins, >however when I look at the traces for the "Y" or "PAD" pins, I always >see unknown values. These values appear whether or not I have the pads >connected (via ripped bus) to the I/O pins of a dram chip (LMC smartmodel). > > >Is there anything special that has to be done to use bibufs in a schematic >that is going to be simulated? > >Any suggestions/advice welcomed. > >-Bob > Bob I also had problems with the "bibuf". It was in March 95, with mentor 8.2 and ALS release 2.3. My problem was when using "ACT3". I found the "bibuf" did not have a mgc_schematic model entry in the interface associated with label ACT3. This caused errors in the generation of my simulation viewpoint and simulation problems. I copied their part from the library and registered the mgc_schematic model for ACT3 with the interface for "bibuf". I then pointed my design to my copy of the part. Then things worked OK. I did send mail to Actel support but never got a reply. Hope this helps. Mike Bates Loral Defense Systems - Eagan mlbates@eag.unisysgsg.comArticle: 2554
peter cnudde sh146 8218 <cnuddep@sh.bel.alcatel.be> wrote: >Sorry, in the US this might be the case, but in Europe nearly everybody is >using VHDL. (Japan also has a preference towards VHDL) Engineering in those two geographies strongly follows the sheep herd principle. When you ask people from either why VHDL, the most common answer is "it's a standard". Not a real, de facto standard, but a rather useless de jure standard, sort of like ISO networks. >I can agree that Verilog is the easier one, but this does not mean that >it is the best one. It's the easier and the best one. This will hold until whatever the successor to both languages comes along. >This is the same as a BASIC programmer which says to his C colleague >that BASIC is better because it is easier. No, more like a C programmer who says to his ADA colleague that C is better because it is easier, and you might get something reasonably useful out of it in a finite time. I've used both. Right now, Verilog is still the best supported language for real development, especially ASIC development. -- "There is a certain level of self-imposed ignorance that I have no desire to try and correct." - Chris Wolf (self-descriptive? you make the call!)Article: 2555
peter cnudde sh146 8218 (cnuddep@sh.bel.alcatel.be) wrote:
> I can agree that Verilog is the easier one, but this does not mean that
> it is the best one.
I read somewhere that, to implement a function, VHDL requires about 3X the
number of lines that Verilog does. I've also read that the number of bugs
in a software program (admittedly, VHDL/Verilog isn't software -- but there
are many similarities in the process of writing HDL and software) correlates to
the number of lines of code. So, without a good study to refer to, I'd be
concerned about the quality implications of using VHDL instead of Verilog.
> This is the same as a BASIC programmer which says to his C colleague
> that BASIC is better because it is easier.
Your analogy is a poor one, because Verilog is very much like C. VHDL?
Well, I've always called it "the engineer's COBOL" :-), but -- being more
truthful -- it's really more like ADA, PL1 or perhaps PASCAL: more verbose,
stricter type checking, somewhat higher-level, etc. I spent the '80s dropping
first FETs then gates on a screen to design ASICs -- either of the languages
are a *big* productivity improvement over that era. And my older friends who
cut rubylith in the '70s would probably agree :-).
Perhaps it depends on your background -- if you have had a lot of system
design experience without the benefit of tools, the higher-level abstraction
that VHDL provides may not be that important to you.
Thanks,
Carl Wuebker * HP Roseville * clw@f.rose.hp.com * (916) 785-4296
Article: 2556Any recommendations ons a verilog simulator for a PC? Any comments on the Frontline sim? Where can they be reached? Thanks email to arnaud@ecla.comArticle: 2557
Since we are on the subject of Verilog vs. VHDL I thought it might be of
interest to post/repost the results of a contest sent out by John Cooley a
while back. Verilog seems to have come out the winner although I would still
have to say I prefer VHDL. That is probably however due to the fact that I
learned VHDL first and become annoyed when Verilog won't do something VHDL
does, especially signed arithmetic. In any case, Verilog is probably faster to
use in most cases but just not as powerfull. Here is the comparison:
[ Editor's Note: At the Boston VIUF and at the recent Japanese Synopsys
Users Group meeting, I had quite a few non-Americans ask me for the
write-up of the reader's response to the "You Be The Judge" article
on the Verilog/VHDL design contest. In addition, quite a few American
engineering academics have asked for the same. (Although it appeared
in the Sept. issue of "Integrated System Design" none of these groups
could get a copy because this magazine only targets the American
engineering design community.) Because most Americans are thinking
about Thanksgiving this week, I felt this would be a good time to put
this final write-up on the Internet for the non-Americans. - 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> 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
--
Russell J. Petersen ***** *****
Hewlett Packard ICBD *** /_ __ *** email: russp@valhalla.fc.hp.com
3404 E. Harmony Rd. ** / / /_/ ** Phone: (970) 229-7007
Ft. Collins, CO 80525 *** / *** fax: (970) 229-6580
***** *****
Article: 2558
I used to work for Mentor for several years. (Now with Synopsys) Try
looking at the pintype properties on the pins. For the bidirectional
resistor, they had to be type IO or IXO (I forget, Sorry). I seem to
remember finding the information in a Bold manual for the primitive.
Mark Hampton
rjmyers@ti.com (Bob Myers) wrote:
>I'm having problems with using "bibuf" primitives on an Actel schematic
>simulation. In the design that I'm trying to simulate, I have valid data
>going to the "D" pins and can see either a "1" or "0" on the "E" pins,
>however when I look at the traces for the "Y" or "PAD" pins, I always
>see unknown values. These values appear whether or not I have the pads
>connected (via ripped bus) to the I/O pins of a dram chip (LMC smartmodel).
>
>
>Is there anything special that has to be done to use bibufs in a schematic
>that is going to be simulated?
>
>Any suggestions/advice welcomed.
>
>-Bob
>
Mark L. Hampton
Senior Applications Consultant
SYNOPSYS, Research Triangle Park,NC
hamp@synopsys.com
ooo ooo
O O
Article: 2559
In Article <4a72fs$917@nouvelles.e33.dreo.dnd.ca> Larry Ryan writes:
>Hi:
> I am just beginning to enter the VHDL synthesis field. I would
>like to get a couple of suggestions for a VHDL editor for use on a Windows
>PC. I will be writing code for FPGAs at this point but may expand to ASICs
>in the future. No synthesis tool has yet been chosen but it most likely
>won't be vendor specific. The simulation tool will be Model Technology's
>V-System/VHDL for Windows.
>
> Please email suggestions. I would also like the location of the
>FAQ.
Hi Larry,
We (Saros Technology) have a product called VHDL Turbo Writer
which is a high performance VHDL syntax directed editor running
on the PC under Windows.
It allows the semi-automatic generation of VHDL code and offers
a fast VHDL code development environment on the PC.
VHDL Turbo Writer "knows" about VHDL, automatically generating
VHDL skeleton code from the rich set of templates included within
the package.
The user types in the first two letters of the VHDL Key word
required followed by a space, eg "en <space>" for entity. VHDL
Turbo Writer then creates the entire skeleton of an entity declaration,
colour coded, line numbered and indented for the user to complete.
The code generated is fully compliant with the IEEE 1076 (87 and 93)
standard, and may be used with any other compliant tool.
Integration with Model Technology's V-System VHDL compiler
allows code to be compiled from within VHDL Turbo Writer,
highlighting any errors found.
VHDL Turbo Writer is priced at just $500, with disounts for
multiple copies.
VHDL Turbo Writer features:
Automatic line numbering
Automatic indentation
Automatic colour coding
Rich set of HDL keyword templates
Multiple template styles
Automatic Testbench generation
Automatic component generation
Fully integrated with Model Technology:
Compile from within the editor
Error lines highlighted in edit window
Fast compile/edit loop
Fully featured Windows based text editor:
Multi-window/multi-document edit
Copy between documents
Unlimited undo/redo
Multi-file search and replace
File size limited only by PC memory
File folding
Brief, vi and emacs emulation
Further info and some screen shots can be found on our web page.
try
http://www.saros.co.uk/saros/tw.html
Regards
Jeremy Sonander.
Article: 2560
In article <4cblkm$1f3@rosenews.rose.hp.com>, clw@hprnd.rose.hp.com (Carl Wuebker) writes:
|> peter cnudde sh146 8218 (cnuddep@sh.bel.alcatel.be) wrote:
|> > I can agree that Verilog is the easier one, but this does not mean that
|> > it is the best one.
|>
|> I read somewhere that, to implement a function, VHDL requires about 3X the
|> number of lines that Verilog does. I've also read that the number of bugs
|> in a software program (admittedly, VHDL/Verilog isn't software -- but there
|> are many similarities in the process of writing HDL and software) correlates to
|> the number of lines of code. So, without a good study to refer to, I'd be
|> concerned about the quality implications of using VHDL instead of Verilog.
It is admittedly true that VHDL is more wordy, or redundant than Verilog.
Likewise, Ada is more wordy than C. However, both Ada and VHDL have very
strong syntactical and semantical checkers, and are significantly more
restrictive than C and Verilog on the other hand, that the argument of the
number of lines vs. quality of code does not really hold. On the opposite:
a terse language like C makes the programmer tend to optimize his problems
in the source code rather than leaving the job to a compiler (or with hardware,
to a HLS or logic synthesis system).
With hardware modeling, we are nowadays still at the niveau the software
writers (and compiler writers) were during the fifties and sixties: that time
it was really profitable to write an application in some machine assembler
because early Fortran and Cobol compilers produduced incredibly inefficent
code. In comparison: HW designers now use the modern version of assembler -
Verilog - to fit together their assembler statements (read: gates and flip
flops); with a native assembler this yields much better results for the short
term than using a higher-level language like VHDL. VHDL is not very good for
writing netlists manually (as the output of a schematics capture noone cares
about that). We know what happened over the time with this assembler stuff
in software - there are still some niches where you need it, but in most
cases you use C or even C++ and don't care whether your binary is now 1 K or
100 K. It is just not worth the effort to write an optimized "printf" without
floating point output, if all you print is "%d". Same will happen in the
hardware world in near future: You will have millions or billions of transistors
in a few years: will you care for a single transistor more or less in a
scan-flipflop, even if there are thousands of them in the circuit?
And then, will you still write some 15 bit-synchronous up-down-counter
by hand, which is admittedly much easier in Verilog than with VHDL? Or will
you rather compose an embedded system with a MIPS core (from library),
1MB DPRAM (from library), 1MB ROM (from library), special MPEG codec (from
library), and a suitable ethernet controller (from library). Well, this is
going to be 3 or 4 million gates anyway, and you care about 10 lines
lines in the spec, that expand to 100000 lines of VHDL as the result of a
code generator? The interesting thing in such a system will be the software
in the ROM in the end; you won't tweak the hell out of the MIPS core in order
to save some square mils on the chip and optimize the core to exclude the
three CPU registers which are not used in this application.
--
Dr.-Ing. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD - German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Information Technology| Fax: (+49) 2241 14 2242
| | / Schloss Birlinghoven | "They're not sending back [Win95]
| |/ D-53754 Sankt Augustin, Germany | because it's not selling well; they
WWW: http://borneo.gmd.de/~veit/ | have overordered" (M$ spokesperson)
Article: 2561
A survey of reprogrammable and multi-FPGA systems is now available. It is
titled "The Role of FPGAs in Reprogrammable Systems", and can be retrieved
via WWW from http://www.eecs.nwu.edu/~hauck/publications.html at the
bottom of the page. I've included the abstract below.
I would appreciate any comments/criticisms on this work.
The Roles of FPGAs in Reprogrammable Systems
Scott Hauck
Department of EECS
Northwestern University
Evanston, IL 60208-3118 USA
hauck@eecs.nwu.edu
Abstract
FPGA-based reprogrammable systems are revolutionizing some forms of
computation and digital logic. As a logic emulation system they provide
orders of magnitude speedup over software simulation. As a
custom-computing machine they achieve the highest performance
implementation for many types of applications. As a multi-mode system
they yield significant hardware savings and provide truly generic
hardware.
In this paper we discuss the promise and problems of reprogrammable
systems. This includes an overview of the chip and system architectures
of reprogrammable systems, as well as the applications of these systems.
We also discuss the challenges and opportunities of future reprogrammable
systems.
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Scott A. Hauck, Assistant Professor |
| Dept. of EECS Voice: (708) 467-1849 |
| Northwestern University FAX: (708) 467-4144 |
| 2145 Sheridan Road Email: hauck@eecs.nwu.edu |
| Evanston, IL 60208 WWW: http://www.eecs.nwu.edu/~hauck |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Article: 2562In article <CNUDDEP.96Jan2074140@btmq0f.sh.bel.alcatel.be>, peter cnudde sh146 8218 <cnuddep@sh.bel.alcatel.be> wrote: >Sorry, in the US this might be the case, but in Europe nearly everybody is >using VHDL. (Japan also has a preference towards VHDL) Didn't I read recently (within the last two quarters) that Japanese engineers, once they've tried out Verilog, have grown to like it a lot more then? Now that Verilog is IEEE standard, the balance of users may increase on the Verilog side over the next few years. -- Michael M.Y. Hui (speaking privately) myhui@thlayli.newport-beach.ca.usArticle: 2563
support@saros.co.uk (Jeremy Sonander) wrote: >In Article <4a72fs$917@nouvelles.e33.dreo.dnd.ca> Larry Ryan writes: >>Hi: >> I am just beginning to enter the VHDL synthesis field. I would >>like to get a couple of suggestions for a VHDL editor for use on a Windows >>PC. I will be writing code for FPGAs at this point but may expand to ASICs >>in the future. No synthesis tool has yet been chosen but it most likely >>won't be vendor specific. The simulation tool will be Model Technology's >>V-System/VHDL for Windows. >> >> Please email suggestions. I would also like the location of the >>FAQ. Hi I am using Winedit v3.1 (Shareware - $99, I think for the professional Windows/Win95/NT version). It works very good for VHDL. I cutomized it to do the following. 1. VHDL code highlighting (Thanks to Larry Cameron). 2. Skeleton VHDL code generaion. 3. Automatic Test Bench generation. 4. Compilation and Synthesis from within the editor for the Viewlogic tools. Winedit is very flexable and can be customized without too much effort. Mail me if you want the configuration files. Ps: I have no affiliation with the Winedit writers, just a satisfied user. Regards Rynier van der Watt CSIR (Councel for Scientific and Industrial Research) South Africa.Article: 2564
Holger Veit wrote: > It is admittedly true that VHDL is more wordy, or redundant than Verilog. > Likewise, Ada is more wordy than C. However, both Ada and VHDL have very > strong syntactical and semantical checkers, and are significantly more > restrictive than C and Verilog on the other hand, that the argument of the > number of lines vs. quality of code does not really hold. Hm, my Verilog simulators do some sort of type checking as well. They output warnings, not errors. I tend to remove all warnings of a design (as I tend to remove warnings form C sources aswell, and I usually compile with all warnings on). There is no strong typechecking in Verilog, so I can propagate any 32-bit vector to any other 32 bit port, but I would say, the size of a vector is most of its typing information. Many faults in a program are not typing faults, they are logical faults. No typechecker can check if you implemented a crappy bit of gates instead of what you wanted to, because you got the logic wrong. If you have equivalent wording to describe logic, your number of logical errors will be the same, even while you have to type anoying header files in VHDL. AFAIK the wording of logic expressions in both Verilog and VHDL is equal enough, the more wordy parts of VHDL are declarations of signals, registers and entities. The difference is that Verlog allows you to declare new registers/wires with a few keystorkes, and VHDL allows you to do so with a few editor commands. > On the opposite: > a terse language like C makes the programmer tend to optimize his problems > in the source code rather than leaving the job to a compiler (or with hardware, > to a HLS or logic synthesis system). This is correkt. However, I found that compilers often are not capable to do this sort of optimizations. One example: an ALU adder has to add two values (including incoming carry) _and_ compute if the result is zero. You can write this at ease in a few lines in Verilog (or VHDL), say assign result = in1 + in2; assign zero = (result == 0); but this may not be performant enough. Especially I doubt that my compiler will choose a recursive carry-select adder that propagates "result is zero", too. So I choose to take this adder into a module (making it more wordy, as VHDL is) and write two versions, one behavioral, as above, and one structural. [...] > And then, will you still write some 15 bit-synchronous up-down-counter > by hand, which is admittedly much easier in Verilog than with VHDL? Or will > you rather compose an embedded system with a MIPS core (from library), > 1MB DPRAM (from library), 1MB ROM (from library), special MPEG codec (from > library), and a suitable ethernet controller (from library). Well, this is > going to be 3 or 4 million gates anyway, and you care about 10 lines > lines in the spec, that expand to 100000 lines of VHDL as the result of a > code generator? The interesting thing in such a system will be the software > in the ROM in the end; you won't tweak the hell out of the MIPS core in order > to save some square mils on the chip and optimize the core to exclude the > three CPU registers which are not used in this application. I would guess that I won't be aware of the language I use for this purpose. I just drag and drop those library parts and press the "synthesize" button. And there is no reason why this can't be done with Verilog. I bet the spec won't expand to more than some 100 lines, because usually library CPU cores come fully synthesized. I always can figure out the 68k core on a die photo of some 683xx CPUs. Perhaps this is different with a MIPS core, because AFAIK Moto still uses the same floorplans for their 68k they used in 1980, and noone rewrote the 68k to a HDL. And if I had to build a 15 bit synchronous up-down-counter on this chip for some special purpose (or perhaps a special decryption scheme used by the vendor of this set-top-box for his pay-TV), and I don't have one in the library, I hope, I can specify it in Verilog (even if the rest is VHDL). -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/Article: 2565
I know it's a silly question, but I don't have any books with the anwer on hand. Thanks. - sent via an evaluation copy of BulkRate (unregistered). ***************************************************************** * On-Core BBS * Tinton Falls, New Jersey * A FirstClass BBS * * 2 Lines * (908) 842-1973 * USR Courier 28.8 * ****************************************************************Article: 2566
rjmyers@ti.com (Bob Myers) wrote: >I'm having problems with using "bibuf" primitives on an Actel schematic >simulation. In the design that I'm trying to simulate, I have valid data >going to the "D" pins and can see either a "1" or "0" on the "E" pins, >however when I look at the traces for the "Y" or "PAD" pins, I always >see unknown values. These values appear whether or not I have the pads >connected (via ripped bus) to the I/O pins of a dram chip (LMC smartmodel). > > >Is there anything special that has to be done to use bibufs in a schematic >that is going to be simulated? what is driving the PAD? are you simulating just the schematic, or is it connected to something else? You may want to experiment with the force type you're driving the PAD with. Even if your default force type is set it's not always used correctly. There are several bugs (features!) that we've seen dealing with this here at TI. Todd 903-868-7088 a0460010@shsun3.dseg.ti.comArticle: 2567
In article <DKKAtI.3r@world.std.com> ecla@world.std.com (alain arnaud) writes: >Any recommendations ons a verilog simulator for a PC? I have used Silos III from Simucad and have had very good success with it. Tom Dillon DILLON ENGINEERING 2017 Continental Place Suite 5 Mount Vernon, WA 98273-5649 e-mail: tom@dilleng.wa.com Voice : (360) 424-3794 FAX : (360) 424-5894Article: 2568
veit@mururoa.gmd.de (Holger Veit) wrote: >With hardware modeling, we are nowadays still at the niveau the software >writers (and compiler writers) were during the fifties and sixties: that time >it was really profitable to write an application in some machine assembler >because early Fortran and Cobol compilers produduced incredibly inefficent >code. In comparison: HW designers now use the modern version of assembler - >Verilog - to fit together their assembler statements (read: gates and flip >flops); with a native assembler this yields much better results for the short >term than using a higher-level language like VHDL. I agree with most of your comments, although I'd use a slightly different comparison when equating the hardware & software design models. I'd put: Assembler <--> schematic capture: Gives the fastest & tightest results for small, human-managable blocks. Least portable. C <--> RTL VHDL or Verilog: You sacrifice some performance and use a bit more memory/ a few more gates in order to improve design productivity, increase portability and improve complexibility managements to cope with much larger designs. I don't think there's really much difference between VHDL & Verilog when you're just coding synthesisable RTL - Verilog may well be a little "closer to the gates" as someone else said. C++ and other OO languages <--> behavioural synthesis and perhaps yet-to-be- developed hardware design techniques: the two trends of gates getting and designs becoming more complex will push us to still higher levels of abstraction. (Where did I see that recent article that was predicting 40-200 million gate ASICs in the next 10 years ?) So, in terms of what it means for the VHDL vs Verilog debate, I'd guess: Short term: more people will start coding RTL as logic synthesis tools continue to mature and the results get closer & closer to the best you can do with schematic capture. Most likely this will continue to fuel the debate over which language is better for designing strange-modulo counters (sigh). Medium term: designs get too large to efficiently code/debug/manage entirely in RTL and behavioural synthesis will be used more. The language debate should lessen as VHDL & Verilog are used less for design entry and more as an intermediate format. System-level modelling will be more important, and VHDL may have an edge over Verilog in this case. Long term: probably neither language will cut it for really huge designs, and there'll be a slower generational change to something higher-level - much as with the move to C++ that's happening in the software world at present. Career advice ? Certainly you should learn to write RTL code in either language (preferably both). You should probably also spend some time learning the ins & outs of system simulation - try out the relevant features of VHDL. Also, see if you can get to play with some behavioural synthesis tools - perhaps at a trade show or the next time you're visiting your friendly EDA vendor. You may not be using them on the job any time soon, but it's worth keeping an eye on what's happening in this area. Cheers, Ken -- Ken Wood - Mentor Technologies / EDA Solutions email: ken@eda.com.au Office: Sydney, Australia Tel: 61-2-413 4600 Fax: 61-2-413 4622 Tech Support: support@eda.com.au Other Enquiries: info@eda.com.au Mentor Graphics: http://www.mentorg.com/ MT: ftp://ftp.eda.com.au/pub/Article: 2569
Ken Wood <ken@eda.com.au> wrote: >developed hardware design techniques: the two trends of gates getting >and designs becoming more complex Oops ! That should say: "gates getting CHEAPER and designs becoming more complex". Ken -- Ken Wood - Mentor Technologies / EDA Solutions email: ken@eda.com.au Office: Sydney, Australia Tel: 61-2-413 4600 Fax: 61-2-413 4622 Tech Support: support@eda.com.au Other Enquiries: info@eda.com.au Mentor Graphics: http://www.mentorg.com/ MT: ftp://ftp.eda.com.au/pub/Article: 2570
January 8th - Hardware Objects and Reconfigurable Computing Imagine an array of custom architected compute nodes such that each node processes data and passes its result on to a (logical) neighbor node for further processing - a distributed vector processor - a data flow machine - perhaps a multidimensional systolic array (of nodes). Suppose the customization of the nodes could be crafted on the fly - maybe during a context switch - by reconfiguration software. Perhaps a self-adaptive Neural Network system might be so implemented. The high performance of ASIC's at much lower development costs and, of course, hardware is intrinsically parallel. Now embed this in the framework of a Distributed Shared Memory machine architecture enabled by a technology such as SCI. It can be done and it is being done! Steve Casselman, President, Virtual Computer Corp. and John Schewel will present 1)ÊHardware Objects - Design, Implementation, and performance benchmarks for use in application programs, and 2) Reconfigurable Computer Systems - the Co-Processor approach to implementing reconfigurable hardware in existing systems and true 'compute-thru' networks. VCC recently built an entire computer using Xilinx run-time reconfigurable FPGA's. The main meeting starts promptly at 7:30PM at Sun Microsystems at 901 San Antonio Road in Palo Alto. This is just off the southbound San Antonio exit of 101. Northbound travelers also exit at San Antonio and take the overpass to the other side of 101. A discussion of member projects currently underway and other issues of interest to entrepreneurs follows immediately thereafter at 9PM. Please be prompt; as usual, we expect a large attendance; don't be left out or left standing. There is a $10 fee for non-members and members will be admitted free. Yearly membership fee is $50. -- B. Mitchell Loebel parallel@netcom.com Director - Strategic Alliances and Partnering 408 732-9869 PARALLEL Processing ConnectionArticle: 2571
The PARALLEL Processing Connection is an entrepreneurial association; we mean to assist our members in spawning very successful new businesses involving parallel processing. Our meetings take place on the second Monday of each month at 7:30 PM at Sun Microsystems at 901 South San Antonio Road in Palo Alto, California. Southbound travelers exit 101 at San Antonio ; northbound attendees also exit at San Antonio and take the overpass to the other side of 101. There is an $10 visitor fee for non- members and members ($50 per year) are admitted free. Our phone number is (408) 732-9869 for a recorded message about upcoming meetings; recordings are available for those who can't attend - please inquire. Since the PPC was formed in late 1989 many people have sampled it, found it to be very valuable, and even understand what we're up to. Nonetheless, certain questions persist. Now, in our seventh year of operation, perhaps we can and should clarify some of the issues. For example: Q. What is PPC's raison d'etre? A. The PARALLEL Processing Connection is an entrepreneurial organization intent on facilitating the emergence of new businesses. PPC does not become an active member of any such new entities, ie: is not itself a profit center. Q. The issue of 'why' is perhaps the most perplexing. After all, a $50 annual membership fee is essentially free and how can anything be free in 1996? What's the payoff? For whom? A. That's actually the easiest question of all. Those of us who are active members hope to be a part of new companies that get spun off; the payoff is for all of us -- this is an easy win-win! Since nothing else exists to facilitate hands-on entrepreneurship, we decided to put it together ourselves. Q. How can PPC assist its members? A. PPC is a large technically credible organization. We have close to 100 paid members and a large group of less regular visitors; we mail to approximately 400 engineers and scientists (primarily in Silicon Valley). Major companies need to maintain visibility in the community and connection with it; that makes us an important conduit. PPC's strategy is to trade on that value by collaborating with important companies for the benefit of its members. Thus, as an organization, we have been able to obtain donated hardware, software, and training and we've put together a small development lab for hands-on use of members at our Sunnyvale office. Further, we've been able to negotiate discounts on seminars and hardware/software purchases by members. Most important, alliances such as we described give us an inside opportunity to JOINT VENTURE SITUATIONS. Q. As an attendee, what should I do to enhance my opportunities? A. Participate, participate, participate. Many important industry principals and capital people are in our audience looking for the 'movers'! For further information contact: -- B. Mitchell Loebel parallel@netcom.com Director - Strategic Alliances and Partnering 408 732-9869 PARALLEL Processing ConnectionArticle: 2572
lull@acm.org (John Lull) writes: ] In the waning years of the 20th century, rob-l@superlink.net (Rob-L) ] wrote (with possible deletions): ] ] > : As an anology - how many times would you buy from a car manufacturer ] > : if their cars died shortly after the warranty period was up? ] > ] > Depends why it dies and how long the warranty is. If it's an otherwise ] > great car, and it's a $.30 fuse that blows after 20,000 miles, is it ] > worth it to buy cars that you don't like just to avoid that? ] ] This discussion was not about an easily-replaceable fuse. It was ] about designing a car (or other unit) using a device you know has a ] severely limited life, and which you know will not be available for ] replacement at the end of that lifetime. ] ] It's about designing a car using an engine computer that you know is ] going to quit in 5 years, when you know you won't be around to provide ] replacement engine computers then. ] ] That, IMO, is reprehensible. Not if the car is priced accordingly, it isn't. If such a car cost 70% of what a comparable "unlimited lifetime" car cost, it would be a good deal (economically) for most people. And it might be an environmentally good thing too, if the old cars were recycled, and new cars were less ecologically harmful. The key thing is wether the customer knows the car will only last five years. OF course, the whole discussion is pretty unreal vis-a-vis comp.arch, since no one is designing computers that fail that young, so ... -- Dennis O'Connor doconnor@sedona.intel.com i960(R) Architecture and Core Design Not an Intel spokesman. TIP#518 Fear is the enemy.Article: 2573
VHSIC Hardware Description Language (VHSIC == Very High Speed Integrated Circuits) see "VHDL: Analysis and Modeling of Digital Systems" by Z. Navabi (section 2.1, page 16). phil .__.__.__.__.__.__.__.__.__.__.__.__.__.__.__.__.__.__.__.__. On 3 Jan 1996, Ben Klass wrote: > I know it's a silly question, but I don't have any books with the anwer on > hand. > > Thanks. > > - sent via an evaluation copy of BulkRate (unregistered). > ***************************************************************** > * On-Core BBS * Tinton Falls, New Jersey * A FirstClass BBS * > * 2 Lines * (908) 842-1973 * USR Courier 28.8 * > **************************************************************** > >Article: 2574
Ben Klass wrote: > > I know it's a silly question, but I don't have any books with the anwer on > hand. > > Thanks. > > - sent via an evaluation copy of BulkRate (unregistered). > ***************************************************************** > * On-Core BBS * Tinton Falls, New Jersey * A FirstClass BBS * > * 2 Lines * (908) 842-1973 * USR Courier 28.8 * > **************************************************************** VHDL is an acronym for VHSIC Hardware Description Language (VHSIC is an acronym for Very High Speed Integrated Circuits). The above defintions came from J. Bhasker's book "A VHDL Primer" which provides a reasonable introduction to the language. Regards, Jeffrey L. Hutchings
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