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 71950

Article: 71950
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 04 Aug 2004 10:09:10 -0700
Links: << >>  << T >>  << A >>
 
> Gupta <gupg@hotmail.com.NOSPAM> wrote
>> 
> The questions are:
> - Speed
> - IO number
> - IO levels
> - Package (-size)
> - Area (usability of cells, e.g. Xillinx wouldn't allow you to use
> 100% of the cells)
This is utter nonsense. There is nothing wrong with using 100% of the logic
resources, if the routing structure supports this. And that depends on the
design style. Newer families have considerably more routing than the old
ones. Whether a design is logic- or routing-limited has nothing to do with
the particular manufacturer.

I am not really paranoid, but our dear competitor has recently cranked up
the marketing spin machine, believing that mudslinging might be productive.
It is not, not even in politics.
When you listen to a new product presentation where 40% of the material
talks about the "bad" competitor, draw your own conclusions. Are they afraid
?
Let's be positive. We all have good products to promote. Spreading lies
about the competition is counter-productive.

Peter Alfke 


Article: 71951
Subject: Re: Xilinx Spartan-3 Supply Issues?
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 4 Aug 2004 10:11:20 -0700
Links: << >>  << T >>  << A >>
"Gordon" <elf_ster@hotmail.com> wrote in message
news:4a2e9945.0408032023.4422fe43@posting.google.com...

[snip]

> My concerns are for moving things to production.  To be totally honest
> with you, this is the first I've heard of the status of the 3S50ES
> part -- I was told that Avnet already has stock on them!
>
> I'll be sure to confirm part numbers with them.

Avnet likely does have some XC3S50 ES devices in stock.  If not, they can
easily obtain them for you.

> In the mean time -- I'll have to admit that the Spartan IIE appears to
> be a better fit for the application (3.3 compatibility required,
> possible 5v inputs, no need for two LDOs) as it's not logic or
> computationally intensive.  It's just too bad it costs more than the
> 3S50ES part!

Just to be clear, Spartan-3 FPGAs support 3.3V I/O.  Likewise, you can
interface a Spartan-3 I/O to a 5V input signal using a 300 ohm or greater
series current-limiting resistor.  Essentially, you want to limit the
voltage at the pin to less than 4.05V and the current to roughly less than
10 mA.  The goal is to keep the I/O diodes off.

The Spartan-3 can drive a 5V device assuming that the device has TTL-style
inputs and that the FPGA I/O uses a 3.3V supply.

You are correct that Spartan-3 provides lower cost per gate and lower cost
per I/O than comparable devices.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC



Article: 71952
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: Gupta <gupt@hotmail.com.NOSPAM>
Date: 04 Aug 2004 10:12:28 -0700
Links: << >>  << T >>  << A >>

Thanks for your reply Thomas.  I guess I should ask the question in a
different way: for devices from different vendors with the same number
of gates, will I get better performance and/or cost from a Flash or a
SRAM based FPGA ?  Also, I assume that the comment about usability of
Xilinx cells being low is related to routability ?  Is it any better
with the Altera/Actel etc parts ?

Thanks
Sumit

Article: 71953
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 04 Aug 2004 10:22:03 -0700
Links: << >>  << T >>  << A >>
Here is a slightly biased comment:
The reason that we do not offer Flash-based FPGA has to do with price and
performance. If Flash is included, the process is inevitably more
old-fashioned and more complex, which means lower performance and higher
cost per function. In our mind, that outweighs any advantage of on-chip
Flash for the majority of applications.
Obviously, there is always a niche where priorities are different...
Peter Alfke

> From: Gupta <gupt@hotmail.com.NOSPAM>
> Organization: University of California, Irvine
> Newsgroups: comp.arch.fpga
> Date: 04 Aug 2004 10:12:28 -0700
> Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
> 
> 
> Thanks for your reply Thomas.  I guess I should ask the question in a
> different way: for devices from different vendors with the same number
> of gates, will I get better performance and/or cost from a Flash or a
> SRAM based FPGA ?  Also, I assume that the comment about usability of
> Xilinx cells being low is related to routability ?  Is it any better
> with the Altera/Actel etc parts ?
> 
> Thanks
> Sumit


Article: 71954
Subject: Re: Spartan 3 errata and pricing
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 4 Aug 2004 10:32:52 -0700
Links: << >>  << T >>  << A >>

"Krishna Kumar" <krishk24@gmail.com> wrote in message
news:e23e0547.0408040741.23cc184e@posting.google.com...

[snip]

> I tried restarting my browser but to of no avail. Can anybody send me
> the errata for Spartan 3? If there is no errata for the device
> XC3s1000 FG456, is it safe to assume that the device is into
> production and NOT Engineering Samples?

The errata for the XC3S1000 essentially says that there are no know issues.

I reported the problem that you encountered to our web team.

Just to be clear, the XC3S1000 is presently only available with an "ES"
marking, indicating that the devices are "Engineering Samples".  The full
production release on the XC3S1000 happens later this month (August 2004).
At this stage, there is little if any difference between the two other than
the non-ES devices are fully qualified for production.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC



Article: 71955
Subject: Re: On-Chip Oscillator
From: jdelaere@altera.com (Joe DeLaere)
Date: 4 Aug 2004 10:57:35 -0700
Links: << >>  << T >>  << A >>
dhruvish@gmail.com (Drew) wrote in message news:<ad2011c0.0407270952.23895c31@posting.google.com>...
> Hello Guys,
> 
> Have anybody tried to make On-Chip Oscillator on Altera EPLD/CPLD? I
> am using Altera Max family parts. I was wondering we can program it
> using VHDL? Another question I have is, How do I reduce the Rise Time
> of clock output from CPLD? I need rise time of < 2ns. I need external
> circuitry but not sure what?
> 
> Feedback please!
> Drew

The Altera MAX II CPLD family does have a general purpose on-chip
oscillator.  The on-chip oscillator is part of the User Flash Memory
block feature but is available as a general purpose clock for the core
logic or off-chip.  The frequency variation on this oscillator is
between 4.6 and 7.4 MHz.  See the MAX II handbook, chapter 2 page 24
and chapter 10 page 7 for more information.

http://www.altera.com/literature/lit-max2.jsp

Article: 71956
Subject: Re: Best tool(s) for filter float->fixed->VHDL flow?
From: Elliot Schei <Elliot.Schei@xilinx.com>
Date: Wed, 04 Aug 2004 11:17:33 -0700
Links: << >>  << T >>  << A >>
Hi Mark

Xilinx's System Generator for DSP has been designed to do exactly this.
Sysgen will allow you to design your entire system in the Simulink
environment
where you can use all the sinks/sources available in the Simulink library
to
analyze your design.  The Sysgen gateway blocks handle the conversion from

floating to fixed point, and it is easy to simulate quantization effects
and see
how the design is affected by using different data/coeff bit widths.

Sysgen comes with libraries that contain DDC, CIC DaFIR, MACCFIR blocks
and many other dsp blocks, but it is also easy to build your own library
out of lower level blocks.  You can easily build custom IIR filters for
example,
and semi-parallel filters that make the best use of available clock cycles
out of
adders/shift registers/multipliers etc.

There was some concerns raised about the resulting VHDL that is produced,
will it perform as well as hand written VHDL?  Well, here is how we
approach
this problem:  First, for most of the sub-components in a design, an
optimized
netlist will be generated from the Core-Generator tool.  These netlists
map very
efficiently to the fpga architecture and use relative placement
constraints to ensure
consistent timing behavior.  Second, if there is a portion of the design
that you feel
could be more efficientlly implemented by hand written VHDL or Verilog,
then the
Sysgen tool provides a method for black boxing this HDL so that it can be
incorporated
into the larger design.

The appearance of the resulting VHDL may be bloated, but the actual
performance
is bound more by the max fpga clock rate vs sample rate, and how well you
make use
of hardware folding and pipelining techniques in your design.

Hope this helps,
Elliot





Mark wrote:

