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

Reverse documentation on breaking prereqs

Browse Source
This commit is contained in:
abejgonzalez
2021-10-25 22:29:38 -07:00
parent b7fd1ffae2
commit 1d3d8e4e01
3 changed files with 16 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/Advanced-Concepts/Debugging-RTL.rst
View File

@@ -22,8 +22,8 @@ make target. For example:
make CONFIG=CustomConfig debug make CONFIG=CustomConfig debug
The ``run-binary-debug`` rule uses the prebuilt simulator to run a custom binary The ``run-binary-debug`` rule will also automatically build a simulator,
and generate a waveform. For example, to run a run it on a custom binary, and generate a waveform. For example, to run a
test on ``helloworld.riscv``, use test on ``helloworld.riscv``, use
.. code-block:: shell .. code-block:: shell
@@ -83,8 +83,20 @@ Torture tests
The RISC-V torture utility generates random RISC-V assembly streams, compiles them, The RISC-V torture utility generates random RISC-V assembly streams, compiles them,
runs them on both the Spike functional model and the SW simulator, and verifies runs them on both the Spike functional model and the SW simulator, and verifies
identical program behavior. The torture utility can also be configured to run identical program behavior. The torture utility can also be configured to run
continuously for stress-testing. The torture utility exists within the ``utilities`` continuously for stress-testing. The torture utility exists within the ``tools``
directory. directory. To run torture tests, run ``make`` in the simulation directories:
.. code-block:: shell
make CONFIG=CustomConfig torture
To run overnight tests (repeated random tests), run
.. code-block:: shell
make CONFIG=CustomConfig TORTURE_ONIGHT_OPTIONS=<overnight options> torture-overnight
You can find the overnight options in `overnight/src/main/scala/main.scala` in the torture repo.
Firesim Debugging Firesim Debugging
--------------------------- ---------------------------

1
docs/Customization/Dsptools-Blocks.rst
View File

@@ -120,7 +120,6 @@ Now we can run our simulation.
.. code-block:: shell .. code-block:: shell
cd sims/verilator cd sims/verilator
make CONFIG=StreamingFIRRocketConfig
make CONFIG=StreamingFIRRocketConfig BINARY=../../tests/streaming-fir.riscv run-binary make CONFIG=StreamingFIRRocketConfig BINARY=../../tests/streaming-fir.riscv run-binary
.. [#] ``ReadQueue`` and ``WriteQueue`` are good illustrations of how to write a ``DspBlock`` and how they can be integrated into rocket, but in a real design a DMA engine would be preferred. ``ReadQueue`` will stall the processor if you try to read an empty queue, and ``WriteQueue`` will stall if you try to write to a full queue, which a DMA engine can more elegantly avoid. Furthermore, a DMA engine can do the work of moving data, freeing the processor to do other useful work (or sleep). .. [#] ``ReadQueue`` and ``WriteQueue`` are good illustrations of how to write a ``DspBlock`` and how they can be integrated into rocket, but in a real design a DMA engine would be preferred. ``ReadQueue`` will stall the processor if you try to read an empty queue, and ``WriteQueue`` will stall if you try to write to a full queue, which a DMA engine can more elegantly avoid. Furthermore, a DMA engine can do the work of moving data, freeing the processor to do other useful work (or sleep).

1
docs/Customization/MMIO-Peripherals.rst
View File

@@ -137,7 +137,6 @@ Now with all of that done, we can go ahead and run our simulation.
.. code-block:: shell .. code-block:: shell
cd sims/verilator cd sims/verilator
make CONFIG=GCDTLRocketConfig
make CONFIG=GCDTLRocketConfig BINARY=../../tests/gcd.riscv run-binary make CONFIG=GCDTLRocketConfig BINARY=../../tests/gcd.riscv run-binary