[Libre-soc-dev] daily kan-ban update 17feb2021

[Luke Kenneth Casson Leighton]

On Wednesday, February 17, 2021, Tobias Platen <libre-soc at platen-software.de>
wrote:
> Verified that running ld/st instructions drives the TestMemory on
wishbone bus
> of the dcache.

that's absolutely fantastic to hear.

> Next step is filling the wishbone memory with a pagetable,

right.  there is a unit test which does this.  let me find it.  cole
implemented it.

right, here it is:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/test/test_mmu_dcache.py;h=dac90d1628e4ad0ed14fe4119c28eb53d520ec88;hb=5ddbf2700780ecada5285b722025452641a28b0f

basically that is *two* simulation processes, not the normal "one only".

the 2nd one responds to data requests over wishbone, not from an actual
Memory but instead by "faking" wishbone read requests using a dictionary to
look up requests.

this dictionary can be pre-loaded with the types of pagetable entries you
want, at any address size or location.

the problem with having a large enough nmigen Memory to hold large
addresses is that it will run your system out of physical RAM somewhere
about 15 hours of failing to start.

the only fly in the ointment here is that all the unit tests so far assume
a tiny (64 word) Memory for data and instruction.

setup_memory is what gets called.

the data memory needs to be made optional for the mmu test, replaced with
this:


 sim.add_sync_process(wrap(wb_get(dcache, default_mem, "DCACHE")))

however the moment that is done test_issuer.py will fail so you will need
to create a test_issuer_mmu.py that does things differently.

then as well through the Config class parameters you can safely expand the
data wishbone bus address width to a full 64 bit, safe in the knowledge
that the unit tests won't try to allocate a nmigen Memory of size 2^64.


l.








-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68