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 18675

Article: 18675
Subject: Re: Comparison between Altera and Xilinx
From: kayrock@my-deja.com
Date: Sun, 07 Nov 1999 02:17:22 GMT
Links: << >>  << T >>  << A >>
In article <381de3c0.1684135@news.freeserve.net>,
  martin@the-thompsons.freeserve.co.uk wrote:
> On 1 Nov 1999 01:01:54 GMT, murray@pa.dec.com (Hal Murray) wrote:
>
> >
> >[snip bit-serial suggestions]
> >
> >> My point was that smaller/cheaper is not the issue for me at the
> >> moment, once smaller/cheaper becomes important, we'll be in ASIC
> >> territory anyway.
> >
> >Won't the same techniques help you get a smaller/cheaper ASIC?
> >

In general, if your design meets timing in programmable logic, you are
WAY ahead in ASIC technology.  This is one of the problems with taking a
 programmable logic design directly to ASIC.  Where on the FPGA you tend
to make highly pipelined architectures since there F/F's are there
anyway, in ASIC you can often get away with way less pipelining because
the interconnect delay is so fast (and availability of wide fan-in
cells).  A direct conversion would be overkill(larger) to build all
those F/Fs in the ASIC.

Josh

>
> Martin
>
> >--
> >These are my opinions, not necessarily my employers.
>
> Martin Thompson
> martin@the-thompsons.freeserve.co.uk
> http://www.the-thompsons.freeserve.co.uk/
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 18676
Subject: Re: Price of FPGA
From: kayrock@my-deja.com
Date: Sun, 07 Nov 1999 02:37:27 GMT
Links: << >>  << T >>  << A >>
In article <3822E2B1.2EFFCB82@yahoo.com>,
  Rickman <spamgoeshere4@yahoo.com> wrote:
> project wrote:
> >
> > Where can I find an address with FPGA prices? Or what is
> > aproximately the prize of an FPGA?
> > Thanks
> >
> > * Sent from AltaVista http://www.altavista.com Where you can also
find related Web Pages, Images, Audios, Videos, News, and Shopping.
Smart is Beautiful
>
> You can get pricing from several distributor's web sites, but it won't
> be very accurate. They then to list the highest prices they charge. I
> have found that FPGA prices are a bit like car prices. If you take the
> first price you are given, you paid too much. It is best to call and
get
> a quote based on your quantity, even if that quantity is small. As
long
> as you do some volume with that disti, they will discount FPGA prices.
>
I agree with you that the price is a bit like buying a car.  When
designing in parts for any volume production you want to avoid sole
source parts like the plague.  Prices tend to be effected more by
competition than by the cost it took to make the part in question.  A
good way to go if you have to use programable logic is design a dual
footprint PCB or select parts and layouts that permit you to populate 1
of 2 competing parts such as Altera 7K and Xilinx 9k.  You will find a
dramatic price difference in your quotes when it is evident that you
could go either way and can do so at any point in your production cycle.

And to answer the original question very roughly speaking small FPGA's
<$10 in qty and CPLDs<$5 in qty.

Josh


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18677
Subject: Re: Input metastability
From: murray@pa.dec.com (Hal Murray)
Date: 7 Nov 1999 04:27:47 GMT
Links: << >>  << T >>  << A >>

> If folks want to always use two synchronizing flip-flops in series,
> that's fine with me, because it's infinitely superior to doing
> nothing, and it works.  But if there's sufficient time for a single
> synchronizing flip-flop to settle (sufficient = acceptably high MTBF),
> a second rank isn't necessarily mandatory.

It isn't foolproof though.  The key idea is excess setup time.

You can build a system with 2 flip-flops that doesn't do much good
if you put them on opposite sides of the chip and burn up the whole
cycle of setup time with routing.

Similarly, if you have a heavily pipelined system and your clock rate
is high enough that you already have very restricted routing, your
MTBF may not be very high even with minimal routing.  Putting both
FFs in the same CLB helps a lot, but that sort of hint depends
upon the technology you are using.

Keep beating on the vendors.  Maybe they will get the message
one of these days.



-- 
These are my opinions, not necessarily my employers.
Article: 18678
Subject: Re: Why DSP in a FPGA?
From: murray@pa.dec.com (Hal Murray)
Date: 7 Nov 1999 04:35:12 GMT
Links: << >>  << T >>  << A >>

> There is much in the literature in that regard already.  Many try to include
> multipliers and such.  Problem is, as you get more complicated blocks, the
> harder it is to generalize to get the ideal block and the harder it is to fit
> your algorithm to the block.  If you take that to the extreme, you wind up with
> a DSP microprocessor.  When you have bigger blocks, you will have less of them
> for a given silicon area, and if they are function specific, then you run into a
> limited resource problem.

There is another problem with specialized/complicated blocks.  It
reduces the volume of the parts you want which raises the cost.

It also means they won't be as close to the leading edge of the
technology curve.  That also raises the cost.

-- 
These are my opinions, not necessarily my employers.
Article: 18679
Subject: I've gotta buncha FPGA chips, but.....
From: linda@jersey.net (Mike)
Date: Sun, 07 Nov 1999 06:06:28 GMT
Links: << >>  << T >>  << A >>
  I deal in hardware. I recently purchased a few lots of CPUs. Among
