The PMA also has to deal with "recoverd bitstreams" (that is, inputs which
can have 0, 1, or 2 valid bits). Export the core of pcs_send_codes into its
own function, as it is useful for generating these signals.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Since 0153975 ("tb: pcs: Send packet spacing packets immediately"), we
have never allowed pma_data_rx to remain idle. There's no need to supply
a default value.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
If we get a run of 1s (or 0s) at the start of the stream, it may take a
while for us to align. Increase the alignment range. Additionally, from
testing, it appears that negative ranges are never used. Just start at
0.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
In the recieve tests, the harness often has a choice of how fast to feed
data to the module. Up to this point, we have always used the same
strategy (typically random), even when multiple strategies were used
when writing the test. Add parametrization to test different strategies
in each test run. The timing decorator is taken from the cocotb source,
since we can't pass parameters to cocotb.test directly any more.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds a helper for printing input/output serial data. Early errors
might not have had the offending bits printed, since slicing
doesn't work with negative indices.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
valid is an internal signal which isn't available in post-synthesis
simulation. Use signal_status instead, which is externally available.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
We set this signal for debugging purposes, so don't die if it's absent
(such as in a post-synthesis simulation).
Signed-off-by: Sean Anderson <seanga2@gmail.com>
To make sure that pmd.signal_status comes up at the right time, keep
signal_detect low at the start of simulation. We don't need to set
pmd.rx, because X is the default value (or rather Z is, but it's the
same for our purposes).
Fixes: 1d65661 ("Add pmd")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Ensure all inputs are initialized before starting the clocks. This
avoids any problems which might occur due to everything being
initialized at once.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Instead of calculating clock periods based on the desired frequncy,
specify the periods diretly. This silences the following kind of error
caused by floating point rounding:
Unable to accurately represent 8000.000000000001(sec) with the simulator precision of 1e-12
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson