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 25700

Article: 25700
Subject: Re: virtex shape
From: "John L. Smith" <jsmith@visicom.com>
Date: Sun, 17 Sep 2000 20:04:54 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------CEFFA3346C3F66A14102E20A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> >  erika_uk@my-deja.com wrote:
> > > why virtex chips are rectangular and not square

 Why not?
 Seriously, is there an inherent advantage to the square
for tiling the design space or the wafer? ( I used to wonder
why the chips were not triangular or hexagonal.)

In my work, the rectangle is probably a better shape.
 We do image processing, and since the parts still don't
have enough internal ram for a complete frame buffer,
we need to hang external banks of memory. If the processing
is viewed as a pipeline, where the FPGA resident stuff is
on top, and RAM storage is below:

 in-->( per/pixel  )   ( warping )    ( Feature    ) 
      ( processing )   (         )    ( Extraction ) --> out
               |       / \     |        / \ 
               |        |      |         |  
              \ /       |     \ /        |  
           [ Frame Store 1]  [ Frame Store 2 ]

(this is not a real application here, just to illustrate!)

The rectangle is a more natural ( form-fitting) container
for pipelined processes. Think of extending/enlarging the
pipeline...with a rectangle, I/O never gets too far from
the center(line), and I/O grows almost proportional to chip
area. With a square, I/O grows proportional only to square
root of chip area, and the center continually gets farther
from the I/O.
--------------CEFFA3346C3F66A14102E20A
Content-Type: text/x-vcard; charset=us-ascii;
 name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
 filename="jsmith.vcf"

begin:vcard 
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard

--------------CEFFA3346C3F66A14102E20A--

Article: 25701
Subject: Re: Are SpartanIIs in FG456 drop in replacements for Virtex FG456
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 17 Sep 2000 23:15:37 -0400
Links: << >>  << T >>  << A >>
"S. Ramirez" wrote:
> 
> Rick,
>      Excellent idea to have an app note discussing the differences so that
> Virtex savvy engineers can switch over quickly.  There has been much
> discussion of this on this newsgroup, and I also think it's worthy of an app
> note in order to clarify most things that comes up.  From what I understand,
> here are the differences:
>          1) temperature sensitive diodes missing on Spartan II
>          2) core (CLB) transistors are 0.18u on Spartan II and 0.25u on
> Virtex
>          3) Spartan IIs come in limited (read: cheapest) packaging
>          4) Spartan IIs are viperware as I write (no need for this
>              to be in the app note)
>     Are you listening, Xilinx?
> -Simon Ramirez, Consultant
> -Synchronous Design, Inc.
> 
> Note:  viperware (vïpêr·wär) n. something that will bite you if you design
> it in and don't have the parts in hand.

I like the viperware definition. But I am not sure you have the
transistor size thing right. If I understand it correctly, the
semiconductor features are the same as Virtex so that the voltage does
not need to be lowered. But the metal pitch is smaller to reduce die
size. Not that this is an issue with using the part.

I would bet that there are some differences in the internal design of
the part. They may be small, but it would be worth an app note to
clearly document them *all*!


-- 

Rick 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

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

Internet URL http://www.arius.com
Article: 25702
Subject: Re: virtex shape
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 18 Sep 2000 03:24:49 GMT
Links: << >>  << T >>  << A >>
	Looking at the V2000E, (80 x 120 array), the amount of actual
area taken up by the BlockRAMs is pretty mild, definatly not the 30%
required to skew things.

	I suspect it is just how it is layed out, combined with some
asymetries in the routing (the clock lines are vertically arranged).
The resulting die is square.


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 25703
Subject: Re: hardware compatibility and patent infringement
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Mon, 18 Sep 2000 08:43:08 +0200
Links: << >>  << T >>  << A >>


--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:39C37C92.FB919779@yahoo.com...
> Ulf Samuelsson wrote:
> > The it follows logically that the context must be protected from
> > another interrupt until the CPU has saved the current context.
> > Yet they patent it. Ridiculous.....
>
> I would like to understand this. You can't patent a concept, how did
> they reduce this to practice? If they have no hardware to save context,
> what did they patent, the software to save context, disabling interrupts
> or what?
They have hardware resources for storing the context, but the
processor does not no it automatically in a reentrant way.
I.E: Pushing return address on a stack while incrementing the stackpointer.
Instead the ARM stores the return address in an internal register which
is common for all interrupts.