these lots were a quantity of FPGA chips. They were accompanied by an
RMA slip which gave as a reason for return: "fine pitch contacts off
line - do not line up with machine". I did NOT get these chips from
Xilinx, so I can only assume the RMA (which is dated 6/98) was never
implemented for some reason.
  Specifically, these are XC4020E-4HQ240C chips, and I have 48 of them
(2 trays). About a dozen chips in one of the trays have varying
degrees of bent pins ranging from mild to severe, but the rest appear
to be perfect.
  So here's my problem: I would like to sell them, but I'm not sure
where I should direct my efforts. Because these are SMD devices I
don't know whether I should even bother directing them towards
hobbyists. But because I only have 48 (and less due to damage), I
doubt that a manufacturer would get real excited over them.
  Any tips or opinions are welcome. Thank you.

	Mike


Article: 18680
Subject: FPGA's interface ....
From: u8713501@cc.nctu.edu.tw (Child K.L. Sun)
Date: Sun, 07 Nov 1999 12:25:27 GMT
Links: << >>  << T >>  << A >>
Dear Guys,

	I am dealing with hardware interfacing between
a FPGA (maybe from Xilinx) and a DAC (digiatal to analog
converter). The DAC, I can found, can be of ECL or TTL.
Does FPGA support these two interfacing voltage levels?

Thanks.

Child
Article: 18681
Subject: ROM or SRAM !?
From: u8713501@cc.nctu.edu.tw (Child K.L. Sun)
Date: Sun, 07 Nov 1999 12:29:36 GMT
Links: << >>  << T >>  << A >>
Dear Guys,

	I know that some FPGAs are of ROM architecture while
some of them are of SRAM. If I would like a speed of 155Mbps,
is there any ROM type FPGA available in the market?

Thanks.

Child
Article: 18682
Subject: Re: Why DSP in a FPGA?
From: rk <stellare@NOSPAM.erols.com>
Date: Sun, 07 Nov 1999 07:41:51 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> > There is much in the literature in that regard already.  Many try to include
> > multipliers and such.  Problem is, as you get more complicated blocks, the
> > harder it is to generalize to get the ideal block and the harder it is to fit
> > your algorithm to the block.  If you take that to the extreme, you wind up with
> > a DSP microprocessor.  When you have bigger blocks, you will have less of them
> > for a given silicon area, and if they are function specific, then you run into a
> > limited resource problem.
>
> There is another problem with specialized/complicated blocks.  It
> reduces the volume of the parts you want which raises the cost.
>
> It also means they won't be as close to the leading edge of the
> technology curve.  That also raises the cost.

it perhaps is an interesting race to see if a "simple and regular" architecture moving
with short development times and staying on the edge of process technology beats in
performance the more "complex with specialized features" architecture with longer
design times and slower to take advantage of new processes.  this was interesting to
watch in the cpu world.

it also makes it harder for the software support - getting the vhdl synthesizers to
deal with it - and there's the push to get things moved into vhdl (or verilog or now
the push is to c/c++, etc.).

rk

Article: 18683
Subject: Re: Input metastability
From: rk <stellare@NOSPAM.erols.com>
Date: Sun, 07 Nov 1999 07:45:06 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> > If folks want to always use two synchronizing flip-flops in series,
> > that's fine with me, because it's infinitely superior to doing
> > nothing, and it works.  But if there's sufficient time for a single
> > synchronizing flip-flop to settle (sufficient = acceptably high MTBF),
> > a second rank isn't necessarily mandatory.
>
> It isn't foolproof though.  The key idea is excess setup time.
>
> You can build a system with 2 flip-flops that doesn't do much good
> if you put them on opposite sides of the chip and burn up the whole
> cycle of setup time with routing.
>
> Similarly, if you have a heavily pipelined system and your clock rate
> is high enough that you already have very restricted routing, your
> MTBF may not be very high even with minimal routing.  Putting both
> FFs in the same CLB helps a lot, but that sort of hint depends
> upon the technology you are using.
>
> Keep beating on the vendors.  Maybe they will get the message
> one of these days.

some vendors are very good at publishing numbers (which should be either
worst-case or guaranteed over different operating conditions in a table).
others produce nothing, even for those devices targeted at high-reliability
and/or military applications.

another beating done.

who's next?

:-)

rk


Article: 18684
Subject: Re: ROM or SRAM !?
From: Ray Andraka <randraka@ids.net>
Date: Sun, 07 Nov 1999 12:08:35 -0500
Links: << >>  << T >>  << A >>
There are non-volatile RAMs on the market which can handle clock rates
of 155Mbps.  However, I can't think of any that have carry chains so if
your design requires arithmetic or fast counters you will have to resort
to other (larger) structures for fast carry generation.  The bottom line
is that the suitability of a particular device depends on the
application.  Look at Actel and Quicklogic.

Child K.L. Sun wrote:

> Dear Guys,
>
>         I know that some FPGAs are of ROM architecture while
> some of them are of SRAM. If I would like a speed of 155Mbps,
> is there any ROM type FPGA available in the market?
>
> Thanks.
>
> Child



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18685
Subject: Re: ROM or SRAM !?
From: rk <stellare@NOSPAM.erols.com>
Date: Sun, 07 Nov 1999 14:01:58 -0500
Links: << >>  << T >>  << A >>
just to add on a bit ...

