CSR scans run *before* do_finalize() is called. This is a silent
failure: The signals get generated but the CSR is not in the csr.json
file or the generated verilog.
pre_finalize() is a function that must be called when all masters are
added to the module. This will generate the CSR before finalization,
(hopefully) ensuring that the CSR is added to the CSR bus.
I need to figure out a way to excise manual use of the CSR bus from the
design. Future options may include having a PreemptiveInterface
control module sitting in front of the PreemptiveInterfaces that exposes
the control lines as a Wishbone register.
New master buses can be added to PreemptiveInterface throughout the
code, simplifying the main SoC code. This removes the requirement that
the amount of masters to the interface needs to be known at
instantiation time.
1. Started writing a lot of documentation on how Upsilon is
structured. This will replace the very outdated documentation.
2. Fixed parameter access and writing. This is also a more generic
interface that can be used for Pico CPUs that implement different
routines.
1. Update LiteX to 2023.12. This update adds wishbone bus addressing
modes. Before this update, all wishbone buses used word addressing.
For example, 0x0 mapped to word 0, 0x0 mapped to word 1, etc. This
caused problems with the PicoRV32 and other modules, which are byte
addressed.
2. Use adapter to convert between byte and word addressing. The SRAM is
word addressed. The PicoRV32 shifts the address down by two bits to
address the correct word. The PicoRV32 core seems to expect this.
3. Add debug register output. This is not working yet.
4. Use LiteX PicoRV32 wishbone adapter instead of PicoRV32 default. This
seems to be simpler (combinatorial not synchronous).
5. Add some documentation.
6. Seperate config to new config file.
The PicoRV32 SoC bus generator conflicts with the main SoC bus
generator, which causes the address locations in the generated verilog file
to be different from the set locations. This code uses custom region
classes in soc.py and the Decoder class directly, which is similar to
what the finalization of the SoC class uses, and is based on the LiteEth
code does.
1) The PicoRV32 bus was not generated correctly. Running "finalize" on
the bus, which is what the SoC does, does not generate the bus logic
correctly. I don't know if this is a bug or if the SoC bus generator is
only meant to be used in the main SoC.
Currently the bus logic is copied from the LiteX finalize code.
2) Add test micropython code to load code.
3) Removed BRAM. The Wishbone cache was messing with the direct
implementation of the BRAM because the BRAM did not implement all the
bus features correctly. LiteX has a Wishbone "SRAM" module, and despite
it's name it can also generate BRAM if there are available BRAM. This is
how the ROM and the startup RAM are implemented. The PicoRV32 ram
is now using this SRAM.
I think LiteX's SoCIORegions are reserved regions. Non-cached regions
are then placed inside these reserved regions. Each module also has
a "do_finalize" method that runs at code generation.
The previous code did not properly assign all values on all cases,
and did not properly assign values (master interfaces, which are
poorly named because they are the interfaces to the master, connect
to the slave lines directly in the interconnect)
LiteX has some distinction between SoCIORegions and SoCRegions that
I don't quite get. SoCRegion has to be cached, SoCIORegion is not
cached. LiteX (Migen?) also does not allow you to reach into
submodules to read values.
Peter McGoron
Adam Mooers