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 54025

Article: 54025
Subject: Re: Xilinx announces 90nm sampling today!
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Mon, 31 Mar 2003 18:49:03 +0100
Links: << >>  << T >>  << A >>
Austin Lesea wrote
> Have just annouced 90nm shipped samples.
>
> http://biz.yahoo.com/prnews/030331/sfm087_1.html
>

Same operating voltages at 90nm as at 130nm?




Article: 54026
Subject: Input Characteristics : HCMOS vs TTL
From: "Charles Barnes" <cbarnes@drc.com>
Date: Mon, 31 Mar 2003 10:08:31 -0800
Links: << >>  << T >>  << A >>
This may be a completely stupid question but I am having trouble locating any information on it online. 
I am using the CPLD 9500 series and it says that the inputs should be of type TTL. However, an oscillator that we are looking into (and highly favor) has a HCMOS output. 
Now, often I have seen HCMOS/TTL as an output type. 

My question is: 

Would this line of CPLDs take an HCMOS input to one of the global clock inputs? 



Article: 54027
Subject: Re: Xilinx announces 90nm sampling today!
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 31 Mar 2003 10:15:00 -0800
Links: << >>  << T >>  << A >>
Tim,

I can not give you any details until they are released.

I think you can make a good educated guess at what the core voltage is
for 90 nm, however.

Austin

Tim wrote:

> Austin Lesea wrote
> > Have just annouced 90nm shipped samples.
> >
> > http://biz.yahoo.com/prnews/030331/sfm087_1.html
> >
>
> Same operating voltages at 90nm as at 130nm?


Article: 54028
Subject: Re: Xilinx announces 90nm sampling today!
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 31 Mar 2003 18:16:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3E887532.31FE90B4@xilinx.com>,
Austin Lesea  <Austin.Lesea@xilinx.com> wrote:
>Nicholas,

It's pronounced "Nick".  :)

>The original question was "why would anyone spend $4,000."
>
>Good question.  No one does.  Well almost no one.  I suppose the 'monster'
>FPGAs (like the 2V8000, or the 2VP100) will always command a premium until
>they, too, are mainstream - just a question of demand).

The way to look at it is there are ALWAYS some fraction of the
applications which need as much computing power/IO/memory that can be
thrown at the task, EG a core router.  And there will always be some
fraction in that (rather profitable) space.

>1M+ gates up until now has certainly been much less than $4,000 (even in small
>quantities).

Yeah.  The V2P7 is looking to be a nice sweet spot for a few years
(~10k LUTs, 8 SerDeses, uP), and Altera has similar.  Both are a
little less than 1M markiting gates, but they do have a lot of
functionality for the money.

The other nice sweet spot are the low end Spartan II/IIE/Cyclone parts
in the ~1k-2k LUT range.  Anything you can get in quantity 1 for $50
from Digikey is interesting.

>ASICs are all but dead except for those really big jobs that can
>afford the $80M++ price tag to develop them.  Or those jobs where low
>current is required (ie cell-phones).

However I don't think ASICs are as dead as Xilinx & Altera would like
to think.  The are chewing away on the low end, AND the NRE costs keep
getting worse (a lot just being linearly with the number of features.
Go from .13 to .09, same reticle size, and the number of features
increases by 2x, so many of the costs are going to jump by at LEAST
2x), but there are many tasks where you just can't fit the
computational power in a cost-effective FPGA, eg Graphics Cards,
chipsets, switches, etc, etc etc.

