Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 15500

Article: 15500
Subject: Re: keeping an Altera EAB register in synplicity
From: Ken McElvain <ken@synplicity.com>
Date: 26 Mar 1999 08:23:53 PST
Links: << >>  << T >>  << A >>
Here is a sample:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity myrom is
 port(q : out std_logic_vector (3 downto 0);
      a : in std_logic_vector (2 downto 0);
    clk : in std_logic);
end entity myrom;

architecture rtl of myrom is
--
-- The following attribute tells Synplify how to process this entity
--
attribute altera_implement_in_eab : boolean;
attribute altera_implement_in_eab of rtl : architecture is true;

subtype romword is std_logic_vector(3 downto 0);
type romtable is array (0 to 7) of romword;
constant rom : romtable := (
 "0000",
 "0001",
 "0011",
 "0010",
 "0110",
 "0111",
 "1101",
 "0100"
 );
begin
 process
 begin
  wait until rising_edge(clk);
  q <= rom(to_integer(UNSIGNED(a)));
 end process;
end architecture rtl;

library ieee;
use ieee.std_logic_1164.all;
entity romtest is
 port(q : out std_logic_vector (3 downto 0);
      a : in std_logic_vector (2 downto 0);
    clk : in std_logic);
end entity romtest;

architecture rtl of romtest is
begin
 u1: entity work.myrom(rtl)
  port map (q => q, a => a, clk => clk);
end architecture rtl;

Hans Christian Lønstad wrote:

> How do you specify (in VHDL) the content of the ROM? I have used an integer array (as
> GENERIC) for a "black box" approach and externally computed a memory content file.
> The MAXPLUS tool requires a memory content file for initialization of the EAB ROM.
> Does Synplify create this for you?.
> One way of circumventing the problem might be to specify a randomized content to the
> synthesis phase, then replacing the ROM content file with the wanted one prior to
> place and route in MAXPLUS.
>
> Ray Andraka wrote:
>
> > Forgot to mention it.  HDL analyst shows the register in the RTL view, but it is
> > stripped out and replaced with a soft buffer in the technology view.  Without the
> > SYN_PRESERVE attribute, the register is optimized out in the RTL view too.
> >
> > Ray Andraka wrote:
> >
> > > Synplicity 5.08, which you can download from their site, correctly infers a ROM
> > > into EAB if you use the ALTERA_IMPLEMENT_IN_EAB attribute on the block you want
> > > to put in the EAB.  If that block includes registers at the output, the EAB
> > > registers get invoked.  If any bit is registered, then all bits must be
> > > registered, or it can't be implemented in an EAB.  The problem I am having is
> > > that one of the bits in the ROM is 'stuck at zero' so the register gets
> > > optimized off that bit.  Since one bit is now unregistered, the whole thing
> > > gets thrown out of the EAB.  I've got another instance of the same component,
> > > different data that implements just fine.
> > >
> > > I'd rather avoid having to instantiate the EAB as a black box if I can.  It's
> > > kind of a pain in the patoot at the system level.
> > >
> > > Hans Christian Lønstad wrote:
> > >
> > > > Ray Andraka wrote:
> > > >
> > > > > I'm trying to use the registers in the altera EAB from synplicity.
> > > > > Works fine, but one bit in my ROM happens to always be zero, so
> > > > > synplicity is optimizing that out to a soft-buf.  I've tried to use the
> > > > > SYN_PRESERVE attribute, but it doesn't want to keep the errant
> > > > > register.  The result is the table is getting implemented in LEs
> > > > > instead.  Has anyone else seen this?  Any ideas on how to make it stay?
> > > > >
> > > > > --
> > > > > -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
> > > >
> > > > To my knowledge Synplify can't infer ROM into EABs (at least up to version
> > > > 5.0.7). I've had to use a "black box" workaround calling a LPM macro in the
> > > > Altera library. This has the unfortunate effect that you have to supply an
> > > > additional simulation model for direct VHDL, VERILOG simulation.
> > > >
> > > > --
> > > > Hans Christian Lønstad       Data Respons AS
> > > >                              Sandviksveien 26
> > > > Real Time                    1322 Høvik
> > > > Professionals                Norway
> > > >
> > > > mailto:Hans.Christian.Lonstad@datarespons.no
> > > > http://www.datarespons.no
> > >
> > > --
> > > -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
> >
> > --
> > -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
>
> --
> Hans Christian Lønstad       Data Respons AS
>                              Sandviksveien 26
> Real Time                    1322 Høvik
> Professionals                Norway
>
> mailto:Hans.Christian.Lonstad@datarespons.no
> http://www.datarespons.no

