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 4350

Article: 4350
Subject: Re: (no subject)
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 18 Oct 1996 16:01:39 GMT
Links: << >>  << T >>  << A >>
There are three levels of PCI compliance.  The first is electrical, ie.
capacitance, second is timing, ie. setup and hold, and third is cycle to
cycle protocol timing.  For an FPGA, the chip determines the first and most
of the second.  The third is determined by the design.

I have used the Xilinx 4xxxE series very successfully in both target only
and target/master implementations.   Xilinx has quite a lot of app notes on
PCI.  I developed my own PCI design, and did not use theirs, although
theirs is not bad.

Be aware that some vendors claim PCI compliance, but they do not have the
internal resources to implement a decent size design, or do not really make
the timing.  33mhz is really not all that easy in something as complicated
as a PCI interface, but it can be done with carefull design and
floorplanning.

Austin Franklin
darkroom@ix.netcom.com




Article: 4351
Subject: Re: xc4000 and 2 clocks
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 18 Oct 1996 17:58:37 GMT
Links: << >>  << T >>  << A >>
In article <01bbbc56$3faf8f20$0fd9e426@pmw> "Peter McLeod Wilcox" <pmw@techatl.com> writes:
>As with most things, it depends :).  The XC4000s have 4 primary and 4
>secondary global buffers, all of which are good choices for internal clocks
>(secondaries have a few nSecs more skew).

The secondary global clocks have more initial delay, but the end point
skews are the same as for the primaries. The clock tree has a significant
delay (device specific, but 7 to 15 ns, primarilly a function of device
size) from the source (bufgp or bufgs) to the clock distribution lines in
each column but these are all ballanced. The clock signal starts at the
bufgp/gs (in a corner), and is hard wired to the center of the chip where
it is then distributed horizontally in the central routing channel. In
each column there are 4 clock lines (vertical, reserved for clock ONLY),
and from these there are connections to the clock pins of the CLBs. Both
primaries and secondaries use the same topology, except the mapping from
the secondaries in the central channel to the clock lines in the columns
is more flexible. This adds between .5 and 1 nS for the distribution of
the secondaries (depending on 4000 or 4000E, and speed grade). The SKEW
between the thousands of potential endpoints is always less than a
nanosecond, and is always less than the clock to out of the flip flops
which is why the clock nets are what you should be using for distributing 
clocks.

>The secondary global buffers may
>be sourced by internal logic, and not just the I/O pin, so your devide by
>two could be generated inside the FPGA.  The choice is going to depend on
>the frequency of the clock and your maximum allowable skew.

A problem with dividing a clock by two and distributing it is that the 
divided clock from the flip flop will have not only been divided by two, 
but also it will be delayed in phase by the clock yo out time of the flip 
flop. If your design had the initial clock on a bufgp/gs clock net, and 
you used a divide by 2 FF in a corner, which you routed to the bufgs in 
the same corner, then the skew between these two clocks is going to be 
quite significant! It is the clock distribution delay (7 to 15 nS 
depending on device size and speed grade) plus Tcko (3 to 5 nS) plus 
routing to the bufgs (another 1 or 2 nS). This looks pretty icky to me, 
so I would want to figure out another way. Almost certainly clock this FF 
from the clock pin directly, rather than the global clock net (will save 
most of the 7 to 15 nS). Or be more creative.

A far better way to do this is to have all the FFs on the same clock net 
(the non divided clock), and use the divided by 2 clock to connect to the 
CE pins of the FFs you want to run at half speed. If there are many of 
these, then this idea may not be too good either.

As with most problems of this type, we are trying to help an initial 
poster who failed to give enough info for us to be able to give good 
specific help.

	Are the two clock domains synchronous or not with each other.
	What is their phase relationship.
	How fast are these clocks.
	How much logic runs at each frequency.
	Why are there two clock domains.
	Is there another clock running twice as fast as the faster clock.
	.
	.
	.