> I've got a minor DSP/comm task to put in an FPGA:
>
> Complex demod to baseband, CIC+decimate+FIR LPF chain, magnitude
> estimate, some FSK and DPSK data to interpolate, correlate and
> extract, plus other sundry tasks.
>
> I'd like to model this all in untimed/behavioral floating-point, have
> a quick way to evaluate filtering options (including IIR, varying
> lengths and structures/forms) and quantization effects, with automatic
> conversion to a somewhat optimal fixed-point implementation that a
> tool can automatically write out as VHDL (RTL, not behavioral).
> Parameterizable block diagram entry is a plus. Probes/sinks with FFT
> and time plots and file writes at nodes of interest are also
> desireable. (SUMMARY: design/analyze at high level, let tools do
> dirty, low-level work.)
>
> Maybe I ask too much ;-) but it seems like this is such a common
> problem and flow that solutions would abound. However, I've been out
> of the DSP world for a while, and don't know what the best, cheapest,
> or most productive tool options are...
>
> What would the gurus of comp.dsp and comp.arch.fpga suggest?
>
> I have access to MathCad, Matlab (with FDAT), Simulink, and possibly
> LabView (National Instruments?) and (Cocentric System Studio (Synopys)
> but am not fluent with them.
>
> I've entered the design in Cadence/CoWare's SPW, but am getting
> frustrated with it -- not as easy to explore different architectures
> as I had hoped.
>
> I suppose Ptolemy is an option, if the learning curve is not
> staggering. Agilent has some Ptolemy add-ons for fixed-point analysis
> and optimization, but they're not free or in my company's budget for
> this project.
>
> Any and all constructive suggestions are very much appreciated; thanks
> in advance...
>
> MarkJ


Article: 71957
Subject: ES vs production
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 04 Aug 2004 11:40:50 -0700
Links: << >>  << T >>  << A >>
All,

Steve may not be in a position to elaborate, but I will.

"Engineering Sample" can, and does mean different things.  We are 
working on a way to be more communicative, but until we have a plan that 
we know works, we have to wait.

In the meantime, understand that ES means different things in time.

It first means that the part has undergone a basic level of testing, for 
both functionality and speed, but we have not qualified the process, not 
performed the ESD testing, and do not have the guaranteed numbers in the 
datasheet yet (TBD's or missing max's etc.).

That is pretty obvious:  we just do not know, so we let you know what we 
know (errata if any), and what we do not know.

Then, after the first part gets its all of its verification and 
characterization done, but the test program isn't complete, and/or the 
qualification program isn't done (it just takes time in the 'easy bake' 
oven) we still have to make the part as something other than production. 
  This is typically 14 weeks after first announced ES.  For example the 
Virtex 4 LX25 is shipping ES now, and is ~ 7 weeks old.  In another 7 
weeks, it will be old hat, and what we know list will be very long 
indeed, and what we do not know list will be at 0 items.  What we don't 
know that we don't know will also be a very short list, as these end up 
being found by customers (so we intentionally test the daylights (and 
nighlights) out of it).

After that, when parts are awaiting the final crossing of it's and 
dotting of i's in the reports, it is still marked ES.

So, if I wanted to know how confident I should be about a part, I would 
find out how long it has been since any part in the family first 
sampled.  If that is greater than 14 weeks, then I would be pretty 
confident that what is disclosed (if an errata at all) is complete, and 
99%+ accurate.

Once the qual report is done (available from our QA group, and posted on 
the website when a part goes into production), I would be totally confident.

Austin

Article: 71958
Subject: practical Virtex2 output buffer speeds
From: "Robert Sefton" <rsefton@nextstate.com>
Date: Wed, 4 Aug 2004 11:56:02 -0700
Links: << >>  << T >>  << A >>
Is it documented anywhere what the practical upper limits are, in terms of Mbps, for the various Virtex2 output buffer
types? For example, if I need to output a 600MHz clock (effectively 1.2Gbps), do I need to use LVDS or HSTL, or can a
FAST 3.3V CMOS output buffer handle it? I don't have the luxury of running HSpice sims, but can I extract this
information from any of the buffer models available from Xilinx?

Thanks,

Robert



Article: 71959
Subject: Re: Matlab/Simulink - System Generator HDL Co-Simulation
From: Elliot Schei <Elliot.Schei@xilinx.com>
Date: Wed, 04 Aug 2004 12:14:31 -0700
Links: << >>  << T >>  << A >>


Mukesh wrote:

> I am using Mathworks Simulink and Xilinx ISE tools for digital designs
> related to wireless communications. People who are using this design
> flow are requested to answer/ share their experience. The
> descreptionof my problem is as follows:
>
> I am using Xilinx black box in a Simulink Model and am using my VHDL
> code for its hardware implementation. The idea is to use the Simulink
> model  as a test bed for checking my hardware model for Wireless/ DSP
> based algos. I have successfully checked the behavioral simulation of
> my Code using HDL Co-simulation. The next stage in my design flow is
> to take it to the target Xilinx FPGA device and complete synthesis and
> place and route. At this stage, I want to go back to my Simulink model
> and use it to test my placed and routed model (now available in the
> form of flat netlist with Xilinx Simprims and SDF file (timing info
> file). I am able to verify post PAR outside Simulink by using my own
> test bench and controlling the clock myself in it.
>
> I want to do the same with the simulink model and check the results in
> simulink environment. Now the problem is:
>
> 1) How to control the clock that is generated automatically, whenever
> the simulation is started from within simulink. I dug into the files
> that are generated by Simulink for making a simulation model for HDL
> Co simulation, and found that it generated the clock with period 6.25
> ns always. Question is that is it possible to change this clock
> period.
>
> 2) How to link the SDF file in the simulation model that is generated
> from within Simulink for HDL Co simulation, for doing Post PAR
> simulation with simulink data.
>
> 3) If all above is not possible, then is there any way to make a test
> bench with the simulink generated data (the data that is available
> right after the gateway blocks). If this is possible then I can test
> my model outside simulink in modelsim environment.
>
> Thanks,
>
> Mukesh.

