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 10050

Article: 10050
Subject: Re: Arbiter help !!!
From: murray@pa.dec.com (Hal Murray)
Date: 24 Apr 1998 09:13:33 GMT
Links: << >>  << T >>  << A >>
In article <6hmksq$vm4$1@nnrp1.dejanews.com>, channing-wen@usa.net writes:

> First, I CAN'T guarantee that requests will not arrive at the same time;

You have to build a circuit that picks one when they do arrive close together.
[If they are close enough in time, it doesn't matter which one you pick.]
Don't forget the case when 3 or 4 arrive all together.

> The Second, the requests are realy "First Come, First Served", I CAN'T set
> any other priority, for instance, there are four requests INT0, INT1, INT2
> and INT3 will arrive at any time, when the controller processing the first

I think you have to build a small FIFO.

One way is for each slot in the FIFO to have an empty-full flag and
4 FFs, one for each int.

You could compress the 4 FFs to 2.  (There are only 4 possible states.
Actually 5 if you count empty, but you have another FF for that.)


-- 
These are my opinions, not necessarily my employers.
Article: 10051
Subject: Re: Ask for / Discuss which FPGA & ASIC tools best buy
From: leslie.yip@asmpt.com
Date: Fri, 24 Apr 1998 03:38:29 -0600
Links: << >>  << T >>  << A >>
Dear everybody

Welcome other tools as evaluation and comparison, discussion !

I would like to like the performance of the following tools:

1) Synopsis FPGA Express

2) FPGA vendor: Actel


In article <6hkboc$k6o$1@nnrp1.dejanews.com>,
  leslie.yip@asmpt.com wrote:
>
> In fact this idea raises when I answer the e-mail from the person below. As
I
> come to a new company doing ASIC & FPGA design. I would like to seek advice
> from different people for the company to buy a new tool for synthesis,
> simulation and implementation.
>
> Xilinx - very popular vendor. Good FPGA tool. Excellent for moderate design
> like joystick, Gun for playing TV games (PS, .....). But it seems quite
> difficult for trouble shooting on a large design about 30,000 gates on PC
> environment. I have used to design a video ASIC chip with DRAM & SDRAM
> controller. Another problem is the cost. It is quite expensive, probablity
> because its name is commonly known.
>
> Epson - Auklet. SLAx000 series. This tool is a Gate-level design. You can
draw
> schematic diagram and simulate. Its cost is low for small quantity. Besides,
> it has some embedded chip for FPGAs.
>
> Exemplar Leonardo -
>
> ModelSim (V-system) - Fast simulation even for large design
>
> Viewlogic - ViewLogic consists of ViewDraw,ViewSim and ViewTrace which
allows
> us to draw schematic diagrams with connections of module blocks such that
each
> blocks can be formulated from the library or based on VHDL codes (compiled
by
> Designer Series etc.). We would then checked out the whether if the VHDL
codes
> or connections are correct by simulation through ViewSim. One can execute
the
> command file which contains all the input signals (to test all the blocks).
Or
> you may compile & execute the Testbench file. Actually I use ViewLogic for
> small design, as it takes long time to compile. Someone may like the
schematic
> generating, perhaps for easy trouble shooting.
>
> ----------
> From: 	Yip Yiu Man
> Sent: 	Wednesday, April 22, 1998 8:39 AM
> To: 	'engp6396@leonis.nus.edu.sg'
> Subject: 	RE: Exemplar Leonardo Experiences; Many bugs in ViewLogic &
> MAX
>
> Siew Kuok,
>
> Actually I use ViewLogic for small design, as it takes long time to compile.
> Someone may like the schematic generating, perhaps for easy trouble
shooting.
>
> In the past, I simulate the result like Xilinx command tool, ViewSim,
> executing the command file. It seems to me that this one costs a lot of time
> to do synthesis and sometimes some unexpected results occur.
>
> Perhaps these are the most important factors that people concern.
>
> Best regards,
>
> YM Yip
> Yip Yiu Man, Leslie
> 5/F ES
> Phone:	+852 26912 835		FAX:	+852 26192 159
> E-mail:	leslie.yip@asmpt.com
>
> ----------
> From: 	engp6396@leonis.nus.edu.sg[SMTP:engp6396@leonis.nus.edu.sg]
> Sent: 	Monday, April 20, 1998 5:14PM
> To: 	leslie.yip@asmpt.com
> Subject: 	Re: Exemplar Leonardo Experiences; Many bugs in ViewLogic &
> MAX
>
> Hi Leslie,
>   While reading the newsgroup, I came across your message posting and I
> would like to seek advice from you on this  :
>
> Software programs like ViewLogic consists of ViewDraw,ViewSim and
> ViewTrace which allows us to draw schematic diagrams with connections of
> module blocks such that each blocks can be formulated from the library
> or based on VHDL codes (compiled by Designer Series etc.). We would then
> checked out the whether if the VHDL codes or connections are correct by
> simulation through ViewSim. I suppose by executing the command file
> which contains all the input signals (to test all the blocks), it is
> like compiling & executing the Testbench file ? It seems that with the
> ViewDraw & ViewSim, we can more or less elminate the need for writing
> test benches, why would people still stick to using test benches sort of
> thing ?
>
>   Is the ViewSynthesis, the application to compile & link Test Benches &
> programs of VHDL codes ?
>
>   Hope you don't mind these simple questions as I am still a novice in
> VHDL & ViewLogic.
>
> Thanks,
> Siew Kuok
>
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/   Now offering spam-free web-based newsreading
>


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
Article: 10052
Subject: Re: Xilinx Serial Proms
From: "Michael W. Ellis" <in@the.text>
Date: Fri, 24 Apr 1998 12:24:19 -0500
Links: << >>  << T >>  << A >>
Austin Franklin wrote in message <01bd6f15$a09ad560$7370d6ce@drt3>...
>Most any programmer that claim to be able to program these parts have these
>set as 'options'.  I know the late(r) Data I/O and BP MicroSystems do it
>this way.  You might have to get late(r) software for your Data OH-NO! or
>what ever programmer you are using.
>
>I remember 6 years ago having to change some locations when using a Data
>OH-NO! UniSite.  I think that is so lame on the programmer manufacturers to
>not make this easier...but I believe most do these days.
>


