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
2017JanFebMarApr2017

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 1300

Article: 1300
Subject: Re: ABEL optimization
From: bowns@Data-IO.COM (Tom Bowns)
Date: Tue, 30 May 1995 15:40:20 GMT
Links: << >>  << T >>  << A >>
In article <MIKER.95May26181740@sunburn.megatek.com> miker@megatek.com (Mike Reeves) writes:
>
>Try compiling this simple little file. ABEL's unable to optimize
>signals la4..la7 as 1. It does produce a working equation (cond1 & st2);
>however, this failure to optimize between states can lead to some lengthy
>equations for a complex state machine. (@DCSTATE/@DCSET doesn't change this)
>As a result I'd recommend avoiding ABEL's "with" statement.
>
>---cut here---
>module JUNK
   [ ABEL source not included ]



Mike -

I'm not sure if I perhaps misunderstood your post, but running the design
through ABEL 6.0 I believe shows correct compilation and reduction.

In your post, it is stated that ABEL is unable to optimize signals
la4..la7 as 1.

However, according to the ABEL source, la0 through la3 are the signals
that should be optimized as 1. Note:

(line 23 in JUNK.ABL)	LA = [la0..la7];   
in this line, la0 is the MSB and la7 is the LSB. This statement is
POSITION sensitive, rather than NUMERIC sensitive. Thus, other 
constructs than numerals are allowed in SET declarations.

(lines 36-38 in JUNK.ABL)state st2:	if (cond1) then
					st2 with {
					  LA := ^hOF;}

Here, la0..la3 are being assigned 0000, and la4..la7 are being
assigned 1111 under the condition (st2 & cond1).

Thus, these reduced equations provided by ABEL 6.0:
la0 := (0);
la1 := (0);
la2 := (0);
!la3 := (1);
la4 := (cond1 & st2);
la5 := (cond1 & st2);
la6 := (cond1 & st2);
!la7 := (!cond1 # !st2);

Note that la3 and la7 both reflect an istype 'neg' equation set.

I believe this is corre; you may wish to check my work here
to see if I've missed an important point.

-TBB
Synario Systems Integration Engineering
Data I/O Corporation.

Opinions expressed are entirely my own, and do not necessarily
reflect those of Data I/O Corp.



Article: 1301
Subject: Re: Help on Programming FPGAs
From: Paul Walker <paul@walker.demon.co.uk>
Date: 30 May 1995 19:51:46 +0100
Links: << >>  << T >>  << A >>
In article <fliptronD9E1F6.67q@netcom.com>
           fliptron@netcom.com "Philip Freidin" writes:

>In article <3qctns$2b2@icaro.uminho.pt> esteves@di.uminho.pt writes:
>>
>>We are using an FPGA 3090 from XILINX and we stated some problems with
>>programming it.
>>Could someone please help us with useful information ?

>>- The board we use consists on a transputer T425, memory and LCA3090 devices.

> [and all Philip Freidin's helpful comments snipped]>                        

Not for your immediate question, but for using Xilinx devices with 
transputers, you might consider for a future project the 
board/transputer module designed precisely for developing such 
mixtures.

The board has been developed as part of Oxford University's research 
into hardware/software codesign and hardware compilation.

Details of the board and the Oxford research can be found at
 http://www.comlab.ox.ac.uk/oucl/hwcomp.html

-- 
Paul Walker                 4Links for technical help
+44 1908 566253             P O Box 816, Two Mile Ash
paul@walker.demon.co.uk     Milton Keynes MK8 8NS, UK


Article: 1302
Subject: Re: What's happening with NeoCAD?
From: victory@wwa.com
Date: 30 May 1995 20:15:40 GMT
Links: << >>  << T >>  << A >>
>   Roland Welte <100070.3321@CompuServe.COM> writes:
>  Just a few questions regarding the future of NeoCAD. They
>  may have been answered in this newsgroup before, but due to
>  my vacation I might have missed them.
>  
>    - What company bought NeoCAD (Xilinx, AT&T) ?

Xilinx has purchased NeoCAD.  I have read that they will ultimately
drop support for non-Xilinx parts in one year, but I cannot speak 
for Xilinx and users should contact them directly to obtain 
definitive information.

AT&T also has rights to the NeoCAD code, and now offers a tool
called "ORCA Foundry" to support their devices (only).  In fact, 
they have programmers on staff who were working with 
NeoCad prior to the takeover in order to help provide the support for 
AT&T devices.

In short, AT&T users will still be able to obtain software.

>    - Since NeoCAD was the only design system for FPGAs from
>      Motorola, what is happening with the support for these
>      devices, now that NeoCAD is not independent anymore.

I am less familiar with the Motorola parts.  I have read postings indicating
that Pilkington has other tools to support them, but I have no definitive
information and would suggest contacting Motorola.

>  Half a year ago, I decided that NeoCAD is the tool of choice
>  for our company's FPGA designs, mainly because of its
>  device independent philosophy. But now it looks quite
>  differently.

I agree; IMHO, Xilinx's move was more good for them than 
for their customers.

>  Thanks a lot for any help to the above. I'll appreciate it.

You are welcome!

----------------------------------------------------------------------------------------------------
DISCLAIMER:  Although I work for a company which represents 
AT&T Microelectronics, the opinions expressed are my own and
not those of Victory Sales or of AT&T M.E.  All comments are
factually accurate to the best of my knowledge.  Please do not
sue me.
-----------------------------------------------------------------------------------------------------
POINT OF INFORMATION:  Information about any AT&T
Microelectronics product, including FPGA foundry, can be 
obtained from your local AT&T rep.  To determine who that is,
you can call (800) - 372 - 2447.
----------------------------------------------------------------------------------------------------



Article: 1303
Subject: Re: What's happening with NeoCAD?
From: victory@wwa.com
Date: 30 May 1995 20:35:14 GMT
Links: << >>  << T >>  << A >>
>   Bond <bond@rahul.net> writes:

>  This is purely a matter of personal opinion. But why would anyone
>  want another company and another choice when there is Xilinx which
>  offers all possible technologies you can think of, SRAM or Antifuse
>  or EPLDs ... with best possible software :-)
>  
>  -Bond

Some advantages of AT&T's ORCA product include:

 * Sufficient routing resources to get the larger parts to route with
   in designs that use almost all of the device.  This has a huge
   impact on time to market.

 * Fully PCI compliant, even in large designs.  Anyone attempting a PCI
   interface should check the clock => out specifications of their technology
   against the 11 ns. number in the PCI spec.  The 7 ns input to clock setup
   and the 0 ns. data hold from clock are also important.  The fourth item to
   check in competing FPGAs is the IV curves on outputs; ORCA complies
   with PCI.

 * Size.  ORCA parts are available in 40,000+ gate sizes (and, as mentioned
   above, the large ORCA parts have additional routing resources so that their
   gates can actually be used).

 * On chip user SRAM.  

 * AT&T employs a .5 micron (drawn) technology, so their die are very small; 
   this usually translates to cost and power advantages.

 * Low clock skew, even for very large numbers of clocks.  It is possible to 
   have multiple clock trees in an ORCA, all with low skew.  That enables
   logic to run faster.

 * Lots of I/Os.  ORCAs can be obtained in packages ranging up to 384 pins.
   
 -------------------------------------------------------------------------------------------------------------
DISCLAIMER:  Although I work for a company which represents AT&T 
Microelectronics, the opinions expressed are my own and not those of 
Victory Sales or of AT&T M.E.  All comments are accurate to the best 
of my knowledge.  Please do not sue me.
---------------------------------------------------------------------------------------------------------------
POINT OF INFORMATION:  Information about any AT&T Microelectronics 
product, including FPGA foundry, can be obtained from your local AT&T rep.  
To determine who that is you can call (800) - 372 - 2447.
---------------------------------------------------------------------------------------------------------------



Article: 1304
Subject: FPGAs for PCI Interfaces
From: victory@wwa.com
Date: 30 May 1995 21:09:38 GMT
Links: << >>  << T >>  << A >>
Recently, I have seen postings about implementing PCI in FPGAs.

I would like to point out that the ATT2Cxx family (ORCA) of FPGAs from
AT&T Microelectronics is particularly suited to PCI applications.  

There is an app note in the latest AT&T ORCA FPGA databook covering
a PCI interface; here, I would like to just briefly touch on why ORCA suits
PCI particularly well:

 * ATT2Cxx meets ac/dc drive specifications.
 * ATT2Cxx has a clock-to-out <11 ns.
 * Setup time <7 ns. / hold times ~0 ns.
 * On Chip SRAM; can be used for configuration registers.
 * .5 micron (drawn) technology allows ORCA to meet 33 MHz 
   system timing requirements.
 * PCI requires at least 124 I/O; ORCA architecture has up to 384,
   leaving room for incremental logic.
 * The ORCA family is large enough to implement PCI *and* user 
   functions in a single device.  A PCI target fits in part of an ATT2C08;
   larger family members include the 2C10, 2C12, 2C26 and 2C40, with
   more on the way.


Anyone interested in further information should contact their local AT&T ME
sales rep.  Literature and information about who your rep is can both be
obtained by calling (800) 372 - 2447.  

----------------------------------------------------------------------------
DISCLAIMER:  Although I work for a company which represents AT&T 
Microelectronics, the opinions expressed are my own and not necessarily 
those of Victory Sales or of AT&T M.E.  All comments are accurate to the 
best of my knowledge, but I am only human.  Please do not sue me.
----------------------------------------------------------------------------



Article: 1305
Subject: Re: Any company for conversion FPGA to ASIC?
From: victory@wwa.com
Date: 30 May 1995 21:23:47 GMT
Links: << >>  << T >>  << A >>
>   backfire@saturn.sst.co.kr (baik jong sung <4224>) writes:

>  By the way, is there anybody who knows a company which
>  provides FPGA-to-ASIC conversion services ?
  
   ...

>  Please answer me about above question.
>  
>  Thank you for reading.
>  
>   J.S. Baik

Matra MHS, which is part of the TEMIC group, does FPGA=>Gate array
conversions.   Matra has a line of ULCs (Universal Logic Circuits), 
which include support for the EPM7064 family you are using, and 
many others as well.




Article: 1306
Subject: Re: affordable fpga design tools?
From: jeanpaul@stack.urc.tue.nl
Date: 30 May 1995 22:45:44 GMT
Links: << >>  << T >>  << A >>
In <Pine.HPP.3.91.950521074308.9169B-100000@pmafire.inel.gov>, Jack Mott <jackm@pmafire.inel.gov> writes:
>On 20 May 1995, Eric T. Brewer wrote: 
>> Check out QuickLogic. They have a $99 eval package which is there complete
>> set of tools minus the programming software. Their parts/tools are nice
>> beacuse they are auto-place and auto-route as well as high speed. Also, they
>> have Verilog synthesis!
>
>I have used Altera HDL with some success.  Is Verilog synthesis another
>type of HDL?  When I last looked at Quicklogic a year-and-a-half ago, they
>only had schematic entry, but not HDL.
>
>The Quicklogic parts are fast (like using 10K ECL), but they are one-time
>programmable.  In addition, the fuse burning process seems to be much
>slower than the EEPROM or UV-EPROM parts I have used. 
>
>An engineer using Quicklogic at the time also told me that the software 
>timing simulation was not so good.  He claimed to be able to do a better 
>job by looking at the data sheet and working things out with paper and 
>pencil.
>
>I would appreciate hearing comments from others who are more experienced 
>using Quicklogic.
>
>Charles Mott
>

I have been using QuickLogic for one and a half year now and I'm very satisfied
with the results. The parts are very fast but what is more important the timing
is predictable and very insensitive to the utilisation percentage of the device.
The performance figures they give in their spec sheets are real, unlike my 
experience with some others devices.

Devices can be used for more than 95%, something which is impossible with
some other architectures.

The reason for this is that there is almost no delay in the interconnect. I have
designed a VESA bus based color frame grabber with 4 of these devices. Initially I
had chosen the Xilinx 3100 series of FPGAs but it was not possible to achieve the
desired operating speed. For example in some cases I lost 20ns in interconnect delay
on very long lines, with QuickLogic the delay is a couple of ns max.

All sofware versions prior to the current 5.0 series were mostly schematic entry
based, but a simple textual based entry (QuickBoolean) was available. The features
of QuickBoolean however are very limited.

For the timing critical parts I used the schematic entry, but for the other parts
I used Abel, together with some simple scripts I wrote which converted the output
from Abel to QuickBoolean.

The current version of the software, QuickWorks 5.0, now offers the choice of
schematic entry, QuickBoolean or Verilog. I have only done some limited tests
with Verilog, but it seems possible to achieve the same results with Verilog as with
schematic entry, if the abstraction level used to describe the circuit is about
the same level as in schematic entry. 

I think that with the availability of Verilog the need for schematic entry will
almost be eliminated. Verilog based textual entry however is much easier and faster
than schematic entry.

Jean-Paul



Article: 1307
Subject: HTML version of "FPGA Workout II"
From: devb@elvis.vnet.net (David Van den Bout)
Date: 30 May 1995 18:05:58 -0500
Links: << >>  << T >>  << A >>
The "FPGA Workout II" text has just been released
in the HTML format by XESS Corp.

The URL for "FPGA Workout II" is
file://ftp.vnet.net/pub/xess/hyperdoc/html/fpgawk2.htm

There are currently five chapters covering the following topics:
    + detailed architecture of the EPX780 FPGA
    + syntax manual for the PLDasm HDL
    + JTAG fundamentals and use with the EPX780
    + a configuration circuit for the EPX780
    + FIFO construction with the EPX780
-- 

||  Dave Van den Bout  ||
||  Xess Corporation   ||


Article: 1308
Subject: Re: ABEL optimization
From: miker@megatek.com (Mike Reeves)
Date: 31 May 1995 00:10:57 GMT
Links: << >>  << T >>  << A >>
>>>>> "Ken" == Ken Goldman <kgold@watson.ibm.com> writes:



    Ken> miker@megatek.com (Mike Reeves) writes:
    >>  Try compiling this simple little file. ABEL's unable to
    >> optimize signals la4..la7 as 1. It does produce a working
    >> equation (cond1 & st2); however, this failure to optimize
    >> between states can lead to some lengthy equations for a complex
    >> state machine. (@DCSTATE/@DCSET doesn't change this) As a
    >> result I'd recommend avoiding ABEL's "with" statement.
    >> 
    >> ---cut here--- module JUNK
[snip happens...]

    Ken> I might be missing something here, since I don't have
    Ken> immediate access to ABEL right now, but I'll comment anyway
    Ken> (in true Internet tradition).

    Ken> I would not expect the reduced equation to be LA<4:7> = 1 but
    Ken> rather LA<4:7> = (STREG==st2) & cond1.  Is this what ABEL
    Ken> did?

    Ken> A big difference between ABEL and Verilog is that ABEL
    Ken> implies "else 0" in state machines while Verilog implies
    Ken> "else keep the previous state."

As mentioned, the @DCSTATE directive was also used. This directive
should treat undefined states as don't cares.

-- 
   Michael G. Reeves          email:     miker@megatek.com
   Megatek Corporation        voice:  (619) 675-4300 x2663
   16868 Via Del Campo Court  facsimile:    (619) 675-4341
   San Diego, CA  92127
	
--
   Michael G. Reeves          email:     miker@megatek.com
   Megatek Corporation        voice:  (619) 675-4300 x2663
   16868 Via Del Campo Court  facsimile:    (619) 675-4341
   San Diego, CA  92127
	


Article: 1309
Subject: Re: Help on Programming FPGAs
From: Donald Sinclair <Donald@seescan.demon.co.uk>
Date: 31 May 1995 09:08:23 +0100
Links: << >>  << T >>  << A >>
You can't just send the .BIT file. It has a header the XILINX doesn't want.
Try MAKEROM, then convert the resulting file from whatever hex
format you choose to the corresponding data-bytes, and send that.
Good luck...
-- 
Donald Sinclair
Disclaimer : the above is just my opinion.


Article: 1310
Subject: Re: Any company for conversion FPGA to ASIC?
From: randraka@ids.net
Date: Wed, 31 May 95 15:02:03 +500
Links: << >>  << T >>  << A >>
In Article <3qcpuk$8ip@dartvax.dartmouth.edu>
jeff_cunningham@fostex.com (Jeff Cunningham) writes:
>In article <3qbot9$oge@noc.sait.samsung.co.kr>
>backfire@saturn.sst.co.kr (baik jong sung <4224>) writes:
>
>> By the way, is there anybody who knows a company which
>> provides FPGA-to-ASIC conversion services ?
>> That is, I have some control logic designed by several
>> EPLD(5-Altera EPM7064QC100). But I have to convert these
>> chips to one-chip of ASIC, for example, LSI, Toshiba, etc.
>
>Orbit Semiconductor, ATS (Advanced Technical Solutions) & AMI all do
>turnkey FPGA conversions. I would guess all three could convert the
>chips you mention into a single ASIC. In the case of the first two, you
>need to supply full production test vectors. In the case of AMI, you
>can opt to just give them functional test vectors and they will (for a
>fee) insert scan elements and generate production test vectors
>themselves. AMI will also (for a fee) automatically add full JTAG
>boundary scan.
>
Atmel also does conversions to their family of gate arrays from any of the
FPGA or EPLDs.  They require a full set of test vectors and whatnot.  A
complete narrative of their services can be found in the 1995 Atmel
configurable logic data book.
 
I am familiar with Orbit as well.  LSI and AMI Gould may also offer conversion
services to their product.  Onyx, in Bedford, MA may also be doing something in
conversions (I seem to remember talking to a rep there about an Actel
conversion)
 
-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
obtaining the maximum performance from FPGAs.  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: 1311
Subject: Feb. article in ISD
From: fmj@pe.dk (Finn M. Johansen)
Date: Wed, 31 May 1995 13:05:48 GMT
Links: << >>  << T >>  << A >>
Hi everyone
I am not a subscriber of Integrated System Design, and I know that there is
an article entitled  "Practical State Machine Design Using VHDL" in the
February issue of this magazine which would be of much interest to me. Could
someone please tell me how get the specified issue or how I subsribe the
magazine. Note that I am living in Denmark.
Thanks in advance.

/Finn
*******************************
                                                               
Finn M. Johansen, M.Sc.E.E.
Hardware Design Engineer, R&D

PURUP PREPRESS A/S
5 Soenderskovvej
DK-8520 Lystrup
Denmark
Phone: +45 87 434 343
Fax: +45 87 434 445
E-mail: fmj@pe.dk                           
                                                                            
                                                    
******************************



Article: 1312
Subject: Re: FPGAs for PCI Interfaces
From: cfernand@dsy-srv3.cern.ch (Fernandes Carlos /ECP)
Date: Wed, 31 May 1995 14:58:52 GMT
Links: << >>  << T >>  << A >>

How do you implement the PCI on a ATT2C15-3 FPGA?
Indeed, timings are VERY critical or even impossible to meet:

With the ATT2C15-3 FPGA, timings seems the folowing

- Input-PAD		: 1.8 ns
- clock routing		: about 3.4 ns
- CK to Output register : 1.7 ns
- Output Pad		: 5.9 ns (Bidir, tristate)
- 1 PFU layer (LUT)	: 3.1 ns

So if I summ those values, I get 15.9 ns.
This value doesn't include any routing delay (except clock
routing)
It is true that if we have an internal clock which would be
4 ns earlier (26 later) than PCI-CLK (using some part of the
7 ns setup in the inputs), we can gain 4 ns.

So, according to these values, Clock to Output delay will be
at least 11.9 ns (WITHOUT ANY ROUTING !!!)

So how can you get the value "clock-to-out < 11 ns" ?


>> Anyone interested in further information should contact their local AT&T ME
>> sales rep.  Literature and information about who your rep is can both be
>> obtained by calling (800) 372 - 2447.  

We are certainly very interested and running a PCI project with ATT2C15.
However, our ATT dataline in Europe doens't seems to be able to answer
to our questions.



-- 
                                      ?
                                    ,,,
                                   (o o)
-------------------------------oOO--(_)--OOo------------------------------------
          	    Carlos FERNANDES - ECP/EDA Division
              CERN - European Laboratory for Particle Physics
                       CH-1211 Geneva 23 Switzerland
                   E-Mail  : cfernand@dsy-srv3.cern.ch
                   URL  : http://sunshine.cern.ch:8080/
________________________________________________________________________________




Article: 1313
Subject: REPOST: "Verilog Won & VHDL Lost; You Be The Judge!"
From: jcooley@world.std.com (John Cooley)
Date: Wed, 31 May 1995 16:44:53 GMT
Links: << >>  << T >>  << A >>
 [ Because of the recent exchanges on comp.lang.verilog and comp.lang.vhdl
   concerning this contest, I've been getting late comers e-mailing me for
   copies of this article.  To save hassle, I'm reposting it.  - John Cooley ]


   !!!     "It's not a BUG,                           jcooley@world.std.com
  /o o\  /  it's a FEATURE!"                                 (508) 429-4357
 (  >  )
  \ - /       The Unexpected Results From A Hardware Design Contest:
  _] [_           Verilog Won & VHDL Lost? -- You Be The Judge!

                       by John Cooley, the ESNUG guy

        Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222


I knew I hit a nerve.  Usually when I publish a candid review of a particular
conference or EDA product I typically see around 85 replies in my e-mail "in"
box.  Buried in my review of the recent Synopsys Users Group meeting, I very
tersely reported that 8 out of the 9 Verilog designers managed to complete
the conference's design contest yet *none* of the 5 VHDL designers could.  I
apologized for the terseness and promised to do a detailed report on the
design contest at a later date.  Since publishing this, my e-mail "in" box
has become a veritable Verilog/VHDL Beirut filling up with 169 replies!  Once
word leaked that the detailed contest write-up was going to be published in
the DAC issue of "Integrated System Design" (formerly "ASIC & EDA" magazine),
I started getting phone calls from the chairman of VHDL International,
Mahendra Jain, and from the president of Open Verilog International, Bill
Fuchs.  A small army of hired gun spin doctors (otherwise know as PR agents)
followed with more phone calls.  I went ballistic when VHDL columnist Larry
Saunders had approached the Editor-in-Chief of ISD for an advanced copy of my
design contest report.  He felt I was "going to do a hatchet job on VHDL" and
wanted to write a rebuttal that would follow my article...  and all this was
happening before I had even written *one* damned word of the article!

Because I'm an independent consultant who makes his living training and
working *both* HDL's, I'd rather not go through a VHDL Salem witch trial
where I'm publically accused of being secretly in league with the Devil to
promote Verilog, thank you.  Instead I'm going present *everything* that
happened at the Design Contest, warts and all, and let *you* judge!  At the
end of court evidence, I'll ask you, the jury, to write an e-mail reply which
I can publish in my column in the follow-up "Integrated System Design".


The Unexpected Results
----------------------

Contestants were given 90 minutes using either Verilog or VHDL to create a
gate netlist for the fastest fully synchronous loadable 9-bit increment-by-3
decrement-by-5 up/down counter that generated even parity, carry and borrow.

Of the 9 Verilog designers in the contest, only 1 didn't get to a final gate
level netlist because he tried to code a look-ahead parity generator.  Of the
8 remaining, 3 had netlists that missed on functional test vectors.  The 5
Verilog designers who got fully functional gate-level designs were:

   Larry Fiedler     NVidea               3.90 nsec     1147 gates
   Steve Golson      Trilobyte Systems    4.30 nsec     1909 gates
   Howard Landman    HaL Computer         5.49 nsec     1495 gates
   Mark Papamarcos   EDA Associates       5.97 nsec     1180 gates
   Ed Paluch         Paluch & Assoc.      7.85 nsec     1514 gates

The surprize was that, during the same time, *none* of 5 VHDL designers in
the contest managed to produce any gate level designs.


Not VHDL Newbies vs. Verilog Pro's
----------------------------------

The first reaction I get from the VHDL bigots (who weren't at the competition)
is: "Well, this is obviously a case where Verilog veterans whipped some VHDL
newbies.  Big deal."  Well, they're partially right.  Many of those Verilog
designers are damned good at what they do -- but so are the VHDL designers!

I've known Prasad Paranjpe of LSI Logic for years.  He has taught and still
teaches VHDL with synthesis classes at U.C. Santa Cruz University Extention
in the heart of Silicon Valley.  He was VP of the Silicon Valley VHDL Local
Users Group.  He's been a full time ASIC designer since 1987 and has designed
*real* ASIC's since 1990 using VHDL & Synopsys since rev 1.3c.  Prasad's home
e-mail address is "vhdl@ix.netcom.com" and his home phone is (XXX) XXX-VHDL.
ASIC designer Jan Decaluwe has a history of contributing insightful VHDL and
synthesis posts to ESNUG while at Alcatel and later as a founder of Easics,
a European ASIC design house.  (Their company motto: "Easics - The VHDL
Design Company".)  Another LSI Logic/VHDL contestant, Vikram Shrivastava, has
used the VHDL/Synopsys design approach since 1992.  These guys aren't newbies!


Creating The Contest
--------------------

I followed a double blind approach to putting together this design contest.
That is, not only did I have Larry Saunders (a well known VHDL columnist)
and Yatin Trivedi (a well known Verilog columnist), both of Seva Technologies
comment on the design contest -- unknown to them I had Ken Nelsen (a VHDL
oriented Methodology Manager from Synopsys) and Jeff Flieder (a Verilog based
designer from Ford Microelectronics) also help check the design contest for
any conceptual or implementation flaws.

My initial concern in creating the contest was to not have a situation where
the Synopsys Design Compiler could quickly complete the design by just
placing down a DesignWare part.  Yet, I didn't want to have contestants
trying (and failing) to design some fruity, off-the-wall thingy that no one
truely understood.  Hence, I was restricted to "standard" designs that all
engineers knew -- but with odd parameters thrown in to keep DesignWare out
of the picture.  Instead of a simple up/down counter, I asked for an up-by-3
and down-by-5 counter.  Instead of 8 bits, everything was 9 bits.

                                  recycled COUNT_OUT [8:0]
                     o---------------<---------------<-------------------o
                     |                                                   |
                     V                                                   |
               -------------                     --------                |
  DATA_IN -->-|   up-by-3   |->-----carry----->-| D    Q |->- CARRY_OUT  |
   [8:0]      |  down-by-5  |->-----borrow---->-| D    Q |->- BORROW_OUT |
              |             |                   |        |               |
       UP -->-|    logic    |                   |        |               |
     DOWN -->-|             |-o------->---------| D[8:0] |               |
               -------------  | new_count [8:0] | Q[8:0] |->-o---->------o
                              |                 |        |   |
                 o------<-----o        CLOCK ---|>       |   o->- COUNT_OUT
                 |                               --------           [8:0]
 new_count [8:0] |     -----------
                 |    |   even    |              --------
                 o-->-|  parity   |->-parity-->-| D    Q |->- PARITY_OUT
                      | generator |   (1 bit)   |        |
                       -----------           o--|>       |
                                             |   --------
                                   CLOCK ----o

   Fig.1) Basic block diagram outlining design's functionality

The even PARITY, CARRY and BORROW requirements were thrown in to give the
contestants some space to make significant architectural trade-offs that
could mean the difference between winning and losing.

The counter loaded when the UP and DOWN were both "low", and held its state
when UP and DOWN were "high" -- exactly opposite to what 99% of the world's
loadable counters traditionally do.

                  UP  DOWN   DATA_IN    |    COUNT_OUT    
                 -----------------------------------------
                   0    0     valid     |   load DATA_IN
                   0    1   don't care  |     (Q - 5)
                   1    0   don't care  |     (Q + 3)
                   1    1   don't care  |   Q unchanged

   Fig. 2) Loading and up/down counting specifications.  All I/O events
           happen on the rising edge of CLOCK.

To spice things up a bit further, I chose to use the LSI Logic 300K ASIC
library because wire loading & wire delay is a significant factor in this
technology.  Having the "home library" advantage, one saavy VHDL designer,
Prasad Paranjpe of LSI Logic, cleverly asked if the default wire loading
model was required (he wanted to use a zero wire load model to save in
timing!)  I replied: "Nice try.  Yes, the default wire model is required."

To let the focus be on design and not verification, contestants were given
equivalent Verilog and VHDL testbenches provided by Yatin Trivedi & Larry
Saunder's Seva Technologies.  These testbenches threw the same 18 vectors at
the Verilog/VHDL source code the contestants were creating and if it passed,
for contest purposes, their design was judged "functionally correct."

For VHDL, contestants had their choice of Synopsys VSS 3.2b and/or Cadence
Leapfrog VHDL 2.1.4; for Verilog, contestants had their choice of Cadence
Verilog-XL 2.1.2 or Chronologic VCS 2.3.2 plus their respective Verilog/VHDL
design environments.  (The CEO of Model Technology Inc., Bob Hunter, was too
paranoid about the possiblity of Synopsys employees seeing his VHDL to allow
it in the contest.)  LCB 300K rev 3.1A.1.1.101 was the LSI Logic library.

I had a concern that some designers might not know that an XOR reduction tree
is how one generates parity -- but Larry, Yatin, Ken & Jeff all agreed that
any engineer not knowing this shouldn't be helped to win a design contest.
As a last minute hint, I put in every contestant's directory an "xor.readme"
file that named the two XOR gates available in LSI 300K library (EO and EO3)
plus their drive strengths and port lists.

To be friendly synthesis-wise, I let the designers keep the unrealistic
Synopsys default setting of all inputs having infinite input drive strength
and all outputs were driving zero loads.

The contest took place in three sessions over the same day.  To keep things
equal, my guiding philosophy throughout these sessions was to conscientiously
*not* fix/improve *anything* between sessions -- no matter how frustrating!

After all that was said & done, Larry & Yatin thought that the design contest
would be too easy while Ken & Jeff thought it would have just about the right
amount of complexity.  I asked all four if they saw any Verilog or VHDL
specific "gotchas" with the contest; all four categorically said "no."


Murphy's Law
------------

Once the contest began, Murphy's Law -- "that which can go wrong, will go
wrong" -- prevailed.  Because we couldn't get the SUN and HP workstations
until a terrifying 3 days before the contest, I lived through a nightmare
domino effect on getting all the Verilog, VHDL, Synopsys and LSI libraries
in and installed.  Nobody could cut keys for the software until the machine
ID's were known -- and this wasn't until 2 days before the contest!  (As it
was, I had to drop the HP machines because most of the EDA vendors couldn't
cut software keys for HP machines as fast as they could for SUN workstations.)

The LSI 300K Libraries didn't arrive until an hour before the contest began.
The Seva guys found and fixed a bug in the Verilog testbench (that didn't
exist in the VHDL testbench) some 15 minutes before the constest began.

Some 50 minutes into the first design session, one engineer's machine
crashed -- which also happened to be the licence server for all the Verilog
simulation software!  (Luckily, by this time all the Verilog designers were
deep into the synthesis stage.)  Unfortunately, the poor designer who had his
machine crash couldn't be allowed to redo the contest in a following session
because of his prior knowlege of the design problem.  This machine was
rebooted and used solely as a licence server for the rest of the contest.

The logistics nightmare once again reared its ugly head when two designers
innocently asked: "John, where are your Synopsys manuals?"  Inside I screamed
to myself: "OhMyGod! OhMyGod! OhMyGod!"; outside I calmly replied: "There are
no manuals for any software here.  You have to use the online docs available."

More little gremlins danced in my head when I realized that six of the eight
data books that the LSI lib person brought weren't for the *exact* LCB 300K
library we were using -- these data books would be critical for anyone trying
to hand build an XOR reduction tree -- and one Verilog contestant had just
spent ten precious minutes reading a misleading data book!  (There were two
LCB 300K, one LCA 300K and five LEA 300K databooks.)  Verilog designer Howard
Landman of HaL Computer noted: "I probably wasted 15 minutes trying to work
through this before giving up and just coding functional parity -- although
I used parentheses in hopes of Synopsys using 3-input XOR gates."

Then, just as things couldn't get worst, everyone got to discover that when
Synopsys's Design Compiler runs for the first time in a new account -- it
takes a good 10 to 15 minutes to build your very own personal DesignWare
cache.  Verilog contestant Ed Paluch, a consultant, noted: "I thought that
first synthesis run building [expletive deleted] DesignWare caches would
*never* end!   It felt like days!"

Although, in my opinion, none of these headaches compromised the integrity of
the contest, at the time I had to continually remind myself: "To keep things
equal, I can *not* fix nor improve *anything* no matter how frustrating."


Judging The Results
-------------------

Because I didn't want to be in the business of judging source code *intent*,
all judging was based solely on whether the gate level passed the previously
described 18 test vectors.  Once done, the design was read into the Synopsys
Design Compiler and all constraints were removed.  Then I applied the command
"clocks_at 0, 6, 12 clock" and then took the longest path as determined by
"report_timing -path full -delay max -max_paths 12" as the final basis for
comparing designs -- determining that Verilog designer Larry Fiedler of
NVidia won with a 1147 gate design timed at 3.90 nsec.

      reg [9:0] cnt_up, cnt_dn;   reg [8:0] count_nxt;

      always @(posedge clock)
      begin
        cnt_dn = count_out - 3'b 101;  // synopsys label add_dn
        cnt_up = count_out + 2'b 11;   // synopsys label add_up

        case ({up,down})
           2'b 00 : count_nxt = data_in;
           2'b 01 : count_nxt = cnt_dn;
           2'b 10 : count_nxt = cnt_up;
           2'b 11 : count_nxt = 9'bX;  // SPEC NOT MET HERE!!!
          default : count_nxt = 9'bX;  // avoiding ambiguity traps
        endcase

        parity_out  <= ^count_nxt;
        carry_out   <= up & cnt_up[9];
        borrow_out  <= down & cnt_dn[9];
        count_out   <= count_nxt;
      end

 Fig. 3) The winning Verilog source code.  (Note that it failed to meet
         the spec of holding its state when UP and DOWN were both high.)

Since judging was open to any and all who wanted to be there, Kurt Baty, a
Verilog contestant and well respected design consultant, registered a vocal
double surprize because he knew his design was of comparable speed but had
failed to pass the 18 test vectors.  (Kurt's a good friend -- I really
enjoyed harassing him over this discovery -- especially since he had bragged
to so many people on how he was going to win this contest!)  An on the spot
investigation yielded that Kurt had accidently saved the wrong design in the
final minute of the contest.  Even further investigation then also yielded
that the 18 test vectors didn't cover exactly all the counter's specified
conditions.  Larry's "winning" gate level Verilog based design had failed to
meet the spec of holding its state when UP and DOWN were high -- even though
his design had successfully passed the 18 test vectors!

If human visual inspection of the Verilog/VHDL source code to subjectively
check for places where the test vectors might have missed was part of the
judging criteria, Verilog designer Steve Golson would have won.  Once again,
I had to reiterate that all designs which passed the testbench vectors were
considered "functionally correct" by definition.


What The Contestants Thought
----------------------------

Despite NASA VHDL designer Jeff Solomon's "I didn't like the idea of taking
the traditional concept of counters and warping it to make a contest design
problem", the remaining twelve contestants really liked the architectural
flexiblity of the up-by-3/down-by-5, 9 bit, loadable, synchronous counter
with even party, carry and borrow.  Verilog designer Mark Papamarcos summed
up the majority opinion with: "I think that the problem was pretty well
devised.  There was a potential resource sharing problem, some opportunities
to schedule some logic to evaluate concurrently with other logic, etc.  When
I first saw it, I thought it would be very easy to implement and I would have
lots of time to tune.  I also noticed the 2 and 3-input XOR's in the top-level
directory, figured that it might be somehow relevant, but quickly dismissed
any clever ideas when I ran into problems getting the vectors to match."

Eleven of contestants were tempted by the apparent correlation between known
parity and the adding/subtracting of odd numbers.  Only one Verilog designer,
Oren Rubinstein of Hewlett-Packard Canada, committed to this strategy but ran
way out of time.  Once home, Kurt Baty helped Oren conceptually finish his
design while Prasad Paranjpe helped with the final synthesis.  It took about
7 hours brain time and 8 hours coding/sim/synth time (15 hours total) to get
a final design of 3.05 nsec & 1988 gates.  Observing it took 10x the original
estimated 1.5 hours to get a 22% improvement in speed, Oren commented: "Like
real life, it's impossible to create accurate engineering design schedules."

Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of
Easics, both complained of having to deal with type conversions in VHDL.
Prasad confessed: "I can't believe I got caught on a simple typing error.
I used IEEE std_logic_arith, which requires use of unsigned & signed subtypes,
instead of std_logic_unsigned."  Jan agreed and added: "I ran into a problem
with VHDL or VSS (I'm still not sure.)  This case statement doesn't analyze:
"subtype two_bits is unsigned(1 downto 0); case two_bits'(up & down)..."  But
what worked was: "case two_bits'(up, down)..."  Finally I solved this problem
by assigning the concatenation first to a auxiliary variable."

Verilog competitor Steve Golson outlined the first-get-a-working-design-and-
then-tweak-it-in-synthesis strategy that most of the Verilog contestants
pursued with: "As I recall I had some stupid typos which held me up; also I
had difficulty with parity and carry/borrow.  Once I had a correctly
functioning baseline design, I began modifying it for optimal synthesis.
My basic idea was to split the design into four separate modules: the adder,
the 4:1 MUXes, the XOR logic (parity and carry/borrow), and the top counter
module which contains only the flops and instances of the other three modules.
My strategy was to first compile the three (purely combinational) submodules
individually.  I used a simple "max_delay 0 all_outputs()" constraint on each
of them. The top-level module got the proper clock constraint.  Then
"dont_touch" these designs, and compile the top counter module (this just
builds the flops).  Then to clean up I did an "ungroup -all" followed by a
"compile -incremental" (which shaved almost 1 nsec off my critical path.)"

Typos and panic hurt the performance of a lot of contestants.  Verilog
designer Daryoosh Khalilollahi of National Semiconductor said: "I thought 
I would not be able to finish it on time, but I just made it.  I lost some
time because I would get a Verilog syntax error that turned up because I had
one extra file in my Verilog "include" file (verilog -f include) which was
not needed."  Also, Verilog designer Howard Landman of Hal Computers never
realized he had put both a complete behavioral *and* a complete hand
instanced parity tree in his source Verilog.  (Synopsys Design Compiler just
optimized one of Howard's dual parity trees away!)

On average, each Verilog designer managed to get two to five synthesis runs
completed before running out of time.  Only two VHDL designers, Jeff Solomon
and Jan Decaluwe, managed to start (but not complete) one synthesis run.  In
both cases I disqualified them from the contest for not making the deadline
but let their synthesis runs attempt to finish.  Jan arrived a little late so
we gave Jan's run some added time before disqualifying him.  His unfinished
run had to be killed after 21 minutes because another group of contestants
were arriving.  (Incidently, I had accidently given the third session an
extra 6 design minutes because of a goof on my part.  No Verilog designers
were in this session but VHDL designers Jeff Solomon, Prasad Paranjpe, Vikram
Shrivastava plus Ravi Srinivasan of Texus Instruments all benefited from this
mistake.)  Since Jeff was in the last session, I gave him all the time needed
for his run to complete.  After an additional 17 minutes (total) he produced
a gate level design that timed out to 15.52 nsec.  After a total of 28 more
minutes he got the timing down to 4.46 nsec but his design didn't pass
functional vectors.  He had an error somewhere in his VHDL source code.

Failed Verilog designer Kurt Baty closed with: "John, I look forward to next
year's design contest in whatever form or flavor it takes, and a chance to
redeem my honor."


Closing Arguments To The Jury
-----------------------------

Closing aurguments the VHDL bigots may make in this trial might be: "What 14
engineers do isn't statistically significant.  Even the guy who ran this
design contest admitted all sorts of last minute goofs with it.   You had a
workstation crash, no manuals & misleading LSI databooks.  The test vectors
were incomplete.  One key VHDL designer ran into a Synopsys VHDL simulator
bug after arriving late to his session.  The Verilog design which won this
contest didn't even meet the spec completely!  In addition, this contest
wasn't put together to be a referendum on whether Verilog or VHDL is the
better language to design in -- hence it may miss some major issues."

The Verilog bigots might close with: "No engineers work under the contrived
conditions one may want for an ideal comparision of Verilog & VHDL. Fourteen
engineers may or may not be statistally significant, but where there's smoke,
there's fire.  I saw all the classical problems engineers encounter in day to
day designing here.  We've all dealt with workstation crashes, bad revision
control, bugs in tools, poor planning and incomplete testing.  It's because
of these realities I think this design contest was *perfect* to determine how
each HDL measures up in real life.  And Verilog won hands down!"

The jury's veridict will be seen in the next "Integrated System Design".


You The Jury...
---------------

You the jury are now asked to please take ten minutes to think about what
you have just read and, in 150 words or less, send your thoughts to me at
"jcooley@world.std.com".  Please don't send me "VHDL sucks." or "Verilog
must die!!!" -- but personal experiences and/or observations that add to
the discussion.  It's OK to have strong/violent opinions, just back them with
something more than hot air.  (Since I don't want to be in the business of
chasing down permissions, my default setting is *whatever* you send me is
completely publishable.  If you wish to send me letters with a mix of
publishable and non-publishable material CLEARLY indicate which is which.)
I will not only be reprinting replied letters, I'll also be publishing stats
on how many people had reported each type of specific opinion/experience.

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

P.S. In replying, please indicate your job, your company, whether you use
     Verilog or VHDL, why, and for how long.  Also, please DO NOT copy
     this article back to me -- I know why you're replying!  :^)

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

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


Article: 1314
Subject: FPGA primer text?
From: dhopper@t2.telogy.com (Dan Hopper)
Date: 31 May 1995 18:32:29 GMT
Links: << >>  << T >>  << A >>
Does anyone have a recommendation for and FPGA text (for someone
who has had no prior experience with them)?

Thanks
Dan

-- 
--------------------------------------------------------------------------
|  Dan Hopper   (KD4VGM)        | dhopper@telogy.com (Internet)          |
|  Telogy Networks Inc.         | KD4VGM@N1GMV.#RTP.NC.USA.NOAM (AX.25)  |
|       "Resistance is Futile!" - Inductor said to Capacitor.            | 


Article: 1315
Subject: Re: FPGAs for PCI Interfaces
From: husby@fnal.gov (Don Husby)
Date: 31 May 1995 18:43:20 GMT
Links: << >>  << T >>  << A >>
In article <D9G6y4.8py@news.cern.ch>, cfernand@dsy-srv3.cern.ch says...
> How do you implement the PCI on a ATT2C15-3 FPGA?
> Indeed, timings are VERY critical or even impossible to meet:
>
> With the ATT2C15-3 FPGA, timings seems the folowing
>
> - Input-PAD             : 1.8 ns
> - clock routing         : about 3.4 ns
> - CK to Output register : 1.7 ns
> - Output Pad            : 5.9 ns (Bidir, tristate)
> - 1 PFU layer (LUT)     : 3.1 ns
>
> So if I summ those values, I get 15.9 ns.

According to my data book, I got the following times:

Clock to Output Pad:
  Clock pad to PFU CK:             4.9 ns
  PFU CK to output pad (edge FF):  5.7 ns
                                 _________
                        Total:    10.6   Includes routing

Clock to Pad through tristate control:
  Clock pad to PFU CK:             4.9 
  PFU CK to output:                2.8 
  PFU to PAD TS control (routing): 1.0 
  TS to PAD:                       4.7       
                                 _________
                        Total:    13.4

Inputs into pipeline register (setup):
  Setup to Pad (edge FF):          2.1
  Clock routing:                  -4.9
                                 _________
  Actual setup, PAD to CLK PAD:   -2.8 +/- ~1 ns
  Using delayed input: (6.8-4.9)  +1.9 +/- ~1 ns

Inputs through a PFU (setup):
  Pad delay:                       2.3
  PFU setup to clock:              1.7
  Routing:                        ~1
  Clock routing:                  -4.9
                                 _________
  Total setup time through PFU:    0.1 +/- ~1 ns




Article: 1316
Subject: Re: Display EDIF (EDIF -> ORCAD)
From: dlb@potomac.wash.inmet.com (David Barton)
Date: Wed, 31 May 1995 19:04:22 GMT
Links: << >>  << T >>  << A >>
In article <743510216wnr@rwattsa.demon.co.uk>
"C:COMMSDISWIN32KA9QSPOOLMAIL" <horste@rwattsa.demon.co.uk> writes: 

   we are doing some FPGA/ASIC design in VHDL. 
   To see the output of the design it would be a nice thing to get the 
   EDIF netlist displayed.Does anyone know about a EDIF display program, 
   or a converter for ORCAD?

The EDIF Technical Center at the University of Manchester in the UK
has a tool called EVS (EDIF Visualization System) that does just this.
You can get in touch with them at edif@cs.man.ac.uk (from memory; if
this does not work, please drop me a line at the address below and I
will forward you message).

					Dave Barton
					dlb@wash.inmet.com


Article: 1317
Subject: Re: ABEL optimization
From: bowns@Data-IO.COM (Tom Bowns)
Date: Wed, 31 May 1995 20:06:04 GMT
Links: << >>  << T >>  << A >>
In article <3qf5ua$rpp@watnews1.watson.ibm.com> kgold@watson.ibm.com (Ken Goldman) writes:
>I might be missing something here, since I don't have immediate access
>to ABEL right now, but I'll comment anyway (in true Internet tradition).
>
>I would not expect the reduced equation to be LA<4:7> = 1 but rather
>LA<4:7> = (STREG==st2) & cond1.  Is this what ABEL did?
>

Yes, exactly. I don't know if I was completely clear in
my last post, but yes; LA<4:7> were assigned to ((STREG == st2) & cond1);

Another thing to remember (thanks, Mike) is that it is best to assume that
a variable's output level is undefined unless explicitly assigned in a 
given state. So leaving out an assignment to the group LA in the power up
or first state may cause the outputs to go either way, and thus may cause
unexpected equations for those outputs. 

-TBB
Tom Bowns
Synario Systems Integration Engineering
Data I/O Corporation

The opinions expressed do not necessarily reflect those of Data I/O Corp.


Article: 1318
Subject: Latch up in Xilinx 3000 Series FPGA's. Part smokes & smells bad.
From: dstarr@world.std.com (David J Starr)
Date: Thu, 1 Jun 1995 02:59:25 GMT
Links: << >>  << T >>  << A >>
  We are having trouble with latchup using Xilinx 3090/3190 160 pin
parts.  When it happens the part is toast.  It will draw a couple of amps at 
5 volts and get hot enough to burn your fingers.  We have had three or
four parts do this, out of 10 or 12 parts overall.  It seems to happen on
1st power up, before we can even program the part with Xchecker.  The
board only has 5 volt power and is running by itself on the bench.  One
part went poof before any test equipment was connected.  Signals look
pretty clean, nothing rings very far below ground, or above vcc.  Any
hints, suggestions or experiences would be appreciated.  Are these parts
really that tender?  Or is there something we don't understand? TIA.
David J. Starr



Article: 1319
Subject: Re: Latch up in Xilinx 3000 Series FPGA's. Part smokes & smells bad.
From: murray@src.dec.com (Hal Murray)
Date: 1 Jun 1995 08:14:11 GMT
Links: << >>  << T >>  << A >>
In article <D9H4B2.L9J@world.std.com>, dstarr@world.std.com (David J Starr) writes:
|>   We are having trouble with latchup using Xilinx 3090/3190 160 pin
|> parts.  When it happens the part is toast.  It will draw a couple of amps at 
|> 5 volts and get hot enough to burn your fingers.
...


I've fried a few Xilinx chips and burned my thumb, but that didn't involve
any latchup.  Just two chips pulling a bus in opposite directions.

I've never had any troubles from a Xilinx before it was configured.  Consider
patching ~Reset to ground so you know that the chip isn't trying to do
anything.

Have you checked for the "obvious" gross blunders, like getting a pair of
power/ground pins wired up backwards.  If you have troubles when ~Reset is tied
low it's probably something simple like that.


During configuration, most I/O pins are high impedance.  Beware though, a few are
output.  You can get into real trouble if some other chip is driving one of
those signals.

Do you have the M0/M1/M2 pins connected correctly?  Things get real confusing
if it comes up in the wrong mode.  It might even start driving the address bus
trying to load itself from a ROM.  (That assumes that ~Reset isn't low.)


Article: 1320
Subject: faculty positions
From: dowd@acsu.buffalo.edu (P.W. Dowd)
Date: 1 Jun 1995 13:19:28 GMT
Links: << >>  << T >>  << A >>


*******************************************************************************
Available Faculty Position 


The   Department of Electrical  and Computer  Engineering at the State
University of  New York at Buffalo is  seeking candidates for at least
one tenure track faculty position.   Visiting appointments may also be
considered. The positions are available as early as Fall 1995.

The area of  interest is Computer Engineering.   In particular, we are
seeking candidates   with background  in
 - Computer  Architecture, 
 - VLSI and/or
 - Computer Communications.
However, exceptional candidates in all areas will be considered.

The positions  are primarily at  the level of  Assistant Professor but
exceptional  candidates of all  levels   are encouraged to apply.  The
candidate is  expected to  build and  lead a  research group  and also
teach at  the graduate and  undergraduate levels.  A PhD in Electrical
and/or Computer Engineering/Science is required. Industrial experience
is a plus.

Please mail your C.V. with names and addresses of 3 references to:

   Dr. Patrick Dowd
   Department of Electrical and Computer Engineering
   State University of New York at Buffalo
   201 Bell Hall
   Box 602050
   Buffalo, NY 14260-2050

or dowd@eng.buffalo.edu for electronic submission.


The University at Buffalo  is an equal opportunity, affirmative action
employer.

*******************************************************************************





Article: 1321
Subject: User-friendly & powerful synthesizer
From: rpeltier@cime424 ()
Date: 1 Jun 1995 15:00:38 GMT
Links: << >>  << T >>  << A >>
Dear sirs,


    Innovative Synthesis Technologies Inc. offers a product line comprising :

	- an FPGA / CPLD Synthesizer
	  (Actel, Altera, Xilinx, Quicklogic, AMD, Lattice, Cypress...) 

	- an ASIC Synthesizer
	  (list of supported libraries available on request)

	- an FPGA Partitioner

	- an ASIC Prototyping system for APTIX, I-Cube, Zycad boards.


    The pricing of these tools is more than competitive.

    We have a worldwide sales network.

    Please note that the product called ASYL+ integrated into the ACTMAP from 
    Actel and COMPASS software are NOT IDENTICAL to the above ones.

    Don't hesitate to contact me at the following address.


Best regards.


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

  
                                      ____________________________________
   Regis PELTIER                     |  Tel : 76.70.51.03                 |
   -------------                     |  Fax : 76.84.12.61                 | 
                                     |  E-Mail : rpeltier@ist.fr          |
   Field Applications Engineer       |____________________________________|

          .                  
       .  o  .               
     . o  O  o .             
   . o O oOo O o .             
     . o  O  o .
       .  o  .    _/_/_/_/_/        _/_/_/_/_/     _/_/_/_/_/
          .          _/            _/                 _/
                    _/            _/_/_/_/_/         _/
                   _/                    _/         _/
                  _/                    _/         _/
             _/_/_/_/_/   _/   _/_/_/_/_/   _/    _/   _/


    EUROPOLE
    4, place Robert Schuman
    38000 GRENOBLE
    FRANCE
    
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
                          



Article: 1322
Subject: Re: What's happening with NeoCAD?
From: Bond <bond@rahul.net>
Date: 1 Jun 1995 15:44:28 GMT
Links: << >>  << T >>  << A >>
victory@wwa.com wrote:

> Some advantages of AT&T's ORCA product include:
> 
>  * Sufficient routing resources to get the larger parts to route with
>    in designs that use almost all of the device.  This has a huge
>    impact on time to market.
> 
>  * Fully PCI compliant, even in large designs.  Anyone attempting a PCI
>    interface should check the clock => out specifications of their technology
>    against the 11 ns. number in the PCI spec.  The 7 ns input to clock setup
>    and the 0 ns. data hold from clock are also important.  The fourth item to
>    check in competing FPGAs is the IV curves on outputs; ORCA complies
>    with PCI.
> 
>  * Size.  ORCA parts are available in 40,000+ gate sizes (and, as mentioned
>    above, the large ORCA parts have additional routing resources so that their
>    gates can actually be used).
> 
>  * On chip user SRAM.  
> 
>  * AT&T employs a .5 micron (drawn) technology, so their die are very small; 
>    this usually translates to cost and power advantages.
> 
>  * Low clock skew, even for very large numbers of clocks.  It is possible to 
>    have multiple clock trees in an ORCA, all with low skew.  That enables
>    logic to run faster.
> 
>  * Lots of I/Os.  ORCAs can be obtained in packages ranging up to 384 pins.
>    

Your post seems more like a sales ad than elucidating what is great
about AT&T products.

I completely agree that Xilinx currently does not have a product
(as far as I know) with the capacity of 40K equivalent gates and
I/O of 384 pins. 

But about Routing resurces, how sufficient is sufficient enough.
Does it mean that for your flagmark product 2C40, with 100%
capacity routes without any hassle. My records show otherwise.
Please post some benchmarks if you have access to any.

I can't find anything unique about the rest of the *advantages
you have mentioned. 

Doesn't Xilinx support On Chip RAMs much before AT&T first came 
out with their product ? (correct me if I'm wrong). 

Isn't Xilinx 4000E products fully PCI complaint ?

I guess all of us have heard from Salesmen from
Altera & Xilinx & all fpga companies. that their technology
is unique and greatest and it is good for designs with large
number of clocks. I'm sick of it, because it is hardly true.
All these architectures have a long way to go and their supporting
software is even slightly behind the hardware.


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

Disclaimer: I am no authority on FPGA architectures of AT&T,
Xilinx and Altera, neither do I stand to gain financially
by increasing or decreasing the sales of any of these fpgas.
All opinions expressed here are my own.




Article: 1323
Subject: VHDL->Exemplar->NeoCAD
From: Fernandes Carlos /ECP <cfernand>
Date: Thu, 1 Jun 1995 15:57:08 GMT
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

---------------------------------1246783671004810540992774133
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii

I'm triyng to write a PCI VHDL model to be implemented in an AT&T ORCA
FPGA (ATT2C15-3)

To do it, I'm using the following tools:
	Any Editor	-> VHDL source
	Exemplar	-> translates VHDL in XNF (synthesize)
	NeoCAD		-> Map and Place&Route in the FPGA.

1st questions:
Is there a better solution? In deed:
- NeoCAD doen't accepts FAN format which would be better (according
to Exemplar)
- Our version of Exemplar cannot generate optimised EDIF: I get an
error-message indicating that values (probably area and delay values)
are not availble, so the different solutions proposed by exemplar are
the same
So, I use the XNF format, which is normaly optimised for Xilinx, but
it 

2nd question
Most signal generated in the XNF format have the "_internal" extention
(version 2.11) (In the version, 2.2, it is now "_int"
For example, I have a signal called PCI_AD<10>_internal
But, for NeoCAD, this signal is completly independent of the signal
PCI_AD<11>_internal
So those signal are not mapped in the same PFU.
I created a small program that converts the names in the XNF file.
So signal PCI_AD<10>_internal becomes internal_PCI_AD<10> which can
be compared with internal_PCI_AD<11> by NeoCAD and then, it maps
the 2 signals in the same PFU.
If someone is interrested in using the converter it is attached to this
news)

Does anybody use something more interesting that this way

Thanks for any answer.


	Carlos Fernandes.


P.S. To use the converter:
It needs a configuration file indicating the keyword to be identified
and to be moved from the end of the name to the begin of the name:
For exemple, my configuration file is now like this (the order of the
rules is important, for exemple _IBUF must be put after _xxxxIBUF

_BDBUF-IBUFT	BDBUF-IBUFT_
_BDBUF-OBUFT	BDBUF-OFUFT_
_BDBUF-IBUF	BDBUF-IBUF_
_BDBUF-OBUF	BDBUF-OBUF_
_IBUF		IBUF_
_OBUF		OBUF_
_DFF_EN		DFF_EN_
_internal	internal_


To use the converter:
	Convert Input-File Config-File
or	Convert Input-File Config-File Output-File

(In the first case, it overwrites the input file)

-- 
                                     ?
                                   ,,,
                                  (o o)
------------------------------oOO--(_)--OOo------------------------------------

          	    Carlos FERNANDES - ECP/EDA Division
              CERN - European Laboratory for Particle Physics
                       CH-1211 Geneva 23 Switzerland

                   E-Mail  : cfernand@dsy-srv3.cern.ch
                   URL  : http://sunsci5.cern.ch:8080/
_______________________________________________________________________________

---------------------------------1246783671004810540992774133
Content-Transfer-Encoding: 7bit
Content-Type: text/plain


#include <stdio.h>
#include <string.h>

#define MaxLen 1000
#define NbMax	50
#define TMP_FILE	"./TemporaryFileForTranslation_DoNotUseItForSomethingElse"

main(int argc, char *argv[])
{
	FILE	*fpi,*fpo,*fpc;
	char	*wordkey;
	char	*new_word,*EndWord;
	char	*line,*line2;
	char	*match;
	int	l1,l2,i;
	char	*Word1,*Word2;
	char	*Word1_Tab[NbMax],*Word2_Tab[NbMax];
	int	Nb_Word=0;
	char	Command[1000];

/*
	Word1_Tab[0]="_BDBUF-OBUFT";
	Word2_Tab[0]="BDBUF-OBUFT_";
	Word1_Tab[1]="_internal";
	Word2_Tab[1]="internal_";
	Nb_Word = 2;
*/

	if ((argc <3) || (argc>4)){
		printf("usage: %s InputFile.xnf ConfigFile\n",argv[0]);
		printf("usage: %s InputFile.xnf ConfigFile OutputFile\n",argv[0]);
		return(1);
	}
	if ((fpi = fopen(argv[1],"rt"))==NULL){
		printf("Can't open Input File (%s)\n",argv[1]);
		return(1);
	}
	if ((fpc = fopen(argv[2],"rt"))==NULL){
		printf("Can't open Config File (%s)\n",argv[3]);
		return(1);
	}
	if (argc==3)
	{
		if ((fpo = fopen(TMP_FILE,"wt"))==NULL){
			printf("Can't open Output File (%s)\n",argv[2]);
			return(1);
		}
	} else {
		if ((fpo = fopen(argv[3],"wt"))==NULL){
			printf("Can't open Output File (%s)\n",argv[2]);
			return(1);
		}
	}



	
	match	=(char *)malloc(MaxLen);
	line	=(char *)malloc(MaxLen);
	wordkey	=(char *)malloc(MaxLen);
	new_word=(char *)malloc(MaxLen);
	EndWord	=(char *)malloc(MaxLen);


	printf("\nLoading Translation rules...\n");
	while ((fgets(line,MaxLen,fpc)) && (Nb_Word<=NbMax)){
		Word1_Tab[Nb_Word] = (char *)malloc(MaxLen);
		Word2_Tab[Nb_Word] = (char *)malloc(MaxLen);
		sscanf(line,"%s %s",Word1_Tab[Nb_Word],Word2_Tab[Nb_Word]);
		printf("NetName%s\t->\t%sNetName\n",Word1_Tab[Nb_Word],Word2_Tab[Nb_Word]);
		Nb_Word++;
	}
	fclose(fpc);

	printf("\nTranslating...\n");


	while (fgets(line,MaxLen,fpi)){
		int l,lmax;


		lmax = strlen(line)-1;
		l=0;
		line2=line;
		while (l<lmax){
			int KeySize;
			int j;
/*printf("Lign2= %s (%d %d)\n",line2,l,lmax);*/
			sscanf(line2,"%s",wordkey);
			l1=strlen(wordkey);
			line2=line2+l1+1;
			l+=l1+1;

			strcpy(new_word,wordkey);

/*printf("New = %s (%d)",new_word,l1);*/

			for (j=0;j<Nb_Word;j++)
			{
				Word1=Word1_Tab[j];
				Word2=Word2_Tab[j];
				KeySize=strlen(Word1);

				if ((match=strstr(wordkey,Word1))!=NULL)
				{
					strcpy(EndWord,match+KeySize);
/*printf("End = %s\n",EndWord);*/
/*
					l2=match-wordkey;
					strcpy(new_word,Word2);
					for (i=0; i<l2; i++)
						new_word[i+KeySize]=wordkey[i];
*/

					*match='\0';
					sprintf(new_word,"%s%s%s",Word2,wordkey,EndWord);
					*match='/';
/*
					printf("%s -> %s\n",wordkey,new_word);
*/

					strcpy(wordkey,new_word);
				}
			}

			fprintf(fpo,"%s ",new_word);

		}
		fprintf(fpo,"\n");
	}

	if (argc==3) {
		sprintf(Command,"mv %s %s",TMP_FILE,argv[1]);
		system(Command);
	}

	printf("\nTranslation Done !\n");
	fclose(fpi);
	fclose(fpo);
	free(EndWord);
	free(new_word);
	free(wordkey);
	free(line);
	free(match);
}

---------------------------------1246783671004810540992774133--


Article: 1324
Subject: pci-video-accell.card with Altera ?
From: tw38966@vub.ac.be (SH.RYU KIM HOFMANS)
Date: 1 Jun 1995 19:49:51 GMT
Links: << >>  << T >>  << A >>

Hi there,

could someone tell me if it's possible to make a pci video accellerator card 
with Altera or Xilinx FPGA's ?
One of my professors (a Xilinx fanatic) is telling me it isn't quite
possible because for that you need a lot of floating point calculations
and he says a Xilinx FPGA isn't capable of that sort of things.
Another of my professors (an Altera fanatic) is telling me it's possible
because Altera is providing special FPGA features for that kind of things.
But he doesn't know if it will be a lot of trouble to make it work with a
PCI-bus (he's also a MAC-fanatic so he doesn't know  lot about PC's)

So, if it is possible to make a PCI-video card with an FPGA, will it be a
lot of trouble ? And could someone tell me if there are any good books
about the hardware of PCI-busses and video-accelerator cards ?

Thanx in advance,

Kim Hofmans
tw38966@is1e.vub.Ac.Be





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
2017JanFebMarApr2017

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