It this was the only feature you have a problem.
Guess what happens if you get two interrupts?
The second interrupt overwrites the internal register.
So they disable the interrupt.
The core of the patent is that they disable "interrupts" while allowing
other exceptions to happen. (Page Fault, Fast Interrupt (which uses
a separate register)

In my opinion , as long as you decide to do interrupt handling in S/W
(which is prior art) and you want to have an exception register
and MMU , the rest is obvious.
Patent is 5,701,493

>
> > In the light of the ARM threats to the  "www.open-cores.com"  activity
it
> > would be interesting to see how easy  the ARM patents would fall down in
> > court...."
>
> I have not heard of the conflict with ARM. Is there a web page
> discussing it?
I saw that www.open-cores.com got a threatening letter when
they published their FPGA core implementation. -> www.altavist.com ?
ARM has sued some U.S. company that cloned the core.
They claim they do not violate the patents.
> --
>
> Rick 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
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 25704
Subject: Re: Good FPGA prototyping boards?
From: "Ulf Samuelsson" <ulf@atmel.spammenot.com>
Date: Mon, 18 Sep 2000 08:51:35 +0200
Links: << >>  << T >>  << A >>

<default@user.com> wrote in message news:39C2F1C4.6D15B439@user.com...
> Hello, a few months back I purchased an XS40-010XL+ from XESS
> corporation (http://www.xess.com.)  The board is populated with an
> 8051uC and Xilinx XC4010XL ("10k system gates") FPGA, with a 128k X 8
> async SRAM chip.  The board has its own VGA connector (you are
> responsible for implementing the display controller circuit), a PS/2
> keyboard connector, and standard connector headers giving access to all
> 84 I/O pins of the FPGA.
>
> Initially, the board was great, but I've since discovered 10k gates
> isn't a whole lot at all!  So now I'm looking to move up to a larger
> FPGA board.

The Atmel  STK40  has 2 x size (AT40K20) and is about $150-200.
Check at www.kanda-systems.com
It has a socket for an AVR (8515) and I think you may be able to put an 8051
there.
No external memory though.

If you wait for a month or two, you may be able to get your hands on the
brand new
FPSLIC demoboard.
I think it will be about the same price and has an AVR integrated w 36 kB of
SRAM.

--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden





Article: 25705
Subject: Re: Clock skew in XILINX CPLD
From: Nial Stewart <nials@sqf.hp.com>
Date: Mon, 18 Sep 2000 09:48:14 +0100
Links: << >>  << T >>  << A >>
"S. Ramirez" wrote:
> 
> Nial,

snip ><

>      The real answer to your question, though, is to know the system that
> you are working with in order to understand which signals are asynchronous,
> which are protocol stabilized, which are skewed relative to your clock, and
> which are synchronous.  By knowing these parameters, you can take advantage
> of the properties of these signals and design a synchronous system that is
> reliable and fast.
> -Simon Ramirez, Consultant
> -Synchronous Design, Inc.

Ah,

I thought you had some magic technique for guaranteeing that you'd
properly
received a parallel word that was generated asynchronously with no other
info.

The only way of doing this I can think of would be to synchronise the
input 
twice and only accept the input when the two values are identical.

Nial.
Article: 25706
Subject: Re: Clock skew in XILINX CPLD
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Mon, 18 Sep 2000 12:17:46 GMT
Links: << >>  << T >>  << A >>
Nial,
     Unfortunately, there is no magic in this department.  The synchronizing
of asynchronous signals takes clock cycles.  Your method takes clock cycles,
as mine does.
     The important thing is to recognize when we don't need to synchronize
asynchronous signals, which wastes time and resources.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.


> Ah,
>
> I thought you had some magic technique for guaranteeing that you'd
> properly
> received a parallel word that was generated asynchronously with no other
> info.
>
> The only way of doing this I can think of would be to synchronise the
> input
> twice and only accept the input when the two values are identical.
>
> Nial.
>


Article: 25707
Subject: Bluetooth core??
From: khatib@ieee.org
Date: Mon, 18 Sep 2000 12:53:32 GMT
Links: << >>  << T >>  << A >>
Hi,
Me and some young engineers (students and non-students) like get more
practice in digital design by doing a real design.
We found that the bluetooth technology is a new technology and may have
good future even in a home made systems.

Could you please help us on the following questions:
1. Is there any avialable cores for this technology that we can learn
from?
2. how large is this core going to be?
3. where can I find information about implementing it?
4. can a group of 3 young engineers work on it?
5. Is ther any possibility to implement a device at home with this core?
6. can we implement it on FPGA?
7. Does it worth the time or should we look for another technology to
learn from?


Thanks in advance
Jamil Khatib


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25708
Subject: Re: Are SpartanIIs in FG456 drop in replacements for Virtex FG456
From: Ray Andraka <ray@andraka.com>
Date: Mon, 18 Sep 2000 13:43:50 GMT
Links: << >>  << T >>  << A >>


"K. Orthner" wrote:
> 
> daniel.deconinck@sympatico.ca (Dan) wrote:
> >The Spartan II has three sizes that come in the FG456 package:
> <snip>
> >The Spartan II has three sizes that come in the FG456 package:
> <snip>
> >Are the footprints interchangable ???
> 
> I asked this question of Xilinx support, and this was their answer:
> 
> <open quote>
> 
> Hi Kent,
> There are actually some minor pinnout differences between the two:
> 
> The Virtex DXN and DXP pins have been replaced w/ STARTUP and PWRDN pins in
> the Spartan-II.
> 
> Those are the only differences.
> 
> <close quote>
> 
> ** Note
> 1. The pin is called "STATUS", not "STARTUP" in the data sheet
> (DS001/03/03/2000).
> 
> 2. /PWDN should be pulled high for normal operation.  (So thereis a tiny
> PCB change).

If you do your board design for SpartanII you can put the matching virtex in its
place, as long as you don't use the powerdown feature.  Note that in virtex,
pulling up that pin has no effect on the temp diode.  I've got one customer with
his early boards populated with XCV50-4 FG256s and the later ones with XC2S50-5
FG256s.  We purposely did the board to accept both.  So far the only differences
we have noted are the temp diode, which we don't use.  Also the spartanII is a
little faster than the virtex-4, and the cost is considerably less.  We're
loading the same bitstream into both parts.

> 
> -Kent

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25709
Subject: Re: Clock skew in XILINX CPLD
From: Ray Andraka <ray@andraka.com>
Date: Mon, 18 Sep 2000 13:49:39 GMT
Links: << >>  << T >>  << A >>
The best way I've found for general purpose parallel is create one extra signal
with a toggle flip flop toggled by writing valid data to a register.  On the
second clock side, you have a wrtie pulse generator that is triggered when it
senses a change in the level on the synchronized flag, and then that is used to
transfer the data from the common holding register across the clock domain
boundary.  It can be pipelined a little, but you do generally still need 2 or 3
clocks on the recieving side per clock on the transmit side.  You can put
parallel circuits to maintain the data rate.

Nial Stewart wrote:
> 
> "S. Ramirez" wrote:
> >
> > Nial,
> 
> snip ><
> 
> >      The real answer to your question, though, is to know the system that
> > you are working with in order to understand which signals are asynchronous,
> > which are protocol stabilized, which are skewed relative to your clock, and
> > which are synchronous.  By knowing these parameters, you can take advantage
> > of the properties of these signals and design a synchronous system that is
> > reliable and fast.
> > -Simon Ramirez, Consultant
> > -Synchronous Design, Inc.
> 
> Ah,
> 
> I thought you had some magic technique for guaranteeing that you'd
> properly
> received a parallel word that was generated asynchronously with no other
> info.
> 
> The only way of doing this I can think of would be to synchronise the
> input
> twice and only accept the input when the two values are identical.
> 
> Nial.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25710
Subject: Looking for an Altera APEX eval board
From: "Mikhail Matusov" <matusov@ANNTIsquarepegSPPAMM.ca>
Date: Mon, 18 Sep 2000 14:12:22 GMT
Links: << >>  << T >>  << A >>
Are there any available?

--
============================
Mikhail Matusov
Hardware Design Engineer
Square Peg Communications
Tel.: 1 (613) 271-0044 ext.231
Fax: 1 (613) 271-3007
http://www.squarepeg.ca


Article: 25711
Subject: Re: Reassurance on Xilinx Sought
From: Ray Andraka <ray@andraka.com>
Date: Mon, 18 Sep 2000 14:15:47 GMT
Links: << >>  << T >>  << A >>
Sounds like you didn't pay any attention whatsoever as to the chip architecture,
and you attempted to let the tools do everything without any tailoring for a
cheaper, faster, better implementation.

I routinely utilize upwards of 75% of the resources in Xilinx parts, with some
just about reaching 100%.  Many of these report equivalent gates numbers that
are 120% or more of the nominal gate count, and virtually all are working at the
upper end of the speed envelope.  Xilinx also provides a saftety net through
pin-out compatibility across chip sizes.  See my specific comments below

My experieince with Altera has been a bit different, as the Altera tools and
architecture can make it quite difficult to reach the same level of performance
or gate density as I can reach with the xilinx tools/architecture.

Duane Hague wrote:
> 
> As always Xilinx feature promises remain very attractive.  However, I
> have been "burnt" in the past on three projects where Xilinx was used
> (one scorched-earth [total project failure] and two roasts[massive
> time/cost over-runs]) in about the 1989 thru 1995 time-frames with XC200,
> XC3000, & XC4000 chips.  In fairness, the two "roasts" occurred when
> management allowed a contractor to ignore my design specification
> guidelines on the grounds that the contractor knew more then I did!  My
> basic Xilinx "Lessons Learned" were:
> 
> 1.  Chip Selection:  Design estimate at 40% or less of chip capacity.

Estimate the LUTs needed by knowing how you intend to map the design into the
chip.  This can be done from a detailed block diagram, and will get you to
within +/- 10-15% easily.  If you base your chip selection on the fictional
"marketing gates", you are quite prone to error as you don't know how that
figure was created or what structures were assumed


> 2.  Chip Speed:  Assume design can only achieve 25% of "expected"
> relative to chip ratings until proven otherwise.

Again, you need to design to the FPGA architecture to get deterministic speeds. 
XC4000E-2s are/were capable of 66+ MHz with careful design and lots of
pipelining  Virtex -4 parts ae capable of 133 MHz, and upto 150 MHz with careful
layout (for example the 16 bit 16 point 16 point FFT core I will be offering
this fall runs in an XCV100-4 at up to 153MHz worst case in its current
incarnation).  The carry chains are generally the worst case paths.  If you know
the timing for those, you can determine what the part is capable of.

> 3.  Timing Simulator:  If lucky, your implementated design will only be
> 125% of the critical-path timing predicted by the Timing Simulator.

Timing simulation is a can of worms.  It is quite easy to miss testing of some
critical paths based on a poor set of vectors.  I advocate a flow using
functional simulaton and static timing analysis.  That way, you are guaranteed
to surface any timing issues,provided you set up your constraints properly
(which you must do any way for the router to do its job right)

> 4.  Never go to Production PCB before the prototype works, "bugfixes"
> always seem to require IOB assignments to be "unlocked" before the design
> will "re-compile".

I've done over 200 FPGA designs, and have NEVER had a pin locking issue.  You
need to pick your pins intelligently (which can, beleive it or not be done
before you do the detailed design), rather than letting the tool shot-gun them
whereever it's random seed wants.  With newer parts, there is considerably less
sensitivity to pin placement than there was with the devices you mentioned,
thanks to more plentiful routing resources.

> 
> During this same time frame, I used Altera with no equivalent problems.

Altera is better at handling the 'designer' who wants no control over the
design, mostly because of its routing sturcture makes it less sensitive to
placement of the logic in the FPGA.

> I would summerize my experience as:
> 
> **Xilinx promises more, but implementation can only achieve about 40% of
> their promises.
> 
> **Altera promises less, but implementation can achieve about 90% of their
> promises.
> 
My findings are that Xilinx lets the interested designer get considerably more
performance and density than Altera.

Again, I think the biggest problem you've had here is that you/your design team
has not been designing to the FPGA architecture.  Don't despair though, it is a
common mistake with fPGAs.  You need to do your design using the elements in the
package rather than the other way around.  If you assigned two people to build a
widget out of legos, and gave one a bucket that contained only the basic 2x4
bricks, and the other a bucket that contained mostly those specialized parts,
you'd end up with two very diffferent solutions.  The same is true of the target
technology.



>         I would be very interested to hear from current Xilinx End-Users
> to see if the performance of the current generation of Xilinx
> hardware/software is sufficiently improved to revise my lessons-learned
> and/or make me willing to again step into a "Xilinx-swamp".
> 
> TIA and Bye while looking forward to an interesting thread.
> 
> PS:  I actually designed as well as "monitored" contractors doing design,
> so you can flame me as obsolete but hopefully not as ignorant.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com
Article: 25712
Subject: Re: Clock skew in XILINX CPLD
From: Nial Stewart <nials@sqf.hp.com>
Date: Mon, 18 Sep 2000 15:32:35 +0100
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> The best way I've found for general purpose parallel is create one extra signal
> with a toggle flip flop toggled by writing valid data to a register.  On the
> second clock side, you have a wrtie pulse generator that is triggered when it
> senses a change in the level on the synchronized flag, and then that is used to
> transfer the data from the common holding register across the clock domain
> boundary.  It can be pipelined a little, but you do generally still need 2 or 3
> clocks on the recieving side per clock on the transmit side.  You can put
> parallel circuits to maintain the data rate.
> 

Ray,

I thought Simon was describing a situation where you have 
parallel data being generated asynchronously with no other timing or 
flag info, and thought he had some clever way of ensuring you'd 
captured the data correctly.

I realise that each case needs to be examined and a properly 'safe'
interface
designed where required.

Nial.
Article: 25713
Subject: Re: MAX PLUS 2
From: Phil James-Roxby <phil.james-roxby@xilinx.com>
Date: Mon, 18 Sep 2000 09:08:36 -0600
Links: << >>  << T >>  << A >>
gk7eong wrote:
> 
> Hi, yes I will appreciate it if you send the license.dat for ModelSim to me.
> 
> About my school paying for the software? I think it is really fat hopes. The
> way things work here is kind of different. =)
> 

Fat hopes, or no fat hopes, Altera have a university program which
donates software, and discounts hardware.  See
http://www.altera.com/html/univ/univ.html for details.  Xilinx has a
similar program, as do Aldec for their Active VHDL. I don't know about
Model Tech.
This is vastly superior to hacking disk ids.
Phil
-- 
---------------------------------------------------------------------
 __
/ /\/  Dr Phil James-Roxby         Direct Dial: 303-544-5545
\ \    Staff Software Engineer     Fax: Unreliable use email :-)
/ /    Loki/DARPA                  Email: phil.james-roxby@xilinx.com
\_\/\  Xilinx Boulder                 
---------------------------------------------------------------------
Article: 25714
Subject: Safe voltage regulator for Xilinx XC2S150 part?
From: "Gary Watson" <gary2@nexsan.com>
Date: Mon, 18 Sep 2000 16:26:12 +0100
Links: << >>  << T >>  << A >>
I know it's difficult to predict the power requirements of Xilinx parts, but
what's a safe 2.5V regulator to use for the internal supply of a XC2S150?
The data sheet is most unhelpful in figuring this out.  Since I plan to roll
out this product in phases over the next year, I can't say what all my
internal logic might be doing down the road, so I'm happy to over-spec the
regulator to a reasonable degree.