Hi Mukesh

Here are some answers to your questions:

1) I think you are referring to the timing constraints that Sysgen is
creating during
generation.  The actual clock will be provided from an external source,
either a
from a testbench stimulus, or in hardware from some oscillator feeding the
clock pin.
In Sysgen you specify how the Simulink sample period relates to the
hardware
clock, then Sysgen writes timing constraints based on what you specify.
The purpose
of the timing constraints are to ensure that the design will work properly
for a given
clock frequency.  You can change the clock source to be of any frequency
that you
want, but to be sure that the design will work properly it is a good idea
to test the
design in a timing simulation using constraints specific to the desired
operating frequency.
If you set up a variable in Simulink that represents your sample period,
then it will be
very easy to re-define the variable in Matlab which will update the design
to work at
different sample rates.  Re-generating the design will then write out new
timing constraints,
or you can directly modify the constraints in the .XCF file that is
written into the project
directory.

2) Simulink is only a behavioral simulation environment.  The HDL Co-Sim
that is done
in the Simulink environment will be a behavioral simulation.  If you want
to use SDF
information then you will need to do timing simulations outside of
Simulink.  The good
news is that Sysgen will automatically create a testbench for you that can
be used for
timing simulations.  This answers your question below....

3) Yes.  When you double click on the Sysgen Token to generate, there is
an option
to tell Sysgen to generate a testbench.  This takes any data that is
coming into a gateway
in block and writes the data into a text file.  This text file is then
read in by a VHDL testbench
so the same inputs that are driving the Simulink design will now be used
as stimulus when
simulations are done using a standard HDL simulation tool.

If you have more questions about this then I encourage you to open a case
with Xilinx's hotline:
http://www.xilinx.com/support/clearexpress/websupport.htm
http://www.xilinx.com/support/techsup/northam.htm

Best Regards,
Elliot


Article: 71960
Subject: Virtex 2 Pro OCM question
From: wpiman@aol.com (MS)
Date: 4 Aug 2004 13:05:25 -0700
Links: << >>  << T >>  << A >>
We are using a V2Pro with the embedded PowerPC.  We have several
packet queues that go back and forth between the processor and the
custom fast path logic.  We have decided to implement these in Data
OCM block memories.

The issue we are having is that when we goto add a DSOCM- it generates
one memory (not necessary one block memory)- with Port A going to the
DSOCM IF and port B going to the logic.  This is great for one queue-
but doesn't work for multiple queues.

We then looked at the generated code (HDL directory of our project)
and figure we can edit the dsocm_bram_elaborate and wrapper to do what
we want.  This should be fine- but whenever we change the MHS file
and/or compile it- it will write over these changes.  The process
would become more manual.

We would like to be able to edit this blockRam so that the MHS file
references this.  I looked in the EDK/hw/XilinxProcessorIP/pcores
directory at the bram block- and there is no HDL to edit.

Has anyone else done something similar?  I have a few paths I want to
go down- but if anyone can eliminate or suggest one I am all ears.  My
next thing will be to edit a copy of the dsbram_if_cntl HDL and plop a
few block Memories directly into it and see if this works- but again-
I am open to suggestions.

Article: 71961
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 04 Aug 2004 16:41:31 -0400
Links: << >>  << T >>  << A >>
Gupta wrote:
> 
> Thanks Rick.  You are right that if the size of the transistor does not
> reflect, I shouldn't care on the cost metric.  But what about the
> performance metric ?  Does smaller size of the configuration memory
> improve the performance, because the size of the FPGA will be smaller
> for the same number of gates (assuming that its in the same process
> technology).

Again, if performance is what you care about, then look at the
performance numbers.  The problem with looking at the configuration cell
size (or any other single feature of an FPGA) to gauge various
performance characteristics (price, speed, etc) is that they are
controlled by many other aspects of an FPGA.  If all other aspects were
the same, then that one feature could be a good indicator, but the other
aspects also change a great deal.  

So if you care about speed, then look at the speed!  

