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
2019JanFebMar2019

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 42975

Article: 42975
Subject: PCI bus software for Xilinx PCI core
From: Paul Smith <ptsmith@indiana.edu>
Date: Wed, 08 May 2002 15:49:41 -0500
Links: << >>  << T >>  << A >>
Greetings,

We're implementing a flash ADC data acquisition PCI card using a Xilinx 
XC2S50 to buffer samples.  We have the Xilinx PCI core implemented as a 
target only.

Under linux, we can see the card's configuration registers, the Xilinx 
vendor ID, base address registers, etc.

One base address register points to a group of control registers for the 
front end hardware which we can read and write with no problem.

So far, so good.

Another base register points to a data FIFO.  In our application, we 
don't know ahead of time how much data will be in this FIFO.  The hope 
was to poll this FIFO with a burst read. Most of the time the FIFO 
should be empty, so we want 0 words to be returned.  When the FIFO 
contains data we want to read all its words.  Since this can vary, we 
want to use the PCI STOP signal to have a target-initiated termination.

This seems to be much harder than we hoped.  We haven't figured out how 
to do a PCI burst read under linux.  A series of single reads sort of 
works, but hangs up the computer when there is no data in the FIFO.

We're having a lot of trouble trying to find out how the computer's 
mother board translates kernel calls to PCI bus transactions.  For 
example, what is the difference between a memory read (CBE 0110) and a 
memory read multiple (CBE 1100) ?  How does the PCI core know whether to 
  output S_SRC_EN ?

We have the MindShare PCI book that came with the Xilinx PCI core.  What 
  we really need is information on exactly how to write software which 
causes various things to happen on the PCI bus.  Any suggestions for 
other books, sample code, a software tool kit, etc. would be greatly 
appreciated.

Paul Smith
Indiana University Physics


Article: 42976
Subject: Does an EDIF schematic editor exist?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Wed, 08 May 2002 15:50:11 -0500
Links: << >>  << T >>  << A >>
Hi, I will like to know if such a thing as an EDIF schematic editor
exists.
Lately, I have been trying to convert my design (A PCI IP core) from a
one that needs to be synthesized with the rest of the design to a
netlist so that I can reduce the backend synthesis time and be able to
instantiate the IP core from a VHDL design. (The IP core is done in
Verilog, so I hate to redo the work for VHDL.)
The problem I have been experiencing was that (See: Duplicating IOB FFs
Without I/O Pads Being Inserted in XST, How can I get rid of I/O pads
from a netlist generated by XST? for details.) XST doesn't duplicate
output and OE (Output Enable) FFs unless I add I/O pads (I/O buffers) to
the design, but just to get the FFs duplicated, adding I/O pads to the
IP core causes problems when I instantiate it from the backend module.
(NGDBUILD will give me lots of errors because of duplicate I/O pads.)
Unfortunately, the latest version of XST (Ver. E.xx) no longer generates
an EDIF file, and instead generates an encrypted .NGC file, so I cannot
tinker with the netlist at all. (I resent Xilinx for changing that.)
Fortunately, I happened to have WebPACK ISE 3.3 in a CD-R, so I was able
to use the older XST (Ver. D.xx) which generates an EDIF file.
Of course, the older XST doesn't automatically duplicate FFs, so I had
to go into an EDIF file, and manually duplicate FFs, which I hate, but I
was able to duplicate some FFs by editing an EDIF file.
However, it is sort of time consuming to have to edit an netlist by a
text editor, so I was wondering, does an EDIF schematic editor exist
where I can edit Xilinx library primitives XST generates?
Obviously, I don't use schematics, and I am poor, so if it costs
something, I probably won't get it, but just for my information I will
like to know such a thing exists.
It will be nice if ECS schematic editor that comes with ISE WebPACK can
edit Xilinx library primitives of an EDIF file.




Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 42977
Subject: Re: FIFO
From: "Paul Butler" <Paul.Butler@ni.com>
Date: Wed, 8 May 2002 15:50:17 -0500
Links: << >>  << T >>  << A >>

"BÝrge Strand" <borges@ping.uio.no> wrote:
> I could need a FIFO . . . Spartan II

How about searching xilinx.com?

http://www.xilinx.com/xapp/xapp175.pdf
http://www.xilinx.com/ipcenter/catalog/search/logicore/synchronous_fifo.htm
http://www.xilinx.com/ipcenter/catalog/search/logicore/asynchronous_fifo.htm

Paul.Butler@ni.com





