[lowrisc-dev] Untethered lowRISC: run bbl using Verilator

Wei Song ws327 at cam.ac.uk
Thu Jul 13 11:27:39 BST 2017


Hello Grady,

Right now there is no instruction to deliberately flush the data cache.
Some discussion from the RISC-V maillist can be found here:
https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa-dev/XD_QkBH7HEk/Ag18X7IlCAAJ
https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa-dev/Bo0nb26fguM/dhBQOaMBBAAJ
https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa-dev/EYAG7yQRnaQ/hc5uEOwUBQAJ

In the unthether-v0.2 of lowRISC, we did support bypassing the whole 
cache hierarchy by mapping the memory to I/O space at run-time.
However, this behaviour is no longer supported and not recommended.
The reason for us to do so was the RISC-V GCC had insufficient support 
for program relocation at that time.
As a result, the bootloader and the kernel were located at the same 
physical address space.

As I said, I strongly recommend you not to go for the cache bypass 
direction.

The Verilog you pointed out controls the address mapping of the DDR 
memory after LLC.
It has little to do with the run-time cache bypassing as Verilog 
parameters are a compile time mechanism.

If we can understand more of your use case, we might provide some 
suggestions.

I guess if what you want is a processor to access a memory without any 
cache, you can configure the latest Rocket-chip from the 
freechipsproject with a scratch pad replacing the L1 cache. In this 
case, everything is controlled by software.
However, that is not something we support right now.

Best regards,
Wei


On 13/07/2017 05:23, Grady Chen wrote:
> Hi Wei,
>
> Thank you for your explanation.
> Is there a way to flush data cache? I meant to add some code on BBL.
> or how to bypass data cache for behaviour dram?
> Supposedly, I will need to modify the following parameters in 
> chip_top.sv <http://chip_top.sv> to bypass data cache, right?
>    // crossbar to merge memory and IO to the behaviour dram
>    nasti_crossbar
>      #(
>        .N_INPUT    ( 2                  ),
>        .N_OUTPUT   ( 1                  ),
>        .IB_DEPTH   ( 3                  ),
>        .OB_DEPTH   ( 3                  ),
>        .W_MAX      ( 4                  ),
>        .R_MAX      ( 4                  ),
>        .ID_WIDTH   ( `MEM_TAG_WIDTH + 1 ),
>        .ADDR_WIDTH ( `PADDR_WIDTH       ),
>        .DATA_WIDTH ( `MEM_DAT_WIDTH     ),
>        .BASE0      ( 0                  ),
>        .MASK0      ( 32'hffffffff       )
>        )
>    mem_crossbar
>      (
>       .*,
>       .s ( mem_io_nasti  ),
>       .m ( ram_nasti   )
>       );
>
> --
> Thanks,
> Grady Chen
>
> On Wed, Jul 12, 2017 at 5:44 PM, Wei Song <ws327 at cam.ac.uk 
> <mailto:ws327 at cam.ac.uk>> wrote:
>
>     Hello Grady,
>
>     When there is a write-allocated data cache in the system, a store
>     operation does not cause a write transaction to the memory but
>     usually a read transaction. The write is handled in the
>     write-allocated cache. If the cache line is missed in cache, it is
>     fetched from memory, that is why you see the read transaction.
>
>     Write transactions happens when there is a replacement occurs in
>     the last level cache, and the dirty cache line is written back to
>     memory before a new one can be fetched.
>
>     That is to say, you need more memory operations to trigger a
>     writeback to see any write transactions to memory.
>
>     BTW, the lowRISC version you are using is old. For debug-v0.3 and
>     the latest minion-v0.4, +load= accepts an elf executable and the
>     elf2hex step is no longer necessary.
>
>     Best regards,
>     Wei
>
>
>     On 12/07/2017 08:27, Grady Chen wrote:
>
>         Hi All,
>
>         For some reason, I am running bbl using Verilator.
>         The following are my steps:
>
>         grady at riscv:~/lowrisc-chip/riscv-tools/riscv-pk$ elf2hex 16
>         8192 build/bbl
>
>             ../../vsim/bbl.hex
>
>         grady at riscv:~/lowrisc-chip/vsim$ ./DefaultConfig-sim-debug +vcd
>         +vcd_name=bbl.vcd +max-cycles=100000000 +load=bbl.hex |
>         spike-dasm > bbl.log
>
>         Core 0 get unsolved tohost code 8cb0 *# This is what I expected.*
>
>         grady at riscv:~/untether/lowrisc-chip/vsim$ grep request bbl.log
>
>         memory read request: 1 @ 200
>
>         memory read request: 1 @ 240
>
>         memory read request: 1 @ 280
>
>         memory read request: 1 @ 2c80
>
>         memory read request: 1 @ be80
>
>         memory read request: 2 @ bfc0
>
>         memory read request: 1 @ 2cc0
>
>         memory read request: 1 @ 2d00
>
>         ......
>
>
>         There is only the memory read request but no memory write
>         request. Seems
>         not right.
>         Any one know how to make SD assembly instruction leads memory
>         write
>         transaction?
>
>         --
>         Thanks,
>         Grady Chen
>
>
>



More information about the lowrisc-dev mailing list