The AGPL was mostly a placeholder until I determined a better license to
use. TBH I wasn't expecting that anyone would find this repo.
Closes: #1
Signed-off-by: Sean Anderson <seanga2@gmail.com>
We can't actually accept data during reset, so don't assert ready.
Modify the testbench to try to send data while the core is reset, so we
can verify that it doesn't get accepted.
Fixes: 52325f2 ("Add AXI stream replay buffer")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The value of the lfsr does not matter, as long as it keeps ticking. Use
initial instead of resetting it.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Expand a bit on the AXI stream and Wishbone interfaces, documenting the
particular choices we use. The reset signalling could likely also use
some further documentation, but I have deferred that until I have gone
though all the cores and fixed bugs.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The OUI in the PHY ID is "bit-reversed," AKA each byte is bit reversed,
but the overall order is the same. This is a bit more complex than I
initially thought. Fix the mapping, and use a non-zero OUI for testing.
Fixes: d9602b6 ("Add MII management functions")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Document how the LFSR initial values are generated. Also fix several
off-by-one errors (where the documented cycles was not quite right).
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Add a script to calculate the initial value to load into an LFSR based
on how many cycles it should run for. The calculation is based on [1].
It takes advantage of the commutative and properties of exclusive or to
recursively break down the number of steps. This lets us achieve an
O(log(n)) runtime by caching our results. There's an alternative version
of this algoritm which stores bits by value (0x100) instead of position
(8). It's probably easier to do things that way in C or verilog, but
this was more elegant in python. When calculating the number of cycles,
we subtract one to get the number of cycles instead of the number of
steps.
[1] https://www.eevblog.com/forum/projects/algorithm-for-calculating-previous-states-of-lfsr-counters/msg2524395/#msg2524395
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Add an option to register the wishbone busses post-mux. This can help
achieve timing, since the phys are often in different parts of the FPGA.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
If the input and output clock enables are exactly aligned, the elastic
buffer can overflow (as it waits for 2 entries before offering, and
there's a cycle of latency). Increase the size so we don't run into that
situation.
Fixes: b351beb ("Add hub")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This module registers all signals on a wishbone bus. This increases
latency/decreases throughput, but the wishbone cores here are just for
management, so that's not really critical.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
It's convenient to be able to adjust this parameter if the counters ever
end up on the critical path. Support adjusting it from hub.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The counters in this module end up on the critical path a lot. The
counters themselves take 3-4 ns to compute, but routing the increment
signal to the counter eats up a lot of slack. Register the increment signal
for a clock to let it cross the FPGA without affecting the counter timing.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
ack/err can only be combinatorial if data_read is also combinatorial.
I suspect doing that will kill my Fmax, so register ack/err.
Fixes: d9602b6 ("Add MII management functions")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Add a reset synchronizer to ensure synchronous reset release. There is
also a glitch filter to reject spurious resets. It will reject pulses
shorter than 5 ns (or around 1.25 ns per LUT).
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Add a basic bridge for debugging. It's around 50% efficient, but this
could be increased to 66% with the addition of some FIFOs. The limiting
factor is the constant overhead of the request/status bytes. If we used
a wider bus, we could get better efficiency.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Handshaking happens on the rising edge based on the current values of
ready/valid. Fix the current (incorrect) logic. Additionally, modify the
testbench to properly stimulate AXI stream cores. This will catch
several handshaking failures fixed in previous commits.
Fixes: 52325f2 ("Add AXI stream replay buffer")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
AXI stream data is transferred based on the current values of the signals,
not the previous ones. This will cause problems if the other end isn't
valid all the time. Fix this, and amend the testbench to test it.
Fixes: e44d381 ("Add UART transmit module")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The wishbone transfer logic is incorrect. We need to use signals from the
current cycle, not the previous one.
Fixes: 7514231 ("Add AXIS-Wishbone bridge")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Since cocotb/cocotb#2793, writes happen before the clock instead of
after the clock. This breaks the collision test, since we test for
differing behavior over a difference of 1 ns. Fix the failure by
applying an adjustment for newer versions.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
signal_status and must be low for a rising edge before it goes high. At
the moment we depend on ClockEnable to wait for a rising edge. Instead,
wait for a falling edge explicitly. This makes this test less
dependent on how tx_ce is generated.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
AXI stream is transferred exactly on the rising edge of the clock. Use
the current value of the signals for this, instead of past values.
Simulate a slower slave to ensure this is tested.
Fixes: a549fca ("Add UART receive module")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The AXI stream master doesn't cope with slaves that aren't ready all the
time. There are two separate issues: first, the data was only valid for one
cycle. Second, the handshake logic was incorrect. Rectify these, and modify
the testbench to test for this condition.
Fixes: 7514231 ("Add AXIS-Wishbone bridge")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This was defined but left unused. Use it for the width of various
registers.
Fixes: 7514231 ("Add AXIS-Wishbone bridge")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This adds the core of the UART-Wishbone bridge. The protocol has
a variable-length address phase to help reduce overhead. Multiple
in-flight commands are not supported, although this could be resolved
with some FIFOs.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Signals modified by cocotb tasks may not be visible to other tasks on
the same clock cycle. This was causing issues for recv_packet, because
it might not see the same values for ready/valid driven by ClockEnable
that the DUT sees. This was worked around by sampling on the RisingEdge.
However, this can cause recv_packet to miss data. Fix this by using
RisingEdge for ClockEnable, so everything can be sampled on the
FallingEdge.
Fixes: 52325f2 ("Add AXI stream replay buffer")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Add the recieve half of the UART. It's more or less the inverse of the
transmit half, except we manage the state explicitly. I originally did
this in hopes that yosys would recode the FSM, but it doesn't like the
subtraction in the D* states. I left in the async reset anyway since it
reduces the LUT count.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Export recv_packet for use by other testbenches. This is mostly
straightforward, except we need the ability to manually specify when
last should be asserted (to handle replays).
Signed-off-by: Sean Anderson <seanga2@gmail.com>
I join everyone and their mother in creating my own UART. 8n1 only, and 2
baud rates. Accepts AXI-stream.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Icarus verilog complains if you are sensitive to every element in an
array:
rtl/mii_elastic_buffer.v:78: warning: @* is sensitive to all 5 words in array 'data'.
This makes sense if you intend to synthesize this array to a block RAM,
but not really if it's supposed to be registers. Silence this warning.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson