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 37000

Article: 37000
Subject: Re: DLL cycle-to-cycle jitter
From: Nurit.Eliram@mailandnews.com
Date: Wed, 28 Nov 2001 12:43:14 GMT
Links: << >>  << T >>  << A >>

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: 37001
Subject: Re: Simple Logic State Analyser
From: c_oflynn@yahoo.com (Colin O'Flynn)
Date: 28 Nov 2001 04:54:53 -0800
Links: << >>  << T >>  << A >>
Hi Again,

  If no one has done this before, and you don't really want to spend
all that time figuring out how to make the logic anaylzer, concider
buying a kit or the plans. This place sells both,
http://www.alta-engineering.com/LOGWEB.HTM the kit is pretty
expensive, but It looks like a pretty good logic anaylzer. The March
1998 Electronics Now had the plans for it, and the November 1998 issue
of Electronics Now had the plans for the speed-doubling adapter for
it. However you would also need the July 1998 Issue as it had the
corrections for the logic anaylzer. However you still have to buy the
software for $10, so its just as easy to buy the plans.

   Good Luck!

       -Colin

PS: The main IC is a ispLSI1016E

Article: 37002
Subject: Need a Revision man for my project
From: dottavio@ised.it (Antonio)
Date: 28 Nov 2001 05:38:36 -0800
Links: << >>  << T >>  << A >>
There's a good men that want to take a look at my vhdl QPSK modulator,
it works but probably it needs some adjustment due to your experience.
I could send you the ActiveHDL 5.1 project or the Sinplify 7.01
Project or the VHDL files simply.
Thanks

   Antonio

Article: 37003
Subject: Re: XST design flow for XC4010XL
From: Kamal Patel <kamal.patel@xilinx.com>
Date: Wed, 28 Nov 2001 08:01:00 -0700
Links: << >>  << T >>  << A >>
Hello Bernd,

That is an error in the documentation that will be noted and fixed.
The older 4000 and Spartan / Spartan-XL devices are not supported
by XST.  Sorry for any inconvenience.

Regards,
Kamal

Bernd Scheuermann wrote:

> Hi,
>
> when creating a new project in Foundation ISE 4, I selected XC4010XL as
> device and I searched for XST design flow for that chip. Unfortunately, only
> EDIF and FPGA Express are offered, even though XST should be available
> according to the help tool:
>
> "For XST, you can synthesize the following families. Virtex, VirtexE,
> Virtex2, Virtex2P, Spartan, Spartan2, Spartan2E, SpartanXL, XC4000E,
> XC4000EX, XC4000L, XC4000XL, XC4000XLA, XC9500, XC9500XL, XC9500XV,
> CoolRunner XPLA3, CoolRunner II."
>
> Do you have an explanation for that?
>
> Thanx a lot!!!
>
> Bernd
>
> --
> * Bernd Scheuermann, Institute AIFB, University of Karlsruhe, Germany
> * e-mail: scheuermann@aifb.uni-karlsruhe.de


Article: 37004
Subject: Re: maximum output current on Spartan2
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 08:07:16 -0800
Links: << >>  << T >>  << A >>
Allan,

Download the IBIS files.

Then you can read the I/V curves (either by importing them into a
spreadsheet), or plotting them by hand.

Pick the IO you like.  The strongest IO will the the LVTTL 24 for 3.3
Volts.  The minimum current under all corners of
process/voltage/temperature is 24 mA, so the maximum is much greater than
that.

You can also download the free demo version of Hyperlynx (Innoveda's IBIS
tool) and do all of this fun stuff quickly and correctly without all of
the fiddling around).

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.

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

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: 37005
Subject: Re: DLL cycle-to-cycle jitter
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 08:09:06 -0800
Links: << >>  << T >>  << A >>
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: 37006
Subject: Re: Got enough mebibytes of RAM ?
From: "Victor Schutte" <victors@mweb.co.za>
Date: Wed, 28 Nov 2001 18:13:16 +0200
Links: << >>  << T >>  << A >>
I just got my wife to work with computers and now they have gone and made it
all complicated again..." No dear, a kibi is a lot less than a gibi..."

They call it the Nist Reference on Constants, Units and Uncertainty.  I
think this only applies to Uncertainty.


"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3C04269A.B77CECDB@algor.co.uk...
>
>
> Peter Alfke wrote:
>
> > We all need a laugh now and then.
> > This one is good for a serious smile, whatever that is.
> >
> > http://physics.nist.gov/cuu/Units/binary.html
> >
> > Peter Alfke
>
> Priceless!
>
> Do you happen to know if they're hiring ? Sounds like a nice relaxing
> place to hunker down for the recession.
>
>
>



