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

Grady Chen gchen at viosoft.com
Thu Jul 13 05:23:12 BST 2017


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
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> 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