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 2300

Article: 2300
Subject: Re: [q][Reverse Engineering Protection]
From: ejessen@ix.netcom.com (Erik Jessen)
Date: Fri, 17 Nov 95 19:37:46 GMT
Links: << >>  << T >>  << A >>
In article <DI6H3x.5Lz@world.std.com>,
   jcooley@world.std.com (John Cooley) wrote:
>Jyri Hamalainen <jyrih@cat.co.za> wrote:
>>Does anyone here know anything about protecting ASIC's from reverse 
>>engineering? OR logic camourflaging? With modern technologies such as 
>>electron beam induced current imaging and Charge induced voltage 
>>alteration (Scania Labs), I suppose there are no more solutions to 
>>protecting ones investment?

Jyri,

I've used some special layout cells we called "fake gates" - they looked like
normal combinatoric-logic cells, but actually had their outputs shorted to 
either VDD or GND.  If someone reverse-engineered the design, and didn't 
notice, it would cause the design to behave erratically, every 3-5 days.

As a practical matter, if you want to keep someone from copying your design, 
simply design it so that you can't debug it yourself - put in lots of async. 
logic, race conditions, etc.  And then lay it out so that the timing is right 
on the edge.  If you're really careful, build up some RC circuits using normal 
routing - if someone else' process has different parameters, the circuit will 
fail erratically (or, even better, just corrupt the data, like toggling the 
parity bit and one other bit).

:>

Erik


Article: 2301
Subject: Re: [Q] FPGA Software for Linux
From: pkh@fantti.tky.hut.fi (Petri Havanto)
Date: 17 Nov 1995 20:14:04 GMT
Links: << >>  << T >>  << A >>
In article <1995Nov16.081949@timp.ee.byu.edu> wirthlim@timp.ee.byu.edu (Michael J. Wirthlin) writes:
   >In article <48eu90$gc8@rs18.hrz.th-darmstadt.de>, bon@elektron.ikp.physik.th-darmstadt.de (Uwe Bonnes) writes:
   >>|> Hallo,
   >|> 
   >|> is there any software to design FPGAs available for the Linux Operating
   >|> system or planned to be available in the next future?
   >|> 

   >There is a schematic capture program called chipmunk available in Linux.
   >Somebody mentioned that they would port the Xilinx libraries into chipmunk

The Alliance-tools do offer some support for some Xilinx-chips (of the
3000 family ?).  I haven's checked this out yet, no room on the
current hard disk left. Anyway, you may like to check their ftp-site,
ftp.ibp.fr, [132.227.60.2], /ibp/softs/masi/alliance.

#define DISCLAIMER "I have nothing to do with the software or the project, I'm just an
interested outsider."

Petri



Article: 2302
Subject: Re: X-Blox...The good, bad and ugly
From: jcooley@world.std.com (John Cooley)
Date: Fri, 17 Nov 1995 21:55:40 GMT
Links: << >>  << T >>  << A >>
John McCluskey  <jbm> wrote:
>X-Blox is OK if you are using schematics only, and you have the intention to
>NEVER switch to another FPGA family, or switch to an HDL like VHDL or Verilog.

X-Blox is Xilinx's version of LPM's (or for those familiar with Synopsys, it's
like a Xilinx specific DesignWare library with limited information in it.)
The complaint that John McCluskey is saying is the number 1 problem many
engineers have had with X-Blox -- it locks you into Xilinx-only 
implementations -- which is rather frustrating when you run into parts
availability shortages or better competing FPGA's suddenly coming out from
other FPGA vendors.

Other than the business issues, technically X-Blox with Synopsys seems to
work very well from what other engineers are telling me.  (That is, when
Synopsys, Inc. and Xilinx, Inc. publically decided to jump in bed with each
other as <hoopla!> <hoopla!> "technology partners" [as the world's biggest
synthesis and the world's biggest FPGA vendors] is was more than just noise
for articles in EE Times -- they really worked on improving their joint
design flow!)
                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3713 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 2303
Subject: Re: Industry Trends
From: Ray Andraka <randraka@ids.net>
Date: 18 Nov 1995 00:15:20 GMT
Links: << >>  << T >>  << A >>
rob@pe1chl.ampr.org (Rob Janssen) wrote:
 
> >SRAM based devices are being used increasingly for "reconfigurable computers".
> 
> >See;
> > http://www.io.com/~guccione/HW_list.html
> > http://www.reconfig.com/
> 
> >In these applications the devices are reprogrammed in circuit. This is a growing 
> >application of SRAM based FPGAs.
> 
> SRAM??  Shouldn't that read EEPROM?
> 
No, SRAM is correct. In the reconfigurable computing, the logic is
changed essentially on the fly.  An example would be a signal 
processor whose function is modified by a controller in according to the
type of signal being processed.  A practical example might be a 
process that is not completely pipelined so that intermediate results
get stored, the hardware is changed, and then the processing continues
through the same FPGA with a completely different configuration.
There are some people who are working toward dynamic instruction set
computers and the like using these techniques.

Ray Andraka
Chairman, the Andraka Consulting Group
401/884-7930   FAX 401/884-7950
email randraka@ids.net
 
The Andraka Consulting Group is a digital hardware design firm specializing 
in high performance FPGA designs.  Services include complete design, development, 
simulation, and integration of these devices and the surrounding circuits.  We 
also evaluate,troubleshoot, and improve existing designs. Please call or write 
for a free brochure.



Article: 2304
Subject: Re: Industry Trends
From: elvey@hal.COM (Dwight Elvey)
Date: 18 Nov 1995 04:16:00 GMT
Links: << >>  << T >>  << A >>
In article <DI4yEG.1v7@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) writes:
|> In <48d3vm$945@harry.lloyd.com> Rocky Awalt <rocky@trg.com> writes:
|> 
|> >Erich,
|> 
|> >SRAM based devices are being used increasingly for "reconfigurable computers".
|> 
|> >See;
|> > http://www.io.com/~guccione/HW_list.html
|> > http://www.reconfig.com/
|> 
|> >In these applications the devices are reprogrammed in circuit. This is a growing 
|> >application of SRAM based FPGAs.
|> 
|> SRAM??  Shouldn't that read EEPROM?
|> 
|> Rob
|> -- 
|> +------------------------------------+--------------------------------------+
|> | Rob Janssen         rob@knoware.nl | AMPRnet:   rob@pe1chl.ampr.org       |
|> | e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
|> +------------------------------------+--------------------------------------+