By the way, I'm getting quoted over 10 UK pounds ($14) for the config prom
for this puppy (XC18V01S20C).  Is there a cheaper way to do this?  This prom
increases the cost of using a Spartan II by 50%!

--

Gary Watson
gary2@nexsan.com
Nexsan Technologies Ltd.
Derby DE21 7BF  ENGLAND
http://www.nexsan.com





Article: 25715
Subject: Re: 3.3/2.5 voltage regulators
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 18 Sep 2000 08:29:08 -0700
Links: << >>  << T >>  << A >>
Rick,

OK.  You are welcome.  Let me see if I can help you with this.

For 4K:

1* discharge to less than ~150 mv before staring up again as last configuration
doesn't leak away completely and higher start up current results,

2* don't hold off clean-out/configuration with INIT as power on current remains until
you let go (unless that is OK with you and your power supply),

3* keep power rising (or at least flat) through the POR region,

4* >2ms and <50ms power on ramp up time recommended (within the data sheet power on
ramp up time and current capacity spec).

3&4 apply to Virtex, but not 1&2.

Austin

rickman wrote:

> This is very useful information, thanks.
>
> I was not asking about the internal design of the two families of parts,
> although that would be interesting. I was asking about the functional
> difference. In your earlier posts you seem to indicate that there is a
> large current draw under a wider range of conditions with the 4K series
> than with the Virtex series. This is what I am trying to understand.
>
> > > > In 4K, holding INIT and preventing clean out does not make the device
> > > > HOT -- it may be that the 4K device is in contention from the Vcc not
> > > > going down below a few hundred millivolts, and then the Vcc returns,
> > > > and the 4K device is in a partially configured state, and drawing
> > > > current.  So the device is already HOT and getting hotter, and INIT
> > > > prevents the clean out.
> > > >
>
> ********************* This bit right here
> ********************************
> > > > Again, Virtex, Virtex E, Spartan2 do not have this behavior.  The
> ********************* This bit right here
> ********************************
>
> This is the statement I am asking you to clarify. Tell us about the
> difference noted above. I do not understand exactly what is different
> about the behaviour of the two families of devices. I am not asking you
> to explain the internal proprietary design issues.
>
> I do not agree that there is such a significant difference in the
> markets for the Virtex and the Spartan parts. I don't know how you are
> targeting your parts, but I can tell you that the users only look at
> capability (size) and price. I have no reason to care about what the
> intended market for a family of parts is. So with the considerable
> overlap in size of the two families (50, 100 and 200K gates), I expect
> that I will be using either family depending on my specific needs for
> expandability and size.
>
> So I don't agree that you can just say, that there will only be a small
> number of people using the Virtex parts in designs with current limited
> power supplies... except for the fact that you won't support them when
> used that way.
>
> Austin Lesea wrote:
> >
> > Rick,
> >
> > The increased current draw occurs at about 0.6 to 0.8 Vdc in Virtex.
> >
> > It occurs at the POR trip point in 4K (see respective data sheets).
> >
> > The differences between the virtex and 4k power up cleanout circuits are not
> > something I can discuss.
> >
> > While a supply is ramping up, it is driving the filter capacitors to the
> > intended output voltage, and the supply is often current limited (can't supply
> > any more current than it already is) while doing this, and hence the power ramp
> > up time is constrained (i.e. not instant, by I=C*dV/dt).
> >
> > If I had 2000uF of capacitance, and it rises in 2 ms (typical of a really fast
> > power ramp), that is 2.5V into 2,000uF in 2 ms, or I=2.5A.
> >
> > If I had 2000uF of capacitance, and the device suddenly requires 500 mA, you can
> > see what the dV/dt would be.  But, nothing is sudden, and the voltage and
> > current interact.
> >
> > Even hot swap PCI has a rise time due to the resistance and inductance of the
> > pcb traces to the bypass capacitors of usually no faster than 1 ms.
> >
> > You can think of Virtex as being a really big non-linear capacitor.  It actually
> > draws less current as the ramp slows down.  This makes this a chicken and egg
> > problem:  how does the power ramp?  Is the part connected?  they affect one
> > another.  We test to make sure that if a power supply could supply no more than
> > 500 mA (in Virtex C grade), the device would be ready for configuration and the
> > vccint is at the power supply vccint (not sagging, or collapsed).  The Virtex
> > part may put a flat spot in the ramp up, but that is just fine (we just don't
> > like to see it foldback, and dip which is the case with a power supply that is
> > arranged for a foldback response -- datasheet recommends against this kind of
> > behavior!).
> >
> > We have noted that if you could only supply 100 mA, the ramp might be really
> > long (~100 ms), but the part would clean out, and start to configure.
> >
> > Virtex is not going to be characterized for low current startup, as most designs
> > require more than 500 mA while operating (no market push to do this).
> >
> > Spartan2 on the other hand will be considered (is now being characterized) for
> > lower current startup as the markets are different for the two parts (there is a
> > push to do this).
> >
> > I hope this answers the first question, and I hope you understand that I can not
> > discuss the internal circuit design and operation here required to answer you
> > second question,
>
> --
>
> Rick 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
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

