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 21000

Article: 21000
Subject: xilinx synthesis tool
From: "Björn Lindegren" <bjorn.lindegren@home.se>
Date: Thu, 2 Mar 2000 21:56:01 +0100
Links: << >>  << T >>  << A >>
Do Xilinx synthesis tool support std_logic_signed / unsigned?

Björn Lindegren



Article: 21001
Subject: Re: Xilinx Tools Vs Altera tools
From: David Bishop <dbishop@vhdl.org>
Date: Thu, 02 Mar 2000 16:06:33 -0500
Links: << >>  << T >>  << A >>
Bob Baman wrote:
> 
> Ray,
> 
> Since you are in the subject of optimization, how is fmax affected for
> better or worse by FPGA Express versus Synplify synthesis?

fpga_express doesn't even take fmax into account when it does it synthesis.
Synplicity does.

-- 
David W. Bishop           INTERNET: dbishop@vhdl.org            (  \  )
US MAIL:  Hilton NY 14468-9101      A Long time ago,             \__\/
PHYSICAL: 43:17:17N 77:47:37W 281'  In a Galaxy far, far away...  | |
For Supernova info:  http://www.ggw.org/asras/snimages            | |
For VHDL/Synthesis info:  http://www.vhdl.org/siwg              _/___\_
All standard disclaimers apply.                                [_______]
Article: 21002
Subject: DLL Details of Xilinx Virtex FPGAs
From: "Nestor" <nestor@ece.concordia.ca>
Date: Thu, 02 Mar 2000 21:28:51 GMT
Links: << >>  << T >>  << A >>
Hi.

Would anyone know the intricate details of how the Delay-Locked Loop (DLL)
in Virtex devices is implemented?  Is it asynchronous using a tapped-delay
line?  Aside from the appnote (xapp132) and general DLL information in the
Xilinx databook, I couldn't find anything more specific.

I am very interested in building a DLL, but if not possible, at least gain a
very good understanding of this new device.  I thought I would start with
xilinx since they have already implemented it in their FPGAs.  I would
greatly appreciate any information on the topic of DLLs, including any
recent references on the subject.

Thanks in advance to all who can help.

Nestor


Article: 21003
Subject: Re: xilinx synthesis tool
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Thu, 2 Mar 2000 14:46:19 -0700
Links: << >>  << T >>  << A >>
Björn Lindegren wrote in message
<8AAv4.3428$yw1.7286@nntpserver.swip.net>...
>Do Xilinx synthesis tool support std_logic_signed / unsigned?

FPGA Express does ('cause it's a Synopys product).  however, you shouldn't
use those libraries.


--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Money is property; it is not speech."
            -- Justice John Paul Stevens



Article: 21004
Subject: Re: ORCA 3T - input/output delay reduction?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 02 Mar 2000 17:15:05 -0500
Links: << >>  << T >>  << A >>
Harald Simmler wrote:
> 
> Hi
> 
> I have a design where 4 ORCA 3T125  chips communicate together
> ( programmed in VHDL ). All four designs should run at arond 20 MHz.
> At least the P&R tools calculates that frequency on internal delays.
> 
> But the highest frequency on the board is only 8MHz.
> The FPGAs are directly connected by wires, so I think that this
> should not be the problem. I think that the PIO blocks which are
> programmed as input add an delay block at the
> input ( per default ? ) which has to be added to the internal
> tPD. And the output is set to slow ( also per default ? ).
> 
> Has anyone an idea what reduces the frequency and does anyone
> know how to disable the input delay or change the settings for the PIO
> blocks during P&R ( constrains  in the CHDL code or in a constrains file
> )??
> 
> Any help is needed.
> Thanks in advance.
> 
> H. Simmler

I would agree with Peter's comment that the input delay should not be
the cause of your problem. Also, this delay is only added when you are
using the input FF in the PIC (IOB in Xilinx terms). 

You did not say anything about your design. This is very possibly the
cause of your problems. By working in VHDL, you may well have a great
deal of logic in the input or output paths. This is much more likely the
cause of your problem. 