Hi Rob
 Actually both. I believe Xilinx's has SRAM type programmable
logic stuff. These are usually reloaded at powerup time by
some simple serial loader method. One could reload at any time.
Dwight


Article: 2305
Subject: Re: Industry Trends
From: "gyoung.sna.com" <gyoung@sna.com>
Date: 18 Nov 1995 05:02:17 GMT
Links: << >>  << T >>  << A >>
I have one major bitch!!!

Why do I need oodles of RAM, disk space, and computational power to 
compile simple combinatorial PALs and other simple EPLDs?

If you want to broaden your customer base, how about some simple tools 
for simple jobs? Simple jobs are, after all, a majority of the jobs!!!




Article: 2306
Subject: Re: [q][Reverse Engineering Protection]
From: Mike Saltmarsh <r27863@email.sps.mot.com>
Date: 18 Nov 1995 14:08:58 GMT
Links: << >>  << T >>  << A >>
Jyri Hamalainen <jyrih@cat.co.za> wrote:
>Does anyone here know anything about protecting ASIC's from reverse 
>engineering? OR logic camourflaging? With modern technologies such as 
>electron beam induced current imaging and Charge induced voltage 
>alteration (Scania Labs), I suppose there are no more solutions to 
>protecting ones investment?

FYI, CIVA (from Sandia labs), is intended to be used as a failure 
analysis technique. Its purpose is to find open metal runs on IC's. As 
far as I know, it has no characterization/reverse engineering 
applications. EBIC only has minimal use in this area. It will "light up" 
junctions, but only if there are biased in certain states.

Mike




Article: 2307
Subject: Re: [q][Reverse Engineering Protection]
From: indovina@cse.fau.edu (Mark Indovina)
Date: 18 Nov 1995 14:21:24 GMT
Links: << >>  << T >>  << A >>
In article <DI6H3x.5Lz@world.std.com> jcooley@world.std.com (John Cooley) writes:
>Jyri, one clever idea for protecting designs in chips I heard of was
>using Xilinx FPGA's that were programmed once at the factory with a
>small battery attached after programing.  (That is, the power-up
>program for the Xilinx part was NOT included in the PCB.)  What this
>did was make the circuit unreversable but still functional.
>

John,

Do you remember if the XACT download interface pins were
"de-activated" somehow? If not, I could still hook up my download
cable and access the device internals...

Regards,
Mark
-- 
/* Mark A. Indovina, Adjunct Professor       indovina@sunrise.cse.fau.edu */
/* College of Engineering    Department of Computer Engineering & Science */
/* Florida Atlantic University                                            */
/* 777 Glades Road                          Boca Raton, FL 33431-0991 USA */


Article: 2308
Subject: Re: Industry Trends
From: devb@lys.vnet.net (David Van den Bout)
Date: 18 Nov 1995 09:26:53 -0500
Links: << >>  << T >>  << A >>
In article <48jpcp$mlt@tweety.sna.com>, gyoung.sna.com <gyoung@sna.com> wrote:
>I have one major bitch!!!
>
>Why do I need oodles of RAM, disk space, and computational power to 
>compile simple combinatorial PALs and other simple EPLDs?
>
>If you want to broaden your customer base, how about some simple tools 
>for simple jobs? Simple jobs are, after all, a majority of the jobs!!!

You might try ALTERA's free PLDSHELL tool.  It doesn't take much disk or
need much RAM and you can program a lot of the smaller PLDs.  That's all 
I use for the smaller devices.  I only crank up the mega-MAX+PLUS tools 
when I need to design with MAX 7000-10000 type devices.


-- 
|| Dave Van den Bout  --  XESS Corp. ||
|| 2608 Sweetgum Dr., Apex, NC 27502 ||
|| (919) 387-0076 FAX:(919) 387-1302 ||
|| devb@xess.com       devb@vnet.net ||


Article: 2309
Subject: Re: [q][Reverse Engineering Protection]
From: Eric@wolf359.exile.org (Eric Edwards)
Date: Sat, 18 Nov 1995 19:40:16 GMT
Links: << >>  << T >>  << A >>
In article <DI6H3x.5Lz@world.std.com>, John Cooley writes:

> Jyri, one clever idea for protecting designs in chips I heard of was
> using Xilinx FPGA's that were programmed once at the factory with a
> small battery attached after programing.  (That is, the power-up
> program for the Xilinx part was NOT included in the PCB.)  What this
> did was make the circuit unreversable but still functional.

Interesting technique.  How long did the battery last?  How big did it
have to be?  In certain designs this might be a suitable alternative to
adding board space for the configuration PROMs.

----
If reply fails due to uunet botching DNS again, try eric@wolf359.us.com
Remember the home hobbyist computer: Born 1975, died April 29, 1994



Article: 2310
Subject: Re: [Q] FPGA Software for Linux
From: "Ingo Cyliax" <cyliax@cs.indiana.edu>
Date: Sat, 18 Nov 1995 16:15:02 -0500 (EST)
Links: << >>  << T >>  << A >>
In article <1995Nov16.081949@timp.ee.byu.edu>,
Michael J. Wirthlin <wirthlim@timp.ee.byu.edu> wrote:
>
>In article <48eu90$gc8@rs18.hrz.th-darmstadt.de>, bon@elektron.ikp.physik.th-darmstadt.de (Uwe Bonnes) writes:
>|> Hallo,
>|> 
>|> is there any software to design FPGAs available for the Linux Operating
>|> system or planned to be available in the next future?
>|> 
>
>There is a schematic capture program called chipmunk available in Linux.
>Somebody mentioned that they would port the Xilinx libraries into chipmunk
>a few months ago, but I don't know the status of their work. As far as I
>am aware, the manufacturer place and route tools are only available on 
>standard operating system platforms.

That was probably me. I finished an XNF netlister for Chipmunk which
I can make available. It can work with the Actel library by translating
some of the Actel gates that have a one-to-one correspondence. I haven't
had time to come up with a specific Xilinx library for Chipmunk. It's 
pretty tedious, and the Actel gates work OK for us at this point.

We have generated several XC3000 designs for a robot controller, as
well as XC3000 and XC4000 designs for the Xilinx demo board.

I also have a serial Atmel EEPROM programmer which runs from a PC
parallel port. The code is in qbasic(yuck) but it was a quick and
dirty one day project.