Similarly, the cost for an ASIC is so much lower, especially for small
parts, so a 25-35 mm^2 ASIC costs somewhere around $5-10/chip
(including packaging).  If one is shipping enough volume to justify
the NRE cost (which is now much lower because we aren't full reticle,
but I don't know how well that scales), the ASIC once again is at an
advantage.  You can do a hell of a lot in 25 mm^2 of ASIC silicon, and
at a fraction of the power.

Actually, I'd guess that the next big target for FPGAs are NOT the
ASICs per se, but the DSP and network processor based systems, where
the greater parallelism of the FPGA, combined with integrating the
I/O, results in a lower system cost.  You're starting to really see
this with the Simulink flows, and Ray Andraka's consulting projects.

>Even televisions don't sell enough to afford some of the new ASIC
>pricetags.  Think about it.  An "appliance" doesn't sell in large
>enough volume to have its own ASIC.

Except this example doesn't NEED a heck of a lot of computational
power.  If requirements are low enough, throw a uP or FPGA at it and
be done with it, the cheaper the better.

>So 'cheap' ASICs are stuck at 180nm (and above).  But with 90nm FPGAs we are
>three or more techology steps ahead (.15, .13, .09), and that makes us a
>better deal.

"Stuck" at 180nm is still faster than an FPGA for many purposes, and
you get the volume production costs.  It's a big tradeoff game.

However, I like the emerging trend of the low end FPGAs switching to
the process-leading position: Cyclone (.13) and the rumored Spartan
III, this does help alot.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 54029
Subject: Re: ModelSIM XE wave files
From: "Kevin Neilson" <kevin_neilson@removethistextattbi.com>
Date: Mon, 31 Mar 2003 18:52:12 GMT
Links: << >>  << T >>  << A >>
Here are the methods I use:

o Do a 'print screen' to copy the image to the paste buffer.  Then you can
paste it into Word.  This is quick, but the image is big.

o Do the same thing, but paste it into a program like Paint, and then you
can crop it and save it as JPEG if you wish.

o Use the Adobe Acrobat (the one you have to buy) PDF distiller function.
You print the image, but use the PDF Distiller instead of a printer driver.
The result is a small, clean, B&W image that you can put in docs or just
print out by itself.

-Kevin

"Michael Nicklas" <michaeln@nospam.slayer.com> wrote in message
news:b6927n$6sp$1$8300dec7@news.demon.co.uk...
> Hi
>
> does anybody know if there is a way to export the wave file created during
a
> simulation to a Word document or other package instead of just taking a
> screen capture??
>
> I honestly cant seem to find anything about this in the pdf documentation
or
> release notes etc.
>
> Thanks in advance.
>
> --
> Cheers!
>
> Mike
>
>



Article: 54030
Subject: Re: microblaze gnu tool info ?
From: Steve Lass <lass@xilinx.com>
Date: Mon, 31 Mar 2003 12:03:11 -0700
Links: << >>  << T >>  << A >>


Petter Gustad wrote:

>John Williams <jwilliams@itee.uq.edu.au> writes:
>
>>Muzaffer Kal wrote:
>>    
>>
>>>Hi,
>>>I guess some people here must be working with Microblaze processors. I
>>>understand that Microblaze EDK ships with a port of GNU tools. Are the
>>>sources for these tools available (from the GPL I understand that they
>>>must be). When one gets the EDK, do you get the sources on the CD ?
>>>
>>>      
>>>
>>Hi Muzaffer,
>>
>>The EDK runs on top of a modified version of Cygwin, called Xygwin[1].
>>    
>>
>
>Is there a native version for Solaris
>
Yes.  The 3.1 version batch tools run on Solaris, but not the GUI.  The 
3.2 release does support GUIs
on Solaris and will be shipping in 2 weeks.

> or Linux?
>
This is planned for the 6.1 release in September.

>>The gnu tools (mb-gcc, mb-ld, etc etc) run within Xygwin.  The source
>>for these tools is publicly available for download from Xilinx.  You
>>don't need to be an EDK customer to obtain it.
>>I have a copy here, it's several hundred megabytes.  I looked but
>>can't find the place on xilinx's website where I downloaded it.
>>    
>>
>
>Does anybody else have an URL?
>
>I checked for the EDK price:
>
>http://www.xilinx.com/xlnx/xebiz/productview3.jsp?category=-18886
>
>But it's "Out of Stock". Does it mean that Xilinx is out of CD-R's,
>manuals, etc.
>
We ran out of 3.1 CDs.  Since we are in the middle of the manufacturing 
cycle on 3.2, no
more 3.1 CDs were orderred.

> It would be easier if it was possible to just pay and
>download the kit.
>
I'll look into setting this up.

Steve

>
>Petter
>  
>






Article: 54031
Subject: Re: ModelSIM XE wave files
From: "kero" <kero@cuhk.edu.hk>
Date: Tue, 1 Apr 2003 03:11:27 +0800
Links: << >>  << T >>  << A >>
Try "print postscript"
then convert ps to eps using gs or some graphics utility
word can import eps file

"Michael Nicklas" <michaeln@nospam.slayer.com> ¼¶¼g©ó¶l¥ó·s»D
:b6927n$6sp$1$8300dec7@news.demon.co.uk...
> Hi
>
> does anybody know if there is a way to export the wave file created during
a
> simulation to a Word document or other package instead of just taking a
> screen capture??
>
> I honestly cant seem to find anything about this in the pdf documentation
or
> release notes etc.
>
> Thanks in advance.
>
> --
> Cheers!
>
> Mike
>
>



Article: 54032
Subject: Re: connecting 2 FPGAs
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 31 Mar 2003 19:29:56 GMT
Links: << >>  << T >>  << A >>
One item to consider when interconnecting chips: try to arrange the link to
allow pipeline stages.  When the outputs and inputs are both registered in
the IOBs (Input/Outbut Blocks) in the two devices, system timing is simple;
200MHz for simple short point-to-point connection is very reasonable.  Use
of a combinatorial output to a combinatorial input could be ugly.

Some ASIC prototyping tools that target FPGAs (e.g. Synplicity's Certify
product) will help to handle the interface between multiple FPGAs very
cleanly.

"Andreas Wortmann" <wortmann@informatik.hs-bremen.de> wrote in message
news:b69hvv$ds6$1@hermes1.rz.hs-bremen.de...
> Hi,
>
> I need to connect 2 FPGAs (Xilinx SpartanIIe, Virtex) via a parallel data
> link.
> i.e. 80Bit @ 50Mhz, bidirectional.
>
> Does somebody have any experience what to take care of or does somebody
know
> some good reference ?
>
> thank, andreas



Article: 54033
Subject: Re: DSP-FPGA interface
From: tonym@gallagher.co.nz (Tony McKay)
Date: 31 Mar 2003 12:21:46 -0800
Links: << >>  << T >>  << A >>
> 'f2407 is a fixed point DSP and has something between 100 and 200 MIPS,
> while c67xx family is floating point and some models go beyond 2000
> MFLOPS. They aren't exactly equivalent. ;)

Its worse than that, the 240X are 40MIPS tops. 

Mybe the 240X could be used with the 67XX. The 2402 has 6 PWMs and the
2407 has 12 as well as heaps of other peripherals that maybe handy,
like I/O, in-circuit writable flash, and serial commms. This may free
up the 67XX to do other tasks. If cost is a big factor then mybe a
cheap micro to run the peripherals? You could send it a command then
leave it to accomplish its job.

Article: 54034
Subject: Re: Xilinx announces 90nm sampling today!
From: "raymund hofmann" <filter001@desinformation.de>
Date: Mon, 31 Mar 2003 23:57:33 +0100
Links: << >>  << T >>  << A >>

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3E887532.31FE90B4@xilinx.com...
> Nicholas,
>
> Now we are talking about even less money for 1M+ gates in 90 nm.
>
> ASICs are all but dead except for those really big jobs that can afford
the
> $80M++ price tag to develop them.  Or those jobs where low current is
required
> (ie cell-phones).

Or jobs that need more than 1000-10000 Parts ?
Or jobs that need a unit price lower than 1/100 ?
Or jobs that need some logic going fast ?

>
> Even televisions don't sell enough to afford some of the new ASIC
pricetags.
> Think about it.  An "appliance" doesn't sell in large enough volume to
have
> its own ASIC.

Or maybe they don't have engineers to handle a ASIC ?

> So 'cheap' ASICs are stuck at 180nm (and above).  But with 90nm FPGAs we
are
> three or more techology steps ahead (.15, .13, .09), and that makes us a
> better deal.

One should think about these things:

Usually a FPGA needs around 15 times the transistors for implementing random
logic compared to a standard cell ASIC.
This means ~15 in Area.
It looks similar for the delay to perform the same random logic.
So one could say that 0.09 FPGA compares to a 0.35 STD Cell ASIC.
One should also think about the process technology and NRE is getting more
expensive the smaller it gets.
But when going into details the things may look very different in favor of
either ASIC or FPGA.

The expensive FPGA's have no volume.

The sweet spot for FPGA's is where the other costs for using it dominate the
pure silicon area costs (which have some relation to the marketing price).

Austin,

Have you just recently joined the Marketing at Xilinx ?

Raymund Hofmann




Article: 54035
Subject: Re: [Question] FPGA/PLX9054
From: Bassman59a@yahoo.com (Andy Peters)
Date: 31 Mar 2003 15:12:49 -0800
Links: << >>  << T >>  << A >>
"Garrett Mace" <g.ryan@macetech.com> wrote in message news:<v8d6qmog6fr357@corp.supernews.com>...
> Simple question, for those who've done it before:
> 
> How many I/O's are required to implement an interface to PLX9054?
> 
> I'm running pretty tight on I/O right now, and this may not be a high-volume
> project, so the customer may prefer $18 extra per board as opposed to $2000
> for a Xilinx core (still fuzzy on that, you can use and sell the $2000 IP on
> one project, right?).
> 
> I can get by with the ~50 pins needed for in-FPGA PCI; do I need much more
> than that to use a PLX chip?

Well, for starters, you could look at the PLX documentation and count
how many pins are used by the local bus.

You have to choose the PLX local bus mode, either "C" (non-muxed
address and data bus) or "J" (muxed address and data bus).  There's
another dozen or so control lines you'll need.  If you only require an
8-bit local bus, you can save some pins.  If you need all 32 data
pins, and need to decode all 32 address bits, AND don't want to use
the "J" mode (does ANYONE use the "J" mode?), then you'll need maybe
80 pins.
 
> If I tried to use an open core, do I run up against GNU if I sell the board,
> or does simply attributing the core source satisfy licensing?

The GPL doesn't have anything to do with the hardware.  What, are you
making your FPGA code open-source?  Besides, you don't get the source
to the Xilinx core, anyway.

-a

Article: 54036
Subject: Re: More xilinx webpack verilog questions: always @(clock) legal?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 31 Mar 2003 15:31:54 -0800
Links: << >>  << T >>  << A >>
Jan Panteltje <panteltje@yahoo.com> wrote in message news:<b64p0p$qe2$1@reader1.tiscali.nl>...
> Xilinx webpack 4.1, some question:
> If  I use:
> always  @(clock)
> it is optimized away (and subsequently no output at test)..
> if I use 
> always @(posedge clock)
> things work, OK, then you get half the freq at test.
> 
> I looked always() up in some verilog tutorial, and it seems to be legal 
> to write always @(clock)
> 
> So is Xilinx wrong, or am I wrong, or what gives guys?
> 
> 
> module lcd_text_driver(clock, text, text_strobe,
>         lcd_rst,
>         lcd_read_data,
>         lcd_e, lcd_rw, lcd_rs,
>         lcd_write_data, lcd_dir, test);
> 
> input         clock;
> output test;
> 
> // other in and outputs snipped
> 
> reg [7:0] fstate;
> reg lcd_initialized;
> reg us_clock;
> wire test;
> 
> // THIS 
> //generate micro second clock (from 50 MHz)
> //always @(posedge clock)
> always @(clock)
> begin
> fstate = fstate + 1;
> if(fstate >= 50)
>         begin
>         fstate = 0;
>         us_clock = !us_clock;
>         end 
> end // always
> 
> assign test = us_clock;
> endmodule
> 
> look at ..map:
> 
>  The signal "clock" is loadless and has been removed.
>   Loadless block "clock" (PAD) removed.


Look again at your code.  Without the "posedge," the always block is
sensitive only to clock, which means several things:

1) If you want an edge-triggered flip-flop, you need the "posedge,"
otherwise the synth tool will make a combinatorial latch.  But ...

2) You code never uses the signal clock inside that block, so the tool
says, "whoops! You never use that signal, so the synth tool optimizes
it away.  So, you have a latch, or something, that doesn't exactly do
what you want.

Remember that the "posedge clock" is what the synth tool uses as a
template for edge-triggered flops.  When the tool sees it, it goes,
"ah! flop!"  That's also why other signals shouldn't be on the
sensitivity list for a flip-flop.

Helpful side comment that may prevent much gnashing of teeth and
bullet-holes later:

Your comparison, 

    if (fstate >= 50)

may not do what you want.  I would guess that fstate is not declared
an integer.  However, Verilog helpfully considers the constant 50 to
be an integer, which is a 32-bit signed value.  What happens is that
fstate is sign-extended to a 32-bit integer, and a bit-for-bit
comparison is made.

Follow this through.  Say that fstate is declared like:

    wire [5:0] fstate;

and, at some point, fstate is incremented and ends up as 6'd50.  What
is the result of the following comparison:

    (6'd50 == 50)

?

To find the answer, simply sign-extend 6'd50 to 32 bits, and do a
bit-by-bit compare.

--a

Article: 54037
Subject: Re: Input Characteristics : HCMOS vs TTL
From: "Gregory C. Read" <readgc.invalid@hotmail.com.invalid>
Date: Tue, 01 Apr 2003 00:02:44 GMT
Links: << >>  << T >>  << A >>
A TTL input is easily driven by an HCMOS output (assuming the same VCC).
It's the other way around that presents a problem.

--
Greg
readgc.invalid@hotmail.com.invalid
(Remove the '.invalid' twice to send Email)


"Charles Barnes" <cbarnes@drc.com> wrote in message
news:ee7ca13.-1@WebX.sUN8CHnE...
This may be a completely stupid question but I am having trouble locating
any information on it online.
I am using the CPLD 9500 series and it says that the inputs should be of
type TTL. However, an oscillator that we are looking into (and highly favor)
has a HCMOS output.
Now, often I have seen HCMOS/TTL as an output type.
My question is:
Would this line of CPLDs take an HCMOS input to one of the global clock
inputs?



Article: 54038
Subject: Re: Xilinx announces 90nm sampling today!
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Mon, 31 Mar 2003 16:13:34 -0800
Links: << >>  << T >>  << A >>
Raymund,

No, last I looked, I still had "engineer" in my title.  Still have to run
simulations, do fourier transforms, examine pcb layouts, create circuits and
designs.

Still have a job, too.  How many positions are open for ASIC designers?  Are you
one of the very lucky, very few, still employed?

Austin

raymund hofmann wrote:

> "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
> news:3E887532.31FE90B4@xilinx.com...
> > Nicholas,
> >
> > Now we are talking about even less money for 1M+ gates in 90 nm.
> >
> > ASICs are all but dead except for those really big jobs that can afford
> the
> > $80M++ price tag to develop them.  Or those jobs where low current is
> required
> > (ie cell-phones).
>
> Or jobs that need more than 1000-10000 Parts ?
> Or jobs that need a unit price lower than 1/100 ?
> Or jobs that need some logic going fast ?
>
> >
> > Even televisions don't sell enough to afford some of the new ASIC
> pricetags.
> > Think about it.  An "appliance" doesn't sell in large enough volume to
> have
> > its own ASIC.
>
> Or maybe they don't have engineers to handle a ASIC ?
>
> > So 'cheap' ASICs are stuck at 180nm (and above).  But with 90nm FPGAs we
> are
> > three or more techology steps ahead (.15, .13, .09), and that makes us a
> > better deal.
>
> One should think about these things:
>
> Usually a FPGA needs around 15 times the transistors for implementing random
> logic compared to a standard cell ASIC.
> This means ~15 in Area.
> It looks similar for the delay to perform the same random logic.
> So one could say that 0.09 FPGA compares to a 0.35 STD Cell ASIC.
> One should also think about the process technology and NRE is getting more
> expensive the smaller it gets.
> But when going into details the things may look very different in favor of
> either ASIC or FPGA.
>
> The expensive FPGA's have no volume.
>
> The sweet spot for FPGA's is where the other costs for using it dominate the
> pure silicon area costs (which have some relation to the marketing price).
>
> Austin,
>
> Have you just recently joined the Marketing at Xilinx ?
>
> Raymund Hofmann


Article: 54039
Subject: What would it take?
From: "Jerry" <nospam@nowhere.com>
Date: Mon, 31 Mar 2003 20:03:59 -0500
Links: << >>  << T >>  << A >>
With the recent announcement of 90 nanometer FPGAs and the multi mega gate
counts that the geometries implies
I was wondering what would it take to implement the synthesis, place and
router internal to the FPGA? Perhaps the
source is store in some form of an intermediate result, say like P code was
to Pascal. I'm thinking that the internal
place and router could map around defective silicon thereby boasting yield.
Anyway its a thought, maybe a thread, maybe
a product?

Jerry






Article: 54040
Subject: Re: Xilinx announces 90nm sampling today!
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 01 Apr 2003 13:15:54 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Raymund,
> 
> No, last I looked, I still had "engineer" in my title.  Still have to run
> simulations, do fourier transforms, examine pcb layouts, create circuits and
> designs.
> 
> Still have a job, too.  How many positions are open for ASIC designers?  Are you
> one of the very lucky, very few, still employed?
> 
> Austin

 On this general subject, this was interesting :

  
Monday, March 31, 2003 
Analysis: ASIC design starts fall below 1,500 

http://www.ebnonline.com/showArticle.jhtml;jsessionid=1WAFUWCBLY0WEQSNDBCSKICCJUMEIJVN?articleID=8100159

 Tho I think the proof-readers got lost on this one :

"--Roughly 75% of designs were reported to work on the first pass, with
a surprising one out of 10 ASICs requiring two passes or more before
working, if ever." 

 this implies that 15% of designs 'fail and die' at the first hurdle ?.

I think they really meant to say  
"one out of 10 ASICs requiring three passes more before working, if
ever."

which gives a more credible :
75% work (tolerably) first time
15% work after two spins
10% work after three or more spins, or not at all 

-jg

Article: 54041
Subject: Re: What would it take?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 01 Apr 2003 13:38:07 +1200
Links: << >>  << T >>  << A >>
Jerry wrote:
> 
> With the recent announcement of 90 nanometer FPGAs and the multi mega gate
> counts that the geometries implies
> I was wondering what would it take to implement the synthesis, place and
> router internal to the FPGA? Perhaps the
> source is store in some form of an intermediate result, say like P code was
> to Pascal. I'm thinking that the internal
> place and router could map around defective silicon thereby boasting yield.
> Anyway its a thought, maybe a thread, maybe
> a product?

 You need to clarify a little - if you mean 'design time
compiler/accelerator',
I think that is already being done, as co-processor engines etc.
 Certainly simulation is being greatly accelerated with real devices.

 If you mean 'load time smarts', that's more of a minefield.
- FPGAs are wastefull enough of silicon now, this adds a heap more, for
something that is used once at load time.
- Load times would become indeterminate & long
- How does the on-chip router KNOW what's defective
- Timing closure would need large data fields

 Altera does have some redundancy scheme (yield improve), but that's 
invisible to the design file, so must use some fuse scheme.
 Xilinx will sell you cheaper FPGAs, if you promise to use huge numbers,
and never change the bit-patterns. (yield and testing improve)

-jg

Article: 54042
Subject: Re: What would it take?
From: "Robert Finch" <robfinch@sympatico.ca>
Date: Mon, 31 Mar 2003 20:51:28 -0500
Links: << >>  << T >>  << A >>
> place and router could map around defective silicon thereby boasting
yield.
> Anyway its a thought, maybe a thread, maybe
> a product?
>

How would it be possible to know whether or not there is a defect in the
FPGA until the application is actually run ?

Surely in a multi-mega gate FPGA it's not possible to test every possible
combination of programming pattern that could be used ?

Otherwise if there are defects that are detected during the manufacture
process, would it be possible to store a defect list that could be retrieved
by the tools ?

Rob




Article: 54043
Subject: Re: Input Characteristics : HCMOS vs TTL
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Mon, 31 Mar 2003 21:01:55 -0500
Links: << >>  << T >>  << A >>


"Gregory C. Read" wrote:

> A TTL input is easily driven by an HCMOS output (assuming the same VCC).
> It's the other way around that presents a problem.
>
> --
> Greg
> readgc.invalid@hotmail.com.invalid
> (Remove the '.invalid' twice to send Email)

Please explain, as I would have thought that a TTL output could easily drive an
HCMOS input.  (Is it perhaps a question of signal levels requiring a pull up
resistor to get a solid logic "1"?)   However, the _really_  _old_ CMOS (4000
series) could not drive a ttl input due to the sink current required to pull
down the ttl input.  I cannot recall the exact sink and source capacity of HCMOS
so I might be missing something.

Theron

>
>
> "Charles Barnes" <cbarnes@drc.com> wrote in message
> news:ee7ca13.-1@WebX.sUN8CHnE...
> This may be a completely stupid question but I am having trouble locating
> any information on it online.
> I am using the CPLD 9500 series and it says that the inputs should be of
> type TTL. However, an oscillator that we are looking into (and highly favor)
> has a HCMOS output.
> Now, often I have seen HCMOS/TTL as an output type.
> My question is:
> Would this line of CPLDs take an HCMOS input to one of the global clock
> inputs?


Article: 54044
Subject: Re: Input Characteristics : HCMOS vs TTL
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 01 Apr 2003 02:23:55 GMT
Links: << >>  << T >>  << A >>
Hi  - 

On Mon, 31 Mar 2003 21:01:55 -0500, "Theron Hicks (Terry)"
<hicksthe@egr.msu.edu> wrote:

>"Gregory C. Read" wrote:
>
>> A TTL input is easily driven by an HCMOS output (assuming the same VCC).
>> It's the other way around that presents a problem.
>>
>> --
>> Greg
>> readgc.invalid@hotmail.com.invalid
>> (Remove the '.invalid' twice to send Email)
>
>Please explain, as I would have thought that a TTL output could easily drive an
>HCMOS input.  (Is it perhaps a question of signal levels requiring a pull up
>resistor to get a solid logic "1"?)  

You'll need a pullup.  A true CMOS input usually needs a logic HIGH
level of 0.7xVcc.  For a 5V supply, then, we'd need 3.5V.  TTL outputs
are not guaranteed to reach this level, although many will in fact.

Bob Perlman
Cambrian Design Works 

Article: 54045
Subject: Re: Spartan vs. Cyclone for arithmetic functions
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Tue, 01 Apr 2003 02:25:44 GMT
Links: << >>  << T >>  << A >>
Hello Matt,

First off, the best way to get a feel for the performance of two
architectures is to try them out yourself.  The architectural trade-offs are
too difficult to work out by hand (though I'll try below ;-)).  Both Altera
and Xilinx have tools available for free over the web.  One caveat: it's
best to use non-trivial designs, as any device will run fast with a single
adder or shift register.  Also, beware the effect of pin placement -- always
register your inputs and outputs when benchmarking, and either don't specify
any timing constraints or only specify an internal Fmax (or global clock)
constraint.  This ensures that pin placement will not affect your
measurement of core performance.

Cyclone is definitely worth taking a look at.  The Cyclone LE supports
dynamic add/subtract control, allowing you to implement adder/subtractors
with one LE per bit.  Your options when using registered logic are quite
plentiful: in a single LE you can implement an adder/subtractor feeding a
register with asynch or synchronous load, asynch & synchronous reset, clock
enable, and asynchronous clear.  You can also pack registers with unrelated
unregistered logic (such as arithmetic) to increase the effective logic
density of your design.

You should also see a substantial speed advantage in Cyclone vs. Spartan
IIE.  This is due to process (0.13u vs. 0.18u) and architecture (IIE hails
from the Virtex E days, Cyclone is cutting edge and designed for low-density
applications).  For small designs, Cyclone approachs the speed of Stratix,
our high-end FPGA.

Regards,

Paul Leventis
Manager, Software Engineering
Altera Corp.



"Matt Ettus" <matt@ettus.com> wrote in message
news:e8fd79ea.0303281453.1a94c2f0@posting.google.com...
> I've seen this question answered in the FAQ, but only for older
> devices.
>
> I have a design which is mostly composed of adder-subtractors (i.e.
> you add or subtract depending on a third data input) of between 16 and
> 32 bits wide.  Some of these need to run as fast as 120 MHz.  Previous
> posts seem to indicate that Xilinx is much better for things of this
> type, but the posts were pre-Cyclone.  Does this still apply?
>
> We were planning on using the Spartan 2E with 300K-gates, but we are
> constrained to use a non-BGA part, and thus have become pin-limited.
> The Cyclone parts have more I/Os in the PQFP packages, so the EP1C6
> and EP1C12 looked interesting.  If Cyclone is usable for this sort of
> application, which part is closest in functionality to the SpartanII
> 300?
>
> Thanks
> Matt



Article: 54046
Subject: Re: What would it take?
From: "Jerry" <nospam@nowhere.com>
Date: Mon, 31 Mar 2003 22:58:51 -0500
Links: << >>  << T >>  << A >>
With scan one can get above 99% fault coverage so detecting defective logic
shouldn't be a problem.

> Otherwise if there are defects that are detected during the manufacture
> process, would it be possible to store a defect list that could be
retrieved
> by the tools ?

Yes thats what I'm getting at. During test the defective CLBs and routes are
stored in on chip memory. At power on
time the on chip router takes the defective list in to consideration to do
the palce and route.

Maybe whats stored is the results of the Xilinx mapping process.

"Robert Finch" <robfinch@sympatico.ca> wrote in message
news:Bg6ia.1407$DD6.332428@news20.bellglobal.com...
> > place and router could map around defective silicon thereby boasting
> yield.
> > Anyway its a thought, maybe a thread, maybe
> > a product?
> >
>
> How would it be possible to know whether or not there is a defect in the
> FPGA until the application is actually run ?
>
> Surely in a multi-mega gate FPGA it's not possible to test every possible
> combination of programming pattern that could be used ?
>
> Otherwise if there are defects that are detected during the manufacture
> process, would it be possible to store a defect list that could be
retrieved
> by the tools ?
>
> Rob
>
>
>



Article: 54047
Subject: Re: [Question] FPGA/PLX9054
From: "Garrett Mace" <g.ryan@macetech.com>
Date: Mon, 31 Mar 2003 22:08:08 -0600
Links: << >>  << T >>  << A >>
> > I can get by with the ~50 pins needed for in-FPGA PCI; do I need much
more
> > than that to use a PLX chip?
>
> Well, for starters, you could look at the PLX documentation and count
> how many pins are used by the local bus.

I know, I'm in a quoting phase right now and have five or six options I'm
trying to put together in a short amount of time. ;-)
The PLX doc's really aren't all that clear. The app notes vary quite a bit
depending on what the application is.

> You have to choose the PLX local bus mode, either "C" (non-muxed
> address and data bus) or "J" (muxed address and data bus).  There's
> another dozen or so control lines you'll need.  If you only require an
> 8-bit local bus, you can save some pins.  If you need all 32 data
> pins, and need to decode all 32 address bits, AND don't want to use
> the "J" mode (does ANYONE use the "J" mode?), then you'll need maybe
> 80 pins.

32-bit would be handy (memory is an array of 32-bit values). So you're
saying the pin count is going to be roughly the bus width+address lines+11.
J mode doesn't sound too attractive, I think multiplexed bus is what I'm
looking for here. So I'd have a 32-bit bus + 11 control lines, so ~43 I/O?
Looks good.

> > If I tried to use an open core, do I run up against GNU if I sell the
board,
> > or does simply attributing the core source satisfy licensing?
>
> The GPL doesn't have anything to do with the hardware.  What, are you
> making your FPGA code open-source?  Besides, you don't get the source
> to the Xilinx core, anyway.

Yeah...well, I saw "Open" and assumed GNU...but actually the open hardware
license is still in flux from what I can tell. I can't release the
application HDL as open source, but thought perhaps you can use the open
core in a commercial application if the HDL for the core is distributed as
well. I know you don't get the source for the Xilinx core...but then it
works, is ~optimized, and you get some measure of support. Haven't heard
many good things about Open PCI either, or much of anything for that matter.
I have heard it's not the easiest way to go, but better than trying to roll
your own....

Thanks for your help, the PLX chip seems to be a good option. May be able to
offset some of the cost by using a smaller FPGA.




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 54048
Subject: Re: Spartan vs. Cyclone for arithmetic functions
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Tue, 01 Apr 2003 04:20:45 GMT
Links: << >>  << T >>  << A >>
Hi Sanjay,

I'm no expert on Xilinx's CLB.  But I do not believe they can implement an
n-bit A+B+C operation in one bit per LC.  In a quick experiment; A+B+C turns
into 16 LCs in their latest software.  Now, this could be bad synthesis/HDL,
and given all the goo in a LC, I could very well have missed an interesting
way to configure the LC to do this function.  If so, I'm sure one of Xilinx
folk will jump in quickly :-)

