Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 2550

Article: 2550
Subject: xilinx xxx.cst files
From: maya@asp.co.il (Maya Reuveni)
Date: Mon, 1 Jan 1996 10:54:54 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Career value: VHDL or Verilog?
From: cnuddep@sh.bel.alcatel.be (peter cnudde sh146 8218)
Date: 02 Jan 1996 06:41:40 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Gate-level description of 8051 to become available
From: frederik@cicl02.seri.philips.nl (L.L. Frederiks)
Date: 2 Jan 1996 12:58:57 GMT
Links: << >>  << T >>  << A >>
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: 2553
Subject: Re: Need help: Actel "bibuf" working with Quicksim II (Men 8.4)
From: mlbates@eag.unisysgsg.com (Michael L. Bates)
Date: 2 Jan 1996 14:58:21 GMT
Links: << >>  << T >>  << A >>
In 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.com



Article: 2554
Subject: Re: Career value: VHDL or Verilog?
From: jlodman@alumni.caltech.edu (Michael Lodman)
Date: 2 Jan 1996 16:09:09 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Career value: VHDL or Verilog?
From: clw@hprnd.rose.hp.com (Carl Wuebker)
Date: 2 Jan 1996 16:14:14 GMT
Links: << >>  << T >>  << A >>
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: 2556
Subject: Verilog simulator for PC
From: ecla@world.std.com (alain arnaud)
Date: Tue, 2 Jan 1996 16:22:30 GMT
Links: << >>  << T >>  << A >>
Any recommendations ons a verilog simulator for a PC?
Any comments on the Frontline sim? Where can they be reached?

Thanks

email to arnaud@ecla.com



Article: 2557
Subject: Re: Career value: VHDL or Verilog?
From: Russell Petersen <russp>
Date: 2 Jan 1996 16:57:55 GMT
Links: << >>  << T >>  << A >>

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
Subject: Re: Need help: Actel "bibuf" working with Quicksim II (Men 8.4)
From: "Mark L. Hampton" <hamp@synopsys.com>
Date: 2 Jan 1996 17:26:28 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: VHDL Editor for Windows PC, Suggestions?
From: support@saros.co.uk (Jeremy Sonander)
Date: 2 Jan 1996 17:33:50 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Career value: VHDL or Verilog?
From: veit@mururoa.gmd.de (Holger Veit)
Date: 2 Jan 1996 18:09:37 GMT
Links: << >>  << T >>  << A >>
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
Subject: Survey of Reprogrammable Systems
From: hauck@eecs.nwu.edu (Scott A. Hauck)
Date: Tue, 02 Jan 1996 12:29:34 -0600
Links: << >>  << T >>  << A >>
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: 2562
Subject: Re: Career value: VHDL or Verilog?
From: huimm@nb.rockwell.com (Michael M.Y. Hui)
Date: Tue, 2 Jan 1996 20:40:20 GMT
Links: << >>  << T >>  << A >>
In 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.us


Article: 2563
Subject: Re: VHDL Editor for Windows PC, Suggestions?
From: Rynier van der Watt <arvdwatt@.csir.co.za>
Date: 3 Jan 1996 08:14:41 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Career value: VHDL or Verilog?
From: Bernd Paysan <paysan@informatik.tu-muenchen.de>
Date: Wed, 03 Jan 1996 17:03:08 +0100
Links: << >>  << T >>  << A >>
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
Subject: What does VHDL stand for?
From: Ben_Klass@oncore.com (Ben Klass)
Date: 03 Jan 1996 16:55:43 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Need help: Actel "bibuf" working with Q
From: Todd Thuss
Date: 3 Jan 1996 17:24:00 GMT
Links: << >>  << T >>  << A >>

  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.com







Article: 2567
Subject: Re: Verilog simulator for PC
From: tom@dilleng.wa.com (Tom Dillon)
Date: Wed, 03 Jan 96 09:39:18 -0800
Links: << >>  << T >>  << A >>
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-5894


Article: 2568
Subject: Re: Career value: VHDL or Verilog?
From: Ken Wood <ken@eda.com.au>
Date: 4 Jan 1996 02:45:14 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Career value: VHDL or Verilog?
From: Ken Wood <ken@eda.com.au>
Date: 4 Jan 1996 02:54:09 GMT
Links: << >>  << T >>  << A >>
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
Subject: The PARALLEL Processing Connection - January Meeting Notice
From: parallel@netcom.com (B. Mitchell Loebel)
Date: Thu, 4 Jan 1996 10:50:45 GMT
Links: << >>  << T >>  << A >>

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 Connection 


Article: 2571
Subject: The PARALLEL Processing Connection - What Is It?
From: parallel@netcom.com (B. Mitchell Loebel)
Date: Thu, 4 Jan 1996 10:51:52 GMT
Links: << >>  << T >>  << A >>

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 Connection 


Article: 2572
Subject: Re: [q][Reverse Engineering Protection]
From: doconnor@sedona.intel.com (Dennis O'Connor~)
Date: 4 Jan 96 3:23:03
Links: << >>  << T >>  << A >>

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
Subject: Re: What does VHDL stand for?
From: Phil Sailer <sailer@lss1038>
Date: Thu, 4 Jan 1996 10:00:35 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: What does VHDL stand for?
From: "Jeffrey L. Hutchings" <jhseng@xmission.com>
Date: Thu, 04 Jan 1996 10:22:45 -0700
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search