The width of a ternary operator expression is the width of the wider of the
two selectable expression. This means the right side expression of the
tx_data assigment is always 256 bits. This generates an implicit truncating
warning if the tx_data signal itself is only 128 bits.
To avoid this slightly reformulate the expression to yield the correct
width depending on the configuration.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The width of a ternary operator expression is the width of the wider of the
two selectable expression. This means depending on the selected DMA_RATIO
the right side expression of the dma_waddr_rel_s assignment can be up to
three bits wider than the dma_waddr_rel_s signal. This generates an
implicit truncation warning.
Slightly reformulate the expression without the use of the ternary operator
to avoid this warning.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The signal is called adc_clk and not adc_clock. None of the designs is
currently using the signal, so this hasn't been an issue other that it
generates a warning.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Comments starting with the word altera are interpreted by the Altera tools
to be synthesis attribute assignments. In this case this is just a generic
comment though which results in a warning that the synthesis attribute is
unknown.
Slightly reword the comment to avoid this. This is not pretty, but better
than having the false positive warning show up in the log.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some of the standard Quartus components (especially the Merlin cores) generate
quite a few synthesis warnings. Lets assume these are false positives and
disable the warnings.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The PLL frequency must be half of the lane rate and the core clock rate
must be lane rate divided by 40. There is no other option, otherwise things
wont work.
Instead of having to manually specify PLL and core clock frequency derive
them in the transceiver script. This reduces the risk of accidental
misconfiguration.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The clock bridge expects the clock rate to be specified in Hz, but
$m_coreclk_frequency is in MHz. Do the appropriate conversion.
Nothing seems to rely on the clock bridge reporting the correct frequency
at the moment, so this is only a cosmetic change.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
While things seem to work fine with only specifying the the IO standard for
the positive side of differential signals Quartus will issue a warning
about incomplete constraints if the IO standard is not specified for the
the neagtive side as well. To avoid these warnings add the missing
constraints.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fix a copy and paste error and specify the IO_STANDARD for all gpio_bd_i
rather than twice for half of them.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The ad_pps_receiver is instantiated at the top of core.
The rcounter is placed into adc/dac_common registers space, at the
address 0x30 (word aligned).
The interrupt mask is placed into adc/dac_common, at the address 0x04
(word aligned). Because the core has an instance of both modules, the
interrupt masks are OR-ed together.
Add a module to receive 1PPS signal from a GPS module. The module has a
free running counter, which runs on the device's interface clock. The
counter value is latched into a register each time when a 1PPS arrives.
An interrupt signal is also generated in every 1PPS.
Add a check to RX register map to confirm that the ILAS memory registers
return the correct values after the ILAS data has been received.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Lars-Peter Clausen
Rejeesh Kutty
AndreiGrozav
Adrian Costina
Istvan Csomortani
Nick Pillitteri