08-07-2017 06:28 AM
I have a design that include three data streams and i want to switch between them. when i select one of these streams that is the output of an ADC i see unwanted peak such as below picture.Of course design is fully constrained and all of them have been met.
Is there any analysis technique in VIVADO that help to find out what the problem is?
08-07-2017 07:44 AM
Is the output of the multiplexer registered? If it is, the the state is only able to change at clock rising edges. The inputs to the multiplexer (and the ADC) should also be registered (change) on the same clock edge.
08-07-2017 08:05 AM
@nariman just to clarify:
There are three different ADCs which generate data streams or one ADC with three inputs and an analog MUX to select the input from?
You are switching between the digital data streams or between the analog channels?
The peaks are in the signal or in the data streams or just in the output of your system?
08-07-2017 08:38 AM
Do we know the scales of your graphs ?
First question, are the spikes in the analog or the digital ?
i.e. could these be what the adc is seeing ?
are the spikes the same with the input to the adc shorted ?
08-07-2017 11:13 PM
08-07-2017 11:19 PM
08-07-2017 11:56 PM
This could be a cause of unregistered data - read what @austin mentioned. Would you please confirm that all these three data ports have the same unique clock which are coming toward multiplexer?! Otherwise, you should definitely use FIFO to change clock domains!.
Use three FIFOs with independent clocks. In the FIFO input use every data port with its own clock. Then, in the output use a common clock - and maybe faster than input clock to prevent FIFO full - and switch between various FIFO outputs.
Another issue could be unstable clock or oscillator in your Analyzer board which makes it behave differently.
Hope this will help,
08-08-2017 02:16 AM
That digram has not detail of my design in main design every stream registered in adc clk and where ever need to cross domain clock i've used fifo.
08-08-2017 02:25 AM
08-08-2017 02:27 AM
You seem confident the adc is not seeing these spikes ,
what have you done to test ?
The spike amplitude, compared to your +- 32K , they are quiet small,
Have you checked the 12 bit to 16 bit conversion.
Your getting an equivalent number of bits of the ADC of about 7 , at the sample rate your using , with the bandwidth and frequency of the input signal what number of bits are you assuming you will have ?
You did not answer have you tried the input to the adc shorted to ground, see what noise you get.
08-08-2017 03:42 AM - edited 08-09-2017 03:09 AM
How can i get this untenability in clock or oscillator? is there any analysis reports in vivado to get this issue from them? is there any way to improve this in fpga for example using DCM? I think these peak could be the effect of clock jitter. I've used adc clk in overall of my design.
Sorry my mistake in the last line. You should consider "Report Clock Interaction" from Implemented Design where placer&router have optimized the design according to your strategies.
What Vivado is able to do - as far as I know - is to analyze your input jitter and calculate the output jitter of MMCM/PLL - which in 7 series is more than a simple DCM in previous generations.
What you are observing is that clock and data are not aligned well!. One simple test can be using a PLL and shifting the output clock and observing if displacement changes or not? This should be done in your Analyzer clock path!.
Do make sure that your clock wouldn't fail for anything by using reprot_timing_summery. Or, try take a look at the "Report Clock interaction" when you have opened Synthesis design.
Hope this would help,
08-08-2017 08:10 AM
I run report clock interaction and there are several hold time violation as you can see in the below picture but there isn't any hold time violation in timing summery!
08-08-2017 10:24 PM - edited 08-09-2017 01:34 AM
I don't know why it didn't mention anything regarding timing failure! Maybe it is like any other bugs which has not been fixed in any release ;-) It had happened for myself. It seems that you should always use report_timing_summery or take a look at clock interaction report in order to get complete information of clocks and timing.
This is the actual point you should start and try hard to achieve timing closure. Have you specified all timing requirements of input/output and clocks? You should specify those which are not used in MMCM/PLL.
Hope this would be helpful,