Article: 15501
Subject: Re: IBM 600MHz FPGA
From: "Martin Duffy" <martin_duffy@penarth31.freeserve.co.uk>
Date: Fri, 26 Mar 1999 16:38:26 -0000
Links: << >>  << T >>  << A >>
DynaChip's ECL FPGA family, DL5000, is manufactured on a 0.8micron BiCMOS
process at IBM. It is capable of max clock speeds of 270MHz. If/when they
shrink to 0.5micron, they will be able to cope with 500-600MHz.

Is this what you are thinking of ?
I haven't heard anything about IBM releasing their own FPGAs.

DynaChip are at www.dyna.com.

Martin Duffy, Ambar Components Ltd, UK.

Mike Scott wrote in message <36FB9D65.7826@mediaone.net>...
>I have heard rumors about a 600MHz FPGA from IBM floating around.
>I did a search but have not been able to find anything on the
>subject.  Could someone who knows anything about this please
>comment (via email as well).  We would be extremely interested.
>
>Thanks,
>Mike Scott


Article: 15502
Subject: Re: IBM 600MHz FPGA
From: Richard Guerin <guerin2@home.com>
Date: Fri, 26 Mar 1999 17:20:25 GMT
Links: << >>  << T >>  << A >>
Wonder it's an application of the new SOI-CMOS (Silicon-On-Insulator)
process that IBM announced late last year ... perhaps uses copper
technology too.

Check out these IBM SOI links

	http://www.chips.ibm.com/bluelogic/showcase/soi/

	http://www.chips.ibm.com/gallery/soi2.html

Mike Scott wrote:
> 
> I have heard rumors about a 600MHz FPGA from IBM floating around.
> I did a search but have not been able to find anything on the
> subject.  Could someone who knows anything about this please
> comment (via email as well).  We would be extremely interested.
> 
> Thanks,
> Mike Scott
Article: 15503
Subject: Re: IBM 600MHz FPGA
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Fri, 26 Mar 1999 13:57:20 -0800
Links: << >>  << T >>  << A >>
Hmm. If they mean real system clock rates with I/O to match, it could
be interesting. Otherwise, heck, Xilinx is already claiming 1 GHz.
(input toggle rate) Designers of frequency counters are ecstatic.

Here's what my search turned up:
http://www.electronicnews.com/enews/front/1007f1.html
(1996 article describing end of IBM's abortive attempt
to get into the FPGA biz using Atmel/Concurrent technology)


Mike Scott wrote:
> 
> I have heard rumors about a 600MHz FPGA from IBM floating around.
> I did a search but have not been able to find anything on the
> subject.  Could someone who knows anything about this please
> comment (via email as well).  We would be extremely interested.
> 
> Thanks,
> Mike Scott

Tom Burgess
Article: 15504
Subject: Re: keeping an Altera EAB register in synplicity
From: Ray Andraka <randraka@ids.net>
Date: Fri, 26 Mar 1999 17:26:08 -0500
Links: << >>  << T >>  << A >>
That's basically what I did, 'cept I put the constant array in a separate package file so I
could generate it with a C program without having to generate the architecture and entity
from there too.  As I said, one bit of the ROM is always 0, and synplicity is optimizing it
out even with the syn_preserve attribute.  I got a note back from synplicity saying that
they agree, and that it is fixed in 5.2.

Ken McElvain wrote:

> Here is a sample:
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
> entity myrom is
>  port(q : out std_logic_vector (3 downto 0);
>       a : in std_logic_vector (2 downto 0);
>     clk : in std_logic);
> end entity myrom;
>
> architecture rtl of myrom is
> --
> -- The following attribute tells Synplify how to process this entity
> --
> attribute altera_implement_in_eab : boolean;
> attribute altera_implement_in_eab of rtl : architecture is true;
>
> subtype romword is std_logic_vector(3 downto 0);
> type romtable is array (0 to 7) of romword;
> constant rom : romtable := (
>  "0000",
>  "0001",
>  "0011",
>  "0010",
>  "0110",
>  "0111",
>  "1101",
>  "0100"
>  );
> begin
>  process
>  begin
>   wait until rising_edge(clk);
>   q <= rom(to_integer(UNSIGNED(a)));
>  end process;
> end architecture rtl;
>
> library ieee;
> use ieee.std_logic_1164.all;
> entity romtest is
>  port(q : out std_logic_vector (3 downto 0);
>       a : in std_logic_vector (2 downto 0);
>     clk : in std_logic);
> end entity romtest;
>
> architecture rtl of romtest is
> begin
>  u1: entity work.myrom(rtl)
>   port map (q => q, a => a, clk => clk);
> end architecture rtl;
>
> Hans Christian Lønstad wrote:
>
> > How do you specify (in VHDL) the content of the ROM? I have used an integer array (as
> > GENERIC) for a "black box" approach and externally computed a memory content file.
> > The MAXPLUS tool requires a memory content file for initialization of the EAB ROM.
> > Does Synplify create this for you?.
> > One way of circumventing the problem might be to specify a randomized content to the
> > synthesis phase, then replacing the ROM content file with the wanted one prior to
> > place and route in MAXPLUS.
> >
> > Ray Andraka wrote:
> >
> > > Forgot to mention it.  HDL analyst shows the register in the RTL view, but it is
> > > stripped out and replaced with a soft buffer in the technology view.  Without the
> > > SYN_PRESERVE attribute, the register is optimized out in the RTL view too.
> > >
> > > Ray Andraka wrote:
> > >
> > > > Synplicity 5.08, which you can download from their site, correctly infers a ROM
> > > > into EAB if you use the ALTERA_IMPLEMENT_IN_EAB attribute on the block you want
> > > > to put in the EAB.  If that block includes registers at the output, the EAB
> > > > registers get invoked.  If any bit is registered, then all bits must be
> > > > registered, or it can't be implemented in an EAB.  The problem I am having is
> > > > that one of the bits in the ROM is 'stuck at zero' so the register gets
> > > > optimized off that bit.  Since one bit is now unregistered, the whole thing
> > > > gets thrown out of the EAB.  I've got another instance of the same component,
> > > > different data that implements just fine.
> > > >
> > > > I'd rather avoid having to instantiate the EAB as a black box if I can.  It's
> > > > kind of a pain in the patoot at the system level.
> > > >
> > > > Hans Christian Lønstad wrote:
> > > >
> > > > > Ray Andraka wrote:
> > > > >
> > > > > > I'm trying to use the registers in the altera EAB from synplicity.
> > > > > > Works fine, but one bit in my ROM happens to always be zero, so
> > > > > > synplicity is optimizing that out to a soft-buf.  I've tried to use the
> > > > > > SYN_PRESERVE attribute, but it doesn't want to keep the errant
> > > > > > register.  The result is the table is getting implemented in LEs
> > > > > > instead.  Has anyone else seen this?  Any ideas on how to make it stay?
> > > > > >
> > > > > > --
> > > > > > -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
> > > > >
> > > > > To my knowledge Synplify can't infer ROM into EABs (at least up to version
> > > > > 5.0.7). I've had to use a "black box" workaround calling a LPM macro in the
> > > > > Altera library. This has the unfortunate effect that you have to supply an
> > > > > additional simulation model for direct VHDL, VERILOG simulation.
> > > > >
> > > > > --
> > > > > Hans Christian Lønstad       Data Respons AS
> > > > >                              Sandviksveien 26
> > > > > Real Time                    1322 Høvik
> > > > > Professionals                Norway
> > > > >
> > > > > mailto:Hans.Christian.Lonstad@datarespons.no
> > > > > http://www.datarespons.no
> > > >
> > > > --
> > > > -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
> > >
> > > --
> > > -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
> >
> > --
> > Hans Christian Lønstad       Data Respons AS
> >                              Sandviksveien 26
> > Real Time                    1322 Høvik
> > Professionals                Norway
> >
> > mailto:Hans.Christian.Lonstad@datarespons.no
> > http://www.datarespons.no



