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 37025

Article: 37025
Subject: Re: How to set timing constraint in Xilinx VirtexII device when using
From: Kate Meilicke <katem@xilinx.com>
Date: Wed, 28 Nov 2001 13:21:36 -0700
Links: << >>  << T >>  << A >>
Kenneth,

Put the period on the input clock to the DCM.  The Xilinx tools will create
the necessary period constraints for the output clocks of the DCM.

Kate Kelley

Kenneth wrote:

> Dear all,
>
> Sorry, I added the following line to UCF file(I typed wrongly in my
> previous post)
>
> NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x";
> TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH
> 50%;
> NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x";
> TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH
> 50%;
> NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx";
> TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 6.25 ns HIGH
> 50%;
> (the hierarchy is Top_level -> CLOCK -> DCM0,
> and the net name of the 1x output is dcm0_clk1x,
>                         2x output is dcm0_clk2x,
>                         4x output is dcm0_clk4x)
>
> Thanks again.
>
> Regards,
> Kenneth
>
> Kenneth wrote:
> >
> > Dear All,
> >
> > I am not clear about how to set the timing constraint in VirtexII
> > device when using the build-in DCM.
> >
> > Currently I am using Synplify Pro 6.2 for synthesis and Xilinx ISE
> > 3.308i for implementation.  My Design use an external 40MHz clock,
> > and is fed into a DCM.  Within the design,  I use both the 2x(clk2x)
> > and 4x(clkfx) clock output of the DCM to clock the internal logics.
> >
> > In the Synplify Pro, there is a field for me to specify the required
> > operating frequency.  However no matter what value(e.g. 40MHz) I set,
> > the implementation will treat all the clock(1x, 2x and 4x) have the
> > same timing constraint of 40MHz(this is shown in the Place and Route
> > Report after the implementation).    As a result, I got a poor
> > implementation result.
> >
> > Even I add the the following constraints in the UCF file,
> >
> > NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x";
> > TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH 50
> > %;
> > NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x";
> > TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH
> > 50 %;
> > NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx";
> > TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 12.5 ns HIGH
> > 50 %;
> > (the hierarchy is Top_level -> CLOCK ->DCM)
> >
> > the Place and Route Report still shown that the required frequency
> > for all clock are 40Mhz.
> >
> > So, what should be the correct method to set the timing in my case?
> >
> > Thanks in advance.
> >
> > Regards,
> > Kenneth


Article: 37026
Subject: Re: Device Support in Webpack
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Nov 2001 15:22:02 -0500
Links: << >>  << T >>  << A >>
Kamal Patel wrote:
> 
> Hello Rick,
> 
> Devices supported in WebPACK besides all Xilinx CPLDs include
> Virtex-E and Virtex-II devices up to 300K and all Spartan-II and
> Spartan-IIE devices.

I was asking so that I could be sure that the new VII parts were
actually in the WebPack rather than just being planned for support.
Thanks.

 
> The main features that WebPACK is missing when compared to the
> Foundation version of ISE are Core Generator, FPGA Editor, and
> FPGA Express synthesis.
> 
> As far as OS support, Windows XP is not officially supported but
> many cases have been seen where the software has worked fine.
> I know that the Xilinx support team has a machine with a fresh
> install of XP up and running with no changes to the OS. You may
> want to get in contact with an FAE about this as they've probably
> seen cases for both sides of the story.
> 
> I hope this helps.
> 
> Regards,
> Kamal

Any idea when Xilinx plans to "officially" support XP? I really don't
want to have to use an older copy of Windows and I don't want to have a
dual boot machine, or triple boot machine since you don't support Win95
anymore :)


-- 

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: 37027
Subject: Re: reducing PAR time
From: "Bryan" <bryan@srccomp.com>
Date: Wed, 28 Nov 2001 13:52:24 -0700
Links: << >>  << T >>  << A >>
>
> This is not for the faint of heart, and is considered advanced even
> for Xilinx FAE's but it works great. Turn your little submodule into a
> hard macro. This will fix the placement and routing. The other nice
> thing about this is that every instatiation will be routed idencly,
> instead of randomly. I use it mostly for circuits that have clocks
> that are not on the globabl clock net. It's the only way I can
> gurantee that I get a good route on the clock net everytime.
>
> This will get you started:
> see Xilinx Answer Database record #10901 "FPGA Editor - How do I
> create a hard macro?"
>
> Oh, and make sure you use LOCs for every instantiation of the macro,
> otherwise your PAR time will go up, not down.
>
> Mark

5. To maintain the relative placement of the CLBs/Slices in the Macro,
select a CLB to use as the reference, and go to Edit -> Set Macro Reference
Comp. This will effectively create an RPM, and will make the system's timing
as consistent as possible. Keep in mind that it is impossible to lock down
routing, so there are no guarantees that the asynchronous paths will not
change.


This is from the answer record you mentioned.  It says it is impossible to
lock routing, so how did you get the clock route locked down?

Bryan



Article: 37028
Subject: Re: SpartanIIE
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 28 Nov 2001 13:18:19 -0800
Links: << >>  << T >>  << A >>
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3C0535D4.868C1E65@algor.co.uk...
> o Do they relate to VirtexE's in the same way as SpartanII did to the
> Virtex ? Esp wrt timing.

http://fpgacpu.org/#011120:

"You might think that

   as Virtex-E is to Virtex, so is Spartan-IIE to Spartan-II

But you would be wrong. According to data sheets, whereas an XCV200 has 14
BRAMs (56 Kb) and the XCV200E has 28 BRAMs (112 Kb), in the Spartan-II/E
family, both the XC2S200 and (alas) the XC2S200E have the same 14 BRAMs (56
Kb).
...
But let us count our blessings. The new Spartan-IIE family is lower-voltage,
faster (470 ps TILO (2SxxxE-6) vs. 700 ps TILO (2Sxxx-5)), offers a larger
part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of different
I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208
QFP packages. "

Jan Gray
Gray Research LLC




Article: 37029
Subject: Re: SpartanIIE
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 28 Nov 2001 13:32:01 -0800
Links: << >>  << T >>  << A >>


rickman wrote:

> I can't say anything about the connection to the Virtex IIE parts except
> that I expect that is correct.

Spartan-IIE is functionally identical to Virtex-E, but has fewer BlockRAMs, and
slightly different (?) timing parameters, and it comes in different packages and
fewer speed grades.
Peter Alfke