If there is enough interest, I can make the software available via
anon. ftp.

You still need to have access  to Xilinx's software to be able to
compile the XNF netlists for a design. However, if you use diglog
you now only need the low-end core package (good for small parts 
and runs under DOS) which costs $1000, instead of the low-end 
Viewlogic package which sells for $2500. For the $1000 package,
you even get the little demo board (switches, LED's XC3000/4000).

I do wish Xilinx had a cheap package for Linux or equiv., which
would be great for hobbyist, students et., Or would releases the
bitstream information so that someone can come up with cheap/free
Unix/Linux compiler. I don't think it would hurt their sales of
software to make the information available for their older parts,
like XC3000. After all, commercial designers would still buy the
software from Xilinx.

See ya, -ingo
-- 
/* Ingo Cyliax, cyliax@cs.indiana.edu, +1 812 333 4854, +1 812 855 6984 (day) */


Article: 2311
Subject: Re: [q][Reverse Engineering Protection]
From: fliptron@netcom.com (Philip Freidin)
Date: Sun, 19 Nov 1995 02:11:10 GMT
Links: << >>  << T >>  << A >>
In article <48kq54$6u8@cybernet.cse.fau.edu> indovina@cse.fau.edu (Mark Indovina) writes:
>In article <DI6H3x.5Lz@world.std.com> jcooley@world.std.com (John Cooley) writes:
>>Jyri, one clever idea for protecting designs in chips I heard of was
>>using Xilinx FPGA's that were programmed once at the factory with a
>>small battery attached after programing.  (That is, the power-up
>>program for the Xilinx part was NOT included in the PCB.)  What this
>>did was make the circuit unreversable but still functional.
>>
>
>John,
>
>Do you remember if the XACT download interface pins were
>"de-activated" somehow? If not, I could still hook up my download
>cable and access the device internals...
>
>Regards,
>Mark
>-- 
>/* Mark A. Indovina, Adjunct Professor       indovina@sunrise.cse.fau.edu */
>/* College of Engineering    Department of Computer Engineering & Science */
>/* Florida Atlantic University                                            */
>/* 777 Glades Road                          Boca Raton, FL 33431-0991 USA */

Part of the bitstream used to configure the device has a code that controls
a diagnostic function called 'readback'. It has 3 modes:

1) As many as you want. This mode lets you readback the contents over and 
   over. This is usefull for debug, as the readback stream includes not
   just the config data, but also the state of the CLB outputs, and other
   stuff. The XChecker hw/sw can extract useful info from this.

B) Once only. This is the mode that is appropriate for what john was 
   describing. At the factory, you config the device and read it back
   once to check that the data is all ok, then the chip prohibits
   readback until you reprogram it. This is extremely secure, as there
   is no way to get at the config data after the one readback. As John
   said, you maintain the config with battery backup. On XC3000 devices
   in powerdown mode, this can take as little as 5uA.

III) Readback never. just like (B), except you dont bother checking
   what you wrote.


Philip Freidin.



Article: 2312
Subject: Re: [q][Reverse Engineering Protection]
From: ljbartel@naomi.b23b.ingr.com (Les Bartel)
Date: 19 Nov 1995 02:37:53 GMT
Links: << >>  << T >>  << A >>
> Jyri Hamalainen <jyrih@cat.co.za> wrote:
> >Does anyone here know anything about protecting ASIC's from reverse 
> >engineering? OR logic camourflaging? With modern technologies such as 
> >electron beam induced current imaging and Charge induced voltage 
> >alteration (Scania Labs), I suppose there are no more solutions to 
> >protecting ones investment?

I'm no expert on ASIC's, but can offer some personal speculation on how
this may be done.

I would assume that the person reverse engineering (PRE) the device is
applying values to the inputs and watching the outputs, looking for the
relationship.  If you were to design the ASIC so that certain input values
would cause the chip to self-destruct, that could be rather effective.  Of
course, you would have to ensure that your application would never apply
that bit pattern to the inputs.  That doesn't prevent the PRE the device
from popping the lid and examining the circuit under a microscope.  To
defeat this, you would have to make the die appear to be something it isn't
:-).  Another thing that could be done to make the job more difficult for
the PRE the device is to implement all kinds of strange functions (like a
very complex state machine) that are never used.

 - les

-- 
        Les Bartel
  Intergraph Corporation
   Electronics Division
      Huntsville, AL
    ljbartel@ingr.com
      (205) 730-8537


Article: 2313
Subject: options for VHDL or Verilog simulation/synthesis < $10,000 ?
From: eric@wolf359.exile.org (Eric Edwards)
Date: Sun, 19 Nov 1995 10:17:45 GMT
Links: << >>  << T >>  << A >>
I am looking for simulation and synthesis targeted to mid size CPLD's. 
The choice of CPLD's has not yet been made.  That decision will likely be
made based on software support.

I would rather not use a product tied to a particular vender's chips. 
Total software cost needs to be less than $10,000.  The budget is tight. 
I can come in signicantly under $10,000 it that much better.

Either Verilog or VHDL will do.  However, I have not encounted low cost
Verilog synthesis so VHDL is more probable.  

Either PC or Unix platorm is acceptable.

So far I am leaning toward Minc's PLDesigner-XL.  It helps that they have
a 50% off sale going on now on their Windows version.

Synario is another option.

Viewlogic gets very expensive once all the necessary pieces are assembled.

Any pros and cons on the above products?  Any good alternatives that I
have overlooked?

----
If reply fails due to uunet botching DNS again, try eric@wolf359.us.com
Remember the home hobbyist computer: Born 1975, died April 29, 1994



Article: 2314
Subject: Re: NeoCAD and AT&T vs. Xilinx
From: fink@post.tau.ac.il (Udi Finkelstein)
Date: Sun, 19 Nov 1995 12:21:52 GMT
Links: << >>  << T >>  << A >>
jcooley@world.std.com (John Cooley) wrote:

>Overall, quite a few users were rather pissed about Xilinx buying NeoCAD
>because NeoCAD was the *only* general FPGA P&R tool around -- making
>it purely Xilinx specific means that if users what to use Actel or Altera
>or QuickLogic or Lattice or AT&T FPGA's they'd *have* to learn each
>specific FPGA vendor's P&R tools.

I've been using ATMEL's P&R tool for their AT60XX components. It's
called Figaro, and it's made by Cadence. I was told it may support
other manufacturer's families (which would qualify if as a general
FPGA P&R tool), but I haven't seen this mentioned in any other place.
Can anyone comment on this?

>                           - John Cooley
>                             Part Time EDA Consumer Advocate
>                             Full Time ASIC, FPGA & EDA Design Consultant

Udi




Article: 2315
Subject: Re: Xilinx XACT Windows Version
From: acher@informatik.tu-muenchen.de (Georg Acher)
Date: 19 Nov 1995 23:40:23 GMT
Links: << >>  << T >>  << A >>


>I have trouble installing XAct for Windows. The problem is that the dongle 
>can't be found by the software. Any idea??
>The printerport works fine with an HP-Laserjet.
>It's onboard a ASUS PT55XE with 32MB RAM and an 133mhz CPU.
>Hope on help.

I had the same problems when 'tuning' my Pentium from 90 to 100MHz :-) To get rid
of that, increase the 8bit I/O-recovery time in the BIOS 'chipset features' setup 
from 3 ( I think that's default) to 6 or greater. Then the printer port should be
slow enough for the dongle :-)

---
        Bye
        Georg Acher
+--------------------------------------------------------------+
|         Georg Acher, acher@informatik.tu-muenchen.de         |
|           "Oh no, not again !" The bowl of petunias          |
+--------------------------------------------------------------+


Article: 2316
Subject: Re: NeoCAD and AT&T vs. Xilinx
From: jcooley@world.std.com (John Cooley)
Date: Sun, 19 Nov 1995 23:47:15 GMT
Links: << >>  << T >>  << A >>
Pete Becker <peb@trsvr.tr.unisys.com> wrote:
>Is there any good software available for general FPGA development
>as opposed to manufacturer-specific tools?

Well, if you count Verilog & VHDL simulators plus a myriad of synthesis tools
as being non-FPGA manufacturer-specfic tools, then sure! there are plenty of
general FPGA development tools out there!   But, if you want to do FPGA P&R,
it seems, as far as I know, to be very FPGA vendor specific.  As I said before,
quite a few designers were pissed at Xilinx for buying NeoCAD because NeoCAD
was the only general purpose FPGA P&R tool out there.

For Verilog/VHDL/synthesis check out: Cadence, ViewLogic, Synopsys, Simucad,
Mentor, Chronologic, Vantage, Exemplar, Model Tech, Intergraph, Frontline,
interHDL, IST, Data I/O, SpeedSim, Pendulm, Compass, Fintronic, Wellspring,
Minc, Silerity, Synplicity, and Veritools.

                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3713 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 2317
Subject: Re: [q][Reverse Engineering Protection]
From: tzechien@pc2.hinet.net (tzechien)
Date: 20 Nov 1995 03:46:10 GMT
Links: << >>  << T >>  << A >>
>
>Jyri Hamalainen <jyrih@cat.co.za> wrote:
>>Does anyone here know anything about protecting ASIC's from reverse 
>>engineering? OR logic camourflaging? With modern technologies such as 
>>electron beam induced current imaging and Charge induced voltage 
>>alteration (Scania Labs), I suppose there are no more solutions to 
>>protecting ones investment?
>
Hi 
  I am the guy who might do reverse enginerring .(ASIC only)(FPGA is
  unable to reverse)
  To tell the truth there is no good way to prevent it.
  Even you design your chip very critical.
  We reverse the IC,and we also run the simulation and Hspice too.
  We will not totally copy your IC's Layout because of differnet process.

  So the best way to keep pepole from reverse your IC.is

  1.Do BIG IC more then 10KGate.
  2.Use 3 Metal
  3.Do fully customer IC .
    Shrink the Chip size.And Fully customer ic is harder to reverse.
  (1,2,3 is to keep the reverse slow)
  4.Keep your technology update.

  


Article: 2318
Subject: Re: BP Micro and CUPL -- a good start?
From: trev@ss11.wg.icl.co.uk (Trevor Hall)
Date: 20 Nov 1995 06:28:41 GMT
Links: << >>  << T >>  << A >>
ddecker@usa.pipeline.com(mush) writes:
stuff deleted
>    5. Outputs can be persistent or transient on an output by output  
>     basis, although the syntax is obnoxious, like CUPL's. If you declare  
>     an output to be 'reg d' then its output will go true on the clock  
>     leaving the state that sets it, but it will return low on the state  
>     following that unless you keep setting it high. For this you use the  
>     out A := 1 syntax.  
>     If you want your output to be persistent and stay high until told to  
>     go low many states later, then you declare the output to be type  
>     reg_jk. Ah but you can't say A := 1. If you do, it will go high and  
>     never go low because this sets up an equation for the J input to the  
>     JK and none for the K. To make it work you have to say A.j = 1 to set 
>
>     the out put high, and A.k = 1 to set it low. Why can't someone do this
> 
>     right??????? 

MINC's PLDesigner has nice syntax for this. When declaring a register/output or
state machine you can use the DEFAULT_TO modifier. In the above case the 
DEFAULT_TO LAST_VALUE makes things persistent.

T.H.















Article: 2319
Subject: Re: options for VHDL or Verilog simulation/synthesis < $10,000 ?
From: peb@trsvr.tr.unisys.com (Pete Becker)
Date: Mon, 20 Nov 1995 13:25:15 GMT
Links: << >>  << T >>  << A >>
In article <9jBEx*qS1@wolf359.exile.org>,
   eric@wolf359.exile.org (Eric Edwards) wrote:
>I am looking for simulation and synthesis targeted to mid size CPLD's. 
>The choice of CPLD's has not yet been made.  That decision will likely be
>made based on software support.
>
>I would rather not use a product tied to a particular vender's chips. 
>Total software cost needs to be less than $10,000.  The budget is tight. 
>I can come in signicantly under $10,000 it that much better.
>
>Either Verilog or VHDL will do.  However, I have not encounted low cost
>Verilog synthesis so VHDL is more probable.  

WARP2 (VHDL) from Cypress is $99.  It is Cypress specific, but it's cheap.  I 
don't know much about the performance, though.


================================================
My comments and questions are composed of my own
opinions and do not necessarily reflect those of
my employer (or anyone else).
------------------------------------------------
  Peter Becker
  peb@trsvr.tr.unisys.com
================================================


Article: 2320
Subject: Re: [q][Reverse Engineering Protection]
From: ejessen@ix.netcom.com (Erik Jessen)
Date: Mon, 20 Nov 95 14:31:54 GMT
Links: << >>  << T >>  << A >>
In article <48j34t$8nu@ixnews7.ix.netcom.com>,
   ejessen@ix.netcom.com (Erik Jessen) wrote:
