- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Suppose that I have two boards with Stratix II FPGAs. The boards sit close to each other, and lines from one FPGA reach the other, via a connector. The total length is circa 20 cm (8 inch). I want the two FPGAs to communicate with LVDS. Can I use the built in Altera LVDS IO for this purpose ? I'm concerned about speed / distance. The communication isn't too fast (40 MHz), but there's the distance and connector. Can I somehow know for which distance the internal LVDS drivers / receivers are good at this speed? Additionally, should I send both clock and data as separate LVDS pairs and recover with Altera megafunction at the receiving end ? Do I need a DPA here ? thanks in advanceLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The answer to the typical question "how fast and how much long" is not simple. The signal frequency vs. distance issue is strictly cable-dependant, and especially varies with cable size, quality of the shield and quality of the twist for each pair.
But you are speaking of 40MHz, which is realy low speed for LVDS and you should not have any problem with 20cm. At least be sure of a good shielding of your cable and the resulting eye pattern shoul be clean enough for a correct data recovery.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
At 40MHz you don't need to worry. However, I don't know if LVDS is the right choice for such a slow clock speed. You could do what you need to with just regular I/O. If it were me, I would run a serial data trace and a clock trace using regular I/O. Then just treat the interface as you would any source-synchronous interface.
Again at 40MHz you've got a lot of flexibiliity but your life will be easier if you've matched the trace lengths between the FPGA and connector on both boards and if your connector is impedance matched to your trace impedance. If you've got one trace that's noticably longer than the others, use this as your clock trace, then you may not need to phase delay your clock within the FPGA. Jake- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If doing something source-synchronous(i.e. sending the clock with the data), you could just invert the clock and have 12.5ns of setup and hold margin. The main thing to be concerned about is your clock, as you want to make sure there is no ringing, glitching, cross-coupling, etc. As long as that's all right, your data should have enough margin that if it does have any problems, they will settle down by the time the actual clock comes along. The only downside of source-synchronous is that the clock domain that comes back with the data will not be in synch with your internal clock, so you need to account for that. At 40MHz, you could just send a clock to both chips and you should be fine.
DPA is definitely not required.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the tips. My motivation to go for LVDS stems from electrical requirements, and not particularly speed. The two cards' digital grounds are not shorted together, and differential is the best way I can see to transfer data between them.
Therefore, I think I'll still go for LVDS, low speed nonwithstanding (unless there are better options you can suggest). The choice is now between internal Stratix II LVDS and an external RXTX LVDS device. I'll go for source-synchronous for sure, because there's no way to share a clock between the cards. When using the internal LVDS, is it completely transparent to top level code, i.e. does the corresponding Altera megafunction just present a "data_out" signal, that will come out as differential from 2 pins ? Also, if my clock speed is 40 MHz, and the transmission rate is also 40 MHz, I guess I"ll must use a DPA at the receiving end to shift the clock by 180 degrees ? Or is it better to multiply ?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
LVDS is good I/O standard for interchip and also interboard communication to my opinion, I have used it in several system designs, for lower distances with FPGA internal drivers. A reason not to use internal LVDS I/O are mainly requirements of overvoltage protection. Main adavantages are low generated EMI and matched impedance transmission at low power.
The protocol used through this physical channel is another thing. Generally, a synchronous transmission needs a bit clock and a sync signal (or frame clock). In some variants, the bit clock is generated from the frame clock by a a PLL (usually with high speed serial I/O) or bit and sync clock are reconstructed from a special coded data channel (e. g. by 8b/10b coding). Alternatively, you can use asynchronous (UART) transmission. A simple, well defined protocol with separate bit and sync clock is SPI. At 40 Mbit/s, the clock to data skew is low enough, to guarantee correct alignment without special means (as DPA), even through 10 or 20 m of twisted pair cable. A center aligned sampling is preferable, normally.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- A simple, well defined protocol with separate bit and sync clock is SPI. At 40 Mbit/s, the clock to data skew is low enough, to guarantee correct alignment without special means (as DPA), even through 10 or 20 m of twisted pair cable. A center aligned sampling is preferable, normally. --- Quote End --- Do you refer to the Serial Peripheral Interface SPI ? Because it doesn't have a separate frame sync signal, AFAIK, only a clock, data and in some cases a chip-select signal. Or did you mean the SPI-4.2 protocol ? In any case, are you perhaps aware of any Altera-provided megafunctions that can help me establish a physical-layer protocol relatively easily ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Thanks for the tips. My motivation to go for LVDS stems from electrical requirements, and not particularly speed. The two cards' digital grounds are not shorted together, and differential is the best way I can see to transfer data between them. --- Quote End --- Just how disconnected are your ground domains? If they are not connected at all, you will want to AC couple the LVDS signal lines, at least with capacitors, if not a transformer. An encoding scheme such as 8b10b will then be required to prevent DC drift on the AC coupling components.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Just how disconnected are your ground domains? If they are not connected at all, you will want to AC couple the LVDS signal lines, at least with capacitors, if not a transformer. --- Quote End --- I would expect a common ground and also ground connection together with the data lines. Otherwise the said transformer coupling would be necessary to guarantee an input voltage within receiver common mode range. Then you move far away from an easy interface, clock recovery and data resynchronisation from 8b/10b encoded data is supported by dedicated hardware only for gigabit I/O standards. It may be possibly achieved utilizing the DPA block and additional logic, but not easily. --- Quote Start --- Do you refer to the Serial Peripheral Interface SPI ? Because it doesn't have a separate frame sync signal? --- Quote End --- I've been often using a standard SPI (Motorola defined) interface. The CS acts as sync or frame clock in this case, just a shift register is the basic logic needed for receiver and transmitter.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I would expect a common ground and also ground connection together with the data lines. Otherwise the said transformer coupling would be necessary to guarantee an input voltage within receiver common mode range. Then you move far away from an easy interface, clock recovery and data resynchronisation from 8b/10b encoded data is supported by dedicated hardware only for gigabit I/O standards. It may be possibly achieved utilizing the DPA block and additional logic, but not easily. --- Quote End --- The two boards do share a common chassis, but their operating voltages and grounds are generated by separate isolated DC/DC converters. Their grounds are definitely close enough to not require AC coupling on the transmission lines. --- Quote Start --- I've been often using a standard SPI (Motorola defined) interface. The CS acts as sync or frame clock in this case, just a shift register is the basic logic needed for receiver and transmitter. --- Quote End --- I see, so it's the basic SPI that's used with, say, ADCs and various sensors. Thanks for the tips.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- The two boards do share a common chassis, but their operating voltages and grounds are generated by separate isolated DC/DC converters. Their grounds are definitely close enough to not require AC coupling on the transmission lines. --- Quote End --- A problem may arise, when the LVDS signal ground is the only ground connection between the two systems or even the only existing ground connection at all. Then high intereference currents are attracted by this connection. An additional ground connection and a common mode choke including all data lines and the signal ground (e. g. a ferrite core around the cable) may be advisable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- A problem may arise, when the LVDS signal ground is the only ground connection between the two systems or even the only existing ground connection at all. Then high intereference currents are attracted by this connection. An additional ground connection and a common mode choke including all data lines and the signal ground (e. g. a ferrite core around the cable) may be advisable. --- Quote End --- I don't understand - how does this work out with distant enclusures connected with LVDS between them ? They have absolutely no common ground (except Earth), and no other signals except the LVDS between them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Whoa let's not make this too complicated. If your grounds are seperated with no way of making them common, then yes your best bet is to run differential. If your grounds are not related to each other in some way, then you have absolutely no way of knowing what the potential between the two is.
However remember we're only talking 40Mbps here. Run four traces (a differential clock and a differential data signal). Use AC coupling caps on the traces (preferably close to the receiver). And use a simple DC-biased termination scheme. If you provide the clock, there is absolutely no need to encode the data. Encoding schemes like 8b/10b are designed to provide a maximum number of transitions to allow for easier clock data recover at the receiver. Just provide the clock. I assume that your boards have been layed out with differential traces? Jake- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Whoa let's not make this too complicated. If your grounds are seperated with no way of making them common, then yes your best bet is to run differential. If your grounds are not related to each other in some way, then you have absolutely no way of knowing what the potential between the two is. However remember we're only talking 40Mbps here. Run four traces (a differential clock and a differential data signal). Use AC coupling caps on the traces (preferably close to the receiver). And use a simple DC-biased termination scheme. If you provide the clock, there is absolutely no need to encode the data. Encoding schemes like 8b/10b are designed to provide a maximum number of transitions to allow for easier clock data recover at the receiver. Just provide the clock. I assume that your boards have been layed out with differential traces? Jake --- Quote End --- Yes, if I provide the clock I don't need to encode the data. No bad effects will happen if a AC-coupled line stays high for too long ? My boards are in the design phase, and we plan to use differential traces, yes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't claim to know your system enviroment in detail, but a LVDS connection without a acompanying signal ground has a high risc of catching interferences, with or without AC coupling. Also possible damage to the FPGA IOs must be feared.
You have to consider also higher frequecy interferences, not only DC and mains frequency potential differences. Would be different when using a transformer coupling, e. g. by ethernet magnetics. But this also requires 8b/10b, as suggested. Another (DC capable) solution is to use digital isolators from NVE or Analog.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I don't claim to know your system enviroment in detail, but a LVDS connection without a acompanying signal ground has a high risc of catching interferences, with or without AC coupling. Also possible damage to the FPGA IOs must be feared. You have to consider also higher frequecy interferences, not only DC and mains frequency potential differences. Would be different when using a transformer coupling, e. g. by ethernet magnetics. But this also requires 8b/10b, as suggested. Another (DC capable) solution is to use digital isolators from NVE or Analog. --- Quote End --- Thanks for all the help :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Yes, if I provide the clock I don't need to encode the data. No bad effects will happen if a AC-coupled line stays high for too long ? --- Quote End --- In most AC coupling schemes, it is important for the time average of the signal to be equal (or nearly equal) to the common mode voltage (ie. the same number of zeros and ones over some time span). If a constant value is held for too long, it will behave like DC, and will be filtered by the coupling circuit so that the receiver sees 0V differential. One way around this is to use 8b10b or similar encoding (yes, even if you are not doing clock recovery), as it guarantees DC balancing. This encoding scheme is not that complicated, and at your frequency, does not require any dedicated hardware. The complicated part would be the clock recovery, but you are not doing that.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page