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