You should be using timing constraints on your design on both internal
paths as well as input and output paths. Lucent has recently improved
the utility of the input format for timing constraints so that this is
much easier to do. I believe that the current version of the back end
tools (Foundry) is 9.4. I am still using 9.35 which has the same
capability, but uses an intermediate file for some forms of constraints.
If you don't have version 9.4, I suggest that you get it. It should be
much easier to use in this regard. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21005
Subject: New name: DLLs, PLLs and videotape...
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 02 Mar 2000 17:59:58 -0500
Links: << >>  << T >>  << A >>
Don Husby wrote:
> 
> Ray Andraka <randraka@ids.net> wrote:
> > I thought the point to using a DLL was to get away from the analog circuit.
> 
> Speculating about the Lucent chip, I think they chose a tapped-delay DLL/PLL
> because it uses the best features of an analog/digital implementation.
> The tapped delay allows a coarse adjustment while allowing the analog
> part to operate with a small dynamic range.  The analog can then
> be implemented in a standard digital process.  Since it's in the feedback
> path, it doesn't have to be terribly linear, and it's probably just as
> tolerant of power and temperature fluctuations as a strictly digital DLL.
> Since the analog provides a fine adjustment, the digital part can have
> fewer taps (32), and doesn't have to spend a lot of effort on keeping
> individual tap delays within a tight tolerance.
> 
> --
> Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
> Fermi National Accelerator Lab                          Phone: 630-840-3668
> Batavia, IL 60510                                         Fax: 630-840-5406

I am jumping into this thread rather late, but I think the point of the
DLL is not the taps themselves, but that they can be used without a VCO.
Is that correct? If you still have a VCO it seems to me that you don't
get rid of all of the analog circuitry. 

I also don't think that tolerance is a problem with the digital delay
taps. I expect that they don't have to be held tightly to an exact
value, but they simply need to be kept to a small value to allow fine
adjustments. These delays are in the feedback path and any tolerance
variation would be corrected for just like an analog non-linearity. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21006
Subject: Re: DLL Details of Xilinx Virtex FPGAs
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Thu, 02 Mar 2000 15:21:43 -0800
Links: << >>  << T >>  << A >>
You could try the IBM patent server  http://www.patents.ibm.com -
Try ((delay) AND ( (Xilinx) <in> PA)) in the search field.
US05815016 looks like a possible implementation. Also try searching 
just for (delay locked loop). This returned 82 matches, many of which look
relevant. 

regards, tom

Nestor wrote:
> 
> Hi.
> 
> Would anyone know the intricate details of how the Delay-Locked Loop (DLL)
> in Virtex devices is implemented?  Is it asynchronous using a tapped-delay
> line?  Aside from the appnote (xapp132) and general DLL information in the
> Xilinx databook, I couldn't find anything more specific.
> 
> I am very interested in building a DLL, but if not possible, at least gain a
> very good understanding of this new device.  I thought I would start with
> xilinx since they have already implemented it in their FPGAs.  I would
> greatly appreciate any information on the topic of DLLs, including any
> recent references on the subject.
> 
> Thanks in advance to all who can help.
> 
> Nestor

-- 
Tom Burgess
-- 
Digital Engineer
Dominion Radio Astrophysical Observatory
Penticton, B.C. Canada V2A 6K3
Article: 21007
Subject: Re: New name: DLLs, PLLs and videotape...
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 02 Mar 2000 16:06:37 -0800
Links: << >>  << T >>  << A >>


Rickman wrote:

>
>
> I also don't think that tolerance is a problem with the digital delay
> taps. I expect that they don't have to be held tightly to an exact
> value, but they simply need to be kept to a small value to allow fine
> adjustments. These delays are in the feedback path and any tolerance
> variation would be corrected for just like an analog non-linearity.
>
> --
>

The issue is the amount of jitter. A purely digital VCO will never be right on
frequency, and the delay of each stage will vary with temperature and voltage.
This must be continuously adjusted, since the timing error would be cumulative. So
you would end up with a lot of jitter = one stage delay, almost each clock period.

This would be so ugly that, to my knowledge, nobody uses a purely digital PLL.

A mixed digital/analog VCO would be less ugly, but what does it do when the analog
correction has reached its limit and demands a digital step correction? How fast
can the analog circuit correct the new and different digital delay? During the
time of adaption, there is a large phase error = jitter.