for the actelians, look at the new sx-a (0.25um) 2.5V devices they recently
announced.  i haven't had a chance to look at them yet with some sample
designs (need software update) although some prototype devices were quite
fast.  what sort of logic do you need to run at 155 Mbps?  for q-logic, i
haven't seen anything below their 0.35 um, 3.3V process, although for
high-speed stuff they've been putting hardwired functions on chip, taking a
different path (i.e., memories, pci controllers).

lastly, perhaps a nit (and i'm struggling to come up with good defintions
for these terms, perhaps a later post), the classification of storage
technologies can be divided up a bit more.  for non-volatile, i would also
include flash technologies (such as gatefield) and sonos cell (developed by
westinghouse aka northrop-grumman) which was being used in the mission
research corp. fpga).  i would also classify these two technologies into the
re-programmable class, from which most actel and all q-logic products would
be excluded.

so, for the original poster, is there a requirement for otp or just
non-volatility?

rk

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

Ray Andraka wrote:

> There are non-volatile RAMs on the market which can handle clock rates
> of 155Mbps.  However, I can't think of any that have carry chains so if
> your design requires arithmetic or fast counters you will have to resort
> to other (larger) structures for fast carry generation.  The bottom line
> is that the suitability of a particular device depends on the
> application.  Look at Actel and Quicklogic.
>
> Child K.L. Sun wrote:
>
> > Dear Guys,
> >
> >         I know that some FPGAs are of ROM architecture while
> > some of them are of SRAM. If I would like a speed of 155Mbps,
> > is there any ROM type FPGA available in the market?
> >
> > Thanks.
> >
> > Child



Article: 18686
Subject: Re: Input metastability
From: bob@nospam.thanks (Bob Perlman)
Date: Sun, 07 Nov 1999 19:02:04 GMT
Links: << >>  << T >>  << A >>
On 7 Nov 1999 04:27:47 GMT, murray@pa.dec.com (Hal Murray) wrote:

>
>> If folks want to always use two synchronizing flip-flops in series,
>> that's fine with me, because it's infinitely superior to doing
>> nothing, and it works.  But if there's sufficient time for a single
>> synchronizing flip-flop to settle (sufficient = acceptably high MTBF),
>> a second rank isn't necessarily mandatory.
>
>It isn't foolproof though.  The key idea is excess setup time.
>
>You can build a system with 2 flip-flops that doesn't do much good
>if you put them on opposite sides of the chip and burn up the whole
>cycle of setup time with routing.
>
>Similarly, if you have a heavily pipelined system and your clock rate
>is high enough that you already have very restricted routing, your
>MTBF may not be very high even with minimal routing.  Putting both
>FFs in the same CLB helps a lot, but that sort of hint depends
>upon the technology you are using.

I think we're going in circles here.  The purpose of my post was to
amplify a point Rick Collins made, namely that excess setup time, and
not necessarily the number of synchronizer stages, is the central
issue.  The first problem you mention, that of squandering the excess
setup time in routing, can be addressed through placement, or by
defining an additional timespec for each synchronizer rank that
minimizes the delay between that FF and any FF it drives (me, I add
the timespec).  The second situation may require more synchronizer
stages.

In short, when I design synchronizers, I:

 1) choose the number of synchronizer stages that best match the clock
speed and the latency requirements.

 2) maximize the amount of settling time at each synchronizer stage
through the addition of a tight timespec for that stage.

 3) calculate the resultant MTBF.  I go for 1 million years minimum; a
convincing argument can be made for higher targets, and I wouldn't
argue against it.

4) Iterate on (1) - (3) until I get an MTBF I can live with.

This is all fairly straightforward stuff that (I hope) people have
been doing for years.  Here are a couple of less obvious problems:

1) inadvertent flip-flop duplication.  It's been mentioned in this
newsgroup that either the synthesis tool or the place/route tool can
inadvertently duplicate synchronizer flip-flops.  The solution is
vendor-dependent, but the bottom line is that synchronizing a signal
in two flip-flops wired in parallel can be a disaster, and must be
avoided.

2) anomalous FIFO full/empty flag behavior.  Lots of folks, myself
included, use FIFOs to transfer data between two mutually-asynchronous
clock domains.  The full and empty flags of the FIFO are sometimes
used to control write and read state machines on either side of the
FIFO.  These flags are a function of both the write clock and the read
clock; to be useful, the full flag must be synchronized to the write
clock and the empty flag to the read clock.  At the risk of making the
biggest understatement in the thread so far, THIS IS TRICKY.  What's
more, you usually can't solve the problem merely by putting the flag
through additional synchronization external to the FIFO.  (Question:
What happens if you put the full flag through a couple of stages of
synchronization before presenting it to the FSM that controls FIFO
writes?  When the FIFO goes full, how long does it take for the FSM to
stop writing?  Answer: Uh-oh.)  Some designers avoid the problem by
ensuring that a given FIFO never goes empty or full, but this isn't
always possible.

Designers of FIFO ICs have been grappling with these flag problems for
ages; the person who designed your TI or IDT or Cypress FIFO may have
been designing FIFOs for 10 years.  Whereas the person who designed
your FIFO macrocell or FIFO IP may have been designing FIFOs since,
say, last Tuesday.  It behooves the FPGA designer to check the design
of any FIFO he or she uses, particularly if the FIFO's full or empty
flags are being used.