Article: 42978
Subject: Re: trace report
From: John_H <johnhandwork@mail.com>
Date: Wed, 08 May 2002 21:09:11 GMT
Links: << >>  << T >>  << A >>
Probably more important, if the clock goes through a DCM phase shift
relative to another clock you can end up with the source and destination
clocks giving you different values.  I believe this "PHASE" support
started with the 4.1i Xilinx tools and has certainly messed up my rising
edge, falling edge mix of logic in a couple spots.  If you don't do any
phase shifting and don't use negative clock edges you'll probably have
everything report as you expect relative to the 3.3i tools.

sanjay parekh wrote:

> Can anyone tell me what is the meaning of these two lines in a trace
> report -
>
> Source Clock: clk_c rising at 0.000ns
> Destination Clock: clk_c rising at 5.000ns
>
> My guess is that it is just specifying the period.  But if this clock
> goes through a buffer does it say otherwise.
>
> Thanks.
> -sanjay


Article: 42979
Subject: Re: PCI bus software for Xilinx PCI core
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Wed, 08 May 2002 21:09:32 -0000
Links: << >>  << T >>  << A >>
>Another base register points to a data FIFO.  In our application, we 
>don't know ahead of time how much data will be in this FIFO.  The hope 
>was to poll this FIFO with a burst read. Most of the time the FIFO 
>should be empty, so we want 0 words to be returned.  When the FIFO 
>contains data we want to read all its words.  Since this can vary, we 
>want to use the PCI STOP signal to have a target-initiated termination.
>
>This seems to be much harder than we hoped.  We haven't figured out how 
>to do a PCI burst read under linux.  A series of single reads sort of 
>works, but hangs up the computer when there is no data in the FIFO.

PCI isn't designed to work that way.

Think of it as memory.  You asked to read location xxx.  STOP
says not-right-now, try again later.  That "later" means right
away, a few machine cycles, perhaps after some other device has
used the PCI bus for another transaction.  The STOP signal never
gets back to the software.  The hardware retries until it gets
some data or maybe an error-abort timer goes off.

One suggestion is to include a status bit so you can tell the
software that the word it read was empty.

If you have a FIFO, you can read the number of words in the FIFO
(using a different address) and then read the right number of
data words.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 42980
Subject: Timing of XC2S200E-6FG456C compared to XC2S200E-6FG456I
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 May 2002 17:23:05 -0400
Links: << >>  << T >>  << A >>
Can anyone say with any certainty that the timing of an XC2S200E-6FG456I
will be the same as the XC2S200E-6FG456C?  I need to do a design for
both versions and we will be building boards with both versions of the
FPGA.  Some will actually be industrial boards, but sometimes we will
use the industrial versions of the FPGA on the commercial temp boards if
that is the FPGA we have on hand.  

Will I expect to see any differences in timing between the three
verisons of the board (comm chips run at comm temps, ind chips run at
comm temps and ind chips run at ind temps)?  I know the ind chips will
run better if kept within the comm temp range, but are the timing files
the same?  If I do a design that meets timing for the comm temp chip,
can I expect that to meet timing in the ind temp chip at either temp
range?  


-- 

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: 42981
Subject: Re: Timing of XC2S200E-6FG456C compared to XC2S200E-6FG456I
From: John_H <johnhandwork@mail.com>
Date: Wed, 08 May 2002 21:43:54 GMT
Links: << >>  << T >>  << A >>
Your question - I don't know the answer, I only have my suspicions - seems
to be whether the worst case timing numbers for an I suffix part match the
worst case timing numbers for the C suffix device.

For real compliance testing over all operating conditions, you need to run
your timing analysis at specified voltages and temperatures.  If the 25C
nominal voltages are the same for the commercial and industrial parts,
expect to see the timing different at the maximum ranges.  You can run the
speedprint utility with full part numbers and override for temperature and
voltage to make a comparison for yourself, assuming the timing numbers are
production.


rickman wrote:

> Can anyone say with any certainty that the timing of an XC2S200E-6FG456I
> will be the same as the XC2S200E-6FG456C?  I need to do a design for
> both versions and we will be building boards with both versions of the
> FPGA.  Some will actually be industrial boards, but sometimes we will
> use the industrial versions of the FPGA on the commercial temp boards if
> that is the FPGA we have on hand.
>
> Will I expect to see any differences in timing between the three
> verisons of the board (comm chips run at comm temps, ind chips run at
> comm temps and ind chips run at ind temps)?  I know the ind chips will
> run better if kept within the comm temp range, but are the timing files
> the same?  If I do a design that meets timing for the comm temp chip,
> can I expect that to meet timing in the ind temp chip at either temp
> range?
>
> --
>
> 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: 42982
Subject: Re: Timing of XC2S200E-6FG456C compared to XC2S200E-6FG456I
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Wed, 08 May 2002 15:25:25 -0700
Links: << >>  << T >>  << A >>
Good question, and here comes the good anwer:
There is only one speeds file for any part. The ac parameters are identical
for the commercial and industrial part. Because it has to guarantee the same
performance over a wider temperature range, the I part is better (faster),
but all performance numbers are the same.
This has been the rule in Xilinx since times immemorial, i.e. since 1985.