>
>
> But the FT package is just a lower profile version of the FG package.
> There are a lot of applications where height is very, very important.
> Didn't you go to the web site to find the packaging data sheet? That is
> where I found it.
>


Article: 37030
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 13:50:07 -0800
Links: << >>  << T >>  << A >>
Rick,

All fair and reasonable comments.

The Virtex II has agressive forward pricing as a new product, and you would need
to contact your appropriate sales channel.  The prices you quote, are of course,
today's list prices.  I would say that some very large accounts are looking at
the 2V40 and 2V80, where they would normally be interested in the Spartan IIE
parts, and they have no problem with the pricing.

Your comments on IOs are equally valid as to the numeric count, but if a Virtex
II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a ~160 Mb/s DDR
IO, Virtex II wins from a bits per second per package point of view.  If you go
to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty respectable.

Additionally, Spartan IIE has fewer power and ground pins than Virtex E, so the
SSO table is less agressive, so unless you just need lots of LEDs and switches
(which a lot of Spartan applications do require), you can't really run the IOs
as agressively.  So the ~160 Mb/s per pin of Spartan IIE is not sustained across
as many IOs (exceeds SSO guideline).

So what to choose?  I would suggest that you look at more than just the pin
counts, and look into the speeds, strengths, SSO's, and so on.  Maybe Spartan
IIE is the best for you.

As for 2 amperes at -40C, this is the legacy of the orginal Virtex design, and
we have only had the opportunity to address it in Virtex II, as Virtex E and
Spartan II and Spartan IIE are all derivatives of the original Virtex design.

Again, this specification as well, is under revision as we characterize Spartan
IIE, and Spartan IIE.

I would also like to say that the Virtex family and it derivatives is the best
selling FPGA 'dynasty' in the history of FPGAs.  It is hard to argue with that
kind of sucess, so I will only suggest that using the 2V40 is an option, and one
that should be considered.

Austin


rickman wrote:

> Austin,
>
> I don't mean to pick on Xilinx, but to suggest that the Virtex II family
> is a good replacement for a Spartan II device is hard to understand from
> a cost and IO count perspective.
>
> Here are some devices side by side. All IO counts and prices are for the
> slowest speed grade in the FG256/FT256 packages.
>
>  Part    IO  Slices  Price
> XC2S50  176    768    $17
> XC2V40   88    256    $35
>
> XC2S100 176   1200    $25
> XC2V80  120    512    $43
>
> XC2S200 176   2352    $33
> XC2V250 172   1536    $79
>
> As you can see there is no comparison between the actual part size, IO
> count and price. To get an equivalent chip you would need to spend at
> least double the money and more likely 3 or 4 times the money.
>
> The Virtex II chips may have solved the startup current issue, but they
> are hard to justify in a cost sensitive application. I am fully aware of
> the unique features of the Virtex II family. There is the DCM, the
> bigger memory, the multipliers. But these features can only improve
> usability if you need those features. I would love to have the DCMs on
> my next board. But I can't justify the $146 price tag for the parts to
> get the IO count I need when I can get an XC2S part for $35.
>
> If my information is incorrect, please let me know. I have been trying
> to find out if the Virtex II prices will be coming down in the near
> future and I am not hearing anything to make me think so.
>
> BTW, you quote 500 mA startup current in the commercial temp grade, but
> in the industrial grade it is a full 2.0 AMPS per chip!!! Makes it hard
> to turn on a board with 3 or 4 chips on it.
>
> Any idea when the updated info will be available? I am looking at a new
> design and can't use the Spartan II chips until I know if I can power up
> the board with the available power source.
>
> Rick Collins
>
> Austin Lesea wrote:
> >
> > Brad,
> >
> > In the data sheet there is a 'Supply Current Requirements During Power On'
> > section for all Xilinx FPGAs.
> >
> >  http://www.support.xilinx.com/partinfo/ds001_3.pdf
> >
> > This states clearly what the power supply must supply to power on the
> > device reliably, 100% of the time.
> >
> > For a Spartan II, the current in the latest data sheet is 500 mA (C parts)
> > for all device members.
> >
> > This number is under present study, and we are changing the data sheet to
> > reflect the result of a massive re-characterization of the material from
> > the fab's.
> >
> > It turns out that the smaller devices do not require as much current as
> > the larger ones.
> >
> > As for why CMOS draws current?  It isn't as simple as everyone suspects.
> > If it was, then anyone would be able to make cost effective reliable
> > FPGAs.  Obviously,  that isn't the case, and the hundreds of
> > engineer-years that we dedicate to each family of FPGAs would not be
> > required.
> >
> > There are many reasons why current can accumulate to large values.
> >
> > I will say that Virtex II is a much better choice for new small designs,
> > where extremely low startup power is desired.  Look at the similar section
> > there.  The 2V40 is 512 LUTs, so small is not an issue, and the price is
> > pretty good there, too (simialr to Spartan pricing).
> >
> > Austin
> >
> > Brad Eckert wrote:
> >
> > > At a recent FPSLIC seminar, Atmel's marketing guy mentioned that some
> > > FPGAs have high startup current (a couple of amps) so their FPSLIC
> > > would have simpler power requirements than a soft CPU.
> > >
> > > Is this still true? I'm looking at a Spartan II XC2S30 or XC2S15 for a
> > > soft CPU. Even a 1A startup current is a little hard to imagine, since
> > > you'd expect the logic to start out in a cleared state.
> > >
> > > Can anyone tell me what kind of startup current to expect from low
> > > cost FPGAs like Spartan or ACEX?
> > >
> > > --
> > > Brad Eckert
>
> --
>
> 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: 37031
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 28 Nov 2001 23:05:55 +0100
Links: << >>  << T >>  << A >>
mrgs1000@yahoo.com (Mark) writes:

> Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90u
k0l3mmebi1703urlud5e91rou5af@4ax.com>...
> >
> > I understand that the scarcity of such software is partly because
> > vendors do not release enough information. Are there any modern devices
>
> I would venture to say that the primary road block to open-source
> tools is that they are too dificult to support and keep current for
> people to do for free.

As opposed to tons of video and ethernet chips that the Linux people
seem to have no great problem with?

Just simply support those chips that members of the open source group
use. And the software users then buy those parts.

Hint to vendors: if your part has open source support, it gets more
recommendations ("take that one, it works"), and you get to sell more
of them. I principially buy video and ethernet cards after consultion
the on-line support databases.


> There are lots of flows for design entry and
> simulation,

Just support those that the present maintainers use. And use those
that are supported.


