8.7. Creating Clocks in the Test Harness¶
Chipyard currently allows the SoC design (everything under ChipTop
) to
have independent clock domains through diplomacy.
This implies that some reference clock enters the ChipTop
and then is divided down into
separate clock domains.
From the perspective of the TestHarness
module, the ChipTop
clock and reset is
provided from a clock and reset called buildtopClock
and buildtopReset
.
In the default case, this buildtopClock
and buildtopReset
is directly wired to the
clock and reset IO’s of the TestHarness
module.
However, the TestHarness
has the ability to generate a standalone clock and reset signal
that is separate from the reference clock/reset of ChipTop
.
This allows harness components (including harness binders) the ability to “request” a clock
for a new clock domain.
This is useful for simulating systems in which modules in the harness have independent clock domains
from the DUT.
Requests for a harness clock is done by the HarnessClockInstantiator
class in generators/chipyard/src/main/scala/TestHarness.scala
.
This class is accessed in harness components by referencing the Rocket Chip parameters key p(HarnessClockInstantiatorKey)
.
Then you can request a clock and syncronized reset at a particular frequency by invoking the requestClockBundle
function.
Take the following example:
withClockAndReset(th.buildtopClock, th.buildtopReset) {
val memOverSerialTLClockBundle = p(HarnessClockInstantiatorKey).requestClockBundle("mem_over_serial_tl_clock", memFreq)
val serial_bits = SerialAdapter.asyncQueue(port, th.buildtopClock, th.buildtopReset)
val harnessMultiClockAXIRAM = SerialAdapter.connectHarnessMultiClockAXIRAM(
system.serdesser.get,
serial_bits,
memOverSerialTLClockBundle,
th.buildtopReset)
Here you can see the p(HarnessClockInstantiatorKey)
is used to request a clock and reset at memFreq
frequency.
Note
In the case that the reference clock entering ChipTop
is not the overall reference clock of the simulation
(i.e. the clock/reset coming into the TestHarness
module), the buildtopClock
and buildtopReset
can
differ from the implicit TestHarness
clock and reset. For example, if the ChipTop
reference is 500MHz but an
extra harness clock is requested at 1GHz, the TestHarness
implicit clock/reset will be at 1GHz while the buildtopClock
and buildtopReset
will be at 500MHz.