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 57500

Article: 57500
Subject: Re: Cyclone vs Spartan-3
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 01 Jul 2003 10:46:17 -0700
Links: << >>  << T >>  << A >>
Let's stick with English, otherwise we have ro rename this the
"FPGAinformationsaustauschzentralverteilungsstelle".

All presently existing S3-50s lack the BlockRAM and therefore the DLLs (
BlockRAM and DLL share a column. When we took out one, we had to take
out the other). The decision was made in order to speed up the design,
and was then reversed, so all future production 50's will have BlockRAMs
and DLLs.
The existing S3-1000s of course have DLLs and BlockRAMs.
Everybody using these "Early Silicon" devices MUST consult the errata sheet.
By definition, ES always has an errata sheet ( in the best case it would
just say "no errata").

Peter Alfke, Xilinx Applications
===============================
Mike Randelzhofer wrote:
> 
> "> Hab auch ein paar S3-50 in der Schublade...
> Weiss aber immer noch nicht ob die Blockrams und DLL's haben oder nicht ?
> 
> Gruss MIKE
> 
> for our english readers:
> I also have some spartan3-50 devices, but don't know if they have blockrams
> and dll's ?
> 
> regards MIKE

Article: 57501
Subject: Re: Cyclone vs Spartan-3
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Tue, 1 Jul 2003 18:12:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mike Randelzhofer <michael.randelzhofer@mchf.siemens.de> wrote:

: Hab auch ein paar S3-50 in der Schublade...
: Weiss aber immer noch nicht ob die Blockrams und DLL's haben oder nicht ?

: Gruss MIKE

: for our english readers:
: I also have some spartan3-50 devices, but don't know if they have blockrams
: and dll's ?

To my knowledge, the first batch of 3S50 was made without BRAM and DLLs. Try
to decipher the Date Code and you probably you'll find information on the
Xilinx webpage ( and you probably will get feedback here).

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 57502
Subject: Re: Suitable motherboard for Spartan-IIE PCI design
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Tue, 01 Jul 2003 11:16:52 -0700
Links: << >>  << T >>  << A >>

Hi,

There are a number of boards available.  You should look
for a server class motherboard, one that supports PCI-X
or at least PCI at 66 MHz.  A board that supports either
of those will be (by requirement) at 3.3v slot, not a 5.0v
slot.

If you are looking for a cheap machine that will do the
job, you may consider the HP Kayak XU800.  I see a number
of them available on Ebay from time to time.

Eric

Colin Hall wrote:
> 
> Dear All,
> 
> Apologies if this is slightly off-topic but I hope there may be
> someone reading who has faced a similar problem.
> 
> I have a prototype 33/32 PCI peripheral. The PCI bus interface is
> implemented in a Spartan-IIE device, which is not +5V tolerant. Design
> verification of the hardware is underway on this new design.
> 
> I would like to make progress on software development while we wait
> for the hardware to be finished. To that end, I am looking for a
> PC-architecture motherboard into which I can plug our prototype card
> without blowing the Spartan-IIE device.
> 
> I tried searching for suitable commodity motherboards. There are
> plently of boards but none of them specified that their PCI bus
> interfaces were 3.3V only.
> 
> If anyone can suggest a suitable board I would be most grateful.
> 
> Regards,
> Colin.

Article: 57503
Subject: Re: Cyclone vs Spartan-3
From: "M.Randelzhofer" <mrandelzhofer@uumail.de>
Date: Tue, 1 Jul 2003 20:20:13 +0200
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag
news:3F01C8E9.9E79F922@xilinx.com...
> Let's stick with English, otherwise we have ro rename this the
> "FPGAinformationsaustauschzentralverteilungsstelle".

OK, but i didn't know that this NG is called
"FPGAinformationexchangecentraldistributioncenter".

>
> All presently existing S3-50s lack the BlockRAM and therefore the DLLs (
> BlockRAM and DLL share a column. When we took out one, we had to take
> out the other). The decision was made in order to speed up the design,
> and was then reversed, so all future production 50's will have BlockRAMs
> and DLLs.

So the present s3-50 devices without blockrams are the fastest s3 90nm chips
forever ?

