FMC ADC 100M 14b 4cha - Gateware issueshttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues2019-08-05T10:49:09Zhttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/38Simulation: add ADC functional model2019-08-05T10:49:09ZDimitris LampridisSimulation: add ADC functional modelIdeally, we should provide an ADC functional model capable of providing
realistic inputs to our module, and ADC core test and verification
class, which we should use then in both the SPEC and SVEC testbenches.
Furthermore, these testbenches should be used to test all features of
the ADC core and provide clear pass/fail return values.https://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 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/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/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/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/6Generalize timetag core and move to general-cores2019-08-05T09:33:16ZDimitris LampridisGeneralize timetag core and move to general-coresThe timetag core currently is tightly coupled to the ADC core.
It should be generalized to take the form of a time-keeping module, with
the possibility to generate interrupts (alarms) on predefined moments.Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/7Update testbench2019-08-05T10:49:51ZDimitris LampridisUpdate testbenchCurrent simulation testbenches are very limited (and fragmented).
Ideally, we should provide an ADC functional model capable of providing
realistic inputs to our module, and ADC core test and verification
class, which we should use then in both the SPEC and SVEC testbenches.
Furthermore, these testbenches should be used to test all features of
the ADC core and provide clear pass/fail return values.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/8Replace hardware trigger enable logic2019-08-05T10:45:50ZDimitris LampridisReplace hardware trigger enable logicCurrently only one hardware trigger can be selected at a time, which can
be logically OR'ed with the software trigger.
It makes much more sense to have a logical OR of all possible trigger
sources, including:
- Internal thresholds per channel
- External trigger in
- Time trigger
- WR trigger
- ...V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://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/10hdl - switch to 125MHz clock source2019-08-05T09:58:32ZDimitris Lampridishdl - switch to 125MHz clock sourceIn view of the addition of White Rabbit support to the FMC-ADC, switch
to a 125MHz clock source in order to free the 20MHz VCXO clock (which
will be used for the DMTD clock input of WRPC).V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/11Discipline the ADC sampling clock with WR2019-08-05T10:50:32ZDimitris LampridisDiscipline the ADC sampling clock with WRDiscipline the 100MHz sampling clock with WR, in order to have multiple
ADCs with synchonized sampling.https://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/12Implement a basic WR trigger message2019-08-05T09:52:49ZDimitris LampridisImplement a basic WR trigger messageProvide functionality to support a basic WR message which will allow
triggers to be translated to WR messages and vice versa.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/13Add extra trigger input from FPGA logic2019-08-05T09:52:38ZDimitris LampridisAdd extra trigger input from FPGA logicAdd one new trigger source, coming from the FPGA logic.
This will be used for example via White Rabbit in order to allow WR
messages to be translated to triggers.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/14Add option to tag based on WR time2019-08-05T09:52:31ZDimitris LampridisAdd option to tag based on WR timeWith WR support added (\#1289), add the possibility to use the timing
interface of the WR PTP core to tag the acquisitions.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/15Add "trigger on time" functionality2019-08-05T10:43:11ZDimitris LampridisAdd "trigger on time" functionalityAdd the possibility to generate another "software" trigger signal, at a
specific moment in time.
Currently, the FMC-ADC device driver initializes the counters in the
Time-tag core with the UNIX POSIX time from the host computer (eg. FEC).
It should be possible for the driver to program the gateware to generate
a soft trigger when the counters in the time-tag reach a certain value.
This is also a step towards being able to trigger in a distributed way
several FMC-ADC cards synchronized over White Rabbit.V5.0 gateware releaseDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/16hdl: dpram0 erroneously instantiates dual clock memory2019-02-12T11:15:53ZDimitris Lampridishdl: dpram0 erroneously instantiates dual clock memoryIn the adc-core design, dpram0 (used in multi-shot mode) instantiates a
dual port on-chip memory with two separate clocks (one per port), even
though the same clock signal (sys\_clk\_125) is used on both ports.
dpram0 should be converted to single clock and the second clock input
can be left open or driven to ground.
dpram1 is correctly instantiated as single clock.Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/17Clean up and update simulations and testbenches2019-02-12T11:15:54ZDimitris LampridisClean up and update simulations and testbenchesSimulations have fallen behind with respect to the HDL design files.
Update them and make sure that they run and produce results.Dimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/18Clean up and update build process2019-02-12T11:15:54ZDimitris LampridisClean up and update build process1\. Make use of hdlmake v2.1
2\. For git modules in Manifest.py, point to specific git commits and
not at branch heads
3\. remove and (git)ignore all hdlmake-generated filesDimitris LampridisDimitris Lampridishttps://ohwr.org/project/fmc-adc-100m14b4cha-gw/issues/19Use 200MHz clock for WB bus from ddr-ctrl to gn4124-core2019-08-05T10:55:18ZDimitris LampridisUse 200MHz clock for WB bus from ddr-ctrl to gn4124-coreWas listed in "missing features" of v4.0 gateware manual.Dimitris LampridisDimitris Lampridis