>In article <DI6H3x.5Lz@world.std.com>,
>   jcooley@world.std.com (John Cooley) wrote:
>>Jyri Hamalainen <jyrih@cat.co.za> wrote:
>>>Does anyone here know anything about protecting ASIC's from reverse 
>>>engineering? OR logic camourflaging? With modern technologies such as 
>>>electron beam induced current imaging and Charge induced voltage 
>>>alteration (Scania Labs), I suppose there are no more solutions to 
>>>protecting ones investment?
>
>Jyri,
>
>I've used some special layout cells we called "fake gates" - they looked like
>normal combinatoric-logic cells, but actually had their outputs shorted to 
>either VDD or GND.  If someone reverse-engineered the design, and didn't 
>notice, it would cause the design to behave erratically, every 3-5 days.
>
>As a practical matter, if you want to keep someone from copying your design, 
>simply design it so that you can't debug it yourself - put in lots of async. 
>logic, race conditions, etc.  And then lay it out so that the timing is right 
>on the edge.  If you're really careful, build up some RC circuits using 
normal 
>routing - if someone else' process has different parameters, the circuit will 
>fail erratically (or, even better, just corrupt the data, like toggling the 
>parity bit and one other bit).
>
>:>
>
>Erik


Umm, this is a follow-up to my own message; Rich Greene slammed me in a post 
to all these groups; obviously, he didn't notice my ":>" that I put, just 
before my name.  I don't think that ANY of those techniques are the way to go,
and I was never happy when I was ordered to implement them.
If you want to keep people from reverse-engineering your product, do this:
	- continuously upgrade it, so that your competition can't keep up
	- keep your price reasonable, so that they will never try, because 
	  they couldn't make any money at it, if they tried.

These same sentiments were posted by a guy who's obviously done a little 
reverse-engineering in the past.

Cheers,
Erik

Erik Jessen
Com-Solutions, Inc.
(619) 942-9790
The views expressed here are purely my own.


Article: 2321
Subject: Re: [q][Reverse Engineering Protection]
From: rgreene@netaxs.com (Richard M. Greene)
Date: Mon, 20 Nov 95 14:52:40 GMT
Links: << >>  << T >>  << A >>
In article <48j34t$8nu@ixnews7.ix.netcom.com>,
   ejessen@ix.netcom.com (Erik Jessen) wrote:
~In article <DI6H3x.5Lz@world.std.com>,
~   jcooley@world.std.com (John Cooley) wrote:
~>Jyri Hamalainen <jyrih@cat.co.za> wrote:
~>>Does anyone here know anything about protecting ASIC's from reverse 
~>>engineering? OR logic camourflaging? With modern technologies such as 
~>>electron beam induced current imaging and Charge induced voltage 
~>>alteration (Scania Labs), I suppose there are no more solutions to 
~>>protecting ones investment?
~
~Jyri,
~
~I've used some special layout cells we called "fake gates" - they looked like
~normal combinatoric-logic cells, but actually had their outputs shorted to 
~either VDD or GND.  If someone reverse-engineered the design, and didn't 
~notice, it would cause the design to behave erratically, every 3-5 days.
~
~As a practical matter, if you want to keep someone from copying your design, 
~simply design it so that you can't debug it yourself - put in lots of async. 
~logic, race conditions, etc.  And then lay it out so that the timing is right 
~on the edge.  If you're really careful, build up some RC circuits using 
normal 
Jyri;
I'd be really interested in finding out the name of the company you worked for 
.. then I'd make DAMN sure I did'nt send any business your way. I've been 
designing ASIC and Memory IC's for over 30 years and the last thing the people 
I design for want is a chip that is marginal. Between end of life and process 
variations as they effect yeild, the design box that a GOOD designer applies 
to his design precludes your suggestion. An IC does NOT lend itself to a 
design that "the timing is right~on the edge". 

--------------------------------------------------------------------
       _______	    _______                                        ?
      / _____ \    / _____ \          AEROSPACE DESIGN CONCEPTS    ^
     / /     \ \  / /     \ \            MEMORIES INTO SPACE      ^
  __/ /__    | |__| |    __\ \__             PLVS VLTRA . . . . .^
 /__| |_ \   /      \   / _| |__\
    | | | | | _    _ | | | | |             THE RAMMER
    | |_| | | \\  // | | |_| |              Richard Greene
     \___/   \ "  " /   \___/                E-MAIL:RGREENE@NETAXS.COM
              |    |                          HUMAN:(609) 859-8833
              | oo |                           FAX:  (609) 859-3671
               \__/                             VINCENTOWN, NJ 08088




Article: 2322
Subject: Looking for Low-$ Programmer
From: peb@trsvr.tr.unisys.com (Pete Becker)
Date: Mon, 20 Nov 1995 16:45:41 GMT
Links: << >>  << T >>  << A >>
I need recommendations for a low-cost device programmer with a PC interface 
for programming PLDs, CPLDs, and EPROMS.

Thanx in advance.


================================================
My comments and questions are composed of my own
opinions and do not necessarily reflect those of
my employer (or anyone else).
------------------------------------------------
  Peter Becker
  peb@trsvr.tr.unisys.com
================================================


