The specification requires that the MII be isolated before the STA
clears the BMCR.ISOLATE bit. Add support for this to the MII I/O
modules.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This better reflects the function of the module (interfacing the
transciever via the I/O pins), and fits better with the naming scheme
used for other I/O modules.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The actitecture is overall fairly similar to the receive interface,
except that the directions are mostly different. The timing is a bit
easier, since we control the ce signal. Data is sampled one clock before
tx_clk goes high, which is the earliest that it is guarantee'd to be
valid. We could get an extra half-clock by having tx_clk go high at the
negedge of clk, but it's unnecessary at the moment.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This generates the appropriate output for MII receive signals. Because
we don't have a clock synchronous to the recieved data, we may
occasionally have some cycles which are 32 ns or 48 ns long (instead of
the nominal 40 ns). This distorts the duty cycle to 38% or 58%,
respectively, which is within the specified 35% to 65%. This does change
the frequency to either 31 MHz or 21 MHz, respectively, which *is* a
violation of the spec. This could be avoided by introducing a FIFO to
smooth out any variations in jitter, like what RMII does.
The generation of rx_clk is a bit tricky. We can use a combinatorial
signal for the posedge, since that is what the rest of the logic is
referenced to, However, we need to register the negedge to prevent an
early (or late) ce from modifying the duty cycle.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
If we get very lucky, the descrambler can lock after only 28 bits
(the size of the idle counter). Take this scenario into account when
deciding on the offset.
Fixes: 12a4678 ("Add (de)scrambling support")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This module implements the I/O portion of the MII management interface.
The output is delayed by 2 clocks in order to ensure that the external
level shifter has switched directions before we drive it. The latency
increase (around 16 ns) is not consequential, since we have around 300
ns from the rising edge of MDC before MDIO has to be valid.
On the other end, the timing requirements for MDIO driven by the STA are
very lenient (for them); MDIO only has to be valid for 10 ns on either
side of the rising edge of MDC. This effectively means we must sample
MDIO synchronously to MDC (not easy with nextpnr), or oversample by 50x.
Fortunately, we have a 125 MHz clock which the rest of the phty runs off
of. However, this basically makes 10x oversampling with the MII clock
impossible.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This module implements the MII management interface ("MDIO"), and
translates frames into classic wishbone reads/writes. We use a
"state_counter" to keep track of how many additional bits we expect to
recieve before continuing on to the next field in the frame. We require
a preamble because it prevents ambiguity, and omitting it doesn't seem
to be very popular (seeing as it was removed for c45). Generally, even
if we find an error in the frame, we still procede through the states as
usual. This prevents any spurious reads/writes caused by misinterpreting
an unaligned data stream.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Several interfaces have ce signals. Create a common function for driving
these signals, similar to the Clock function.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds support for (de)scrambling as described in X3.263. The
scrambler is fairly straightforward. Because we only have to recognize
idles, and because the timing constraints are more relaxed (than e.g.
the PCS), we can make several simplifications not found in other
designs (e.g. X3.263 Annex G or DP83222).
First, we can reuse the same register for the lfsr as for the input
ciphertext. This is because we only need to record the scrambled data
when we are unlocked, and we can easily recover the unscrambled data
just by an inversion (as opposed to needing to align with /H/ etc).
Second, it is not critical what the exact thresholds are for locking an
unlocking, as long as certain minimums are met. This allows us to ignore
edge cases, such as if we have data=10 and valid=2. Without these
relaxed constraints, we would need to special-case this input to ensure
we didn't miss the last necessary consecutive idle. But instead we just
set the threshold such that one missed bit does not matter.
To support easier testing, a test input may be used to cause the
descramble to become unlocked after only 5us, instead of the mandated
361. This makes simulation go much faster.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Instead of using a wildcard, import used members explicitly. This is
more tenable now that we don't have to import all the valids
separately.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Parametrizing a test over different methods of generating valid data
will be useful for other tests as well. Refactor it out. We have to bind
valids early in with_valids.test, otherwise we will end up binding
with_valids.valid by reference (causing all tests to use saw_valid).
Signed-off-by: Sean Anderson <seanga2@gmail.com>
At the end of the bitstream, we might not have enough bits for valid=2.
If we don't change it to valid=1, instead of marking an X as valid.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
24.6.1 requires that CRS goes high fewer than 4 cycles after TX_EN goes
high. This means we need to assert tx when we enter then START_J state,
not when we actually transmit a /J/. This also has the upside of
simplifying the logic a bit.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Using -O allows grouping job output, which is helpful when output would
otherwise be interleaved (such as when running tests). However, it also
means that there is no tty attached to the job, resulting in cocotb
automatically turning off color. Detect whether we have a tty during the
parsing phase, and force color output if we do. Technically this should
probably take into account the existing value of COCOTB_ANSI_OUTPUT, but
I don't use it normally.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
We will need this in every verilog file, so consolidate things a bit. In
terms of timescale, we need to modify the post-synthesis verilog
generation a bit in order to avoid the module's timecale being
inadverdently overwritten.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
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>
The PCS state machine is evaluated every cycle, but its outputs are only
registers when the rx_bits module indicates. However, the flush signal
is not registered and is instead combinatorial. Although it's OK to
evaluate the other outputs every cycle, we should only indicate if we
are actually going to change state.
Fixes: d351291 ("Initial commit")
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 support for running testbenches post-synethesis. Simulating
this way should (hopefully) catch most synthesis/simulation mismatches.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds a levels parameter to DUMP, allowing dumping just the
top-level signals, instead of the whole hierarchy. This is helpful for
post-synthesis simulation, where all sub-modules are primitives (with
their inputs and outputs already available at the top level).
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>
The data yielded by the PMD is not really valid until it has made its
way through the pipeline. Delay it until the data is valid. As a side
effect, this should also eliminate any metastability. This is not
necessary for real hardware, but it allows us to to post-synthesis
simulation (where we can't reach in and probe the internal valid
signal).
Additionally, ensure that the state is known by resetting it when we
don't have a signal.
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>
There were two unused variables; remove them. The wrong type of
assignments were used; fix them.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Without this state, receiving would immediately go low. However, figure
24-11 shows that receiving should go low only after an additional code
group (the second idle) is received.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
When the PMA has no new data for us, idle should be determined based on
raw_bits[11:2]. However, we just calculated that last cycle, so we can
reuse it.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
There's no strict requirement for us to handle linke failures immediately.
The PMA's link timer will ensure the signal stays low, so we don't have to
worry about missing it. This fixes some strange Xs during initialization.
Fixes: d351291 ("Initial commit")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson