06-18-2018 02:32 AM
I am implementing an SpaceWire in Spartan6. One of the characteristics of this link is the clock recovery logic, which requires that the spacewire Data signals is also connected to a clock generation logic.
I wonder if the threshold for the edge detection could be an issue to be taken into account in the STA. I mean, this data goes from input pin to the D input in internal flip flop. In this D input, it shall be a voltage threshold to distinguish between low and high value.
But this data signal is also applied to an XOR gate, where again, the digital value has to be detected, but maybe with a different voltage threshold.
The incoming signal has a slow slope and changes in this voltage threshold could lead to some ps that are important to our STA.
How can we get this voltage thresholds? Or it is exactly the same for all cells?
06-18-2018 04:11 AM
You do not need to worry about voltage thresholds internal to the FPGA. You do need to worry about voltage thresholds at the pin. The input signal needs to be a valid logic signal for the type of pin (regular IO or GTP transceiver).
06-18-2018 04:38 AM
I don't understand you reply.
The input signals are how they are. They are analogue and not digital and sometimes they have noise and they could have very strange shape, even ripple in the edges. I want to know this bad quality of the signals affect the timing.
06-18-2018 05:08 AM
The input to a Spartan 6 must be a digital signal. Read UG381 Spartan-6 FPGA SelectIO Resources User Guide to find a list of digital signal standards that you can use. If you have a noisy analogue signal, you should put a comparator on the board with some hysteresis and possibly some noise filtering before the comparator.
Another possibility if your signal is low enough bandwidth is to use a fast ADC to digitize it. You would then have the ability to do more complex noise filtering.
06-18-2018 06:12 AM
I understand what you mean. But the board is done and we have some noise in the signals and we need to analyze if the noise could have an impact in the behavior or not.
In this case, we can't modify the board and in the FPGA documentation I expect to have enough information to analyze this case.
06-18-2018 08:23 AM
You have more or less been given the answer you are looking for. DS162 shows the Vih and Vil voltages for all input standards (Table 9). If you don't meet these requirements, then this is not a "digital" input can cannot be handled as a digital (or at least synchronous digital) signal by the FPGA.
You should also note that the separation in Vih/Vil is much smaller for a Vref referenced standard (like SSTL or HSTL), so you should use these standards instead of a conventional input like LVCMOS. Of course, you would need to supply a proper Vref voltage for the bank used (and if your board is already done, then you probably don't have this...)
You haven't told us what you are doing with this signal - is it synchronous or are you trying to oversample it? If it is synchronous, then you would need to provide constraints that represent the "latest" time it crosses above/below Vih/Vil for the maximum timing and the "earliest" time it crosses back below/above Vih/Vil for the minimum time - between Vih and Vil, the signals is neither considered a valid 0, nor a 1.
If it is oversampled, then you need to ensure that the time it spends above/below Vih/Vil is "long enough" to be sampled (more than 1 clock period, usually approximated as 2), and that you use proper synchronization techniques - if it is a slow changing single bit signal, then a 2 (or more) stage synchronizer is sufficient, but it if is something else then it needs a more sophisticated synchronizer.
06-18-2018 11:42 PM
I have checking the table you referenced in the DS162.
For more details, it is handle of an spacewire interface. It is a synchronous signal but with special characteristics. The same signal goes to the D input of a FIFO and to a XOR gate to generate the clock for the same flip-flop. That is why the timing is very critical in this implementation and any noise or distortion in the signal have an impact in the correct detection of the clock.
Additionally, there is no way to set proper constraints to control this, as the signal is synchronized with itself.
The incoming signal is, of course, digital, between 0 and 3.3 Volts. It looks good.
In an LVCMOS33 then we have an area between Vil and Vih with not determined value, it is between 0.8 and 2.0 v.
As the slope is slow, it can take more than 1 or 1.5 ns to cross this no-where area, which creates an uncertainty in the incoming signal.
This uncertainty has to be considered only in the input port, or it is somehow propagated to the internal cells?
I really think that the best is consider this uncertainty timing as additional margin for our calculation, what represent also our observations.
Thank you again.
06-19-2018 04:39 AM
The input port of the FPGA is basically a logic buffer/level translator. It translates the input signal, in this case a "1" at around 3 volts, or a "0" at around 0.2 volts and sends the 1 or 0 to the FPGA fabric at the logic level that the fabric (core) is running at. The buffer is saturated logic. It will try to always send either a clean "1" or a clean "0" to the fabric. If you get the input level close enough to the trip point, you might make it oscillate, but with something as fast as a Spartan 6, I've never seen it happen. 1 to 1.5 nS really isn't a slow rise time unless your signal is very high frequency. What is its baud rate?
06-19-2018 06:00 AM
The Baudrate is 100 Mbps. It means for signals toggling every 10 ns, we have 1.5 ns uncertainty in the edges.
If after the input pad, the signal we have is pure digital, it is just jitter in the input signal, which probably have to be included in our analysis.
06-19-2018 08:19 AM
It is hard for me to express how un-FPGA friendly this standard is... Having any kind of gate on the "clock" means that you cannot use the dedicated clocking paths inside the FPGA - the signal has to come in on a pad, go to the general fabric for the XOR gate and then go to the clock resources (clock buffer). This is pretty bad - the timing characteristics of this interface will vary from implementation run to run since it is not using dedicated clocking resources.
Furthermore, constraints are at least "difficult" - I am not sure they are impossible, but they are certainly difficult. Doing this interface (which relies on fabric routing) without constraints is pretty much a formula for disaster - this thing is going to be very hard to prove that it works...
I have an alternative - oversample the interface.
If the data is really 100Mbps, then you have lots of room for oversampling; the ISERDES and the BUFIO2 can run at almost 1GHz - that's WAY more than enough to oversample a 100Mbps interface. This can be done using all dedicated resources, (the clock on a clock buffer, the data captured in the ISERDES), so there will be no variation run to run. If you sample at (say) 800MHz, you get 8 samples per bit - more than enough to figure out when your data and strobe are changing, and hence figure out where the bit is, and what value it is. If you use the ISERDES in 8:1 deserialization at this speed, you can look at the 8 sample of D and S and determine what bit there is during this clock - note that due to clock drift you could get 0, 1, or 2 bits in a given 100MHz sample (with an average of 1).
This is definitely workable - you have lots of degrees of freedom as to how to design this. And the result would be reliable, which is more than I can say for a conventional implementation of this on an FPGA...