On the memory side of things, Cyclone does offer more dedicated memory in
devices of equivalent logic density (92Kb in 1C6 vs. 64K in XC2S300E).  For
large/parellel shift registers, the M4K blocks can be used, and for small
shift registers, the LE has a shift-register cascade function that allows
shift-registers to be packed with unrelated logic.  Obviously there are
applications where SRLs or distributed RAM will work well -- for example, a
design full of independently controlled 16-bit shift registers.  You need to
look at your memory requirements and decide which suites your design.

Regards,

Paul Leventis
Altera Corp.


"sanjay" <sanjay@cg-coreel.com> wrote in message
news:b63d8p$18l7i$1@ID-164436.news.dfncis.de...
> Hi Matt,
> what Ray says is perfect.
> There is no competition to Spartan-IIE when it comes to arithmatic
> operations.
> Apart from SRL [ which according to Ray is biggest plus point of Xilinx ],
> LUT can be configured as Distributed RAM which may be useful to you.
> This you can't do with Cyclone.
> Also 3 operand arithmatic Function [Sum = A+B+C]  goes in one Logic Block
in
> Spartan-IIE, which takes two Logic Blocks with Cyclone.
> Apart from that Spartan-II E has Mult-AND for doing Fast Multiplications.
>
> So I don't think there can be a any substitute for Spartan-IIE for your
app.
> --Sanjay
>
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3E84FB53.F9E1D5EA@andraka.com...
> > Cyclone is certainly usable.  The mapping efficiency is going to depend
on
> > whether you are just doing a simple add or if there is more
functionality
> > in front of the add such as a mux.  It does have the direct connects
> > between LABs, and it also has extra gating to allow a controllable
> > add/subtract without going to a second level of logic.  The Xilinx
> > structure is still a bit more flexible going into a carry chain (you get
> > a  4 input LUT and a separate dedicated carry as opposed to 3 LUTs for
> > carry and sum plus a bit of gating for add/subtract).  The biggest
> > advantage the spartan has IMHO is the SRL16, which can be used as a
> > reloadable LUT (which is great for reprogrammable DA filters), as a
delay
> > queue, as a reorder queue or other things.  The cyclone is closer to the
> > Xilinx functionality than 10K or 20K devices.
> >
> > Matt Ettus wrote:
> >
> > > I've seen this question answered in the FAQ, but only for older
> > > devices.
> > >
> > > I have a design which is mostly composed of adder-subtractors (i.e.
> > > you add or subtract depending on a third data input) of between 16 and
> > > 32 bits wide.  Some of these need to run as fast as 120 MHz.  Previous
> > > posts seem to indicate that Xilinx is much better for things of this
> > > type, but the posts were pre-Cyclone.  Does this still apply?
> > >
> > > We were planning on using the Spartan 2E with 300K-gates, but we are
> > > constrained to use a non-BGA part, and thus have become pin-limited.
> > > The Cyclone parts have more I/Os in the PQFP packages, so the EP1C6
> > > and EP1C12 looked interesting.  If Cyclone is usable for this sort of
> > > application, which part is closest in functionality to the SpartanII
> > > 300?
> > >
> > > Thanks
> > > Matt
> >
> > --
> > --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: 54049
Subject: Re: Spartan vs. Cyclone for arithmetic functions
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Tue, 01 Apr 2003 04:36:39 GMT
Links: << >>  << T >>  << A >>
Marc,

If only comparing logic cells were that simple.

Though Xilinx's data sheet shows 6912 logic cells for XC2S300E, there are
only physically 6144 logic cells in the part.  Take the CLB array size (32 x
48) and multiply it out (x4 LCs per CLB) = 6144.  Or look at the distributed
RAM -- 98304/16 bits per LC = 6144 LCs.  So this is much closer to the 5980
logic elements in the 1C6.

Why is this, you may ask?  It's a creative piece of marketing where Xilinx
has decided their logic cell is worth 12.5% more than their past or Altera's
(I forget which) logic cell.  This is due to all the goo that allows various
functions to be rolled into the LC in addition to a 4-input LUT.

Each Stratix/Cyclone LE can be 4-input LUT + flop + loads of control/logic
functions, so our marketing could play a similar game, but they don't.

We get very efficient mapping of designs into LEs, achieving a 9% reduction
relative to the Virtex II Pro raw logic cell counts (not including logic
cell/logic cell factor) in Stratix.  See
http://www.altera.com/literature/wp/wp_stx_logic_efficiency.pdf.  Cyclone
uses the same LE as Stratix, and Spartan IIE uses the same LE as Virtex E,
so you should see somewhat similar results.  These are real results on real
user designs -- your results will vary, as the graph shows.

So as always, I encourage you to download both of our tools and try things
out on your designs.

