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
Arash Salarian wrote: > > Hi, > > I'm starting a new design in which I'm using a multi-channel A/D with a low > sampling-rate and Flash memory for the storage and the system is going to be > powered by battery. In this stage, I'm not yet sure if using a FPGA would be > wise, as I'm very concerned with the power consumption. The gate count of > the circuit will be 3k~4k in my opinion so basically any medium Spartan > family or even maybe XPLA would do. I've seen a device from ATmel (T87C5111) > that consumes only 5mA and I guess is a good candidate too. This makes me > hesitate to choose any FPGA over these types of micro-controller in designs > were every bit of current matters.. > > Does anyone has experience in using FPGAs in low power applications and is > there any suggestion in selection FPGAs over micros in these types of > designs? > > Regards > Arash I am not familiar with the T87C5111, but it appears to be an MCU. This is not a bad way to go if you don't mind debugging software. Assuming that your application is very simple, you could go either way, HW or SW. But I expect your power consumption would be better with an MCU. The Xilinx XCR3128XL is a 3.3 volt device with a static Icc of nearly 0. The power consumption is a function of frequency at about 0.5 mA/MHz according to the data sheet. If 128 is not enough macro cells, then the XCR3256XL has 256 macro cells at about a 1 mA/MHz power curve. You might be able to do a little better with a low power micro, expecially if you can use the on chip ADC. The MSP430 from TI has several members which have a power consumption of well less than 1 mA/MHz including the ADC or get to the single digit uA at low KHz! The high end chips are about $8 vs. ~$9/$15 for the XCR3128XL/XCR3256XL. The MSP430F133 price gets below $5 including the 8 input ADC. But the MSP430 family is not 5 volt tolerant. So watch out for that. -- 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: 38926
Markus, The largest part is the 2V8000. No real market for the 10K gate part right now....we'll wait and see how the upturn goes. Lots of demand for the 2V6000 (shipments, too!). Austin Markus Wannemacher wrote: > Hi all, > > the biggest part of Xilinx' Virtex-II family should be > the XC2V10000 with 10 Mio. System gates. > But I can't find anymore any information > on this part on Xilinx' web. > > Only the press release: > http://www.xilinx.com/prs_rls/silicon_vir/0207_EProd_PoY.html > from Jan 23th 2002 still talks about 10 Mio. gates devices. > > Can anyone comment on this? > > Regards, > MarkusArticle: 38927
"Martin Fischer" <Martin.Fischer@fzi.de> schrieb im Newsbeitrag news:a33a0k$ve@absalom.fzi.de... > Yes, I mean glitches. > Do you mean also the clock for the processes ? > > For example I have a signal Zustandsfehler with glitches and an process > Ladenabbrechen > can I than ignore the glitches in my output signal Laden_abbrechen ? > > Ladenabbrechen : process (Abbruch, Zustandsfehler) > Begin > if Abbruch='1' or Zustandsfehler='1' > then > Laden_abbrechen<='1'; > else Laden_abbrechen<='0'; > end if; > end process Ladenabbrechen; This is NOT a clocked process, its pure combinatorical. A "real" clocked process is something like process(clk) begin if clk='1' and clk'event then . . . . . . .. end if; end process; If the rest of your design is a clean synchrounous design, the glitches on the data signals dont matter. -- MfG FalkArticle: 38928
"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag news:3C55764C.40E1023@earthlink.net... > Russell, the question wa: How man diffrent functions can a LUT > implement. > And the answer is 64K. > It only taks a few minutes to describe few hundred completely > different ones, not counting input permutations. I remember that there was a small file discussing the number of diffent functions possible with a 4 input LUT, 2^16-permutations of inputs But I cant find it anymore www.fpga-faq.com ?? NO. AFAIR the number was somewhere around 1800. -- MfG FalkArticle: 38929
Iwo Mergler napisal(a): >> Sometimes these problems are helped by using an add-on >> printer port card rather than the port on the motherboard. >> >> "Marcin E. Hamerla" <mehamerla@.........pl> wrote >> >> > According to Altera datasheet I made my own ByteBlaster programmer >> > board for programming FLEXes and MAXes. Up to now everything worked >> > with minor problems. There was only a limitation of the programmer >> > cable lenght. Two weeks ago I have purchused a new fast computer >> > (Athlon 1600+). Then I have realized that I can not program any >> > chips. Cutting the cable down to 20cm helped but it is rather >> > difficult to work with such a short cable. Changing BIOS parallel port >> > properties did not help - I tried this. And there is a question: are >> > there any problems with the original ByteBlaster (LPT) board used with >> > these new fast computers or I should rather go for USB programmer >> > cable? Does it work with +5V chips? Is it expensive? > >Your new chipset probably uses 3.3V or less on the parport pins. That >is borderline for driving 5V logic and with a long cable you push it >over the edge. > >The suggestion to use a add-on port is a good one. Another thing you >can try is to pull the lines up to 5V (with resistors). This should >give a high-level of about 4V and may allow a longer cable. Thanks a lot. I found different solution. It appears that exchanging resistor values from 33ohm to 100ohm solves the problem. -- Pozdrowienia, Marcin E. Hamerla "Nienawidze turystow."Article: 38930
Decoding glitches ( do you call them "Spitzen"?) are either innocent or a disaster. Innocent on the combinatorial signals in a fully synchronous ( clocked ) design, as long as the glitches do not overlap the active clock edge ( which is never the case in a single-clock synchronous design). Disaster when they occur on a clock line, or on the asynchronous clear or preset input to flip-flops and latches. So it all depends. You really cannot avoid glitches in complex decoding or data routing structures. But you have to make sure they do not appear on any D-input during the active clock edge. Peter Alfke, Xilinx Applications ======================================= Martin Fischer wrote: > > What do you mean with peaks?? small pulses (glitches) on data signals. > This > > is just normal an ca be ignored in 99% of all cases. But your clock > signals > > must be absolutely glitch free. > > Yes, I mean glitches. > Do you mean also the clock for the processes ? > > For example I have a signal Zustandsfehler with glitches and an process > Ladenabbrechen > can I than ignore the glitches in my output signal Laden_abbrechen ? > > Ladenabbrechen : process (Abbruch, Zustandsfehler) > Begin > if Abbruch='1' or Zustandsfehler='1' > then > Laden_abbrechen<='1'; > else Laden_abbrechen<='0'; > end if; > end process Ladenabbrechen; > > Thanks > > MartinArticle: 38931
On 27 Jan 2002 18:41:17 -0800, newman5382@aol.com (newman) wrote: >Kevin Goodsell <goodsell@bridgernet.com> wrote in message news:<k4t55u4lf2n5bnppbagfog8e8jbqcipesj@4ax.com>... >> Thanks for the additional comments. I've discovered a few things since >> my last post: >> >> The lines I was using as inputs to the FPGA are at least part of the >> problem - they seem to be too weak. I added non-inverting buffers and >> it *almost* works. Strangely, the FPGA seems to be registering >> positive clock edges where it shouldn't. Sometimes this is on a >> negative edge, sometimes not. It seems like the clock is too noisy, >> but it looks pretty clean on the oscilloscope. I tried creating a >> Schmitt trigger using the trick with two resistors and an extra I/O > >If you have a slow clock and look at it on the oscilloscope, it may >look perfect cause you have the timescale zoomed out. Measure the >rise time and the fall time of your clock. I suspect it is too slow, >and the cmos inputs are interpreting this as multiple clocks per >transition. > >Newman Possible. The rise time, IIRC, was around 220 ns. I would guess that this is fast enough, but I don't know. -KevinArticle: 38932
--------------65D5B70C5DA9AFF8A56C2AC4 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Kevin Goodsell wrote: > > Possible. The rise time, IIRC, was around 220 ns. I would guess that > this is fast enough, but I don't know. > > -Kevin Not fast enough for a clock nowadays. Can you spare an output and create some input hysteresis? Better still, terminate the clock line so that it has nochance to ring... You might also click on the following for some internal remedy. http://www.xilinx.com/xcell/xl34/xl34_54.pdf Peter Alfke, Xilinx ApplicationsArticle: 38933
There is a new book out by Uwe Meyer-Baese titled "Digital Signal Processing with
FIeld Programmable Gate Arrays" (
http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/102-6110898-2675311)
that is well written and covers many of the aspects of DSP with FPGAs. It is
featured on the bookstore page on my website (links to Amazon: if you use the
link above or go through my website I get a kickback which helps to support the
website). I very highly recommend this book.
For FPGAs we only use floating point where it really is necessary. Most
applications don't need floating point at all (but you do have to work a little
harder to track your scaling). Those that do usually need a much smaller range
of exponents than what is provided in typical DSP micros. Floating point
multiplies aren't much more complicated than a fixed point multiply: just an
adder for the exponents, a 2:1 mux to renormalize the output and an increment to
readjust the exponent if the product needed adjustment. Floating point adds are
where the cost comes in. In that case, you need a compare to determine which
exponent is bigger, and exchange network (pair of 2:1 muxes) to steer the smaller
addend through a shifter, a barrel shifter to right shift the smaller addend by
the difference in the exponents, a fixed point adder to sum the equally weighted
mantissas, then a normalizing barrel shift to renormalize the sum, and an adder
to adjust the exponent to reflect the renormalization. A floating point adder
uses about the same resources as a multiplier with the same width in an FPGA.
Needless to say, we try to avoid the floating point adds. One trick I often use
is to process a string of operations on a fixed point mantissa and then
renormalize at the end of the series. You can do floating point arithmetic in
any FPGA that you can do fixed point arithmetic in, it just uses more resources.
FIR filters, in nearly all cases are better done using fixed point arithmetic in
FPGAs. IIR filters can be done fixed point if you are careful to carry enough
precision, round carefully to eliminate any DC biases, and choose your
coefficients carefully. These can also be done with distributed arithmetic, as
long as the output is available back at the input within a sample time, which
means you can't use deep pipelining. The performance is limited by not being
able to deeply pipeline, but you can easily do a biquad that works at sample
rates under 10 MHz using serial distributed arithmetic in current FPGAs.
Generally, IIR filters are not a real good fit to FPGAs, even when done fully
parallel because the first order feedback has to get back to the input within a
sample interval. That limits the performance no matter what the implementation
is.
Tom wrote:
> Hi,
>
> I am sorry to disappoint you but there really are no books that I am aware of
> which focus on DSP in FPGAs. The reason, in my opinion, is as follows..
>
> DSP is a tough enough topic to engage in when we are in the floating point
> world and FPGAs do not have floating point multipliers. (Please, everybody,
> don't email me that there is a floating point core available somewhere ;-)
> ). Even the Virtex 2 devices with multipliers can only implement "Fixed
> Point" aritithmetic. Since, for digital filters, one of the inputs to the
> multiplier is always known (the coefficients) a particularly efficient
> (area-wise) method of doing fixed point math is called "Bit Serial
> Arithmetic". There are some good articles on Bit Serial stuff. One was
> written by Peter Alfke, who now writes Xilinx application notes. It has a
> title something like "The role of distributed arithmetic in FPGA design".
> There are also articles by the late Les Mintzer, which are quite good (I
> would have to dig out in the garage for the title and I am sure that a quick
> internet search would find it quicker). Mintzer also wrote the last chapter
> in the "DSP Applications Handbook" (I hope that the title is close to being
> right), which is a really good book to have except for the fact that it
> usually goes for more that $100 (I am way too cheap, times being what they
> are). Ray Andraka has a web site dedicated to FPGA stuff which has examples
> of arithmetic forms other than Bit Serial.
>
> One other thing that I should mention is that doing IIR filters or any
> filters of a recursive nature, in Distributed Arithmetic, while very
> possible, is really difficult. The fiixed point scaling issue and especially
> the feedback to the first order recursive output (say, Y(n-1) ) can be
> tricky.
>
> I hope that this helps.
>
> Tom Cipollone
>
> Przemyslaw Wegrzyn wrote:
>
> > Hello !
> >
> > I'm looking for some books about implementing DSP algorithms in FPGA. Can
> > someone advise any title ?
> >
> > -=Czaj-nick=-
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38934David, Perhaps this has been answered however I have been told to use the -ext (-extassertmsg) switch when invoking ncsim to get the full path to the affected instance. I have not tried it myself but hopefully this will give you th info you need. -- Brian David Rogoff wrote: > Hi. > > I am doing a gate-level/back-annotated simulation of am FGPA. It's a > Xilinx Virtex E, using the simprims library (ISE 4.1). I'm using > Cadence ncvhdl/ncsim. I've got a few timing violation messages, but > they don't have the path to the offending component and/or the signal > names involved. Here's one example: > > ASSERT/WARNING (time 8970249 PS) from procedure > @ieee.VITAL_Timing:ReportViolation > */X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK; Expected := > 0.271 NS; Observed := 0.11 NS; At : 8970.249 NS > > I'm used to Verilog, and having the full path shown in the timing > violation. Is this a problem with the Xilinx library? Is there some > switch setting I can change? > > Thanks, > > DavidArticle: 38935
That's really really slow. It should be at least 20 times faster (a couple of ns at most). With that kind of
switching speed, it lingers in the threshold region for quite a while. Any noise on the signal or even on the
power supplies wil cause multiple transitions to be detected. That includes the small shifts due to that input
switching. Are you sure you did the hysteresis circuit correctly?
Kevin Goodsell wrote:
> On 27 Jan 2002 18:41:17 -0800, newman5382@aol.com (newman) wrote:
>
> >Kevin Goodsell <goodsell@bridgernet.com> wrote in message news:<k4t55u4lf2n5bnppbagfog8e8jbqcipesj@4ax.com>...
> >> Thanks for the additional comments. I've discovered a few things since
> >> my last post:
> >>
> >> The lines I was using as inputs to the FPGA are at least part of the
> >> problem - they seem to be too weak. I added non-inverting buffers and
> >> it *almost* works. Strangely, the FPGA seems to be registering
> >> positive clock edges where it shouldn't. Sometimes this is on a
> >> negative edge, sometimes not. It seems like the clock is too noisy,
> >> but it looks pretty clean on the oscilloscope. I tried creating a
> >> Schmitt trigger using the trick with two resistors and an extra I/O
> >
> >If you have a slow clock and look at it on the oscilloscope, it may
> >look perfect cause you have the timescale zoomed out. Measure the
> >rise time and the fall time of your clock. I suspect it is too slow,
> >and the cmos inputs are interpreting this as multiple clocks per
> >transition.
> >
> >Newman
>
> Possible. The rise time, IIRC, was around 220 ns. I would guess that
> this is fast enough, but I don't know.
>
> -Kevin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38936Hi - On Mon, 28 Jan 2002 19:04:23 GMT, Kevin Goodsell <goodsell@bridgernet.com> wrote: >On 27 Jan 2002 18:41:17 -0800, newman5382@aol.com (newman) wrote: > >>Kevin Goodsell <goodsell@bridgernet.com> wrote in message news:<k4t55u4lf2n5bnppbagfog8e8jbqcipesj@4ax.com>... >>> Thanks for the additional comments. I've discovered a few things since >>> my last post: >>> >>> The lines I was using as inputs to the FPGA are at least part of the >>> problem - they seem to be too weak. I added non-inverting buffers and >>> it *almost* works. Strangely, the FPGA seems to be registering >>> positive clock edges where it shouldn't. Sometimes this is on a >>> negative edge, sometimes not. It seems like the clock is too noisy, >>> but it looks pretty clean on the oscilloscope. I tried creating a >>> Schmitt trigger using the trick with two resistors and an extra I/O >> >>If you have a slow clock and look at it on the oscilloscope, it may >>look perfect cause you have the timescale zoomed out. Measure the >>rise time and the fall time of your clock. I suspect it is too slow, >>and the cmos inputs are interpreting this as multiple clocks per >>transition. >> >>Newman > >Possible. The rise time, IIRC, was around 220 ns. I would guess that >this is fast enough, but I don't know. That's nowhere near fast enough. Your clock signal is spending so much time making it through the transition region that small amounts of noise can make the FPGA see multiple clock pulses. Try for a risetime under 5ns. Just out of curiousity: what are you driving the clock with (i.e., chip type, net topology) that gives you a risetime of 220ns? Bob Perlman -- Cambrian Design Works digital design, signal integrity http://www.cambriandesign.com e-mail: respond to bob at the domain above.Article: 38937
And it is popular - Amazon.com Sales Rank: 539,591 :) "Ray Andraka" <ray@........com> wrote > There is a new book out by Uwe Meyer-Baese titled "Digital Signal Processing with > FIeld Programmable Gate Arrays" ( > http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/102-6110898-2675311) > that is well written and covers many of the aspects of DSP with FPGAs.Article: 38938
Hi!
I'm looking at this data sheet and wondering... It seems to be
copy-paste-search-and-replace of Spartan 2 data sheet. However, this
doesn't seem to be consistent.
BlockRAM JTAG ID Bitstream DLL
XC2S200 56K ??????? 1335840 4
XC2S200E 56K ??????? 1442016 4
XCV200E 112K v0A1C093h 1442016 8
When I connect Impact to XC2S200E the chip is identified as XCV200E
(ID 10A1C093), so I assume JTAG ID is same as for Virtex-E device.
Bitstream is said to be same size. But almost everything else in the
data sheet is copy-paste from Spartan-2 data sheet and doesn't match
Virtex-E.
Which data sheet is correct for the Spartan-2E? For now I would assume
that I have to use Virtex-E data sheet for internal structure and hope
that nothing was changed in PQ208 package from XC2S200 to XC2S200E
device.
Article: 38939I think I must have misinterpreted your original mail as I thought you wanted to do reconfigurations with just the XC4000 and nothing more (ie no PAL, ROM, SRAM etc.) Hope things work out for you Fong. (I would have replied sooner, but I was stuck on a mountain with no cell towers.) Alex :)Article: 38940
On Mon, 28 Jan 2002 19:48:34 GMT, Bob Perlman <no-spam@sonic.net> wrote: > >Just out of curiousity: what are you driving the clock with (i.e., >chip type, net topology) that gives you a risetime of 220ns? > >Bob Perlman Well, I may not be remembering the time correctly. I can't test it again at the moment because I'm snowed in at home today. Anyway, the clock is being driven from the I/O lines of a microprocessor called an AIC (Advanced Instrument Controller). I don't think it is very widely used, but it is basically a modified Intel 8051 built to tolerate more extreme conditions (originally designed for use is space, I think). Also, I think it is designed to be extremely low power, which might be part of the problem (?). The I/O lines are different from a standard 8051. The directions are controlled by a set of internal registers. That's about all I know about it. (I'm a software guy, which probably goes a long way to explain all the problems I'm having. ;) ) Actually, coming directly off the AIC, the rise time was much slower - around 20 times slower, I think. We are going through a buffer to strengthen the signal, and the rise time of the signal from that buffer is the one I'm claiming was about 220 ns. -KevinArticle: 38941
On Mon, 28 Jan 2002 04:18:57 GMT, Bob Perlman <no-spam@sonic.net> wrote: >Hi - > >What's the bandwidth of your 'scope? You're going to need something >on the order of at least 700MHz bandwidth for the probe and scope >combined (and I'm talking bandwidth, not sampling rate) to see a >1ns-wide glitch on a clock edge. > >Those 100MHz-bandwidth scopes can make a glitchy signal look mighty >fine. Sometimes it's a good idea to keep one in the lab just to boost >morale. > >Bob Perlman LOL :) I think that's exactly what I've been using. I can't say that I've seen the morale-boosting effects yet, though. -KevinArticle: 38942
heyho wrote:
>
> Hi,
>
>
> BTW, Kevin, why should he use Spartan II´s? ACEX devices are great! This should be a newsgroup which discusses technical questions and not stupid stuff what device is a few cents cheaper than another one. This kind of information hich cannot be proven anyway!!
The reasons why I think the original poster should try out
Spartan-IIs are because,
1) Roughly speaking, Spartan-II speed grade -5 and ACEX 1K speed grade
-1 should provide similar performance in random logic (state machine),
but Spartan-II has a faster speed grade -6 part, and that part should be
faster than ACEX 1K speed grade -1.
2) Regardless of what you say about saving money, for similar
performance, I will rather pay less for something similar. Again,
comparing Arrow's pricing for buying one ACEX 1K and Insight
Electronics' pricing for buying one Spartan-II, Spartan-II is much
cheaper ($30 to $40 for Spartan-II -5 or -6 vs. over $90 for ACEX 1K-1)
The prices here are what I saw on their websites a few months ago.
3) Altera doesn't offer a starter version of ModelSim like Xilinx does
(ModelSim XE-Starter). Sure, Xilinx says that ModelSim XE-Starter has a
500-line code limitation, but the simulation only gets pretty slow after
that, and the simulation will be done at some point. The simulator
Altera offers with MAX+PLUS II-BASELINE and Quartus II 1.1 Web Edition
is not an HDL-based simulator, and only a waveform can be entered.
Frankly, I find writing test code for HDL-based simulation much faster
than entering test waveforms into a waveform editor.
4) Very few vendors that I know offers ACEX 1K-based development board
versus several (Insight Electronics, Avnet, etc.) for Spartan-II.
One thing to note is that here I am comparing Xilinx's free
tools versus Altera's free tools because I think the original poster who
is thinking of using ACEX 1K should at least try it out and see how
Spartan-II fares.
Yes, if the original poster already owns the paid version of MAX+PLUS
II, Quartus II, or ModelSim-AE, doesn't want to learn another vendor's
tools, or the original poster's design already heavily uses vendor
specific features like LPM or EAB, those are legitimate reasons to keep
using Altera tools/devices, but that will still make the original
poster's product less competitive in the market, or will make less
profit.
I will rather use Spartan-II over ACEX 1K, and make more profit per
board or sell more boards for less, unless ACEX 1K is so much better
than Spartan-II in something.
Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)
Article: 38943On Mon, 28 Jan 2002 05:18:01 GMT, Ray Andraka <ray@andraka.com> wrote: >What is your board like? The FPGA is on a Spartan 2 Demo Board from Insight Electronics. The clock and data lines are coming from a completely separate board (described a little in my other post). > Is the FPGA properly decoupled, and does it have >good low impedance paths from the power plane? Er... <Kevin scratches his head> >HOw about your signal >integrity, especially on the clock. Are the edges really clean (keep in >mind the chip is fast enough to react to a sub-nanosecond pulse on the >clock)? As far as I can tell they are clean, but from what I'm hearing that doesn't mean much. >Are the clock levels correct? Pretty sure. >Do you see any evidence of ground >bounce on the output signals? No, but again that probably doesn't mean much. >Are your edge rates fast enough (if being >driven by some of the older CMOS families, they may not be)? Probably not. -KevinArticle: 38944
Aare, Spartan IIE has its own test program, so its data sheet applies, no others. As for the silicon JTAG IDCODE, that will change as masks and revisions change, so never use that to "guess" which device you have, you have what the device is marked as. Austin Aare Tali wrote: > Hi! > > I'm looking at this data sheet and wondering... It seems to be > copy-paste-search-and-replace of Spartan 2 data sheet. However, this > doesn't seem to be consistent. > > BlockRAM JTAG ID Bitstream DLL > XC2S200 56K ??????? 1335840 4 > XC2S200E 56K ??????? 1442016 4 > XCV200E 112K v0A1C093h 1442016 8 > > When I connect Impact to XC2S200E the chip is identified as XCV200E > (ID 10A1C093), so I assume JTAG ID is same as for Virtex-E device. > Bitstream is said to be same size. But almost everything else in the > data sheet is copy-paste from Spartan-2 data sheet and doesn't match > Virtex-E. > > Which data sheet is correct for the Spartan-2E? For now I would assume > that I have to use Virtex-E data sheet for internal structure and hope > that nothing was changed in PQ208 package from XC2S200 to XC2S200E > device.Article: 38945
I am looking for some code to define a glitch less clock enable/disable circuit. The clock frequency is 100MHz. What I am trying to say is that I have a counter with a 100MHz clock and I want to avoid runt pulses on the clock. This could either be a clock mux switching between 0 and clock on the output or a "safe" clock enable that would eliminate (or at least minimize) the possibility of metastability. The counter could be asynchronous if that simplifies things. Any ideas, suggestions, sources, etc. Thanks, TheronArticle: 38946
"Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag news:3C559919.A017798E@xilinx.com... > Disaster when they occur on a clock line, or on the asynchronous clear or preset > input to flip-flops and latches. Also disasterous when glitches happen on the D input of a " should be" latch. What does this mean? We once did a VHDL design in a XC95xx and wanted some latches. The compiler said, blabla . .latches inferred. Hmm, but this was a D-FlipFlop whit the cler/set inputs wired weird to "emulate" a latch. :-(( > So it all depends. You really cannot avoid glitches in complex decoding or data > routing structures. But you have to make sure they do not appear on any D-input Hmm, Iam curious how much these glitching contributes to power consumption?. Just recently we had a presentation from our FAE about the new Coolrunner-II, where everything was tried to save the last uA (disabeling inputs to prevent internel nets from toggeling etc.) -- MfG FalkArticle: 38947
I remember that too, and I'm pretty sure it was Phil Freidin that posted
the number. I couldn't find it in the FAQ or the archive either.
Falk Brunner wrote:
> "Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
> news:3C55764C.40E1023@earthlink.net...
>
> > Russell, the question wa: How man diffrent functions can a LUT
> > implement.
> > And the answer is 64K.
> > It only taks a few minutes to describe few hundred completely
> > different ones, not counting input permutations.
>
> I remember that there was a small file discussing the number of diffent
> functions possible with a 4 input LUT, 2^16-permutations of inputs
> But I cant find it anymore
> www.fpga-faq.com ?? NO.
>
> AFAIR the number was somewhere around 1800.
>
> --
> MfG
> Falk
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 38948Sorry to return to this topic yet again... XAPP450/451 show the SpartanII power-up current requirement as 500mA for _all_ parts, provided the temperature requirements are met. However, I have a distant recollection that someone (Austin?) has at one time posted that the smaller parts need less than this? Any ideas on the slope of the curve from the 2S15 to the 2S200? I am particularly interested in the 2S30.Article: 38949
Hi, Does anyone know how to perform (Static) Timing Analysis within QuartusII without only comparing against explicitly defined timing constraints, but just an interactive post-processing kind of job? It is my impression that other FPGA vendors (like Xilinx or Actel) have better solutions in this area, since they also offer seperate timing analysis tools (TRACE and DT ANALYSE, respectively). In addition, they also support min/max values, whereas Altera seems to be thinking that only max values are sufficient (for setup-time), not keeping in mind that min timing values can give you indications of potential hold-time problems. Does anyone have similar experiences, opinions, etc.??? Best regards, Jaap Mol
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