>It should also
>be noted that the secondary global buffers use global routing resources -
>I've had designs that would not route when I assigned a signal to a BUFGS
>because it (the clock) hogged the long lines.

Well this isn't true. The bufgs does not use long lines, only clock 
lines. The router when it gets desperate has been known to use the bufgs 
resource for non clock signals as a last ditch attempt to route a design 
and if your design was in that state, using the bufgs remove that escape 
path for the router. Usually some floor planning of the design will make 
routing much easier, and so such desperate measures will not be needed.


>
>If you can provide some more information on frequency and timing
>requirements I might be able to give a better answer.
>

Me too.  :)


Philip Freidin





Article: 4352
Subject: Re: (no subject) attempted humor
From: fliptron@netcom.com (Philip Freidin)
Date: Fri, 18 Oct 1996 18:05:43 GMT
Links: << >>  << T >>  << A >>
In article <5470mg$jcq@news.iastate.edu> Shawn Lee <lxd@iastate.edu> writes:
>Another question: Who knows the actual size of the XC3164A and XC4000E. 
>I can not find them on the web.
>Shawn Lee
>lxd@cpre1.ee.iastate.edu
>lxd@iastate.edu

The XC3164A is this big (I am holding up my right hand, and thumb and 
first finger are "this" far apart).

The XC4000E is "this" big (same thing).

Are you asking:
	Package size
	CLBs
	gates
	die size
	market share
	.
	.
	.

Note: the XC4000E is a familly of a dozen different parts.
      The 3164A comes in many different packages and speed grades.


Philip.

Article: 4353
Subject: Re: VHDL for Xilinx designs?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 18 Oct 1996 21:54:00 GMT
Links: << >>  << T >>  << A >>
I would agree that the VHDL tools have improved significantly over the past
few years, but you will never be able to get the speed and density with any
HDL as you can with schematic.

VHDL is not a very good tool for data path.  Most people like to see a data
flow, and an HDL does not lend it self to visualization like schematics do.
 For state machines, and random logic, an HDL is certainly much easier to
follow and understand than a schematic.

