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 47375

Article: 47375
Subject: Re: Fast serial interconnect bus using spartan-II
From: "TC" <noone@noplace.com>
Date: Tue, 24 Sep 2002 19:36:09 -0400
Links: << >>  << T >>  << A >>
What do you mean by "bus like"? Are you in fact connecting independent IO
buses together? And if so, is there a specific bus that you are using (for
example PCI)?

What are the functional requirements? Does it need to recover from errors?
Is it a data only interface? Is there some form of flow control? What is the
size of the payload (fixed, variable, etc.)?

Are the modules in a common system with a single power supply and ground?
Or, is the connection between cabinets with different power systems?

More details on the problem would enable more specific/helpful responses.

TC


"Markus Meng" <meng.engineering@bluewin.ch> wrote in message
news:aaaee51b.0209230623.700eae42@posting.google.com...
> hi all,
>
> has anybody done this using spartan-ii with - for example -
> an LVDS interface?
>
> What I require is a fast serial - bus like - connection between
> 3 or 4 electronic modules. Those modules are close to each other
> but in separate cabinets. I would like to use - let's say - RJ11
> connector and cabling, the speed should be ~ 100 Mbps
>
> markus



Article: 47376
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 24 Sep 2002 16:44:51 -0700
Links: << >>  << T >>  << A >>


Tim wrote:

> BTW, was there ever silicon of a 1000 series, before
> the 2064?

No, 2064, (followed by 2018, then 3020...) was the first Xilinx FPGA.

Peter Alfke



Article: 47377
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 25 Sep 2002 12:08:50 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Marc,
> 
> I will reiterate something Peter has said once before:  Altera has
> announced that they will have (note use of the future tense) .......
> 
> So comparing an exisiting Spartan IIE product that is selling like
> crazy today (and is the fourth generation Spartan Product) with a
> product that doesn't exist yet at a future technology node is a little
> silly.

Of course, but it is an almost universal marketing reflex.

Considering the technical skills of the customer base, and all the 
credit given to 'listening to the customers', you would expect
semiconductor company press releases to read less 
like soap powder adverts....

Digging about on Altera's releases, we can get a time-line
( now, they could have presented a time line, but you never see
that in SoapPowder 101 )


Cyclone time line:

Beta SW          : Quartus II version 2.1, July 2002
Software Support : Now, Quartus II version 2.1 (service pack 1)
Programming      : Programming file generation for Cyclone devices will
be supported
                   in a subsequent software release
Beta Samples     : ??
Eng Samples      : E.S. Cyclone EP1C20 and EP1C6 January and February
2003, respectively. 
                   E.S  EP1C3 and EP1C12 in April 2003. 
Release          : All family members will be in full production in the
first half of 2003.
Process          : 1.5V, 0.13µm, all-layer-copper process from TSMC.

 Clearly not in general release right now, but not 100% vaporware as
'a product that doesn't exist yet at a future technology node' suggests.
0.13u is not 'future technology', and they will have some silicon in
their
LABs. ( and probably at key customers )


Looking thru Altera's info, the configuration memory looked to have
taken
a significant step.


-jg

Article: 47378
Subject: Unpredictable Place and Route
From: "Clyde R. Shappee" <clydes@world.std.com>
Date: Tue, 24 Sep 2002 20:51:31 -0400
Links: << >>  << T >>  << A >>
Hello, all,

I am working a design with the Xilinx Spartan IIe, using ISE 4.2 sp3,
Sinplicity 7.1 for synthesis.

My design is relatively minimally constrained and meets static timing.
In my report I see 8 levels of logic associated with my system clock.

Today, I removed some unused logic, and reduced the length of some shift
registers in my design, dropping about 32 flip-flops.

Now the design fails to make static timing and the number of levels of
logic associated with my clock has gone up to 12!

What is at work here?

Is the synthesis tool shooting me in the foot, or is it in the Xilinx
tool, or my constraints.