Article: 25716
Subject: Re: Simon,Floating Inputs
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 18 Sep 2000 08:46:57 -0700
Links: << >>  << T >>  << A >>
I know, I know...

The APP158:  http://www.support.xilinx.com/xapp/xapp158.pdf

may seem like over kill, and maybe it is.  But I don't know what YOU are doing,
and I don't know what YOUR clock speed is, and I don't know what YOUR IO's are
switching, and I don't know if YOU have read a good signal integrity book or any
of the app notes, and so on.... so we were ultra conservative!

I have seen some spectacular bypass jobs that didn't work because of SSO's and
ground bounce (you just can't have every single pin switch 24 mA simultaneously
-- read app133).  I have also seen some rather poor (in my opinion) bypassing
layouts that worked fine because they measured it afterwards and pulled off
parts until their noise margin was just under their specification (not my style
-- but it works).

Anyone interested in APP158 and how to bypass big fast ultra deep sub micron
chips is encouraged to email me directly at austin@xilinx.com with their
comments.  I know I may be opening Pandora's box, but the intent is to
understand the real issues, and make it easier to use, so I am ready and
willing.

We will be re-releasing a re-written and improved app158 soon.

Austin

"S. Ramirez" wrote:

> Dan,
>      Ignore the previous post.  You are using a Virtex XCV600.  Xilinx has
> an app note that tells you how much decoupling to use.  I do not have it in
> front of me, but I know that it requires big capacitors, and I think these
> big capacitors are overkill.  It does require more caps that what you told
> us about; however, at the company I work at we collectively decided that
> they are not enough.  We think that 0.1uF or 0.01uF caps are required for
> every pin.  This assumes ground and power planes.
>      Your problem, though, may involve something other than power quality.
> I would involve the Xilinx FAE on this one.
> -Simon Ramirez, Consultant
>  Synchronous Design, Inc.
>
> "Dan" <daniel.deconinck@sympatico.ca> wrote in message
> news:8miw5.261590$1h3.5258160@news20.bellglobal.com...
> > The decoupling is four .1uF caps. One at each corner of a QP240. I plan to
> > make a new PCB with a .1uF at each power pin.
> >
> > When the device is drawing minimum power, shouldn't four decoupling caps
> be
> > enough ?
> >
> > Dan
> >
> >
> >
> >
> >