Article: 2323
Subject: Rorschach Testing 273 Engineers With The Verilog-VHDL Contest
From: jcooley@world.std.com (John Cooley)
Date: Mon, 20 Nov 1995 17:22:03 GMT
Links: << >>  << T >>  << A >>

   [ 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  88 VHDL-only, 76 Verilog-only, 66 bilinguals, and 43 unknown
language users replied.  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 CS types, a chemistry professor, an EE PhD
candidate seeking permission to translate the design contest into Estonian,
3 EDA sales pitches and one "Christ is Coming Soon!" letter.  Four ESDA
vendors wrote for the contest specs making great claims in the process but
were never heard from again after getting them.


PAYBACK TIME  Because of all the time and energy some the EDA sales staffs
put into pushing VHDL onto engineers happy with Verilog, this contest seemed
to be a clarion call for Verilog customers (14 to be exact) to tell me the
shenannigans they suffered at the hands of these EDA vendors.  Synopsys, Inc.
topped the perpetrator list because they had a Verilog/VHDL synthesis tool
but only a VHDL simulator (VSS) to go with it.  Hence, their sales staff was
quite motivated to creatively work overtime promoting VHDL over Verilog.

> When I worked at HP Roseville, I remember taking my first Synopsys training
> class.  The instructor from Synopsys kept telling us that we were making a
> grave mistake using Verilog and that EVERYONE who was anyone was using
> VHDL.  (I actually was worried at the time we had chosen the wrong
> language, and that he was really unbiased.  As I look back it is obvious
> that he was probably a VSS VHDL salesman and did Design Compiler training
> on the side.)  I'm glad we chose Verilog, especially when teaching new
> engineers and when getting our SW/FW folks (who eat/sleep/breathe "C") to
> understand the HDL I have written.  I would really encourage any new HDL
> designer to choose Verilog rather than VHDL, since it is much easier to
> learn, use and eventually master.
>
>  - Scott C. Petler
>    Next Level Communications, Inc.


I laughed out loud when I saw this next letter.  At the Synopsys Users Group
meeting three years ago, the HP Boise Laserjet VHDL "success" story was a
main event.  And recently, Synopsys even used it in a major ad campaign
promoting VHDL with synthesis in all the trade journals!  

> I have spent most of my design life (last 4 years) working on VHDL designs.
> Recently, I have been forced into the Verilog camp by a vendor.  My initial
> concerns that Verilog would not have the functionality that I needed have
> been proven wrong.  Verilog does what I need better - and the simulators
> are faster than VHDL simulators.
>
> Since VHDL was driven mostly by the government which has no interest in the
> productivity of the designers, it is not surprising to see your results
> from the contest.  VHDL syntax hinders progress and does not improve the
> robustness or quality of the design.  The behavioral compilers, not VHDL,
> make the most sense for doing even more sophisticated design work.  
>
> Please don't make be go back to VHDL!
>
>  - Robert Rust
>    Hewlett Packard Boise Printer Division


HOW TO NOT LIE WITH STATISTICS  To my surprize, hardly anyone (2 VHDL-only
users) tried to say this was statistically insignificant, but 4 (5%) VHDL-
only, 5 (7%) Verilog-only, 3 (5%) bilinguals, 3 (18%) EDA vendors, and one 
(25%) professor thought is was mathematically kosher.

> One question that you have the VHDL bigots make in this "trial" can be
> completely refuted: the results are statistically significant as the term
> is usually defined.  To say a result is statistically significant, you
> show that it was very unlikely to be achieved by chance.  Given: 9 Verilog
> designers and 5 VHDL designers, choose 8 winners at random.  What is the
> chance that they will all be Verilog designers?
>
>     Answer: (9/14)*(8/13)*(7/12)*(6/11)*(5/10)*(4/9)*(3/8)*(2/7)
>             = 0.002997
>             = 1/333.7
>
> So there is one chance in 333.7 that this result is purely by chance.  We
> can't argue that this result isn't statistically significant given this
> figure.  This is a greater than 99% confidence level.  If we take one VHDL
> designer out (the one who suffered from the VHDL simulator bug), we get
> (9*8*...2)/(13*12*...6) or 1/143.


FROM THE FOUNDRY  Rather than risk losing any business or possibly angering
customers, six ASIC foundry and three FPGA vendors wrote carefully balanced
replies that said effectively: "Whatever the customer wants is right."  One
former foundry person wrote on condition of anonimity:

> In a previous life, I worked as an onsite applications engineer for an ASIC
> vendor.  The customer that I supported was developing 17 ASIC's for a large
> program.  The customer chose to develop some of the designs in VHDL and
> others in Verilog.  All were synthesized using Synopsys.  The smallest
> design was 15K gates, the largest was 100K gates.  I interviewed the design
> teams to gather some interesting statistics.  Conclusions were:
>
>   1) Designs done in Verilog were, without fail, completed faster than
>      those done in VHDL.  (In terms of gates/manweek.)
>
>   2) Adding designers to VHDL and Verilog based designs SLOWED the 
>      gates/manweek metric, but adding designers to VHDL-based designs
>      had a greater negative impact.  (Probably due to data-typing issues.)
>
>   3) Single or dual-person design teams out performed all others.
>
> The designers (80) were of various experience levels, working in groups of
> 2 to 10.  From end of specification to final signoff, the highest
> performancing was a Verilog team at 1500 gates/manweek, the lowest was a
> VHDL team with 8 gates/manweek!


VHDL'S STRATEGIC RETREAT  In the engineering press and on the Internet prior
to the Verilog/VHDL Design Contest, the VHDL bigots managed to create an
image that the only problem their language of choice had was in convincing
the ASIC foundries to provide VHDL libraries.  Hence, the big media presence
of "VHDL Initiative Towards ASIC Libraries" (VITAL).  With the Design Contest
results 39 (44%) VHDL-only, 4 (5%) Verilog-only, 19 (29%) bilinguals, and 14
(33%) unknown language users conceded that Verilog "wins" in low level gate
type designing, but VHDL "wins" in higher level abstract designing.  That is,
VHDL is retreating from gate level design to "own" high level design.  (Just
weeks before the Design Contest, VHDL proponents were openly claiming VHDL
was just as good at gate level ASIC design as Verilog was.)

> I've successfully used both languages, think that the results of the
> contest are directly correlated to the structure of the languages.  It
> exactly mirror my experiences.  Given this, I still prefer VHDL.  My first
> design was with Verilog and on the first day (after I'd taken the Synopsys
> Verilog class) I was able to write useable code that was simulatable and
> synthesizable.  I found the language relatively simple and easy to use, and 
> thus easy to produce results with.  When I changed jobs I started using
> VHDL and have produced several large chips with it.  It took me more than a
> week to get my first VHDL code to compile, not to mention simulate.  At
> first I couldn't stand VHDL, but as time went by I found that it's more
> structured, verbose and abstract from actual hardware.  Although harder
> to learn and easier to mess up, it's valuable on large projects.  
>
>  - Sean Atsatt
>    Seagate


TESTING MORE IMPORTANT  For some engineers testing was more important than
other issues: 14 (16%) VHDL-only and 9 (12%) Verilog-only stated that their
chosen HDL was best for this; 9 (14%) bilinguals and 4 (9%) unknowns liked
VHDL on testing; 8 (12%) bilinguals and 1 unknown preferred Verilog.

