I am using Quartus Prime Standard for a Cyclone V design to instantiate an interface to an 8 channel 12-bit ADC in 2-wire mode. I'm using the ALTLVDS_RX megafunction and I have configured it for 16 channels each running at a deserialization factor of 6. I am using the frame clock out of the ADC which is running at 30 MHZ (which is actually half the ADC sample rate of 60MHz because the frame clock is intended to be DDR). So here are my inputs to the ALTLVDS_RX module:Input clock: 30 MHz Deserialization factor: 6 Number of channels: 16 Data rate: 360 MHz The documentation (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/ug/ug_altlvds.pdf page 3) claims that the output clock rx_outclock rate will be the Data rate divided by the deserialization factor (360/6 = 60), however, the rx_outclock rate that the FPGA is generating is at half that rate (30 MHz). Why?
Interesting. This is related to a post I just made regarding ALTLVDS_RX. What I can tell you is that if you use the MegaWizard GUI to instantiate an ALTLVDS_RX module, and you choose to use an external PLL, it will tell you that you need to apply;1) (rx_inclock) a fast clock at the data rate = 360Mhz 2) (rx_enable) a slow (framing) clock = 60Mhz (with a specified duty cycle)
Yeah, I'm thinking I'm going to have to switch to using an external PLL so I have more control over the clocks. I just assumed the input clock rate didn't really matter as long as it was related to the data rate. In other words I assumed the ALTLVDS block would use the input clock to generate the data rate clock and then based on the deserialization factor it would use the data rate clock to create the output clock. However, if the internal data rate clock is running at half rate (because maybe it is DDR) then dividing it by the deserialization factor would create a clock at half the output (parallel) data rate. What concerns me then is that if the output register is turned on in the megafunction (I think there is an option for registering the output data with rx_outclock) then the module would be throwing away half the data unless that register was a Double data rate register also.
Well, log this one away as user error. It turns out, due to a totally unrelated issue, the input clock was at half the rate I expected...therefore the output clock was at half the rate I expected.