Peter Alfke, Xilinx Applications
===========================================
rickman wrote:

> Can anyone say with any certainty that the timing of an XC2S200E-6FG456I
> will be the same as the XC2S200E-6FG456C?  I need to do a design for
> both versions and we will be building boards with both versions of the
> FPGA.  Some will actually be industrial boards, but sometimes we will
> use the industrial versions of the FPGA on the commercial temp boards if
> that is the FPGA we have on hand.
>
> Will I expect to see any differences in timing between the three
> verisons of the board (comm chips run at comm temps, ind chips run at
> comm temps and ind chips run at ind temps)?  I know the ind chips will
> run better if kept within the comm temp range, but are the timing files
> the same?  If I do a design that meets timing for the comm temp chip,
> can I expect that to meet timing in the ind temp chip at either temp
> range?
>
> --
>
> 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: 42983
Subject: Re: Timing of XC2S200E-6FG456C compared to XC2S200E-6FG456I
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Wed, 08 May 2002 15:28:18 -0700
Links: << >>  << T >>  << A >>


John_H wrote:

> Your question - I don't know the answer, I only have my suspicions - seems
> to be whether the worst case timing numbers for an I suffix part match the
> worst case timing numbers for the C suffix device.

Yes they do, and that's the way the parts are tested. No ifs or buts.

Peter Alfke, Xilinx Applications


Article: 42984
Subject: Transistor Counts for Xilinx FPGAs
From: Steve Charlwood <s.m.charlwood@bham.ac.uk>
Date: Wed, 08 May 2002 23:49:59 +0100
Links: << >>  << T >>  << A >>
Hi all,

I'm doing some research into trends in programmable technologies, and 
would like to be able to compare the transistor counts of FPGAs and 
general-purpose microprocessors. However, finding data for the FPGAs is 
proving difficult. Does anyone have any reliable data for the transistor 
counts of Xilinx FPGAs newer than those listed below (and ideally, the 
XCV3200E and XC2V6000 devices)?

Xilinx XC4085XL = 16 million transistors
Xilinx XC40125XV = 25 million transistors
Xilinx XCV1000 = 75 million transistors

Note: this data comes from Xilinx's own literature.

I could estimate the transistor counts, but there would be uncertainty 
involved that I would like to avoid if possible.

Thanks,

Steve


Article: 42985
Subject: Re: Timing of XC2S200E-6FG456C compared to XC2S200E-6FG456I
From: John_H <johnhandwork@mail.com>
Date: Wed, 08 May 2002 22:57:30 GMT
Links: << >>  << T >>  << A >>
What I'm missing is... the two devices use the same speed files.  You can derate
for temperature.  If they're the same speed file, don't they give identical
results for max commercial temp?  So are the derating factors flat from
commercial max temp to industrial max temp?

I like your answer, it's just confusing my poor, addled gray matter.

It sounds like the only thing an industrial temp part will guarantee over a
commercial part "within the commercial temperature range" is an unknown better
margin.


Peter Alfke wrote:

> Good question, and here comes the good anwer:
> There is only one speeds file for any part. The ac parameters are identical
> for the commercial and industrial part. Because it has to guarantee the same
> performance over a wider temperature range, the I part is better (faster),
> but all performance numbers are the same.
> This has been the rule in Xilinx since times immemorial, i.e. since 1985.
>
> Peter Alfke, Xilinx Applications
> ===========================================
> rickman wrote:
>
> > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I
> > will be the same as the XC2S200E-6FG456C?  I need to do a design for
> > both versions and we will be building boards with both versions of the
> > FPGA.  Some will actually be industrial boards, but sometimes we will
> > use the industrial versions of the FPGA on the commercial temp boards if
> > that is the FPGA we have on hand.
> >
> > Will I expect to see any differences in timing between the three
> > verisons of the board (comm chips run at comm temps, ind chips run at
> > comm temps and ind chips run at ind temps)?  I know the ind chips will
> > run better if kept within the comm temp range, but are the timing files
> > the same?  If I do a design that meets timing for the comm temp chip,
> > can I expect that to meet timing in the ind temp chip at either temp
> > range?
> >
> > --
> >
> > 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: 42986
Subject: Re: Transistor Counts for Xilinx FPGAs
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 08 May 2002 16:36:41 -0700
Links: << >>  << T >>  << A >>
Steve,