MIKE





Article: 57504
Subject: Re: Xilinx ISE drops support for more parts
From: Philip Freidin <philip@fliptronics.com>
Date: Tue, 01 Jul 2003 18:32:28 GMT
Links: << >>  << T >>  << A >>
On 1 Jul 2003 05:47:25 -0700, lecroy7200@chek.com (lecroy) wrote:
>I am reposting after a memo from reader siting problems using the
>Xilinx link to post to this group.  Sorry about any problems this may
>have caused.

Thanks, I appreciate the lack of HTML in the news group.

>After the release of Alliance 3 support was no longer offered
>for the XC3xxx family.  Worse, if you did not happen to
>have the original software that supported these
>devices, Xilinx would not sell you a copy.  Even today we
>still have product that uses the 3xxx family.

At least for XC4000E, EX, XL, XLA, and Spartan, the SW is
available as Xilinx "Classic" software (free, but need normal
xilinx user id/password).

    http://www.xilinx.com/webpack/classics/spartan_4k/index.htm


>I am looking at upgrading our group to Allience 5.x
>and again see that Xilinx has dropped all support for
>Spartan.  Other families were dropped as well. We would
>now need three copies of software running to
>support the Xilinx devices we use. Of course, not all
>the Xilinx tools like to be co-installed, so it's multiple
>computers or swap installs.

As for maintaining multiple versions of the software
on the same computer, I have found that VMWARE (www.vmware.com)
is a very good solution. I basically set up a virtual computer
for each version of the software, and each is kept separate
and there are no conflicts. Costs a few GBytes of disk, which
these days is only a few $.



Philip Freidin



Philip Freidin
Fliptronics

Article: 57505
Subject: Re: SPARTAN-3 vs. VIRTEX-II
From: oen_br@yahoo.com.br (Luiz Carlos)
Date: 1 Jul 2003 12:19:01 -0700
Links: << >>  << T >>  << A >>
> You can feel how you wish about your designs, but even the loss of the
> 64 bit dual ports and the 128 bit single port rams is not signficant. 
> To make a 64 bit dual port RAM requires 8 LUTs for ram (same as in VII)
> and one LUT for the read mux and possibly two more LUTs for the WEs. 
> But if this is part of a larger ram block you are making half of the WEs
> would have been required anyway.  So it is not a "large" amount of
> logic, just a bit more.  

Ok, I agree with you, it´s not to much logic. But because these extra
delays maybe I have to duplicate the circuits.

> If you are making really large blocks where the longer runs on the
> address and data can slow it down significantly, then you likely are
> better off with the block rams.  

No, they are not large blocks, but I have 128 to 512 FIR filters (256
coefs) running in parallel, and the sampling rate is 2 megaHertz.
Throughput!

> Considering the much lower price of the XC3S parts, all this sounds to
> me like a benefit, not a liability.  Think of it as paying for the LUTs
> that have RAM and getting the other LUTs for free  :)

I'm not complaining, and I know that Xilinx wil not make a special
Spartan3 just for me. But I have the right to express what I think,
and maybe I'm not alone. Maybe there are a lot of Luizes and Rays,
maybe Xilinx will hear us and maybe, at these nanometer scales where
the pads are so big, to have all the CLBs configurable as memory is
not so significant in silicon area.

Luiz Carlos Oenning Martins
KHOMP Solutions

Article: 57506
Subject: Re: NAND flash file
From: Steve Prokosch <sprokosch@xilinx.com>
Date: Tue, 01 Jul 2003 13:33:01 -0600
Links: << >>  << T >>  << A >>


Matt,
You must register through the link at the end of the app note (after
reading the disclaimer).  You will then receive a email with a link to
the HDL code.
Hope that helps,
Steve

mduane@umich.edu wrote:

> Does anyone know where I can find the xapp354_verilog or xapp354_VHDL
> files for NAND flash?  I went to the Xilinx ftp site, and they were
> not listed there.  Thanks.--Matt




