Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

DCLK and DATA0 connected to LVDS output instead of floating

Altera_Forum
Honored Contributor II
2,389 Views

The Cyclone II handbook says that after programming, the DCLK and DATA0 inputs should not be left floating and should therefore be connected to a logic high or low. 

However, it also states that the inputs are Schmitt-trigger gated. 

 

So, what if, after programming, I connect the DCLK and DATA0 inputs to the respectively positive and negative output of an LVDS line? 

That does keep them from floating, but it also doesn't present a clear low or high; then again, the schmitt-trigger input should be happy with this; or is it?
0 Kudos
29 Replies
Altera_Forum
Honored Contributor II
800 Views

I forgot to mention (in case it wasn't obvious already) that I'm using passive configuration mode.

0 Kudos
Altera_Forum
Honored Contributor II
800 Views

Judging by the "overwelming" responserate to this question, I presume it is not easily answered unless you work at Altera, and Altera employees don't contribute to the fora. Any suggestion where I can mail/send this question to catch their attention? (No, I do not have a support contract (yet)).

0 Kudos
Altera_Forum
Honored Contributor II
800 Views

If you are using passive configuration mode you are driving Dclk and Data0 with a LVTTL signal during configuration, so where does the LVDS come in? 

LVDS is not a LVTTL signal and although there is a schmitt-trigger input the LVDS level may fall in the intermediate zone.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

Seriously, noone can predict what's exactly happening with your circuit. Strictly speaking, the questioned circuit is violating the requirement of keeping the input either high or low. So I would avoid it. I guess however, that you have a reasonable motivation for the attempt. There's no way than trying it yourself! Furthermore, for obvious reasons you can be rather sure to get no satifying answer from Altera about unsupported features and device operation beyond the specified conditions. 

 

Generally, it's simply good engineering praxis to avoid floating inputs. Floating input will at least cause additional current consumption, because the respective CMOS input buffers are possibly floating through their linear range. At worst case, very high frequent self oscillations can be brought up, causing excessive supply currents and interferences.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

Strictly speaking, the questioned circuit is violating the requirement of keeping the input either high or low. 

--- Quote End ---  

You don't have to keep Dclk And Data0 at either a logic high or a logic low indefinitely, they may toggle. We use the same signals for both configuring and controlling the FPGA, by connecting both Dclk and Data0 to an IO pin as well.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

without going into the specifics of these two pins requirements, in general I will apply the rule of unused pins to them once their use is over, hence the same options for unused pins apply: either ground them or tristate them if applicable. Keeping pins as floating converts them to mini-aerials picking up frequencies and increasing the noise...at least that is what I am told...

0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

There's no way than trying it yourself! 

... 

Generally, it's simply good engineering praxis to avoid floating inputs. Floating input will at least cause additional current consumption, because the respective CMOS input buffers are possibly floating through their linear range. At worst case, very high frequent self oscillations can be brought up, causing excessive supply currents and interferences. 

--- Quote End ---  

 

 

Of course I can try it myself, but that doesn't mean that I get a statistically relevant result, which is why an answer with more insight might give me a bit more confidence about the risks I'm running. 

 

As to floating, strictly speaking I don't keep them floating, I fix them to a narrow range (specifically the range of the LVDS signals), which should keep them from floating and in theory, this should be within spec of a Schmitt Trigger input. 

 

The reason I want to implement it like this is that I have a remote unit which I want to program (re)using some of the wires to it which are normally used for LVDS dataexchange. 

This means that I have an FPGAmain on my mainboard from which three wires (plus power) are running to the FPGAremote unit. 

 

The FPGAmain will have one LVDS inputpair which I connect to two separate TTL outputs also on FPGAmain. Both lines are connected to DCLK and DATA0 on FPGAremote in addition to some LVDS outputpair on FPGAremote. There is one line from FPGAmain (TTL output) which is connected to nCONFIG on FPGAremote. 

 

During startup FPGAmain is programmed using active mode via a flashrom. 

Then FPGAmain will manipulate DCLK/DATA0/nCONFIG to FPGAremote using TTL levels to program it, after which FPGAmain will tri-state the drivers on the TTL-outputs for DCLK and DATA0 to FPGAremote, and subsequently will FPGAremote (after startup) use LVDS on that same signalpair to communicate to the corresponding LVDS inputpair on FPGAmain. 

 

My assumption was that it might work because the inputs strictly aren't floating anymore and therefore should not pickup stray signals, and the fact that they're Schmitt Triggered should keep them from oscillating wildly because the LVDS levels do not hover around the Schmitt Trigger levels.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

This could be tricky indeed. 

I didn't find the hysteresis specifications for DClk and Data0 in the Cyclone II data sheet. I have the feeling that the LVDS levels applied after configuration could stay in the undefined zone. So without more information from Altera about the Schmitt Trigger hysteresis we don't know whether it will always work. Maybe the Ibis models could be of help? (if they are also given for Dclk and Data0) 

One more observation is that at the end of the configuration of FPGAremote this may possibly start sending data on the LVDS outputs before you can tristate the TTL outputs on FPGA main, possibly disrupting the configuration. 

Why not use 2 more wires between FPGAmain and FPGAremote?  

Or use LVCMOS differential signalling instead of LVDS (saving 2 pins on FPGAmain as well)?
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

I aggree to your considerations in so far, as I don't expect problems when connecting DCLK and DATA0 to a LVDS level logic signal during user mode. I didn't se a specification of the Cyclone II ST input buffer, so I can't say, if the LVDS signal will possibly cross the threshold levels during operation and if the hysteresis is larger than the maximum LVDS swing.  

 

I also keep my opinion, that you can't derive conclusions about the behaviour of single ended inputs connected to in-between (LVDS) logic levels from the datasheet. But I must admit, it's more a theretical discussion about what can be said for sure. 

 

P.S.: There should be simple option to "disconnect" the signals based on the state of CONFIG_DONE.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

One more observation is that at the end of the configuration of FPGAremote this may possibly start sending data on the LVDS outputs before you can tristate the TTL outputs on FPGA main, possibly disrupting the configuration. 

Why not use 2 more wires between FPGAmain and FPGAremote?  

Or use LVCMOS differential signalling instead of LVDS (saving 2 pins on FPGAmain as well)? 

--- Quote End ---  

 

 

Well, for one, I know exactly in FPGAmain when the config data is complete, so I can switch to tristate well before FPGAremote has finished its boot-process. 

As for two more wires, yes, I wish... 

 

The connection that I have between main and remote is a CAT-5 cable with 4 wirepairs. 

One wirepair is used for GND/18V (the powerlines). 

One wirepair is used for LVDS communication from FPGAmain to FPGAremote. 

One wirepair is used for LVDS communication from FPGAremote to FPGAmain (and doubles as DCLK/DATA0 during the configuration stage). 

One wire is used for nCONFIG to FPGAremote. 

One wire is unused (but will probably be connected to GND). 

 

So, in short, I don't have the two extra wires (I have one, but that doesn't solve the problem). Unless someone has a clever idea on how to solve this differently given the CAT5 constraint. 

 

As for using LVCMOS hand-made differential signaling. That would be an option, I guess. But I'd like to communicate over CAT5 wires up to a 100m with 32MHz, so real LVDS would be better, I think.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

100 m over CAT5 is different ballgame than what I had visualised. 

I personally wouldn't connect a cable directly to a FPGA. Any disturbance on the cable could kill off the FPGA(s). 

The direct connection to config_n may/will be vulnerable to disturbances as well. 

 

My suggestion is to do everything in LVDS using external drivers/receivers. To make up for the missing signals you could add a MAXII to (safely) decode the configuration from the 2nd incoming LVDS line.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

I personally wouldn't connect a cable directly to a FPGA. Any disturbance on the cable could kill off the FPGA(s). 

The direct connection to config_n may/will be vulnerable to disturbances as well. 

--- Quote End ---  

 

 

Is a Cyclone II more likely to break due to spikes than some kind of dedicated LVDS driverchip? 

Meaning: since I'm using the cheapest Cyclone II chips (EP2C5), there is no concern that an expensive chip might break. The only concern is that something breaks. So if the probabilty that something breaks can be significantly reduced by using driverchips between the FPGA and the CAT5, then that is what I'll do. 

 

As for vulnerability of the nCONFIG line, I was meaning to put a pull-up resistor on it to 3.3V at both ends of the line, to make sure that it never spikes down to zero and causes a spurious reconfig. 

 

[Addition] 

I already looked it up, and notice that the ESD protection offered by dedicated LVDS buffer chips is a lot higher than that what the FPGA offers (if any). I'll redesign and use LVDS buffers/converters, which kind of automatically solves my problem with the LVDS connected to the FPGA (it won't be, anymore).
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

I'm not sure whether the external LVDS chips will be stronger, and as you are using the smallest EP2C devices you may as well give it a try. 

To reduce the chance of breaking things you have to add additional protection devices as well. 

Also you must protect the circuit from false cureent supply loops while hotplugging the system (this if you are using RJ45 connectors, or in fact almost any connector).  

Did you think about the termination of the mixed LVDS-LVCMOS pair? You may run into an incompatibility there.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

Is a Cyclone II more likely to break due to spikes than some kind of dedicated LVDS driverchip? 

--- Quote End ---  

 

I think it is. A lot of LVDS interface chips have specified ESD strength in contrast to the FPGA. 

 

I personally prefer isolation by ethernet transformers for external LVDS interfaces, but it's involving additional effort for a DC balanced physical layer.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

I'm not sure whether the external LVDS chips will be stronger, and as you are using the smallest EP2C devices you may as well give it a try. 

 

--- Quote End ---  

 

I digged into it some further, and it appears that the Cyclone II is capable of taking a 1kV discharge by human touch. Comparing that to some of the dedicated buffers which are typically 2kV/4kV/8kV, I'm wondering if it will make a large difference in my case. The equipment is usually installed once, the main part will be indoors, the remote part will be outdoors on the roof in an isolated plastic box connected to just this single RJ45 which also supplies power. The 1kV provided by the Cyclone II might be enough. 

 

--- Quote Start ---  

 

To reduce the chance of breaking things you have to add additional protection devices as well. 

 

--- Quote End ---  

 

Like? The circuit does not have to survive a direct lightning hit. 

 

--- Quote Start ---  

Also you must protect the circuit from false cureent supply loops while hotplugging the system (this if you are using RJ45 connectors, or in fact almost any connector). 

 

--- Quote End ---  

 

I understand what you mean, but I have to admit that I lack the experience to readily know where it would apply to my RJ45 signals. Could you give an example? 

 

--- Quote Start ---  

 

Did you think about the termination of the mixed LVDS-LVCMOS pair? You may run into an incompatibility there. 

--- Quote End ---  

 

Well, that basically is solved (I think), because I use the LVDS termination and simply make sure that the slewrate for the configuration signals is slow enough and low frequency enough to survive the wrong termination.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

One (curious) question: how many circuits are you going to build? Tens or thousands? 

 

A construction on a roof is exposed to more 'lightning' than one thinks. 

 

If you insert a 'live' RJ45 connector into its mating socket the sequence of making contact is undefined. Sometimes the Vcc makes and some signals make contact before the Gnd finally gets there. Some circuits do not survive this 'game of Russian roulette'. 

 

The termination could be the Achilles' Heel. The slow slew on the TTL outputs may not be enough to get rid of reflections on the Dclk and Data0. If it turns out to be enough they represent a significant resistance of 50 ohm (or more). These resistances in combination with the mandatory 100 ohm termination to receive LVDS later will eat heavily into the signal swing of the TTL outputs. To quote Einstein: "Everything should be made as simple as possible, but not simpler." 

 

Do you need 32 MHz signalling rate towards FPGAremote?
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

One (curious) question: how many circuits are you going to build? Tens or thousands? 

--- Quote End ---  

 

A production run of 1000 to 4000 (depending on how well they perform). 

 

--- Quote Start ---  

 

If you insert a 'live' RJ45 connector into its mating socket the sequence of making contact is undefined. Sometimes the Vcc makes and some signals make contact before the Gnd finally gets there. Some circuits do not survive this 'game of Russian roulette'. 

 

--- Quote End ---  

 

Good point. Part of this can be solved (in my case) by instructing the installer not to powerup the main unit until the remote unit has been plugged in. 

 

--- Quote Start ---  

 

The termination could be the Achilles' Heel. The slow slew on the TTL outputs may not be enough to get rid of reflections on the Dclk and Data0. If it turns out to be enough they represent a significant resistance of 50 ohm (or more). These resistances in combination with the mandatory 100 ohm termination to receive LVDS later will eat heavily into the signal swing of the TTL outputs. To quote Einstein: "Everything should be made as simple as possible, but not simpler." 

 