Article: 25717
Subject: Re: Reassurance on Xilinx Sought
From: Bob Perlman <bobperl@best_no_spam_thanks.com>
Date: Mon, 18 Sep 2000 08:51:36 -0700
Links: << >>  << T >>  << A >>
Hi - 

On Mon, 18 Sep 2000 14:15:47 GMT, Ray Andraka <ray@andraka.com> wrote:

<stuff deleted>

>> 4.  Never go to Production PCB before the prototype works, "bugfixes"
>> always seem to require IOB assignments to be "unlocked" before the design
>> will "re-compile".
>
>I've done over 200 FPGA designs, and have NEVER had a pin locking issue.  You
>need to pick your pins intelligently (which can, beleive it or not be done
>before you do the detailed design), rather than letting the tool shot-gun them
>whereever it's random seed wants.  With newer parts, there is considerably less
>sensitivity to pin placement than there was with the devices you mentioned,
>thanks to more plentiful routing resources.

I agree with everything Ray said in his post (except for
Altera-specific stuff, of which I have no direct knowledge), but I
think that the point he makes above is particularly important because
the conventional wisdom is so terrible.  In particular, designers seem
to take two bad approaches to pin assignment:

1) Arbitrarily assign the I/O pins.  This leads to disaster.

2) After trying (1), the designer seeks advice from the FPGA vendor,
who usually says, "Never lock down the pins yourself; let the place
and route tool do that."  This usually leads to disaster, too, only
getting there takes a bit longer.  The first route may be OK, but as
soon as you make a significant design change, oh, boy...