2V6000 = 320 million

Will announce the others as they arrive.....

Austin

Steve Charlwood wrote:

> Hi all,
>
> I'm doing some research into trends in programmable technologies, and
> would like to be able to compare the transistor counts of FPGAs and
> general-purpose microprocessors. However, finding data for the FPGAs is
> proving difficult. Does anyone have any reliable data for the transistor
> counts of Xilinx FPGAs newer than those listed below (and ideally, the
> XCV3200E and XC2V6000 devices)?
>
> Xilinx XC4085XL = 16 million transistors
> Xilinx XC40125XV = 25 million transistors
> Xilinx XCV1000 = 75 million transistors
>
> Note: this data comes from Xilinx's own literature.
>
> I could estimate the transistor counts, but there would be uncertainty
> involved that I would like to avoid if possible.
>
> Thanks,
>
> Steve


Article: 42987
Subject: Re: OP-AMP in FPGA
From: mikeandmax@aol.com (Mikeandmax)
Date: 08 May 2002 23:45:54 GMT
Links: << >>  << T >>  << A >>
Jonathan!!!

>Lattice Semi have the ispPAC family which they acquired from a
>small, now defunct startup whose name I've forgotten.  It's a 
>configurable bag of gain blocks, filter blocks and suchlike 
>useful things.

ispPAC is an all LATTICE development, begun in 1995 - lot of work and effort
into making a digital CMOS process behave well enough for the designs to go. 
Devices have been in production and shipping since summer of 1999.

Zetex rolled their own also-
>Zetex have the TRAC range, marketed by their Fast Analog Solutions 
>division;

>Anadigm's FPAA devices look suspiciously like the programmable 
>analog parts that Motorola launched a few years ago and then 
>withdrew in unseemly haste

This is a clean assumption - after Motorola folded their effort, Anadigm got
their hands on it, and have made a go of it. >

thanks for mentioning us -

Michael Thomas
SFAE
Lattice Semiconductor

Article: 42988
Subject: Re: OP-AMP in FPGA
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 09 May 2002 11:49:25 +1200
Links: << >>  << T >>  << A >>
Roger King wrote:
> 
> Can one build an OP-AMP in an FPGA?

 No, but you can buy an op-amp in a SOT23 package, in
an analog optimised process, and with low noise supply connections.
-jg

Article: 42989
Subject: Re: Timing of XC2S200E-6FG456C compared to XC2S200E-6FG456I
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Wed, 08 May 2002 16:49:33 -0700
Links: << >>  << T >>  << A >>
Confusion, confusion.
Let's forget temperature derating for a moment.
Most delays get longer at higher temperature.
So the data sheet and the speeds file list a worst-case number as max delay. It
happens to apply to a  commercial part @ 85 degr, and equally well to an industrial
part @100 degr.
That was the original question.
The industrial part has the same timing over its wider range, as the commercial part
has over its narrower range.
Tomorrow  I'll explain temperature derating, which is a newfangled thing.

Peter Alfke, Xilinx Applications
====================================
John_H wrote:

> What I'm missing is... the two devices use the same speed files.  You can derate
> for temperature.  If they're the same speed file, don't they give identical
> results for max commercial temp?  So are the derating factors flat from
> commercial max temp to industrial max temp?
>
> I like your answer, it's just confusing my poor, addled gray matter.
>
> It sounds like the only thing an industrial temp part will guarantee over a
> commercial part "within the commercial temperature range" is an unknown better
> margin.
>
> Peter Alfke wrote:
>
> > Good question, and here comes the good anwer:
> > There is only one speeds file for any part. The ac parameters are identical
> > for the commercial and industrial part. Because it has to guarantee the same
> > performance over a wider temperature range, the I part is better (faster),
> > but all performance numbers are the same.
> > This has been the rule in Xilinx since times immemorial, i.e. since 1985.
> >
> > Peter Alfke, Xilinx Applications
> > ===========================================
> > rickman wrote:
> >
> > > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I
> > > will be the same as the XC2S200E-6FG456C?  I need to do a design for
> > > both versions and we will be building boards with both versions of the
> > > FPGA.  Some will actually be industrial boards, but sometimes we will
> > > use the industrial versions of the FPGA on the commercial temp boards if
> > > that is the FPGA we have on hand.
> > >
> > > Will I expect to see any differences in timing between the three
> > > verisons of the board (comm chips run at comm temps, ind chips run at
> > > comm temps and ind chips run at ind temps)?  I know the ind chips will
> > > run better if kept within the comm temp range, but are the timing files
> > > the same?  If I do a design that meets timing for the comm temp chip,
> > > can I expect that to meet timing in the ind temp chip at either temp
> > > range?
> > >
> > > --
> > >
> > > 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: 42990
Subject: Re: Transistor Counts for Xilinx FPGAs
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Wed, 08 May 2002 17:05:02 -0700
Links: << >>  << T >>  << A >>
One reason we are not too eager to volunteer these numbers is that they
often are being abused for a strange purpose, namely to calculate Mean Time
Between Failure (MTBF).
There still exists a misguided opinion, especially in military circles, that
transistor count directly affects (un)reliabilty.
Nothing could be further from the truth. Transistors well inside the chip
hardly ever fail, I/O transistors are far more likely to fail.