Article: 37007
Subject: FPGA startup current
From: brad@tinyboot.com (Brad Eckert)
Date: 28 Nov 2001 08:14:58 -0800
Links: << >>  << T >>  << A >>
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

Article: 37008
Subject: Kibibytes?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 08:49:26 -0800
Links: << >>  << T >>  << A >>
Sounds like dog food.

Austin



Article: 37009
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 08:59:13 -0800
Links: << >>  << T >>  << A >>
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


Article: 37010
Subject: Re: don't cares and X's in a case statement?
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Wed, 28 Nov 2001 12:04:49 -0500
Links: << >>  << T >>  << A >>
Peter,
    What drove the invesatigation of this alternative is the requirement for
bufgmux's.  In order to properly gate the clock to each counter you need a bufgmux
for each clock.  You also need a bufgmux for the feedback for each DCM.  In addition
the clock input requires a bufgmux.  In my case I was looking at using 8 counters.
This requires 2 DCM's and of course 1 clock input.  I can see using the primary
bufgmux's as the clock gates for the counter.  Then the feedback ca be carefully
assigned to two of the secondary bufgmux's.  Unfortunately I cannot see a way to get
that primary clock buffer in anywhere.

For example I thought that I could DCM1 in the NE quadrant and DCM2 in the SE
quadrant.  DCM1 generates clock0, 90, 180, and 270.  DCM2 generates clock45, 135,
225, and 315.  Now I can put feedback 0 in 0S and feedback45 in 1S.  clock0 is the
clock for counter0, etc.

clock0      7P    counter0      NW quadrant
clock45    6P    counter45    SW
clock90    5P    counter90    NW
clock135  4P    counter135  SW
clock180  3P    counter180  NE
clock225  2P    counter225  SE
clock270  1P    counter270  NE
clock315  0P    counter315  SE

Unfortunately, what can I share the input clock with?

I tried to design my own glitch free clockmux and it was less than desired.

So, assuming I haven't missed some simple (or not so simple) trick, where do I get
the extra bufgmux?

As a result, I considered the sampled clock approach I mentioned.  I have pretty
much discarded the sampled clock approach because of routing delay issues.  I
suspect that it would work well in a dedicated ASIC or custom IC but the issues are
probably too tricky for an FPGA based system.  To bad, as it would have yielded
double the resolution with many fewer gates required.

Thanks,
Theron

Peter Alfke wrote:

> Three comments:
> 1.The X is really "only" a simulation issue. In reality, the latch will either
> be 0 or 1.
> X only exists in the unreal world of simulation.    :-(
> 2. A BlockRAM can make a nice encoder, especially when you can use both ports
> independently...
> 3. I still prefer your original counter approach, but I would use 16 binary
> ripple counters ( each composed of cascaded 2-bit Johnson counters in a slice).
> Thus the routing delays don't matter. Wait a little after closing the last gate,
> then perform the addition. Could be done in a serial adder, since you probably
> have plenty of time after the end of the capture.
> Just thinking...
>
> Peter Alfke
> ==========================
> Theron Hicks wrote:
>
> > Hi,
> >     I am designing a system where I have multiple (16) clocks coming
> > from 4 DCM's in a Virtex2.  These clocks are staggered by an equal phase
> > delay such that the clocks are phase delayed by 360/16 degrees from each
> > other.  I am then latching these into a sixteen bit latch.  I need to
> > know when in the cycle the latch pulse occurs.  To determine this I am
> > looking for a series of '1's followed by a zero in the 16 bit data
> > word.  In the simulation I may get an X (unknown) in the edge between
> > the 1's and 0's.  For example, "1111 X000 0000 X111" or "00X1 1111 11X0
> > 0000".  As a result I am looking for at least 6 '1's in a row.
>
> <snip>
>
> > By the way, the purpose of this code is give me a very precise
> > measurement of a pulse width.  The main clock is 200MHz, thus, in
> > theory, the resolution is equivalent to using a 3.2GHz clock.  I tried
> > to use multiple counters and sum the resultant count values, but I was
> > limited by the clock routing capacity of the virtex2.  In theoy, there
> > are 16 clock muxes, but in practice you are lucky to use more than 8.
> > This greatly limits the required number of clock channels, as the 16
> > phases are not really clock channels.  They do require low skew routing,
> > however.
> >
> > Thanks,
> > Theron Hicks


Article: 37011
Subject: Re: Creating a jitter free clock
From: John_H <johnhandwork@mail.com>
Date: Wed, 28 Nov 2001 17:24:25 GMT
Links: << >>  << T >>  << A >>
The 1pps reference from the hydrogen maser may give you the correction you need to use a sloppier (read: cheaper) timing reference.

If you only need a 32MHz sampling of a very high resolution clock I'd suggest that jitter is not as much of a problem (defined as high frequency phase deviation of the timing source) as much as wander (low frequency phase deviation) to borrow terms from the telecom folks.  FPGAs will induce high frequency jitter (cycle-to-cycle values) that contribute an error of 20-200ps due
to local digital effects like simultaneous switching.  Intermediate jitter should give you about 250ps of inaccuracy for some decent clock elements (check the datasheets).  Since these jitter values are effectively random, the averaging you persue will be affected much more by the limited resolution (32MHz gives >30ns) than by the sampling error.

If you want numbers that give you even better precision, techniques are available that can improve your sampling resolution to a few picoseconds.  The averaging required would be significantly reduced.  If pulsar pulses are accurate to ppb levels, you really just need to count up an integer number of pulses in approximately 5 minutes and only worry about the partial second at
each end of the count since the 1pps can give you the extreme precision you need at the long time scale.

Have fun with the stuff!


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


Article: 37012
Subject: Re: Creating a jitter free clock
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 09:55:16 -0800
Links: << >>  << T >>  << A >>
Adrian,

Can you also have access to a much higher frequency? (IE a 10 MHz
reference?)

By the time it is reduced to 1 PPS, it is worthless.  Good for clocks on the
wall, maybe.

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

So, with a hydrogen maser, you have this extremely small drift,  about 100
times less than a cesium, but you don't really know what its frequency is.

You can average it for a year, and compare it with a GPS derived reference,
and then you can get close to knowing the answer.

If all you want is an extremely precise time tick, and you don't really care
that it is +/- 1E-11, then use the maser.  But I would start with the
highest frequency it can provide, as jitter is everywhere, and once you
divide down to 1 PPS, it is hard to measure anything precisely.

Just think of waiting 1E14 seconds to make a 1E-14 measurement ....

Austin

adrian wrote:

> Hi,
>
> Forgot to mention, the system does have access to a 1pps hydrogen MASER.
>
> adrian


Article: 37013
Subject: CALL FOR PAPERS - RTC 2002
From: Phil James-Roxby <phil.james-roxby@xilinx.com>
Date: Wed, 28 Nov 2001 11:13:05 -0700
Links: << >>  << T >>  << A >>
CALL FOR PAPERS - RTC 2002
****************************************************************************
Reconfigurable Technology: FPGAs & Reconfigurable Processors
for Computing and Applications (7th Year)
at SPIE sponsored   ITCOM 2002   29-30 July 2002, Boston MA
****************************************************************************

RTC Website: http://www.vcc.com/RTC/RTC.html

ITCOM Website:
http://spie.org/Conferences/calls/02/itcom/confs/IT203.html

INTRODUCTION:  In the late 1980’s, when Reconfigurable Technology  (RT)
was
in its  infancy, the largest programmable logic devices (FPGAs) had 2K
gates
of reconfigurable  logic.  Far from enough logic real-estate to build
computing devices or systems. Recent  advances in the manufacturing
process
promises 50 million gates of reconfigurable logic by  2005 at
substantially
lower costs.  The increased gate count along with richer embedded 
feature
sets have greatly improved the economics for using RT in the general
marketplace.   ASIC manufacturers are embedding reconfigurable logic
into
ASICs and FPGA  manufacturers are embedding Hard Cores into FPGAs. The
design tools and system  platforms for ASICs and FPGAs are merging.
Furthermore, embedding processors in  FPGAs as either hard cores or as
soft
macros leads to many new target applications, as  well as many new
design
and tool challenges.

Toolmakers are actively building high-level compilers for hardware
design
implementation  based upon the C and Java programming languages to make
system programming easier.  These factors have added to the acceleration
of
the commercial use for reconfigurable  technology and their
applications.

PURPOSE: To bring together researchers, manufacturers and users of
reconfigurable  technology for processors, communications, computing and
applications. Contributions are  solicited on all aspects of
reconfigurable
technologies, including but not limited to:

1)      processors,  devices and systems
2)      tools and techniques
3)      applications & designs
4)      commercial implementations

The conference will present papers that illustrate applications and
techniques for using  reconfigurable technology in both design and
production cycles.  Papers relating to the  following areas are
solicited:

·       RT-based communications & networking applications
·       Field programmable devices & reconfigurable processors
·       Adaptive computing systems and architectures
·       Programming tools and methodologies
·       Applications utilizing RC Technologies