With Viewlogic (may be other schematic tools too) it is quite easy to do
schematics mixed with HDL (VHDL, XABEL I don't know about Verilog).  Since
someone has to maintain the design (usually) and it's (usually) not the
original designer, anything that can be done to make the design self
explanitory is good in my book.  Also, in Viewlogic, you can simulate the
entire design (schematic, VHDL/XABEL) with no difficulty.  You don't even
need to compile it!  This only gives unit delay simulations, but if you
make all your static timing numbers (TIMESPECs) then full timed simulation
becomes an option.

Another thing, at least for FPGA designs, it is real good to do
floorplanning of data path.  If you leave the data path unfloorplanned, if
it gets a bad placement (usually all the time) it will use up many more
routing resources, and have much longer delays.  If you have an internal
bus, with TBUFs and registers, schematics make it easier to get consistent
names to these elements, and therefore place them.  VHDL gives kind of
random names, different for each compile, unless you spend a lot of time
massaging the VHDL to give you consistent names.

A good number of contracts I have had have involved cleaning up a VHDL FPGA
design that did not fit in the part (obese) or was too slow.  I had to
either re-do the VHDL so we could floorplan the design to make timing, or
re-doing most of the design in schematic (even some state machines/control
logic).

This is only my humble opinion based on my experiences.

Austin Franklin
darkroom@ix.netcom.com

Article: 4354
Subject: Re: Xilinx xchecker.exe and Windows NT
From: David Dye <davidd@xilinx.com>
Date: Fri, 18 Oct 1996 18:17:40 -0700
Links: << >>  << T >>  << A >>
Actually there is a much more complete solution found in the Xilinx
Solutions Database: 
http://www.xilinx.com/techdocs/902.htm

There are more steps to be done than just installing the Rainport
driver.  Following 
these steps should get people running with the DOS version (5.2.1) of
the XACTstep 
software in either Windows NT 3.51 or 4.0.

david.



David Dye
Technical Applications Engineer
Xilinx, Inc., San Jose, CA
ph> (408) 879-5370
email> david.dye@xilinx.com
Article: 4355
Subject: CFP: 1997 Intl. Symp. on Physical Design, April 14-16, CA
From: ispd97@jade.cs.Virginia.EDU (1997 International Symposium on Physical Design)
Date: Sat, 19 Oct 1996 02:07:04 GMT
Links: << >>  << T >>  << A >>
=============================================================================

                             Call for Papers

               1997 International Symposium on Physical Design
                             April 14-16, 1997
                          Napa Valley, California

              Sponsored by the ACM SIGDA in cooperation with 
                   IEEE Circuits and Systems Society

   The International Symposium on Physical Design provides a forum to
exchange ideas and promote research on critical areas related to the
physical design of VLSI systems.  All aspects of physical design, from
interactions with behavior- and logic-level synthesis, to back-end
performance analysis and verification, are within the scope of the
Symposium.  Target domains include semi-custom and full-custom IC, MCM
and FPGA based systems.
 
   The Symposium is an outgrowth of the ACM/SIGDA Physical Design
Workshop.  Following its five predecessors, the symposium will
highlight key new directions and leading-edge theoretical and
experimental contributions to the field. Accepted papers will be
published by ACM Press in the Symposium proceedings. Topics of
interest include but are not limited to:

       1. Management of design data and constraints 
       2. Interactions with behavior-level synthesis flows 
       3. Interactions with logic-level (re-)synthesis flows 
       4. Analysis and management of power dissipation 
       5. Techniques for high-performance design 
       6. Floorplanning and building-block assembly 
       7. Estimation and point-tool modeling 
       8. Partitioning, placement and routing 
       9. Special structures for clock, power, or test
      10. Compaction and layout verification
      11. Performance analysis and physical verification 
      12. Physical design for manufacturability and yield 
      13. Mixed-signal and system-level issues.
      
IMPORTANT DATES:    Submission deadline:              December 20, 1996
                    Acceptance notification:          February 1, 1997
                    Camera-ready (6 page limit) due:  March 1, 1997

SUBMISSION OF PAPERS:

    Authors should submit full-length, original, unpublished papers 
    (maximum 20 pages double spaced) along with an abstract of at most 
    200 words and contact author information (name, street/mailing address, 
    telephone/fax, e-mail).

    Electronic submission via uuencoded e-mail is encouraged (single 
    postscript file, formatted for 8 1/2" x 11" paper, compressed with 
    Unix "compress" or "gzip''). Email to:

                        ispd97@ece.nwu.edu

    Alternatively, send ten (10) copies of the paper to:

                        Prof. Majid Sarrafzadeh
                        Technical Program Chair, ISPD-97
                        Dept. of ECE, Northwestern University
                        2145 Sheridan Road, Evanston, IL 60208 USA
                        Tel 847-491-7378 / Fax 847-467-4144 

SYMPOSIUM INFORMATION:

    To obtain information regarding the Symposium or to be added to the
    Symposium mailing list, please send e-mail to ispd97@cs.virginia.edu. 
    Information can also be found on the ISPD-97 web page:   

                         http://www.cs.virginia.edu/~ispd97/

SYMPOSIUM ORGANIZATION:

General Chair:               A. B. Kahng (UCLA and Cadence)
Past Chair:                  G. Robins (Virginia)
Steering Committee:          J. Cohoon (Virginia), S. Dasgupta (Sematech),
                             S. M. Kang (Illinois), B. Preas (Xerox PARC) 
Program Chair:               M. Sarrafzadeh (Northwestern)
Keynote Address:             T. C. Hu (UC San Diego) & E. S. Kuh (UC Berkeley)
Special Address:             R. Camposano (Synopsys)
Publicity Chair:             M. J. Alexander (Washington State)
Local Arrangements Chair:    J. Lillis (UC Berkeley)
Technical Program Committee: C. K. Cheng (UC San Diego)
                             W. W.-M. Dai (UC Santa Cruz) 
                             J. Frankle (Xilinx) 
                             D. D. Hill (Synopsys) 
                             M. A. B. Jackson (Motorola) 
                             J. A. G. Jess (Eindhoven)  
                             Y.-L. Lin (Tsing Hua) 
                             C. L. Liu (Illinois)
                             M. Marek-Sadowska (UC Santa Barbara)
                             M. Sarrafzadeh (Northwestern)
                             C. Sechen (Washington) 
                             K. Takamizawa (NEC)
                             M. Wiesel (Intel) 
                             D. F. Wong (Texas-Austin) 
                             E. Yoffa (IBM)

=============================================================================
 

Article: 4356
Subject: Comment/opinion on ACTEL's annonced SPGA devices?
From: Peter Fenn <pfenn@electrosolv.co.za>
Date: 19 Oct 1996 03:18:31 GMT
Links: << >>  << T >>  << A >>
I'm interested to hear opinion on Actel's new SPGA devices...
Also - Does anyone have an indication of pricing & availability of these?

Peter Fenn

Article: 4357
Subject: Anyone use Lattice's CPLD
From: 96kwong@uxmail.ust.hk (Wong Man Kit)
Date: 19 Oct 1996 04:33:20 GMT
Links: << >>  << T >>  << A >>
I would like to use Lattice's ispLSI2032LV CPLD in my design. It is a ISP
3.3V supply CPLD and the input signal can be either 3.3V or 5V. Anyone
has experience in using it before? Please let me know whether there is any
problem this chip.

Thanks in advance.

--
******************************************************************************
* Wong Man Kit                                                        黃文傑 *
******************************************************************************
* Email address     *        96kwong@alumni.ee.ust.hk       *       電郵地址 *
* Home page         *   http://eelindc1.ee.ust.hk/~eekwong  *           網頁 *
******************************************************************************
Article: 4358
Subject: Re: Anyone use Lattice's CPLD
From: sja@gte.net (Steven J. Ackerman)
Date: Sat, 19 Oct 1996 15:18:16 GMT
Links: << >>  << T >>  << A >>
96kwong@uxmail.ust.hk (Wong Man Kit) wrote:

>I would like to use Lattice's ispLSI2032LV CPLD in my design. It is a ISP
>3.3V supply CPLD and the input signal can be either 3.3V or 5V. Anyone
>has experience in using it before? Please let me know whether there is any
>problem this chip.

>Thanks in advance.

>--
>******************************************************************************
>* Wong Man Kit                                                        黃文傑 *
>******************************************************************************
>* Email address     *        96kwong@alumni.ee.ust.hk       *       電郵地址 *
>* Home page         *   http://eelindc1.ee.ust.hk/~eekwong  *           網頁 *
>******************************************************************************

While I haven't used the LV variant of the 2032, I have done several designs
using the isp2032 and isp2064. I recommend the Data I/O Synario toolset instead
of the Lattice PDS. I suggest that you simulate your design if at all possible
and lock your pinouts afterwards. Depending upon what changes you may make
later, it may or may not be possible to route to the same pinouts if the design
tends to fill the device. I got burned by fixing the pinout on a design to make
my board layout easier and then couldn't route to those pins after finishing the
design.


Steven J. Ackerman
Consultant
ACS, Sarasota, FL
sja@gte.net
http://www.acscontrol.com

Article: 4359
Subject: Announcing Workview Office Student Edition
From: atomrob@aol.com (ATOMROB)
Date: 19 Oct 1996 13:20:49 -0400
Links: << >>  << T >>  << A >>
Workview Office Student Edition is now available! 

The Student Editon provides students and universities with industry's
premier design tools for obtaining real world design solutions. A complete
product description can be obtained from our web page,
http://www.prenhall.com.  For other information contact, Prentice Hall
customer service, 1-800-374-1200.
Tom Robbins
Prentice Hall
Article: 4360
Subject: help Flex 10K configuration
From: yunfeng@cse.ucsc.edu (Yun Feng)
Date: 19 Oct 1996 17:42:04 GMT
Links: << >>  << T >>  << A >>
Hi,

Does anyone have the experience with Altera flex 10K device? I
have encountered some very strange phenomenon with it. I use a
Flex 10K50, setting it at PS mode as described at the databook.
Each time I powered on the system, the CONFIGURE_DONE pin will
go to "1". Then I set the nCONFIG pin to low, this should make
the CONFIG_DONE pin to go to "0" as described by the databook.
However, it remains a "1" on CONFIG_DONE.

Does anyone have any idea about the possible cause except that
the device is bad?


Feng Yun
Computer Engineering
UCSC
Article: 4361
Subject: Re: help Flex 10K configuration
From: "Tim Green" <tgreen@inil.com>
Date: Sat, 19 Oct 1996 19:20:55 GMT
Links: << >>  << T >>  << A >>
Call Altera at 1-800-800-EPLD the hot line is VERY helpful !!!

> Does anyone have the experience with Altera flex 10K device?

Article: 4362
Subject: Re: VHDL for Xilinx designs?
From: zz80@digiserve.com (extra z to stop junk mail)
Date: Sun, 20 Oct 1996 07:46:57 GMT
Links: << >>  << T >>  << A >>
Austin,

I thought I would never hear anyone say this. 

Having tried to get into VHDL myself, I feel exactly the same way
about it. But there is so much hype in the press, and so many people
are trying to use it for applications for which good old schematic
entry would have been far more appropriate.

On top of that, a schematic can compile only into *one* netlist
(assuming no bugs in the netlister). But an HDL program can itself
have bugs in it, just like any other programming language. And my
feeling on VHDL is that its syntax has a few too many "suprises". I do
probably 3-4 fairly big FPGA designs each year, and one needs to do
more just to keep fluent in this language.

Peter.

>I would agree that the VHDL tools have improved significantly over the past
>few years, but you will never be able to get the speed and density with any
>HDL as you can with schematic.
>
>VHDL is not a very good tool for data path.  Most people like to see a data
>flow, and an HDL does not lend it self to visualization like schematics do.
> For state machines, and random logic, an HDL is certainly much easier to
>follow and understand than a schematic.

Article: 4363
Subject: Re: price conversion from FPGA to gate array
From: zz80@digiserve.com (extra z to stop junk mail)
Date: Sun, 20 Oct 1996 07:46:58 GMT
Links: << >>  << T >>  << A >>
It would be a miracle if you can get $2 on just 10k, and certainly not
*including* the NRE.

In 1987-89 this sort of pricing would have been commonplace, but not
now.

I recently did an ASIC, ~2500 gates, and this is $3 in 100k qty.

>Looking for a rough coast estimate, to convert a 3020 fpga to an asic.
>Quantity would be 10,000. Need a piece price under $2.00, excluding all
>NRE and setup cost.
>
>
>JimC 

Article: 4364
Subject: Re: help Flex 10K configuration
From: Rune Baeverrud <r@acte.no>
Date: Sun, 20 Oct 1996 13:57:15 +0200
Links: << >>  << T >>  << A >>
Yun Feng wrote:

> Does anyone have any idea about the possible cause except that
> the device is bad?

It could be that you are not asserting the nCONFIG for long enough time.
-- 
Rune Baeverrud <r@acte.no>           
Field Application Engineer                    |\      _,,,---,,_
ScandComp, ACTE NC Norway AS            ZZzz  /,`.-'`'    -.  ;-;;,_
P.O. Box 190, N-2020 Skedsmokorset, Norway   |,4-  ) )-,_..;\ (  `'-'
Tel: +47 6389 8969   Fax: +47 6389 8979     '---''(_/--'  `-'\_)
Article: 4365
Subject: Re: VHDL for Xilinx designs?
From: Scott Kroeger <Scott.Kroeger@mei.com>
Date: Sun, 20 Oct 1996 08:30:42 -0500
Links: << >>  << T >>  << A >>
Peter,

> I thought I would never hear anyone say this.
> 
> Having tried to get into VHDL myself, I feel exactly the same way
> about it. But there is so much hype in the press, and so many people
> are trying to use it for applications for which good old schematic
> entry would have been far more appropriate.
> 
> On top of that, a schematic can compile only into *one* netlist
> (assuming no bugs in the netlister).

I've never seen a bug in my netlister, but I've seen plenty of bugs in
the libraries!

Cheers,
Scott
Article: 4366
Subject: Re: VHDL for Xilinx designs?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 20 Oct 1996 22:35:11 GMT
Links: << >>  << T >>  << A >>
A number of problems exist with HDLs in general.  One is you don't know
exactly what the code is going to compile down to...  Kind of like the
difference between a C program and assembly code..., though I would hardly
consider a good hierarchical schematic assembly code.  C is great for fast
proccessors with lots of memory (ASICs), but for a small slow micro (FPGAs)
it's not as good.  In an HDL, a case statement can become this really obese
thing checking for every possible condition for each branch...  I certainly
believe you can do pretty well with some finely crafted HDL code, if you
know exactly what it is going to compile down to.

Second is controlability.  It is much harder to floorplan an HDL design. 
Much harder...  I find that floorplanning is the real key to resource
utilization and speed, especially for FPGAs.

Personally, I like to mix both...but schematics is really the way to go for
the best speed and resource utilization.  I do schematics with my own
libraries of n bit registers, tbufs, counters, muxes.  They are device
independent, and require very little library work to add a new device. You
may save time writing with HDL up front, but if it is for a fast/dense
design, you will spend a great amount of time massaging it, rewriting it,
or you may not even be able to use it at all, or spend a lot more money on
a larger, faster part.

I have some clients who I told them they would only have to pay me what I
save them.  For one, I converted their VHDL to schematics, went down two
part sizes, and two speed grades, saving $46 per board, and the volume is
in the thousands!

Austin Franklin
darkroom@ix.netcom.com


Article: 4367
Subject: Has anyone ever used a C -> Xilinx netlister?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 21 Oct 1996 03:09:25 GMT
Links: << >>  << T >>  << A >>
There are two C -> Xilinx netlisters I know of, and I am curious if anyone
has any experience with them, or any others.

The first I know of is called NLC, developed by Christian Iseli at the
System Logic Lab of the Federal Polytechnical School of Lausanne,
Switzerland.  The second I know of was developed by the networking group of
Digital in California.

Thanks,

Austin Franklin
darkroom@ix.netcom.com

Article: 4368
Subject: Evolvable hardware/evolutionary elecronics
From: monty@watson.open.ac.uk (Tony Hirst)
Date: Mon, 21 Oct 1996 12:33:55 GMT
Links: << >>  << T >>  << A >>
Anyone making use of links via my EHW/Evolutionary Electronics Resources
web page please note a change of host

*from*      kmi.open.ac.uk/~monty/EHW.html, evolelec.html etc

*to*     watson.open.ac.uk/~monty/EHW.html, evolelec.html etc

thanks

monty

--------------------------------------------------------------------------
 All opinions etc etc...
--------------------------------------------------------------------------
      | Tony Hirst ("Monty")          | e-mail:  A.J.Hirst@open.ac.uk
       -------------------------------------------------------------------

Article: 4369
Subject: VHDL Aware Editor
From: John Maher <jmaher@vhdl.com.au>
Date: 21 Oct 1996 12:37:43 GMT
Links: << >>  << T >>  << A >>
To whom it concerns:

There is free evaluation copy of a VHDL aware editor called 
Setanta ED. It runs on Win 3.x, Win95 and Windows NT

This editor can:

-highlight keywords
-template expansions
-free VHDL models for commonly used components
-integrated to work with Model Technologies Vsystem and 
Accolade Design Inc. PeakVHDL

-No limit to buffer or file size.

-Fully user configureable, including menus and the ability to 
write macro functions.

- Also supports C,C++, pascal, HTML, JAVA and up to 20 other 
languages!

For details and your free download, see http://www.vhdl.com.au


-John Maher

 VHDL System Solutions P/L
 128 Lt. Lonsdale St.
 Melbourne
 Victoria
 Australia

+61 419 897 789 


Article: 4370
Subject: Re: VHDL for Xilinx designs?
From: garyk@svpal.svpal.org (George Noten)
Date: 21 Oct 1996 15:50:28 GMT
Links: << >>  << T >>  << A >>
extra z to stop junk mail (zz80@digiserve.com) wrote:
: Austin,

: I thought I would never hear anyone say this. 

: Having tried to get into VHDL myself, I feel exactly the same way
: about it. But there is so much hype in the press, and so many people
: are trying to use it for applications for which good old schematic
: entry would have been far more appropriate.

: Peter.

 Agreed 100%.  Unfortunately, it is very difficult to work with both
 tools.  I don't know any vendor that provides good integration between
 schematic entry and an HDL ( I still prefer to write state machines
 using HDL and not schematic).

	George
Article: 4371
Subject: Re: VHDL for Xilinx designs?
From: "Austin Franklin" <darkroom@ix.netcom.com>
Date: 21 Oct 1996 19:01:59 GMT
Links: << >>  << T >>  << A >>
Viewlogic does.  It is *REAL* easy to do.  In ViewDraw, make a symbol for
the VHDL code, change the attributes on the symbol to get it to use the
VHDL and voila! you have VHDL and schematics.  You have to write the VHDL
code too...  You can do unit delay simulation directly.  To compile the
chip, and do timed simulation, use any VHDL compiler that supports .xnf
output, so when you run xnfmerge it will find the compiled VHDL code...

Austin Franklin
darkroom@ix.netcom.com


> 
>  Agreed 100%.  Unfortunately, it is very difficult to work with both
>  tools.  I don't know any vendor that provides good integration between
>  schematic entry and an HDL ( I still prefer to write state machines
>  using HDL and not schematic).
> 
> 	George
> 
Article: 4372
Subject: Re: VHDL for Xilinx designs?
From: Lance Gin <c43lyg@dso.hac.com>
Date: Mon, 21 Oct 1996 21:06:07 -0700
Links: << >>  << T >>  << A >>
George Noten wrote:

(snip)
> 
>  Agreed 100%.  Unfortunately, it is very difficult to work with both
>  tools.  I don't know any vendor that provides good integration between
>  schematic entry and an HDL ( I still prefer to write state machines
>  using HDL and not schematic).
> 
>         George

mentor graphics provides the ability to capture/simulate mixed
vhdl/schematic designs with their qv-pro system (although i've been using
qv-pro primarily in all-vhdl mode so far.

my "vhdl/xilinx" pet peeves are more with regard to:

1. xilinx not officially supporting xnf netlists synthesized by mentor's
   autologic II which forces me to use SG to synthesize schematics before
   going to the XACT backend.

2. lack of xilinx synthesis documentation to support non-synopsys users. this
   is a crime because many vhdl/fpga users are new to synthesis (as pointed
   out by someone else in this thread). synopsys won the asic synthesis market,
   but the fpga market is still up for grabs (eg. exemplar, synplicity).

3. ppr's limited ability to do incremental layout (ala guide file mechanism)
   when the design is mostly hdl-based. the guide option relies on net
   names as reference points (but synthesis keeps changing them).

i wish xilinx would ressurect some of the neat place/route technology they
developed for their ill-fated antifuse family (which was marketed as being
"synthesis-friendly"). the 8100 place/route program supposedly performed
incrementally not by matching net names, but by performing topological
comparison. a cool idea.

-- 
_______________________________________________________________________

Lance Gin                                         "off the keyboard
Delco Systems - GM Hughes Electronics              over the bridge,
OFC: 805.961.7567  FAX: 805.961.7739               through the gateway,
C43LYG@dso.hac.com                                 nothing but NET!"
_______________________________________________________________________
Article: 4373
Subject: Re: VHDL for Xilinx designs?
From: Lance Gin <c43lyg@dso.hac.com>
Date: Mon, 21 Oct 1996 21:36:19 -0700
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

(snip)
> 
> Second is controlability.  It is much harder to floorplan an HDL design.
> Much harder...  I find that floorplanning is the real key to resource
> utilization and speed, especially for FPGAs.

especially when CLB arrays are involved. i've done standard-cell and
structured-custom layout (where physical resources are admittedly often
less scarce and not fixed). in each of these paradigms, one reason the
place/route problem is less complex than CLB's is because there are fewer
primitives to deal with. a 32-bit counter is floorplanned as a *single*
(sometimes malleable) entity. but in a CLB array, the floorplanner is
confronted with a myriad of primitives which make up the counter!
who wants to deal with a bunch of individual F, G, H, and DFF primitives
for each single *bit*?! (well, possibly the fpga consultants who make
money by "rescuing" fpga projects for a living)  ;)

add on top of that the effort required to correlate your hdl code to
the synthesized instance/net names that appear in the floorplanner and
you've got yourself a nice challenge.

-- 
_______________________________________________________________________

Lance Gin                                         "off the keyboard
Delco Systems - GM Hughes Electronics              over the bridge,
OFC: 805.961.7567  FAX: 805.961.7739               through the gateway,
C43LYG@dso.hac.com                                 nothing but NET!"
_______________________________________________________________________
Article: 4374
Subject: Re: VHDL for Xilinx designs?
From: wehr@mikro.uni-stuttgart.de (Andreas Wehr)
Date: 22 Oct 1996 06:50:32 GMT
Links: << >>  << T >>  << A >>
In article 2da8b8cd@drt1, "Austin Franklin" <darkroom@ix.netcom.com> writes:

>A number of problems exist with HDLs in general.  One is you don't know
>exactly what the code is going to compile down to...  

Synthesis is a deterministic process!

>it's not as good.  In an HDL, a case statement can become this really obese
>thing checking for every possible condition for each branch...  

In In IEEE Standard Logic 1164 there is a dontcare value and in 
HDLs there is something like 'others' or 'default' statements ...

>believe you can do pretty well with some finely crafted HDL code, if you
>know exactly what it is going to compile down to.

Same with schematics, only finely crafted schematics...

>Second is controlability.  It is much harder to floorplan an HDL design. 
>Much harder...  I find that floorplanning is the real key to resource
>utilization and speed, especially for FPGAs.

HDL has nothing to do with floorplanning, you have to floorplan a schematic
and a HDL design.

>Personally, I like to mix both...but schematics is really the way to go for
>the best speed and resource utilization.  I do schematics with my own
>libraries of n bit registers, tbufs, counters, muxes.  

In VHDL there are generics for this, and you can create also small libraries
with registers, counters AND in a non-fixed width!

>They are device independent, 

This one of the big advantage of HDLs.
With one HDL DEscription I can do a FPGA from XILINX, ACTEL or what you want
AND an ASIC. The only thing you need is the appropriate setup file
and the technology libs. But only one HDL description.

 and require very little library work to add a new device. You
>may save time writing with HDL up front, but if it is for a fast/dense
>design, you will spend a great amount of time massaging it, rewriting it,

Why? When the counter will get bigger i have to change only a generic .
Is this a great amount?

>I have some clients who I told them they would only have to pay me what I
>save them.  For one, I converted their VHDL to schematics, went down two
>part sizes, and two speed grades, saving $46 per board, and the volume is
>in the thousands!

I bet, optimization of the VHDL to better VHDL had saved more than $46!

Andreas



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