Timing-aware ISS model

[chili-chips-ba]

With ISS as one abstraction level option in Wireguard-FPGA sim TB, we are looking for it to be timing-aware. And so in a structured, plug-and-play way.

This mean that, while it does not need to be fully cycle-accurate, but only "close enough", the ISS should also allow easy swaps and user-accessible adjustments of its timing model. This article presents what is currently available. What seems to be missing is:

• ability to specify clock frequency
• standardized method for customizing timing parameters to any given RISC-V CPU, possibly with a worked out library of a few popular options*
• timing model of caches, possibly with following two options:

  • Statistical -- Random spread from 0 to a given n, where n can be set by user
  • Functional -- Configurable for size of lines, number of ways and number of sets

    ---

    (*) 1) Ibex timing model.

2) PicoRV32 timing model should use the following settings:

• 5 cycles for Load and Store
• 4 cycles for everything else That's for on-chip TCM as it currently does not have any Caching option.

3) eduBOS5 info card shows that in its standard "2-stage" config, the core consumes:

• 3 cycles for Load and Store
• 2 cycles for everything else

eduBOS5 "3-stage" pipeline option adds 1 cycle to everything. It in return allows faster clock.

[wyvernSemi]

Why is there a need to specify clock frequency when using the ISS for simulation? All the units for timing are in cycles, which is what the ISS/co-sim synchronisation uses. Whatever clock speed it (or a logic implementation) is run at, it will still take that many cycles. The frequency only affects the generation of the clock in the test bench (and the synthesis constraints, of course).

The ISS already has a really simple method to update seven defined categories of timing. Maybe an external class can be defined with a set of constants, one set for each supported implementation, and a method to update the ISS, with the timing set selected at construction.

The cache timing (as in my LatticMico32 ISS) is actually external to the ISS, and done in the number of reported wait states returned by the external memory access callback function. So this can be made to be one of a cached or non-cached wait state values. The current WireGuard ISS integration code does not have a cache model, but the LatticeMico32 code should be adaptable.

[chili-chips-ba]

Why is there a need to specify clock frequency when using the ISS for simulation?

You are right, there isn't. It's simply the matter of getting used to the fact that the ISS is in this case merely a VProc app. And, the VProc has an input for bringing in whatever clock the actual CPU is running at.

Traditionally, the Instruction Set Simulators have no notion of time, or clock. But, we are parting away with traditions 😉.

---

an external class can be defined with a set of constants, one set for each supported implementation, and a method to update the ISS, with the timing set selected at construction.

Yes, that would do 👍

---

cache timing (as in my LatticMico32 ISS) is actually external to the ISS

Since Ibex, our front-runner RISC-V core, includes Caches as an internal config option, we are good as long as the Cache model is contained within VProc