When building a design with PicoRV32 we end up with multiple top-level
modules and Verilator becomes confused as to which is the right one.
This change ensures the dut.v generated by the sim build process has
it's top-level name set to 'dut' and that verilator is invoked with this
name.
This is needed to specify timing constraints on some Lattice Diamond
library specials, like the EHXPLLL.
To keep backwards compatibility we allow the directive to still be a
single string. If it's not, we assume it's an iterable.
Well, at least PicoRV32-specific. Turns out there is no RISC-V
specification for simple microcontroller-like interrupts, so PicoRV32
implements its' own based on custom opcodes.
It's somewhat esoteric, and for example doesn't offer a global interrupt
enable/disable. For this we implement a thin wrapper in assembly and
then expose it via a few helpers in irq.h.
Swaps hard coded PORT_OUT in tftp.c for parameter on the tftp_get()
and tftp_put() functions. Allow TFTP_SERVER_PORT used by BIOS to be
set at compile time from compiler defines.
Otherwise you can't override the UART with another UART, you get an
error like;
```
File "/home/tansell/github/timvideos/HDMI2USB-litex-firmware/third_party/litex/litex/soc/integration/soc_core.py", line 176, in __init__
interrupt, mod_name, interrupt_rmap[interrupt]))
AssertionError: Interrupt vector conflict for IRQ 2, user defined uart conflicts with SoC inbuilt uart
```
Increases the initial delay step into the valid read window as
with the original delay I was not getting out of the noisy
transition window, as evidenced by seeing read delay windows
of only 8 LSB ~10% of the time, leading to failing memory
tests
It is useful to support slightly different variants of the CPU
configurations. This adds a "cpu_variant" option.
For the mor1k we now have the default mor1k configuration and the
"linux" variant which enables the features needed for Linux support on
the mor1k.
Currently there are no variants for the lm32, but we will likely add a
"tiny" variant for usage on the iCE40.
Previously we would wait the same number of iterations as it took us to
receive the first data block after sending the request. When using the
build in tftp server in qemu, the first wait loop succeeds (and thus
breaks when 'i' is still 0.
Since the counter was never reset between the first and second data
block, under qemu the tftp_get call would fail before ever checking if
we have received the second block of data.
Now that we initialise 'i' to 12M, we ensure that we wait the same
amount of time for the second data block as it previously did for the
third (and subsequent) blocks.
Sergiusz Bazanski
Florent Kermarrec
William D. Jones
Tim Ansell
Ewen McNeill
Felix Held
Chris Ballance
Tim 'mithro' Ansell
Greg Darke