1
\$\begingroup\$

I have a ADC (TLC2323-12) that (as far as i understand from the datasheet) has two modes of controlling the output of the converted signal. One method is with the input signal SCK that can be controlled from the FPGA whenever you want to shift the value to the FPGA, and the other is way is through CLKOUT which is an internal clock from the ADC that "automatically and bursting" (sorry I'm new at this) spit out the results bit by bit of the 12 bits resolution in total. This last method is described in datasheet as "High-speed" in comparison with the SCK method.

Now, I was able to control the ADC with the SCK method, because I can send the signals from the FPGA top module easily and the pick the value I want, in general I work with only 1 clock. But with the CLKOUT, seemingly this one behave like a second clock, so this is a dual-clock system?

What should I do to properly code the interface when using the CLKOUT method? There are 2 clocks now. The FPGA internal clock and the CLKOUT coming from the ADC that can "announce" to the FPGA the availability of the data.

I was reading around that an easy way maybe is to code an Asyncrhonous FIFO that can write from the CLKOUT and read from the FPGA Clock. is this right?

The interface is Serial, 2 channels.

\$\endgroup\$

1 Answer 1

Reset to default
2
\$\begingroup\$

I think you need to go a little further than your proposed solution. I would suggest that you have the data read from the ADC into a register using the ADC clock. The register should be long enough to hold the entire integer value from the ADC. Once that register is full with a reading the associated state machine logic would generate a signal to indicate that the value was valid and not going to change and can be read by the main FPGA logic.

From the point of view of the logic driven from the main FPGA system clock the register complete signal would be asynchronous, however you could use it as an enable signal to copy the data in one system clock cycle to another register on the next system clock edge. Thus you would now have the data available synchronous to the FPGA system clock.

The only restriction with this scheme that I can forsee is that the FPGA clock would need to be at a higher rate than the ADC clock to ensure that the data was available for sufficiently long.

\$\endgroup\$
2
  • \$\begingroup\$ In that case should I use 12 different data registers and 12 different "ready" signals? Because the ADC clock shift the data one by one, so they are available one after the other, and I wouldn't like to wait until 12 bits are completed for FPGA to start to read. And I was also concern about what you said, what if the output data is not there long enough or it changes in the wrong moment so the FPGA can't pick it up, wouldn't be better to let the ADC save the data on fixed memory, finish conversio at the same time the fpga read them to finally make fpga order adc to start again the conversion. \$\endgroup\$
    – sujeto1
    Commented Aug 4, 2017 at 9:21
  • \$\begingroup\$ I have assumed you need the whole integer value from the ADC for subsequent process so I am proposing a single 12 bit register which could be read into over 12 ADC clock cycles [probably as a shift register] but all 12 bits would then be read from by the FPGA in one system clock cycle. Having the data ready signal as an enable signal for the read logic solves the synchonisation issue. I have amended the answer to hopefully make this clearer. \$\endgroup\$
    – John
    Commented Aug 4, 2017 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.