Interesting subject.

Peter Alfke

Article: 21008
Subject: Comment on Atmel AT40K ?
From: "Peter Fenn" <PeteFenn@mindspring.com>
Date: Thu, 2 Mar 2000 17:02:22 -0800
Links: << >>  << T >>  << A >>
Hi
I am looking for 1st-hand comment from users of Atmel AT40K FPGA tools and
devices.
- What are the shortcomings?
- How does it compare to eg. Xilinx?
- How does architecture rate compared to other FPGA offerings out there?
- What is the "sweet-spot" in terms of price, performance,etc?
- Any other observations / tips appreciated

Thanks for all your input
Pete Fenn



Article: 21009
Subject: Re: Comment on Atmel AT40K ?
From: Ray Andraka <randraka@ids.net>
Date: Fri, 03 Mar 2000 01:13:09 GMT
Links: << >>  << T >>  << A >>
My stock answer:  It depends on the application.

The 40K's Achilles heel is the fact it has no fast carry logic.  That really
cripples its arithmetic performance/density when compared to Xilinx.  If you
don't need a carry chain (unfortunately, I can only think of a few
applications that don't benefit there), it's not all that bad a device.  I
truthfully have not looked at their software in a few years.  I would hope
that it has been improved.  Previously they were using Figaro, which was
dreadfully slow, especially when you tried to do any edits.  I think they
still give away the software for free.  You might test drive it to see what
you think.

Peter Fenn wrote:

> Hi
> I am looking for 1st-hand comment from users of Atmel AT40K FPGA tools and
> devices.
> - What are the shortcomings?
> - How does it compare to eg. Xilinx?
> - How does architecture rate compared to other FPGA offerings out there?
> - What is the "sweet-spot" in terms of price, performance,etc?
> - Any other observations / tips appreciated
>
> Thanks for all your input
> Pete Fenn

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21010
Subject: Re: restrictions due to signal types of Global Clock inputs for Virtex
From: krw@attglobal.net (Keith R. Williams)
Date: 3 Mar 2000 01:46:56 GMT
Links: << >>  << T >>  << A >>
On Thu, 2 Mar 2000 19:54:19, gzs@clark.net (George) wrote:

> 
> I have a multi-clock design I am doing in a Virtex XCV1000 device.
> All four global clock inputs are used and the I/O bank where one of
> the clock inputs enters the chip is SSTL2.  Xilinx tells me to make
> the clock be an SSTL2 signal.  This is no problem.  The FAE also tells
> me that I should not try to use this particular clock to clock any of
> the internal logic of the device, only the IO pads of the banks which
> are also SSTL2.
> 
> This is very hard for me to believe.  Does anyone know of any type of
> restriction on the uses of the global clocks depending on the Select
> IO types used for the clock inputs?

If this is true I'm truely screwed!  I'd like a clarification 
here too.  I'm using LVPECL clock generators and am planning to 
use these clocks for the entire chip.  Note that I am playing 
games with the clocks because I couldn't get Virtex-E parts on a 
reasonable schedule.  If these games come back to bite...

----
  Keith
Article: 21011
Subject: SpartanXL route and place
From: krw@attglobal.net (Keith R. Williams)
Date: 3 Mar 2000 02:05:05 GMT
Links: << >>  << T >>  << A >>

I'll admit to being a novice at FPGA/s and Xilinx in particular, 
but I can't have missed this much.  I'm doing a board with a 
SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I
can get them).  I'm using Synplify as the design tool and then 
into Alliance.  Alliance is taking *forever* to to Place-N-Route.
 I started with a 56% or so full device (both Synplify and 
Alliance agreed within reason) and then went to wire.  After 
*hours* it gave up saying that I had hundreds of un-routed nets. 
After tweaking the design (it was very crude) down to where I now
have less than 25% used, it still takes *hours* to P&R with 
rather unsatisfactory results. I have to put it through the 
re-entrant roter to get it to wire at all.  I left affter two 
hours of this today (it's a PII-333 running NT). This is a 
*simple* design.

1)  What the hell am I doing wrong?  Is this normal?

