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
> This seems to be the season of metastability. > Ok, so in the absolute worst case scenario the two conflicting simultaneous writes > leave the cell in the metastable condition. Everybody agrees that it cannot stay > there very long. I claim that 5 ns is extremely unlikely, 10 ns only once in our > lifetime. So, unless you read that same location that you just wrote conflicting > information into ( so you really shouldn't care whether it's a 1 or a 0) within a > few ns again, everything will be calm and peaceful. It's real easy to combine a dual-port RAM with some other logic such that routing and/or logic delays eat up all of the cycle time. That means that effectively you ARE looking at the RAM within a few ns of the clock. How hard would it be for tools to notice the different-clock case and compute the settling time available? Similarly, I'd like a tool that would raise a red flag if a signal from a different clock goes to more than one FF. The dual port ram case is more complicated. That's the same clock, but we only case if the addresses are the same. > Phil and I have been friends ( and colleagues at AMD ) for the past 20 years. We > just have this running battle over the practical ( not the philosophical !) > aspects of metastability. Let me establish the probabilities by testing Virtex-II > in January. All data in this area is very welcome. Thanks for all your previous contributions. I hope you have time to measure what happens at non-typical Vcc and temp too. But speaking of the practical side... I work on several types of gear. One type is a one-shot hack in the lab. I tinker until it works. Metastability is lost in the noise of all the other confusion. Another type is low volume with friendly users. I want it to be reasonably reliable but I probably know all the people who will ever use it so I will get feedback if it isn't solid enough. I'd accept glitches like metastability might cause if they happen (say) less frequently than once per year per box. (I'd be embarrassed with that level of flakiness, but might live with it in order to work on something with higher payoff.) Another type of gear is higher volume. I'm not talking about TV or cell-phone scale, but something like web servers. One failure that causes a system crash (or worse, corrupt data) per my lifetime per installed system is too high - way too high. Say my lifetime is 100 years. That gives 10 crashes per year per 1000 systems in use. Decent software is better than that. Most of the time, it's easy to be conservative when crossing clocking boundaries. It just adds another cycle of latency - and that cycle turns the failure rate into once per lifetime of the universe or some other silly number so I can forget about it. But every now and then, the delay is critical and I have to make a tradeoff between time and reliability. Can I get away with a half cycle rather than a whole cycle? Can I move some logic into that slot? Is sure would be nice to do that with engineering rather than handwaving. I'd also like to be able to double check the simple case and make sure that the failure rate is astronomical rather than just waving my hands and claiming it's good enough. I find it somewhat amazing that this area hasn't received more attention. Do schools cover metastability? I wonder how many projects have failed because they were just a bit too flakey due to a metastability bug. Just in case anybody thinks I'm picking on the digital world, try reading the spec sheet for a linear regulator and then try to prove to yourself that your design is stable. It's as bad as GSR timings. :) -- These are my opinions, not necessarily my employers. I hate spam.Article: 28101
Neil, You are right-on! We didn't need to put a higher frequency osc module on the kit because of the Spartan II on-chip DLLs - they are used to multiply up the clock on chip if necessary. No problem with the power supply, or supply decoupling. Indeed, one of the reasons the 24MHz was chosen was because of rationalising the inventory (a 24MHz osc module is also included with the BED-FPGA-CPU-IO kit). The BED-FPGA-CPU-IO module can also plug onto the other BED FPGA proto kits, which don't always have a 24MHz oscillator on them. So in alot of cases it is not redundant. Please note that BurchED is a small enough company that we will consider all requests such as "can you ship the kit with a different frequency oscillator module?". We are always happy to receive requests - just email me. Best regards and seasons greetings Tony www.BurchED.com.au "Neil Franklin" <neil@franklin.ch.remove> wrote in message news:6uelz2rfvb.fsf@chonsp.franklin.ch... > sulimma@my-deja.com writes: > > > In article <3A3FA329.C726271@jetnet.ab.ca>, > > Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote: > > > Simon Gornall wrote: > > > > 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 > > Cheaper clock chip? This is after all only the default "good for most > users" chip, which can be replaced by "we want max power" users. > > Also don't forget that the XC2S chips like the XCV have 4 on-chip DLLs > which can do f*2 and of which pairs can be cascaded (App note says > so). So you can go up to 96MHz with that default Osc. > > > > > This could be for VGA output. One clock does all. > > As would a 48 MHz or 96 Mhz or 144 MHz Clock. So they really might > > have a problem with the power supply or similar. > > The post from Burch also mentioned expansion boards. One of these has > an VGA connector and 3*4bit DACs on it. That board also has an second > 24MHz Osc (and an 3.xxxMHz for the RS 232 on it). So the 24MHz on the > main board is not for VGA. > > Hmmm. Having 24MHz for the VGA board would make reducing inventory > positions an further reason for an 24MHz default. Given that Burch > seems to be aiming for absolute minimal cost that could be it. > > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, MysticArticle: 28102
Good site Harvey. A couple of comments though... 1) If people are after this sort of info. I'd recommed the NG sci.electronics.design, which is probably more suitable than an fpga site. 2) Never use sharp tweezers? I've been working for years in the industry and it was because of SMT that people went to sharp tweezers. You don't stab the devices with the sharp points but you need the narrow tips improved precision to grab those little parts. Are the tweezers you're talking about smooth on the gripping surface or ribbed? 3) The use of 2% silver solder is not that common for reel type solder and I certainly I have seen lots of SMT done without it. What is the reason for it? 4) I think tin-plating is generally good and I'd recommend it. I guess it depends on what kind of junk you let get in the solution and whether you have control of the source. You could have a virgin bottle and a used bottle so that you don't degrade the whole lot at once. Typically I find that the solution becomes very ineffective but doesn't contaminate. I've gone from old, used solution that took 20 minutes to plate to new, fresh solution that plated instantaneously when dropped in the solution. 5) With tin plating you can typically place the part flat and then solder. However, if you don't do plating you can follow the technique you described. However, I don't quite agree with your interpretation of the commercial pcb vendors overcoming the problem. They do solve the problem but typically the boards they build are not hand soldered and thus not subject to the sinking problem of one pin being soldered before the other. In commercial operation you typically use solder paste and go through an IR-relflow oven. If not, you glue the part down and go through a molten wave-solder machine. The HASL finish (hot air solder leveling) is to make sure that the large fine pitch multi-pin devices sit flat before they are soldered. As I've moved into very big and even finer pitch BGA devices HASL is sometimes found to be not flat enough and hence the move to gold electro-plate finishes (but HASL keeps improving). 5) You say that capacitors have no identification marks at all. Well that isn't always true and there many smt caps I've used with codes. However, they are not as easy to read as the resistors or the old through-hole caps. They use a cryptic alpha numeric code. The first letter is the vendor (k= kemet) and then a alpha-numeric pair that requires a decoding table to figure out the value. If I find a table on the kemet site (or other) I'll post a link. Steve harveytwyman@my-deja.com wrote in message <91q1s5$mag$1@nnrp1.deja.com>... >Being involved with student projects, the ability to handle the latest >SMT devices has been essential. > >I've developed techniques over the last few years that are successful >for beginners as they only require simple hand tools. > >My Web Page below describes these techniques in detail: > >http://www.Makaton-Signs.org.uk/PCB-Techniques > > ___________________________________________ >===| |=== >===| H A R V E Y T W Y M A N |=== >===| ----------------------------------------- |=== >===| Department of Electronics, |=== >===| University of Kent. |=== >===| Canterbury. U.K. |=== >===| ----------------------------------------- |=== >===| ABOUT ME: http://www.Twyman.org.uk/CV.htm |=== >===| ----------------------------------------- |=== >===| EMAIL ME: H.E.Twyman@ukc.ac.uk |=== >===|___________________________________________|=== > > > >Sent via Deja.com >http://www.deja.com/Article: 28103
Ray Andraka wrote: > > WOrks as long as 1) you can tolerate the ringing that inevitably occurs when the > driver shuts off, Ray, I clearly saw this effect on a 'scope when experimenting with different configurations for driving the op. As you might expect it gets worse as the DRIVE attribute is increased. It's actually very hard to properly terminate the track whilst pulling the line high as hard as possible. Nial.Article: 28104
If you use VIRTEX than it is recommended not to use GSR. This way the software will do a static timing for you. RESET is usually very loaded. Not all FF devices need to have their RESET de-asserted at the same clock. You may consider doing it sequentially: For instance control first and data-path next. Given that RESET is asserted for quite a long time – a few cycles – than you need to worry only for the RESET de-assertion synchronization. Suppose a case where FF A drives FF B. In that case the cycle time must be greater than: 1. RESET de-assert to q time + 2. Routing delay time + 3. Logic delay time + 4. FF B setup time. In article <3a37e67f@news.datacomm.ch>, "Martin Heimlicher" <heimlicher@scs.ch> wrote: > Dear all, > > This is a very basic and general FPGA question: > > How do I assure that an externally supplied reset signal connected to some > sort of GSR (global set/reset) net releases all registers simultaneously (in > the same clock cycle) and reliably (no metastability) ? > > Do I need to synchronize the external reset signal through one or two > registers before feeding it to the GSR net ? > > If yes, what do I do in the case of multiple clocks in a design ? Can I use > the GSR net only to reset registers clocked by one clock and using other > routing ressources to reset registers clocked by the other clocks ? > > If I am worrying to much about this issue: How do FPGAs circumvent these > problems ? > > Regards, > Martin Heimlicher, Supercomputing Systems AG, Switzerland > > Sent via Deja.com http://www.deja.com/Article: 28105
eml@riverside-machines.com.NOSPAM wrote: > I hadn't noticed the 1ns receiver-receiver jitter - you obviously > won't get anywhere near this with a digital PLL. You also mentioned a > DLL, but this isn't any use for data recovery of a PCM waveform, since > it's irregular. You could use a DLL if you were willing to have a > separate clock line, but I agree that 1 ns is going to be a real > problem unless you put in an adjustable delay line. > > Evan Quicklogic makes a 2.5 Gb/s fiber encoder/decoder's so something in that line may be useful for ideas of what is available. http://www.quicklogic.com/devices/QuickFC -- "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: 28106
I want to do a straightforward simulation of a design one on of these
boxes using an internally generated clock and reset. Memories are
being preloaded so the cpu will run (hopefully).
It seems however that to get a simple reset you need to use one of the
user bits, physically loop that back to the design's reset input, then
give vrun come options to make it generate the clock even though it
might not have (I/O having been enabled).
Surely somebody has solved this rather fundamental problem ?
Jon
Article: 28107
"Javier SERRANO" <Javier.Serrano@cern.ch> wrote in message
news:3A3E05DF.8D1904FE@cern.ch...
> Hi,
>
> I am looking for an encoder/decoder pair to transmit serial data through
> long distances. There will be one emitter and many receivers, and the
> system cannot accept more than one nanosecond of jitter among receivers,
> that is there can be absolute delay differences from one receiver's
> decoder output to another's, but those differences have to be stable to
> within one ns. On the other hand, I would not like to buy a commercial
> pair of encoder/decoder but rather design my own with an FPGA (I might
> have to give support for many years). I assume that to get that kind of
> accuracy, I will have to use either an on-chip or an on-board PLL/DLL.
> Does someone know where I can get schematics or text-based designs for
> simple encoders like Manchester or biphase mark? Any good books or URLs
> on the subject?
>
> Thank you very much.
>
> Javier
This is a very tight spec indeed. The the tolerance of the refractive index
of the transport media itself (fibre optic or whatever) can introduce
changes of speed of propagation that over large distances that will possibly
swamp this tolerance. A high speed serial receiver can lock to an incoming
data stream with quite high accuracy, but you seem to be talking about
controlling changes in absolute propagation time across large distances.
Mark.
P.S. Cypress do some simple high speed (400Mbit/sec) serial transmitter and
receivers ('Hotlink'). They may not be of use to you, but there are app
notes full of interesting stuff regarding jitter.
http://www.cypress.com/hotlink/hotlinkappnotes.html
Article: 28108The pins on which I am trying to reduce the drive are LVTTL. I've constrained them to a Clock to out of 6 ns, to allow some setup time (the clock is 131M, so clock period is about 7.8ns). Under 12 mA, it tells me it can't possibly meet a clock to out of 6 ns. And fails. I finally got an answer from Xilinx TechSup. They told me I had two choices: a) ease off the constraints so that PAR will complete, or b) change all pins manually. For the TRIs, the OEs on the IOBs are active-high, and so were my OE signals. I guess I'll investigate this the next time it comes up + try to use different tools.Article: 28109
> > I am looking for an encoder/decoder pair to transmit serial data through
> > long distances. There will be one emitter and many receivers, and the
> > system cannot accept more than one nanosecond of jitter among receivers,
> > that is there can be absolute delay differences from one receiver's
> > decoder output to another's, but those differences have to be stable to
> > within one ns. On the other hand, I would not like to buy a commercial
> > pair of encoder/decoder but rather design my own with an FPGA (I might
> > have to give support for many years). I assume that to get that kind of
> > accuracy, I will have to use either an on-chip or an on-board PLL/DLL.
> > Does someone know where I can get schematics or text-based designs for
> > simple encoders like Manchester or biphase mark? Any good books or URLs
> > on the subject?
> >
> > Thank you very much.
> >
> > Javier
>
> This is a very tight spec indeed. The the tolerance of the refractive
index
> of the transport media itself (fibre optic or whatever) can introduce
> changes of speed of propagation that over large distances that will
possibly
> swamp this tolerance. A high speed serial receiver can lock to an incoming
> data stream with quite high accuracy, but you seem to be talking about
> controlling changes in absolute propagation time across large distances.
>
> Mark.
>
> P.S. Cypress do some simple high speed (400Mbit/sec) serial transmitter
and
> receivers ('Hotlink'). They may not be of use to you, but there are app
> notes full of interesting stuff regarding jitter.
> http://www.cypress.com/hotlink/hotlinkappnotes.html
Mark and Javier,
It sounds to me that your very tight jitter spec has nothing to do with
the tolerance of the refractive index of the transport media. I am assuming
that that transport media is steady in its prop delay of the signals. I am
also assuming that the system is designed with this in mind. If this is the
case, then it sounds to me that the clock is the only thing that will affect
the jitter spec.
For example, assume that there is a 7.345 ns difference in delay
between two receiver inputs. Javier says that this is okay. What he
doesn't want is a jitter in this delay greater than 1 ns. In order to meet
this spec, the sending clock must have a jitter spec that is better than
this. If Javier uses a PLL or DLL, then this device will add jitter to the
basic clock. I would use a very stable clock circuit that meets the jitter
spec.
Now if these cables are swinging in the wind, then I can see where that
kind of phenomena can affect the prop delay and introduce jitter. But
Javier has this under control, since he is only asking about circuits. If
transmission lines are held perfectly still and still introduce variations
in prop delay, then this is new to me and I am wrong here.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Article: 28110On Wed, 20 Dec 2000 10:53:14 -0800, Peter Alfke <peter.alfke@xilinx.com> wrote: >Hal Murray wrote: > >> >> Could you get an extra half bit of resolution by clocking things >> on the other edge of the clock too? >> >> I think that requires that both the clock-enable (pulse being measured) >> and the clock be be routed to 2 CLBs with matching routing delays. >> > >Come to think of it: >Why limit yourself to just two edegs? You can create a bunch of increasingly >longer clock delays with perhaps 100 ps granularity, and use all of them. > >Peter Alfke This reminded me of a Vernier caliper. I did a quick search and came up with: http://www.lecroy.com/lrs/pubs/p48/P48.htm Which is a LeCroy paper on how they built a chip to do this. The idea is obvious (that didn't stop them applying for a patent, though): you use a delay line as the high-precision scale, with 10 delay steps taking up 9 clock periods, and you measure progress through the delay line together with the clock count. So, if you've got a clock count of 4, say, and 3 delay elements have switched, then your delay is 4.3 clocks. You can calibrate the delay line using random measurements, which takes 'a few minutes' in their case. Their target was 50ps resolution. EvanArticle: 28111
On 21 Dec 2000 02:40:38 GMT, murray@pa.dec.com (Hal Murray) wrote: > >> They always get set/reset by GSR - the SR input is just an optional >> additional term. > >Thanks. Is that in the documentation someplace? I don't remember >seeing it and it's the sort of detail I think I would remember. I just had a look at the online docs, and it's pretty much all covered in the first few pages of: Synthesis and Simulation Design Guide Chapter 4: Designing FPGAs with HDL Using Dedicated Global Set/Reset Resource >> BTW, the last time I checked both the Virtex and the 4K data sheets >> there were no relevant skew timings on GSR. None of the important >> numbers are documented. > >Why are you interested in skew? Suppose the skew is 1 ns but the >prop time is somewhere between 0 and 20. How do I use GSR if my clock >time is 10 ns? I just meant delay specs in general - 'skew' was a bad choice of word. >My copy of the VirtexE data sheet has some GSR data: GSR to Pad, >is on the bottom of the IOB Output Switching, Table 21. There is >a similar number a few pages earlier for GSR to IQ on the input >side. > >Yes, similar data for CLBs and RAMs would be helpful. Not to mention a setup/hold parameter to the clock. I don't think it matters, though - you can still use GSR effectively with some extra messing around. EvanArticle: 28112
On Wed, 20 Dec 2000 22:27:31 GMT, eml@riverside-machines.com.NOSPAM wrote: > Xilinx have an app note on Manchester >coding, but I don't think it covers the digital PLL, which is the only >part of the design which requires any thought. I hadn't noticed the 1ns receiver-receiver jitter - you obviously won't get anywhere near this with a digital PLL. You also mentioned a DLL, but this isn't any use for data recovery of a PCM waveform, since it's irregular. You could use a DLL if you were willing to have a separate clock line, but I agree that 1 ns is going to be a real problem unless you put in an adjustable delay line. EvanArticle: 28113
Dear all, I'm sorry for issuing a kind of advertisement to this groupe, but let us intruduce our new product. We has just released testbench generation tool named "TBassistant" for $55.00. Please visit our site at http://www.din.or.jp/~yagiyagi/HTML/index_english.htm and click products button on the page. Sicerely, hiro FLEMO Inc.Article: 28114
Hal, I think we would agree that the goal should be an MTBF of >10,000 years, so that 1000 systems running concurrently produce only one "crash" per 10 years. And "crash" may not involve loss of life, in which case we should add more zeros. I am itching to start the test with Virtex-II. Peter Alfke =============================== Hal Murray wrote: > <snip> > Another type of gear is higher volume. I'm not talking about > TV or cell-phone scale, but something like web servers. One > failure that causes a system crash (or worse, corrupt data) per > my lifetime per installed system is too high - way too high. > > Say my lifetime is 100 years. That gives 10 crashes per year per 1000 > systems in use. Decent software is better than that. > > Most of the time, it's easy to be conservative when crossing clocking > boundaries. It just adds another cycle of latency - and that cycle > turns the failure rate into once per lifetime of the universe or > some other silly number so I can forget about it. > > But every now and then, the delay is critical and I have to make a > tradeoff between time and reliability. Can I get away with a half > cycle rather than a whole cycle? Can I move some logic into that > slot? Is sure would be nice to do that with engineering rather > than handwaving. > > I'd also like to be able to double check the simple case and make > sure that the failure rate is astronomical rather than just waving > my hands and claiming it's good enough. > > I find it somewhat amazing that this area hasn't received more > attention. Do schools cover metastability? > > I wonder how many projects have failed because they were just a > bit too flakey due to a metastability bug. > > Just in case anybody thinks I'm picking on the digital world, try > reading the spec sheet for a linear regulator and then try to prove > to yourself that your design is stable. It's as bad as GSR timings. :) > > -- > These are my opinions, not necessarily my employers. I hate spam.Article: 28115
Peter Alfke wrote: > > markp wrote: > > > In my experience series terminating clocks is superior to other forms of > > clock termination, but I'll leave that can of worms to another thread! > > > > Series termination is great for signals that go from one source to one > destination. > Since the drive impdance is adjusted to match the transmission line Z0, a > half-amplitude signal travels down the line, is reflected at the unterminated > far end to become a full signal "instantaneously", then travels back to the > source, where it is swallowed up in the output impedance = Z0. > > Neat trick. It USES the reflection instead of FIGHTING it. > > But beware: Never ever (NEVER EVER!) use series termination for a signal that > has to travel to multiple destinations. All but the farthest of these > destinations will see the half-amplitude signal for some time, which is the > worst level possible. Poor noise immunity, double-triggering etc. Ugly stuff. Actually -- you can get away with series termination for something driving multiple loads IFF you pay strict attention to the layout (keep all arms the same length, etc etc etc). Simulation of the PCB with something like Hyperlynx is required. I know it works because I just did an XC4013XLA SRDAM controller design. The FPGA talked to four SDRAM devices. The series terminations (the CTS four-banger SMT jobs) were installed as close as we could get them to the FPGA. Two of the SDRAMs were on the top of the board; the other two were on the bottom. We also made sure line lengths were equal, and the SDRAM and FPGA clocks were all driven by a zero-delay PLL clock buffer chip. Works fine (the board runs at 80 MHz) and looking at the signals on a fast 'scope (with proper probing, etc etc) shows real clean signals for everything. > The best way to terminate a clock that drives multiple loads is to have a > strong ( low-impedance ) driver, then terminate the farthest end of the clock > "snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in > SERIES, and this combination used as a parallel termination) > Make the RC larger than the transition time, but smaller than the clock High or > Low time. > 50 Ohm and 100 pF is a proven combination for all but the very fastest clocks. But only use AC termination for 50% duty-cycle signals like clocks. -- 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: 28116
Check www.ezchip.com and www.broadcom.com and www.bluetooth.com Saqib wrote: > It is said that the three areas of DSP, Communications and Networking > are very hot in FPGAs designs. DSP is ok...but what specifically is > meant by "communications"..does it include products like Encryptors, > Forward error correction products (Viterbi , RS codecs),Modems...or it > means telecommunications..if yes what are specific cores that are > suitable for FPGA implementation... > And what does NETWORKING mean..what are specific networking products > implemented in FPGAs? > Thanx > > -- > --saqib yaqub-- > > Sent via Deja.com > http://www.deja.com/Article: 28117
Hal Murray wrote: > > It's real easy to combine a dual-port RAM with some other logic such that > routing and/or logic delays eat up all of the cycle time. That means that > effectively you ARE looking at the RAM within a few ns of the clock. But don't forget: The potential problem occurs only when you read very soon (!) from the SAME location that you just wrote conflicting information to. You can read any other location any time without any problem. Metastability seems to be a neat excuse for indulging in way-out fantasies. :-) But, as we agreed, we are looking for an MTBF of >10,000 years, so we should let our fantasy run wild... Peter Alfke > >Article: 28118
> > Mark and Javier, > It sounds to me that your very tight jitter spec has nothing to do with > the tolerance of the refractive index of the transport media. I am assuming > that that transport media is steady in its prop delay of the signals. I am > also assuming that the system is designed with this in mind. If this is the > case, then it sounds to me that the clock is the only thing that will affect > the jitter spec. <snip> > Now if these cables are swinging in the wind, then I can see where that > kind of phenomena can affect the prop delay and introduce jitter. But > Javier has this under control, since he is only asking about circuits. If > transmission lines are held perfectly still and still introduce variations > in prop delay, then this is new to me and I am wrong here. > Simon Ramirez, Consultant > Synchronous Design, Inc. I have to admit I'm a little out of my depth here. I had assumed that the receivers themselves were a 'long distance' apart. Let's say 100m for arguments sake - this translates to around 500ns or so in delay. I assumed also that there are very slight changes in the refractive index in the cables due to expansion and other physical phemomenon. These changes are very small and won't cause much dispersion to the light passing through it, but their effect is cumulative on the absolute delay through the whole fibre. If you had two of these fibres next to each other and subjected them to different temperatures, would the light propagate down them to within 1ns at the receiving end? I don't really know, but my gut feeling is there would be a difference, and that this might be greater than 1ns. I've tried to find refractive index tolerances for fibres but so far failed. Any ideas? Mark.Article: 28119
> I have to admit I'm a little out of my depth here. I had assumed that the
> receivers themselves were a 'long distance' apart. Let's say 100m for
> arguments sake - this translates to around 500ns or so in delay. I assumed
> also that there are very slight changes in the refractive index in the
> cables due to expansion and other physical phemomenon. These changes are
> very small and won't cause much dispersion to the light passing through
it,
> but their effect is cumulative on the absolute delay through the whole
> fibre. If you had two of these fibres next to each other and subjected
them
> to different temperatures, would the light propagate down them to within
1ns
> at the receiving end? I don't really know, but my gut feeling is there
would
> be a difference, and that this might be greater than 1ns. I've tried to
find
> refractive index tolerances for fibres but so far failed. Any ideas?
>
> Mark.
Mark and Javier,
If you laid down to fibers next to each other and subjected them to
different temperatures, then the prop delay of one fiber would change
differently than the prop delay of the other fiber, as you said above. But
Javier isn't worried abot this. According to his email, he is designing the
circuitry, not the transmission media. For a tight spec like what he
quoted, the transmission media guys would have to control temperature
differences, movement, etc., in order to keep the overall jitter spec within
tolerance.
Javier's job is to design the circuitry, i.e., implement an
encoder/decoder pair such that there is less than 1 ns of jitter at the
decoder output. This jitter is a sum of the "jitter" in the transmission
media as well as the jitter of the encoder/decoders, so he must take the
transmission jitter into account if significant. Javier needs to ask the
transmission media guys what that jitter is, so that he can subtract it from
his total 1 ns jitter. The remainder is what he has to design to.
Also, since the temperatures and movements of the transmission media
are likely to cause slow changes in the difference between the prop delay,
then it may not even be a problem, i.e., it may not be considered "jitter."
For example, if the top cable is exposed to the sun more than the bottom
cable, then it would swing slowly every 24 hours. Is this considred
"jitter." Only Javier knows.
I think Javier needs to nail down this transmission media contribution,
but he really needs to look at the encoder clock as well as the decoder
clock, however he plans to derive it. A serial decoder can extract the
clock (self clocking), but there is jitter there. He can transmit the clock
from the encoders, but skew problems can arise.
Javier, can you tell us more about your transmission media and/or your
clocking scheme?
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 28120In article <91th4k$hd1$1@lure.pipex.net>, "markp" <map@nospam_dial.pipex.com> wrote: (snip) > > I have to admit I'm a little out of my depth here. I had assumed that the > receivers themselves were a 'long distance' apart. Let's say 100m for > arguments sake - this translates to around 500ns or so in delay. I assumed > also that there are very slight changes in the refractive index in the > cables due to expansion and other physical phemomenon. These changes are > very small and won't cause much dispersion to the light passing through it, > but their effect is cumulative on the absolute delay through the whole > fibre. If you had two of these fibres next to each other and subjected them > to different temperatures, would the light propagate down them to within 1ns > at the receiving end? I don't really know, but my gut feeling is there would > be a difference, and that this might be greater than 1ns. I've tried to find > refractive index tolerances for fibres but so far failed. Any ideas? > > Mark. > > Try posting in sci.optics.fiber -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/Article: 28121
Hello, I used the algorithm in the xapp058 from Xilinx to load a serial eeprom XC18V02 with a xsvf file and it is not working. The support at Jtag said this algorithm is not working with proms, that this algo is for fpgas or cpld and they were few changes to do to this algorithm to make it works with proms. Is any of you know what are the expected changes? They should not be much but I don't know were it could be... Thank you Sent via Deja.com http://www.deja.com/Article: 28122
Peter and all,
I'll jump in here quickly and then go away because I have a
different perspective on the value of the capacitor for a parallel RC
termination. Refer to Johnson and Graham's "High-Speed
Digital Design, A Handbook of Black Magic." I just did to check
my reasoning.
In a nutshell, the R is chosen to equal Z0. The requirement
for C is that its impedance should be negligible compared to Z0.
Remember that it's the edge that we're terminating, and what
we'd all do if it didn't take so much static power is have a simple
R (= Z0) to a termination voltage. The C is a substitute for
that voltage source, and should present a very low impedance.
What's a "very low impedance"? Z0/10? Z0/100? You're the
engineers, I'll let you decide. The voltage source's output
impedance would ideally be 0 ohms. Keep in mind the
frequencies you use to calculate C's impedance: it's not the
signal's repetition rate, it's the frequencies present in the
edge. A 100MHz clock with a 1ns rise/fall has the same
termination requirement as a 1MHz clock with a 1ns rise/fall
time. According to the previously mentioned book, for a 1ns
rise/fall time and an impedance of 1 ohm you'd need C = 318pf.
Here's where most people get confused. The termination
voltage is not important from a signal integrity standpoint. It
can be 0V, 3.3V, even 100V. Of course, you then need to
assess the signal's drive capability into R and such a voltage.
Because of this, if it's not a drive issue, C can be arbitrarily large.
For that same reason, the signal's frequency and duty cycle are
not factors, UNTIL YOU NEED TO CONSIDER THE DRIVE
CAPABILITIES OF THE SOURCE.
Marc
"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3A412F6A.ACE1B0D6@xilinx.com...
>
>
> markp wrote:
>
> > In my experience series terminating clocks is superior to other forms of
> > clock termination, but I'll leave that can of worms to another thread!
> >
>
> Series termination is great for signals that go from one source to one
> destination.
> Since the drive impdance is adjusted to match the transmission line Z0, a
> half-amplitude signal travels down the line, is reflected at the
unterminated
> far end to become a full signal "instantaneously", then travels back to
the
> source, where it is swallowed up in the output impedance = Z0.
>
> Neat trick. It USES the reflection instead of FIGHTING it.
>
> But beware: Never ever (NEVER EVER!) use series termination for a signal
that
> has to travel to multiple destinations. All but the farthest of these
> destinations will see the half-amplitude signal for some time, which is
the
> worst level possible. Poor noise immunity, double-triggering etc. Ugly
stuff.
>
> The best way to terminate a clock that drives multiple loads is to have a
> strong ( low-impedance ) driver, then terminate the farthest end of the
clock
> "snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in
> SERIES, and this combination used as a parallel termination)
> Make the RC larger than the transition time, but smaller than the clock
High or
> Low time.
> 50 Ohm and 100 pF is a proven combination for all but the very fastest
clocks.
>
> Peter Alfke, Xilinx Applications
>
Article: 28123
Take a look at my site below:
Let me know if you have questions.
M. Simon Space-Time Productions http://www.spacetimepro.com
Free CNC Machine Control Software
Free Source Code
Control the World From a Parallel Port
Article: 28124On Thu, 21 Dec 2000 15:42:22 GMT, "S. Ramirez" <sramirez@deleet.cfl.rr.com> wrote: >Mark and Javier, > It sounds to me that your very tight jitter spec has nothing to do with >the tolerance of the refractive index of the transport media. I am assuming >that that transport media is steady in its prop delay of the signals. I am >also assuming that the system is designed with this in mind. If this is the >case, then it sounds to me that the clock is the only thing that will affect >the jitter spec. > For example, assume that there is a 7.345 ns difference in delay >between two receiver inputs. Javier says that this is okay. What he >doesn't want is a jitter in this delay greater than 1 ns. In order to meet >this spec, the sending clock must have a jitter spec that is better than >this. If Javier uses a PLL or DLL, then this device will add jitter to the >basic clock. I would use a very stable clock circuit that meets the jitter >spec. > Now if these cables are swinging in the wind, then I can see where that >kind of phenomena can affect the prop delay and introduce jitter. But >Javier has this under control, since he is only asking about circuits. If >transmission lines are held perfectly still and still introduce variations >in prop delay, then this is new to me and I am wrong here. In practice, I think that the clock jitter could be a very small part of the total jitter. This'll depend on exactly how he implements the system. Attenuation and dispersion, and other second order effects, will cause significant changes in the waveform down the line. On the systems I've worked on, the eye diagram at the receiver has generally been more closed than open. This is a direct measure of (best case) jitter on the line. In typical systems, you could easily get a jitter of 50% or more of the unit interval. Given this, I think there are a number of potential problems: (1) If Javier has cables of different lengths, then the receivers will be looking at different points in the pulse train, with different frequency components, and different (maybe very different?) instantaneous jitter (2) The receivers will have different receive thresholds, and so they'll be sampling their eye diagrams at different points (3) The receivers will have different terminations, and different asymmetries in their propagation delays. This'll affect the sampling threshold and the decision. I don't do a lot of this, but I think Javier's going to have to do some hard work unless he has short cables compared to the unit interval, a very clear eye diagram, tightly controlled receiver tolerances, and a good PLL. Evan PS - ignore what I said about delay lines in the last post - too much coffee...
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