If you want to get an idea of just how involved proper FIFO flag
design can be, take a look at Peter Alfke's app notes on the Xilinx
website, or at some writeups done by John Birkner and his colleagues
on the Quicklogic website.

Take care,
Bob Perlman


-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 18687
Subject: Re: looking for XNF Grammar
From: anup kumar raghavan <anup@elec.uq.edu.au>
Date: Mon, 08 Nov 1999 08:31:09 +1000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------C309E856364F06028EA638F2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

U can check out this site

ftp://ftp.xilinx.com/pub/documentation/xactstep6/xnfspec.pdf

Cheers

Anup

YUN SONG HYUN wrote:

> Hi there!
>
> I am about to make XNF Reader.
>
> If you have XNF grammar, could you email me?
>
> -- Yun song hyun --

--------------C309E856364F06028EA638F2
Content-Type: text/x-vcard; charset=us-ascii;
 name="anup.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for anup kumar raghavan
Content-Disposition: attachment;
 filename="anup.vcf"

begin:vcard 
n:Anup Kumar;Raghavan
tel;home:0061-7-38761962
tel;work:0061-7-33658849
x-mozilla-html:FALSE
url:www.csee.uq.edu.au
org:University of Queensland;Computer Science and Electrical Engineering
adr:;;;;;;Australia
version:2.1
email;internet:anup@elec.uq.edu.au
fn:Anup Kumar
end:vcard

--------------C309E856364F06028EA638F2--

Article: 18688
Subject: Re: Input metastability
From: Ray Andraka <randraka@ids.net>
Date: Sun, 07 Nov 1999 18:58:05 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> This is all fairly straightforward stuff that (I hope) people have
> been doing for years.  Here are a couple of less obvious problems:
>
> 1) inadvertent flip-flop duplication.  It's been mentioned in this
> newsgroup that either the synthesis tool or the place/route tool can
> inadvertently duplicate synchronizer flip-flops.  The solution is
> vendor-dependent, but the bottom line is that synchronizing a signal
> in two flip-flops wired in parallel can be a disaster, and must be
> avoided.
>

Easiest way to avoid it in synthesis it to instantiate the primitives
directly.  You can also RLOC the flipflops to the same CLB easily that way.

> 2) anomalous FIFO full/empty flag behavior.  Lots of folks, myself
> included, use FIFOs to transfer data between two mutually-asynchronous
> clock domains.  The full and empty flags of the FIFO are sometimes
> used to control write and read state machines on either side of the
> FIFO.  These flags are a function of both the write clock and the read
> clock; to be useful, the full flag must be synchronized to the write
> clock and the empty flag to the read clock.  At the risk of making the
> biggest understatement in the thread so far, THIS IS TRICKY.  What's
> more, you usually can't solve the problem merely by putting the flag
> through additional synchronization external to the FIFO.  (Question:
> What happens if you put the full flag through a couple of stages of
> synchronization before presenting it to the FSM that controls FIFO
> writes?  When the FIFO goes full, how long does it take for the FSM to
> stop writing?  Answer: Uh-oh.)  Some designers avoid the problem by
> ensuring that a given FIFO never goes empty or full, but this isn't
> always possible.
>
> Designers of FIFO ICs have been grappling with these flag problems for
> ages; the person who designed your TI or IDT or Cypress FIFO may have
> been designing FIFOs for 10 years.  Whereas the person who designed
> your FIFO macrocell or FIFO IP may have been designing FIFOs since,
> say, last Tuesday.  It behooves the FPGA designer to check the design
> of any FIFO he or she uses, particularly if the FIFO's full or empty
> flags are being used.
>
> If you want to get an idea of just how involved proper FIFO flag
> design can be, take a look at Peter Alfke's app notes on the Xilinx
> website, or at some writeups done by John Birkner and his colleagues
> on the Quicklogic website.

Couldn't agree more.  Be careful of the macros out there too, they are far
from perfect.


> Take care,
> Bob Perlman
>
> -----------------------------------------------------
> Bob Perlman
> Cambrian Design Works
> Digital Design, Signal Integrity
> http://www.best.com/~bobperl/cdw.htm
> Send e-mail replies to best<dot>com, username bobperl
> -----------------------------------------------------



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18689
Subject: Downloading Xilinx FPGA with just .bit file???
From: "Austin Franklin" <austin@darkroo8m.com>
Date: 8 Nov 1999 03:07:15 GMT
Links: << >>  << T >>  << A >>
It appears that the new Xilinx tools don't allow me to just download a bit
file.  XChecker is apparently not shipped with the new tools, and the
hardware debugger requires me to have the 'project' there....

What gives?

Article: 18690
Subject: Re: Downloading Xilinx FPGA with just .bit file???
From: Ray Andraka <randraka@ids.net>
Date: Sun, 07 Nov 1999 23:51:43 -0500
Links: << >>  << T >>  << A >>
All the debugger needs in the 'project' is the bit file, and if you are
planning on doing readbacks the .ll file.  For just downloading, the bit file
can be the .bit or a rom file in any of the formats (.exo, .mcs etc.).   For
readback, you must use the .bit file.

