Before;
```
"/usr/local/lib/python3.5/dist-packages/litex-0.1-py3.5.egg/litex/soc/integration/soc_core.py",
line 258, in get_csr_dev_address
return self.csr_map[name]
KeyError: 'core'
```
Now;
```
Traceback (most recent call last):
File "XXXX/github/enjoy-digital/litex/litex/soc/integration/soc_core.py", line 259, in get_csr_dev_address
return self.csr_map[name]
KeyError: 'ddrphy'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
...
File "XXXX/github/enjoy-digital/litex/litex/soc/interconnect/csr_bus.py", line 199, in scan
mapaddr = self.address_map(name, None)
File "XXXX/github/enjoy-digital/litex/litex/soc/integration/soc_core.py", line 269, in get_csr_dev_address
) from e
RuntimeError: Unable to find ddrphy in your SoC's csr address map.
Check BaseSoC.csr_map in XXXX/github/enjoy-digital/litex/litex/boards/targets/arty.py
Found l2_cache, timer0, ddrphy2, buttons, sdram, identifier_mem, uart, uart_phy, leds, crg in the csr_map
```
This change introduces an AXI4Lite to CSR bridge. Hopefully it will
become extended in the future with full AXI support and more structures
(Wishbone bridge, interconnect, ...). For now this will do.
The bridge has been simulated (and includes an FHDL testbench) and
tested in hardware (on a Zynq 7020).
When building multi-source files the toolchain gets confused as to which
module is top-level. This ensures that the build_name of the design is
selected.
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.
Tim 'mithro' Ansell
enjoy-digital
William D. Jones
Sergiusz Bazanski
Paul Schulz