-- 

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: 71962
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 04 Aug 2004 16:48:08 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> 
> > Gupta <gupg@hotmail.com.NOSPAM> wrote
> >>
> > The questions are:
> > - Speed
> > - IO number
> > - IO levels
> > - Package (-size)
> > - Area (usability of cells, e.g. Xillinx wouldn't allow you to use
> > 100% of the cells)
> This is utter nonsense. There is nothing wrong with using 100% of the logic
> resources, if the routing structure supports this. And that depends on the
> design style. Newer families have considerably more routing than the old
> ones. Whether a design is logic- or routing-limited has nothing to do with
> the particular manufacturer.
> 
> I am not really paranoid, but our dear competitor has recently cranked up
> the marketing spin machine, believing that mudslinging might be productive.
> It is not, not even in politics.
> When you listen to a new product presentation where 40% of the material
> talks about the "bad" competitor, draw your own conclusions. Are they afraid
> ?
> Let's be positive. We all have good products to promote. Spreading lies
> about the competition is counter-productive.

Whoa!!!  Calm down there.  Are you saying that Thomas Stanka is an
Altera vendor?  I think he is just another user and you have mistaken
his non-native english for a criticism of Xilinx.  I don't think he
meant "Xillinx [sic] wouldn't allow" for "Xilinx does not guarantee". 
We all understand that you might be able to use all the logic, but it
depends on the design and some routing dense designs may not be able to
achieve 100% logic usage.  

-- 

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: 71963
Subject: Re: Need StateCAD 4.11!
From: sense_1909S_VDB@yahoo.com (google_guy)
Date: 4 Aug 2004 14:28:56 -0700
Links: << >>  << T >>  << A >>
mwm11@cornell.edu (mmock) wrote in message news:<b2c16e8.0408032014.5129bb5c@posting.google.com>...
> Due to a calamtity of computer problems, including some affecting my
> backups, I'm suddenly in desparate need of StateCad Version 4.11 (or
> possibly Version 5.0) to support an active project.  An evaluation
> version is fine.  Can anyone help?

eMule is your friend.  Check it out and see if you can find a copy there.  :)

Article: 71964
Subject: Re: practical Virtex2 output buffer speeds
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 04 Aug 2004 14:32:06 -0700
Links: << >>  << T >>  << A >>
Robert,

You can run an IBIS simulator.......

By the way, I found out today that there is a public domain software 
tool that converts IBIS back into spice, so you could then run the IBIS 
model under a spice simulator that doesn't already support IBIS (like a 
public domain spice program).

So as to not frustrate you if you just don't have any tool available 
right now, and are in a position to have to make a decision, our hotline 
can run "what if" cases if you tell them the IO standard(s) you want to 
use, the frequency, the trace length, and the load (as in another Xilinx 
part, or 10 pF, or whatever).

Finally, if you can't even wait that long to get the right answer, my 
own experience in the lab tells me that for very light loading, and 
short run lengths (like less than 6 ") if everything is done right as 
far as signal integrity engineering goes:

Virtex II, single ended IO - 200 MHz (HSTL 1.8V); differential IO - 420 
MHz LVDS
Virtex II Pro, single ended IO - 266 MHz (HSTL 1.8V); differential IO - 
420 MHz LVDS
Virtex 4, single ended - TBD (can't say right now, looks too good); 
differential - 500 MHz LVDS

Your mileage may vary depending on loading, etc.

My numbers are for the commercial operating range, and all speed grades 
(as IO does not vary by speed grade much at all).

Austin

Robert Sefton wrote:
> Is it documented anywhere what the practical upper limits are, in terms of Mbps, for the various Virtex2 output buffer
> types? For example, if I need to output a 600MHz clock (effectively 1.2Gbps), do I need to use LVDS or HSTL, or can a
> FAST 3.3V CMOS output buffer handle it? I don't have the luxury of running HSpice sims, but can I extract this
> information from any of the buffer models available from Xilinx?
> 
> Thanks,
> 
> Robert
> 
> 

Article: 71965
Subject: Re: Compact FPGA Board?
From: daragoth@kuririnmail.com (Daragoth)
Date: 4 Aug 2004 14:33:30 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<BD34280A.7CD7%peter@xilinx.com>...
> I know (from my own experience) that it is tempting to design something
> small and neat. But I have also seen many failures when there just was not
> enough room to complete the design properly.
> My advice is: Think twice ( or thrice) before committing to a very tight
> footprint.
> Peter Alfke

Thanks for the advice Peter, but unfortunately this isn't an option
for me.  The space that the board must go in has already been
determined; it must be 40x30x10 mm in volume.

-DAG

Article: 71966
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 04 Aug 2004 14:40:00 -0700
Links: << >>  << T >>  << A >>
Sorry if my outburst was misunderstood as criticism of any author here in
the ng. It was not meant as that,
I just was p***ed off by a stream of marketing material from the A-company.
Our sales force spends too much time correcting FUD generated by our
"friends". It's counter-productive, same as it is between Bush and Kerry.
I am dying to explain the many great things in Virtex-4 (soon!), instead of
dodging the mudslinging.
Peter Alfke

> 


Article: 71967
Subject: Re: ChipScope Pro Loading Memory
From: Vivek <vjoshi@harris.com>
Date: Wed, 4 Aug 2004 15:12:07 -0700
Links: << >>  << T >>  << A >>
See, the problem is that there will be no microprocessor interface. There will just
be a Virtex II FPGA interfaced to the memory. Thats why I am trying to use ChipScope pro. 

Vivek 


Article: 71968
Subject: Re: Manipulation on netlist for faster simulation.
From: Joe <joe_y@invalid_address.nospam.com>
Date: Wed, 04 Aug 2004 23:20:02 +0100
Links: << >>  << T >>  << A >>
Kelvin wrote:
> Hi, there:
> 
> My Xilinx software generated a flattened netlist and SDF each over
> 100MB...Now NC_Verilog
> takes hundreds of hours to simulate that.
> 
> Now if I write a perl to replace all the long wire names with some random
> 10-alphabet string,
> it will probably shrink the file size to 10MB...But will that make my
> simulation faster?
> ---sample
>   wire
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 0)/F ;
>   wire
> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1
> 0)/G ;
> 
> 
> Thanks.
> Kelvin
> 
> 
> 