Austin Franklin wrote:

> It appears that the new Xilinx tools don't allow me to just download a bit
> file.  XChecker is apparently not shipped with the new tools, and the
> hardware debugger requires me to have the 'project' there....
>
> What gives?



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18691
Subject: Re: ROM or SRAM !?
From: u8713501@cc.nctu.edu.tw (Child K.L. Sun)
Date: Mon, 08 Nov 1999 06:31:23 GMT
Links: << >>  << T >>  << A >>

>so, for the original poster, is there a requirement for otp or just
>non-volatility?

	I am using FPGA for the lab purpose to implement some selectable
demux and encoding. 

>                     +-------+ (2) +-------+ (10)                           
>                  o--|1:2 S/P|=====|Encoder|======o                         
>                /    +-------+     +-------+        \\                      
>              /      +-------+ (3) +-------+ (10)     \\                    
>155Mbps------o    o--|1:3 S/P|=====|Encoder|======o     o=== Parallel Output
>                     +-------+     +-------+                                
>                     +-------+ (4) +-------+ (10)                           
>                  o--|1:2 S/P|=====|Encoder|======o                         
>                     +-------+     +-------+                                
>               ^                                     ^                      
>               |                                     |                      
>               |                                     |                      
>            Selector                              Selector               

So, the highest speed "seen" by the encoding circuitry should be only 155Mbps/2.
For the convenience of experiment, I would prefer ROM rather RAM type FPGA.
Is there any?

Thanks.
Child

Article: 18692
Subject: LATTICE SEMICONDUCTOR INTRODUCES THE PLD OF ANALOG CHIPS
From: "Number Cruncher" <michel.heuts@pandora.be>
Date: Mon, 8 Nov 1999 10:46:46 +0100
Links: << >>  << T >>  << A >>
LATTICE SEMICONDUCTOR INTRODUCES THE PLD OF ANALOG CHIPS

Truly Programmable Analog Products Bring Easy, Fast & Flexible Design to
Analog Designers
HILLSBORO, OR - NOVEMBER 8, 1999 -Lattice Semiconductor (NASDAQ: LSCC) today
announced its entrance into the Programmable Analog market with its new
family of Programmable Analog Circuit monolithic ICs, the ispPAC(tm) family.
The first two devices in the family available today are the ispPAC10 and
ispPAC20. Dubbed by Lattice as the "PLD of Analog Chips," the ispPAC family
brings the easy, fast, and flexible design benefits associated with
Programmable Logic to the world of Analog design for the first time.

The ispPAC products integrate up to 60 active and passive analog components
with hundreds of values onto a single chip. An engineer uses PC-based
point-and-click software to set the characteristics of the analog components
needed and to hook them together. The chip is programmed when the resulting
design is downloaded into the chip's E2 configuration memory, and can be
instantly reprogrammed when the user makes design changes.

"The PLD sprang onto the scene 20 years ago and engineers creating digital
logic seized on the PLD's great step forward in ease-of-design and
time-to-market, growing a $2.3B market in the process," said Cyrus Tsui,
Lattice's CEO. "Pioneering in PLDs was gratifying because it changed the
world of digital design. I've wanted to bring the same benefits to analog
designers for 10 years and am very pleased that our breakthrough engineering
work allows us to do that today."

Systems interface with the real world, and that creates a need to handle
analog signals representing temperature, voltage, current, pressure, etc.
Engineers typically design the desired analog circuits on paper or at a
computer, then build a prototype board to prove it out. But it is very
laborious and time-consuming to make the prototype work due to the
variability of the multiple analog components used, combined with the
extreme sensitivity analog circuits generally have to layout. Analog
components exhibit slightly different characteristics from manufacturing lot
to lot and from supplier to supplier, so once completed, the prototype board
may be further delayed as it is modified to achieve manufacturability.

The Initial ispPAC Products
The first member of the PAC(tm) family is the ispPAC10. It includes four
filter-summation PACblocks connected by an Analog Routing Pool. These can be
configured to do summation and integration, and have programmable gain up to
±20x, delivering a large gain range of 0-160,000 in millions of steps. The
PAC(tm) blocks also provide push-button, high precision, continuous time,
second-, third-, and fourth-order low-pass filtering over a range of
10KHz-100kHz, with fine resolution selectable from thousands of useful
combinations.

The ispPAC20 has two PAC blocks similar to the ispPAC10's, and adds an 8-bit
D-to-A converter and two differential comparators.

The initial ispPAC devices both perform with high linearity (88dB THD @
10kHz) over a large dynamic range (>100dB), through fully differential
inputs and outputs, all using a single +5V power supply at industrial
temperatures. And since the ispPAC family incorporates Lattice-innovated
ISP(tm) (In-System Programmability), ispPAC products can be programmed and
reprogrammed right on the circuit board, even after being soldered in place.
ISP makes design changes remarkably fast and easy.

The PAC-Designer software tool is an integrated analog design environment
with an easy-to-use GUI. It quickly enables the user to obtain
"what-you-see-is-what-you-get" design results. PAC-Designer software is
available for Windows 95, Windows 98, and Windows NT.