Conference Chairs:
John Schewel, Virtual Computer Corp.; Philip James-Roxby, Xilinx Inc.;
John T. McHenry, National Security Agency, Herman Schmit, Carnegie
Mellon
University

IMPORTANT DATES:
        Conference Dates:  29 July – 30 July 2002
      Abstract Due Date: 21 January 2002
        Notification of Acceptance: 1 April, 2002
        Manuscript Due Date: 13 May, 2002

SUBMIT ABSTRACT DIRECTLY
http://butler2.spie.org/abstracts/absin.lasso?-token=IT203

****************************************************************************
-- 
---------------------------------------------------------------------
 __
/ /\/  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: 37014
Subject: Re: Creating a jitter free clock
From: Tom Burgess <tom.burgess@nrc.ca>
Date: Wed, 28 Nov 2001 10:23:12 -0800
Links: << >>  << T >>  << A >>
Maybe this GPS clock with PPS and 10 MHz outputs would do
as a reference? http://www.absolutetime.com/products/100mod.htm
It looks like a small, easy to use package, and is likely
much lower cost. The pulse to pulse jitter of <1 ns RMS is OK
for many applications, and it looks like you are more concerned
with longer term stability anyway.

Adrian wrote:
> 
> Well, the point was to replace the couple hundred thousand dollar clock which can do it!

regards, 
Tom Burgess 
Digital Engineer
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Article: 37015
(removed)


Article: 37016
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 28 Nov 2001 19:37:56 +0100
Links: << >>  << T >>  << A >>
Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> writes:

> I'm looking for an open-source implementation of the entire synthesis
> path for an FPGA, in particular placement, routing, and generation of a
> configuration file for the FPGA. Any pointers to such software would be
> greatly appreciated.

I do not know of any. All I know of are VHDL/Verilog -> EDIF/XNL, then
the vendor tools for P&R take over to do ther top-sekrit work.


> I understand that the scarcity of such software is partly because
> vendors do not release enough information.

s/partly/entirely/

Bad bad vendors :-(.


P.S. to the @xilinx.com readers here: the often given reason for
bitstream secrecy was that the PROM->FPGA link allows it to be grabbed
and disassembled. With V2 the DES stuff was implemented to fix that
hole. Is there any chance that the V2 bitstream will one day be publically
(= non-NDA) documented? Perhaps an XAPP for those that want to know?


> Are there any modern devices
> for which this information *is* available?

AFAIK none. Else I would be using them :-).


> IOW, if I wanted to implement
> an open-source synthesis tool, which devices should I target? Again,
> recommendations would be greatly appreciated.

The nearest I have found is to use Virtex/Spartan-II. For these there
exists JBits. This is an API+library to modify/generate bitsreams. It
is totally low-level (individual CLB features), driven by Java code (so
usable to implement own CAE tools), free (as in beer, not as in speech),
not crippled (such as artificially slowed to make an payware version
attractive), written in Java (runs on Linux and BSD with Sun JDK).


--
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: 37017
Subject: Re: reducing PAR time
From: mrgs1000@yahoo.com (Mark)
Date: 28 Nov 2001 10:48:37 -0800
Links: << >>  << T >>  << A >>
khtsoi@cse.cuhk.edu.hk wrote in message news:<9u1qjp$7um$1@eng-ser1.erg.cuhk.edu.hk>...
> Hi,
> 
> I have a design including many instances (say 100) of a regular
> cell. The design is in form of VHDL codes. The cell use only
> LUTs and FDs and all have RLOC attribute on them.
> 
> Can I find a way to reduce the place and route (par tools from
> Xilinx) time by telling the par tools not to re-consider the
> placement and routing in the identical cells? How?
> 
> Env: Synopsys Design Compiler & Xilinx Alliance 3.1i on SunOS
> 
> Thanks in advance!
> 
> ---- Brittle

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

Article: 37018
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: mrgs1000@yahoo.com (Mark)
Date: 28 Nov 2001 10:58:00 -0800
Links: << >>  << T >>  << A >>
Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90uk0l3mmebi1703urlud5e91rou5af@4ax.com>...
> Hi,
> 
> I'm looking for an open-source implementation of the entire synthesis
> path for an FPGA, in particular placement, routing, and generation of a
> configuration file for the FPGA. Any pointers to such software would be
> greatly appreciated.
> 
> Alternatively:
> 
> I understand that the scarcity of such software is partly because
> vendors do not release enough information. Are there any modern devices
> for which this information *is* available? IOW, if I wanted to implement
> an open-source synthesis tool, which devices should I target? Again,
> recommendations would be greatly appreciated.

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. There are lots of flows for design entry and
simulation, and new devices are released on a weekly basis. I
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. It's a nice dream, but I doubt it will ever become a
reality.

Mark

Article: 37019
Subject: SpartanIIE
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 28 Nov 2001 19:07:00 +0000
Links: << >>  << T >>  << A >>
Can anybody answer:

o Do they relate to VirtexE's in the same way as SpartanII did to the
Virtex ? Esp wrt timing.

o What the ^$%£$£ is an FT package ? I'm beginning to wonder if package
proliferation has taken the place of all those quirky TTL MSI devices I
used to spend a lot of time trying to figure a use for.



Article: 37020
Subject: Re: Creating a jitter free clock
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Nov 2001 11:33:13 -0800
Links: << >>  << T >>  << A >>
Tom,

Nice product.  I tested an earlier version of it a few years back.

Austin

Tom Burgess wrote:

> Maybe this GPS clock with PPS and 10 MHz outputs would do
> as a reference? http://www.absolutetime.com/products/100mod.htm
> It looks like a small, easy to use package, and is likely
> much lower cost. The pulse to pulse jitter of <1 ns RMS is OK
> for many applications, and it looks like you are more concerned
> with longer term stability anyway.
>
> Adrian wrote:
> >
> > Well, the point was to replace the couple hundred thousand dollar clock which can do it!
>
> regards,
> Tom Burgess
> Digital Engineer
> Dominion Radio Astrophysical Observatory
> P.O. Box 248, Penticton, B.C.
> Canada V2A 6K3


Article: 37021
Subject: Re: Creating a jitter free clock
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 29 Nov 2001 08:46:34 +1300
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.
> 
> adrian

 You could then do dual-sampling - store both the Pulsar info, and a
sample of 
an oven xtal, for example, or a GPS locked fast Clock, Colour burst etc
( or all of these :-). 
 This would provide a drift correction slope, as well as giving some
usefull
real numbers on what drift you actually have.
 Then, you are not trying to 'load everything' into one clock: 
Absolute precision, User defined Frequency, and Stability.

-jg

Article: 37022
Subject: Re: FPGA startup current
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Nov 2001 15:04:57 -0500
Links: << >>  << T >>  << A >>
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: 37023
Subject: Re: SpartanIIE
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Nov 2001 15:06:56 -0500
Links: << >>  << T >>  << A >>
I can't say anything about the connection to the Virtex IIE parts except
that I expect that is correct. 

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.



Rick Filipkiewicz wrote:
> 
> Can anybody answer:
> 
> o Do they relate to VirtexE's in the same way as SpartanII did to the
> Virtex ? Esp wrt timing.
> 
> o What the ^$%£$£ is an FT package ? I'm beginning to wonder if package
> proliferation has taken the place of all those quirky TTL MSI devices I
> used to spend a lot of time trying to figure a use for.

-- 

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: 37024
Subject: Re: Device Support in Webpack
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Nov 2001 15:17:52 -0500
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> CoreGen and LogiBlox, methinks, are meta-libraries that are more useful
> if your design-entry method is schematics.  LogiBlox is the "old stuff,"
> CoreGen is the "new stuff."  It's neat in principle to be able to custom
> configure a FIFO or a RAM with CoreGen.  However, I've found that I've
> been able to get better results writing my own code.  Synplify and
> Leonardo both handle RAM inference quite well, so there's no reason to
> instantiate a library component.
> 
> And I'm of the opinion that some of the simulation models Xilinx provide
> -- the CoreGen FIFO, for one -- are broken.  Search the archives of this
> newsgroup, and of comp.lang.vhdl, for more of my bitching and moaning in
> that regard.
> 
> --andy
> 
> PS: Why XP?

Thanks for the info. I may be shelling out for a synthesis front end in
the next few months. I will take a hard look at how well they infer RAM. 

I was asking about XP because all the new machines come with XP now. I
assume M$ has made it difficult for a computer vendor to sell a machine
with one of the older versions of Windows. I know that the laptops I
have looked at have no other option. Plus I have found that it really
does pay to keep up with this OS stuff. I have an old machine running 95
and I get tired of it crashing 2 or 3 times a day in normal use. My 98
machines seem much more stable. 

Speaking of laptops, does anyone know if laptops will be available with
more than 512 MB max memory and/or DDR SDRAM? Of the machines I have
looked at, that is the only significant difference with the desktops. I
would much prefer to get a top end laptop if I can be sure I won't
outgrow the memory capabilities in a year or so. This FPGA software
requires more and more memory every year!


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search