> and new devices are released on a weekly basis. I

Huh? As far as I see it Xilinx has so far created about 9 families
(2000 3000 4000/Sparten 4000XL/SpartanXL 5200 6200 Virtex/SpartenII
VirtexE/SpartanIIE Virtex2) in 15 years. Altera has 8 families
(MAX3000 MAX7000 MAX9000 FLEX6K FLEX8K FLEX10K/ACEX APEX Mercury)
in over 10 years. Lucent has IIRC 4 families of ORCA. Atmel 2
families (4000 6000). Actel I do not know, as I can not read their
website (damn Flash and not HTML alternative). And a few other
irrelevant manufacturers.

So that makes about 2 falimies per year industrywide to support. Or
simply only support a few of them and only use those.


> occasionaly start using parts before they are released so I would not
> be able to wait for open-source tools to have the support. In fact, I
> have started designs where the vendors own tools didnt suport the part
> I was using.

Does not look like you are an average user there. :-)


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 37032
Subject: Re: Creating a jitter free clock
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Wed, 28 Nov 2001 22:06:34 GMT
Links: << >>  << T >>  << A >>
adrian wrote:
> 
> I'll tell you exactly what I need it for. I have designed an FPGA based Pulsar timer for a radio astronomy observatory. What the instrument essentially does is coherent averaging on pulses coming from neutron stars (pulsars)to build up a pulse profile. Averaging, right now, will take place over a maximum of 5 minutes, although this will probably be much less in the future.
> 
> I need to be able to set a user defined sampling frequency to this resolution, and not have at move at all. If it does, it means that the pulse will being to drift across the averaged profile, and move around with jitter.

How typical -- astronomers with astonishingly-stringent specifications
that they don't understand...

-a

Article: 37033
Subject: Re: FPGA startup current
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Nov 2001 19:10:17 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> All fair and reasonable comments.
> 
> The Virtex II has agressive forward pricing as a new product, and you would need
> to contact your appropriate sales channel.  The prices you quote, are of course,
> today's list prices.  I would say that some very large accounts are looking at
> the 2V40 and 2V80, where they would normally be interested in the Spartan IIE
> parts, and they have no problem with the pricing.

I got this pricing from my distributors. I am not a large customer so we
don't get promises of big discounts. Even if I were larger, I seriously
doubt that the part I would need due to pin count considerations will be
dropping from $146 to $50 or less. 

 
> Your comments on IOs are equally valid as to the numeric count, but if a Virtex
> II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a ~160 Mb/s DDR
> IO, Virtex II wins from a bits per second per package point of view.  If you go
> to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty respectable.

This does not help for many designs. If a new design can run a
arbitrarily high clock rate, then this would be ok. But many, if not
most, designs have set constraints on clock speeds and IO rates. I can't
change the number of IOs or the clock speed of a PCI interface for
example. 

 
> Additionally, Spartan IIE has fewer power and ground pins than Virtex E, so the
> SSO table is less agressive, so unless you just need lots of LEDs and switches
> (which a lot of Spartan applications do require), you can't really run the IOs
> as agressively.  So the ~160 Mb/s per pin of Spartan IIE is not sustained across
> as many IOs (exceeds SSO guideline).
> 
> So what to choose?  I would suggest that you look at more than just the pin
> counts, and look into the speeds, strengths, SSO's, and so on.  Maybe Spartan
> IIE is the best for you.

Does the Spartan IIE get around the heavy startup currents? Otherwise I
might as well stick to the Spartan II since they are a bit cheaper. 

 
> As for 2 amperes at -40C, this is the legacy of the orginal Virtex design, and
> we have only had the opportunity to address it in Virtex II, as Virtex E and
> Spartan II and Spartan IIE are all derivatives of the original Virtex design.
> 
> Again, this specification as well, is under revision as we characterize Spartan
> IIE, and Spartan IIE.

I understand the reason for the Spartan IIs having the same problems as
the Virtex. But I remember this detailed characterization being
announced back at the beginning of the year if I am not mistaken. It
will be necessary to see the results before I can design in two or three
Spartan II or IIE chips. 

 
> I would also like to say that the Virtex family and it derivatives is the best
> selling FPGA 'dynasty' in the history of FPGAs.  It is hard to argue with that
> kind of sucess, so I will only suggest that using the 2V40 is an option, and one
> that should be considered.

You have a very different view of FPGAs from your customers. I don't
care about the success of a "dynasty". I only care about the utility of
a specific FPGA for my application. As to the 2V40, that part has only
88 IOs regardless of package and would only be usable in one possible
use on my boards. That particular set of slots is currently being filled
by a $10 Lucent (opps! Agere) chip while the 2V40 is $29. I am trying to
replace these chips with a single less expensive solution. The XC2V
parts just aren't cost effective enough.

-- 

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: 37034
Subject: Re: FPGA startup current
From: brad@tinyboot.com (Brad Eckert)
Date: 28 Nov 2001 16:16:23 -0800
Links: << >>  << T >>  << A >>
Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0517E1.D2BA1B8C@xilinx.com>...
> 
> In the data sheet there is a 'Supply Current Requirements During Power On'
> section for all Xilinx FPGAs.
> 
>  http://www.support.xilinx.com/partinfo/ds001_3.pdf
> 
According to the data sheet, this heavy current demand occurs during
voltage rampup. Switching regulators put out more current at low
voltage, so if 500mA current peak occurs at, say, 0.8V and the
regulator's input is 5V then the 5V power supply would see something
like 500*0.8/5 mA. About 100 mA with a 80% efficient switcher.

As long as you're characterizing startup current, it would be useful
to know at what voltage the heaviest current draw occurs. For example,
some of my applications use USB, so I have limits on what I can draw
from the 5V supply if the device is bus-powered.

I thought Virtex was a lot more expensive than Spartan. What price
point do you expect for the 2V80 in 2Q 2002?

BTW, do you have a link to Virtex power requirements?

Article: 37035
Subject: Re: reducing PAR time
From: khtsoi@cse.cuhk.edu.hk
Date: 29 Nov 2001 00:29:08 GMT
Links: << >>  << T >>  << A >>
Mark <mrgs1000@yahoo.com> wrote:
> Oh, and make sure you use LOCs for every instantiation of the macro,
> otherwise your PAR time will go up, not down.
Hi,
I still confuse at this point. If I create a *hard* macro, shouldn't it
contain all the placemanet and routing information need by par. Then
why should I use LOC inside the FPGA editors again?
Also, is there a way to do it in a high level (in VHDL level or enen UCF)
but not donwto to the FPGA editor? The reasons for this are:
1. I don't always have access to the consol with *both* good display and
	fast CPU. I usually write the VHDL codes on my laptop and submit
	them to a SunE4500 machine though text mode.