2)  If I can extrapolate this to my Virtex (XCV600-FG680, btw) 
design, I'll grow foot-long fingernails waiting for routing (if I
don't bite them off first).  Is Spartan not routable?  Is Virtex 
better?  (good grief, I hope so!)

3)  Can I make simple changes (pinouts and such) without 
re-routing completely?  

4)  Or, am I all wet, and pushing the wrong buttons?  It would be
nice to be able to tell Alliance to use the re-entrant router 
from the beginning, and then go home.

Oh, my head hurts! I've had full head of grey hair for 20 years, 
but me think's it's coming out now!

----
  Keith


Article: 21012
Subject: Re: New name: DLLs, PLLs and videotape...
From: muzo <muzok@nospam.pacbell.net>
Date: 02 Mar 2000 21:09:02 EST
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote:
>The issue is the amount of jitter. A purely digital VCO will never be right on
>frequency, and the delay of each stage will vary with temperature and voltage.
>This must be continuously adjusted, since the timing error would be cumulative. So
>you would end up with a lot of jitter = one stage delay, almost each clock period.
>
>This would be so ugly that, to my knowledge, nobody uses a purely digital PLL.

I don't think this is true. There are pure digital ways of subdividing
the delay of a single stage. I have seen at least two papers relating
to this subject. The idea is to control the rise time of a signal in
one of the stages. One way to do this is to have a very large load at
the output of multiple tri-state drivers. The more drivers you enable
the faster the rise time. This can be implemented with a standard cell
library and can be characterized with spice after AP&R. Look at recent
ISSCC papers.

Article: 21013
Subject: Re: Error in Xilinx application note XAPP131?
From: Manfred Kuhland <man@atlantek.com.au>
Date: Thu, 02 Mar 2000 16:25:09 -1030
Links: << >>  << T >>  << A >>
Hi Steve,
The information given in XAPP131 is correct. The comments refer to
the FALLING edges of the Empty and Full flags, i.e. the Empty signal may
stay high (empty) for one more clock cycle after the first word has been
written to the FIFO. However, the same does NOT apply to the rising edges.
In other words, the Empty flag will always be high when the FIFO is actually

empty but it may delay flagging the non-empty status by one clock cycle.

Hope this helps,

Manfred Kuhland
------------------------------------------------------------------------
Atlantek Microsystems Pty Ltd,  Innovation House, Technology Park,
Mawson Lakes, SA, 5095, AUSTRALIA
Tel:         +61-8-8260-8990         Fax:        +61-8-8349-4286
E-mail:    man@atlantek.com.au    Internet:  http://www.atlantek.com.au
------------------------------------------------------------------------


Steve Charlwood wrote:

> Hi all,
>
> I'm using a FIFO design based on Xilinx's synchronous FIFO with
> independent clocks, described in XAPP131. In this, it states that in the
> worst-case scenario (due to the asynchronous nature of the READ and
> WRITE clocks), the FULL and EMPTY flags would simply stay active one
> cycle longer and that this would _not_ generate an error.
>
> I have a simulation in which EMPTY goes low, indicating that there is
> data to be read from the FIFO, and then, due to the clock edges from the
> two different domains coinciding, the signal is forced into an unknown
> state, which could be high or low. In the case where the signal is
> actually interpreted as low, the FIFO would indicate that it was not
> empty, when in fact it might be. This causes a problem when trying to
> read data from the FIFO using the EMPTY signal as the read enable: for
> each occurence, and additional word may be inserted into the data
> stream.
>
> Does anyone know of a solution to this problem (apart from avoiding the
> use of multiple clock domains!).
>
> Cheers,
>
> Steve
>
>
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>   Heterogeneous, Parallel & Reconfigurable Architectures Group
>   School of Electronic & Electrical Engineering
>   University of Birmingham, Edgbaston, Birmingham, B15 2TT
>   e-mail: s.m.charlwood@bham.ac.uk
>   tel: +44 (0)121-414-4340 (shared)/fax: +44 (0)121-414-4291
>
>   Signal Processing & Imagery Department
>   Defence Evaluation & Research Agency (DERA)
>   DERA Malvern, St. Andrews Road, Malvern, Worcs., WR14 3PS
>   e-mail: charlwood@signal.dera.gov.uk
>   tel: +44 (0)1684-895452 (shared)/fax: +44 (0)1684-894389
>
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Article: 21014
Subject: Virtex decoupling cap considerations...
From: "Matt Billenstein" <mbillens@one.net>
Date: Fri, 03 Mar 2000 03:55:08 GMT
Links: << >>  << T >>  << A >>
I just got back a board the other day with a Virtex XCV50FG256-4 FPGA
running largely at 40 MHz...  And I'm using most of the available 180 user
i/o.  The thing that always mistified me about the decoupling of the device
was simply the number and size of the caps.  Xilinx recommends a total of 10
47uF low ESR Tantalum caps as well as a 470uF tantalum to decouple the
Vccint and Vcco power pins of the device... as well as a 0.1uF cap per
Vccint and Vcco pin as I recall...  Well as some of you might also be
experiencing, I'm having trouble finding *any* tantalum caps in the
footprint that I needed for this design, so I decided to try and bring up
the board without any of the 10 47uF caps and also without the 470uF cap.  I
only had the 0.1uF caps in house to populate the board.  Turns out that the
design appears to work flawlessly without any of these decoupling caps and
I'm standing here wondering why I sacrificed board space for all of these
damn caps...  I see very little (if any) ground bounce or ripple on the
power planes...  Just some advice for those of you attemping similar
designs...

