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
See my comments below: Karl Olsen wrote: > According to ds001_1.pdf, some Spartan2 -5 speed grades are available in the > industrial temperature range -- this should mean that the worst-case timings > are guaranteed at die temperatures -40 to 100°C instead of 0 to 85°C. Yes > What > does the "Temperature Prorating" then mean in the WebPack Timing Analyzer? > > The Timing Analyzer allows Temperature Prorating down to -40°C. Can > commercial grade parts safely be used down at these temperatures, and can I > expect other effects than faster timings and larger power-up currents? You named the two "problem areas". Also, since we did not production-test these parts at the low temperature, we do not guarantee the parameters. Peter Alfke, Xilinx Applications > > > Thanks a lot, > Karl OlsenArticle: 28026
Greg Neff wrote: > In article <3A3EBCB4.93ADDE5B@xilinx.com>, > peter.alfke@xilinx.com wrote: > > > No, I don't see how such a primitive structure can sustain an > oscillation. > > Once it leaves its metastable balanced state, there is no way to > return > > back to or through it. ( As is possible in multi-stage structures > popular > > with TTL technology) > > > > I'm thinking that the phase delay of noise amplified through the > inverters may permit a very brief low amplitude oscillation around Vth > before the latch stabilizes. Depending on the structure of the flip- > flop, this oscillation could be amplified by the next stage. This is > hypothetically speaking of course, I'm not saying that Xilinx FPGAs do > this. The low-amplitude frequency of this oscillation ( if it existed, which I don't believe) would be multiple GHz, and would not pass through the slave latch circuitry. > > > > For data, it is irrelevant whether it oscillates or not. > > Irrelevant only if the data has one destination, hence the need for two- > stage synchronizers. I meant to say that oscillation is no worse than an unpredictably long delay ( which is bad enough). So let's just document the long delay. Interesting thread ! Peter AlfkeArticle: 28027
Greg Neff wrote: > In article <3A3F3339.AC12CB9E@sqf.hp.com>, > nials@sqf.hp.com wrote: > > I'm looking at a problem where we need to drive a > > couple of 5V CMOS clock inputs from a SpartanII > > 3v output. > > > (snip) > > I like to have a reel of these on hand: > > http://www.fairchildsemi.com/pf/NC/NC7ST86.html > > They can be used as inverters or buffers, depending on how you strap > the other input. > > Other manufacturers (such as Toshiba) make similar parts. > > -- > Greg Neff > VP Engineering > *Microsym* Computers Inc. > greg@guesswhichwordgoeshere.com > Greg, This is a super suggestion, but I would use the dual Schmitt trigger: http://www.fairchildsemi.com/pf/NC/NC7WZ14.html Total input protection against power down as well as ESD, absolutely tiny package, lightning fast, 1.8-5.5Vcc, 1V hysteresis- would still use a nominal RC on input though. The threshold spec extremes stink- so he would need a pull-up.Article: 28028
Jason Daughenbaugh wrote: > > "There are data lines being driven from the 3V output, > we can get away with the 'tristate and pull high > for logic high' trick, but I don't want to do this with > the clock signals. The active (rising) edges are > _very_ slow and the risk of double clocking etc > would be too high." > > Something worth considering would be a modified version > of this method. I have had great success driving a clock > line by configuring the logic so that it drives the output > pad high until it is a high level and then tristate and let > the pullup work the rest. This allows the output to be > driven all of the way up to 3V, creating some much faster > slew rates. > > Xilinx clains that this can decrease the rise time from > 0.4 to 3.0V from 20ns to 3ns. I have seen this to be true > on a spartan-2 The threshold Vin low for the chip I'm clocking is 3.5V. I've implemented the technique above (and increased the 'DRIVE' property on the CLk output pins). It's working on the bench, but I'm not happy with the slope of the signals as they pass through the high input voltage threshold, it needs to be more robust. I really want to drive the input with something that'll take the input cleanly through 3.5V. Nial.Article: 28029
"Pascal C." wrote: > > I don't think any terminations were put on those pins. They probably need them. How far from the FPGA pin is the load? > The measure was taken with an active probe, at 5 GS/s sampling. Yes, but how was the 'scope ground connected to the circuit? -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 28030
Robert wrote: > > Greg, > > This is a super suggestion, but I would use the dual Schmitt trigger: > http://www.fairchildsemi.com/pf/NC/NC7WZ14.html > > Total input protection against power down as well as ESD, absolutely > tiny package, lightning fast, 1.8-5.5Vcc, 1V hysteresis- would still use > a nominal RC on input though. The threshold spec extremes stink- so he > would need a pull-up. Thanks for the suggestions guys, I'll get the guy who's designing the board to have a look at this. Nial.Article: 28031
In article <3A3F99A7.2A9E3931@earthlink.net>, Robert <romapa@earthlink.net> wrote: (snip) > > This is a super suggestion, but I would use the dual Schmitt trigger: > http://www.fairchildsemi.com/pf/NC/NC7WZ14.html > > Total input protection against power down as well as ESD, absolutely > tiny package, lightning fast, 1.8-5.5Vcc, 1V hysteresis- would still use > a nominal RC on input though. The threshold spec extremes stink- so he > would need a pull-up. > > Just one caveat: With Xilinx FPGAs you need to be careful about using output pullup resistors to drive CMOS inputs. Many of the I/O configurations are not 5V tolerant. The non-5V tolerant output configurations will actively clamp the output to VCCO plus a diode. The OP is probably using LVTTL mode, and if this is the case then your suggestion is okay. We have to be careful not to generalize when dealing with Xilinx FPGAs. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/Article: 28032
Simon Gornall wrote: > > I may end up buying a BED board as well (just to get the gates :-) but > I'll need to figure out how easy/stable it is when you get rid of the > 24MHz clock. Presumably there's a good reason why they've crippled it > like this - maybe it just doesn't run any faster. I guess I'll find > out when I buy one. This could be for VGA output. One clock does all. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchukArticle: 28033
Greg Neff wrote: > In article <3A3F99A7.2A9E3931@earthlink.net>, > Robert <romapa@earthlink.net> wrote: > (snip) > > > > This is a super suggestion, but I would use the dual Schmitt trigger: > > http://www.fairchildsemi.com/pf/NC/NC7WZ14.html > > > > Total input protection against power down as well as ESD, absolutely > > tiny package, lightning fast, 1.8-5.5Vcc, 1V hysteresis- would still > use > > a nominal RC on input though. The threshold spec extremes stink- so he > > would need a pull-up. > > > > > > Just one caveat: With Xilinx FPGAs you need to be careful about using > output pullup resistors to drive CMOS inputs. Many of the I/O > configurations are not 5V tolerant. The non-5V tolerant output > configurations will actively clamp the output to VCCO plus a diode. The > OP is probably using LVTTL mode, and if this is the case then your > suggestion is okay. We have to be careful not to generalize when > dealing with Xilinx FPGAs. This is good to know, and a good point. I was talking about pull-ups on the input though.Article: 28034
I see what you are saying now. His source is 3V logic from a Spartan II. Keen observation. Greg Neff wrote: > In article <3A3F99A7.2A9E3931@earthlink.net>, > Robert <romapa@earthlink.net> wrote: > (snip) > > > > This is a super suggestion, but I would use the dual Schmitt trigger: > > http://www.fairchildsemi.com/pf/NC/NC7WZ14.html > > > > Total input protection against power down as well as ESD, absolutely > > tiny package, lightning fast, 1.8-5.5Vcc, 1V hysteresis- would still > use > > a nominal RC on input though. The threshold spec extremes stink- so he > > would need a pull-up. > > > > > > Just one caveat: With Xilinx FPGAs you need to be careful about using > output pullup resistors to drive CMOS inputs. Many of the I/O > configurations are not 5V tolerant. The non-5V tolerant output > configurations will actively clamp the output to VCCO plus a diode. The > OP is probably using LVTTL mode, and if this is the case then your > suggestion is okay. We have to be careful not to generalize when > dealing with Xilinx FPGAs. > > -- > Greg Neff > VP Engineering > *Microsym* Computers Inc. > greg@guesswhichwordgoeshere.com > > Sent via Deja.com > http://www.deja.com/Article: 28035
This is a multi-part message in MIME format. --------------3CF0956B9CC42BAF0319C8E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Pascal C." wrote: > I have 2 questions about Xilinx pins used in high-frequency designs.<br> > <br> > First:<br> > There are DFFs on the OE in VirtexE IOBs. These, however, are not used by the PAR, even if they are needed. When my colleague called Xilinx support, they said the only way was to use them was to use FPGA Editor and place them manually. On a 32-bit bus, however, this is hardly practical (esp. since you have to do it on each implementation).<br> If you use Map -pr b then the mapper will place the registers for the Output Enable in the IOB, this is only the case however if there is one source register per pin (eg 32 bit bus with single OE register will not be placed in the IO). This will give you faster switch-over and make doing ZBT interfaces much easier... > > <br> > Second:<br> > In another high-frequency design, I found it was necessary to put a FAST 12 mA DRIVE on an output pin. However, in the lab, I saw it created a 1V overshoot on the LVTTL pin, which would damage external components. I would like to reduce the drive, but PAR does not allow me to go below 12 mA: when I do attempt it, it tells me it cannot respect constraints. However, it says this assuming a 35 pF load, when in fact I a have a much lighter 5 pF load. Considering this load, I know I can go well below 12 mA, however PAR stops and refuses to go on despite violations. Is there any work-around? If you are using LVTTL IO standards, then you can vary the DRIVE from 2mA to 24mA on a pin by pin basis. Control of this is done in the UCF file..When using large numbers of high drive IO, then be aware of the SSO guidlines in the app notes.. Dave --------------3CF0956B9CC42BAF0319C8E0 Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:Hawke;David Hawke tel;cell:(+44) 778 875 5002 tel;work:(+44) 870 7350 517 x-mozilla-html:TRUE org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx"> version:2.1 email;internet:dhawke@xilinx.com title:XILINX Field Applications Engineer adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;; x-mozilla-cpt:;2672 fn:David Hawke end:vcard --------------3CF0956B9CC42BAF0319C8E0--Article: 28036
Mark Russell wrote: > To improve the hold time further I would like to turn on the IOB delay. > How do you turn it ON? > My understanding is it defaults to on for registered inputs and may be > turned off using NODELAY. > What about non-registered inputs where the default seems to be off? Years ago, I recommended to use the input latch with the clock permanently tied to "transparent". That makes it look to the software as if there were an input latch, but in reality the input is not latched. Kind of hokey... Peter AlfkeArticle: 28037
In article <3A3FA882.51138D7E@earthlink.net>, Robert <romapa@earthlink.net> wrote: > > > Greg Neff wrote: > > > In article <3A3F99A7.2A9E3931@earthlink.net>, > > Robert <romapa@earthlink.net> wrote: > > (snip) > > > > > > This is a super suggestion, but I would use the dual Schmitt trigger: > > > http://www.fairchildsemi.com/pf/NC/NC7WZ14.html > > > > > > Total input protection against power down as well as ESD, absolutely > > > tiny package, lightning fast, 1.8-5.5Vcc, 1V hysteresis- would still > > use > > > a nominal RC on input though. The threshold spec extremes stink- so he > > > would need a pull-up. > > > > > > > > > > Just one caveat: With Xilinx FPGAs you need to be careful about using > > output pullup resistors to drive CMOS inputs. Many of the I/O > > configurations are not 5V tolerant. The non-5V tolerant output > > configurations will actively clamp the output to VCCO plus a diode. The > > OP is probably using LVTTL mode, and if this is the case then your > > suggestion is okay. We have to be careful not to generalize when > > dealing with Xilinx FPGAs. > > This is good to know, and a good point. I was talking about pull-ups on the > input though. > > The NC7WZ14 input would be driven by the FPGA output, so the pullup would source current to both the NC7WZ14 input, and the FPGA output driver and protection circuit. This is why I made the comment. My "output pullup resistor" statement was probably a bad choice of words. Sorry for the confusion. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/Article: 28038
Robert wrote > > This is good to know, and a good point. I was talking about pull-ups on the > input though. Every input is also a 3-stated output. There are hardly any dedicated inputs ! Peter AlfkeArticle: 28039
Greg Neff wrote: > > a nominal RC on input though. The threshold spec extremes stink- so he > > would need a pull-up. > > > > > > Just one caveat: With Xilinx FPGAs you need to be careful about using > output pullup resistors to drive CMOS inputs. Many of the I/O > configurations are not 5V tolerant. The non-5V tolerant output > configurations will actively clamp the output to VCCO plus a diode. The > OP is probably using LVTTL mode, and if this is the case then your > suggestion is okay. We have to be careful not to generalize when > dealing with Xilinx FPGAs. > Greg, it's a Spartan II so using a pull up on the op is OK, it's not actively clamped. Nial.Article: 28040
Hi, Do the JTAG interfaces on Xilinx Spartan II and XC9500XL devices behave the same as the user IO lines on those devices. ie. Are the JTAG inputs 5V tolerant, and what voltages are the TDO pins driven with? Dean ArmstrongArticle: 28041
In article <3A3FB450.668A606A@sqf.hp.com>, nials@sqf.hp.com wrote: > Greg Neff wrote: > > > > a nominal RC on input though. The threshold spec extremes stink- so he > > > would need a pull-up. > > > > > > > > > > Just one caveat: With Xilinx FPGAs you need to be careful about using > > output pullup resistors to drive CMOS inputs. Many of the I/O > > configurations are not 5V tolerant. The non-5V tolerant output > > configurations will actively clamp the output to VCCO plus a diode. The > > OP is probably using LVTTL mode, and if this is the case then your > > suggestion is okay. We have to be careful not to generalize when > > dealing with Xilinx FPGAs. > > > > Greg, it's a Spartan II so using a pull up on the op is > OK, it's not actively clamped. > > Nial. > Take a look at page 4 of the Spartan II data sheet (V1.1). It says that for non-5V compliant outputs, a clamp diode may be connected to VCCO. So to be safe, make sure that you are using a 5V compliant output mode such as LVTTL. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/Article: 28042
> To improve the hold time further I would like to turn on the IOB delay.
> How do you turn it ON?
> My understanding is it defaults to on for registered inputs and may be
> turned off using NODELAY.
> What about non-registered inputs where the default seems to be off?
[I couldn't figure that one out myself either. So I asked support.]
The magic you need to put in your ucf file is: IOBDELAY={NONE|BOTH|IBUF|IFD}
More info at:
http://toolbox.xilinx.com/docsan/3_1i/data/common/lib/chap12/lib12006.htm#BAJDGDBI
I tried to put it in the source code with a "synthesis" directive but
ndgbuild didn't like that.
--
These are my opinions, not necessarily my employers. I hate spam.
Article: 28043bfredc@my-deja.com wrote: > Hi all, > > I'm starting a new design using VIRTEX XCV600. I want to know if the > methodology is the same than with a device like XCV 50 ? > > BFC > > Sent via Deja.com > http://www.deja.com/ One thing you might want to be careful of is the pinout if you're going for the FG676 package. What ``methodology'' do you use now ? Here are my, necessarily personal, recommendations: (1) If you're not using HDL now then I, personally, would suggest you do so although there are those on this NG who swear by schems even for large designs. (2) Get hold of some version control s/w e.g. RCS/CVS, SourceSafe, ... (3) Do builds from the command line. Learning how to use ``make'' will vastly repay the effort. (4) Get into some serious simulation if you're not there already. (5) If you go the HDL route get a language sensitive Editor. Emacs + VHDL/Verilog-mode is free & powerful. (6) Get hold of a big computer with lots of memory. I'd say a minimum PIII-600 + 512Mbytes. Routing a 75% used XCV600E will burn ~220M. Remember that if you are using Win-NT then the moment it starts swapping the performance drops by a factor of 5+. (7) Finally, and more contentiously, if you are going the HDL route and have the money then drop FPGA Express & invest in Synplify. Be careful here since (3) implies you have to get a floating license which costs 50% more than the list price but is worth it.Article: 28044
bobdittmar@my-deja.com wrote: > I only posted response to original post because I am doing design with > common clock where 1 side constantly reads only and the other side > constantly writes. > I had several designeers tell me that the Xilinx DPRAM could handle this > without arbitration. I decided to verify it myself and found that not to > be true (or so I believe) so I added arbitartion. Yet my initial arch > did not have it. I would of found the problem in the lab at the > expense of other developers time. > > So I was passing this along Let me explain: The best text is on page 3-48 of the 2000 Xilinx data book. All Virtex generations and Spartan-II devices show the same behavior. Simultaneous writes to the same location: The last clock wins, but in order to guarantee that, it must be Tbccs (~3 ns ) later than the earlier clock. Otherwise there is even a small chance of corrupted data ending up in the memory location. Both writes clobbering each other. Similarily for read during write: For a reliable read, its clock must be ~3ns either before or after the write clock. Otherwise it might possibly even read a mixture of old and new data. For the application Bob Dittmar mentioned ( common clock ) I would recommend offsetting the two clocks, e.g. running one on the rising and the other on the falling edge of the same clock. That will be safe, no arbitration is needed. Sorry if anyone found this confusing. It's really obvious when you think about it... Peter Alfke, Xilinx ApplicationsArticle: 28045
Peter Alfke wrote: > > I am sure that the reborn Fairchild ( I am an old Fairchilder of 30 > years ago!) has circuits with an input threshold of 2.4 V and > available in really tiny packages. > > Peter Alfke > Fairchild has at least AHCT available in single gate (didn't they buy TIs logic?) (as does Philips) e.g. 74AHCT1G14GW - single gate inverter with hysteresis. these are more expensive than the larger chips but work well Garry Allen It is also worth downloading the TI logic family application notes. Level conversion is one thing they spend a lot of time discussing.Article: 28046
Jamie Sanderson wrote: > > > wire: Only has a value when driven, defaults to 'z' when not driven > > reg: retains the last value assigned to it. > > integer > > While I distinctly didn't want to start a big argument, I guess it's > inevitable. The "reg" declaration in Verilog has always been a thorn in my > side. To the novice, it implies that it will be a register, typically with a > clock input. Actually, all it means is that the assignment must occur within > an "always" block. Therefore, some regs are "registers", while others are > combinational. However, the combinational variety can typically be done as a > wire outside of an "always" block. Confusing... In VHDL, a signal becomes a > register by virtue of being assigned on a rising or falling clock edge. > I thought this at first but after a while I realised that the two uses of `reg' aren't really that far apart. In Verilog a reg can only be assigned inside an always block [for synthesis at least, ignoring ``initial'']. This block has a sensitivity list so that it gets executed only when one of the signals changes i.e. when there's an edge on one of the signals in the list. So you can, if you like, look on a `reg' as a `register' with a, possibly very complex & async, clock. > > I'm also philosophically opposed to the "always @ (posedge clock or negedge > reset)" terminology. You typically want level sensitivity, not edge > sensitivity on your reset. In fact, that's what you get once this code is > synthesized. VHDL is much more clear in this aspect. The process is > sensitive to the clock and reset, but the "if" statement indicates that only > the clock has an edge sensitivity. > You're right that the difference is philosophical since the Verilog approach is to keep all the stuff inside the always block free of timing information & to put all the control of the block's execution in the sensitivity list - which should really be called an event list. From the simulation point of view the construct you mention is nicely minimal since you don't really care about the rising edge of an active low async reset. You also get the sync/async change just by removing the second condition as opposed to having to move the position of the ``if'' statement inside the block. Note that you can put further @(xxx) statements inside an always block but I don't think many synth tools can handle this. > > > Because Verilog's types are restricted these sort of issues can mostly be > taken > > care of by some careful self-discipline or formal coding styles. If > necessary > > you could invest in one of the `lint' style tools [Anyone know if there's > a > > shareware or GPL'ed one ?]. > > Or you could use VHDL and get much of the checking for free with the > compiler. Again philosophical: I prefer to be allowed to do as I please, esp with FPGAs, & if necessary use a separate tool to measure how much risk I'm taking. > > > The **big** thing that bites people with Verilog esp those brought up on > VHDL is > > the blocking/non-blocking assignment thing on which whole tomes have been > > written. Without care & attention to this its perfectly possible to write > > Verilog that simulates fine at RTL, synthesises o.k., but whose synth > results > > don't actually match the RTL. Ultimately its not that hard to grasp but it > does > > expose the actions of the simulator, basically the way different classes > of > > event are scheduled becomes visible at the HDL level. > > I always thought the problem was that simulation didn't match the designer's > intentions, as opposed to the synthesized results. At least, this has been > my experience with the blocking/non-blocking mix-ups. I think one of the biggest problems with the blocking/non-blocking thing is that designers can realise their intentions in ways that *will* simulate correctly at the RTL level but will fail after synthesis. Its sort of a more subtle way of getting it wrong than using #delay's to get your RTL to work right.Article: 28047
hoyte@ucsu.colorado.edu wrote: > > I recently worked on a senior project where we designed a 16-bit RISC > microprocessor, and implemented the design in an FPGA. I'd like to be > able to do something similar on my own, and I'm trying to find a good > FPGA/board combination that is (relatively) affordable, and compatible > with the Xilinx student edition software. If anyone has any suggestions, > they would be greatly appreciated. > Hi Eric, i think it's probably a good thing to point out that the previous 2 posts are from people who want to sell you stuff. I've just bought the XS40 and I'm happy with it. The XS40 is pretty good for prototyping stuff with. It has a 100MHz clock, but only ~5000 gates (advertised at ~9000 by Xilinx, but that's misleading IMHO). The BED board is pretty cool in that it has loadsagates (200,000), which is a *lot* to play with. For some weird reason they've only put a ~24MHz clock on it though. Ruins it for me. YMMV. I may end up buying a BED board as well (just to get the gates :-) but I'll need to figure out how easy/stable it is when you get rid of the 24MHz clock. Presumably there's a good reason why they've crippled it like this - maybe it just doesn't run any faster. I guess I'll find out when I buy one. All IMHO, of course. Simon -- Physicists get hadrons!Article: 28048
Nial,
Something else you *might* consider (I don't know
how fast your clock is, or how fast a rising edge
you need) is using the FPGA to pull up to a 3.3v
level, and then tristating, letting the resistor
pull it up the ret of the way.
I think this solution comes from Peter Afke, but
I'm not sure.
The VHDL process to drive your pins would be as
follows, assuming that PIN is of type inout, and
that OUTPUT is the output level that you want.
process (PIN, OUTPUT) is
begin
if OUTPUT = '0' then
PIN <= '0';
elsif PIN = '0' then -- This is when OUTPUT is '1,
-- but PIN isn't there yet, so
PIN <= '1'; -- you keep driving with the
-- FPGA.
else -- This is when PIN is above the
-- the FPGA's Vih threshold, and
PIN <= 'Z'; -- you let the resistor do the rest
-- of the work.
end if;
end process;
Disclaimer: I have not done this myself, and I
don't know if it's a particularly good idea to do it
with a clock signal.
HTH,
Kent.
Nial Stewart <nials@sqf.hp.com> writes:
> I'm looking at a problem where we need to drive a
> couple of 5V CMOS clock inputs from a SpartanII
> 3v output.
>
> There are data lines being driven from the 3V output,
> we can get away with the 'tristate and pull high
> for logic high' trick, but I don't want to do this with
> the clock signals. The active (rising) edges are
> _very_ slow and the risk of double clocking etc
> would be too high.
>
>
> Space is fairly tight so my immediate thought was
> to use an 8 pin soic dual comparator with the -ve
> input tied to 1.8V (power plane).
>
> My only concern with this is that I think I read a
> while ago that comparators shouldn't be used for this
> sort of application, I can't remember where I read this
> so I can't check if I'm right. It might have been
> because of the lask of hysteresis on the input,
> but if the -ve input is set to a 'clean' part
> of the waveform I don't think we should see
> any problems.
>
> Can anyone think of any drawbacks of using a fast
> comparator for this conversion?
>
> Nial.
Article: 28049On Mon, 18 Dec 2000 10:18:09 -0800, Peter Alfke <peter.alfke@xilinx.com> wrote: >We will soon ( a matter of weeks ) publish metastable delay curves for >VirtexII in a style similar to good old XAPP094, i.e. MTBF as a function of >acceptable extra delay, for a given clock and data frequency. [snip] Why is the "standard" estimation of MTBF a function of only td, f1 and f2? (td = acceptable extra delay, f1 = clock and f2 = data frequency). The rise time of the clocks and data signals must matter... or? At least for external interfaces. / Jonas
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