2. Some one say (and what I always beleave is) that I can do every thing
	in VHDL as the schematic method can. Isn't that true in this
	case? (don't start a war on this, I just want to get my work done)
3. To ensure my instructions of LOCs in VHDL is correctly passed to par,
	I have checked the PCF (physical constrain file) generated by map
	tools. One interesting thing is that I can only find the LOCs from
	top level (i.e. indicating where the submodules should be placed)
	but not the LOCs inside the sum modules telling the locations of
	the internal components. If this is the normal case, how can the
	par tool know the information about the internal components?
4. My sub moduls are not quite simple. It use up to a 6x4 CLB block and
	use up all resource in that (including the TBUFs). Also, I am at
	the dead line of my project and it's looks impossible for me to
	get the schematic work within a day (I will finally do it after
	the dead line if this is the only way, but my report will have
	only estimated performance...so sad)
Thanks for those all help me and spent time to read my news. Thanks again!

---- Brittle

Article: 37036
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 16:48:14 -0800
Links: << >>  << T >>  << A >>

--------------8BA419420E4C016985287943
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rick,

See inbetween the lines, below.

Austin

rickman wrote:

> Austin Lesea wrote:
> >
> > Rick,
> >
> > All fair and reasonable comments.
> >
> > The Virtex II has agressive forward pricing as a new product, and you would need
> > to contact your appropriate sales channel.  The prices you quote, are of course,
> > today's list prices.  I would say that some very large accounts are looking at
> > the 2V40 and 2V80, where they would normally be interested in the Spartan IIE
> > parts, and they have no problem with the pricing.
>
> I got this pricing from my distributors. I am not a large customer so we
> don't get promises of big discounts. Even if I were larger, I seriously
> doubt that the part I would need due to pin count considerations will be
> dropping from $146 to $50 or less.

OK.  I hear you there.  This is something of a disconnect from what I was told.  If we
price 2V40's like that, I can see why you don't like them.  I will go find out why
they are listed at this level.

> > Your comments on IOs are equally valid as to the numeric count, but if a Virtex
> > II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a ~160 Mb/s DDR
> > IO, Virtex II wins from a bits per second per package point of view.  If you go
> > to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty respectable.
>
> This does not help for many designs. If a new design can run a
> arbitrarily high clock rate, then this would be ok. But many, if not
> most, designs have set constraints on clock speeds and IO rates. I can't
> change the number of IOs or the clock speed of a PCI interface for
> example.
>

True, for a given problem, there may be no ability to do an optimal systems solution.

> > Additionally, Spartan IIE has fewer power and ground pins than Virtex E, so the
> > SSO table is less agressive, so unless you just need lots of LEDs and switches
> > (which a lot of Spartan applications do require), you can't really run the IOs
> > as agressively.  So the ~160 Mb/s per pin of Spartan IIE is not sustained across
> > as many IOs (exceeds SSO guideline).
> >
> > So what to choose?  I would suggest that you look at more than just the pin
> > counts, and look into the speeds, strengths, SSO's, and so on.  Maybe Spartan
> > IIE is the best for you.
>
> Does the Spartan IIE get around the heavy startup currents? Otherwise I
> might as well stick to the Spartan II since they are a bit cheaper.
>

The Spartan IIE parts are smaller, so the currents are smaller.  But I think that
Spartan II is going to have lower values for the power on.

>
> > As for 2 amperes at -40C, this is the legacy of the orginal Virtex design, and
> > we have only had the opportunity to address it in Virtex II, as Virtex E and
> > Spartan II and Spartan IIE are all derivatives of the original Virtex design.
> >
> > Again, this specification as well, is under revision as we characterize Spartan
> > IIE, and Spartan IIE.
>
> I understand the reason for the Spartan IIs having the same problems as
> the Virtex. But I remember this detailed characterization being
> announced back at the beginning of the year if I am not mistaken. It
> will be necessary to see the results before I can design in two or three
> Spartan II or IIE chips.
>

Well.  The Spartan II new datasheet numbers are done.  The revisions are in the mill.
The Spartan IIE was just announced, so the intitial datasheets will be more
conservatively stated until we have sufficient silicon to go back and look at it
again.

> > I would also like to say that the Virtex family and it derivatives is the best
> > selling FPGA 'dynasty' in the history of FPGAs.  It is hard to argue with that
> > kind of sucess, so I will only suggest that using the 2V40 is an option, and one
> > that should be considered.
>
> You have a very different view of FPGAs from your customers. I don't
> care about the success of a "dynasty". I only care about the utility of
> a specific FPGA for my application. As to the 2V40, that part has only
> 88 IOs regardless of package and would only be usable in one possible
> use on my boards. That particular set of slots is currently being filled
> by a $10 Lucent (opps! Agere) chip while the 2V40 is $29. I am trying to
> replace these chips with a single less expensive solution. The XC2V
> parts just aren't cost effective enough.
>

Sure I do (have a different view).  I work for Xilinx, you work for your clients.  You
are my customer.  I am trying to help you solve your problems as effectively as
possible.  If, in that process, I am astonished at the success of a product that
solved not only your problems, but everyone else's, I want to see what we did right,
and do it more, and what we did wrong, and do it less.

And, if you do not care that Virtex was successful, then I am a bit surprised!

When I did jobs for my clients, it was important to choose suppliers that had superior
quality, reliability, stability, and support.

My clients sure as hell wouldn't let me design in parts that came from "fpga's R Us*."

*Used as an example only.  Purely a fictional company.  Any possible resemblance to
any FPGA supplier, living or dead is purely coincidental, and not the intent of the
author.

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

--------------8BA419420E4C016985287943
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Rick,
<p>See inbetween the lines, below.
<p>Austin
<p>rickman wrote:
<blockquote TYPE=CITE>Austin Lesea wrote:
<br>>
<br>> Rick,
<br>>
<br>> All fair and reasonable comments.
<br>>
<br>> The Virtex II has agressive forward pricing as a new product, and
you would need
<br>> to contact your appropriate sales channel.&nbsp; The prices you quote,
are of course,
<br>> today's list prices.&nbsp; I would say that some very large accounts
are looking at
<br>> the 2V40 and 2V80, where they would normally be interested in the
Spartan IIE
<br>> parts, and they have no problem with the pricing.
<p>I got this pricing from my distributors. I am not a large customer so
we
<br>don't get promises of big discounts. Even if I were larger, I seriously
<br>doubt that the part I would need due to pin count considerations will
be
<br>dropping from $146 to $50 or less.</blockquote>
OK.&nbsp; I hear you there.&nbsp; This is something of a disconnect from
what I was told.&nbsp; If we price 2V40's like that, I can see why you
don't like them.&nbsp; I will go find out why they are listed at this level.
<blockquote TYPE=CITE>> Your comments on IOs are equally valid as to the
numeric count, but if a Virtex
<br>> II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a
~160 Mb/s DDR
<br>> IO, Virtex II wins from a bits per second per package point of view.&nbsp;
If you go
<br>> to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty
respectable.
<p>This does not help for many designs. If a new design can run a
<br>arbitrarily high clock rate, then this would be ok. But many, if not
<br>most, designs have set constraints on clock speeds and IO rates. I
can't
<br>change the number of IOs or the clock speed of a PCI interface for
<br>example.
<br>&nbsp;</blockquote>
True, for a given problem, there may be no ability to do an optimal systems
solution.
<blockquote TYPE=CITE>> Additionally, Spartan IIE has fewer power and ground
pins than Virtex E, so the
<br>> SSO table is less agressive, so unless you just need lots of LEDs
and switches
<br>> (which a lot of Spartan applications do require), you can't really
run the IOs
<br>> as agressively.&nbsp; So the ~160 Mb/s per pin of Spartan IIE is
not sustained across
<br>> as many IOs (exceeds SSO guideline).
<br>>
<br>> So what to choose?&nbsp; I would suggest that you look at more than
just the pin
<br>> counts, and look into the speeds, strengths, SSO's, and so on.&nbsp;
Maybe Spartan
<br>> IIE is the best for you.
<p>Does the Spartan IIE get around the heavy startup currents? Otherwise
I
<br>might as well stick to the Spartan II since they are a bit cheaper.
<br>&nbsp;</blockquote>
The Spartan IIE parts are smaller, so the currents are smaller.&nbsp; But
I think that Spartan II is going to have lower values for the power on.
<blockquote TYPE=CITE>&nbsp;
<br>> As for 2 amperes at -40C, this is the legacy of the orginal Virtex
design, and
<br>> we have only had the opportunity to address it in Virtex II, as Virtex
E and
<br>> Spartan II and Spartan IIE are all derivatives of the original Virtex
design.
<br>>
<br>> Again, this specification as well, is under revision as we characterize
Spartan
<br>> IIE, and Spartan IIE.
<p>I understand the reason for the Spartan IIs having the same problems
as
<br>the Virtex. But I remember this detailed characterization being
<br>announced back at the beginning of the year if I am not mistaken. It
<br>will be necessary to see the results before I can design in two or
three
<br>Spartan II or IIE chips.
<br>&nbsp;</blockquote>
Well.&nbsp; The Spartan II new datasheet numbers are done.&nbsp; The revisions
are in the mill.&nbsp; The Spartan IIE was just announced, so the intitial
datasheets will be more conservatively stated until we have sufficient
silicon to go back and look at it again.
<blockquote TYPE=CITE>> I would also like to say that the Virtex family
and it derivatives is the best
<br>> selling FPGA 'dynasty' in the history of FPGAs.&nbsp; It is hard
to argue with that
<br>> kind of sucess, so I will only suggest that using the 2V40 is an
option, and one
<br>> that should be considered.
<p>You have a very different view of FPGAs from your customers. I don't
<br>care about the success of a "dynasty". I only care about the utility
of
<br>a specific FPGA for my application. As to the 2V40, that part has only
<br>88 IOs regardless of package and would only be usable in one possible
<br>use on my boards. That particular set of slots is currently being filled
<br>by a $10 Lucent (opps! Agere) chip while the 2V40 is $29. I am trying
to
<br>replace these chips with a single less expensive solution. The XC2V
<br>parts just aren't cost effective enough.
<br>&nbsp;</blockquote>
Sure I do (have a different view).&nbsp; I work for Xilinx, you work for
your clients.&nbsp; You are <b>my </b>customer.&nbsp; I am trying to help
<b>you</b> solve your problems as effectively as possible.&nbsp; If, in
that process, I am astonished at the success of a product that solved not
only your problems, but everyone else's, I want to see what we did right,
and do it more, and what we did wrong, and do it less.
<p>And, if you do not care that Virtex was successful, then I am a bit
surprised!
<p>When I did jobs for my clients, it was important to choose suppliers
that had superior quality, reliability, stability, and support.
<p>My clients sure as hell wouldn't let me design in parts that came from
"fpga's R Us*."
<p>*Used as an example only.&nbsp; Purely a fictional company.&nbsp; Any
possible resemblance to any FPGA supplier, living or dead is purely coincidental,
and not the intent of the author.
<blockquote TYPE=CITE>&nbsp;
<br>--
<p>Rick "rickman" Collins
<p>rick.collins@XYarius.com
<br>Ignore the reply address. To email me use the above address with the
XY
<br>removed.
<p>Arius - A Signal Processing Solutions Company
<br>Specializing in DSP and FPGA design&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; URL
<a href="http://www.arius.com">http://www.arius.com</a>
<br>4 King Ave&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
301-682-7772 Voice
<br>Frederick, MD 21701-3110&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
301-682-7666 FAX</blockquote>
</html>

--------------8BA419420E4C016985287943--


Article: 37037
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 16:58:13 -0800
Links: << >>  << T >>  << A >>
Brad,

 http://www.support.xilinx.com/partinfo/ds003-3.pdf

for virtex.

The power on current is all required at ~ twice the Vt of the core transistors.  Somewhere from
0.8 to 1.0 Vdc.

A switcher running from 5 V (like the Elantec parts: >95% efficient) would supply a lot of current
at that moment, being power limited, rather than current limited.  Good point.

For pricing on any parts, I can not speak, as I do not know.  Our sales partners have their set
pricing, based on all of the objectives .... so on and so forth.

I know what our suggested pricing is, but that is not going to help you at all.

The fact is that the Virtex II and Virtex E is less expensive to make than Virtex, for the same
number of LUTs due to the shrink in technology (.22u to .18u to 0.15u).  The same is true for
Spartan II to Spartan IIE.

Moving to 300 mm wafers also increases the yield, so parts on the new 300 mm wafers cost us less
to make as well.

All of this gets passed along to the customer, through the pricing models.

Austin



Brad Eckert wrote:

> Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0517E1.D2BA1B8C@xilinx.com>...
> >
> > In the data sheet there is a 'Supply Current Requirements During Power On'
> > section for all Xilinx FPGAs.
> >
> >  http://www.support.xilinx.com/partinfo/ds001_3.pdf
> >
> According to the data sheet, this heavy current demand occurs during
> voltage rampup. Switching regulators put out more current at low
> voltage, so if 500mA current peak occurs at, say, 0.8V and the
> regulator's input is 5V then the 5V power supply would see something
> like 500*0.8/5 mA. About 100 mA with a 80% efficient switcher.
>
> As long as you're characterizing startup current, it would be useful
> to know at what voltage the heaviest current draw occurs. For example,
> some of my applications use USB, so I have limits on what I can draw
> from the 5V supply if the device is bus-powered.
>
> I thought Virtex was a lot more expensive than Spartan. What price
> point do you expect for the 2V80 in 2Q 2002?
>
> BTW, do you have a link to Virtex power requirements?


Article: 37038
Subject: Re: Help needed in choosing the right PC for VLSI EDA
From: Serial # 19781010 <mpub@sohu.com>
Date: Thu, 29 Nov 2001 09:29:30 +0800
Links: << >>  << T >>  << A >>
Hi,
Would like to list some Eda tools' names and links used
on linux?


Article: 37039
Subject: Re: maximum output current on Spartan2
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 29 Nov 2001 03:36:49 GMT
Links: << >>  << T >>  << A >>
On Wed, 28 Nov 2001 08:07:16 -0800, Austin Lesea
<austin.lesea@xilinx.com> wrote:

Hi Austin,

[snip off topic stuff]
>
>The maximum current into, or out of a pin on a static basis is stated int
>he absolute maximum DC ratings of the data sheet as 10 mA (notes 4 and 5)
>for voltages forced above or below ground.  The AC current is listed as
>less than 100 mA.

I understand these limits are latchup related.   The I/O voltage will
always be between the supply rails, so I don't think these apply.

>If you are pulling up a load, as you describe, I expect the current to be
>at least 24 mA, and perhaps as much as 60 mA, with no ill effects, forever
>as long as you are within the Vol, Voh limits as well (ie not dissipating
>a lot of power in the pmos pullup device, as it has a small voltage drop).

Are you saying that metal migration doesn't happen in Spartan2?  The
4000E devices had a limit of 20mA, based on metal migration.

The output voltage is clamped well below Voh (actually about 900mV to
1V above ground), so I'll be dissipating a lot of power in the output.
How do I find out the actual device limits for this case?

I expect that there will be a few limits:
1.  A maximum steady state current, based on metal migration
2.  A maximum power dissipation in the output transistor(s), based on
localised heating on the die.
3.  A maximum current, with the voltage outside the supply rails,
based on latchup.

The data sheet has values for (1) but not the others.  To know whether
the particular design I'm interested in will work reliably, I require
the other parameters.

I realise that the output driver wasn't meant to be (ab)used in this
way, but a redesign isn't possible.

Thanks,
Allan.

>Austin
>
>Allan Herriman wrote:
>
>> Hi,
>>
>> I'm looking for the maximum current I can draw from a Spartan2 output
>> (LVTTL mode) without impairing reliability.  I'm only interested in
>> sourcing current (i.e. from the P channel strong pullup).
>>
>> I found Xilinx Answer 4453:
>> http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=4453
>> that says that the figure is 20mA for 4000E/XL devices, based on metal
>> migration.
>>
>> I couldn't find any figures for Spartan2 though.
>>
>> My next question: how does this scale with the selected I/O standard?
>> E.g. if an LVTTL24 output has an absolute maximum current of 'X' mA,
>> will an LVTTL12 output have an absolute maximum current of 'X' mA, or
>> 'X'/2 mA?
>> I guess it depends on which bits of metalization are the 'critial
>> path'.
>>
>> Thanks,
>> Allan.
>


Article: 37040
Subject: Re: maximum output current on Spartan2
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 29 Nov 2001 17:02:31 +1300
Links: << >>  << T >>  << A >>
Allan Herriman wrote:
> 
<snip> 
> The output voltage is clamped well below Voh (actually about 900mV to
> 1V above ground), so I'll be dissipating a lot of power in the output.
> How do I find out the actual device limits for this case?
> 
> I expect that there will be a few limits:
> 1.  A maximum steady state current, based on metal migration
> 2.  A maximum power dissipation in the output transistor(s), based on
> localised heating on the die.
> 3.  A maximum current, with the voltage outside the supply rails,
> based on latchup.
> 
> The data sheet has values for (1) but not the others.  To know whether
> the particular design I'm interested in will work reliably, I require
> the other parameters.
> 
> I realise that the output driver wasn't meant to be (ab)used in this
> way, but a redesign isn't possible.

 Where I saw this tried on a uC, it failed in practice.

You will need to  characterise this yourself, as the IC suppliers
do not do these tests.
 At significant current levels, the drop across the FET should be < 1V,
and typ 0.5V. 
 This tends to self-adjust, as a large PFET area can dissipate more, but
has a lower on resistance.

 Above this, (continuous) and you start cooking the silicon / metalise.

 You could get an indication of the Temp rise, by ploting the drive
current,
which will decrease as the local heating occurs
 It will also vary batch to batch.

 Can you pick LVDS drive, which limits to 8mA, for this pin(s) ?

 What's clamping the pin, and why is a redesign not possible ?

-jg

Article: 37041
Subject: Re: Help needed in choosing the right PC for VLSI EDA
From: "Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in>
Date: Thu, 29 Nov 2001 11:07:46 +0530
Links: << >>  << T >>  << A >>
Hi Thomas,

"Thomas Stanka" <thomas.stanka@de.bosch.com> wrote in message
news:Xns91675D2429562Stankasatcom@127.0.0.1...
> Xpost F'up2caf set.
>
> "Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in> wrote:
> > Pentium 4
> > OS: Windows XP (and Linux - will RH 7.1 do?)
>
> RH 7.1 should do for most tools that support Linux (great exception
is
> Synopsys tools in GUI-mode which need an older version of RH. AFAIK
> Pentium4 needs RH 7)
>
> > RAM: 256 MB
>
> Not enough for EDA. Take 511 MB to 1 GB. I think memory is the wrong
place
> to save money in EDA. BTW which type of RAM ?
>
> > Many other stuff are moderately high-end and I would like to know
if
> > any thing else (than listed above) will impact the PC for EDA
Usage.
> > The EDA Usage will be mostly based on FREE tools
>
> While doing simulation with Modelsim I learned that the graphiccard
has to
> be good (not excellent). No onboard 8MB graphiccard or something
like that,
> but of course you don't need the latest card with 128MB or more.
>

    Thanks for the information.

> > Sorry for this slightly off-technical post.
>
> I don't think you miss the topic. But please learn to qoute and set
a
> Followup2 while Xposting.
>

   Ok, I have now set "Show All Headers" and see what you mean. I
remember (vaguely) reading somewhere that a post being posted to
multiple NGs is a actually a SINGLE copy and all the NGs "refer" to
it - may be I had mistaken. Anyway will be careful from now on -
Thanks for the hint.

Bye,
Srinivasan

> bye Thomas
>
> --
> Thomas Stanka BC/EMD4
> Space Communications Systems
> Tesat Spacecom GmbH & Co KG
> thomas.stanka@de.bosch.com

--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
"I don't Speak for Intel"





Article: 37042
Subject: Re: FPGA startup current
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Thu, 29 Nov 2001 16:54:09 +1100
Links: << >>  << T >>  << A >>
If the SMPS was connected to the load only after its output
caps had charged, then the current spike should be very short,
and no load would happen on the regulator.

Austin Lesea wrote:
> 
> Brad,
> 
>  http://www.support.xilinx.com/partinfo/ds003-3.pdf
> 
> for virtex.
> 
> The power on current is all required at ~ twice the Vt of the core transistors.  Somewhere from
> 0.8 to 1.0 Vdc.
> 
> A switcher running from 5 V (like the Elantec parts: >95% efficient) would supply a lot of current
> at that moment, being power limited, rather than current limited.  Good point.
> 
> For pricing on any parts, I can not speak, as I do not know.  Our sales partners have their set
> pricing, based on all of the objectives .... so on and so forth.
> 
> I know what our suggested pricing is, but that is not going to help you at all.
> 
> The fact is that the Virtex II and Virtex E is less expensive to make than Virtex, for the same
> number of LUTs due to the shrink in technology (.22u to .18u to 0.15u).  The same is true for
> Spartan II to Spartan IIE.
> 
> Moving to 300 mm wafers also increases the yield, so parts on the new 300 mm wafers cost us less
> to make as well.
> 
> All of this gets passed along to the customer, through the pricing models.
> 
> Austin
> 
> Brad Eckert wrote:
> 
> > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0517E1.D2BA1B8C@xilinx.com>...
> > >
> > > In the data sheet there is a 'Supply Current Requirements During Power On'
> > > section for all Xilinx FPGAs.
> > >
> > >  http://www.support.xilinx.com/partinfo/ds001_3.pdf
> > >
> > According to the data sheet, this heavy current demand occurs during
> > voltage rampup. Switching regulators put out more current at low
> > voltage, so if 500mA current peak occurs at, say, 0.8V and the
> > regulator's input is 5V then the 5V power supply would see something
> > like 500*0.8/5 mA. About 100 mA with a 80% efficient switcher.
> >
> > As long as you're characterizing startup current, it would be useful
> > to know at what voltage the heaviest current draw occurs. For example,
> > some of my applications use USB, so I have limits on what I can draw
> > from the 5V supply if the device is bus-powered.
> >
> > I thought Virtex was a lot more expensive than Spartan. What price
> > point do you expect for the 2V80 in 2Q 2002?
> >
> > BTW, do you have a link to Virtex power requirements?

Article: 37043
Subject: Re: maximum output current on Spartan2
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 29 Nov 2001 07:27:17 GMT
Links: << >>  << T >>  << A >>
On Thu, 29 Nov 2001 17:02:31 +1300, Jim Granville
<jim.granville@designtools.co.nz> wrote:

>Allan Herriman wrote:
>> 
><snip> 
>> The output voltage is clamped well below Voh (actually about 900mV to
>> 1V above ground), so I'll be dissipating a lot of power in the output.
>> How do I find out the actual device limits for this case?
>> 
>> I expect that there will be a few limits:
>> 1.  A maximum steady state current, based on metal migration
>> 2.  A maximum power dissipation in the output transistor(s), based on
>> localised heating on the die.
>> 3.  A maximum current, with the voltage outside the supply rails,
>> based on latchup.
>> 
>> The data sheet has values for (1) but not the others.  To know whether
>> the particular design I'm interested in will work reliably, I require
>> the other parameters.
>> 
>> I realise that the output driver wasn't meant to be (ab)used in this
>> way, but a redesign isn't possible.
>
> Where I saw this tried on a uC, it failed in practice.
>
>You will need to  characterise this yourself, as the IC suppliers
>do not do these tests.
> At significant current levels, the drop across the FET should be < 1V,
>and typ 0.5V. 
> This tends to self-adjust, as a large PFET area can dissipate more, but
>has a lower on resistance.
>
> Above this, (continuous) and you start cooking the silicon / metalise.
>
> You could get an indication of the Temp rise, by ploting the drive
>current,
>which will decrease as the local heating occurs
> It will also vary batch to batch.
>
> Can you pick LVDS drive, which limits to 8mA, for this pin(s) ?

No LVDS on Spartan2.

> What's clamping the pin, and why is a redesign not possible ?

It's connected to the base of an NPN BJT.  The emitter is connected to
ground.  There's no resistor.

It's not my design.  I'd like to find out how reliable it's going to
be.

If it turns out that these things will fail after a month, then I
guess a redesign *is* possible :)