The best approach, as Ray suggests, is to pick the pinouts
intelligently based on the design.  In particular:

1) Figure out how the data/control is going to flow through the
device, and assign the pins accordingly.

2) Try to isolate groups of mutually asynchronous signals to avoid
noise problems.

I do pin assignments on Xilinx devices before place and route, and
haven't run into a pinout-related problem yet.

Take care,
Bob Perlman

Article: 25718
Subject: Re: Looking for an Altera APEX eval board
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Mon, 18 Sep 2000 16:06:53 GMT
Links: << >>  << T >>  << A >>
Altera has just started selling one for $995 with a apex200-1. Go to
https://websupport.altera.com/estore/excalibur.asp

On Mon, 18 Sep 2000 14:12:22 GMT, "Mikhail Matusov"
<matusov@ANNTIsquarepegSPPAMM.ca> wrote:

>Are there any available?

Article: 25719
Subject: Re: VirtexE availability?
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Mon, 18 Sep 2000 09:22:15 -0700
Links: << >>  << T >>  << A >>
Mark Harvey wrote:
> 
> >
> > --Yes and no.  That somebody is the Xilinx FAE, but we're not talking
> about
> > him, we're talking about disties.  A disty does not need to be involved,
> > i.e., register a design, every time.  Just ask the direct accounts.
> >
> 
> Agreed, but I think this discussion was started by someone who is not a
> direct account...or have I misunderstood?

