From a89b86c7851be11d541d26ee2dba3500a5862ec4 Mon Sep 17 00:00:00 2001 From: Jerry Zhao Date: Fri, 12 May 2023 15:21:27 -0700 Subject: [PATCH] Update HarnessClocking docs --- docs/Advanced-Concepts/Harness-Clocks.rst | 30 ++++++----------------- 1 file changed, 8 insertions(+), 22 deletions(-) diff --git a/docs/Advanced-Concepts/Harness-Clocks.rst b/docs/Advanced-Concepts/Harness-Clocks.rst index e7501cec..f8210b64 100644 --- a/docs/Advanced-Concepts/Harness-Clocks.rst +++ b/docs/Advanced-Concepts/Harness-Clocks.rst @@ -5,22 +5,14 @@ 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. +``ChipTop`` clock ports are driven by ``harnessClockInstantiator.requestClock(freq)``. +``ChipTop`` reset ports are driven by the ``referenceReset()`` function, which is intended to provide an asynchronous reset. -Requests for a harness clock is done by the ``HarnessClockInstantiator`` class in ``generators/chipyard/src/main/scala/harness/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. +The ``HarnessBinder`` s in ``ChipTop`` are clocked by the ``HarnessBinderClockFrequencyKey`` value. The reset is provided as a synchronous reset, sync'd to the clock. + + +Requests for a harness clock is done by the ``HarnessClockInstantiator`` class in ``generators/chipyard/src/main/scala/harness/HarnessClocks.scala``. +Then you can request a clock and syncronized reset at a particular frequency by invoking the ``requestClock`` function. Take the following example: .. literalinclude:: ../../generators/chipyard/src/main/scala/harness/HarnessBinders.scala @@ -28,11 +20,5 @@ Take the following example: :start-after: DOC include start: HarnessClockInstantiatorEx :end-before: DOC include end: HarnessClockInstantiatorEx -Here you can see the ``p(HarnessClockInstantiatorKey)`` is used to request a clock and reset at ``memFreq`` frequency. +Here you can see the ``th.harnessClockInstantiator`` 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.