Do you need 32 MHz signalling rate towards FPGAremote? 

--- Quote End ---  

 

Well, I need 8MHz datarate, 32MHz is a tad bit higher than the minimum. So lowering that would still be an option (a bit). 

 

However, I shopped around for some LVDS drivers/receivers, and eventually found: SN65LVDS391 and SN65LVDT390 from Texas Instruments. They offer >15kV ESD protection, which is significantly higher than the 1kV of the standard Cyclone II protection. 

 

So what I'll do now is skip the LVDS on the FPGA and simply use LVTTL to/from the buffers. This automatically solves the DATA0/DCLK/nCONFIG issues, since I connect them over three pairs, through LVDS, through the buffers.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

 

--- Quote Start ---  

So what I'll do now is skip the LVDS on the FPGA and simply use LVTTL to/from the buffers. 

--- Quote End ---  

A much more safe solution, I think. 

 

--- Quote Start ---  

Part of this can be solved (in my case) by instructing the installer not to powerup the main unit until the remote unit has been plugged in. 

--- Quote End ---  

 

Simply consider that people (and particularly hasty service guys) use to hot-plug any connector, that you won't even think of. Unfortunately, they don't confess, just return a device "defective on arrival". It can be really reassuring to make the device hot-plug capable, if ever possible.
0 Kudos
Altera_Forum
Honored Contributor II
800 Views

The whole hardware design approach here is not going to work :) 

First thing that you'll experience is sporadic remote FPGA reconfigurations due to noise pickup on 100 m nCONFIG line. 

As to ESD then "human body model" is just one of the several ESD model. There is a "machine model" and most important for you - "cable discharge model" (http://www.national.com/an/an/an-1511.pdf). They differ greatly in the ESD power they can apply to you circuit (e.g 15kV "human" is not equivalent to 15 kV "cable"). 

You'd need a reliable way to configure remote FPGA. You might add a small flash-based micricontroller on the remote side with LVDS-to-LVTTL buffers, send FPGA configuration data to MCU over LVDS with some CRC. And then MCU configures FPGA.
0 Kudos
Altera_Forum
Honored Contributor II
685 Views

 

--- Quote Start ---  

The whole hardware design approach here is not going to work :) 

First thing that you'll experience is sporadic remote FPGA reconfigurations due to noise pickup on 100 m nCONFIG line. 

--- Quote End ---  

 

This is likely, even if nCONFIG is a dedicated LVDS twisted pair? 

 

--- Quote Start ---  

 

As to ESD then "human body model" is just one of the several ESD model. There is a "machine model" and most important for you - "cable discharge model" (http://www.national.com/an/an/an-1511.pdf). They differ greatly in the ESD power they can apply to you circuit (e.g 15kV "human" is not equivalent to 15 kV "cable"). 

 

--- Quote End ---  

 

I realise(d) that already, however, AFAICS the ESD specs for buffers seem to increase for both values when the human body model value increases. I figured, that the best I could do, was find a buffer IC that has the highest values for the human body model, and that will automatically make it the most robust for the machine model (albeit with lower absolute values than for the human body model). And considering that, the best buffer ICs I could find offer 15kV human body model of ESD protection, which translates into a lot less in the machine model, but since they're the best I can find, what else can I do? Hmmm, I see that the reference you provided outlines some of the other protective measures I can take. Interesting read, thanks. 

 

--- Quote Start ---  

 

You'd need a reliable way to configure remote FPGA. You might add a small flash-based micricontroller on the remote side with LVDS-to-LVTTL buffers, send FPGA configuration data to MCU over LVDS with some CRC. And then MCU configures FPGA. 

--- Quote End ---  

 

If a 100m LVDS driven nCONFIG twisted pair is going to be prone to occasional transients which are going to cause it to misread as a spurious undesired low level, then the most likely alternative is that I use a flashrom for FGPAremote as well, and then program the flashrom from inside the FPGAremote if I need to adjust the programming/logic (yes, I know that makes me vulnerable to powerloss during reprogramming, but that is an acceptable risk).
0 Kudos
Reply