m



Matt Billenstein
2373 Rohs Street
Cincinnati, OH  45219
Home:  513-651-2376
Work:  513-573-6832
http://w3.one.net/~mbillens/
mbillens@one.net




Article: 21015
Subject: Re: SpartanXL route and place
From: Phil Hays <Spampostmaster@sprynet.com>
Date: Thu, 02 Mar 2000 19:57:11 -0800
Links: << >>  << T >>  << A >>
"Keith R. Williams" wrote:
 
>  Alliance is taking *forever* to to Place-N-Route.
>  I started with a 56% or so full device (both Synplify and
> Alliance agreed within reason) and then went to wire.  After
> *hours* it gave up saying that I had hundreds of un-routed nets.

> After tweaking the design (it was very crude) down to where I now
> have less than 25% used, it still takes *hours* to P&R with
> rather unsatisfactory results. I have to put it through the
> re-entrant roter to get it to wire at all.  I left affter two
> hours of this today (it's a PII-333 running NT). This is a
> *simple* design.

> 1)  What the hell am I doing wrong?  Is this normal?

Without looking at your design I can't be sure of exactly what you are doing
wrong, however it seems too common that the first FPGA design turns into this
sort of disaster.  What I suspect is that you have logic that needs some
restructuring and I suspect you probably need to do a little floorplanning. 
After doing one or both, your run time will be much shorter.


> 2)  If I can extrapolate this to my Virtex (XCV600-FG680, btw)
> design, I'll grow foot-long fingernails waiting for routing (if I
> don't bite them off first).  Is Spartan not routable?  Is Virtex
> better?  (good grief, I hope so!)

The Virtex is rather more routable.  You still may need to floorplan to improve
the design's speed.


> 3)  Can I make simple changes (pinouts and such) without
> re-routing completely?

It is probably best to re-route every time.


> 4)  Or, am I all wet, and pushing the wrong buttons?  It would be
> nice to be able to tell Alliance to use the re-entrant router
> from the beginning, and then go home.

You can write a simple batch, make or script file that will do a re-entrant
route from the beginning.  I don't know how to do this from the GUI.


-- 
Phil Hays
"Are you willing to vote for funding the completion 
of the third report of the IPCC"?  Ask the question!
Article: 21016
Subject: Re: Comment on Atmel AT40K ?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 02 Mar 2000 23:21:07 -0500
Links: << >>  << T >>  << A >>
I was following an earlier thread on multipliers IIRC that used a lot of
non ripple adders. In this type of application, wouldn't the Atmel parts
do well since they are a finer grained architecture? They should be able
to provide more bits for the buck since they have a simpler structure
and lend themselves well to an ordered array with direct interconnect.
Again, IIRC systolic or array logic is about the only area where they
show well. 