Applications
The ispPAC family will be used in a diverse field of applications, just as
are discrete and low-integration analog components. Some general usage
themes will find ispPAC products near DSP functions preparing the analog
signal for digitization, next to the 30 percent of microcontrollers
estimated to be used in conjunction with analog signals, in front of the
volume of 12-bit A-to-D converters consumed today, and next to
Lattice/Vantis ispPLDs used in myriad applications, which include analog
circuitry.

Applications are expected to include a host of industrial sensing, test, and
measurement designs as well as communication and computation systems.

What You See Is What You Get
Using the ispPAC Family's PAC-Designer(r) software at a PC, an engineer
selects the right analog components, their characteristics, and their
interconnections on-screen. A simulator shows the resulting signals
immediately. Since the analog components, their characteristics, and their
interconnect are all on-chip, the designer can now enjoy the incomparable
"What You See Is What You Get" benefit of the ispPAC Family - the programmed
chip delivers precisely the signal shown by the simulator. And each ispPAC
device delivers the same high-precision results repeatably, so board
manufacturability follows quickly and easily.

Powerful Macros
Continuous-time Biquad and Ladder Filters are very complex functions that
have been burdensome and involved for analog designers. Now they are
included as user-friendly macros in the PAC-Designer software's library.
Although board-level designers have enjoyed filter-synthesis software for
years, the frame-breaking difference we provide is that after completing the
design on the computer screen, the user downloads the design into the ispPAC
device and the job is instantly complete, with unprecedented precision. This
ease-of-design has never before existed for analog circuitry. The Lattice
programmable continuous-time technology that makes it possible is truly a
major engineering advance.

Reduced Cost of Ownership
The integration of dozens of analog components in a single ispPAC product
yields higher quality and reliability; lower purchasing, inventory, and
assembly costs; and a board space savings.

Further, each board can be calibrated while in use at the system level,
exploiting the built-in autocalibration capability. This robust approach
eliminates the need for costly trimming steps and components in the
manufacturing process.

Availability
The ispPAC10 and ispPAC20 products and the PAC-Designer software are all
available now. Pricing for the ispPAC10 or the ispPAC20 is under $7 in
thousands. The PAC-Designer software can be downloaded from
www.latticesemi.com and is complimentary during an introductory period.
PACsystem10 and PACsystem20 Evaluation Kits can be ordered on the website
for $149. The Kits include software, samples, download cables, evaluation
boards, technical documentation, and application notes. The PACsystems are
also available through our extensive distribution channels at a suggested
retail price of $149.

About Lattice Semiconductor and Vantis

Oregon-based Lattice Semiconductor Corporation designs, develops and markets
the broadest range of high-performance ISP programmable logic devices (PLDs)
and offers total solutions for today's advanced logic designs. Lattice
introduced in-system programmability to the logic industry in 1992. In June
1999, Lattice acquired Vantis, the corporation that invented the PAL(r)
device and PLD switch matrix architecture, from AMD. With nearly double the
R&D and sales resources, the resulting integrated company will focus on
delivering logic products that satisfy the performance, density and
ease-of-use requirements of its customers.

Lattice/Vantis products are sold worldwide through an extensive network of
independent sales representatives and distributors, primarily to OEM
customers in the fields of communications, computing, computer peripherals,
instrumentation, industrial controls and military systems. Company
headquarters are located at 5555 NE Moore Court, Hillsboro, Oregon 97124
USA; Telephone 503-268-8000; FAX 503-268-8037. For more information on
Lattice Semiconductor or Vantis Corporation, access our World Wide Web site
at http://www.latticesemi.com.

Statements in this news release looking forward in time are made pursuant to
the safe harbor provisions of the Private Securities Litigation Reform Act
of 1995. Investors are cautioned that forward-looking statements involve
risks and uncertainties, including the effect of changing economic
conditions, the effect of overall semiconductor market conditions, product
demand and market acceptance risks, risks associated with dependencies on
silicon wafer suppliers, the impact of competitive products and pricing,
technological and product development risks and other risk factors detailed
in the Company's Securities and Exchange Commission filings. Actual results
may differ materially from forward-looking statements.



# # #


Article: 18693
Subject: Re: Analog FPGA ?!
From: "Number Cruncher" <michel.heuts@pandora.be>
Date: Mon, 8 Nov 1999 10:58:50 +0100
Links: << >>  << T >>  << A >>

Hello Alexander,

                            I would suggest that you consider once the
recently announced and introduced ispPAC10
and ispPAC20 family parts from Lattice Semiconductor corp.
Free CAD sw is also downloadable and designkits are available at 149 US $.
I believe LSC has well studied its competitors (Zetex) and learned from
another (Mot....a) analog crash.

www.latticesemi.com

I hope this helps ...

regards,

Michel
WMU - Belgium

Alexander Sherstuk <sherstuk@amsd.com> wrote in message
news:7vt13m$8su$1@bull.east.ru...
> Hi All,
>
>    Has anybody experience with TRAC020 chip from
> http://www.fas.co.uk/silicon.htm?
> Their data sheet does not mention possibility of any programming for
> resistors
> and capacitors in the matrix. Is that just specification omission?
>
> Thanks,
>    Alex Sherstuk
>
>
>