--
-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: 15505
Subject: Re: What do you think about philips XPLA?
From: Richard Guerin <guerin2@home.com>
Date: Sat, 27 Mar 1999 04:58:39 GMT
Links: << >>  << T >>  << A >>
Download free tools at http://www.coolpld.com/xplaxl.html

BTW...you'll need a good synthesis tool if you plan to use a popular HDL
for design entry.



"Dr. Peter Schulz" wrote:
> 
> The tools are easy to use and the CoolRunners
> are "real" low power devices.
> 
> NO-SPAM (damiano) schrieb in Nachricht ...
> >They seem low cost available and with low cost tools.
> >But performance compared to Xilinx and others?
> >
> >Damiano Rullo
> >Trezzano S/N
> >Milan, Italy
> >http://members.it.tripod.de/Damianoux/index.html
> >mailto: dmn@cheerful.com
> >mailto: damiano@mclink.it
> >
Article: 15506
Subject: Re: Free Xilinx Vendor Tools ... JBits
From: Steve@XXX_REMOVE_XXXrsn-tech.demon.co.uk (Steve Rencontre)
Date: Sun, 28 Mar 1999 03:39:28 GMT
Links: << >>  << T >>  << A >>
On Thu, 25 Mar 1999 20:04:22 -0800, Steve Casselman <sc@vcc.com>
wrote:

>> But Xilinx don't publish their bitstream format, do they? So you can't
>> write your own complete software.
>>
>
>With JBits you won't need to know the exact bit format.  People
>are starting to write their own tools that bypass the Xilinx software
>altogether.

What's JBits? URL?

>It may be that soon, 1-2 yrs

With respect, that's not much use to anyone /now/.

--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk/  --  remember to despam return address
Article: 15507
Subject: Re: Info about FPGA/PLD
From: "Mike Roberts" <mfroberts@mediaone.net>
Date: Sun, 28 Mar 1999 12:14:54 -0600
Links: << >>  << T >>  << A >>
The most CPLDs are fully CMOS.  The difference between FPGAs and CPLDs are
the programmed cells. FPGAs use a SRAM pass transistor that must be
configured on power up.  CPLDs use non-volatile E2CMOS cells that require
current based sense amps to determine the cell state. These sense amps
translate into high quiescent (static) currents.  If you take the quiescent
(static) current away and compare FPGAs and CPLDs, you will see that they
are comparable for the same gate count at the same frequency.

Mike Roberts

rk <stellare@erols.com.NOSPAM> wrote in message
news:36FAF8FF.F20589F9@erols.com.NOSPAM...
> hi,
>
> i think a lot just, well, depends.
>
> many of the fpga's i use (q-logic, actel) normally have a static current
> of around hundred or so uA and that's from an on-chip charge pump.  i
> normally measure this with the inputs held at either Vcc or GND so there
> is no totem pole current.  a good quality cmos part should have a very low
> static current.  perhaps with some FPGAs there are some on-chip
> oscillators that are running or some inputs that are being driven with TTL
> logic '1' levels.
>
> the cmos asics i have had made (chipx qyh500, cx2001, and cx3001) mostly
> all had currents that were in the noise level of the adc on the power
> supply, which is tens of uA.  i measured a few with a good current shunt
> and they were very low, as would be expected.
>
> the altera's that i have running are, well, let us say, warm to the touch
> (they're pretty old, didn't do the intial design, don't know much about
> them - 5192) and the dl5000 was quite a heater (bicmos process @ ~50mW or
> so per enabled logic block).
>
> the "cmos" pals that i have used were obviously not fully "cmos."
>
> just a thought,
>
> rk
>
> ______________________________
>
> Tom Burgess wrote:
>
> > If we're going to be picky, might as well also point out that the
> > Philips "zero power" CPLDs have static current specs in the tens
> > of microamps (e.g. 35 uA for the PZ3032C). Quite a bit closer to
> > zero. Not meaning to disparage Peter's generally helpful quick
> > summary for the neophyte.
> >
> > Ray Andraka wrote:
> > >
> > > Peter Alfke wrote:
> > >
> > > > FPGAs have a more versatile structure with lots and lots of
> > > > flip-flops. Static power consumption is zero, it's all
> > > > dynamic and thus proportional to clock rate.
> > >
> > > Really?!! Where can I get some of these FPGAs with zero static
> > > dissipation.  Last I checked, seems that the majority of devices had
> > > static currents of 5-10mA
> > >
> > > --
> > > -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
> >
> >
> > Tom Burgess
>
>
>


Article: 15508
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Sun, 28 Mar 1999 18:18:35 GMT
Links: << >>  << T >>  << A >>
On Thu, 25 Mar 1999 12:24:35 -0800, Peter Alfke <peter@xilinx.com>
wrote:

<on the wisdom of NeoCAD>

>Just grab a few experienced guys, spend a few dozen
>man-years, and then find out that there is no way to make
>money. If that's your idea of fun, go ahead...

Then you can get bought by Xilinx for a chunk of money and live it up
a little! Was the real reason(s) Xilinx paid money for NeoCAD:

a) An incompetent financial decision by Xilinx management who paid way
over the worth for a "no way to make money" company and technology.

b) A philanthropic gesture as part of Xilinx charity to lost causes.

c) An attempt to access a technology that was seen as superior to that
in house at the time. (Why M1 instead of XACT7.0?)

d) A direct attack upon other competing FPGA vendors supported solely
by NeoCAD software, in order to destroy their P&R capability, and thus
place uncertainty and doubt in the market place (even if some of them
had legal rights to code etc.)

My money would be on b) right? (insert tongue in cheek now).

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 15509
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Sun, 28 Mar 1999 18:18:37 GMT
Links: << >>  << T >>  << A >>
On Fri, 26 Mar 1999 07:46:25 GMT, Richard Guerin <guerin2@home.com>
wrote:

<snip of low cost entry tools>

>My view diverges, however, when it comes to place-and-route tools. IMHO,
>P&R tools and FPGA devices exist in symbiosis and should therefore be
>considered as one body of work. After all, what real good is a P&R tool
>unless your going to make chip ... conversely, what good is chip unless
>you have a P&R tool to crunch your netlist ? So, who would benefit from
>a free P&R tool .... Hmmmmmm, how about someone who was going to burn an
>FPGA ... someone who was going to PAY for an FPGA ?  Does it seem
>logical that the largest FPGA vendor in the world would be in the best
>competitive position to roll software development costs into the price
>of their products ?  I'm pretty sure that Intel passes on charges to you
>for new compiler development each time they introduce a new CPU
>architecture.

Intel may be free to do this because of their seemingly monopolistic
position in their specific marketplace. The FPGA market does not work
in such a way in most cases (IMHO). Frequently there will be two or
three FPGA vendors who can competently complete your design
requirement. So then it's down to price, delivery, and a few other
factors...

<snip of downloadable limited Alliance product>

Good idea. But then we are assuming access to third party design
entry, simulation and synthesis tools, which cost "real" money because
the vendors don't have a silicon revenue to support their efforts.
Hence spending $10K..$100K+ to leverage a "free" tool seems rather
peculiar. What such a free P&R tool would do is enable an existing
vendor independent designer to try a different FPGA technology without
a purchase order or any interaction with a sales-droid. Strangely
though, I would expect those kinds of companies (high FPGA spend, with
third party tools installed) to have the sales-droids all over them
with free tools.

>BTW .... I don't argue this point for myself. I work for a very large
>global corporation  ... in fact, a key element of the Dow Jones
>Industrial 30. I get all free FPGA development tools (including Xilinx)

Ah ha! My point exactly. They want your volume, and to them, the
support effort and P&R tools cost is in the noise-floor of doing
business. This is manifestly not the case for the guy in a garage who
is going to buy a few hundred parts per year.

