Add some modules to test with which were previously missing.
Fixes: b68e131 ("Add a basic hub")
Fixes: 0495ae3 ("Add TX MAC (most of it)")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds an example of how to integrate the hub into a design. For the
moment, wishbone is disabled, but I plan to add a uart bridge in the
future.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Create a list of extensions to clean, and then use wildcards to remove
the files. This will make it easier to clean other (nested) directories.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds a basic hub wrapper module which incorperates the core
introduced in b68e131 ("Add a basic hub"). For each port, it
instantiates a phy (itself using a phy_internal wrapper) and an elastic
buffer. A WISHBONE parameter is used to control whether to instantiate a
wishbone interface. When disabled, we just respond to any request with
err. I've ommitted a separate testbench for phy_internal, since it is
much easier to create a smoke test using the hub interface.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds a simple wishbone mux. The idea is that each slave gets its
own address bit. This lends itself to extemely simple address decoding,
but uses up address space quickly. In theory, we could also give larger
addres space to some slaves, but currently lower bits have priority. The
testbench is also very simple. Since everything is combinatorial, we can
determine the outputs from the inputs exactly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Using -s /dev/stdin will add a dependency on it, and /dev/stdin is
always considered newer than the synthesis output. Just use multiple
-p options.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This module will make it easier to observe internal signals which would
otherwise be too short to see, or would trigger too fast to distinguish.
Continuous triggered will cause blinking, so signals which are expected
to be high for a while (e.g. level-based and not edge-based) should not
use this module.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
In order to move data between MIIs without implementing a MAC, we need
some kind of elastic buffer to bring the data into the transmit "clock
(enable) domain." Implement one. It's based on a classic shift-register
FIFO, with the main difference being the MII interfaces and the
elasticity (achieved by delaying asserting RX_DV until we reach the
WATERMARK). We use a register-based buffer because we only need to deal
with an under-/over-flow of 5 or so clocks for a 2000-byte packet. The
per-stage resource increase works out to 6 FFs and 1 LUT, which is
pretty much optimal.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
In addition to PNR-ing for per-module, post-placement simulation, we
also want to be able to do PNR for the purposes of generating a
bitstream. Refactor things a bit so we can (mostly) reuse the same
command line.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds the integrated PMD module to be used with the DP83223. It
contains NRZI en/decoding as well as the I/O interfaces. The rx I/O was
added a while back, and the tx is just the I/O cell.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This implements an AXI stream buffer which allows replaying of the first
portion of each packet. The intent is to simplify the implementation of
CSMA/CD. This requires keeping 56 bytes of data to "replay" (slot time
minus the preamble). After these bytes are transmitted, we can only get
late collisions.
We always read from the buffer, as this simplifies the implementation
compared to some kind of hybrid fifo/skid buffer approach. The primary
design problem faced is in determining when it's OK to overwrite the
first byte in the packet. A naïve approach might be to allow overwriting
whenever the slave reads the last byte. However, in the case of a
54-byte packet, we will still need to allow replaying at this point (in
case there is a collision on the last byte). We can't just wait for
m_axis_ready to go high, because that would violate the AXI stream
protocol. To solve this, the slave must assert the done signal when it
is finished with the packet.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The dependencies for the test target never got updated when some modules
were renamed. Fix this.
Fixes: 494ef2a ("pcs: Split into rx/tx")
Fixes: cf0aed4 ("pmd_io: Rename to pmd_dp83223_rx")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
While manually dumping signals with a macro works OK for standalone
modules, it doesn't work when multiple modules are included. Instead,
create a second top-level module to dump signals. Inspired (once again)
by [1].
[1] https://github.com/steveicarus/iverilog/issues/376#issuecomment-709907692
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Yosys is very verbose, so I usually run it quietly. However, it may be
usefult to review synthesis logs when debugging.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This isn't really useful for most modules (since the placement info is
if they were the only thing instantiated), but it should be a good base.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds a module implementing the the MII management functions (the
MDIO regs). For the moment, we just implement the standard registers.
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>
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>
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>
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>
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>
Sean Anderson