spelling check | better heading for accelerators
This commit is contained in:
@@ -3,7 +3,7 @@ Berkeley Out-of-Order Machine (BOOM)
|
||||
|
||||
The `Berkeley Out-of-Order Machine (BOOM) <https://boom-core.org/>`__ is a synthesizable and parameterizable open source RV64GC RISC-V core written in the Chisel hardware construction language.
|
||||
It serves as a drop-in replacement to the Rocket core given by Rocket Chip.
|
||||
BOOM is heavily inspired by the MIPS R10k and the Alpha 21264 outoforder processors.
|
||||
BOOM is heavily inspired by the MIPS R10k and the Alpha 21264 out-of-order processors.
|
||||
Like the R10k and the 21264, BOOM is a unified physical register file design (also known as “explicit register renaming”).
|
||||
Conceptually, BOOM is broken up into 10 stages: Fetch, Decode, Register Rename, Dispatch, Issue, Register Read, Execute, Memory, Writeback and Commit.
|
||||
However, many of those stages are combined in the current implementation, yielding seven stages: Fetch, Decode/Rename, Rename/Dispatch, Issue/RegisterRead, Execute, Memory and Writeback (Commit occurs asynchronously, so it is not counted as part of the “pipeline”).
|
||||
|
||||
@@ -22,7 +22,7 @@ The X will be a number 0-3, and determines the opcode of the instruction, which
|
||||
The ``rd``, ``rs1``, and ``rs2`` fields are the register numbers of the destination register and two source registers.
|
||||
The ``funct`` field is a 7-bit integer that the accelerator can use to distinguish different instructions from each other.
|
||||
|
||||
Note that communication through a RoCC interface requires a custom software toolchain, whereas MMIO peripherals can use that standard toolchain with approriate driver support.
|
||||
Note that communication through a RoCC interface requires a custom software toolchain, whereas MMIO peripherals can use that standard toolchain with appropriate driver support.
|
||||
|
||||
Integrating into the Generator Build System
|
||||
-------------------------------------------
|
||||
@@ -138,7 +138,7 @@ For a simple memory-mapped peripheral, this just involves connecting the periphe
|
||||
|
||||
|
||||
Note that the ``PWMTL`` class we created from the register router is itself a ``LazyModule``.
|
||||
Register routers have a TileLike node simply named "node", which we can hook up to the Rocket Chip bus.
|
||||
Register routers have a TileLink node simply named "node", which we can hook up to the Rocket Chip bus.
|
||||
This will automatically add address map and device tree entries for the peripheral.
|
||||
|
||||
The module implementation trait is where we instantiate our PWM module and connect it to the rest of the SoC.
|
||||
|
||||
@@ -13,7 +13,7 @@ Chisel/FIRRTL
|
||||
|
||||
One of the tools to help create new RTL designs quickly is the `Chisel Hardware Construction Language <https://chisel.eecs.berkeley.edu/>`__ and the `FIRRTL Compiler <https://freechipsproject.github.io/firrtl/>`__.
|
||||
Chisel is an embedded language within Scala that provides a set of libraries to help hardware designers create highly parameterizable RTL.
|
||||
FIRRTL on the other hand is a compiler for hardware which allows the user to run FIRRTL passes that can do dead code elimation, circuit analysis, connectivity checks, and much more!
|
||||
FIRRTL on the other hand is a compiler for hardware which allows the user to run FIRRTL passes that can do dead code elimination, circuit analysis, connectivity checks, and much more!
|
||||
These two tools in combination allow quick design space exploration and development of new RTL.
|
||||
|
||||
Generators
|
||||
|
||||
@@ -17,7 +17,7 @@ Processor Cores
|
||||
An out-of-order RISC-V core.
|
||||
See :ref:`Berkeley Out-of-Order Machine (BOOM)` for more information.
|
||||
|
||||
Data-Parallel Accelerators
|
||||
Accelerators
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
**Hwacha**
|
||||
|
||||
@@ -97,7 +97,7 @@ FireSim enables simulations at 1000x-100000x the speed of standard software simu
|
||||
This is enabled using FPGA-acceleration on F1 instances of the AWS (Amazon Web Services) public cloud.
|
||||
Therefore FireSim simulation requires to be set-up on the AWS public cloud rather than on our local development machine.
|
||||
|
||||
To run an FPGA-accelerated simulation using FireSim, a we need to clone the REBAR repository (or our fork of the REBAR repository) to an AWS EC2, and follow the setup instructions specificied in the FireSim Initial Setup documentation page.
|
||||
To run an FPGA-accelerated simulation using FireSim, a we need to clone the REBAR repository (or our fork of the REBAR repository) to an AWS EC2, and follow the setup instructions specified in the FireSim Initial Setup documentation page.
|
||||
|
||||
After setting up the FireSim environment, we now need to generate a FireSim simulation around our selected digital design.
|
||||
We will work from within the ``sims/firesim`` directory.
|
||||
|
||||
@@ -3,7 +3,7 @@ Getting Started
|
||||
|
||||
These guides will walk you through the basics of the REBAR framework:
|
||||
|
||||
- First, we will go over the different configurations avaliable.
|
||||
- First, we will go over the different configurations available.
|
||||
|
||||
- Then, we will walk through adding a custom accelerator.
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
Commericial Software RTL Simulators
|
||||
Commercial Software RTL Simulators
|
||||
==============================
|
||||
|
||||
VCS
|
||||
-----------------------
|
||||
|
||||
`VCS <https://www.synopsys.com/verification/simulation/vcs.html>`__ is a commercial RTL simulator developed by Synopsys.
|
||||
It requires commerical licenses.
|
||||
It requires commercial licenses.
|
||||
The REBAR framework can compile and execute simulations using VCS.
|
||||
VCS simulation will generally compile faster than Verilator simulations.
|
||||
|
||||
@@ -33,7 +33,7 @@ If you later create your own project, you can use environment variables to build
|
||||
./simulator-<yourproject>-<yourconfig> ...
|
||||
|
||||
If you would like to extract waveforms from the simulation, run the command ``make debug`` instead of just ``make``.
|
||||
This will generate a vpd file (this is a proprietry waveform representation format used by Synopsys) that can be loaded to vpd-supported waveform viewers.
|
||||
This will generate a vpd file (this is a proprietary waveform representation format used by Synopsys) that can be loaded to vpd-supported waveform viewers.
|
||||
If you have Synopsys licenses, we recommend using the DVE waveform viewer.
|
||||
|
||||
Please refer to :ref:`Running A Simulation` for a step by step tutorial on how to get a simulator up and running.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Simulators
|
||||
=======================
|
||||
|
||||
REBAR provides support and intergration for multiple simulation flows, for various user levels and requirments.
|
||||
REBAR provides support and integration for multiple simulation flows, for various user levels and requirements.
|
||||
In the majority of cases during a digital design development process, a simple software RTL simulation will do.
|
||||
When more advanced full-system evaluation is required, with long running workloads, FPGA-accelerated simulation will then become a preferable solution.
|
||||
The following pages provide detailed information about the simulation possibilities within the REBAR framework.
|
||||
|
||||
Reference in New Issue
Block a user