Generating a Rocket32s1 with smaller cache

[cassebas]

Hi Eugene,
Great project! I have a question about generating a small rocket core with even smaller cache than the standard one.

I added the following to src/main/scala/rocket.scala:

/* Small core with 1KiB cache  */
class Rocket32s1_extrasmallcache extends Config(
  new WithNBreakpoints(8) ++
  new WithNSmallCores(1)  ++
  new WithL1ICacheSets(16) ++
  new WithL1ICacheWays(1) ++
  new WithL1DCacheSets(16) ++
  new WithL1DCacheWays(1) ++
  new WithRV32            ++
  new Rocket32BaseConfig)

and then I did make CONFIG=rocket32s1_extrasmallcache BOARD=genesys2 bitstream

The thing is, I tried several benchmarks and compared it with the 'normal' Rocket32s1, and the results (number of cycles) remains the same. Which is suspicious to me. Do you know if my approach to generating a core with smaller cache is right? Is there any method or tool that I could use to verify the resulting cache size?

Thnx!

[eugene-tarassov]

I believe you need to put cache parameters before new WithNSmallCores(1) ++
Alternatively you can define your own class instead of WithNSmallCores - this is the class that sets cache parameters.

Is there any method or tool that I could use to verify the resulting cache size?

Yes, just look into generated device tree file - system.dts

[cassebas]

Thank you! That was it. I was able to generate small cores with other cache sizes.
However, I can't seem to connect to the target when I use a core with a modified cache size.

With the 'normal' WithNSmallCores (unmodified caches) I get from the UART:

RISC-V 32, Boot ROM V3.7
Cannot access SD: Timeout
Cannot mount SD: Disk not ready

RISC-V 32, Boot ROM V3.7
adpcm_dec start
adpcm_dec stop
adpcm_dec cycles cold cache 8081
adpcm_dec cycles warm cache 5973

(This is a benchmark from tacle-bench, which I compiled with riscv toolchain and added some measurements.)

xsdb gives me:

xsdb% connect
tcfchan#0
xsdb% target
  1  xc7k325t
     2  RISC-V
        3  Hart #0 (Running)
xsdb%

But when I program my core with modified cache, I do get the output from the boot rom. But I cannot connect to the target, the Hart is not listed.

xsdb% connect
tcfchan#0
xsdb% target
  1  xc7k325t
xsdb%

Do you have any ideas?

[cassebas]

I have now tried to boot my (bare-metal) program from the SD-card. Since I used the mk-sd-card script, it was easier to boot from a 64-bit bootloader/program, so I moved to the Rocket64b1 core. When I boot from the SD-card, my program always runs fine.

But when using xsdb, I can only connect to the Hart #0 on a core with unmodified cache sizes. Again, when I modify the cache size (both ICache and DCache, e.g. 32K or 64K) then the Hart #0 (Running) won't show.

Hope you have some pointers on how to investigate this. Using xsdb is a lot more friendly than the SD card :-)

[eugene-tarassov]

the Hart #0 (Running) won't show

I cannot reproduce. I tried this config:

class Rocket32s1 extends Config(
  new WithNBreakpoints(8) ++
  new WithL1ICacheSets(16) ++
  new WithL1ICacheWays(1) ++
  new WithL1DCacheSets(16) ++
  new WithL1DCacheWays(1) ++
  new WithNSmallCores(1)  ++
  new WithRV32            ++
  new Rocket32BaseConfig)

xsdb appears working fine.
What version of Vitis do you use?

[cassebas]

I use Vitis 2022.2. I must say I don't use Ubuntu, but Archlinux.

I decided to try to build the bitstreams on another machine, and they seem to be running fine.

A difference between the two machines was that on the one that wasn't building OK, I had a separate sbt and scala installed. I removed them, and now this machine also seems to build OK.

I'm still not sure whether this was the solution. The cores that I have built today do run my benchmarks, but strangely I don't see the bootrom printing messages anymore.

Is it safe to follow your most recent master branch? Or should I switch to one of your releases?

Thanks for your help!

[eugene-tarassov]

Vitis 2022.2 should be OK.
Yes, it is safe to follow the master branch.
I have test automation running continuously, and I push to github only when tests are passing.

but strangely I don't see the bootrom printing messages anymore

Most likely it is issue with serial port setup on your host machine.
I have seen a lot of bugs in USB/Serial drivers on both Linux and Windows.