> It's clear from the contest that Verilog can get you to a netlist faster
> than VHDL - period end of story.   BUT my experience has shown that the
> amount of time to generate a netlist is small in comparison to the over
> all ASIC design schedule.  Verification (i.e. test bench generation) makes
> up most of the ASIC design schedules I put together.  Verilog's C-like
> structure provides a very flexiable environment which integrates very
> smoothly into most test bench solutions.  In addition, focusing on test
> benchs illuminates one of Verilog's best features: the PLI.  I don't
> believe VHDL provides a PLI counterpart.  Without a PLI many of the
> third part tools that I rely on, such as Signalscan, would not be available.
> At GI we have made use of Verilog's PLI for many tasks ranging from memory
> efficient input stimulus handling to automated test vector generation.
>
>  - Rick Price
>    General Instrument Corp


EXPERIENCE QUESTIONS  Quite a number of VHDL proponents raised the issue that
the VHDL contestants might not be experienced with the tools they had at hand
or in ASIC design itself.  (No one questioned the experience of the Verilog
contestants because all but one got to gates.)  The VHDL contestants used
Synopsys for synthesis and had a choice of Cadence and Synopsys for VHDL.
What follows are the sizes of all the ASIC's and FPGA's the VHDL contestants
have designed plus what EDA tools they've used.

  TABLE 1) ASIC, FPGA & TOOL EXPERIENCE OF VHDL COMPETITORS
 ----------------------------------------------------------------------------
 Ravi Srinivasan  ASIC's: 60K, 115K  partial ASIC's: 30K, 45K  FPGA's: 0
 Texas Instr.     Tools: Synopsys VHDL & Design Compiler, Aida, Verilog-XL

 Jan DeCalwe      ASIC's: 60K, 22K, 65K, 35K, 83K  FPGA's 3K, 6K, 4K, 2K
 Easics, Ltd.     Tools: Synopsys VHDL & Design Compiler, Actel P&R, Altera
                         MaxPlusII, Verilog-XL

 Jeff Solomon     ASIC's: 125K (schm.) partial 55K  FPGA's: 2K, 6K, 10K
 NASA Goddard     Tools: Synopsys VHDL & Design Compiler, Concept/Valid,
                         Cadence LWB RapidSim, LSI CMDE

 Prasad Paranjpe  ASIC's: 17K, 20K, 50K, 30K  partial ASIC's: >5  FPGA's: 0
 LSI Logic        Tools: Synopsys VHDL & Design Compiler, Vantage, LeapFrog,
                         Verilog-XL, IKOS, MTI, LSI CMDE

 Vikram Shrivastava  partial ASIC's: lots of synthesis/static timing/CMDE
 LSI Logic           Tools: Synopsys VHDL & Design Compiler, Verilog-XL, CMDE

 ---------------------------------------------------------------------------

The Verilog based contestants had similar tool and ASIC design experiance.
One noteable exception was Howard Landman of HaL Computers.  In his 15 years
of CAD management experience Landman has never designed a single ASIC, yet,
using Verilog he managed to take third place in the design competition!


FAIRNESS:  Of those 44 (16%) engineers who commented on fairness, 6 (2%)
(all VHDL-only's) felt the contest was "rigged" in Verilog's favor (because
they felt it was too low level) while the remaining 38 (14%) overall
designers saw it as honorable.

> Even before I read the "Closing Arguments to the Jury..."  I was thinking
> that this design contest was perfect because it showed exactly what
> engineers are up against - tools are late, support is incomplete and/or
> inexact, workstations crash inexplicably, testing is incomplete, etc.  The
> only thing missing was a change in the specification 10 minutes before the
> end of the contest.  Cool contest - thanks for all the work.
>
>  - Richard Schmidt
>    Exabyte

Two engineers felt that Steve Golson should have won because his design met
the design spec while Larry's didn't -- but this error wasn't caught by the
faulty test suite.

> Steve Golson is the winner. Clearly stated in the spec: "11" - Q holds
> state.  The inability of your testbench designers to adequately test the
> design should not be held against Steve (or should I say assist Larry).
> The bottom line must be that the design is functionally accurate.
>
>  - Michael Fitzsimmons
>    Motorola


TYPE WARS:  The most controversial topic was whether strong typing is a good
thing or a bad thing.  Some VHDL-proponents felt it was VHDL's core strength,
while other VHDL-proponents saw strong typing as an increadable annoyance!
Those who knew VHDL had very strong opinions on this.  Of the bilinguals,
19 (29%) hated strong typing, 6 (9%) loved it, 6 (9%) noted it but couldn't
decide.  Of the VHDL-onlys, the breakout was 13 (15%) hate, 17 (19%) love,
10 (11%) noted but couldn't decide.  Of Verilog-onlys and unknowns, 7 (5%)
hated, 4 (3%) loved, 6 (4%) noted but couldn't decide.

> I thought the contest was a good one and I'm not seriously surprised by the
> results.  I think the difference is in the nature of the languages,
> particularly the strong typing of VHDL, which at least one of your entrants
> had trouble with. VHDL forces you to think carefully about datatypes; if
> the design is simple logic, then this is a liability in terms of quick
> design time.  VHDL has a better chance of producing a correct design if
> there is a mix of signal types, because you are forced to make sure they
> all convert correctly.  C++ versus C is an analogy, the strong class
> binding of C++ objects can make for extra work up front making sure the
> types match up.  In the long run, the design is more robust and easier to
> maintain because of it.  I'm an IC designer who has used both - I'd use
> either one in real life, but I think verilog has the edge in quick draw
> contests.
>
> - Steve McChrystal
>   Siemens Components Inc.


IOWA STATE UNIVERSITY  It appears that the Design Contest's results have even
been verified by academia.  What I liked about this unintentional validation
is that it's not 90 minutes.  That is, there was all sorts of time for the
designers to do what they wanted.  (I've recieved over 100 letters total
starting with: "Your results didn't surprize me one bit!"  If they were from
the VHDL oriented I got explanations that VHDL tools took longer to run, VHDL
was more verbose, and needed more intial time to get results.  If they were
from the Verilog oriented, I got explainations that Verilog was essentially
C with wires, registers, built in flexable HW data types, concurrency and "it
should naturally win.")

> Actually, an interesting look at VHDL vs. Verilog was accidentally done in
> our graduate level logic synthesis course.  We recently got Synopsys Design
> Compiler, Synopsys VHDL and Cadence Verilog-XL.  While The rest of the
> class did their projects in VHDL, my lab partner and I did ours in Verilog.
> (We learned Verilog on our own; unlike my VHDL classmates, we had no class
> lectures, no T/A help, no professoral help.)
>
> The results of this were overwhelmingly in favor of Verilog as a tool to
> teach HDLs.  Our final project, a 7500 gate, 35nsec RISC processor was ~25
> pages of Verilog.  The VHDL people all ended up rushing near the end to
> just make something which worked and could be synthesized.  Several groups
> failed at this altogether!   (Whereas our project grew so large in
> functionality, our only problem was finding a workstation which had enough
> memory to handle the synthesis of the top level design.)
>
> The general comments in talking to the other students was they spent a
> majority of their timing fighting VHDL/Synopsys.  We spent a majority of
> our time doing design work, and optimization.
>
>  - Jeff Echtenkamp
>    Iowa State University


BILINGUAL JUDGEMENTS  The opinions I value the most are those of the bi-
linguals because they know both sides of the story.  Of the bilinguals, 39
(59%) personally preferred Verilog overall, 16 (24%) were HDL neutral,
6 (9%) personally preferred VHDL, and 5 (8%) didn't comment on this.

> My transition from VHDL to Verilog came about 2 years back when I worked
> on a design which was about 45K gates.  I learned Verilog as the ASIC
> Vendor we worked with was only comfortable doing a final signoff in Verilog
> rather than VHDL.  With the flavor of both the languages, here are my
> comments: 
>
>  1) VHDL is a good structured HIGH level language but I feel Verilog is
>     closer to actual hardware which is being designed. 
>
>  2) As far as behavioral goes, I rank VHDL at par with Verilog, but when
>     it comes to RTL, I consider Verilog has the edge over VHDL as far as
>     the time to market ( i.e. meeting the design schedule is concerned.)
>
> As far as the contest goes, I think verilog has again proved the point.
> Yes, with VHDL you can achieve the same target but at the cost of design
> time and support.  In the present industry, time to market a product is
> the key to success.  If a particular market window is missed, the ASIC and
> the man-months spent on it are a sheer waste.  I strongly feel that given
> the choice and the design time I would opt for Verilog.
>
>   - Subhodip Ghosh
>     Western Digital Corp.