2nd best option would replace the BJT with a pin compatible N-ch
MOSFET.  A component change isn't as bad as a board change.

Regards,
Allan.

Article: 37044
Subject: Re: DLL cycle-to-cycle jitter
From: Nurit.Eliram@mailandnews.com
Date: Thu, 29 Nov 2001 07:48:20 GMT
Links: << >>  << T >>  << A >>


Hi Austin.
I do'nt understand.
What is "jitter filer" ?
What is the "tap rate" ?

I understand that tap step is ~50 ps.
Do you mean that the minimum time it takes to reach to
the maximum period jitter is 256 cycles ???

Bye,
Nurit

In article <3C050C22.4C93DBEF@xilinx.com>, Austin Lesea says...
>
>answered separately,
>
>jitter filer * 256 = update of the tap rate.
>
>Austin
>
>Nurit.Eliram@mailandnews.com wrote:
>
>> Hi Austin.
>> ThankX for the answer.
>> Since the DLL period jitter is ~150 ps,
>> and the DLL cycle-to-cycle jitter is ~50 ps,
>>
>> I have the following question :
>>
>> Is the worst case is that for 3 consequtive clock cycles the
>> jitter will rise to it's max value of ~150 ps,
>> Or the worst case is that it will rise slower (i.e 100 clock cycles) ?
>>
>> Do I have a measure of time what is the minimum numver of clock
>> cycles for the period jitter to happen ???
>>
>> Thanks
>> Nurit.
>>
>> In article <3BF94DBD.863C2064@xilinx.com>, Austin Lesea says...
>> >
>> >Nurit,
>> >
>> >From any cycle, to the next cycle, the period out of the Virtex II DCM
>> >(using the DLL feature) can not change by more than a tap value, plus
>> >whatever input jitter may also be present.
>> >
>> >For Virtex II that is ~ 55ps.
>> >
>> >The period jitter is measured by accumulating a histogram of > 200,000
>> >periods, and fitting  a gaussian curve (left and right tail fitting) to get
>> >the peak to peak value.
>> >
>> >Spectral analysis of the histogram shows that the jitter is random, and has
>> >no deterministic component.
>> >
>> >Thus the input jitter going into the DLL may be added to the internal jitter
>> >quadratically to get the output jitter.
>> >
>> >Clock forwarded interfaces have larger margin as a result, as the cycle to
>> >cycle jitter is important as to the sampling of input data by the IOB's.
>> >Worst case, the input data sampling instant error is not the peak to peak
>> >value, but the cycle to cycle value.
>> >
>> >This behavior is completely different than than of a PLL, where the PLL
>> >usually provides some filtering of high frequency jitter components, and
>> >where there is no fixed relationship from an input clock to an output clock
>> >as there is in the DLL (PLL cycle to cycle jitter is bounded only by the
>> >peak to peak jitter, whereas the DLL cycle to cycle jitter is bounded the
>> >delay line tap change).
>> >
>> >Austin
>> >
>> >nurit eliram wrote:
>> >
>> >> Hi.
>> >> I have seen that the period jitter of DLL of virtex-II device is 150 ps.
>> >>
>> >> Can I have any figures about it's cycle-to-cycle jitter ?
>> >>
>> >> ThanKX
>> >
>