To say that an FPGA which may have many times more transistors than a
Pentium, would therefore be less reliable is a naive oversimplification at
best, total nonsense at worst.
(Now you heard my biased opinion).

At the upper end, we are still  well below 1000 million transistors ( a
billion in the US, a milliard in Europe).
That should not be too surprising: A 20 x 20 mm chip obviously has an area
of 400 million square microns, and a logic  transistor is smaller than a
square micron.

Peter Alfke, Xilinx Applications
================================
Steve Charlwood wrote:

> Hi all,
>
> I'm doing some research into trends in programmable technologies, and
> would like to be able to compare the transistor counts of FPGAs and
> general-purpose microprocessors. However, finding data for the FPGAs is
> proving difficult. Does anyone have any reliable data for the transistor
> counts of Xilinx FPGAs newer than those listed below (and ideally, the
> XCV3200E and XC2V6000 devices)?
>
> Xilinx XC4085XL = 16 million transistors
> Xilinx XC40125XV = 25 million transistors
> Xilinx XCV1000 = 75 million transistors
>
> Note: this data comes from Xilinx's own literature.
>
> I could estimate the transistor counts, but there would be uncertainty
> involved that I would like to avoid if possible.
>
> Thanks,
>
> Steve


Article: 42991
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: arast@inficom.com (Alex Rast)
Date: Thu, 09 May 2002 00:10:48 GMT
Links: << >>  << T >>  << A >>
In article <88b55ba7f36a94f98979589c8a3ee425.60722@mygate.mailgate.org>, "Guy Schlacter" <g.schlact@attbi.com> wrote:
>Alex -
..(deletia)
>I ...realize that you are a small
>company.  It is unclear the extent of your staffing and engineering
>capabilities
>but non the less it appears that you do not have the inhouse expertise
>for the
>customization and chip development. 
(Deletia)

I am certainly an expert on chip design and FPGA design and programming. 
However, I can't all do it by myself, of course, not unless I wish to spend 
more years than I've got (any chip design process is a major undertaking 
requiring multiple people simply to tackle the size of the data-entry 
proposition!)

However, I'm certainly NOT the expert on PCI. This is where we are looking for 
other people. Now, there are several unusual design concepts that we're 
considering, that we would like to run past a PCI expert, but only if that 
expert isn't the type to have preconceived ideas about what can or cannot be 
done. We want somebody with enough of an open mind at least to examine the 
possibility of a creative solution, when it's not immediately and 
categorically obvious that the proposed solution is impossible, enough to give 
us input on whether that solution is productive to implement. Also, someone 
intelligent enough to recognize the difference between knowing something is 
impossible or impractical and not knowing enough to be able to tell if the 
proposal is impossible/impractical. He who can recognize that difference 
should be wise enough to be able to start finding out, either by asking 
others, reading, testing, or whatever, and then coming back to us with his 
recommendations, rather than just dismissing the idea as impossible out of 
hand. 

>...HOwever here are some of
>the
>facts that I took into consideration for these suggestions...
>a.  you are a startup and no matter how well funded - cash is king

If that is unequivocally true why try to build a startup company or do 
anything innovative at all? It sounds to me like you believe no startup can 
ever succeed, that they are all doomed to be squashed by big corporate 
entities. 

>b.  not every great idea succeeds (lots of competition for wireless
>broadband)

Not every great idea fails, either. 

>c.  volumes are not yet truely defined unless you have minimums based on
>a contract with cusotmer

Of course volumes aren't truly defined. We know that. Everything that we 
state on volumes is mostly conjecture. Nonetheless manufacturers have to have 
some targets, in order to have "visibility" for production. We do 
additionally have preorders that we are in part factoring in.

By the way, don't get me wrong - we're not so blind as to believe we can't 
fail simply based on the strength of our idea. All startups involve risk and 
we recognize and respect that. But we also believe that we must proceed 
assuming to a certain extent that we will succeed because without that 
assumption you can't get anything done because you can make no future plans.

>d.  luckily PCI is a fairly mature spec and many people have experience

recommendations:
1.  inficon should create the high level specification for what needs to
be developed for the whole chip or chip-set

Minor spelling note - you misspelled the name "Inficom" (I point this out for 
humor - consider a name like "Inficon" - "Yeah...I've got the contracts for 5 
Brooklyn Bridges I'd like to sell you...)  :-)

2.  implement a stagged solution that will reduce risk and ultimately
maximize profit

What we want to see more than anything else is maximized *value* to the 
customer. We see what the customer will want - drop-in, turnkey networking 
that will instantly work with a minimum of configuration on his part, and will 
be reliable for many years. That's what we want to get out of the chute. Our 
objective is a product that in the first generation doesn't scream "beta" - 
buggy, slow, unreliable, difficult to install, riddled with incompatibilities, 
etc. 
 
3.  for ultimate risk reduction use FPGA technology for prototypes (hash
out any bugs/spec changes) into initial-mid production

We also lean in that direction for early release. The benefits are enormous.

4.  rather than spin it yourself, obtain a Fixed Bid from an FPGA
consultant partner program
    ...

I'm looking for all the options. Because of the nature of our design, I think 
there are some integration issues which *will* require custom tweaking of 
existing cores - my guess is that it'll be difficult simply to drop in a 
canned core exactly as is. I also suspect that whoever does this work, they 
will end up having to coordinate so closely with me that they'll end up 
effectively being in-house, even if they're only working here as a contract 
consultant. I'm willing to do the tweaking myself if necessary, but would 
rather have someone else do it.

5.  You should consider the initial project/bid from the consulting firm
to just include development of the low level spec such that
    risk is further reduced and better fix-bid can be presented for full
implementation

Development of a low-level spec would almost certainly have to be a joint 
project between me and the developer. I don't know how realistic it would be 
to make it a fixed-bit situation. I think if it were an external person rather 
than an internal hire, we'd need to use some sort of cost-reimbursement 
contract.

6.  involve your local FPGA vendor's sales teams

We've already done so. They've provided some help but most of the technical 
questions I ask go right over the heads of even the local senior FAE's. 
Usually I end up having to talk to a senior factory engineer.

7.  once the high level spec and other details have been worked through,
estimate the size of the
    actual FPGA device you will need and its embedded resources (ask
consultant)

We've got some ballpark numbers on that.

8.  ask your FPGA vendor to provide you quotes for different volume
levels - specify the time fram for each volume level too

And we've got ballpark pricing as well.

9.  ask your FPGA vendor what other suggestions they could make to
further reduce solution cost - example Altera Hard Copy
(non-programmable reduced cost) or
    or Xilinx Easy Path (reduced cost but still needs configuration)

Usually our questions involve not so much solution cost but instead solution 
flexibility - what things the solution will and will not allow us to do.

10. ask about IP source code - I know Altera will provide a quote if you
do need to ultimately go asic

This approach should reduce Inficon's risk yet provide an optimum manner
to implement your design needs,
reduce both technical and cost risks, minimize direct personnel
expenses, and maximize ultimate profits.

Many people jump to the conclusion that an asic would be best here since
you mentioned Millions of units.
However, being that it appears that you have unproven technology, your
specs may change or evolve which
is much better suited toward FPGAs especially since time to market will
likely be important too.

I likely forgot to mention something but it is "after hours" :-)

We aren't particularly strong on ASICs either, not yet. Our feel is that it is 
still much too early to do an ASIC regardless of projected volumes. We lean 
towards high-volume FPGA's for the moment.

Alex Rast
arast@inficom.com
arast@qwest.net

Article: 42992
Subject: Re: Does an EDIF schematic editor exist?
From: Russell <rjshaw@iprimus.com.au>
Date: Thu, 09 May 2002 01:03:18 GMT
Links: << >>  << T >>  << A >>
You could open the design in floor-planner, write the constraints
to a .ucf file, then edit the LOCs to RLOCs and a couple of other
things. That way, you can instantiate the core as a soft macro
(RPM) with floor-planning intact. The PAR tools should just do
the signal routing after that. You can graphically create a RPM
using group/bind in floor-planner, but unfortunately, that
process doesn't currently work in hierarchial projects.