Article: 57507
Subject: Spartan-3 and Xilinx' PLB Gigabit Ethernet MAC
From: dingler44@postmark.net (Jimbo)
Date: 1 Jul 2003 12:44:59 -0700
Links: << >>  << T >>  << A >>
The question is simply, can the Spartan-3 support the PLB GeMAC at
this time?

I found in the Spartan-3 FAQ that it WILL support 1 Gig Ethernet MACs
but I couldn't tell where in the future the WILL was pointing to.

Thanks for any insight,
Jim

Article: 57508
Subject: Re: Quartus produces wrong parameters for Stratix PLL
From: sdatta@altera.com (Subroto Datta)
Date: 1 Jul 2003 13:10:11 -0700
Links: << >>  << T >>  << A >>
already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0307010229.563153f@posting.google.com>...
> sdatta@altera.com (Subroto Datta) wrote in message news:<ca4d800d.0306301212.1cd9be9c@posting.google.com>...
> > already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0306300619.58b3f8a5@posting.google.com>...
> > > Following PLL was generated with MegaWizard Plug In Manager and
> > > compiled (for Stratix) under Quartus 2.2:
> > > Input Frequency: 36MHz
> > > Dynamic reconfiguration is in use. 
> > > c0 Clock Multiplication Factor = 158
> > > c0 Clock Division Factor = 36
> > > Other counters are not in use.
> > > The compilation report shows:
> > > M value = 79 
> > > N value = 3
> > > VCO frequency = 948MHz !!!!
> > > It looks like Quartus design team is not aware of limitations of the
> > > Stratix PLL as listed in the respective datasheet (300 to 800MHz for
> > > -5 and -6 grades, 300 to 600MHz for -7 grade). They live under
> > > impression that everything up to 1000MHz is o.k. :(
> > The Stratix Fast PLL can go up to 1GHz for certain speedgrades, which
> > is why the Megawizard allows this (only the Enhanced PLL is limited to
> > 800Mhz). A design that needs a VCO at 1GHz will work in Stratix. The
> > PLL will then be placed on the Fast PLL and be used as a general
> > purpose PLL. However a Fast PLL cannot be used for dynamic
> > reconfiguration, and this should have been reported during fitting.
> > 
> > For Quartus II version 3.0, the Megawizard has been enhanced to
> > recognize that only an Enhanced PLL can be used when dynamic
> > reconfiguration is selected, and as a result it will ensure that the
> > VCO is valid for an Enhanced PLL in the Megawizard itself. The
> > Megawizard will become speedgrade aware in a future release of
> > Quartus. In the meantime all calculations are based on the fastest
> > speedgrade.
> > 
> > - Subroto Datta
> > Altera Corp.
> > 
> > 
> 
> I don't have Quartus II version 3.0 (BTW, is it already available ?)
> so can't comment about it. What I do know - Quartus II version 2.2
> Megawizard doesn't emit "enhanced" set of PLL parameters, so the
> Megawizard has no direct control of the VCO frequency. Unless it was
> changed in the 3.0, I can't see how improvements in the Megawizard
> would fix the problem. IMHO, the bug is in the compiler and it's where
> it should be fixed.
> In the mean time, the only reliable solution I can think of is:
> 1. Don't use the Megawizard.
> 2. Manually set enhanced parameters for the altpll().
> It would work, of coarse, but it's a PITA...
> 
> Regards,
> Michael


In Stratix devices there are two types of PLLs - Enhanced PLLs and
Fast PLLs.  The Megawizard performs a feasibility check to make sure
the resulting parameters the compiler will compute (including the VCO
frequency) will be valid for at least one of these PLL types.  For
Quartus II 3.0, the Megawizard is aware of the restriction that forces
the use of Enhanced PLLs when using reconfiguration, and as a result
will make sure all parameters can be implemented in an Enhanced PLL
earlier on in the flow.

But even in Quartus II 2.2, the compiler will give an error if the PLL
cannot be implemented in either of the PLL types, including if no set
of internal parameters could achieve the requested PLL settings and a
legal VCO for the speed grade selected.  If a legal set of internal
parameters did exist that could achieve the requested PLL settings,
then the compiler will implement those parameters.

Quartus II 3.0 was released to production/manufacturing on June 27th
so you should be seeing it real soon.

- Subroto Datta
Altera Corp.

Article: 57509
Subject: Celoxica feedback
From: Alain <arnaudnospam@nospam.ecla.com>
Date: Tue, 01 Jul 2003 17:08:49 -0400
Links: << >>  << T >>  << A >>
Can anyone provide feedback on Celoxica.

Do they meet all of the claims?

Performance obtained ?

Pros and cons?




Article: 57510
Subject: Re: Cyclone vs Spartan-3
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 01 Jul 2003 14:14:03 -0700
Links: << >>  << T >>  << A >>


"M.Randelzhofer" wrote:
> 
> So the present s3-50 devices without blockrams are the fastest s3 90nm chips
> forever ?

No, when I wrote "speed up", I meant weeks in design, not picoseconds in operation.
Spartan3 is not the fastest, in some areas it is slower than Virtex-II,
since the priorities for Spartan3 were: 1. low cost, 2. low cost, and 3.
low cost. We don't throw away speed, but we did not increase the chip
size to gain performance.
Deleting BRAM and DLL does nothing to the performance, but it reduced
the design effort, and it made the chip smaller. But this is all history now.

"FPGAinformationsaustauschzentralverteilungsstelle" was meant as a joke,
referring to the American fascination with the German capability to
concatenate words ad infinitum. Donaudampfschifffartgesellschaftskapitaen....

Peter Alfke



Peter Alfke

Article: 57511
Subject: Re: Can Altera NIOS processor be syntheized on a Flex FPGA
From: kempaj@yahoo.com (Jesse Kempa)
Date: 1 Jul 2003 14:24:14 -0700
Links: << >>  << T >>  << A >>
Quartus II 3.0 was released to production this past Friday, June 27. 

As I am an "insider" and don't wait for the install CDs to be
delivered, I can't give an accurate date of when they will be mailed
out, but an educated guess would be within a couple of weeks.

If you have a more urgent need, I reccomend contacting your local
Altera FAE or Sales office and explain the need for Flex compilation
support with Nios - sometimes its possible to have them burn a CD or
setup an FTP download for you.

Regards,

Jesse Kempa
Altera Corp.
jkempa at altera dot com



> > When is Quartus version 3 coming out?
> > 
> Hi,
> My sources tells me late June worst case early August. (They are
> allready posting app notes on new features on Alteras homepage!)
> /Fredrik
> >

Article: 57512
Subject: Re: SPARTAN-3 vs. VIRTEX-II
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 01 Jul 2003 14:45:31 -0700
Links: << >>  << T >>  << A >>
Xilinx has two major product lines. Virtex is for performance and
features, Spartan is for low cost. Otherwise, the architectures are very similar.

That gives us a chance to really optimize each line. The Spartan
developers reduce the cost, accepting that this makes their devices
non-optimal for certain applications, but there is always Virtex to
deliver higher functionality and performance (at a higher price).
The Virtex designers can optimize functionality and speed, knowing that
this might increase the cost, but there is always Spartan to satisfy
less performance-critical, but more cost-sensitive applications.

There is no free lunch, in engineering almost everything is a trade-off.
But everybody still asks for champagne on a beer budget  :-)
Peter Alfke
=======================
Luiz Carlos wrote:
> 
> 
> I'm not complaining, and I know that Xilinx wil not make a special
> Spartan3 just for me. But I have the right to express what I think,
> and maybe I'm not alone. Maybe there are a lot of Luizes and Rays,
> maybe Xilinx will hear us and maybe, at these nanometer scales where
> the pads are so big, to have all the CLBs configurable as memory is
> not so significant in silicon area.
> 
> Luiz Carlos Oenning Martins
> KHOMP Solutions

Article: 57513
Subject: VirtexII bitstream relocation
From: ecarvalho@inf.pucrs.br (Ewerson Carvalho)
Date: 1 Jul 2003 15:01:07 -0700
Links: << >>  << T >>  << A >>
Hi all

I have questions about bitstream relocation in VirtexII FPGAs. We have
already developed software based on the old Jbits package from Xilinx
for doing small bits manipualations bitstream relacation for Virtex
devices, but we are facing difficulties in finding documentation about
how to perform significant-size IP-core bitstreams (50,000 gates or
more)
relocation in VirtexII devices. Can you give some hint on where such
documentation can be found, if it exists?

We are implementing a configurations controller manager in hardware,
to allow automated swap of IPs in a number of identical size
reconfigurable areas defined using the Modular Design flow (even
though the current documentation suggests that it is complicated to
make things work with more than one reconfigurable area at the same
time, we have managed to define and "almost" use 2 such areas).
The idea is: given a temporal schedule for reconfigurable IPs and
apply this using the ICAP interface to partially reconfigure the
device in one of the areas. Having more than one area is fundamental
to allow bitstream prefetch for hiding reconfiguration latency.

Thanks in advance for any help.

Ewerson L. S. Carvalho, Master Student - Informatics Institute, PUCRS
Mail Address: Av Ipiranga, 6681, Prédio 16. Porto Alegre, RS, Brazil
CEP:90619-900 - Phone:+55 51 3320 3611 - Fax:+55 51 3320 3758
e-mail: ecarvalho@inf.pucrs.br - URL:
http://www.inf.pucrs.br/~ecarvalho