Ray Andraka wrote:
> 
> My stock answer:  It depends on the application.
> 
> The 40K's Achilles heel is the fact it has no fast carry logic.  That really
> cripples its arithmetic performance/density when compared to Xilinx.  If you
> don't need a carry chain (unfortunately, I can only think of a few
> applications that don't benefit there), it's not all that bad a device.  I
> truthfully have not looked at their software in a few years.  I would hope
> that it has been improved.  Previously they were using Figaro, which was
> dreadfully slow, especially when you tried to do any edits.  I think they
> still give away the software for free.  You might test drive it to see what
> you think.
> 
> Peter Fenn wrote:
> 
> > Hi
> > I am looking for 1st-hand comment from users of Atmel AT40K FPGA tools and
> > devices.
> > - What are the shortcomings?
> > - How does it compare to eg. Xilinx?
> > - How does architecture rate compared to other FPGA offerings out there?
> > - What is the "sweet-spot" in terms of price, performance,etc?
> > - Any other observations / tips appreciated
> >
> > Thanks for all your input
> > Pete Fenn
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21017
Subject: Re: Virtex decoupling cap considerations...
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 02 Mar 2000 23:54:09 -0500
Links: << >>  << T >>  << A >>
Matt Billenstein wrote:
> 
> I just got back a board the other day with a Virtex XCV50FG256-4 FPGA
> running largely at 40 MHz...  And I'm using most of the available 180 user
> i/o.  The thing that always mistified me about the decoupling of the device
> was simply the number and size of the caps.  Xilinx recommends a total of 10
> 47uF low ESR Tantalum caps as well as a 470uF tantalum to decouple the
> Vccint and Vcco power pins of the device... as well as a 0.1uF cap per
> Vccint and Vcco pin as I recall...  Well as some of you might also be
> experiencing, I'm having trouble finding *any* tantalum caps in the
> footprint that I needed for this design, so I decided to try and bring up
> the board without any of the 10 47uF caps and also without the 470uF cap.  I
> only had the 0.1uF caps in house to populate the board.  Turns out that the
> design appears to work flawlessly without any of these decoupling caps and
> I'm standing here wondering why I sacrificed board space for all of these
> damn caps...  I see very little (if any) ground bounce or ripple on the
> power planes...  Just some advice for those of you attemping similar
> designs...
> 
> m
> 
> Matt Billenstein
> 2373 Rohs Street
> Cincinnati, OH  45219
> Home:  513-651-2376
> Work:  513-573-6832
> http://w3.one.net/~mbillens/
> mbillens@one.net

Hey, if some is good and more is better... then too much is just enough!
If they (Xilinx) don't know what you are putting in the chip, then they
really can't tell you how to decouple it. So they are very conservative
in saying to use lots and lots of microfarads. 

There was a thread here a few weeks ago on this very topic. I believe
there was a reasonable concensus that the app notes are a bit of
overkill. 

In particular, I have read some good app notes from the cap
manufacturers as well as an article in EDN or Electronic Design IIRC,
that discussed decoupling in great detail. It had a lot of eye opening
info for me that I had never heard before. For example, at the
frequencies of interest (typically > 100 MHz even for designs with slow
clocks) all caps, including the high freq ceramics, are inductive! But
that does not matter as long as the impedance is still low. With a lot
of ceramic caps around the power plane, the effective impedance can be
quite low. The tantalum caps that everyone uses on their boards are
really only needed for low frequency effects and placement largely does
not matter (unless you are using traces for power instead of power
planes). So the dozen or so that Xilinx is recommending will most likely
never be needed. 

One poster discussed a unique design method that isolated regions of the
power plane (not the ground plane) to form "islands" of noise isolation.
One ceramic cap per island was enough to do the job according to the
theory. I would like to learn more about this technique, but I don't
have the time just now to write to the professor that was listed as a
resource. 

My current method is to use a 0.1 uF ceramic cap on each power/gnd pin
pair. I keep the leads fanatically short and never use a cap for more
than one chip although I sometimes connect two adjacent pins to one cap.
It seems to work well so far. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 21018
Subject: Re: SpartanXL route and place
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Fri, 03 Mar 2000 08:32:02 +0200
Links: << >>  << T >>  << A >>
Keith R. Williams wrote:

> I'll admit to being a novice at FPGA/s and Xilinx in particular,
> but I can't have missed this much.  I'm doing a board with a
> SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I
> can get them).  I'm using Synplify as the design tool and then
> into Alliance.  Alliance is taking *forever* to to Place-N-Route.
>  I started with a 56% or so full device (both Synplify and
> Alliance agreed within reason) and then went to wire.  After
> *hours* it gave up saying that I had hundreds of un-routed nets.
> After tweaking the design (it was very crude) down to where I now
> have less than 25% used, it still takes *hours* to P&R with
> rather unsatisfactory results. I have to put it through the
> re-entrant roter to get it to wire at all.  I left affter two
> hours of this today (it's a PII-333 running NT). This is a
> *simple* design.
>
> 1)  What the hell am I doing wrong?  Is this normal?

Please check if there is any patch available in Xilinx.
Search Xilinx on-line documents carefully. There might
be information regarding XCS40XL-BG256.

Please post to the newsgroup, the condition, where the tool
runs mostly. For example, a few months ago, an engineer
told here that when the tool is trying to route PWR/GND
signals it is found it takes too much time to route PWR/GND.
AFAIK it is found that PWR/GND distribution has to be done
per module basis or not from the same sources. The engineer
had given us the place of the report where the tool runs
mostly.

Have you given UCF correctly? You must give:
- clock constraints
- offset constraints
- multiple clock domain constraints

Sometimes forgetting these parameters by unchance might
lead excessive routing times.

> 2)  If I can extrapolate this to my Virtex (XCV600-FG680, btw)
> design, I'll grow foot-long fingernails waiting for routing (if I
> don't bite them off first).  Is Spartan not routable?  Is Virtex
> better?  (good grief, I hope so!)

Virtex and Virtex-E devices have very rich routing resources.
Some engineer told here that he achieved more than 90%
routing resource usage of Virtex. I know another engineer
personally who showed me that their team have successfully
used 94% routing resources of Virtex XCV1000.

> 3)  Can I make simple changes (pinouts and such) without
> re-routing completely?

Probably no.

> 4)  Or, am I all wet, and pushing the wrong buttons?  It would be
> nice to be able to tell Alliance to use the re-entrant router
> from the beginning, and then go home.

As Phil stated, "make" under UNIX might help you very much.
There is no way in GUI to perform batches. It is a must to get
rid of GUI to perform batch for these tools.

> Oh, my head hurts! I've had full head of grey hair for 20 years,
> but me think's it's coming out now!

Hope this helps.

Utku

--
I feel better than James Brown.



Article: 21019
Subject: Re: Delay Lines using FPGA ??
From: "henry" <henry1@nelson192.freeserve.co.uk>
Date: Fri, 3 Mar 2000 08:18:55 -0000
Links: << >>  << T >>  << A >>

Phil Hays <Spampostmaster@sprynet.com> wrote in message
news:38BCA455.75197C0B@sprynet.com...
> henry wrote:
>
> > i was wondering if a delay line could be made easily in an fpga and if
so
> > are there any
> > limitations ie. max delay, max frequency.
>
> The main limitation is accuracy.  A range exceeding three to one should be
> expected over process, temperature and voltage.  Example: if the longest
delay
> is 30 ns, the shortest would be less than 10 ns.
>
> A better way to handle the same problem is a digital delay of some sort.
> Perhaps a high frequency clock runs a counter for the number of cycles
that
> makes up the delay.
>
>
> --
> Phil Hays




thanks for all the replies,

chears

henry


Article: 21020
Subject: Re: xilinx synthesis tool
From: "Sherdyn" <sherdyn@yahoo.com>
Date: Fri, 3 Mar 2000 17:21:21 +0800
Links: << >>  << T >>  << A >>
Why can't we use it?

Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in message
news:89mnlc$13nf$1@noao.edu...
> Björn Lindegren wrote in message
> <8AAv4.3428$yw1.7286@nntpserver.swip.net>...
> >Do Xilinx synthesis tool support std_logic_signed / unsigned?
>
> FPGA Express does ('cause it's a Synopys product).  however, you shouldn't
> use those libraries.
>
>
> --
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "Money is property; it is not speech."
>             -- Justice John Paul Stevens
>
>
>