Kevin Brace wrote:
> 
> Hi, I will like to know if such a thing as an EDIF schematic editor
> exists.
> Lately, I have been trying to convert my design (A PCI IP core) from a
> one that needs to be synthesized with the rest of the design to a
> netlist so that I can reduce the backend synthesis time and be able to
> instantiate the IP core from a VHDL design. (The IP core is done in
> Verilog, so I hate to redo the work for VHDL.)
> The problem I have been experiencing was that (See: Duplicating IOB FFs
> Without I/O Pads Being Inserted in XST, How can I get rid of I/O pads
> from a netlist generated by XST? for details.) XST doesn't duplicate
> output and OE (Output Enable) FFs unless I add I/O pads (I/O buffers) to
> the design, but just to get the FFs duplicated, adding I/O pads to the
> IP core causes problems when I instantiate it from the backend module.
> (NGDBUILD will give me lots of errors because of duplicate I/O pads.)
> Unfortunately, the latest version of XST (Ver. E.xx) no longer generates
> an EDIF file, and instead generates an encrypted .NGC file, so I cannot
> tinker with the netlist at all. (I resent Xilinx for changing that.)
> Fortunately, I happened to have WebPACK ISE 3.3 in a CD-R, so I was able
> to use the older XST (Ver. D.xx) which generates an EDIF file.
> Of course, the older XST doesn't automatically duplicate FFs, so I had
> to go into an EDIF file, and manually duplicate FFs, which I hate, but I
> was able to duplicate some FFs by editing an EDIF file.
> However, it is sort of time consuming to have to edit an netlist by a
> text editor, so I was wondering, does an EDIF schematic editor exist
> where I can edit Xilinx library primitives XST generates?
> Obviously, I don't use schematics, and I am poor, so if it costs
> something, I probably won't get it, but just for my information I will
> like to know such a thing exists.
> It will be nice if ECS schematic editor that comes with ISE WebPACK can
> edit Xilinx library primitives of an EDIF file.
> 
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)

Article: 42993
Subject: More C things
From: Russell <rjshaw@iprimus.com.au>
Date: Thu, 09 May 2002 01:21:26 GMT
Links: << >>  << T >>  << A >>
http://www.eetimes.com/story/OEG20020507S0033

Article: 42994
Subject: Re: Transistor Counts for Xilinx FPGAs
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 9 May 2002 02:35:26 +0100
Links: << >>  << T >>  << A >>
Steve Charlwood wrote

> I'm doing some research into trends in programmable technologies, and
> would like to be able to compare the transistor counts of FPGAs and
> general-purpose microprocessors. However, finding data for the FPGAs is
> proving difficult. Does anyone have any reliable data for the transistor
> counts of Xilinx FPGAs newer than those listed below (and ideally, the
> XCV3200E and XC2V6000 devices)?
>
> Xilinx XC4085XL = 16 million transistors
> Xilinx XC40125XV = 25 million transistors
> Xilinx XCV1000 = 75 million transistors
>
> Note: this data comes from Xilinx's own literature.

At a DAC panel two years ago a "Very High Up" Xilinx guy claimed
that the high-end chips in design (VirtexII, 10K?) have 500M
transistors.  He also claimed that current products run at 50
transistors per (marketing) gate, which fits in with the above.





Article: 42995
Subject: Re: Does an EDIF schematic editor exist?
From: "Steve Casselman" <sc.nospam@vcc.com>
Date: Thu, 09 May 2002 01:41:17 GMT
Links: << >>  << T >>  << A >>
You can try xdl (xilinx design language). xdl -ncd2xdl will give you a text
file of the design. You can edit it and change it back to ncd (native
circuit description) with xdl -xdl2ncd. Then you use it like a linkable
module.


Steve


> Unfortunately, the latest version of XST (Ver. E.xx) no longer generates
> an EDIF file, and instead generates an encrypted .NGC file, so I cannot
> tinker with the netlist at all. (I resent Xilinx for changing that.)




Article: 42996
Subject: Re: More C things
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 09 May 2002 14:17:33 +1200
Links: << >>  << T >>  << A >>
Russell wrote:
> 
> http://www.eetimes.com/story/OEG20020507S0033

 I also came across this recently,

http://www.research.microsoft.com/fse/asml/

and it seemed to me, this could have FPGA applications.

 A key weakness of C, is the sequential nature of all descriptions,
