ucb-bar / chipyard

An Agile RISC-V SoC Design Framework with in-order cores, out-of-order cores, accelerators, and more
https://chipyard.readthedocs.io/en/stable/
BSD 3-Clause "New" or "Revised" License
1.59k stars 632 forks source link

Character Count Test Fails #839

Closed jdeters closed 3 years ago

jdeters commented 3 years ago

Impact: software

Tell us about your environment: Chipyard Version: 1.4.0, Hash: 58076cf OS: Linux pop-os 5.8.0-7642-generic #47 1614007149 20.10 82fb226-Ubuntu SMP Tue Feb 23 02:59:01 UTC x86_64 x86_64 x86_64 GNU/Linux Other:

What is the current behavior? The charcount.c test in /tests fails. The call to count_chars() returns 0.

What is the expected behavior? count_chars() should return 3 given the configuration and hard coded offset.

Other information I've attempted to include both the Character Count accelerator and the Accumulator accelerator in my designs using the following code.

class WithRoCCCharacterCount extends Config((site, here, up) => {
  case BuildRoCC => List(
    (p: Parameters) => {
        val counter = LazyModule(new CharacterCountExample(OpcodeSet.custom2)(p))
        counter
    })
})

class WithRoCCAccumulator extends Config((site, here, up) => {
  case BuildRoCC => List(
    (p: Parameters) => {
        val accumulator = LazyModule(new AccumulatorExample(OpcodeSet.custom0, n = 4)(p))
        accumulator
    })
})

I've been able to successfully add the Accumulator example to a RocketConfig and TinyRocketConfig design, both passing the test in accum.c. I have examined the .fir file to confirm that the Character Counter is indeed being generated by Chisel. I wish I could give more info, but I was doing this as an exercise to learn more about RoCC, so my knowledge is still limited.

alfonrod commented 3 years ago

Hi Justin,

I came across the same issue a few days ago. Upon checking the make run-binary-debug VCD output (Verilator simulation), I found that the RoCC accelerator was reading data from uninitialized memory positions, since string is not aligned to the 64-byte boundaries required by the internal logic. In my simulation, a random '\0' was being read before the actual string even showed up, which effectively made the accelerator assume it had reached the end of the input string (and thus it generated a wrong result).

I just created a pull request (#853) with the changes I made in the software application (now it works as expected). I hope it helps.

jerryz123 commented 3 years ago

This was merged.