>that I can stand :-)  Rather, I argue this point as a matter of
>principle.

Just out of interest, do you get all your ASIC layout tools for free
from your chosen foundry or did your corporation (gasp) PAY for them?

Cheers
Stuart
For Email remove "NOSPAM" from the address
Article: 15510
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: Richard Guerin <guerin2@home.com>
Date: Sun, 28 Mar 1999 19:33:22 GMT
Links: << >>  << T >>  << A >>


Stuart Clubb wrote:

> What such a free P&R tool would do is enable an existing
> vendor independent designer to try a different FPGA technology without
> a purchase order or any interaction with a sales-droid.

This is a luxury that I am fortunate enough to enjoy (realize that this 
isn't the case for everyone.) As a designer I'm free to select the 
device that is best suited for a particular application .....PERIOD !
In fact, coupled with a well developed in-house IP core library, these 
tools are routinely used during the proposal stages of a new project to
help select vendor and device.
  
> Just out of interest, do you get all your ASIC layout tools for free
> from your chosen foundry or did your corporation (gasp) PAY for them?

Wow, that sparked a flash-back of days past. Approx. five years ago, the 
split between in-house ASIC & FPGA based designs was 90% ASIC / 10%
FPGA, 
we did custom in-house ASIC development (including custom layout), the
corp. 
owned a division who in turn owned and operated a fab line. Since, then
the ratio of ASIC to FPGA based designs has completely reversed, a
couple
of years ago the microelectronic division sold its fab, then last year
the corporation sold the microelectronics division ... and of course,
the STOCK price (hence DJIA) has soared. Today, for the 
occasional ASIC turn, we depend on the silicon supplier to provide
layout 
and back-annotation services (similar to what an FPGA P&R tools does). 
So, I guess to answer your question, NO we don't pay for ASIC layout 
tools .... it's rolled up into the price of the silicon. Rather, the
six figure a year CAE/EDA tools budget (for my immediate area alone) is 
virtually 100% utilized on front-end tools ... design entry ...
simulation ...
synthesis ... because these tools are essential in reducing up front
design 
and development NRE costs.
Article: 15511
Subject: Re: Info about FPGA/PLD
From: Richard Guerin <guerin2@home.com>
Date: Sun, 28 Mar 1999 19:41:19 GMT
Links: << >>  << T >>  << A >>
Mike Roberts wrote:
> 
> FPGAs use a SRAM pass transistor that must be
> configured on power up.

True for SRAM based FPGAs (like Xilinx and Altera) ... not
true for anti-fuse based FPGAs (like Actel and QuickLogic).
The latter can exhibit some pretty low power consumption
characteristics.
Article: 15512
Subject: FIFO design
From: Jamil Khatib <mkhatib@Hplanet.planet.edu>
Date: Mon, 29 Mar 1999 00:10:52 +0300
Links: << >>  << T >>  << A >>
Hi

in this address you will find a design of a FIFO buffer to be
implemented on Xilinx xc400XL FPGA 

http://www.geocities.com/SiliconValley/Pines/6639/ip/fifo.html

Please I need your comments on this design

Thanks in advance
Article: 15513
Subject: Re: Free Xilinx Vendor Tools ... JBits
From: Steve Casselman <sc@vcc.com>
Date: Sun, 28 Mar 1999 13:43:05 -0800
Links: << >>  << T >>  << A >>
>
>
> What's JBits? URL?
>
>

http://www.xilinx.com/products/software/sx/sxpresso.html#JBITS

You can build up a bit stream from scratch (tedious but can be
automated with a Java program) or manipulate a M1 created
bit stream (much safer).


--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 15514
Subject: Re: Info about FPGA/PLD
From: "Mike Roberts" <mfroberts@mediaone.net>
Date: Sun, 28 Mar 1999 20:31:42 -0600
Links: << >>  << T >>  << A >>
I forgot about Antifuse based devices. Antifuse devices do offer low
quiescent current and are non-volatile (they are also very fast).  It would
seem like the best of both worlds.  Unfortunately, they have their drawbacks
as well.  They are one time programmable, program very slowing, don't scale
as easily as SRAM based FPGAs or E2CMOS and Flash based CPLDs.  The
non-reprogrammability seems to be the biggest drawback.  Xilinx tried
anti-fuse devices (XC80000) and was never able to mass produce them. The
future does not look bright for anti-fuse FPGAs.

Richard Guerin <guerin2@home.com> wrote in message
news:36FE8647.CD1C272@home.com...
> Mike Roberts wrote:
> >
> > FPGAs use a SRAM pass transistor that must be
> > configured on power up.
>
> True for SRAM based FPGAs (like Xilinx and Altera) ... not
> true for anti-fuse based FPGAs (like Actel and QuickLogic).
> The latter can exhibit some pretty low power consumption
> characteristics.


Article: 15515
Subject: Re: Info about FPGA/PLD
From: Richard Guerin <guerin2@home.com>
Date: Mon, 29 Mar 1999 02:48:39 GMT
Links: << >>  << T >>  << A >>


Mike Roberts wrote:
<snip>
> The non-reprogrammability seems to be the biggest drawback.  

In some market segments this is actually viewed as a desirable feature
along with design security (could you imagine the impact to national
security if the Serbs could extract crypto decoding implementation 
from  the recently downed F117A ?)

>The future does not look bright for anti-fuse FPGAs.

They have their niche market .... future is secure so long as 
aerospace and defense applications continue retargeting ASICS to
FPGAs.
Article: 15516
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: Richard Guerin <guerin2@home.com>
Date: Mon, 29 Mar 1999 03:04:58 GMT
Links: << >>  << T >>  << A >>


Joel Kolstad wrote:

> I'd be willing to bet that, if anything, ModelTech actually pays Xilinx some
> small amount to insert that CD.

Great ! Then MentorGraphics would likely be happy to become a proud
sponsor of Xilinx's new FREE Alliance download site ... in exchange for
a link to ModelSim eval download site, of course  ;-)
Article: 15517
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: Ray Andraka <randraka@ids.net>
Date: Sun, 28 Mar 1999 22:06:37 -0500
Links: << >>  << T >>  << A >>


Joel Kolstad wrote: I'd be willing to bet that, if anything, ModelTech actually
pays Xilinx some

> small amount to insert that CD.

I suspect that is the case too.

> Of course, the ActiveVHDL CD is the more useful one. :-)

The only problem I had with the Active VHDL package is that it doesn't handle
everything ModelTech does.  Particularly, I couldn't get it to pass an
unconstrained vector which I needed to create parameterized macros.  To be fair,
the guys at Aldec are looking at my sample of code to make it work.


--
-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: 15518
Subject: Re: Info about FPGA/PLD
From: Ray Andraka <randraka@ids.net>
Date: Sun, 28 Mar 1999 22:12:15 -0500
Links: << >>  << T >>  << A >>
Actually in that case, I would have preferred to have a SRAM based FPGA in
there, but not its PROM.  In the event of a incident where the equipment
might wind up in the wrong hands, simply removing power or hitting the
program pin would wipe out the SRAM and there would be no chance of the
enemy even getting one working copy to use or study.  In that case, the
FPGA would be programmed sometime before the mission, so that the only
copy of the program on board is the one in the FPGA.  Looked at in that
way, the SRAM FPGA provides the ultimate in security as long as you can
tolerate keeping it alive.

Richard Guerin wrote:

> Mike Roberts wrote:
> <snip>
> > The non-reprogrammability seems to be the biggest drawback.
>
> In some market segments this is actually viewed as a desirable feature
> along with design security (could you imagine the impact to national
> security if the Serbs could extract crypto decoding implementation
> from  the recently downed F117A ?)
>
> >The future does not look bright for anti-fuse FPGAs.
>
> They have their niche market .... future is secure so long as
> aerospace and defense applications continue retargeting ASICS to
> FPGAs.



--
-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: 15519
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sun, 28 Mar 1999 19:36:11 -0800
Links: << >>  << T >>  << A >>
Richard Guerin wrote in message <36FB3BB8.1FB30D4B@home.com>...
>What I'm suggesting is that Xilinx should go one step further in become
>the leading enabler of the FPGA development community by offering a free
>downloadable version of an Aliance-like tool ... no free ModelSim eval CD
....

I'd be willing to bet that, if anything, ModelTech actually pays Xilinx some
small amount to insert that CD.

Of course, the ActiveVHDL CD is the more useful one. :-)

---Joel Kolstad





Article: 15520
Subject: Re: Info about FPGA/PLD
From: Richard Guerin <guerin2@home.com>
Date: Mon, 29 Mar 1999 03:51:16 GMT
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> Actually in that case, I would have preferred to have a SRAM based FPGA in
> there, but not its PROM. 

Hmmm .... an interesting suggestion. However, as they say in the
business, "don't think that would fly (pun intended)"  ;-)

Your suggested approach assumes an ideal operating environment ... that
there would be no ACFT power interruption or other upset event during
the normal course of a mission. A weapon system like the F117 would be
required to survive in an extremely hostile environment (including
flying through nuclear fallout) and still be able to complete its
intended mission. I realize that this is not a typical consideration in
most lower-tech and consumer applications .... doubt that most FPGA
designers have to worry about passing environmental stress screening
(shake-and-bake) tests.
Article: 15521
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: "Mark Rogers" <markr14@hotmail.com>
Date: Sun, 28 Mar 1999 23:50:40 -0600
Links: << >>  << T >>  << A >>
Two reasons I know of.  One is they can use the revenue to create better
tools.  In the old days of 22V10's, it wasn't a big deal, but 1 million gate
FPGA's require a little more sophistication.  They can also use the revenue
to help fund their technical support for the tools, and the products
themselves.   Another reason is that they (vendors in general), are bundling
more and more 3rd party tools such as Synplicity with their tools and
probably have to pay licensing fees.

If you really want free tools, then work at a big company.  I don't pay for
any tools from any FPGA vendor.  And I make the FAE's come in and help me
install the software and get me started using it.  Another thing I do is
just crank out some VHDL, give it to a bunch of FPGA vendors and tell them
to fit it in there parts.  Smallest, lowest power, cheapest part wins the
design.   This has really worked well between Xilinx and Altera, man those
guys will fight it out.  We also get them to convert are old schematic based
designs to VHDL for us.

Mark

Richard Guerin <guerin2@home.com> wrote in message
news:36F479DF.71AC4AD9@home.com...
> Would anyone care comment on why Xilinx doesn't offer some type of free
> PC based vendor tools  ? ... it seems like every other FPGA/CPLD vendor
> does :-)


Article: 15522
Subject: virtex partial reconfiguration
From: Jamie Morken <foster@uvic.ca>
Date: Mon, 29 Mar 1999 03:34:04 -0800
Links: << >>  << T >>  << A >>
Hi,

Does anyone know why the new virtex parts are partially reconfigurable
by column?  Are they planning on allowing partial reconfiguration like
the XC6200 series had?  Thanks for your time.

Jamie Morken

Article: 15523
Subject: Re: Info about FPGA/PLD
From: z80@ds2.com (Peter)
Date: Mon, 29 Mar 1999 12:00:38 GMT
Links: << >>  << T >>  << A >>
This is true but generally you need to run a FPGA very fast indeed to
get its dynamic Icc to approach the static Icc of a similar size CPLD.

>If you take the quiescent
>(static) current away and compare FPGAs and CPLDs, you will see that they
>are comparable for the same gate count at the same frequency.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 15524
Subject: Re: Info about FPGA/PLD
From: "Mike Roberts" <mfroberts@mediaone.net>
Date: Mon, 29 Mar 1999 07:25:18 -0600
Links: << >>  << T >>  << A >>
The aerospace and defense market is definately niche and can not drive new
product development. It is also very hard to support a company on an
industry/market that is shrinking.  I re-iterate, the future does not look
bright for anti-fuse based FPGAs.

Richard Guerin <guerin2@home.com> wrote in message
news:36FEEA70.BF055A9F@home.com...
> They have their niche market .... future is secure so long as
> aerospace and defense applications continue retargeting ASICS to
> FPGAs.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search