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

update with tethered v standalone | small flow fixes [ci skip]

Browse Source
This commit is contained in:
abejgonzalez
2019-09-27 10:39:07 -07:00
parent 9b55ebd3da
commit ddb4676ddf
2 changed files with 33 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/Advanced-Usage/Chip-Communication.rst
View File

@@ -3,8 +3,13 @@
Communicating with the Chip/DUT
===============================
What good is a chip/DUT if it can't communicate with the outside world? Chipyard designs
communicate to the outside world in one of two ways:
What good is a chip/DUT if it can't communicate with the outside world? There are two types of designs that can be
made: tethered or standalone designs. A tethered design is where a host must interact with the DUT (a target) to bringup the design.
A standalone design is a design that can bringup itself (has its own bootrom, loads programs itself, etc). An example of a tethered design
is a Chipyard simulation where the host computer loads the test program into the designs memory. An example of a standalone design is
a design where a program can be loaded from an SDCard by default.
Chipyard designs communicate to the outside world in one of two ways that mainly correspond to a tethered design:
* using the Tethered Serial Interface (TSI) or the Debug Module Interface (DMI) with the Front-End Server (FESVR) to communicate with the design
* using the JTAG interface with OpenOCD and GDB to communicate with the design
@@ -20,7 +25,7 @@ Primer on the Front-End Server (FESVR)
FESVR is a C++ library that manages communication
between a host machine and a RISC-V target. For debugging, it provides a simple API to reset,
send messages, and run programs on a DUT but it also provides peripheral device emulation.
send messages, and load/run programs on a DUT but it also provides peripheral device emulation.
It can be added used simulators (VCS, Verilator, FireSim) as well as in a bringup sequence
for a taped out chip.
@@ -32,7 +37,7 @@ Using the Tethered Serial Interface (TSI)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default, Chipyard uses the Tethered Serial Interface (TSI) to communicate with the target.
TSI is the implementation of the HTIF interface that is used to send commands to the
TSI is the implementation of the HTIF that is used to send commands to the
RISC-V target. These TSI commands are simple R/W commands
that are able to probe the DUT's memory space. In simulation, these TSI commands connect
to a ``SimSerial`` (located in the ``generators/testchipip`` project) simulation C++
@@ -51,9 +56,9 @@ sends the converted TileLink commands over a serial link to the chip.
Using the Debug Module Interface (DMI)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another option to bringup the target is to use the Debug Module Interface (DMI) provided by Rocket Chip.
In this case, a Debug Test Module (DTM) must exist in the target that communicates with the DMI.
The DTM is given in the RISC-V Debug Specification and is responsible for managing communication between
Another option to bringup the target is to use the Debug Module Interface (DMI) provided by a Debug Transfer Module (DTM) existing within the target.
Similar to TSI, DMI is an implementation of HTIF.
The DTM is given in the `RISC-V Debug Specification <https://riscv.org/specifications/debug-specification/>`__ and is responsible for managing communication between
the target and whatever lives on the other side of the DMI (in this case FESVR). This is added by default
to the Rocket Chip ``Subsystem`` by having the ``HasPeripheryDebug`` and ``HasPeripheryDebugModuleImp`` mixins.
Chipyard disables the DTM by default so that it can use the TSI interface.
@@ -74,7 +79,7 @@ configurations. For example:
make CONFIG=LargeBoomConfig run-asm-tests
If you would like to build a DMI system with a Chipyard configuration, the you must create a
If you would like to build and simulate a DMI system with a Chipyard configuration, the you must create a
top-level system with the DTM as well as a config to use that top-level system.
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
@@ -91,12 +96,12 @@ The rest of the mixins specify the rest of the system (cores, accelerators, etc)
# or
cd sims/vcs
make CONFIG=dmiRocketConfig TOP=TopWithDTM MODEL=TestHarnessWithDTM
make CONFIG=dmiRocketConfig TOP=TopWithDTM MODEL=TestHarnessWithDTM run-asm-tests
Using the JTAG Interface
------------------------
The main way to use JTAG with a Rocket Chip based system is to instantiate the Debug Test Module (DTM)
The main way to use JTAG with a Rocket Chip based system is to instantiate the Debug Transfer Module (DTM)
and configure it to use a JTAG interface (by default the DTM is setup to use the DMI interface mentioned above).
However, if you want to use JTAG, you must do the following steps to setup a DTM+JTAG enabled system.
@@ -116,7 +121,7 @@ The ``WithJtagDTM`` will configure that instantiated DTM to use JTAG as the brin
this can be removed if you want a DMI-only bringup).
The rest of the mixins specify the rest of the system (cores, accelerators, etc).
Starting the DTM+JTAG Simulation
Building a DTM+JTAG Simulator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After creating the config, call the ``make`` command like the following:
@@ -131,7 +136,7 @@ After creating the config, call the ``make`` command like the following:
In this example, this will use the config that you previously specified, as well as set
the other parameters that are needed to satisfy the build system. After that point, you
should have a JTAG enabled simulation that you can attach to using OpenOCD and GDB!
should have a JTAG enabled simulator that you can attach to using OpenOCD and GDB!
Debugging with JTAG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

17
docs/Software/Spike.rst
View File

@@ -1,4 +1,19 @@
The RISC-V ISA Simulator (Spike)
=================================
.. attention:: This article is a stub. Fill it out!
Spike is the golden reference functional RISC-V ISA simulator.
It provides full system emulation or proxied emulation with the HTIF/FESVR.
It serves as a starting point for running software on a RISC-V target.
Here is a highlight of some of Spikes main features:
* Multiple ISAs: RV32IMAFDQCV extensions
* Multiple memory models: Weak Memory Ordering (WMO) and Total Store Ordering (TSO)
* Priveleged Spec: Machine, Supervisor, User modes (v1.11)
* Debug Spec
* Single-step debugging with support for viewing memory/register contents
* Multiple CPU support
* JTAG support
* Highly extensible (add and test new instructions)
* And much more!
Spike comes pre-packaged in the RISC-V toolchain.