wu-arch/chipyard
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Update HarnessClocking docs

Browse Source
This commit is contained in:
Jerry Zhao
2023-05-12 15:21:27 -07:00
parent b8e95e0305
commit a89b86c785
1 changed files with 8 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/Advanced-Concepts/Harness-Clocks.rst
View File

@@ -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.