Article: 37045
Subject: Re: SpartanIIE
From: "Damir Danijel Zagar" <dzagar@srce.hr>
Date: Thu, 29 Nov 2001 09:12:18 +0100
Links: << >>  << T >>  << A >>
According to Spartan-IIE datasheet, both 200 parts have the same
amount of block ram (56k).

Damir


"Jan Gray" <jsgray@acm.org> wrote in message
news:9u3knp$53a$1@slb4.atl.mindspring.net...
> "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
> news:3C0535D4.868C1E65@algor.co.uk...
> > o Do they relate to VirtexE's in the same way as SpartanII did to the
> > Virtex ? Esp wrt timing.
>
> http://fpgacpu.org/#011120:
>
> "You might think that
>
>    as Virtex-E is to Virtex, so is Spartan-IIE to Spartan-II
>
> But you would be wrong. According to data sheets, whereas an XCV200 has 14
> BRAMs (56 Kb) and the XCV200E has 28 BRAMs (112 Kb), in the Spartan-II/E
> family, both the XC2S200 and (alas) the XC2S200E have the same 14 BRAMs
(56
> Kb).
> ...
> But let us count our blessings. The new Spartan-IIE family is
lower-voltage,
> faster (470 ps TILO (2SxxxE-6) vs. 700 ps TILO (2Sxxx-5)), offers a larger
> part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of
different
> I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208
> QFP packages. "
>
> Jan Gray
> Gray Research LLC
>
>
>