I'm using a Data I/O 3900 to program my parts.  I have been able to force
the appropriate locations low in my particular case by filling ram with 00
before downloading the mcs file.  This seems to work as long as I remember
to set up the programmer to do this for me.  Tha said, it is my opinion that
this issue is not the responsibility of the programmer -- it is the
responsibility of Xilinx.  Their toolset is generating the rom image that is
used to program their part, but they do not provide a direct method of
setting the polarity of the pin.

--
Michael Ellis
first initial last name at pesa dot you know what



Article: 10053
Subject: Re: XC4000XL and Ground Bouncing
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 24 Apr 1998 10:31:36 -0700
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> Kim Hofmans wrote:
> >
> > Hiya,
> >
> > I'm having severe problems with ground bouncing while driving 32 bit
> data
> > to the
> > output. I'm using a XC4010XL-2.
> > The design uses 4 clok inputs (two 53Mhz clocks and two 106Mhz
> clocks)
> > Turning off the FAST attribute seemed to help a lot. But still the
> ground
> > bouncing occurs. Sometimes more than 2V overshoot.
> > Anyone having similar problems and know how to fix this ?
> > With a XC4000E-2 (same design) I didn't have problems.
> > Thanks in advance,
> >
> > Kim
>
> Good PCB design with very low impedance power/ground distribution and
> good bypassing at the power pins.  Keep to dynamic loading on the FPGA
>
> outputs small too (especially watch capacitance).  You may also need
> to
> control the impedance of signal lines.
> --
> -Ray Andraka, P.E.

More advice:
It helps to stagger the outputs, e.g. by clocking the even bits with one
clock, the odd bits with a slightly delayed clock ( run the clock
through some CLB ). It might even help to have some outputs fast and
others slew-rate limited. Anything to make the SSOs less "simultaneous".

Also: a single-frequency synchronous design is surprisingly tolerant,
but a design with several unrelated clocks will inevitably look at the
inputs sometimes in the middle of an output ground-bounce. Keep the
clocks crisp and give them the best possible Vol and Voh.

Peter Alfke, Xilinx Applications

Article: 10054
Subject: Re: XC4000XL and Ground Bouncing
From: Dave Graf <dgraf@NOSPAM.atvideo.com>
Date: Fri, 24 Apr 1998 11:23:41 -0700
Links: << >>  << T >>  << A >>
Kim Hofmans wrote:

> I'm having severe problems with ground bouncing while driving 32 bit data
> to the output. I'm using a XC4010XL-2.
> The design uses 4 clok inputs (two 53Mhz clocks and two 106Mhz clocks)
> Turning off the FAST attribute seemed to help a lot. But still the ground
> bouncing occurs. Sometimes more than 2V overshoot.
> 
> Anyone having similar problems and know how to fix this ?
> 
> With a XC4000E-2 (same design) I didn't have problems.