Article: 57514
Subject: Re: Xilinx ISE drops support for more parts
From: JoeG <no@where.net>
Date: Tue, 1 Jul 2003 23:31:02 GMT
Links: << >>  << T >>  << A >>
I've ask Xilinx the ? about legacy support for years -- I have the same
problem with XC4005 series -- we have hundreds fielded on MILITARY
applications. However Xilinx newer tool suites Foundation/Alliance DO NOT
support these legacy devices. So we are STUCK with maintaining an OLD
machine with OLD Xilinx XACT software.

lecroy wrote:

> I am reposting after a memo from reader siting problems using the
> Xilinx link to post to this group.  Sorry about any problems this may
> have caused.
>
> After the release of Alliance 3 support was no longer offered
> for the XC3xxx family.  Worse, if you did not happen to
> have the original software that supported these
> devices, Xilinx would not sell you a copy.  Even today we
> still have product that uses the 3xxx family.
>
> I am looking at upgrading our group to Allience 5.x
> and again see that Xilinx has dropped all support for
> Spartan.  Other families were dropped as well. We would
> now need three copies of software running to
> support the Xilinx devices we use. Of course, not all
> the Xilinx tools like to be co-installed, so it's multiple
> computers or swap installs.
>
> Xilinx, what is your problem?  Altera may drop parts, but
> their router continues to support all of their devices.
> Is your software so poorly written that it is so difficult
> to maintain parts that you need to drop them?  I could understand
> if the parts were no longer available, or you at least sold
> older copies of your software.


Article: 57515
Subject: Seminar: Digital Signal Processing, Programmable Device Architecture, and Military/Aerospace Applications
From: "Richard B. Katz" <richard.b.katz@nospamplease.nasa.gov>
Date: 2 Jul 2003 00:53:31 GMT
Links: << >>  << T >>  << A >>
A seminar on "Digital Signal Processing, Programmable Device 
Architecture, and Military/Aerospace Applications" will be presented at 
the 2003 MAPLD International conference on September 8th, 2003, in 
Washington, D.C.

   http://www.klabs.org/richcontent/MAPLDCon03/tutorials/

Abstract
========

Digital signal processing has traditionally been done using Von-Neuman 
or Harvard type processors with enhancements such as single cycle 
multiplies. Recent advances in speed, density, and features have made 
Field Programmable Gate Arrays (FPGAs) very attractive for digital 
signal processing applications, particularly when performance 
requirements are beyond the capability of microprocessors. 
Unfortunately, the majority of signal processing work over the last 
quarter century has been implemented as software on computers. 
Consequently,  there is currently very little overlap between hardware 
design and DSP expertise. Algorithms developed for software platforms 
are usually very inefficient for direct hardware implementation, and 
without the overlapping areas of expertise, the resulting FPGA 
realization is bound to disappoint.