Article: 37046
Subject: Re: Creating a jitter free clock
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 29 Nov 2001 08:19:14 -0000
Links: << >>  << T >>  << A >>
>The beautiful thing about the hydrogen maser, is that it is 1E-14, but at
>frequency all its own (in other words, not related by physics to a standard,
>like a cesium standard).

??  What does the frequency depend upon?  Hasn't somebody measured
the magic number even if we don't know how to do the caclulations?

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


Article: 37047
Subject: Re: Creating a jitter free clock
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 29 Nov 2001 08:26:18 -0000
Links: << >>  << T >>  << A >>

> I'll tell you exactly what I need it for. I have designed an FPGA based
> Pulsar timer for a radio astronomy observatory. What the instrument
> essentially does is coherent averaging on pulses coming from neutron
> stars (pulsars)to build up a pulse profile. Averaging, right now, will
> take place over a maximum of 5 minutes, although this will probably be
> much less in the future. 

What does "coherent averaging" mean?  What's a "pulse profile"?

> I need to be able to set a user defined sampling frequency to this
> resolution, and not have at move at all. If it does, it means that
> the pulse will being to drift across the averaged profile, and move
> around with jitter.

I'm missing the big picture.  If you had the magic clock that you
want, what would you do with it?

Are you looking at the shape of an analog pulse?  Or just the timing
of a digital pulse?

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