Article: 18694
Subject: Re: ROM or SRAM !?
From: rk <stellare@NOSPAM.erols.com>
Date: Mon, 08 Nov 1999 07:07:13 -0500
Links: << >>  << T >>  << A >>
Child K.L. Sun wrote:

> >so, for the original poster, is there a requirement for otp or just
> >non-volatility?
>
>         I am using FPGA for the lab purpose to implement some selectable
> demux and encoding.
>
> >                     +-------+ (2) +-------+ (10)
> >                  o--|1:2 S/P|=====|Encoder|======o
> >                /    +-------+     +-------+        \\
> >              /      +-------+ (3) +-------+ (10)     \\
> >155Mbps------o    o--|1:3 S/P|=====|Encoder|======o     o=== Parallel Output
> >                     +-------+     +-------+
> >                     +-------+ (4) +-------+ (10)
> >                  o--|1:2 S/P|=====|Encoder|======o
> >                     +-------+     +-------+
> >               ^                                     ^
> >               |                                     |
> >               |                                     |
> >            Selector                              Selector
>
> So, the highest speed "seen" by the encoding circuitry should be only 155Mbps/2.
> For the convenience of experiment, I would prefer ROM rather RAM type FPGA.
> Is there any?

the s/p blocks should be easy but the logic equations would need to be known as
speed of these things is design depenedent.  another parameter that may be needed is
the amount of pipelining that the system can take, assuming that the encoding
couldn't be done in a single cycle.  i doesn't sound unreasonable.

perhaps you can call in the local fae's and have them run your design for you, since
there's not enough info here.

rk

Article: 18695
Subject: R: StateCAD versus Viewdraw
From: Mark Harvey <mark.harvey@farsystems.it>
Date: Mon, 8 Nov 1999 14:34:08 +0100
Links: << >>  << T >>  << A >>
	>I did once evaluate StateCAD for a month.  The tool seemed
	>well-written and the support was very good, but at the end of the
	>month I was left with the question, "Why am I doing this?"  There
may
	>be a good answer, but it wasn't apparent to me.  Despite being a
	>schematic diehard, I'm pretty happy with Synplicity, but see no
need
	>to pile other stuff on top of it.  As I once told a vendor, I'm not
	>sure I can survive another productivity improvement.

	>Take care,
	>Bob Perlman


	Couldn't agree more. We got StateCad as part of our Synario toolkit
and had great fun playing with it at the start. But we never could get it to
produce the VHDL code exactly as we wanted it - and then the resulting code
has to be somehow inserted into a higher level VHDL design entity - in the
end we went back to writing the state machines by hand.

	Mark Harvey


 Sent via Deja.com http://www.deja.com/
 Before you buy.
Article: 18696
Subject: Re: ROM or SRAM !?
From: Ray Andraka <randraka@ids.net>
Date: Mon, 08 Nov 1999 08:39:58 -0500
Links: << >>  << T >>  << A >>
Rich,

I'm pretty sure the current crop of xilinx and altera parts could handle this data rate
with minimal pipelining. I've done an FIR filter in xilinx with 16 bit wide parallel
arithmetic that runs at around 150 MHz in a Virtex -4 (slowest speed grade).  I've also
done 16 bit arithmetic designs in 4000XLA-07's that run in the high 140 MHz range.  His
input is 155Mb/s and it is paralleled down to a maximum data rate of 78 MHz.  The
encoder output is 10 bits, so a reasonable guess is any arithmetic inside is likely to
be less than 10 bits. The maximum width into the encoder is 4 bits, so if it is
combinatorial, the logic is one LUT deep in both Altera and Xilinx.  Obviously, not
knowing the details of the encoder blocks, we can't really tell how complicated they
are, but based on the observations of the input and output widths a first guess
indicates that it is possible.

I haven't looked at the Actel selection lately, so I don't know what kinds of speed you
can expect there.  I do know there is no carry chain, so you have to be careful in the
selection of the logic used in artihmetic.

A possibility might be to use a CPLD for this.  Most of the CPLDs are non-volatile, and
many support in system reprogrammability.  If the system is as simple as represented
here, I see no reason it wouldn't fit into one of the many CPLDs out there.  Again, the
data rates are within the realm of possibility for the currently available devices with
careful design.

rk wrote:

> Child K.L. Sun wrote:
>
> > >so, for the original poster, is there a requirement for otp or just
> > >non-volatility?
> >
> >         I am using FPGA for the lab purpose to implement some selectable
> > demux and encoding.
> >
> > >                     +-------+ (2) +-------+ (10)
> > >                  o--|1:2 S/P|=====|Encoder|======o
> > >                /    +-------+     +-------+        \\
> > >              /      +-------+ (3) +-------+ (10)     \\
> > >155Mbps------o    o--|1:3 S/P|=====|Encoder|======o     o=== Parallel Output
> > >                     +-------+     +-------+
> > >                     +-------+ (4) +-------+ (10)
> > >                  o--|1:2 S/P|=====|Encoder|======o
> > >                     +-------+     +-------+
> > >               ^                                     ^
> > >               |                                     |
> > >               |                                     |
> > >            Selector                              Selector
> >
> > So, the highest speed "seen" by the encoding circuitry should be only 155Mbps/2.
> > For the convenience of experiment, I would prefer ROM rather RAM type FPGA.
> > Is there any?
>
> the s/p blocks should be easy but the logic equations would need to be known as
> speed of these things is design depenedent.  another parameter that may be needed is
> the amount of pipelining that the system can take, assuming that the encoding
> couldn't be done in a single cycle.  i doesn't sound unreasonable.
>
> perhaps you can call in the local fae's and have them run your design for you, since
> there's not enough info here.
>
> rk



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18697
Subject: Re: Downloading Xilinx FPGA with just .bit file???
From: "Austin Franklin" <austin@darkroo8m.com>
Date: 8 Nov 1999 14:50:34 GMT
Links: << >>  << T >>  << A >>
Ray, thanks.

