FMC ADC 100M 14b 4cha - Gateware issueshttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues2019-08-05T11:16:17Zhttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/9gateware manual: wrong data format reported for channel status registers2019-08-05T11:16:17ZDimitris Lampridisgateware manual: wrong data format reported for channel status registersThe gateware manual states that the data format for channel status
registers is 2's complement.
This is a (semi) false statement, the actual data format depends on the
configuration of the ADC; it can be either "offset binary", or 2's
complement.
By default, after power-up, the ADC is configured for "offset binary".
On the other hand, our driver will always reconfigure it for 2's
complement if/when loaded.
The gateware manual should be updated to better describe this, to avoid
confusing users of the gateware who are not using our driver and expect
to see 2's complement values, but get the default offset binary instead.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/4Misalignment of external trigger wrt data2019-08-05T10:46:07ZDimitris LampridisMisalignment of external trigger wrt dataIt was discovered that in release 4.1, the external trigger is
misaligned with respect to the ADC data.
Due to differences between the time required for the delivery of the
data (which needs to be digitized, serialized, delivered to the FPGA and
de-serialized before it becomes available) and the delivery of the
trigger pulse (which only goes through a synchronizer inside the FPGA),
the external trigger arrives earlier than the data.
This was acknowledged in release 4.0, when in case of external triggers,
the driver would program the FPGA to introduce 3 delay cycles to the
trigger, to align it with the data.
However, during recent lab measurements, it was discovered that the
correct value for this delay is 5.
This was measured by using an Agilent 33600A function generator to
generate a -5V/+5V square wave, together with a trigger out signal. The
difference between the trigger signal and the zero crossing of the
square wave signal was measured with an oscilloscope to be 5ns. When
acquiring the data with the FMC-ADC, the zero value would appear 2-3
samples after the external trigger. After disabling the software
correction of 3 cycles, the zero value appears 5-6 samples after the
external trigger, revealing the true delay between the two paths. Given
the 5ns "error" from the function generator (half a sampling clock
period), a correction value of 5 clock cycles should be used to align
external trigger and data.
This should not be implemented anymore in software. Instead, with the
new trigger logic in place (see also #8), this delay should be
handled in the gateware because it will be much harder for the software
to know when to introduce it, in case of logically OR'ed triggers.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/3Add correct delays to all trigger sources2019-08-05T10:44:52ZDimitris LampridisAdd correct delays to all trigger sourcesAs already explained in #4, all trigger sources (except the internal
threshold triggers) should be delayed to compensate for the time it
takes to sample, digitize and deliver the ADC data to the FPGA.
For the external trigger it has been calculated that we need 5 delay
cycles for proper alignment.
We need to calculate the delays for time and software triggers as well.
For time triggers, it will be much easier to do it with White Rabbit in
place. See also #15 and #26.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/2Wrong sampling clock freqency in the Xilinx constraints2019-08-05T09:59:28ZDimitris LampridisWrong sampling clock freqency in the Xilinx constraintsThe serialized ADC sampling clock is defined in the Xilinx constraints
file as having a 2ns period. When propagated through the FPGA PLLs this
results in a 125MHz sampling clock.
Indeed, the ADC datasheet states that for two-lane, 16-bit data, the
"length" of each bit is 1/(8\*Fsampling), or 1.25ns. Given the fact that
the stream is DDR, the serial clock frequency will be double that, or
2.5ns.
When the serial clock is set to 2.5ns in the constraints, the propagated
sampling clock is correctly calculated as 100MHz.
Using 2ns instead of 2.5ns (and therefore also 125MHz instead of
100MHz), can generate HOLD timing violations.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/5Update Gennum core to address critical freeze issue2019-08-05T09:59:10ZDimitris LampridisUpdate Gennum core to address critical freeze issueV5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/29hdl - Trim unused clock signals2019-08-05T09:56:20ZDimitris Lampridishdl - Trim unused clock signalsA couple of clock signals described in the VHDL code are not used
anywhere in the design.
Examples include the L\_CLK top-level differential pair on the SPEC
board, which is buffered via a IBUFDS element and then left unused, and
a 250MHz PLL clock output which is buffered via a BUFG element and then
left unused. This list is not exhaustive.
These changes (if any) will be internal to the Gateware and will thus
not break backwards software compatibility.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/30hdl - Review and sanitize reset logic2019-08-05T09:56:07ZDimitris Lampridishdl - Review and sanitize reset logicThis has been mentioned already in Section 7 (Missing features and
improvements) of the Gateware manual v4.0.
Several problematic sequential processes have been already identified
within the Gateware.
Potentially problematic reset strategies include the main power-up reset
process in the top-level SPEC design, as well as the various
asynchronous resets in the FMC ADC core block.
The whole reset strategy should be reviewed and, if necessary, amended.
These changes (if any) will be internal to the Gateware and will thus
not break backwards software compatibility.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/1doc - fix formula for calculating the corrected DAC value2019-08-05T09:52:53ZDimitris Lampridisdoc - fix formula for calculating the corrected DAC valueIn section 5.2.2, the documentation says that the formula for
calculating the corrected DAC value is:
c\_val = ((val + offset) \* gain/0x8000) - 0x8000
However, in bipolar mode, according the manual, the DAC encodes zero as
0x8000, vref as 0xffff and -vref as 0x0000.
Therefore, the formula should be:
c\_val = ((val + offset) \* gain/0x8000) + 0x8000
Note that both the PTS and the driver use the correct formula, it's just
the documentation that has it wrong.V5.0 gateware releaseDimitris LampridisDimitris Lampridis