and the fact that FPGA "C's" are not C at all, but are some
'variant of the C programming language' - they seem more keen
on getting the magic buzzword C in there, than in how it can be used
practically. Throwing thousands of HW novice C coders at FPGAs sounds
more a problem than a solution :-)

 ASML is inherently parallel, until 'step' in invoked, and thus
the SAME source could potentially target an OpCode or FPGA at runtime.

This from the overview
> It is only after a step has been made that the new values 
> become visible. 
> In general, a computation in AsmL is not sequential unless 
> explicitly marked as being so.

 ASML would encourage 'sea of CPU' innovations on the PC, as well as
FPGA implementations.
 Because it has a path to compile -> Runs on a PC, that also gives a
Simulation path, to verify the logic on FPGA.

 Comments ?

 Jim G.

Article: 42997
Subject: Re: Timing of XC2S200E-6FG456C compared to XC2S200E-6FG456I
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 08 May 2002 23:12:26 -0400
Links: << >>  << T >>  << A >>
That was what I was hoping.  I have a broker offering to sell me a
number of these devices from a manufacturer's overstock, but they are
industrial temp.  To make it worthwhile, I would need to use them on
both the comm and ind versions of the board.  I just wanted to make sure
I would not have any problems.  

Now to see if I can get a better price than what disti will give.  


Peter Alfke wrote:
> 
> Good question, and here comes the good anwer:
> There is only one speeds file for any part. The ac parameters are identical
> for the commercial and industrial part. Because it has to guarantee the same
> performance over a wider temperature range, the I part is better (faster),
> but all performance numbers are the same.
> This has been the rule in Xilinx since times immemorial, i.e. since 1985.
> 
> Peter Alfke, Xilinx Applications
> ===========================================
> rickman wrote:
> 
> > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I
> > will be the same as the XC2S200E-6FG456C?  I need to do a design for
> > both versions and we will be building boards with both versions of the
> > FPGA.  Some will actually be industrial boards, but sometimes we will
> > use the industrial versions of the FPGA on the commercial temp boards if
> > that is the FPGA we have on hand.
> >
> > Will I expect to see any differences in timing between the three
> > verisons of the board (comm chips run at comm temps, ind chips run at
> > comm temps and ind chips run at ind temps)?  I know the ind chips will
> > run better if kept within the comm temp range, but are the timing files
> > the same?  If I do a design that meets timing for the comm temp chip,
> > can I expect that to meet timing in the ind temp chip at either temp
> > range?
> >
> > --
> >
> > 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

-- 

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: 42998
Subject: Re: DDR reference design
From: "bob elkind" <eteam@aracnetfoofoo.com>
Date: Thu, 09 May 2002 04:01:07 GMT
Links: << >>  << T >>  << A >>
Anyone out there have a pinter to a reference DDR design (or IP) they care
to recommend ?

Bob Elkind, eteam

"Spam Hater" <spam_hater_7@email.com> wrote in message
news:3cd933cf.3018963@64.164.98.7...
>
> Xilinx has two DDR reference designs available for free.
>
> And (almost) worth every penny.
>
>
>
> On 8 May 2002 00:45:00 -0700, eyals@hywire.com (Eyal Shachrai) wrote:
>
> >Hi ,
> >
> >I'm working on a project which involves a xilinx's virtex-ii fpga.
> >the core of this fpga will run with a 125 MHz clock and interface with
> >a 250 MHz data rate DDR SRAM.
> >I would like to know whether xilinx have a reference design of a DDR
> >SRAM controller. and if not , would it be smart to use the QDR
> >referance design (xapp 262) with some modifications , as a DDR
> >controller?
> >
> >Thanks
> > Eyal.
>



Article: 42999
Subject: Issue with X_SUH (using 4.1 sp 3)
From: vchittap@hotmail.com (Venu)
Date: 8 May 2002 21:58:06 -0700
Links: << >>  << T >>  << A >>
Hi,

  I am having a problem in verilog back-annotated simulations as
described below.Many thanks to anyone who can suggest a workaround.
Everything was O.K
with earlier versions of Xilinx SW and hence design issues are ruled
out.

  In my design , I take Clk_66 as input and internally generate
Clk_132 using
  DCM and external feedback.
  Some of the I/O's of FPGA are driven by logic running at Clk_66
while
  some other by logic running at Clk_132. My problem is that 
  Xilinx verilog writer has added X_SUH elements for all the I/O's
with clk as
  Clk_66..This is resulting in a setup violation being reported for
all Clk_133
  inputs. The PAR does not report any static timing violations. 

  Please let me know if anyone has encountered something similar.

Thanks
Venu



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
2019JanFebMar2019

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