Article: 21021
Subject: Re:
From: Jerry English <jenglish@planetc.com>
Date: Fri, 03 Mar 2000 08:20:43 -0500
Links: << >>  << T >>  << A >>
You might want to look around in Texas Instruments web site for
app notes on line drivers and transmission theory.
http://www.ti.com/cgi-bin/sc/search.cgi

I'm in no way connected to TI. Its just that they had some really good
app notes in this area.

regards
Jerry

Sherdyn wrote:

> It may not be appropriate to pose this question here but I do hope that
> someone may be able to tell me what would be the maximum transmission rate
> for a 1 meter ribbon cable length distance.
>
> sherdyn

Article: 21022
Subject: Re: New name: DLLs, PLLs and videotape...
From: husby@fnal.gov (Don Husby)
Date: Fri, 03 Mar 2000 15:12:12 GMT
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> wrote:
> I am jumping into this thread rather late, but I think the point of the
> DLL is not the taps themselves, but that they can be used without a VCO.
> Is that correct? If you still have a VCO it seems to me that you don't
> get rid of all of the analog circuitry. 

Instead of a fully-analog VCO, the lucent chips implement a 
Voltage-Controlled delay line.  Again, this seems to offer the best
of both worlds:
Tap selection sets the coarse frequency- easy to implement becuse there
are fewer taps, and you don't need to match path delays to the nearest
picosecond.
Fine adjustments are made within a limited linear range- easy to implement
because you can implement it with the same transistors that you use for
the digital part.  You don't need to use extreme analog design rules.

> I also don't think that tolerance is a problem with the digital delay
> taps. I expect that they don't have to be held tightly to an exact
> value, but they simply need to be kept to a small value to allow fine
> adjustments.

You have to make sure that the delay from tap N is not greater than the
delay from tap N+1.  If you're talking a few picoseconds per tap, and
hundreds of taps, this is not easy.

> These delays are in the feedback path and any tolerance
> variation would be corrected for just like an analog non-linearity. 

Not true.  See above.


--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 21023
Subject: Re: SpartanXL route and place
From: "Monte Dalrymple" <monted@systemyde.com>
Date: Fri, 3 Mar 2000 07:37:52 -0800
Links: << >>  << T >>  << A >>

Keith R. Williams wrote in message ...
>
>I'll admit to being a novice at FPGA/s and Xilinx in particular,
>but I can't have missed this much.  I'm doing a board with a
>SpartanXL (XCS40XL-256BG) part and a Virtex (will go to -E when I
>can get them).  I'm using Synplify as the design tool and then
>into Alliance.  Alliance is taking *forever* to to Place-N-Route.
> I started with a 56% or so full device (both Synplify and
>Alliance agreed within reason) and then went to wire.  After
>*hours* it gave up saying that I had hundreds of un-routed nets.
>After tweaking the design (it was very crude) down to where I now
>have less than 25% used, it still takes *hours* to P&R with
>rather unsatisfactory results. I have to put it through the
>re-entrant roter to get it to wire at all.  I left affter two
>hours of this today (it's a PII-333 running NT). This is a
>*simple* design.
>
>1)  What the hell am I doing wrong?  Is this normal?
>

How much memory does your machine have? I had a design that
fit nicely in a 4085 that could not complete the route before the MTBF
of the machine with 256M of memory, but routed in about an hour on
a machine with 1024M of memory...   (ouch, $$$)

Monte

<snip>




Article: 21024
Subject: Re: DLL Details of Xilinx Virtex FPGAs
From: "Nestor" <nestor@ece.concordia.ca>
Date: Fri, 03 Mar 2000 15:53:54 GMT
Links: << >>  << T >>  << A >>
Thanks.  I am looking at it right now.

Nestor


--
> You could try the IBM patent server  http://www.patents.ibm.com -
> Try ((delay) AND ( (Xilinx) <in> PA)) in the search field.
> US05815016 looks like a possible implementation. Also try searching
> just for (delay locked loop). This returned 82 matches, many of which look
> relevant.
>
> regards, tom
>
> --
> Tom Burgess
> --
> Digital Engineer
> Dominion Radio Astrophysical Observatory
> Penticton, B.C. Canada V2A 6K3




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