Yup -- indirect, and low-volume, too.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25720
Subject: Re: Non-disclosures in job interviews, Round Two
From: tangozebra@bigfoot.com (tangozebra)
Date: Mon, 18 Sep 2000 17:52:45 GMT
Links: << >>  << T >>  << A >>
This is a more general legal question - but lets say you're given an NDA 
at an interview, and you write "not signed" as illegibly as possible on 
the signature line and hand it back as if you signed it.  What legal 
ramifications does this have?

TZ

Article: 25721
Subject: Re: Virtex clock fanout
From: "Alun" <alun101@DELETEtesco.net>
Date: Mon, 18 Sep 2000 19:58:50 +0100
Links: << >>  << T >>  << A >>

"Michael Rhotert" <mrhotert@t-online.de> wrote in message
news:8q2pmd$hcq$11$1@news.t-online.com...
> > We are considering moving the fanout functionality inside the
> > Virtex, to save on external parts count.  The issue I have a
> > question about is the following.  When one sets up the constraints
> > for the P&R tool (Alliance in this case), is there a way of doing
> > this so that one can specify the **maximum skew** between any 2
> > clock outputs?  In other words, is it possible to fan out a clock
> > inside the Virtex for external use and simultaneously approximate
> > (dare I say guarantee?) the low skew among all clock outputs that
> > is characteristic of an external buffer?
>
> Maybe you can use the 2x output of the DLL, divide it by 2 in a CLB, and
> feed the divided signal to several IOBs with output registers, clocked by
> the 2x-clock.
> Using this approach, you get multiple low skew signals with the wanted
> frequency.
>
> Michael