This is not an unusual problem with faster FPGA devices. There were some
good articles on the subject of Signal Integrity about a year and a half
ago in EE Times (Sept. '96 - I think). Usually, the ground bounce can be
minimized by selecting the right termination (series R or parallel AC).
I've used BoardSim from HyperLynx which analyzes your PCB and recommends
the proper termination. They have a lot of IBIS (output driver) models
available including the XL4000XL family.
Article: 10055
Subject: Why Altera & Cypress Software Clashes (was: VHDL compiler differences?)
From: jcooley@world.std.com (John Cooley)
Date: Fri, 24 Apr 1998 19:04:51 GMT
Links: << >>  << T >>  << A >>
Steve Dewey <Steve@s-deweynospam.demon.co.uk> wrote:
>Why can't I take my Altera VHDL and run it on another _cheap_ vendor-specific 
>VHDL tool, eg cypress warp ?
>
>Sorry if these are obvious and reveal a lack of insight on my part.

The quick answer is that Altera is primarily interested in getting you to
buy and use Altera chips.  Cypress wants you to buy Cypress chips.  Neither
company really cares about you if you're going to use someone else's
FPGAs, hence the disincentive towards having their compilers being
compatiable.  If you want universiality, go to vendors who are financially
motivated to keep you universal: the EDA vendors.  (EDA stands for "Electronic
Design Automation" and is just a fancy way of saying "the guys who make
software used for chip design".)  For example, if you buy Synopsys, Exemplar,
Synplicity, or any of the other software from an EDA vendor for FPGA
synthesis, it will work with Altera, Xilinx, Cypress, etc. BECAUSE it's
the EDA vendor's bread & butter to let their customers CHOOSE between
competing FPGA vendors.

(Sorry if I appear to be explaining the obvious to you, but you said you were
a newbie who didn't understand these issues.)

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

============================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 6000+ 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: 10056
Subject: Re: XC4000XL and Ground Bouncing
From: Brad Taylor <Brad.Taylor@xilinx.com>
Date: Fri, 24 Apr 1998 12:28:33 -0700
Links: << >>  << T >>  << A >>
Kim Hofmans wrote:
> >
> > Hiya,
> >
> > I'm having severe problems with ground bouncing while driving 32 bit data
> > to the
> > output. I'm using a XC4010XL-2.
> > The design uses 4 clok inputs (two 53Mhz clocks and two 106Mhz clocks)
> > Turning off the FAST attribute seemed to help a lot. But still the ground
> > bouncing occurs. Sometimes more than 2V overshoot.
> >
> > Anyone having similar problems and know how to fix this ?
> >
> > With a XC4000E-2 (same design) I didn't have problems.
> >
> > Thanks in advance,
> >
> > Kim

This may not help you, but a nice trick is to add additional ground pins
to the package by driving a (well positioned) IOB to ground, then
connecting the pad to ground plane (via a close via). If your package
has 16 grounds and you add 16 "pseudo-grounds" you should be able to cut
ground bounce by factor of two.  

-
Brad



-- 
====================================================================
 User Name:        blt
 Intranet Site:    http://web/~blt/top.html
 A map to my cube: http://web/~blt/how_to_find_me.txt
 Email:            brad.taylor@xilinx.com 
 Phone:            1-408-879-6976
 Fax:              1-408-879-4676
 Address:          2100 Logic Drive, San Jose, Ca. 95124

====================================================================
Article: 10057
Subject: Re: Could you help me save CLB's?
From: Rickman <spamgoeshere1@yahoo.com>
Date: Fri, 24 Apr 1998 15:42:38 -0400
Links: << >>  << T >>  << A >>
Vitit Kantabutra wrote:
> 
> Thanks a lot for your extensive reply.  The reason I'm struggling with
> carry-save adders is because I'm trying to do the X & Y iterations for my
> radix-4 CORDIC algorithm.  A Xilinx application engineer responded by
> suggesting reducing 4 operands to 3, instead of 3 to 2.  (He's done carry-save
> adders himself.)  But it seems to me that this would take 3 CLB's for every 2
> bit positions.  Is it possible to do better?

-- 
I guess I have been out of school too long. I don't remember what a
carry-save adder is, and I don't believe I ever learned about the CORDIC
algorithm. My question is, why do you need a carry-save adder as opposed
to whatever adder is fastest in a given device? Perhaps you can tell us
a little more about the details of your adder requirements? What length
are the two operands? How fast are you trying to run? 

I looked at fast ripple carry adders in Xilinx XC4000 parts in great
detail a few years ago. The parts have gotten much faster, but the
principles have not changed. If your adder is less than 4 or 5 bits,
then it is faster to do it in function generators. If your adder is more
than about 6 bits, then it is faster to do it with the dedicated carry
logic. Of course, each added bit makes the adder run slower. But keep in
mind that most of the prior research into fast adder circuits was done
way before there were FPGA devices. These devices have limitations that
custom designs don't have. So you optimize for speed differently. 

Are you using carry-save so that you can pipeline each bit of each
adder? If so, then I would think very hard about using the Atmel line of
chips. Their one real strength is in this type of systolic processing,
since they have a register in each cell and have many more cells than
other logic families. 

BTW, in an earlier post I said that the Atmel chips could do a full
adder in a single cell. That was the 6K product line and it is a HALF
adder in each cell. Basically they have an XOR gate along with a pair of
AND gates in each cell along with the register. So if you are making
HALF adders, you can see there is not much logic wasted. I know a lot
less about the AT40K family. 


Rick Collins

rickmanX@Ywriteme.com

remove the XY to email me.
Article: 10058
Subject: Re: Could you help me save CLB's?
From: Rickman <spamgoeshere1@yahoo.com>
Date: Fri, 24 Apr 1998 15:48:49 -0400
Links: << >>  << T >>  << A >>
I read your summary later in this group which answered my questions. 

Thanks,

Rick Collins



Rickman wrote:
> 
> Vitit Kantabutra wrote:
> >
> > Thanks a lot for your extensive reply.  The reason I'm struggling with
> > carry-save adders is because I'm trying to do the X & Y iterations for my
> > radix-4 CORDIC algorithm.  A Xilinx application engineer responded by
> > suggesting reducing 4 operands to 3, instead of 3 to 2.  (He's done carry-save
> > adders himself.)  But it seems to me that this would take 3 CLB's for every 2
> > bit positions.  Is it possible to do better?
> 
> --
> I guess I have been out of school too long. I don't remember what a
> carry-save adder is, and I don't believe I ever learned about the CORDIC
> algorithm. My question is, why do you need a carry-save adder as opposed
> to whatever adder is fastest in a given device? Perhaps you can tell us
> a little more about the details of your adder requirements? What length
> are the two operands? How fast are you trying to run?
> 
> I looked at fast ripple carry adders in Xilinx XC4000 parts in great
> detail a few years ago. The parts have gotten much faster, but the
> principles have not changed. If your adder is less than 4 or 5 bits,
> then it is faster to do it in function generators. If your adder is more
> than about 6 bits, then it is faster to do it with the dedicated carry
> logic. Of course, each added bit makes the adder run slower. But keep in
> mind that most of the prior research into fast adder circuits was done
> way before there were FPGA devices. These devices have limitations that
> custom designs don't have. So you optimize for speed differently.
> 
> Are you using carry-save so that you can pipeline each bit of each
> adder? If so, then I would think very hard about using the Atmel line of
> chips. Their one real strength is in this type of systolic processing,
> since they have a register in each cell and have many more cells than
> other logic families.
> 
> BTW, in an earlier post I said that the Atmel chips could do a full
> adder in a single cell. That was the 6K product line and it is a HALF
> adder in each cell. Basically they have an XOR gate along with a pair of
> AND gates in each cell along with the register. So if you are making
> HALF adders, you can see there is not much logic wasted. I know a lot
> less about the AT40K family.
> 
> Rick Collins
> 
> rickmanX@Ywriteme.com
> 
> remove the XY to email me.

-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.
Article: 10059
Subject: Re: Could you help me save CLB's?
From: Douglas Clayton <dclayton@fore.com>
Date: Fri, 24 Apr 1998 16:55:37 -0400
Links: << >>  << T >>  << A >>
Rickman wrote:

<snip adder discussion>
 
> BTW, in an earlier post I said that the Atmel chips could do a full
> adder in a single cell. That was the 6K product line and it is a HALF
> adder in each cell. Basically they have an XOR gate along with a pair of
> AND gates in each cell along with the register. So if you are making
> HALF adders, you can see there is not much logic wasted. I know a lot
> less about the AT40K family.

The AT40K can implement a full adder in each cell, meaning an n-bit
ripple-carry adder takes n cells. Furthermore, the direct connections
between cells give you a pretty fast carry chain. 

Now if only they had better routing....

Douglas Clayton
Article: 10060
Subject: How low can they go?
From: s_clubb@die.spammer.netcomuk.co.uk (Stuart Clubb)
Date: Fri, 24 Apr 1998 21:00:53 GMT
Links: << >>  << T >>  << A >>
Hi all,

There I was, flicking through one of the industry weekly's, when I
stumbled across an advert for a Cypress 4Mbit RAM. Nothing remarkable
in that, except I was taken by the "26 million transistors" blurb.
This rang a bell, as I remember this big fuss about an XC40125XV
having 25 Million transistors, and being so difficult to produce,
needing 0.25 micron etc.

Here's some interesting math then:

XC40125XV-2BC560C : $1995.00 in 100 up. (www.marshall.com)
CY7C1049-25VC : $30.60 in 100 up. (www.arrowsemi.com)

So, in the limit, 25 million transistors = 125K FPGA gates.....

We should see 25 cents per thousand gates as soon as the vendors can
pile enough layers of metal on top of the transitors. Hell, then
somebody had better figure out how to build a two tier substrate to
get two transistors in the same area :-)

Here's my new revised price list for the big two :

Xilinx 40125XV : $30.60
Altera 10K100 : $15.18
Xilinx 4044XL : $10.77
Altera 6016 : $1.47
Xilinx 4005XL : $1.22

I know that there are issues such as packaging, economies of scale,
market "worth" etc, but comments are invited nevertheless.

Stuart

Article: 10061
Subject: Re: How low can they go?
From: Christian =?iso-8859-1?Q?Sch=E4fer?= <schaefer@calle2.ruhr.de>
Date: Sat, 25 Apr 1998 01:12:24 +0200
Links: << >>  << T >>  << A >>
Stuart Clubb wrote:
> There I was, flicking through one of the industry weekly's, when I
> stumbled across an advert for a Cypress 4Mbit RAM. Nothing remarkable
> in that, except I was taken by the "26 million transistors" blurb.
> This rang a bell, as I remember this big fuss about an XC40125XV
> having 25 Million transistors, and being so difficult to produce,
> needing 0.25 micron etc.
> 
> Here's some interesting math then:
> 
> XC40125XV-2BC560C : $1995.00 in 100 up. (www.marshall.com)
> CY7C1049-25VC : $30.60 in 100 up. (www.arrowsemi.com)
> 
> So, in the limit, 25 million transistors = 125K FPGA gates.....

You can't compare DRAMs and other chips: DRAM has simple regular
structures and therefor is easy to build compared to logic chips. In
fact new chip fabs and new fabrication processes are "tested" by
producing DRAMs first. DRAM chips can even be repaired by laser (but I
don't know if this is done regularly). The yield rate is much higher for
DRAMs than for logic chips. 

Bis dann,
Christian.

-- 
PGP: pgp-public-keys@keys.de.pgp.net  Subject: GET 0x73036211
Fingerprint: 33 20 99 54 66 C1 1C 32  D9 C1 BC F8 53 AF E4 C6
Luxus ist das, was uns zusammenhaelt    (Herbert Groenemeyer)
http://www.ruhr.de/home/calle2/esc/esc1.html   Moskitos Essen
Article: 10062
Subject: Re: How low can they go?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 24 Apr 1998 16:43:50 -0700
Links: << >>  << T >>  << A >>
Stuart Clubb wrote:

> Hi all,
>
> There I was, flicking through one of the industry weekly's, when I
> stumbled across an advert for a Cypress 4Mbit RAM. Nothing remarkable
> in that, except I was taken by the "26 million transistors" blurb.
> This rang a bell, as I remember this big fuss about an XC40125XV
> having 25 Million transistors, and being so difficult to produce,
> needing 0.25 micron etc.

snip...

I know that Stuart wasn't all that serious, so let me give the answer in
the same tone:

The 125,000 gates in the XC40125 are actually free, you pay $ 0.00
The only thing you have to pay for is the programmable interconnect,
which happens to be  very complex and demanding in silicon area.

This actually applies equally well to our dear competion.

RAMs are the ultimate commodity: no structural flexibility, very simple
interconnect,  very densely packed, self-evident use needing no
technical support, made in very high volume by manufacturers who tend to
lose money in the process.

FPGAs offer enormous structural flexibility and complex interconnect,
which reduces transistor packing density. They need a lot of technical
support, and are made in much lower volume ( well, we shipped something
like 70 million of them over the past ten years, but that's what the
(D)RAM guys ship in a week ) by manufacturers who, thank God, are
profitable, so they have the money to develop new circuits more often
than the 4-year cycle in the RAM industry.

Microprocessors are somewhere in-between.

It's all a matter of perspective.

Peter Alfke, Xilinx Applications
 
 
 
 

>  
>  

 
 

Article: 10063
Subject: Re: Xilinx Serial Proms
From: murray@pa.dec.com (Hal Murray)
Date: 24 Apr 1998 23:56:05 GMT
Links: << >>  << T >>  << A >>
[This is part of a discussion on how to flip the reset-polarity bit.]

> One could develop a little awk program which would run, in e.g. a
> batch file, and edit the .mcs file as required.

One of my gripes is that the Xilinx tools don't have any way to
specify that option in the "source" code.  (I admit that the last
time I checked was a while ago.)  I've always had to set it manually
at the programmer, and that means I have to remember to do it.

I'm willing to call a command file or a makefile "source".  I just want
to put that info someplace where I don't have to remember any more.


Is it possible to put the info into the file that
you can feed to a ROM blaster?

If so, is the recipe documented anywhere?

-- 
These are my opinions, not necessarily my employers.
Article: 10064
Subject: http://www.ebnonline.com
From: b <b@b.com>
Date: Fri, 24 Apr 1998 23:39:33 -0400
Links: << >>  << T >>  << A >>
Take a visit to EBN. Electronic Buyers News web site.  Great for EEs,
electronic component purchasers and general computer part information
plus much more.
http://www.ebnonline.com
Article: 10065
Subject: Re: Synopsys FPGA compiler
From: cheebie@smart.net (Brian "Cheebie" Merchant)
Date: Sat, 25 Apr 1998 04:22:42 GMT
Links: << >>  << T >>  << A >>
In the dying days of the second millennium, Per Fremrot wrote:

>
>I have just started to use Synopsys FPGA compiler and I am slightly
>confused regarding the difference in optimization between DC and
>FPGA-compiler libraries. I am trying to port a standard cell design to
>FPGA (Xilinx) and have (not suprisingly) run into some performance
>problems.

To be 100% Frank, fpga_compiler leaves a lot to be desired as an FPGA synthesys
tool.  If you take a good look at the results, you will see that it still is
doing cell based synthesys and then converting each cell to a LUT!  This is
incredibly inefficient.

Luckily, Synopsys is fixing this.  fpga_express is a vast improvement.  The
algorithm uses LUTs much more efficiently and is faster by an order of
magnitude.  Supposedly fpga_compiler II will incorporate the same algorithms.

When I went from fpga_compiler to fpga_express, I saw a drop from 873/900 sites
used to 680/900 sites.  The speed went from unroutable to 20MHz.

---
cheebie@smart.net
The Mighty Cheebie: loyal drone in the service of Da Queen
Eater of Oreos, wearer of wing weaves, maker of pillows.
Article: 10066
Subject: Re: Could you help me save CLB's?
From: lemieux@eecg.toronto.edu (Guy Lemieux)
Date: 25 Apr 98 05:57:22 GMT
Links: << >>  << T >>  << A >>
staylor@dspsystems.com wrote:
>   Vitit Kantabutra <vkantabu@computer.org> wrote:
> > So why not have several "flavor" of CLB's?  There are certainly enough
> > models of FPGA's out there to support that.
> Because there is such a thing as lawsuits and intellectual property.

also, two more things:
	1/ inventory
	2/ software

the first one... fpga vendors would like to keep variety of
inventory down as much as possible.  keeping small, specialty
chips that ship in low volume is expensive.

the second one is probably more important.  fpga technology
mappers must convert your logic demands into the CLB contents.
it is costly to begin writing new software which behaves in
a much different fashion than the old software.  that's one
reason why xilinx hasn't changed their CLBs much of the last
few years (if it ain't broke...).  there has been lots of
research on the tech mapping issue, but it has focused on
specific small subdomains of the larger problem.  i don't think
multi-output CLBs has been looked at very seriously yet.  the
field is still young, and lots of work remains to be done.
unless the software can efficiently utilize new CLB structures,
you won't be seeing many new CLBs.

guy lemieux
Article: 10067
Subject: Re: XC4000XL and Ground Bouncing
From: bk&dontyabespamminme&willi@smart.net (Bryan Williams)
Date: Sat, 25 Apr 1998 06:04:07 GMT
Links: << >>  << T >>  << A >>
On Fri, 24 Apr 1998 11:23:41 -0700, Dave Graf
<dgraf@NOSPAM.atvideo.com> wrote:

>Kim Hofmans wrote:
>
>> I'm having severe problems with ground bouncing while driving 32 bit data
>> to the output. I'm using a XC4010XL-2.
>> The design uses 4 clok inputs (two 53Mhz clocks and two 106Mhz clocks)
>> Turning off the FAST attribute seemed to help a lot. But still the ground
>> bouncing occurs. Sometimes more than 2V overshoot.
>> 
>> Anyone having similar problems and know how to fix this ?
>> 
>> With a XC4000E-2 (same design) I didn't have problems.
>
>This is not an unusual problem with faster FPGA devices. There were some
>good articles on the subject of Signal Integrity about a year and a half
>ago in EE Times (Sept. '96 - I think). Usually, the ground bounce can be
>minimized by selecting the right termination (series R or parallel AC).
>I've used BoardSim from HyperLynx which analyzes your PCB and recommends
>the proper termination. They have a lot of IBIS (output driver) models
>available including the XL4000XL family.
I got set up with the Hyperlynx Hypersuite about a week ago, I
personally haven't been greatly excited by the IBIS model availability
(which is the fault of the manufacturers).  First off, if Kim's got
data being clocked at 103MHz, I don't see how a SLOW output can work,
period.  Then again, the Xilinx IBIS model doesn't give me great
confidence -- I'm trying to simulate 4000E series devices, but only a
FAST output is given.  The 0.6 micron 4000-series has comparable FAST
slew rates with IBIS models(though slightly slower) so I can only
assume the SLOW 4000E's are not far off from the SLOW 4000's (same
geometry, not that there's 0.8 and 0.6 micron 4000's to choose from).
It would be nice to have accurate models.  Simulating a 4000 0.6u SLOW
output driving a clock signal over a 6" 95-ohm microstrip (built it up
in Linesim to check the models) with 95 ohm/50pF AC terminator, well,
I wouldn't recommend more than 10 MHz due to duty-cycle massacre with
the rise/fall time differences  -- maybe 20 mbit/second data rate if
setup/hold allow for data signals.  XL series I realize is much faster
than the 0.6 micron process Xilinx, YMMV.

If Kim's application allows --- that is, if the data path is
point-to-point, then series terminators will work miracles.  Multidrop
busses at this speed would scare me -- for this application I'd
suggest checking out the Schottky Diode Bus Terminators at California
Micro Devices -- www.calmicro.com -- they're supposedly optimized for
high speed applications (most schottky discrete diodes are optimized
for relatively slow switchmode power supplies) and can terminate
anything -- so they say-- I never tried them.  Obviously need good
power planes for them to be effective.  They work by simply clamping
the overshoot regardless of impedance.  Useful for memory busses and
stuff where you have changing transmission line schemes.  The Cal
Micro devices have SPICE models available, I suppose these can be run
through SPICE2IBIS and get IBIS models- haven't tried it yet.

Oh yeah, the Cal Micro parts are meant for busses- if anyone knows of
a maker of SOT-23 type single units similar in function I'd appreciate
a pointer.  Problem with the Cal Micro bus-oriented parts is that I
really need them for scattered signals, and terminators aren't as
useful if it means routing a long way to get to them.  

Another site you might want to visit on your journey to signal
integrity, http://www.sigcon.com/books.htm  -- BUY THIS BOOK.
As an alternative, you could do some graduate study at the University
of Kentucky under Dr Clayton Paul and get the same knowledge, and get
free basketball tickets to see the 1998 NCAA champs :)  (forgive me,
I'm an alumnus).   

Dr Johnson's book (you might have seen his new column in EDN) is a
no-nonsense, readable book with good knowledge to draw from -- that's
saying a LOT when it comes to EMC/Signal integrity issues -- most
books are way too theoretical and thus totally useless.  He tends to
be a little pessimistic about termination requirements (ie, terminate
if the length >= rise time x velocity / 6 -- some say divide by 4,
some 2.5 -- but then, I don't make commercial products that have to go
through FCC part 15 testing so I haven't compared results).   For
example, when simulating with Hyperlynx, HL tells me I need to
terminate my memory bus if it's over 2.1 inches or so, but when I look
at the overshoot waveforms, they're quite acceptable up to 3.5 inches,
in terms of overshoot. with no terminators.  Sometimes, input ESD
clamp diodes can be your friend.  Xilinx as much as says this -- keep
the clamp current within specs for a tolerable amount of time and
latchup won't occur (see the app note or Peter Alfke's posts to the
same effect).  These are working on exactly the same principle as the
Cal Micro diode terminators -- except some manufacturers use Schottky,
some use silicon (schottky has a lower forward voltage, in general).

Another point worth mentioning -- how did you determine how much
overshoot you had?  Dr Johnson's book has a good opening chapter on
probing techniques and basically how your o-scope can fool you.  The
3-4" ground loop on your scope probe can make a 1ns rising edge look
like 5ns or so due to the self-inductance of the ground lead.
Overshoot can be miscalculated due to this.  Making accurate
measurements can be a pain.  The recommended technique is to remove
the cable and use an Exacto knife across the shield barrel of the
probe to the nearest ground pin -- while probing your signal.  Keep
this under a half inch if you can, at 100+ MHz this is really
important.  

Also, FWIW, the Xilinx databook as much as says how many simulataneous
switching loads you can have between power/ground pairs -- see Xilinx
app notes -- 200 pF/Fast 400pf/Slow on some families, 300/600 for
other families... then they touch on others.  Peter seems to have
written most of these....

Which brings up the last note I read on www.xilinx.com -- how about
clarifying what is meant in
http://www.xilinx.com/xcell/xl27/xl27_10b.pdf when the XC4000 series
is quoted witha lower impedance than the XC4000E series, even though
the IBIS models show the 4000E being faster.  Is this the CMOS/TTL
specification difference (4000 spec'd to TTL levels, 4000E spec'd to
CMOS levels?)



Article: 10068
Subject: Re: How low can they go?
From: Richard Schwarz <aps@associatedpro.com>
Date: Sat, 25 Apr 1998 06:55:32 -0400
Links: << >>  << T >>  << A >>
Stuart,

1 Ton of Scarp Metal and 300 pounds of plastic !=  Ford Escort !=
Mercedes Benz

350.00 worth of chemicals != Madalin Albright  != Cindy Crawford

It's the use & functionality.( with a little marketing thrown in) :-)



Stuart Clubb wrote:

> Hi all,
>
> There I was, flicking through one of the industry weekly's, when I
> stumbled across an advert for a Cypress 4Mbit RAM. Nothing remarkable
> in that, except I was taken by the "26 million transistors" blurb.
> This rang a bell, as I remember this big fuss about an XC40125XV
> having 25 Million transistors, and being so difficult to produce,
> needing 0.25 micron etc.
>
> Here's some interesting math then:
>
> XC40125XV-2BC560C : $1995.00 in 100 up. (www.marshall.com)
> CY7C1049-25VC : $30.60 in 100 up. (www.arrowsemi.com)
>
> So, in the limit, 25 million transistors = 125K FPGA gates.....
>
> We should see 25 cents per thousand gates as soon as the vendors can
> pile enough layers of metal on top of the transitors. Hell, then
> somebody had better figure out how to build a two tier substrate to
> get two transistors in the same area :-)
>
> Here's my new revised price list for the big two :
>
> Xilinx 40125XV : $30.60
> Altera 10K100 : $15.18
> Xilinx 4044XL : $10.77
> Altera 6016 : $1.47
> Xilinx 4005XL : $1.22
>
> I know that there are issues such as packaging, economies of scale,
> market "worth" etc, but comments are invited nevertheless.
>
> Stuart



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 10069
Subject: Re: Xilinx Serial Proms
From: z80@ds2.com (Peter)
Date: Sat, 25 Apr 1998 12:08:55 GMT
Links: << >>  << T >>  << A >>
As I think I have mentioned, it would not be hard to write a little
command-line program, C or even AWK, which edits the .mcs file as
required.

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 10070
Subject: PLD & FPGA Conference and Exhibition 12/5/98
From: johnnyick@aol.com (Johnnyick)
Date: 25 Apr 1998 14:42:39 GMT
Links: << >>  << T >>  << A >>
If you use or want to know more about the latest developments in PLD & FPGA
devices and related software then visit the eighth annual PLD & FPGA conference
and exhibition on 12th May at Royal Ascot Racecourse, Ascot, Berks. For more
details on the conference programme, exhibitor list, map and how to register
on-line please visit the website http://www.pldconf.com
Article: 10071
Subject: FPGA Eng: WANTED Excellent Opportunity
From: mdelaney@servtech.com (Mike DeLaney)
Date: Sat, 25 Apr 1998 13:15:19 -0400
Links: << >>  << T >>  << A >>

TITLE: FPGA Eng
   
REF #: FPGA-309-98                  **  Candidates MUST reside in the US  **

LOCATION: MA/VA/MD/IL/WI, other areas available too...call me to find out more

REQUIREMENTS:   Design/develop products for a leader in the mass storage
industry. Exp in SCSI & RISC microprocessors, board level design,
programmable logic design including FPGAs, PLDs, ASIC and analog design.
Hands-on system architecture, board and chip level hardware design
necessary.  3+ yrs exp.    
___________________________________________________________

Call:      Mike DeLaney:   
        800-248-7020  x260      
         Fax 716-248-3077
     National Engineering Search   
        http://www.nesnet.com    

    "Engineers placing Engineers"

Email (text resume) to: mdelaney@servtech.com
____________________________________________________________
See what your skills are worth...CALL for a FREE salary survey.
____________________________________________________________

National Engineering Search (http://www.nesnet.com) is a technical
recruiting firm, staffed with degreed engineers, dedicated exclusively to
placing Engineers nationwide.  If this position doesn't fit your
requirements, call me with your specific search criteria.
 
 NES can identify  SELECT  engineering opportunities based on your
background, interests, and geographic requirements.  

 What makes us better...We are Engineers placing Engineers, We are not a
generalist, We are very focused in a technical arena ONLY.   And we know it
better than anyone else.
Article: 10072
Subject: XILINX,LUCENT, ATMEL FPGA Test BOARDS
From: Richard Schwarz <aps@associatedpro.com>
Date: Sat, 25 Apr 1998 16:10:17 -0400
Links: << >>  << T >>  << A >>
APS has FPGA Test boards available for XILINX LUCENT and ATMEL FPGAs
with associated low cost software including VHDL, VERILOG, and Router
options. APS also sells several other engineering support tools. You can
see the tools at:

http://www.associatedpro.com

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 10073
Subject: Re: Why Altera & Cypress Software Clashes (was: VHDL compiler differences?)
From: Steve@s-deweynospam.demon.co.uk (Steve Dewey)
Date: Sat, 25 Apr 98 20:46:25 GMT
Links: << >>  << T >>  << A >>
In article <ErxMC3.6KA@world.std.com> jcooley@world.std.com "John Cooley" writes:

> Steve Dewey <Steve@s-deweynospam.demon.co.uk> wrote:
> >Why can't I take my Altera VHDL and run it on another _cheap_ vendor-specific 
> >VHDL tool, eg cypress warp ?
> >
> >Sorry if these are obvious and reveal a lack of insight on my part.
> 
> The quick answer is that Altera is primarily interested in getting you to
> buy and use Altera chips.  Cypress wants you to buy Cypress chips.  Neither
> company really cares about you if you're going to use someone else's
> FPGAs, hence the disincentive towards having their compilers being
> compatiable.  If you want universiality, go to vendors who are financially
> motivated to keep you universal: the EDA vendors.  (EDA stands for "Electronic
> Design Automation" and is just a fancy way of saying "the guys who make
> software used for chip design".)  For example, if you buy Synopsys, Exemplar,
> Synplicity, or any of the other software from an EDA vendor for FPGA
> synthesis, it will work with Altera, Xilinx, Cypress, etc. BECAUSE it's
> the EDA vendor's bread & butter to let their customers CHOOSE between
> competing FPGA vendors.
> 
> (Sorry if I appear to be explaining the obvious to you, but you said you were
> a newbie who didn't understand these issues.)
> 
>                            - John Cooley
> 
Err... Let me clarify: I have not attempted to port VHDL code developed 
in Altera's Maxplus to Cypress' Warp. I was asking whether it would be feasible 
or not. 

And that was just an aside to my main qusetion :

For a given piece of VHDL code, do the mega-bucks tools, e.g. Synopsys, 
Exemplar, Synplicity actually implement it using fewer chip resources
than the standard Altera tools ? I understand that the implementation of VHDL 
may be more complete, and the software able to target multiple vendors
(but only with the vendors back-end tools...).

For what it's worth, I'm quite happy with Maxplus. I think in large part 
this is because Altera know that if it's no good then they won't sell
any chips. Compare this with software vendors know that a bug means you have 
to buy the upgrade. See the threads on Orcad & Protel PCB layout software in
sci.electronics.cad for _lots_ more on this !

-- 
Steve Dewey
Steve@s-deweynospam.demon.co.uk
Too boring to have an interesting or witty .sig file.

Article: 10074
Subject: Re: Xilinx Timing Constraints
From: Rickman <spamgoeshere1@yahoo.com>
Date: Sat, 25 Apr 1998 17:55:18 -0400
Links: << >>  << T >>  << A >>
ems wrote:
> 
> On Sat, 18 Apr 1998 19:06:22 -0400, Rickman <spamgoeshere1@yahoo.com>
> wrote:
> 
> >I have a partial copy of class handouts labled "Timing & Constraints". I
> >have 24 pages, starting with slide 3 and runing to slide 59, missing
> >many slides here and there.
> 
> thanks - i got this from xilinx tech support. there are 64 pages,
> dated jan 98, containing some very useful stuff that i haven't seen
> anywhere else (and i've spent a lot of time looking!)
> 
> i've uploaded the whole presentation to:
> 
> http://www.riverside-machines.com/pub/timingcsts.htm
> 
> for anyone else who's interested.
> 
> evan (ems@nospam.riverside-machines.com)

-- 
Seems pretty silly that Xilinx (and I assume the other vendors too) make
it so difficult to learn about their products. I often shy away (and
thats quite an understatement) from using FPGAs in designs if there are
any conditions which even mildly push the envelope of what I have done
before. About five years ago I did a design in FPGAs which was pushing
on the speed and the density at the same time. Lets just say no one was
happy with the result. So now I limit the designs I do, to what I KNOW
can be done, because I have done it before. 

If they made their tools easier to learn by reading the books (I mean
the online documentation, I forgot that nobody ships books anymore) I
would have more confidence as well as time, to do new designs which are
bigger, faster and take advantage of the new capablities of the software
and hardware. But since they pump stuff out faster than they can
document it well, I will stay a generation or two behind in what I am
willing to sign up to do. 

BTW, thanks for posting the presentation. I downloaded it and printed it
out. It is better than what I had before. I highly recommend it to
anyone working with Xilinx FPGAs. 


Rick Collins

rickman@XYwriteme.com

remove the XY to email me.


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