DON'T SHOOT THE MESSENGER!  I'd like to close with the observation that this
design contest wasn't designed to be a referendum on Verilog vs. VHDL, but
it accidently became this.  I was swamped with e-mail from both the Verilog
*and* VHDL camps *both* saying that Verilog won in this contest.  Judging the
contest overall 175 (64%) felt "Verilog won", 16 (6%) felt "VHDL won", 48
(18%) felt "inconclusive" and 36 (13%) never voted!  Along party lines, 70
(92%) Verilog-onlys voted "Verilog won" and 39 (44%) VHDL-only's did either
an "inconclusive" or "no vote."

> I am in the defense industry, and therefore we went right to VHDL when we
> switched to designing ASICs using HDLs.  I have never learned Verilog.  I
> have always thought the extremely tight typing in VHDL caused a lot of
> inefficiencies, and my guess is that this had a major effect in the contest
> results.  Your contest seemed very fair to me.  I would call Verilog the
> obvious winner.
>
>  - Jim Levie
>    Northrop Grumman    

Yes, quite a few VHDL-only EDA companies like Synopsys, Mentor, Zycad, IKOS,
Model Tech, and ViewLogic have suddenly been working to either buy or
develope Verilog products for their customers.  I don't see them leaving the
VHDL business, though.  In my own consulting practice I've just finished a
Verilog ASIC for one customer and am now writing VHDL training material for
another.  For the next few years I feel being fully Verilog/VHDL bilingual,
just like most EDA companies, is the wave of the future.

                                 - John Cooley
                                   part-time EDA Consumer Advocate
                                   full-time contract ASIC/FPGA designer

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3881 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 2324
Subject: Re: NeoCAD and AT&T vs. Xilinx
From: Bob Hoffman x8931 <bobh@galaxy.nsc.com>
Date: Mon, 20 Nov 1995 17:22:07 GMT
Links: << >>  << T >>  << A >>
The rumor I've heard is that AT&T did an additional savvy thing, which
was to hire a good chunk of the core development team.  It remains to
be seen how the new AT&T release of Foundry preforms, but this combination
(source code and developers) looks to have some real potential.  

With the Neocad purchase by Xilinx, I plan to migrate my work to AT&T.
I'm using FPGA's for silicon emulation, so the larger devices don't hurt
either.

Bob Hoffman           || Any opinions expressed above are purely accidental ||
bobh@galaxy.nsc.com   || and certainly don't have my employers consent!     ||


jcooley@world.std.com (John Cooley) wrote:
>Stan Hodge wrote:
>> Hi.  I am currently evualuating a new FPGA technologies for our 
>> next generation product.  I have looked at Xilinx and AT&T.  The
>> new Xilinx software seem a bit more polished and easer to use 
>> than the AT&T neo stuff.
>
>It's no surprize.  NeoCAD was embarrassing the hell out of Xilinx in their
>own P&R process so Xilinx bought NeoCAD for something like $33 or $35
>million.  The great side effect of this deal is that it effectively kicked
>both AT&T and Motorola in the balls because they both relied rather
>heavily on NeoCAD.  AT&T was savvy enough to gets rights to NeoCAD's
>source code before they signed up with them so they've had a good start
>at developing their own NeoCAD-based P&R tool -- but they're still
>playing catch-up.
>
>Overall, quite a few users were rather pissed about Xilinx buying NeoCAD
>because NeoCAD was the *only* general FPGA P&R tool around -- making
>it purely Xilinx specific means that if users what to use Actel or Altera
>or QuickLogic or Lattice or AT&T FPGA's they'd *have* to learn each
>specific FPGA vendor's P&R tools.
>
>                           - John Cooley
>                             Part Time EDA Consumer Advocate
>                             Full Time ASIC, FPGA & EDA Design Consultant
>
>===========================================================================
> Trapped trying to figure out a Synopsys bug?  Want to hear how 3713 other
> users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
> 
>      !!!     "It's not a BUG,               jcooley@world.std.com
>     /o o\  /  it's a FEATURE!"                 (508) 429-4357
>    (  >  )
>     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
>     _] [_         Verilog, VHDL and numerous Design Methodologies.
>
>     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
>   Legal Disclaimer: "As always, anything said here is only opinion."





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