This is the best approach but the *huge* snag (depending on what you want to
do) is that you can't use external feedback to get the external clocks to
have zero skew compared to the DLL input clock. The external FB clock must
be 2x if you use the DLL 2x output.
Read XAPP132 (Virtex DLL app note) *very* carefully. There are loads of
rules and a new rule appears every few months.

There is an article on how to get low skew with non-clocked outputs which I
can't lay my hands on right now. I got it from the Xilinx web site and
covers the use of MAXSKEW (Xilinx P&R) and placement out outputs for low
skew. Place the outputs near each other along the top or bottom of the
device (ie by the long lines) and constrain the skew to whatever you need.
The article quoted an example result of 56ps with a constraint of 100ps (I
think), though don't bank on getting near this figure.

Alun
Camdigital


Article: 25722
Subject: system-gates and system-bytes
From: "Alun" <alun101@DELETEtesco.net>
Date: Mon, 18 Sep 2000 20:16:19 +0100
Links: << >>  << T >>  << A >>
I have a letter from Altera that came with their News and Views newsletter.
The APEX EP20K1500E has an incredible 416 Kbytes of RAM, far more than the
largest Virtex. The letter is from Cliff Tong, Vice President, Corporate
Marketing.

Altera have now leapfrogged the gate-inflation war with what is obviously a
new method of counting bytes.
I guess this is 'system' bytes which are almost 8 times the number of actual
RAM bytes implemented (416*8/432 = 7.70 according to Altera's web site).
Beat that Xilinx.

Alun
Camdigital


Article: 25723
Subject: Empoyment
From: job_mine@my-deja.com
Date: Mon, 18 Sep 2000 19:39:57 GMT
Links: << >>  << T >>  << A >>
I need help in locating multiple Program
Marketing Managers for FPGA's. Manugacturing,
Vendor or User experience is valid.  Other
experience such as ASICS is valid and will be
considered.  Please email resume or inquire to
Bob Dosier at jka.rd@icnt.net.  Thank you. Bob


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25724
Subject: SoC VSIA meeting
From: sbaker@best.com (DL)
Date: Mon, 18 Sep 2000 19:42:14 GMT
Links: << >>  << T >>  << A >>
Dear System-Level Chip advocate:

If System-Level ICs are important to you, so is this meeting.  The
annual VSI Alliance Member Meeting in the US will be held in Silicon
Valley on October 25.  Admission is free to members and non-members

The keynote speech will be given by Dr. Wally Rhines, president of
Mentor Graphics.  There will be important and useful presentations
from several major companies on how they are handling the SoC design
and development challenges and how they are using VSIA specifications
and standards in that process.

For more information and the registration form, check the VSIA website
at www.vsi.org. 
· The meeting is at the Santa Clara Marriott Hotel, from 9 till 5.  
· Continental breakfast and registration from 7:30am. 
· Lunch served and a cocktail reception at 5pm.  
· There will be a VSIA orientation meeting at 8am for those not
familiar with the Alliance, what all it's all about and how it works.

Hope to see you there:
Stan Baker
VSI  Alliance

The VSI Alliance is a non-profit consortium of over 160 companies
worldwide.



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