Hi Kelvin,

In case your data files are store on a file server and the simulation is 
executed by a separate server, the link between the two servers can be a 
bottle neck.

In SDF simulation the simulator access to the compiled binary files a 
lot, so it is better to put all the files in the same machine that you 
run simulation on.

A lot of UNIX machines have /tmp directory that are accessible by 
everyone, and it is possibly not mount to the file server. So you might 
try to copy your files to /tmp directory and run the simulation from 
there.  (But don't tell your sys admin :-> )

Also try run the simulaion in command mode and redirect stdout to a file 
instead of output to display. (messaage display can be another bottle neck).

Joe


Article: 71969
Subject: Re: Manipulation on netlist for faster simulation.
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Wed, 04 Aug 2004 16:53:30 -0600
Links: << >>  << T >>  << A >>


Eyck Jentzsch wrote:
> Hi Kevin,
> 
> Kelvin wrote:
> 
>> Hi, there:
>>
>> My Xilinx software generated a flattened netlist and SDF each over
>> 100MB...Now NC_Verilog
>> takes hundreds of hours to simulate that.
>>
>> Now if I write a perl to replace all the long wire names with some random
>> 10-alphabet string,
>> it will probably shrink the file size to 10MB...But will that make my
>> simulation faster?
>> ---sample
>>   wire
>> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1 
>>
>> 0)/F ;
>>   wire
>> \modem/bt_top/demodulator/u_demod/dif_dsp_core/u_demod/div_step_2_div_step(1 
>>
>> 0)/G ;
>>
>>
>> Thanks.
>> Kelvin
>>
>>
>>
> This will not help much, it will just speedup the simulation startup 
> because of less file reading.
> It will help more to check if you used all performance switches (and 
> aviod performance degrading options like +access+rwc or linedebug ;-)).
> The online documentation (cdsdoc) has a dedicated chapter ('Maximising 
> simulation performance') for it.
> HTH
> 
> -Eyck
> 

I agree with what has been said here but offer another possible 
suggestion to help out with this situation.  Why are you flattening the 
netlist?  If you keep some hierarchy (some not all of it), it will 
likely allow you to better manage the simulation in multiple ways. 
First, that will likely shrink many of the signal names you are having 
problems with as the hierarchy is no longer needed to be preserved into 
each individual signal name.  Second, it would allow you to set 
accessibility to separate portions of the design by allowing you to 
specify the optimizing of portions you are not currently debugging and 
allowing visibility to the portions you are.  Third, you can do a full 
timing simulation of part of your design so rather than trying to 
simulate the whole thing at once, you could do it in pieces.  This not 
only makes for smaller and usually faster simulations but also can allow 
the re-use of sub-level testbenches, allow for parallel simulations (if 
you have more licenses available), uses less memory/less machine 
requirements, easier debug since it is smaller and better understood, 
and a handful of other benefits.  Fourth, you could replace the portions 
of the design you are not currently trying to perform a timing 
verification on with behavioral or RTL code thus doing a mixed 
behavioral/RTL/Timing simulation which should perform much better than a 
full structural simulation.

At some point in the design, it is always beneficial to do a full 
netlist timing simulation as it can detect problems that can be easily 
missed in functional simulation and static timing analysis (even in 
fully synchronous designs) however that is generally best done at the 
very end of the design cycle.  Much of the timing verification can many 
times be done more efficiently in pieces by retaining the hierarchy and 
using it in this phase of verification.  For information on hierarchy 
preservation for simulation, look at Chapter 6 in the Synthesis and 
Verification design Guide, the section titled, "Design Hierarchy and 
Simulation": 
http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf

Hope this helps.

--  Brian


Article: 71970
Subject: Re: VGA Signals
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 4 Aug 2004 16:31:40 -0700
Links: << >>  << T >>  << A >>
"Andrew Dyer" <andrew.spam.dyer@comcast.net> wrote in message
news:pan.2004.08.04.04.53.31.481111@comcast.net...
> It's perfectly possible to drive a
> "640x480" monitor with 1024x768 if you keep the horizontal and vertical
> frequencies in spec - individual pixels just may not show up all that
well.
>
Probably wouldn't work. The monitor wouldn't like the extra lines. You could
drive it 1024x480 though!
Cheers, Syms.



Article: 71971
Subject: Re: Virtex 2 Pro OCM question
From: Paulo Dutra <paulo.dutra@NOSPAM.com>
Date: Wed, 04 Aug 2004 17:03:15 -0700
Links: << >>  << T >>  << A >>
Yes, this is possible.

There's no HDL in the hdl directory as the bram_block is generated
on the fly.

Depending on how you modified the dsocm_bram_elaborate. It sounds
like you introduced user logic. This may be better partitioned
as it's own pcore. This way you allow the tools to regenerate
bram_block.

You can send me email paulo_dutra@xilinx_com (replace all "_" with ".")
for more details.

MS wrote:
> We are using a V2Pro with the embedded PowerPC.  We have several
> packet queues that go back and forth between the processor and the
> custom fast path logic.  We have decided to implement these in Data
> OCM block memories.
> 
> The issue we are having is that when we goto add a DSOCM- it generates
> one memory (not necessary one block memory)- with Port A going to the
> DSOCM IF and port B going to the logic.  This is great for one queue-
> but doesn't work for multiple queues.
> 
> We then looked at the generated code (HDL directory of our project)
> and figure we can edit the dsocm_bram_elaborate and wrapper to do what
> we want.  This should be fine- but whenever we change the MHS file
> and/or compile it- it will write over these changes.  The process
> would become more manual.
> 
> We would like to be able to edit this blockRam so that the MHS file
> references this.  I looked in the EDK/hw/XilinxProcessorIP/pcores
> directory at the bram block- and there is no HDL to edit.
> 
> Has anyone else done something similar?  I have a few paths I want to
> go down- but if anyone can eliminate or suggest one I am all ears.  My
> next thing will be to edit a copy of the dsbram_if_cntl HDL and plop a
> few block Memories directly into it and see if this works- but again-
> I am open to suggestions.


-- 
/ 7\'7 Paulo Dutra (paulo_dutra@xilinx_com)
\ \ `  Xilinx                              hotline@xilinx.com
/ /    2100 Logic Drive                    http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA


Article: 71972
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: Gupta <gupt@hotmail.com.NOSPAM>
Date: 04 Aug 2004 18:02:42 -0700
Links: << >>  << T >>  << A >>

Can you help me understand the value proposition of Xilinx versus
Altera.  I guess this may turn out to be a religious-type of question
with die-hard followers (and Xilinx, Altera marketing mixed in).  But
perhaps if someone can give me some insight into how do you choose
between the products of these two companies who seemingly have very
similar product lines (well not for the really large and complex FPGAs
where Xilinx has unique parts with PowerPC etc).

Although I appreciate the comments so far, I was hoping to evoke some
user responses as to why they choose certain parts and under what
conditions.  I got a good list of metrics from Rick and Thomas to
evaluate products on, but still didn't get the true insight into what
may be the value propositions of the various FPGA vendors.

Thanks again for all the responses.
Sumit

Article: 71973
Subject: Re: practical Virtex2 output buffer speeds
From: "Robert Sefton" <rsefton@nextstate.com>
Date: Wed, 4 Aug 2004 18:39:12 -0700
Links: << >>  << T >>  << A >>
Thanks, Austin. Not the answer I was hoping for, but I'll figure something out. When will CML be available as a SelectIO
option? Virtex 4?

Robert

"Austin Lesea" <austin@xilinx.com> wrote in message news:cerkj2$p2b2@cliff.xsj.xilinx.com...
> Robert,
>
> You can run an IBIS simulator.......
>
> By the way, I found out today that there is a public domain software
> tool that converts IBIS back into spice, so you could then run the IBIS
> model under a spice simulator that doesn't already support IBIS (like a
> public domain spice program).
>
> So as to not frustrate you if you just don't have any tool available
> right now, and are in a position to have to make a decision, our hotline
> can run "what if" cases if you tell them the IO standard(s) you want to
> use, the frequency, the trace length, and the load (as in another Xilinx
> part, or 10 pF, or whatever).
>
> Finally, if you can't even wait that long to get the right answer, my
> own experience in the lab tells me that for very light loading, and
> short run lengths (like less than 6 ") if everything is done right as
> far as signal integrity engineering goes:
>
> Virtex II, single ended IO - 200 MHz (HSTL 1.8V); differential IO - 420
> MHz LVDS
> Virtex II Pro, single ended IO - 266 MHz (HSTL 1.8V); differential IO -
> 420 MHz LVDS
> Virtex 4, single ended - TBD (can't say right now, looks too good);
> differential - 500 MHz LVDS
>
> Your mileage may vary depending on loading, etc.
>
> My numbers are for the commercial operating range, and all speed grades
> (as IO does not vary by speed grade much at all).
>
> Austin
>
> Robert Sefton wrote:
> > Is it documented anywhere what the practical upper limits are, in terms of Mbps, for the various Virtex2 output
buffer
> > types? For example, if I need to output a 600MHz clock (effectively 1.2Gbps), do I need to use LVDS or HSTL, or can
a
> > FAST 3.3V CMOS output buffer handle it? I don't have the luxury of running HSpice sims, but can I extract this
> > information from any of the buffer models available from Xilinx?
> >
> > Thanks,
> >
> > Robert
> >
> >




Article: 71974
Subject: Re: Choosing FPGAs: Xilinx vs Altera vs Actel vs Lattice
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 04 Aug 2004 21:48:08 -0400
Links: << >>  << T >>  << A >>
Gupta wrote:
> 
> Can you help me understand the value proposition of Xilinx versus
> Altera.  I guess this may turn out to be a religious-type of question
> with die-hard followers (and Xilinx, Altera marketing mixed in).  But
> perhaps if someone can give me some insight into how do you choose
> between the products of these two companies who seemingly have very
> similar product lines (well not for the really large and complex FPGAs
> where Xilinx has unique parts with PowerPC etc).
> 
> Although I appreciate the comments so far, I was hoping to evoke some
> user responses as to why they choose certain parts and under what
> conditions.  I got a good list of metrics from Rick and Thomas to
> evaluate products on, but still didn't get the true insight into what
> may be the value propositions of the various FPGA vendors.

Rather than to try to compare the various products and manufacturers in
a vacuum.  It might be much more useful to evaluate them in the context
of your project.  There are some users who have good experiences with
one vendor or another and so stick with that one vendor.  But many FPGA
designers are willing to use any part that is best for a given
application.  

In general you will find a lot more similarities between X and A than
you will differences.  The tools are slightly different and the parts
are less different.  Unless you are doing a design that requires the use
of one of the architecture specific features, you will find that your
best bet is to design your project to be independant of the chip family
so that you can reuse your IP in other products.  

Of course if you are designing a high volume device where cost is
paramount, then you will want to pick the best chip and optimize the
design for that architecture.  But many if not most FPGAs don't end up
in those sockets.  

Ok, all the caveats aside, here is some general info.  First, I would
not make any significant issues out of the technology or any other
aspect of the devices that does not directly impact your requirements. 
So if you can work with either a Flash/SRAM FPGA or with an SRAM FPGA
with a separate Flash chip equally well, then just don't worry about
that.  BTW, I am pretty sure the Lattice Flash FPGAs also use SRAM. 
They simply have Flash as a backup and load the SRAM from the Flash.  So
there won't be a space savings on the die anyway.  In fact it will take
up more space for several reasons.  But all you care about is what price
they charge you and you won't know that until you get a quote.  

I expect you will find Altera and Xilinx to be pretty much equal for
most apps.  The Xilinx parts seem to do a bit better in DSP or other
heavily pipelined apps.  This is due to a couple of features they have
such as the SRL16 and the better adders they can make with the extra
input on their LUT in arithmetic mode.  Whether this is useful to you
depends on your design requirements.  

I have one socket on a board that Xilinx could not fill.  I needed 5
volt compatibility in a relatively low power device.  All of the newer
(read supported by current software) devices that are 5 volt tolerant
have a power on current surge that makes it hard to use in a low power
design without extra circuitry.  So I ended up using an Altera ACEX
(EP1K) device which is only about 3-4 years old.  Otherwise their newer
chips are mostly similar.  

-- 

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



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