BTW, I too can't wait to see how Spartan III stacks up versus Cyclone.
Nothing like a little competition to keep us all working hard ;-)

Regards,

Paul Leventis
Altera Corp.


"Marc Randolph" <mrand@my-deja.com> wrote in message
news:15881dde.0303282058.647e2db@posting.google.com...
> matt@ettus.com (Matt Ettus) wrote in message
news:<e8fd79ea.0303281453.1a94c2f0@posting.google.com>...
> > I've seen this question answered in the FAQ, but only for older
> > devices.
> >
> > I have a design which is mostly composed of adder-subtractors (i.e.
> > you add or subtract depending on a third data input) of between 16 and
> > 32 bits wide.  Some of these need to run as fast as 120 MHz.  Previous
> > posts seem to indicate that Xilinx is much better for things of this
> > type, but the posts were pre-Cyclone.  Does this still apply?
>
> Howdy Matt,
>
> Most likely not.  But the only way to determine with certainty if the
> design is going to fit and meet timing in any part is to put it
> through the tools and see.
>
> The Cyclone is a much newer part and could likely outperform the
> not-so-new Spartan 2E.  Later this year the Spartan III will come out,
> which may leapfrog the Cyclone slightly.  That's how the competition
> goes.
>
> > We were planning on using the Spartan 2E with 300K-gates, but we are
> > constrained to use a non-BGA part, and thus have become pin-limited.
> > The Cyclone parts have more I/Os in the PQFP packages, so the EP1C6
> > and EP1C12 looked interesting.  If Cyclone is usable for this sort of
> > application, which part is closest in functionality to the SpartanII
> > 300?
>
> It appears that you are correct - although Xilinx has parts with
> considerably more I/O, you must use a fine pitch BGA to get them.  The
> Spartan 2E (XC2S300E) has 7000 logic cells.  Ignoring all other
> factors that might influence your choice (like core voltage, I/O
> support, PLL vs. DLL, etc) this obviously falls between an EP1C6 and
> an EP1C12, which have 6000 and 12000 logic cells respectively.
>
> The key to comparing parts is to ignore the Xilinx marketing gate
> counts and look at logic cells.  Altera has thankfully started putting
> the logic count in their part number.
>
> Now, a question:  What makes you think you need a 300K-gate FPGA for
> this design?
>
> Have fun!
>
>    Marc





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