Article: 37048
Subject: 128-bit scrambling and CRC computations
From: olupas@opencores.org (Ovidiu Lupas)
Date: 29 Nov 2001 01:38:37 -0800
Links: << >>  << T >>  << A >>
Hi all,

In my current project I have to implement scrambling and CRCs over a
128-bit data bus at a clock rate of 100 MHz. My combinatorial areas
are huge and I am having problems meeting the speed requirements.

Could someone give me an hint how to overcome this problem ? 
Any hints will be appreciated.

Thank you for your time.

Best regards,
    Ovidiu Lupas.

Article: 37049
Subject: Re: xilinx foundation 3.1 and pentium 4
From: khtsoi@cse.cuhk.edu.hk
Date: 29 Nov 2001 09:42:21 GMT
Links: << >>  << T >>  << A >>
H.L <alphaboran@yahoo.com> wrote:
> Hi all,
> i have problems when i try to install xilinx foundation 3.1 on a p4 system.
> i heard that the program is not compatible with this processor, is that
> true? if yes, what do i need to download to make the program run properly?

> Take  care
> Harris

The Java runtime comes with 3.1i is not for P4 system.
The solution is to copy all the data from CDs to HDD and then
replace the java with the newly downloaded one. Finally install
the software from HDD.
---- Brittle



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