Advice would be greatly appreciated.

Clyde


Article: 47379
Subject: Re: MTBF
From: Stephen Williams <u7gixiz001@sneakemail.com>
Date: 25 Sep 2002 01:02:13 GMT
Links: << >>  << T >>  << A >>
Jon Elson wrote:

>>Peter Alfke wrote:

>>>After testing devices for millions of device hours at 125 degr C, the
>>>calculated failure rate at Tj = 55 degr C is between 5 and 30 FIT, where
>>>one FIT = one failure per billion device hours.

Jon Elsom wrote:

> No, not millions of hours, millions of DEVICE HOURS.  So, there are 8172
> hours a year, and if you put 1000 devices in a test chamber for a year, you
> have
> 8.172 million device hours.  That is a pretty good test of running the chips
> at that
> temperature, internal power dissipation, etc.

Yikes, that "extrapolation" assumes that a chip failure is some
sort of Poisson process. In other words, at any instant in the
lifetime of any part, the probability of a "failure" is the same
as at any other instant. This is obviously not so for bicycles and
rocket motors, but is it true for an ASIC? Is it really true that
a 5year old chip is as likely to fail this minute as a 5day old chip?

On the other hand, what we are calling a failure, here, is not the
sort of thing we would call a failure in a bicycle or a rocket
motor: a failed bicycle goes crash, a failed rocket motor goes
boom, but a failed FPGA goes on. Perhaps the right word is not
"failure", but "error?"

Or is my ignorance showing?

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
steve at picturel.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

abuse@xo.com
uce@ftc.gov


Article: 47380
Subject: Where can I get XC6200 series FPGAs
From: "Jim Lyke" <jimlyke@comcast.net>
Date: Wed, 25 Sep 2002 01:14:57 GMT
Links: << >>  << T >>  << A >>
Is there any source for the discontinued Xilinx XC6200 series FPGAs?  -jim



Article: 47381
(removed)


Article: 47382
Subject: Re: Spartan II JTAG reconfiguration bug - workaround
From: alann@accom.com (Alan Nishioka)
Date: 24 Sep 2002 18:54:12 -0700
Links: << >>  << T >>  << A >>
td@emu.com (Tony Dean) wrote in message news:<33aa9b10.0209240950.6573a03b@posting.google.com>...
> Pierre-Olivier Laprise <plapri@tesserae.McRCIM.McGill.EDU> wrote in message news:<_Zpj9.624$%C6.203154@charlie.risq.qc.ca>...
>  
> >   This procedure is in fact documented in many places that speak
> > of the configuration procedure, amongst others in the Spartan-II
> > data sheet under the heading "Initiating Configuration", right
> > next to a flow chart describing the proper configuration flow.
> 
> You are absolutely right. I don't know how I could have missed that.
> 
> Actually, I do: I was reading the section in the configuration
> procedure under "Boundary Scan Mode" (JTAG) which contains misleading
> phrases such as "configuration being done entirely throught the TAP
> (JTAG port)", and "configuration and readback via the TAP are always
> available", and has a step-by-step procedure that does not mention the
> PROGRAM pin.
> 
> Nevertheless, I plead guilty to not being observant enough, and I
> hereby acquit Xilinx of the heinous crime of docu-negligence, although
> I submit that much future grief could be averted if in the JTAG
> configuration documentation a simple clause was added, "... and of
> course, one must pulse the PROGRAM line low before reconfiguring the
> device via JTAG."
> 
> Humbly,
> -td


Is it not possible to use the SHUTDOWN command with the Spartan-II?
I looked through the Spartan-II datasheet and XAPP176, and it doesn't
really talk about it.

I know this works with Virtex-E.  I have been using it for months. 
The only problem I had was when I installed new software and it set
the disable reconfiguration and readback flag.

Alan Nishioka
alann@accom.com

Article: 47383
(removed)


Article: 47384
(removed)