This seminar helps to bridge the gap between DSP and FPGA design, aiding 
the designer in achieving the performance potential of FPGAs. This 
seminar will first review computer arithmetic and then look in detail at 
efficient FPGA implementations of common DSP elements such as 
multipliers, filters, and mixers. Tradeoffs between clock rate and 
performance will be discussed along with several design examples. 

Conference home page:  http://klabs.org/mapld03

Additional info: Richard B. Katz, NASA Office of Logic Design
                 richard.b.katz@nasa.gov

Article: 57516
Subject: Re: Xilinx ML300 JTAG Configuration Problem
From: Peter Ryser <ryserp@xilinx.com>
Date: Tue, 01 Jul 2003 18:12:31 -0700
Links: << >>  << T >>  << A >>
Please make sure that you are using the latest Xilinx Implementation tools.
From the previous message I can see that you are using 5.1. The latest
tools are 5.2i with service pack 3.

When looking at the schematics for the ML300 you will see that the FPGA
PROG button goes to the corresponding pin on the FPGA, i.e. pushing the
button will clear out the contents of the FPGA.

- Peter




tk wrote:

> Hi all,
>
> I have problem in configuring the xc2vp7 on the ML300 board. The
> problem is described in the previous thread "ERROR:iMPACT:583".
>
> I doubt that I have omitted some settings on the ML300 board during
> programming (or have done sth wrong in iMPACT). There is a button
> called "FPGA PROG" on the ML300 board. I've searched through the
> documentation but I couldn't find out what's it for.
>
> Does anyone have the experience on using ML300 that can share with me ?
>
> Thanks very much.
>
> tk


