Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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: 37002There'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 AntonioArticle: 37003
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.deArticle: 37004
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
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
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
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 EckertArticle: 37008
Sounds like dog food. AustinArticle: 37009
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 EckertArticle: 37010
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: 37011The 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. > > adrianArticle: 37012
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. > > adrianArticle: 37013
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: 37014Maybe 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 6K3Article: 37015
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 RobberyArticle: 37017
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. MarkArticle: 37018
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. MarkArticle: 37019
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
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 6K3Article: 37021
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. -jgArticle: 37022
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 FAXArticle: 37023
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 FAXArticle: 37024
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:
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