12 bit serial adc

I do not mean simulation, it works in real FPGA designs. What chip are you using? So in your case, you only have a data width of 2? Sure, that might work. My case is the following. I have a data rate of Mbit with a data clock at MHz and a frame clock at The only thing I can think that I did wrong is I forgot to hook up the data and frame clocks to dedicated clock pins. The documentation says this is still a valid clocking method.

Good news: We got it! One common frame-clock and one common data-clock signal for all 8 data lanes. But we have always seen the same data on rising and falling data-clock edge. To be more precise: the falling edge data was always the rising edge data. Due to my colleague, who is our VHDL-expert, the tap we were caught in was a failure in the Xilinx documentation.

By the way: to me it seems as if XAPP documentation and source-code do not match. After some more testing I will come back and tell you the secret. But it will take a few days. Great news! I'm very interested in what your findings were. I would like my code to be a little more robust than it is right now. Is'nt that crazy? Xilinx tries to make it EASY for you.. That's what I am talking about. But in practice, the inversion was not done. I am looking forward to your answer. If what you say is true, and it only works in simulation then it means that XAPP has never been verified on silicon and can not work on real silicon at all.

Let's see if Niels reacts to this ping. How did you handle the instantiation of doublenibbledetect? When I set width to 12 bit and wire to 1 I got wrong size of data buses to that module.

It would be very interesting to know how much your final result diverge from the original xapp Intensive research showed that above 60Msps, the output-timing of the ADC changes slightly. A "feature" not documented in the ADCs data-sheet. If you want to use any automatically generated cores from Xilinx, forget it.

If you want to make it your own, forget about XAPP It was developed and teste with ISE, and the restrictions of Vivado makes this approach useless. Seems trivial and obvious enough, but I was getting some pretty confusing results until I realized it was necessary.

But you have the luck to work with a Bit ADC in two lane mode. I asked "why? Sadly, there are some weird gaps in the coregen IP these days, and they seem to get less flexible over time rather than more flexible.

For instance, you technically can't create a MIG that can run from a 48 MHz USB clock anymore because they've severely restricted the clocking options. What ADC part are you working with?

I am using AD from Analog Devices. I am running it at 32MHz sampling clock. I was stupid enough to install Vivado Not a big issue as I keep old Vivado releases for this kind of upsets, but it adds to the degenerating flexibility of Vivado. We run it stable at 50Msps, and are close to achieve stable operation at 75Msps.

Thanks, EC. I found the problem. The operation of max is controlled by software. The software shall be able to generate all control signals required for successful conversion and detect EOC status. It shall also be able to generate 13 external clock pulses to read serial 12 bit data and convert it into parallel data. In the code, port defines the Centronics port of the PC that interfaces with max If no valid EOC occurs, the loop will continue to operate.

If the value of the serial data bit is 1, 1 is added to the parallel data. Once the parallel data is ready, the subroutine returns this value and displays it on the screen. Your email address will not be published. It is also necessary to check where the bit output DATA sits in the bit data frame.

Figure 1b. The serial interface lends itself to galvanic isolation with external optocouplers. Figure 2 shows the block diagram of the LTC The internal architecture has been optimized to send out data serially during conversion, without degradation of conversion accuracy due to digital noise. As a result, the analog accuracy of the LTC is insensitive to the phase, duty cycle or amplitude 3V or 5V of the external digital inputs.

The LTC is ideal in multiple-ground systems, where the differential input is connected to one ground, the supplies and grounds of the LTC connect to a second, local ground and the output ground connects to a third, digital ground. A proprietary sampling front end circuit achieves exceptional dynamic performance at the 1. Figures 3 and 4 show the spectra from a 1. With this very clean spectrum, the LTC minimizes crosstalk and interference in communications applications where the spectrum is divided into many frequency slots.

Positive signals can be applied with single or dual supplies and bipolar signals are easily accommodated with dual-supply operation. The wideband signal conversion purity shown in Figures 5a and 5b makes the LTC well suited for digitizing sine wave signals well above the 1. Figures 6 and 7 show that transfer function purity, represented by the differential and integral linearity plots, is maintained at the full 2.

Except for the sign inversion, these two inputs are identical. The wide common mode rejection bandwidth of the LTC —60dB at 10MHz input affords excellent ground noise rejection in complex, noisy systems.