Article: 57517
Subject: ARM C/C++ compiler independent of OS
From: kartik20@yahoo.com (Kartik Krishnan)
Date: 1 Jul 2003 19:54:35 -0700
Links: << >>  << T >>  << A >>
i want to use some ARM C/C++ compiler which is independent of the
operating system.
What i am looking for is plain translation of my C/C++ benchmarking
code into plain ARM assebly and then into binaries...
if i use the ADS C/C++ compiler it generates some software interrupts
which kinda throws everything off track... Did any one have the same
problem before...?
or shoudl i get started with writing my own ARM compiler (but would
take ages (:  )
Thanks
Kartik

Article: 57518
Subject: Re: memory
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Wed, 02 Jul 2003 03:30:10 GMT
Links: << >>  << T >>  << A >>
Jon Terje Haugland wrote:

> I am designing a DDR SDRAM controller in a Virtex-II 1500 -5 FFA896.
> It should operate at 166 MHz towrads the DDR SDRAM. I have used
> XAPP266 as reference regarding the timing analysis towards the DDR
> SDRAM. In XAPP266 one of the "results" is:
> 0.503ns<tDQS-tDQ<1.025 (midpoint at 0.76ns). This delay is introduced
> by routing? If the PCB delay is 180ps pr. inch. it would require a DQS
> net that is 4.2 inches? Is this correct???

Yes, this is correct.  This delay is the difference between the DQ line
length on the PCB and the DQS line length on the PCB.  If the DQ lines
are 1.5 inches, the DQS lines need to be 1.5 inches + 4.2 inches = 5.7
inches, assuming 180ps/inch.  The delay of the PCB varies with stackup,
use care.  Delay of vias can be significant, make sure the number and
placement of vias match or that this delay is included in the
calculation.


-- 
Phil Hays

Article: 57519
Subject: VHDL variable setup and propogations
From: Matt <>
Date: Tue, 1 Jul 2003 21:35:22 -0700
Links: << >>  << T >>  << A >>
Greetings, 

I am having a strage time with some code I recently wrote to implement a UART - the code is working fine now, but a problem cropped up that is baffling me. This design is being synthesized in
Xilinx ISE 5 and implemented into a Spartan-II XD2S50 device. I'm on something of a learning curve with things right now so please go easy on me! :D 

when 10 => -- Stop Bit 
                 BitPos := 11; -- next is holding pattern for breaks 
if(FIFOhead = 3) then 
FIFOhead := 0; -- wrap around 
else 
FIFOhead := FIFOhead + 1; 
end if; 

FIFO(FIFOhead)(8) <= RxD; -- stash the break bit 
FIFO(FIFOhead)(7 downto 0) <= RReg; -- stash the received data 

The two FIFO array assignment statements at the bottom are the predominant problem.... The object is to assign the break bit to the 9th bit of the array of 9-bit words (indexed by the process
variable 'FIFOhead'), and then assign the databyte to the lower part. As written and synthesized, the above writes ONLY the received byte and NOT the break bit. If the statements are
exchanged, the opposite happens. In short, only the SECOND assignment appears to be executing properly. If a 'dummy' statement is inserted, so the code looks like: 

............ 
end if; 
FIFO(FIFOhead)(7 downto 0) <= RReg; -- stash the received data 
FIFO(FIFOhead)(8) <= RxD; -- stash the break bit 
FIFO(FIFOhead)(7 downto 0) <= RReg; -- stash the received data 

then both assignments work properly. There appears to be some amount of latency inherent in updating the variable before it can be used as an index, but why? And what is the proper way to
detect or circumvent this problem? This fix works temporarily just fine, but I fear this problem may explain similarly strange behavior in other sections of code. If this IS a latency problem, how
should I go about detecting these sort of things in my design to ensure all code is relatively bulletproof? All of the VHDL texts I have here really only cover language theory and simulation
synthesis, not the perils of things like proper floorplanning of the design. What's the best way to work on filling in the learning gaps? Thanks in advance for any insight! 

-- Matt 


Article: 57520
Subject: Re: Cyclone vs Spartan-3
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Wed, 02 Jul 2003 05:47:42 GMT
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F00FDD2.C74022BD@yahoo.com...
> "Nicholas C. Weaver" wrote:
> That is a good point about the tools.  I forget that the XC3S is only
> supported in webpack in the XC3S50 now and I think only up to the
> XC3S400 in the next release.  I honestly don't get the idea of selling
> very low cost chips and not adding them to the free tools.

Personally, I agree with your statement and have been trying to convince the
powers that be to add additional Spartan-3 devices to WebPack.  The folks
responsible for WebPack are concerned about the total download size.  The
larger devices have multi-MB support files.

> But good luck getting a price on the XC3S1000 at this point.  The
> XC3S1000 parts have been pushed back due to design problems and will not
> be out until Q1 or perhaps later.  The XC3S400 and one of the larger
> parts will be out in 4Q03 according to their schedule.

Hmm.  Engineering samples of the XC3S1000 and XC3S50 are available today.
The engineering samples have the part number XC3S1000J and XC3S50J to
distinguish them from the production devices.  This may be the reason you
were quoted longer delivery.  The non-'J' devices are due out in 4Q2003.
The non-'J' version of the XC3S50 also includes block RAM, embedded
multipliers, and 2 Digital Clock Managers (DCMs), which the XC3S50J does
not.


-- 
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Spartan-3
Tel:  (408) 626-7447
E-mail: steve.knapp@xilinx.com
---------------------------------



Article: 57521
Subject: Re: Cyclone vs Spartan-3
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 02 Jul 2003 17:54:15 +1200
Links: << >>  << T >>  << A >>
Steven K. Knapp wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:3F00FDD2.C74022BD@yahoo.com...
> > "Nicholas C. Weaver" wrote:
> > That is a good point about the tools.  I forget that the XC3S is only
> > supported in webpack in the XC3S50 now and I think only up to the
> > XC3S400 in the next release.  I honestly don't get the idea of selling
> > very low cost chips and not adding them to the free tools.
> 
> Personally, I agree with your statement and have been trying to convince the
> powers that be to add additional Spartan-3 devices to WebPack.  The folks
> responsible for WebPack are concerned about the total download size.  The
> larger devices have multi-MB support files.

 You could always shock them with the 'left field' concept of selective 
downloading just the device library files you need ? :)

-jg

Article: 57522
Subject: Re: why so many problems Xilinx ?
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 02 Jul 2003 02:03:14 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> rickman wrote:
> >
> >
> > Except that I often am contacted by Altera directly rather than here in
> > public.  I can understand why they would do that.
> 
> I cannot understand that at all. If the question is ventilated in
> public, it should be answered in public. Unless the answer is very embarrassing...
> 
> Peter Alfke, Xilinx