So now I have to go setup every guy in the lab and the production floor,
who used to be able to just use a little 486 notebook w/ a 20M disk and
DOS, with some version of Windoze, a mouse, and a project
directory...instead of just XChecker and a .bit file on a floppy...  To me,
this seems silly to have made it 'so' complicated when it used to be so
easy.

Also, is there a way of doing it from the command line, as opposed to
having to bring up the GIU, select 'stuff' etc.?

Austin

Ray Andraka <randraka@ids.net> wrote in article
<382656DF.78722B5F@ids.net>...
> All the debugger needs in the 'project' is the bit file, and if you are
> planning on doing readbacks the .ll file.  For just downloading, the bit
file
> can be the .bit or a rom file in any of the formats (.exo, .mcs etc.).  
For
> readback, you must use the .bit file.
> 
> Austin Franklin wrote:
> 
> > It appears that the new Xilinx tools don't allow me to just download a
bit
> > file.  XChecker is apparently not shipped with the new tools, and the
> > hardware debugger requires me to have the 'project' there....
> >
> > What gives?
> 
> 
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
> 
> 
> 
Article: 18698
Subject: OrcaLut from VHDL?
From: husby@fnal.gov (Don Husby)
Date: Mon, 08 Nov 1999 16:52:49 GMT
Links: << >>  << T >>  << A >>
Has anyone had any luck mapping functions to LUTs in an
Orca3C chip?  Leonardo seems to have access to an internal
library component called ORCALUT4 which does this, but I can't
figure out how to get explicit access to it from VHDL.

Here's the code I'm trying to map into a single PFU.
I think each line could be mapped into its own 4LUT or 5LUT,
and all three luts can be put in the same half of a PFU. 

....
  MH <= (D(15) and D(14) and D(13) and D(12)) or not (D(15) or D(14) or D(13) or D(12));
  ML <= (D(11) and D(10) and D(9) and D(8)) or not (D(11) or D(10) or D(9) or D(8));
  M  <= ( (D(12) and D(11)) or not (D(12) or D(11)) ) and MH and (W or ML);
....

Here's how I tried to use the OrcaLut components:
....
  attribute lut_function of Lut0 : label is "(A*B*C*D+!(A+B+C+D))";
  attribute lut_function of Lut1 : label is "(A*B*C*D+!(A+B+C+D))";
  attribute lut_function of Lut2 : label is "((A*D+!(A+D))*B*(C+E))";
begin
  Lut0: orcalut4 port map (D(15), D(14), D(13), D(12), MH);
  Lut1: orcalut4 port map (D(11), D(10), D(9), D(8), ML);
  Lut2: orcalut5 port map (D(11), MH, ML, D(12), W);
....


--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 18699
Subject: Re: Input metastability
From: murray@pa.dec.com (Hal Murray)
Date: 8 Nov 1999 18:40:10 GMT
Links: << >>  << T >>  << A >>

[Lots of trimming.] 

> >> If folks want to always use two synchronizing flip-flops in series,
> >> that's fine with me, because it's infinitely superior to doing
> >> nothing, and it works.

> I think we're going in circles here.  The purpose of my post was to
> amplify a point Rick Collins made, namely that excess setup time, and
> not necessarily the number of synchronizer stages, is the central
> issue.

I should have been clearer.  What I was focusing on was the "it works"
part.  The two FFs rule works so well that it is almost good enough.
But if you don't understand what is going on, it is possible to
follow that rule and build a buggy system.

One easy way to botch things is by burning all the excess setup time by
routing a signal across the chip.


>  3) calculate the resultant MTBF.  I go for 1 million years minimum; a
> convincing argument can be made for higher targets, and I wouldn't
> argue against it.

Where do you get the data to compute the MTBF?  Are you using worst
case numbers?  The only numbers I've seen published are typicals.

Where do you get data for new chips?  The only data I've seen is
generally an app-note that doesn't get published until the chip has
been out for a while.


I like your checklist.  Now all we have to do is convince the manufacturers
to support it.



> Designers of FIFO ICs have been grappling with these flag problems for
> ages; the person who designed your TI or IDT or Cypress FIFO may have
> been designing FIFOs for 10 years.  Whereas the person who designed

Thanks for the reminder about FIFO flags.

Speaking of metastability data, I don't remember ever seeing any from FIFO
manufacturers.

Note that the section of the FIFO data sheet that says that writes are a
no-op if the FIFO is full and reads when empty doesn't mention metastability.
(That's not a problem if both sides use the same clock and you have enough
setup/hold time.)  Anybody want to take a guess at what happens to the internal
state of a FIFO if you are unlucky?

-- 
These are my opinions, not necessarily my employers.


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