Article: 47385
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: mrand@my-deja.com (Marc Randolph)
Date: 24 Sep 2002 19:38:28 -0700
Links: << >>  << T >>  << A >>
Howdy Austin,

Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D90A1BD.46C477BD@xilinx.com>...
> Marc,
> 
> I will reiterate something Peter has said once before:  Altera has announced
> that they will have (note use of the future tense) .......
> 
> So comparing an exisiting Spartan IIE product that is selling like crazy
> today (and is the fourth generation Spartan Product) with a product that
> doesn't exist yet at a future technology node is a little silly.
>
> Also stating their projected future price per LUT is better than the existing 
> price per LUT is silly.  Of course:  Moore's Law if they haven't totally
> missed the boat (which they are definitely smart enough not to do).

Howdy Austin,

   Perhaps I didn't write my post clearly.  I have no clue what Altera
will be charging per LUT, nor do I have any information on the devices
to compare them to Spartan IIE's - and I don't think I came close to
referencing either item in my post.  I was simply using Rick's
observations as a spring-board to say that I think this direction
(higher LUT to I/O ratio) is overdue, and gave but two examples.

Truth be told, we ran into this on two XC2V3000 designs and at least
two, if not three XCV600E designs.  An XC2V1000 design is nearly in
the same boat.  The point I was trying to make was that if we (a very
small company) have run into this 4 or 5 times in the past 2 years, I
suspect there are alot more out there just like us.
 
> Virtex II Pro is the ninth generation FPGA product.

And it is quite an impressive product, as were previous families of
Xilinx parts when they arrived.  It is truely a marvel that so much
can be done with such a small, cost effective device.  The amazing
part is that even more could be done with them if some BRAM's were
traded for LUT's, thereby upping the LUT to I/O ratio! ;-)
 
> Maybe we have been doing this for awhile, and maybe we have figured out what
> sells, and what works?

Yes, overall I think you have.  Sales of the Virtex-II are proving
this out.  But be careful about repeating that too much.  There are at
least two major telecom silicon vendors out there that fell into that
exact trap and are now without some key products.  The president of
one of the companies (one you do business with, in fact) is irrate
with his product management staff over it.

> Obviously, we can't please absolutely everyone. 

I agree, and would take it a step further: you almost don't want to
please everyone.  If you do even think about trying to please
everyone, it means you are making too many compromises, which will
force the masses to pay for things they don't want or need.  That
creates and opening for a competitor.

> I appreciate the comments,
> and we always listen to what the customer wants.

That is great to hear - both as an engineer and an investor.

Best regards,

   Marc

Article: 47386
Subject: Can I implement a PCI Master in a ACEX EP1k30-3 FPGA?
From: lyqin@cti.com.cn (Leon Qin)
Date: 24 Sep 2002 19:40:11 -0700
Links: << >>  << T >>  << A >>
meet PCI 2.2 spec

Article: 47387
Subject: Re: IC layout
From: spam_hater_7@email.com (Spam Hater)
Date: Wed, 25 Sep 2002 03:20:02 GMT
Links: << >>  << T >>  << A >>
Hi Reala,

comp.lsi.cad has the most traffic regarding IC layout  But most of it
seems to be centered aroung the program 'magic'.

Still at it, eh?   ;)

SH7

On Fri, 20 Sep 2002 09:41:08 +0800, "Reala" <-> wrote:

>Hi,
>
>Sorry that I ask the question about IC layout, but I cannot find any
>newsgroup about IC layout.
>Sorry for any inconvinence.
>
>Anyone can tell me some homepage or newsgroup talk about IC layout?
>Thank you.
>
>Reala
>
>
>


Article: 47388
Subject: Re: Multiple divide by 10
From: bulletdog7 <bulletdog7@netscape.net>
Date: Wed, 25 Sep 2002 03:24:16 GMT
Links: << >>  << T >>  << A >>
Blackie, you are exactly right!  (Please don't think I'm flaming you, 
its not intended) The ASICs I make though don't fit that category.  To 
justify the cost, they are 4 to 10 clock domains, fully synchronous 
within each domain, but very asynchronous, dissimilar.  Gate counts; 
well its rare to be under 1 million but they range from 500K to 10 
million gates.  Embedded risk processors, embedded rams and ROMs 
multiple large FIFOs and analog blocks; a variety of PHYs etc. are 
typical.  Then you have the test circuitry to add even more timing 
complexity.  Timing closure is not automatic, and, yes we earn the 
money, and the customers are usually very happy. because 10 million of 
these were still cheaper than 20 to 30 million FPGA's. that it would 
have taken for FPGA's assuming we could have reached the required speeds 
in an FPGA.

Yes we use FPGA's too,  mostly for prototyping and proof of concept. 
Yes for the smaller designs they have a very valid place in the 
business.  But I haven't seen them hit the speeds we need with the 
density we need. Nor can they satisfy the gate counts required ... yet.

Blackie Beard wrote:

> I'm not sure about the first statement, since if I had a chip with
> custom DSP, custom DPLL, and say, 50-100K gates, and 1
> clock, and I was going to sell 10 Million of them, and it only used
> 1 clock, why would I not make an ASIC?  We shouldn't need to
> break out the calculator to make my point.
> 
> Also, the design should take into place the transition between
> multiple domains, and force synchronization between them.
> I suppose if you couldn't use FIFO bucket for data transfer
> between two domains, then you'd have big timing concerns,
> because depending upon a race condition not occuring would
> be just plain old hokey.
> 
> BB
> 
> ======================================================
> 
> 
>>Anything complicated enough to make an ASIC out of would tend to have
>>multiple clock domains, etc. It would tend to be synchronous within each
>>domain, but if "timing closure is nearly automatic" were true then why
>>do we at Tality get paid piles of dosh to do the layout for so many
>>designs?
>>
>>
> 
> 
> 


Article: 47389
Subject: Re: writing across a column in an SDRAM
From: spam_hater_7@email.com (Spam Hater)
Date: Wed, 25 Sep 2002 03:28:40 GMT
Links: << >>  << T >>  << A >>
Trcd (IIRC) varies same vs/ different bank. (??  Been a long time
since I read the data sheet)  eg, RAS(0)->CAS(3) will have one timing,
while RAS(0)->CAS(0) *MAY* have a different timing.

FWIW, you'll get higher bandwidth if you do half of the convoloution
on the way in, the other half on the way out.  I wound up chopping it
into 4 steps to maximise data transfer.


SH7

On Tue, 24 Sep 2002 09:24:26 -0400, "A. Nelson"
<anelson@NS.lumenera.com> wrote:

>
>Why am I writing across the columns?  I'm trying to rotate a rather large
>image, 90 degrees.  This way, when the data is read out of the RAM, it can
>be read out "normally", and will be rotated.
>
>Because the image is large, I really don't have the space to buffer even a
>couple of lines (I could probalby buffer one, but I really don't want to).
>
>Just one more question about SDRAMs:
>Trcd is listed as the minimum time between Active and Read/Write.  Now, is
>this between ANY Active and Write, or between Active for a specific row/bank
>and a write to that same row/bank?  For example, if I do the 4 consecutive
>Acitves (which would be for banks 0 to 3 consectutively), followed by 4
>writes (again, for banks 0 to 3 consectutively), do I have to wait Trcd
>between the LAST Active and the FIRST Write, or Trcd between the FIRST
>Active and FIRST Write?
>
>Thanks for everyone's input,
>A.
>
>> --
>>
>> Rick "rickman" Collins
>>
>> rick.collins@XYarius.com
>> Ignore the reply address. To email me use the above address with the XY
>> removed.
>>
>> Arius - A Signal Processing Solutions Company
>> Specializing in DSP and FPGA design      URL http://www.arius.com
>> 4 King Ave                               301-682-7772 Voice
>> Frederick, MD 21701-3110                 301-682-7666 FAX
>
>


Article: 47390
Subject: Re: MTBF
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 25 Sep 2002 03:36:15 GMT
Links: << >>  << T >>  << A >>


Stephen Williams wrote:

> J
> Yikes, that "extrapolation" assumes that a chip failure is some
> sort of Poisson process. <snip>

There is a heap of literature on this subject, and I don't think we can explore
it all in this newsgroup. There are bath-tub curves, there are Arrhenius models,
etc.

Of course it is irrelevant whether a one-chip design lasts one million years or
longer, but the various industries, especially the telecom and military guys as
well as consumer folks, have developed pretty sophisticated models that they are
reasonably happy with.  Let's use them.

Peter Alfke, Xilinx Applications


Article: 47391
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 25 Sep 2002 03:51:30 GMT
Links: << >>  << T >>  << A >>
Marc, I talked with Austin about your previous posting (of this morning).
It is true that the Virtex families emphasize high I/O count, but that is driven by market
demand.
One of the few painless modifications we can make at any time to our product offerings is
device/package matching. Within reason and with some physical limitations, we can put "any die in
any package". The actual offered combinations really depend on demand from our dear customers.
Unfortunately, many have stayed away from the low-pin-count offerings that you like so much. And
yes "we listen to our customers". Too much or not enough?

Peter Alfke, Xilinx Applications




Article: 47392
Subject: Re: Where can I get XC6200 series FPGAs
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 25 Sep 2002 04:00:57 GMT
Links: << >>  << T >>  << A >>
Jim, we at Xilinx cannot help you. Our XC6200 shelves are bare. Most chips
went to universities and to one (or two) small-volume commercial design. The
family died for lack of commercial interest. No sales, no money, no further
development, and then no production. Sorry not to be able to help you.
Peter Alfke
==============
Jim Lyke wrote:

> Is there any source for the discontinued Xilinx XC6200 series FPGAs?  -jim


Article: 47393
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 25 Sep 2002 04:09:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <15881dde.0209241838.636a1e49@posting.google.com>,
Marc Randolph <mrand@my-deja.com> wrote:
>And it is quite an impressive product, as were previous families of
>Xilinx parts when they arrived.  It is truely a marvel that so much
>can be done with such a small, cost effective device.  The amazing
>part is that even more could be done with them if some BRAM's were
>traded for LUT's, thereby upping the LUT to I/O ratio! ;-)

Actually, no.  If you look at a Xilinx die, you realize that the
memory is a very small fraction.  You can really see this on the
Virtex E die photo, the BlockRAMs are only about 2x the width of a CLB
column

http://www.xilinx.com/company/press/products/images/large/virtexedie.jpg


This is one of the reasons why progressive parts are more memory
heavy: it really is comparatively small, but when you want the memory,
you REALLY want the memory, making it high value.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 47394
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Wed, 25 Sep 2002 04:36:31 GMT
Links: << >>  << T >>  << A >>
Marc Randolph wrote:

> The amazing
> part is that even more could be done with them if some BRAM's were
> traded for LUT's, thereby upping the LUT to I/O ratio! ;-)

Please, no.  Especially in the larger parts, please more block RAM, not
less.

As parts get larger, and designs get faster, moderate sized internal
buffers have been and will continue to be very useful, at least for
designs I've done.  Last big project I did used 100% of the block RAMS
and a bunch of LUTS as RAMS as well.

A key point is that FPGAs are used for lots of different sorts of
designs, and they can never be a close fit for all but a tiny subset of
these designs.  There will always be some users asking for more A and
less B and other users asking for more B and less A.  Some designs need
one clock tree, why are you wasting resources making more?  Others need
5, or 8, or more.  Some need more LUTS.  Some will need more RAM.  I
have no past, current or known future use for multipliers, yet I'd
suspect that a bunch of DSP guys would whine loudly if you took the
multipliers out.

The one thing I'd ask for is some programmable delays for a fraction of
the pins for a 90 degree phase shift for the DQS for DDR RAMS.  About 1
in 4 IOBs or 1 in 8 IOBs would be just fine, thank you.  Do the Altera
Cyclone parts have something like this?


-- 
Phil Hays

Article: 47395
Subject: Re: Installing ISE5.1i (Alliance) on Solaris 7.
From: Petter Gustad <newsmailcomp3@gustad.com>
Date: Wed, 25 Sep 2002 05:00:06 GMT
Links: << >>  << T >>  << A >>
akineko@pacbell.net (Aki Niimura) writes:

> Hi,
> 
> We tried to install the ISE5.1i on our Sun/Solaris 7 server which has
> 4GB
> memory. We are using ISE4.2i (SP3).
> 
> We got the following error message.
> 
> % ./setup
> ld.so.1: /foo/xilsetup: fatal: librt.so.1: version `SUNW_1.2' not
> found (required by file /foo/xilsetup)
> Killed

I haven't received 5.1 yet, but it appears that you need to set
LD_LIBRARY_PATH to point to the directory where librt.so.1 resides.
LD_LIBRARY_PATH is usually set by sourcing the settings file. But you
can do

find /foo -name librt.so.1

If the file is location in /foo/libs you then do:

LD_LIBRARY_PATH=/foo/libs /foo/xilsetup

I'm assuming a sh compatible shell here. If there more missing
libraries you have to repeat the procedure and add each directory to
the LD_LIBRARY_PATH separated by :.

Petter

-- 
________________________________________________________________________
Petter Gustad         8'h2B | ~8'h2B        http://www.gustad.com/petter

Article: 47396
Subject: RPM_GRID (was MAP problem: Trivial RPM fails)
From: "Jan Gray" <jsgray@acm.org>
Date: Tue, 24 Sep 2002 22:25:35 -0700
Links: << >>  << T >>  << A >>
"Bret Wade" <bret.wade@xilinx.com> wrote in message
news:3D8FB6EC.A33F615F@xilinx.com...
> This RPM pack error has been investigated and found to be a bug in the
mappers
> pack code. A fix is scheduled for 5.1i service Pack 3 which will become
> available in December, 2002.

Thank you!

BTW I have just received 5.1i.  (Compared to 4.2i, on one P&R, effort 5, on
a non-trivial floorplanned datapath, the critical path and path delay was
identical, down to the ps, even though two net delays changed!)

In my review of the 5.1i materials, I have just come across the RPM_GRID
notion, and this app note, written by Mr. Wade:

"Using an RPM Grid Macro to Control Block RAM-to-FF Timing"
http://www.xilinx.com/xapp/xapp416.pdf

Very interesting.  Has anyone here in comp.arch.fpga land been using
RPM_GRID, and can you share your experiences with us?

See also the recent RPM techXclusive,
http://www.xilinx.com/support/techxclusives/RPMs-techX30.htm.

Thanks,
Jan Gray, Gray Research LLC




Article: 47397
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 25 Sep 2002 17:31:47 +1200
Links: << >>  << T >>  << A >>
Marc Randolph wrote:
> 
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<3D8F2B52.9DA16C60@yahoo.com>...
> 
> > After taking a quick look at the Cyclone family, I can see they are
> > taking a slightly different approach than Xilinx.
> >
> > The Xilinx Spartan II series is based on the Virtex family just as the
> > Spartan was based on the XC4000.  In contrast, it looks like the Cyclone
> > family is not directly based on any existing Altera family.
> >
> > Comparing the Spartan II to the Cyclone shows that the Cyclone has a
> > higher LUT to IO ratio.  The Cyclone looks a little more like a
> > potential future Spartan III based on the Virtex II family which also
> > has a high LUT to IO ratio.
> >
> > SpartanII 2S50E 2S100E 2S150E 2S200E 2S300E
> > LUTs       1536   2400   3456   4700   6144
> > IOs         182    202    263    289    329
> > ratio         8     12     13     16     19
> >
> > Cyclone  EP1C3 EP1C6 EP1C12 EP1C20
> > LUTs      2910  5980  12060  20060
> > IOs        104   185    249    301
> > ratio       28    32     48     67
> >
> > As it turns out this makes the Cyclone parts very expensive in high IO
> > count applications.  Further, Altera seems to not have small chip scale
> > packages for the low end of the family.  Looks like they really tried to
> > go for a low price, limited options product line, even more so than the
> > Spartan II.  The high LUT count may prove a benefit for some
> > applications though.
> 
> From what I've seen, the last 3 or so generations of Altera devices
> appear to have higher LUT/IO ratios than the comparible Xilinx family.
>  In general, at least in the telecom industry where I am, I think this
> is the right direction to be moving and Xilinx appears to have finally
> figured this out, from the looks of the proposed Spartan III.
> Undoubtly, the problem is identifing exactly what features and what
> packages to offer for given LUT ranges.
> 
> We are constantly bumping up against the largest device in a cost
> effective package.  IE, we definitely would move to using a larger
> Virtex-II (XC2V4000) if it were available in anything smaller than an
> expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm BGA
> package].  I realize Xilinx probably has their reasons for the
> offerings they have (most likely thermal?), but if they could overcome
> that, it'd be easy money for them, cause I'll bet there are others out
> there in the same boat as us.
>
> Same went for the Virtex-E... the 600E was the largest you could get
> in a reasonable cost/size package.  The XCV812EM was available, but
> not competitively priced.  We would have used a large device if Xilinx
> had offered it in a FG676.  Instead, in both the Virtex-II and
> Virtex-E, we get to play roulette with MAP and PAR, constaintly
> bumping up against random timing violations that differ from run to
> run.

 Package alone is not likely to be a dominant cost factor :
Far more relevent, will be die area, yield, testing times, FAB run
volumes,
( mask amortise) plus the M Squared fudge factor ( M^2 = Marketing
Margin ) 

( see also other thread on higher end CPLD price-kick )

 That said, it makes sound sense to offer a broad range of die in
a common package - designs NEVER get smaller as they mature :)

 A good example, that proves this can be done, is the Actel ProASIC 
- they offer ALL die, from 75K to 1000K, in a PQFP208 package ( 7 steps
). 

 If you really need IO, they also have a FBGA1152 on the biggest device.

 -jg

Article: 47398
Subject: Re: Multiple divide by 10
From: Ray Andraka <ray@andraka.com>
Date: Wed, 25 Sep 2002 05:33:45 GMT
Links: << >>  << T >>  << A >>
What are your speed requirements that FPGAs won't hit?  Many ASIC apps are
achievable with a proper FPGA design (note that such a design is usually much
more heavily pipelined and is floorplanned, a direct port of your ASIC code is
going to be slow in an FPGA).   Your density numbers are certainly high, and I
think well above the industry average.

bulletdog7 wrote:

> Blackie, you are exactly right!  (Please don't think I'm flaming you,
> its not intended) The ASICs I make though don't fit that category.  To
> justify the cost, they are 4 to 10 clock domains, fully synchronous
> within each domain, but very asynchronous, dissimilar.  Gate counts;
> well its rare to be under 1 million but they range from 500K to 10
> million gates.  Embedded risk processors, embedded rams and ROMs
> multiple large FIFOs and analog blocks; a variety of PHYs etc. are
> typical.  Then you have the test circuitry to add even more timing
> complexity.  Timing closure is not automatic, and, yes we earn the
> money, and the customers are usually very happy. because 10 million of
> these were still cheaper than 20 to 30 million FPGA's. that it would
> have taken for FPGA's assuming we could have reached the required speeds
> in an FPGA.
>
> Yes we use FPGA's too,  mostly for prototyping and proof of concept.
> Yes for the smaller designs they have a very valid place in the
> business.  But I haven't seen them hit the speeds we need with the
> density we need. Nor can they satisfy the gate counts required ... yet.
>
> Blackie Beard wrote:
>
> > I'm not sure about the first statement, since if I had a chip with
> > custom DSP, custom DPLL, and say, 50-100K gates, and 1
> > clock, and I was going to sell 10 Million of them, and it only used
> > 1 clock, why would I not make an ASIC?  We shouldn't need to
> > break out the calculator to make my point.
> >
> > Also, the design should take into place the transition between
> > multiple domains, and force synchronization between them.
> > I suppose if you couldn't use FIFO bucket for data transfer
> > between two domains, then you'd have big timing concerns,
> > because depending upon a race condition not occuring would
> > be just plain old hokey.
> >
> > BB
> >
> > ======================================================
> >
> >
> >>Anything complicated enough to make an ASIC out of would tend to have
> >>multiple clock domains, etc. It would tend to be synchronous within each
> >>domain, but if "timing closure is nearly automatic" were true then why
> >>do we at Tality get paid piles of dosh to do the layout for so many
> >>designs?
> >>
> >>
> >
> >
> >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 47399
Subject: Re: Altera Cyclone low-cost FPGA chips?
From: "ds" <nospam@cwix.com>
Date: Wed, 25 Sep 2002 05:34:44 GMT
Links: << >>  << T >>  << A >>
"Each Cyclone device is equipped to interface with DDR SDRAM and FCRAM
devices using optimized I/O pins as seen in Figure 1. Each I/O bank features
two sets of interface signal pins and each set contains a single data strobe
(DQS) pin and eight associated data (DQ) pins. These pins are designed for
high-speed data transfer with an external memory device using the SSTL-2
Class II I/O standard. Up to 48 DQ pins are available per device with 8
corresponding DQS pins, supporting a single dual-inline memory module (DIMM)
with 32-bit data and error correction."

http://www.altera.com/products/devices/cyclone/features/cyc-ext_mem_int.html

Should answer the question below.

> The one thing I'd ask for is some programmable delays for a fraction of
> the pins for a 90 degree phase shift for the DQS for DDR RAMS.  About 1
> in 4 IOBs or 1 in 8 IOBs would be just fine, thank you.  Do the Altera
> Cyclone parts have something like this?

- DS


"Phil Hays" <SpamPostmaster@attbi.com> wrote in message
news:3D913E3F.C4E82D64@attbi.com...
> Marc Randolph wrote:
>
> > The amazing
> > part is that even more could be done with them if some BRAM's were
> > traded for LUT's, thereby upping the LUT to I/O ratio! ;-)
>
> Please, no.  Especially in the larger parts, please more block RAM, not
> less.
>
> As parts get larger, and designs get faster, moderate sized internal
> buffers have been and will continue to be very useful, at least for
> designs I've done.  Last big project I did used 100% of the block RAMS
> and a bunch of LUTS as RAMS as well.
>
> A key point is that FPGAs are used for lots of different sorts of
> designs, and they can never be a close fit for all but a tiny subset of
> these designs.  There will always be some users asking for more A and
> less B and other users asking for more B and less A.  Some designs need
> one clock tree, why are you wasting resources making more?  Others need
> 5, or 8, or more.  Some need more LUTS.  Some will need more RAM.  I
> have no past, current or known future use for multipliers, yet I'd
> suspect that a bunch of DSP guys would whine loudly if you took the
> multipliers out.
>
> The one thing I'd ask for is some programmable delays for a fraction of
> the pins for a 90 degree phase shift for the DQS for DDR RAMS.  About 1
> in 4 IOBs or 1 in 8 IOBs would be just fine, thank you.  Do the Altera
> Cyclone parts have something like this?
>
>
> --
> Phil Hays





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