Often vendors don't want to seem like they are hawking their wares
here.  So I see nothing wrong with contact on a more personal level in
order to get a good answer to a question.  When your sales people make
calls on customers, they don't invite the competition to come along do
they?  Support is no different.  Why should the open the door for
kibitzing from the competition?  And maybe they will be revealing some
information that they don't want the competition to have.  I know that
Xilinx has been pretty tightlipped about their product schedules.  At
least I have had a very hard time getting that info until a couple of
weeks ago when I insisted that I needed it on the Spartan 3s.  

-- 

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: 57523
Subject: Re: SPARTAN-3 vs. VIRTEX-II
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 02 Jul 2003 02:17:33 -0400
Links: << >>  << T >>  << A >>
Luiz Carlos wrote:
> 
> > You can feel how you wish about your designs, but even the loss of the
> > 64 bit dual ports and the 128 bit single port rams is not signficant.
> > To make a 64 bit dual port RAM requires 8 LUTs for ram (same as in VII)
> > and one LUT for the read mux and possibly two more LUTs for the WEs.
> > But if this is part of a larger ram block you are making half of the WEs
> > would have been required anyway.  So it is not a "large" amount of
> > logic, just a bit more.
> 
> Ok, I agree with you, it´s not to much logic. But because these extra
> delays maybe I have to duplicate the circuits.
> 
> > If you are making really large blocks where the longer runs on the
> > address and data can slow it down significantly, then you likely are
> > better off with the block rams.
> 
> No, they are not large blocks, but I have 128 to 512 FIR filters (256
> coefs) running in parallel, and the sampling rate is 2 megaHertz.
> Throughput!
> 
> > Considering the much lower price of the XC3S parts, all this sounds to
> > me like a benefit, not a liability.  Think of it as paying for the LUTs
> > that have RAM and getting the other LUTs for free  :)
> 
> I'm not complaining, and I know that Xilinx wil not make a special
> Spartan3 just for me. But I have the right to express what I think,
> and maybe I'm not alone. Maybe there are a lot of Luizes and Rays,
> maybe Xilinx will hear us and maybe, at these nanometer scales where
> the pads are so big, to have all the CLBs configurable as memory is
> not so significant in silicon area.

Yes, certainly you have the right to express your views and to let
Xilinx know what you need.  But I think you are responding to the idea
that "something" is missing without knowing for sure if it is really an
issue.  When you say above that adding the level of logic may slow down
the design, you first need to know how fast these parts run.  After all,
you are comparing 90 nm Spartan 3s to 150 nm VirtexIIs.  It is very
possible that the S3s will run faster even with the added delays.  

I am sorry if my "nagging" is annoying.  But I have watched a lot of
changes in FPGAs and have often felt they were not for the better.  But
somewhere around the Virtex or VirtexII parts I started to realize that
I needed to forget about how the parts were different and focus on how
to solve my design problems using them.  With that I have come to
understand that often what I saw as a limitation is more than made up
for in other areas.  I am sure that Xilinx does not remove functionality
without considering the trade offs very seriously.  

-- 

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: 57524
Subject: Re: SPARTAN-3 vs. VIRTEX-II
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 02 Jul 2003 02:20:31 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Xilinx has two major product lines. Virtex is for performance and
> features, Spartan is for low cost. Otherwise, the architectures are very similar.
> 
> That gives us a chance to really optimize each line. The Spartan
> developers reduce the cost, accepting that this makes their devices
> non-optimal for certain applications, but there is always Virtex to
> deliver higher functionality and performance (at a higher price).
> The Virtex designers can optimize functionality and speed, knowing that
> this might increase the cost, but there is always Spartan to satisfy
> less performance-critical, but more cost-sensitive applications.
> 
> There is no free lunch, in engineering almost everything is a trade-off.
> But everybody still asks for champagne on a beer budget  :-)
> Peter Alfke

I am not looking for champagne on a beer budget, but I would sure like
to be able to pour them both into the same glass.  That is I would like
to have one footprint that I an put a Spartan into for low cost or a
Virtex when I need high performance and large size.  

-- 

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