add more to docs | 1st spelling pass | more links | proper formatting
This commit is contained in:
abejgonzalez
@@ -1,10 +1,11 @@
|
||||
Berkeley Out-of-Order Machine (BOOM)
|
||||
==============================================
|
||||
|
||||
The Berkeley Out-of-Order Machine (BOOM) is a synthesizable and parameterizable open source RV64GC RISC-V core written in the Chisel hardware construction language.
|
||||
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.
|
||||
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”).
|
||||
|
||||
BOOM is heavily inspired by the MIPS R10k and the Alpha 21264 outoforder 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”).
|
||||
|
||||
Additional information about the BOOM micro-architecture can be found in the `BOOM documentation pages <https://docs.boom-core.org/en/latest/index.html>__`.
|
||||
Additional information about the BOOM micro-architecture can be found in the `BOOM documentation pages <https://docs.boom-core.org/>__`.
|
||||
|
||||
8
docs/Generators/Hwacha.rst
Normal file
8
docs/Generators/Hwacha.rst
Normal file
@@ -0,0 +1,8 @@
|
||||
Hwacha
|
||||
====================================
|
||||
|
||||
The Hwacha project is developing a new vector architecture for future computer systems that are constrained in their power and energy consumption.
|
||||
Inspired by traditional vector machines from the 70s and 80s, and lessons learned from our previous vector-thread architectures Scale and Maven, we are bringing back elegant, performant, and energy-efficient aspects of vector processing to modern data-parallel architectures.
|
||||
We propose a new vector-fetch architectural paradigm, which focuses on the following aspects for higher performance, better energy efficiency, and lower complexity.
|
||||
|
||||
For more information, please visit the `Hwacha website <http://hwacha.org/>`__.
|
||||
@@ -1,3 +1,12 @@
|
||||
Rocket
|
||||
====================================
|
||||
TODO: Basic rocket introduction
|
||||
|
||||
`Rocket <https://github.com/freechipsproject/rocket-chip>`__ is a 5-stage in-order scalar core generator that is supported by `SiFive <https://www.sifive.com/>`__.
|
||||
It supports the open source RV64GC RISC-V instruction set and is written in the Chisel hardware construction language.
|
||||
It has an MMU that supports page-based virtual memory, a non-blocking data cache, and a front-end with branch prediction.
|
||||
Branch prediction is configurable and provided by a branch target buffer (BTB), branch history table (BHT), and a return address stack (RAS).
|
||||
For floating-point, Rocket makes use of Berkeley’s Chisel implementations of floating-point units.
|
||||
Rocket also supports the RISC-V machine, supervisor, and user privilege levels.
|
||||
A number of parameters are exposed, including the optional support of some ISA extensions (M, A, F, D), the number of floating-point pipeline stages, and the cache and TLB sizes.
|
||||
|
||||
For more information, please refer to the `GitHub repository <https://github.com/freechipsproject/rocket-chip>`__, `technical report <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-17.html>`__ or to `this Chisel Community Conference video <https://youtu.be/Eko86PGEoDY>`__.
|
||||
|
||||
@@ -1,8 +1,11 @@
|
||||
Generators
|
||||
============================
|
||||
Generator can be thought of as generalized RTL designs, written using a mix of meta-programming and standard RTL.
|
||||
This type of meta-programming is enabled by the Chisel hardware description framework embedded in Scala.
|
||||
A standard RTL design is esentially a degenerate form of a generator. However, by using meta-programming and parameter systems, generators can allow for integration of complex hardware designs in automated ways. The following pages introduce the generators integrated with the ReBAR framework.
|
||||
|
||||
Generator can be thought of as a generalized RTL design, written using a mix of meta-programming and standard RTL.
|
||||
This type of meta-programming is enabled by the Chisel hardware description language (see :ref:`Chisel`).
|
||||
A standard RTL design is essentially just a single instance of a design coming from a generator.
|
||||
However, by using meta-programming and parameter systems, generators can allow for integration of complex hardware designs in automated ways.
|
||||
The following pages introduce the generators integrated with the REBAR framework.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
@@ -10,4 +13,5 @@ A standard RTL design is esentially a degenerate form of a generator. However, b
|
||||
|
||||
Rocket
|
||||
BOOM
|
||||
Hwacha
|
||||
|
||||
|
||||
@@ -1,80 +1,69 @@
|
||||
|
||||
|
||||
Adding An Accelerator/Device
|
||||
===============================
|
||||
|
||||
Accelerators or custom IO devices can be added to your SoC in several ways:
|
||||
+ MMIO Peripheral (a.k.a TileLink-Attached Accelerator)
|
||||
+ Tightly-Coupled RoCC Accelerator
|
||||
|
||||
These approaches differ in the method of the communication between the processor and the custom block.
|
||||
* MMIO Peripheral (a.k.a TileLink-Attached Accelerator)
|
||||
* Tightly-Coupled RoCC Accelerator
|
||||
|
||||
With the TileLink-Attached approach, the processor communicates with MMIO peripherals through memory-mapped registers.
|
||||
These approaches differ in the method of the communication between the processor and the custom block.
|
||||
|
||||
In contrast, the processor communicates with a RoCC accelerators through a custom protocol and custom non-standard ISA instructions reserved in the RISC-V ISA encoding space. Each core can have up to four accelerators that are controlled by custom instructions and share resources with the CPU.
|
||||
With the TileLink-Attached approach, the processor communicates with MMIO peripherals through memory-mapped registers.
|
||||
|
||||
In contrast, the processor communicates with a RoCC accelerators through a custom protocol and custom non-standard ISA instructions reserved in the RISC-V ISA encoding space.
|
||||
Each core can have up to four accelerators that are controlled by custom instructions and share resources with the CPU.
|
||||
RoCC coprocessor instructions have the following form.
|
||||
|
||||
::
|
||||
.. code-block::
|
||||
customX rd, rs1, rs2, funct
|
||||
|
||||
The X will be a number 0-3, and determines the opcode of the instruction,
|
||||
which controls which accelerator an instruction will be routed to.
|
||||
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 interfaces requires a custom software toolchain, whereas MMIO peripherals can use that standard toolchain with approriate driver support.
|
||||
The X will be a number 0-3, and determines the opcode of the instruction, which controls which accelerator an instruction will be routed to.
|
||||
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.
|
||||
|
||||
Integrating into the Generator Build System
|
||||
-------------------------------------------
|
||||
|
||||
While developing, you want to include Chisel code in a submodule so that it
|
||||
can be shared by different projects. To add a submodule to the project
|
||||
template, make sure that your project is organized as follows.
|
||||
While developing, you want to include Chisel code in a submodule so that it can be shared by different projects.
|
||||
To add a submodule to the REBAR framework, make sure that your project is organized as follows.
|
||||
|
||||
.. code-block::
|
||||
yourproject/
|
||||
build.sbt
|
||||
src/main/scala/
|
||||
YourFile.scala
|
||||
|
||||
Put this in a git repository and make it accessible. Then add it as a submodule
|
||||
to under the following directory hierarchy: ``rebar/generators/yourproject``.
|
||||
Put this in a git repository and make it accessible.
|
||||
Then add it as a submodule to under the following directory hierarchy: ``generators/yourproject``.
|
||||
|
||||
::
|
||||
.. code-block:: shell
|
||||
cd generators/
|
||||
git submodule add https://git-repository.com/yourproject.git
|
||||
|
||||
Then add `yourproject` to the ReBAR top-level build.sbt file.
|
||||
Then add ``yourproject`` to the REBAR top-level build.sbt file.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
lazy val yourproject = project.settings(commonSettings).dependsOn(rocketchip)
|
||||
|
||||
|
||||
You can then import the classes defined in the submodule in a new project if
|
||||
you add it as a dependency. For instance, if you want to use this code in
|
||||
the `example` project, change the final line in build.sbt to the following.
|
||||
the ``example`` project, change the final line in build.sbt to the following.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
lazy val example = (project in file(".")).settings(commonSettings).dependsOn(testchipip, yourproject)
|
||||
|
||||
|
||||
Finally, add `yourproject` to the `PACKAGES` variable in the `Makefrag`. This will allow make to detect
|
||||
that your source files have changed when building the verilog/firrtl files.
|
||||
|
||||
|
||||
Finally, add ``yourproject`` to the ``PACKAGES`` variable in the ``common.mk`` file in the REBAR top level.
|
||||
This will allow make to detect that your source files have changed when building the Verilog/FIRRTL files.
|
||||
|
||||
MMIO Peripheral
|
||||
------------------
|
||||
|
||||
The easiest way to create a TileLink peripheral is to use the
|
||||
TLRegisterRouter, which abstracts away the details of handling the TileLink
|
||||
protocol and provides a convenient interface for specifying memory-mapped
|
||||
registers. To create a RegisterRouter-based peripheral, you will need to
|
||||
specify a parameter case class for the configuration settings, a bundle trait
|
||||
with the extra top-level ports, and a module implementation containing the
|
||||
actual RTL.
|
||||
The easiest way to create a TileLink peripheral is to use the ``TLRegisterRouter``, which abstracts away the details of handling the TileLink protocol and provides a convenient interface for specifying memory-mapped registers.
|
||||
To create a RegisterRouter-based peripheral, you will need to specify a parameter case class for the configuration settings, a bundle trait with the extra top-level ports, and a module implementation containing the actual RTL.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
case class PWMParams(address: BigInt, beatBytes: Int)
|
||||
|
||||
trait PWMTLBundle extends Bundle {
|
||||
@@ -103,16 +92,12 @@ actual RTL.
|
||||
}
|
||||
|
||||
|
||||
Once you have these classes, you can construct the final peripheral by
|
||||
extending the TLRegisterRouter and passing the proper arguments. The first
|
||||
set of arguments determines where the register router will be placed in the
|
||||
global address map and what information will be put in its device tree entry.
|
||||
The second set of arguments is the IO bundle constructor, which we create
|
||||
by extending TLRegBundle with our bundle trait. The final set of arguments
|
||||
is the module constructor, which we create by extends TLRegModule with our
|
||||
module trait.
|
||||
Once you have these classes, you can construct the final peripheral by extending the ``TLRegisterRouter`` and passing the proper arguments.
|
||||
The first set of arguments determines where the register router will be placed in the global address map and what information will be put in its device tree entry.
|
||||
The second set of arguments is the IO bundle constructor, which we create by extending ``TLRegBundle`` with our bundle trait.
|
||||
The final set of arguments is the module constructor, which we create by extends ``TLRegModule`` with our module trait.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
class PWMTL(c: PWMParams)(implicit p: Parameters)
|
||||
extends TLRegisterRouter(
|
||||
c.address, "pwm", Seq("ucbbar,pwm"),
|
||||
@@ -120,20 +105,17 @@ module trait.
|
||||
new TLRegBundle(c, _) with PWMTLBundle)(
|
||||
new TLRegModule(c, _, _) with PWMTLModule)
|
||||
|
||||
The full module code can be found in ``generators/example/src/main/scala/PWM.scala``.
|
||||
|
||||
The full module code with comments can be found in src/main/scala/example/PWM.scala.
|
||||
After creating the module, we need to hook it up to our SoC.
|
||||
Rocket Chip accomplishes this using the cake pattern.
|
||||
This basically involves placing code inside traits.
|
||||
In the Rocket Chip cake, there are two kinds of traits: a ``LazyModule`` trait and a module implementation trait.
|
||||
|
||||
After creating the module, we need to hook it up to our SoC. Rocketchip
|
||||
accomplishes this using the [cake pattern](http://www.cakesolutions.net/teamblogs/2011/12/19/cake-pattern-in-depth).
|
||||
This basically involves placing code inside traits. In the RocketChip cake,
|
||||
there are two kinds of traits: a LazyModule trait and a module implementation
|
||||
trait.
|
||||
The ``LazyModule`` trait runs setup code that must execute before all the hardware gets elaborated.
|
||||
For a simple memory-mapped peripheral, this just involves connecting the peripheral's TileLink node to the MMIO crossbar.
|
||||
|
||||
The LazyModule trait runs setup code that must execute before all the hardware
|
||||
gets elaborated. For a simple memory-mapped peripheral, this just involves
|
||||
connecting the peripheral's TileLink node to the MMIO crossbar.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
trait HasPeripheryPWM extends HasSystemNetworks {
|
||||
implicit val p: Parameters
|
||||
|
||||
@@ -147,17 +129,15 @@ connecting the peripheral's TileLink node to the MMIO crossbar.
|
||||
}
|
||||
|
||||
|
||||
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 RocketChip peripheryBus. This will automatically add
|
||||
address map and device tree entries for the peripheral.
|
||||
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.
|
||||
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. Since this module has an extra `pwmout`
|
||||
output, we declare that in this trait, using Chisel's multi-IO
|
||||
functionality. We then connect the PWMTL's pwmout to the pwmout we declared.
|
||||
The module implementation trait is where we instantiate our PWM module and connect it to the rest of the SoC.
|
||||
Since this module has an extra `pwmout` output, we declare that in this trait, using Chisel's multi-IO functionality.
|
||||
We then connect the ``PWMTL``'s pwmout to the pwmout we declared.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
trait HasPeripheryPWMModuleImp extends LazyMultiIOModuleImp {
|
||||
implicit val p: Parameters
|
||||
val outer: HasPeripheryPWM
|
||||
@@ -167,11 +147,10 @@ functionality. We then connect the PWMTL's pwmout to the pwmout we declared.
|
||||
pwmout := outer.pwm.module.io.pwmout
|
||||
}
|
||||
|
||||
Now we want to mix our traits into the system as a whole.
|
||||
This code is from ``generators/example/src/main/scala/Top.scala``.
|
||||
|
||||
Now we want to mix our traits into the system as a whole. This code is from
|
||||
src/main/scala/example/Top.scala.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
class ExampleTopWithPWM(q: Parameters) extends ExampleTop(q)
|
||||
with PeripheryPWM {
|
||||
override lazy val module = Module(
|
||||
@@ -182,19 +161,15 @@ src/main/scala/example/Top.scala.
|
||||
extends ExampleTopModule(l) with HasPeripheryPWMModuleImp
|
||||
|
||||
|
||||
Just as we need separate traits for LazyModule and module implementation, we
|
||||
need two classes to build the system. The ExampleTop classes already have the
|
||||
basic peripherals included for us, so we will just extend those.
|
||||
Just as we need separate traits for ``LazyModule`` and module implementation, we need two classes to build the system.
|
||||
The ``ExampleTop`` classes already have the basic peripherals included for us, so we will just extend those.
|
||||
|
||||
The ExampleTop class includes the pre-elaboration code and also a lazy val to
|
||||
produce the module implementation (hence LazyModule). The ExampleTopModule
|
||||
class is the actual RTL that gets synthesized.
|
||||
The ``ExampleTop`` class includes the pre-elaboration code and also a ``lazy val`` to produce the module implementation (hence ``LazyModule``).
|
||||
The ``ExampleTopModule`` class is the actual RTL that gets synthesized.
|
||||
|
||||
Finally, we need to add a configuration class in
|
||||
src/main/scala/example/Configs.scala that tells the TestHarness to instantiate
|
||||
ExampleTopWithPWM instead of the default ExampleTop.
|
||||
Finally, we need to add a configuration class in ``generators/example/src/main/scala/Configs.scala`` that tells the ``TestHarness`` to instantiate ``ExampleTopWithPWM`` instead of the default ``ExampleTop``.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
class WithPWM extends Config((site, here, up) => {
|
||||
case BuildTop => (p: Parameters) =>
|
||||
Module(LazyModule(new ExampleTopWithPWM()(p)).module)
|
||||
@@ -203,9 +178,9 @@ ExampleTopWithPWM instead of the default ExampleTop.
|
||||
class PWMConfig extends Config(new WithPWM ++ new BaseExampleConfig)
|
||||
|
||||
|
||||
Now we can test that the PWM is working. The test program is in tests/pwm.c
|
||||
Now we can test that the PWM is working. The test program is in ``tests/pwm.c``.
|
||||
|
||||
::
|
||||
.. code-block:: c
|
||||
#define PWM_PERIOD 0x2000
|
||||
#define PWM_DUTY 0x2008
|
||||
#define PWM_ENABLE 0x2010
|
||||
@@ -230,29 +205,26 @@ Now we can test that the PWM is working. The test program is in tests/pwm.c
|
||||
}
|
||||
|
||||
|
||||
This just writes out to the registers we defined earlier. The base of the
|
||||
module's MMIO region is at 0x2000. This will be printed out in the address
|
||||
map portion when you generated the verilog code.
|
||||
This just writes out to the registers we defined earlier.
|
||||
The base of the module's MMIO region is at 0x2000.
|
||||
This will be printed out in the address map portion when you generated the verilog code.
|
||||
|
||||
Compiling this program with make produces a `pwm.riscv` executable.
|
||||
Compiling this program with make produces a ``pwm.riscv`` executable.
|
||||
|
||||
Now with all of that done, we can go ahead and run our simulation.
|
||||
|
||||
::
|
||||
.. code-block:: shell
|
||||
cd verisim
|
||||
make CONFIG=PWMConfig
|
||||
./simulator-example-PWMConfig ../tests/pwm.riscv
|
||||
|
||||
|
||||
|
||||
|
||||
Adding a RoCC Accelerator
|
||||
----------------------------
|
||||
|
||||
RoCC accelerators are lazy modules that extend the LazyRoCC class.
|
||||
Their implementation should extends the LazyRoCCModule class.
|
||||
RoCC accelerators are lazy modules that extend the ``LazyRoCC`` class.
|
||||
Their implementation should extends the ``LazyRoCCModule`` class.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
class CustomAccelerator(opcodes: OpcodeSet)
|
||||
(implicit p: Parameters) extends LazyRoCC(opcodes) {
|
||||
override lazy val module = new CustomAcceleratorModule(this)
|
||||
@@ -277,34 +249,30 @@ Their implementation should extends the LazyRoCCModule class.
|
||||
}
|
||||
|
||||
|
||||
The ``opcodes`` parameter for ``LazyRoCC`` is
|
||||
the set of custom opcodes that will map to this accelerator. More on this
|
||||
in the next subsection.
|
||||
The ``opcodes`` parameter for ``LazyRoCC`` is the set of custom opcodes that will map to this accelerator.
|
||||
More on this in the next subsection.
|
||||
|
||||
The ``LazyRoCC`` class contains two TLOutputNode instances, ``atlNode`` and ``tlNode``.
|
||||
The former connects into a tile-local arbiter along with the backside of the
|
||||
L1 instruction cache. The latter connects directly to the L1-L2 crossbar.
|
||||
The corresponding Tilelink ports in the module implementation's IO bundle
|
||||
are ``atl`` and ``tl``, respectively.
|
||||
The former connects into a tile-local arbiter along with the backside of the L1 instruction cache.
|
||||
The latter connects directly to the L1-L2 crossbar.
|
||||
The corresponding Tilelink ports in the module implementation's IO bundle are ``atl`` and ``tl``, respectively.
|
||||
|
||||
The other interfaces available to the accelerator are ``mem``, which provides
|
||||
access to the L1 cache; ``ptw`` which provides access to the page-table walker;
|
||||
the ``busy`` signal, which indicates when the accelerator is still handling an
|
||||
instruction; and the ``interrupt`` signal, which can be used to interrupt the CPU.
|
||||
The other interfaces available to the accelerator are ``mem``, which provides access to the L1 cache;
|
||||
``ptw`` which provides access to the page-table walker;
|
||||
the ``busy`` signal, which indicates when the accelerator is still handling an instruction;
|
||||
and the ``interrupt`` signal, which can be used to interrupt the CPU.
|
||||
|
||||
Look at the examples in rocket-chip/src/main/scala/tile/LazyRocc.scala for
|
||||
detailed information on the different IOs.
|
||||
Look at the examples in ``generators/rocket-chip/src/main/scala/tile/LazyRocc.scala`` for detailed information on the different IOs.
|
||||
|
||||
### Adding RoCC accelerator to Config
|
||||
Adding RoCC accelerator to Config
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
RoCC accelerators can be added to a core by overriding the ``BuildRoCC`` parameter
|
||||
in the configuration. This takes a sequence of functions producing ``LazyRoCC``
|
||||
objects, one for each accelerator you wish to add.
|
||||
RoCC accelerators can be added to a core by overriding the ``BuildRoCC`` parameter in the configuration.
|
||||
This takes a sequence of functions producing ``LazyRoCC`` objects, one for each accelerator you wish to add.
|
||||
|
||||
For instance, if we wanted to add the previously defined accelerator and
|
||||
route custom0 and custom1 instructions to it, we could do the following.
|
||||
For instance, if we wanted to add the previously defined accelerator and route custom0 and custom1 instructions to it, we could do the following.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
class WithCustomAccelerator extends Config((site, here, up) => {
|
||||
case BuildRoCC => Seq((p: Parameters) => LazyModule(
|
||||
new CustomAccelerator(OpcodeSet.custom0 | OpcodeSet.custom1)(p)))
|
||||
@@ -313,17 +281,13 @@ route custom0 and custom1 instructions to it, we could do the following.
|
||||
class CustomAcceleratorConfig extends Config(
|
||||
new WithCustomAccelerator ++ new DefaultExampleConfig)
|
||||
|
||||
|
||||
|
||||
|
||||
Adding a DMA port
|
||||
-------------------
|
||||
|
||||
IO devices or accelerators (like a disk or network
|
||||
driver), we may want to have the device write directly to the coherent
|
||||
memory system instead. To add a device like that, you would do the following.
|
||||
IO devices or accelerators (like a disk or network driver), we may want to have the device write directly to the coherent memory system instead.
|
||||
To add a device like that, you would do the following.
|
||||
|
||||
::
|
||||
.. code-block:: scala
|
||||
class DMADevice(implicit p: Parameters) extends LazyModule {
|
||||
val node = TLClientNode(TLClientParameters(
|
||||
name = "dma-device", sourceId = IdRange(0, 1)))
|
||||
@@ -355,8 +319,6 @@ memory system instead. To add a device like that, you would do the following.
|
||||
|
||||
|
||||
The ``ExtBundle`` contains the signals we connect off-chip that we get data from.
|
||||
The DMADevice also has a Tilelink client port that we connect into the L1-L2
|
||||
crossbar through the front-side buffer (fsb). The sourceId variable given in
|
||||
the TLClientNode instantiation determines the range of ids that can be used
|
||||
in acquire messages from this device. Since we specified [0, 1) as our range,
|
||||
only the ID 0 can be used.
|
||||
The DMADevice also has a Tilelink client port that we connect into the L1-L2 crossbar through the front-side buffer (fsb).
|
||||
The sourceId variable given in the ``TLClientNode`` instantiation determines the range of ids that can be used in acquire messages from this device.
|
||||
Since we specified [0, 1) as our range, only the ID 0 can be used.
|
||||
|
||||
@@ -1,55 +1,62 @@
|
||||
Configs, Parameters, Mix-ins, and Everything In Between
|
||||
========================================================
|
||||
|
||||
A significant portion of generators in the ReBAR framework use the Rocket chip parameter system.
|
||||
A significant portion of generators in the REBAR framework use the Rocket Chip parameter system.
|
||||
This parameter system enables for the flexible configuration of the SoC without invasive RTL changes.
|
||||
In order to use the parameter system correctly, we will use several terms and conventions:
|
||||
|
||||
Parameter
|
||||
Parameters
|
||||
--------------------
|
||||
|
||||
TODO: Need to explain up, site, field, and other stuff from Henry's thesis.
|
||||
|
||||
It is important to note that a significant challenge with the Rocket parameter system is being able to identify the correct parameter to use, and the impact that parameter has on the overall system. We are still investigating methods to facilitate parameter exploration and discovery.
|
||||
It is important to note that a significant challenge with the Rocket parameter system is being able to identify the correct parameter to use, and the impact that parameter has on the overall system.
|
||||
We are still investigating methods to facilitate parameter exploration and discovery.
|
||||
|
||||
|
||||
Config
|
||||
Configs
|
||||
---------------------
|
||||
A `Config` is a collection of multiple parameters being set to specific values.
|
||||
Configs are additive, and can override each other.
|
||||
A Config can be composed of other configs.
|
||||
The naming convetion for an additive config is ``With<YourConfig>``, while the naming convention for a non-additive config will be ``<YourConfig>``.
|
||||
Configs can take arguments which will in-turn set parameters in the specific configs.
|
||||
|
||||
Example config:
|
||||
A *Config* is a collection of multiple generator parameters being set to specific values.
|
||||
Configs are additive, can override each other, and can be composed of other Configs.
|
||||
The naming convention for an additive Config is ``With<YourConfigName>``, while the naming convention for a non-additive Config will be ``<YourConfig>``.
|
||||
Configs can take arguments which will in-turn set parameters in the design or reference other parameters in the design (see :ref:`Parameters`).
|
||||
|
||||
:numref:`basic-config-example` shows a basic additive Config class that takes in zero arguments and instead uses hardcoded values to set the RTL design parameters.
|
||||
In this example, ``MyAcceleratorConfig`` is a Scala case class that defines a set of variables that the generator can use when referencing the ``MyAcceleratorKey`` in the design.
|
||||
|
||||
.. _basic-config-example:
|
||||
.. code-block:: scala
|
||||
|
||||
class WithMyAcceleratorParams extends Config((site, here, up) => {
|
||||
case BusWidthBits => 128
|
||||
case MyAcceleratorKey =>
|
||||
MyAcceleratorConfig(
|
||||
Rows = 2,
|
||||
rows = 2,
|
||||
rowBits = 64,
|
||||
Columns = 16,
|
||||
columns = 16,
|
||||
hartId = 1,
|
||||
some_length = 256,
|
||||
)
|
||||
someLength = 256)
|
||||
})
|
||||
|
||||
Example config which uses a higher level config:
|
||||
This next example (:numref:`complex-config-example`) shows a "higher-level" additive Config that uses prior parameters that were set to derive other parameters.
|
||||
|
||||
.. _complex-config-example:
|
||||
.. code-block:: scala
|
||||
|
||||
class WithMyMoreComplexAcceleratorConfig extends Config((site, here, up) => {
|
||||
case BusWidthBits => 128
|
||||
case MyAcceleratorKey =>
|
||||
MyAcceleratorConfig(
|
||||
Rows = 2,
|
||||
rowBits = site(SystemBusKey).beatBits,
|
||||
hartId = up(RocketTilesKey, site).length,
|
||||
)
|
||||
hartId = up(RocketTilesKey, site).length)
|
||||
})
|
||||
|
||||
Example of additive configs:
|
||||
:numref:`top-level-config` shows a non-additive Config that combines the prior two additive Configs using ``++``.
|
||||
The additive Configs are applied from the right to left in the list (or bottom to top in the example).
|
||||
Thus, the order of the parameters being set will first start with the ``DefaultExampleConfig``, then ``WithMyAcceleratorParams``, then ``WithMyMoreComplexAcceleratorConfig``.
|
||||
|
||||
.. _top-level-config:
|
||||
.. code-block:: scala
|
||||
|
||||
class SomeAdditiveConfig extends Config(
|
||||
@@ -58,13 +65,15 @@ Example of additive configs:
|
||||
new DefaultExampleConfig
|
||||
)
|
||||
|
||||
|
||||
Cake Pattern
|
||||
-------------------------
|
||||
The cake pattern is a scala programming pattern, which enable "mixing" of multiple traits or interface definitions (sometimes refered to as dependancy injection). It is used in the Rocket chip SoC library and ReBAR framework in merging multiple system components and IO interfaces into a large system component.
|
||||
|
||||
Example of using the cake pattern to merge multiple system components into a single top-level design, extending a basic Rocket SoC:
|
||||
A cake pattern is a Scala programming pattern, which enable "mixing" of multiple traits or interface definitions (sometimes referred to as dependency injection).
|
||||
It is used in the Rocket Chip SoC library and REBAR framework in merging multiple system components and IO interfaces into a large system component.
|
||||
|
||||
:numref:`cake-example` shows a Rocket Chip based SoC that merges multiple system components (BootROM, UART, etc) into a single top-level design.
|
||||
|
||||
.. _cake-example:
|
||||
.. code-block:: scala
|
||||
|
||||
class MySoC(implicit p: Parameters) extends RocketSubsystem
|
||||
@@ -78,9 +87,14 @@ Example of using the cake pattern to merge multiple system components into a sin
|
||||
//Additional top-level specific instantiations or wiring
|
||||
}
|
||||
|
||||
|
||||
Mix-in
|
||||
---------------------------
|
||||
A mix-in is a scala trait, which sets parameters for specific system components, as well as enabling instantiation and wiring of the relevant system components to system buses.
|
||||
The naming convetion for an additive mix-in is ``Has<YourMixin>``.
|
||||
|
||||
A mix-in is a Scala trait, which sets parameters for specific system components, as well as enabling instantiation and wiring of the relevant system components to system buses.
|
||||
The naming convention for an additive mix-in is ``Has<YourMixin>``.
|
||||
This is show in :numref:`cake-example` where things such as ``HasPeripherySerial`` connect a RTL component to a bus and expose signals to the top-level.
|
||||
|
||||
Additional References
|
||||
---------------------------
|
||||
|
||||
A brief explanation of some of these topics is given in the following video: https://www.youtube.com/watch?v=Eko86PGEoDY.
|
||||
|
||||
25
docs/Getting-Started/Development-Ecosystem.rst
Normal file
25
docs/Getting-Started/Development-Ecosystem.rst
Normal file
@@ -0,0 +1,25 @@
|
||||
Development Ecosystem
|
||||
===============================
|
||||
|
||||
REBAR Approach
|
||||
-------------------------------------------
|
||||
|
||||
The trend towards agile hardware design and evaluation provides an ecosystem of debugging and implementation tools, that make it easier for computer architecture researchers to develop novel concepts.
|
||||
REBAR hopes to build on this prior work in order to create a singular location to which multiple projects within the `Berkeley Architecture Research <https://bar.eecs.berkeley.edu/index.html>`__ can coexist and be used together.
|
||||
REBAR aims to be the "one-stop shop" for creating and testing your own unique System on a Chip (SoC).
|
||||
|
||||
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!
|
||||
These two tools in combination allow quick design space exploration and development of new RTL.
|
||||
|
||||
Generators
|
||||
-------------------------------------------
|
||||
|
||||
Within this repository, all of the Chisel RTL is written as generators.
|
||||
Generators are parametrized programs designed to generate RTL code based on configuration specifications.
|
||||
Generators can be used to generate Systems-on-Chip (SoCs) using a collection of system components organized in unique generator projects.
|
||||
Generators allow you to create a family of SoC designs instead of a single instance of a design!
|
||||
110
docs/Getting-Started/REBAR-Basics.rst
Normal file
110
docs/Getting-Started/REBAR-Basics.rst
Normal file
@@ -0,0 +1,110 @@
|
||||
REBAR Basics
|
||||
===============================
|
||||
|
||||
Generators
|
||||
-------------------------------------------
|
||||
|
||||
The REBAR Framework currently consists of the following RTL generators:
|
||||
|
||||
Processor Cores
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
**Rocket**
|
||||
An in-order RISC-V core.
|
||||
See :ref:`Rocket` for more information.
|
||||
|
||||
**BOOM (Berkeley Out-of-Order Machine)**
|
||||
An out-of-order RISC-V core.
|
||||
See :ref:`Berkeley Out-of-Order Machine (BOOM)` for more information.
|
||||
|
||||
Data-Parallel Accelerators
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
**Hwacha**
|
||||
A decoupled vector architecture co-processor.
|
||||
Hwacha currently implements a non-standard RISC-V extension, using a vector architecture programming model.
|
||||
Hwacha integrates with a Rocket or BOOM core using the RoCC (Rocket Custom Co-processor) interface.
|
||||
See :ref:`Hwacha` for more information.
|
||||
|
||||
System Components:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
**icenet**
|
||||
A Network Interface Controller (NIC) designed to achieve up to 200 Gbps.
|
||||
|
||||
**sifive-blocks**
|
||||
System components implemented by SiFive and used by SiFive projects, designed to be integrated with the Rocket Chip generator.
|
||||
These system and peripheral components include UART, SPI, JTAG, I2C, PWM, and other peripheral and interface devices.
|
||||
|
||||
**AWL (Analog Widget Library)**
|
||||
Digital components required for integration with high speed serial links.
|
||||
|
||||
**testchipip**
|
||||
A collection of utilities used for testing chips and interfacing them with larger test environments.
|
||||
|
||||
.. Fixed Function Accelerators:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
TBD
|
||||
|
||||
Tools
|
||||
-------------------------------------------
|
||||
|
||||
**Chisel**
|
||||
A hardware description library embedded in Scala.
|
||||
Chisel is used to write RTL generators using meta-programming, by embedding hardware generation primitives in the Scala programming language.
|
||||
The Chisel compiler elaborates the generator into a FIRRTL output.
|
||||
See :ref:`Chisel` for more information.
|
||||
|
||||
**FIRRTL**
|
||||
An intermediate representation library for RTL description of digital designs.
|
||||
FIRRTL is used as a formalized digital circuit representation between Chisel and Verilog.
|
||||
FIRRTL enables digital circuits manipulation between Chisel elaboration and Verilog generation.
|
||||
See :ref:`FIRRTL` for more information.
|
||||
|
||||
**Barstools**
|
||||
A collection of common FIRRTL transformations used to manipulate a digital circuit without changing the generator source RTL.
|
||||
See :ref:`Barstools` for more information.
|
||||
|
||||
Toolchains
|
||||
-------------------------------------------
|
||||
|
||||
**riscv-tools**
|
||||
A collection of software toolchains used to develop and execute software on the RISC-V ISA.
|
||||
The include compiler and assembler toolchains, functional ISA simulator (spike), the Berkeley Boot Loader (BBL) and proxy kernel.
|
||||
The riscv-tools repository was previously required to run any RISC-V software, however, many of the riscv-tools components have since been upstreamed to their respective open-source projects (Linux, GNU, etc.).
|
||||
Nevertheless, for consistent versioning, as well as software design flexibility for custom hardware, we include the riscv-tools repository and installation in the REBAR framework.
|
||||
|
||||
**esp-tools**
|
||||
A fork of riscv-tools, designed to work with the Hwacha non-standard RISC-V extension.
|
||||
This fork can also be used as an example demonstrating how to add additional RoCC accelerators to the ISA-level simulation (Spike) and the higher-level software toolchain (GNU binutils, riscv-opcodes, etc.)
|
||||
|
||||
Sims
|
||||
-------------------------------------------
|
||||
|
||||
**verisim (Verilator wrapper)**
|
||||
Verilator is an open source Verilog simulator.
|
||||
The ``verisim`` directory provides wrappers which construct Verilator-based simulators from relevant generated RTL, allowing for execution of test RISC-V programs on the simulator (including vcd waveform files).
|
||||
See :ref:`Verilator` for more information.
|
||||
|
||||
**vsim (VCS wrapper)**
|
||||
VCS is a proprietary Verilog simulator.
|
||||
Assuming the user has valid VCS licenses and installations, the ``vsim`` directory provides wrappers which construct VCS-based simulators from relevant generated RTL, allowing for execution of test RISC-V programs on the simulator (including vcd/vpd waveform files).
|
||||
See :ref:`VCS` for more information.
|
||||
|
||||
**FireSim**
|
||||
FireSim is an open-source FPGA-accelerated simulation platform, using Amazon Web Services (AWS) EC2 F1 instances on the public cloud.
|
||||
FireSim automatically transforms and instruments open-hardware designs into fast (10s-100s MHz), deterministic, FPGA-based simulators that enable productive pre-silicon verification and performance validation.
|
||||
To model I/O, FireSim includes synthesizeable and timing-accurate models for standard interfaces like DRAM, Ethernet, UART, and others.
|
||||
The use of the elastic public cloud enable FireSim to scale simulations up to thousands of nodes.
|
||||
In order to use FireSim, the repository must be cloned and executed on AWS instances.
|
||||
See :ref:`FireSim` for more information.
|
||||
|
||||
VLSI
|
||||
-------------------------------------------
|
||||
|
||||
**HAMMER**
|
||||
HAMMER is a VLSI flow designed to provide a layer of abstraction between general physical design concepts to vendor-specific EDA tool commands.
|
||||
The HAMMER flow provide automated scripts which generate relevant tool commands based on a higher level description of physical design constraints.
|
||||
The HAMMER flow also allows for re-use of process technology knowledge by enabling the construction of process-technology-specific plug-ins, which describe particular constraints relating to that process technology (obsolete standard cells, metal layer routing constraints, etc.).
|
||||
The HAMMER flow requires access to proprietary EDA tools and process technology libraries.
|
||||
See :ref:`HAMMER` for more information.
|
||||
@@ -1,86 +0,0 @@
|
||||
|
||||
|
||||
ReBAR Basics
|
||||
===============================
|
||||
|
||||
|
||||
Generators
|
||||
-------------------------------------------
|
||||
Generators are parametrized programs written as RTL code, designed to generate verilog code based on configuration specifications.
|
||||
Generators can be used to generate Systems-on-Chip (SoCs) using a collection of system components organized in unique generator projects.
|
||||
The ReBAR Framework currently consists of the following generators:
|
||||
|
||||
Processor Cores
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
**Rocket**
|
||||
An in-order RISC-V core.
|
||||
|
||||
**BOOM (Berkeley Out-of-Order Machine)**
|
||||
An out-of-order RISC-V core.
|
||||
|
||||
Data-Parallel Accelerators
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
**Hwacha**
|
||||
A decoupled vector architecture co-processor. Hwacha currently implements a non-standard RISC-V extension, using a vector architecture programming model.
|
||||
Hwacha integrates with a Rocket or BOOM core using the RoCC (Rocket Custom Co-processor) interface
|
||||
|
||||
|
||||
System Components:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
**icenet**
|
||||
A Network Interface Controller (NIC) designed to achieve up to 200 Gbps.
|
||||
|
||||
**sifive-blocks**
|
||||
System components implemented by SiFive and used by SiFive projects, designed to be integrated with the Rocket chip generator. These system and peripheral components include UART, SPI, JTAG, I2C, PWM, and other peripheral and interface devices.
|
||||
|
||||
**AWL (Analog Widget Library)**
|
||||
Digital components required for integration with high speed serial links.
|
||||
|
||||
**testchipip**
|
||||
A collection of utilites used for testing chips and interfacing them with larger test environments.
|
||||
|
||||
|
||||
Fixed Function Accelerators:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
TBD
|
||||
|
||||
|
||||
|
||||
Tools
|
||||
-------------------------------------------
|
||||
**Chisel**
|
||||
A hardware description library embedded in Scala. Chisel is used to write RTL generators using meta-programming, by emdedding hardware generation primitives in the Scala programming language. The Chisel compilter elaborate the generator into a FIRRTL output.
|
||||
|
||||
**FIRRTL**
|
||||
An intermediate representation library for RTL description of digital designs. FIRRTL is used as a formalized digital circuit representation between Chisel and Verilog. FIRRTL enables digital circuits manipulation between Chisel elaboration and Verilog generation.
|
||||
|
||||
**BARSTOOLS**
|
||||
A collection of common FIRRTL transformations used to manipulate a digital circuit without changing the generator source RTL.
|
||||
|
||||
|
||||
Toolchains
|
||||
-------------------------------------------
|
||||
**riscv-tools**
|
||||
A collection of software toolchains used to develope and execute software on the RISC-V ISA. The include compiler and assembler toolchains, functional ISA simulator (spike), the Berkeley Boot Loader (BBL) and proxy kernel. The riscv-tools repository was previously required to run any RISC-V software, however, many of the riscv-tools components have since been upstreamed to their respective open-source projects (Linux, GNU, etc.). Nevertheless, for consistent versioning, as well as software design flexibility for custom hardware, we include the riscv-tools repository and installation in the ReBAR framework.
|
||||
|
||||
|
||||
**esp-tools**
|
||||
A fork of riscv-tools, designed to work with the Hwacha non-standard RISC-V extension. This fork can also be used as an example demonstrating how to add additional RoCC accelerators to the ISA-level simulation (Spike) and the higher-level software toolchain (GNU binutils, riscv-opcodes, etc.)
|
||||
|
||||
|
||||
Sims
|
||||
-------------------------------------------
|
||||
**verisim (Verilator wrapper)**
|
||||
Verilator is an open source Verilog simulator. The verisim directory provides wrappers which construct verilator-based simulators from relevant generated RTL, allowing for execution of test RISC-V programs on the simulator (including vcd waveform files).
|
||||
|
||||
**vsim (VCS wrapper)**
|
||||
VCS is a proprietary Verilog simulator. Assuming the user has valid VCS licenses and installations, the vsim directory provides wrappers which construct VCS-based simulators from relevant generated RTL, allowing for execution of test RISC-V programs on the simulator (including vcd/vpd waveform files).
|
||||
|
||||
**FireSim**
|
||||
FireSim is an open-source FPGA-accelerated simulation platform, using Amazon Web Services (AWS) EC2 F1 instances on the public cloud. FireSim automatically transforms and instruments open-hardware designs into fast (10s-100s MHz), deterministic, FPGA-based simulators that enable productive pre-silicon verification and performance validation. To model I/O, FireSim includes synthesizeable and timing-accurate models for standard interfaces like DRAM, Ethernet, UART, and others. The use of the elastic public clound enable FireSim to scale simulations up to thousands of nodes. In order to use FireSim, the repository must be cloned and executed on AWS instances.
|
||||
|
||||
|
||||
VLSI
|
||||
-------------------------------------------
|
||||
**HAMMER**
|
||||
HAMMER is a VLSI flow designed to provide a layer of abstraction between general physical design concepts to vendor-specific EDA tool commands. The HAMMER flow provide automated scripts which generate relevant tool commands based on a higher level description of physical desing contraints. The HAMMER flow also allows for re-use of process technology knowledge by enabling the construction of process-technology-specific plug-ins, which describe particular contraints relating to that process technology (obsolete standard cells, metal layer routing contraints, etc.). The HAMMER flow requires access to proprietry EDA tools and process technology libraries.
|
||||
@@ -1,123 +1,103 @@
|
||||
Running A Simulation
|
||||
========================================================
|
||||
|
||||
ReBAR provides support and intergration for multiple simulation flows, for various user levels and requirments.
|
||||
In the majority of cases during a digital design development process, simple software RTL. When more advanced full-system evaluation is required, with long running workloads, FPGA-accelerated simulation will then become a preferable solution.
|
||||
|
||||
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, simple software RTL simulation is needed.
|
||||
When more advanced full-system evaluation is required, with long running workloads, FPGA-accelerated simulation will then become a preferable solution.
|
||||
|
||||
Software RTL Simulation
|
||||
------------------------
|
||||
The ReBAR framework provides wrappers for two common software RTL simulators: the open-source Verilator simulator. and the proprietry VCS simulator.The following instructions assume at least one of these simulators is installed.
|
||||
The REBAR framework provides wrappers for two common software RTL simulators:
|
||||
the open-source Verilator simulator and the proprietary VCS simulator.
|
||||
For more information on either of these simulators, please refer to :ref:`Verilator` or :ref:`VCS`.
|
||||
The following instructions assume at least one of these simulators is installed.
|
||||
|
||||
Verilator
|
||||
Verilator/VCS Flows
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Verilator is an open-source RTL simulator. We run Verilator simulations from within the ``sims/verisim`` directory. Therefore, we will start by entering that directory:
|
||||
Verilator is an open-source RTL simulator.
|
||||
We run Verilator simulations from within the ``sims/verisim`` directory which provides the necessary ``Makefile`` to both install and run Verilator simulations.
|
||||
On the other hand, VCS is a proprietary RTL simulator.
|
||||
We run VCS simulations from within the ``sims/vsim`` directory.
|
||||
Assuming VCS is already installed on the machine running simulations (and is found on our ``PATH``), then this guide is the same for both Verilator and VCS.
|
||||
|
||||
First, we will start by entering the Verilator or VCS directory:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
cd sims/verisim
|
||||
# Enter Verilator directory
|
||||
cd sims/verisim
|
||||
|
||||
In order to construct the simulator with our custom design, we run the following command within the ``sims/verisim`` directory:
|
||||
# OR
|
||||
|
||||
# Enter VCS directory
|
||||
cd sims/vsim
|
||||
|
||||
In order to construct the simulator with our custom design, we run the following command within the simulator directory:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make TOP=<my_top_level_name> CONFIG=<my_config_name> SBT_PROJECT=<my_sbt_package_name> MODEL=<my_test_environment>
|
||||
make SBT_PROJECT=... MODEL=... VLOG_MODEL=... MODEL_PACKAGE=... CONFIG=... CONFIG_PACKAGE=... GENERATOR_PACKAGE=... TB=... TOP=...
|
||||
|
||||
Where ``<my_top_level_name>`` is the class name of the top level design, ``<my_config_name>`` is the name of the class we create for our parameters configuration, ``<my_sbt_package_name>`` is the name of the sbt package the include both our top-level class and our config class, and ``<my_test_environment>`` is the name of the class which defines the test harness for our system.
|
||||
The ``make`` command may have additional parameters (such as ``CONFIG_PACKAGE`` or ``MODEL_PACKAGE``) depending on the complexity of the design and integration with multiple sub-project repositories in the sbt-based build system.
|
||||
Each of these make variables correspond to a particular part of the design/codebase and are needed so that the make system can correctly build and make a RTL simulation.
|
||||
The ``SBT_PROJECT`` is the ``build.sbt`` project that holds all of the source files and that will be run during the RTL build.
|
||||
The ``MODEL`` and ``VLOG_MODEL`` are the top-level class names of the design.
|
||||
Normally, these are the same, but in some cases these can differ (if the Chisel class differs than what is emitted in the Verilog).
|
||||
The ``MODEL_PACKAGE`` is the Scala package (in the Scala code that says ``package ...``) that holds the ``MODEL`` class.
|
||||
The ``CONFIG`` is the name of the class used for the parameter Config while the ``CONFIG_PACKAGE`` is the Scala package it resides in.
|
||||
The ``GENERATOR_PACKAGE`` is the Scala package that holds the Generator class that elaborates the design.
|
||||
The ``TB`` is the name of the Verilog wrapper that connects the ``TestHarness`` to VCS/Verilator for simulation.
|
||||
Finally, the ``TOP`` variable is used to distinguish between the top-level of the design and the ``TestHarness`` in our system.
|
||||
For example, in the normal case, the ``MODEL`` variable specifies the ``TestHarness`` as the top-level of the design.
|
||||
However, the true top-level design, the SoC being simulated, is pointed to by the ``TOP`` variable.
|
||||
This separation allows the infrastructure to separate files based on the harness or the SoC top level.
|
||||
|
||||
Common configurations are package using a ``SUB_PROJECT`` make variable. There, in order to simulate a simple Rocket-based example system we can use:
|
||||
Common configurations of all these variables are packaged using a ``SUB_PROJECT`` make variable.
|
||||
Therefore, in order to simulate a simple Rocket-based example system we can use:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make SUB_PROJECT=example
|
||||
make SUB_PROJECT=example
|
||||
|
||||
Alternatively, if we would like to simulate a simple BOOM-based example system we can use:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make SUB_PROJECT=exampleboom
|
||||
make SUB_PROJECT=exampleboom
|
||||
|
||||
|
||||
Once the simulator has been constructed, we would like to run RISC-V programs on it. In the `sims/verisim` directory, we will find an executable file called `TODO`. We run this executable with out target RISC-V program as a command line argument. For example:
|
||||
Once the simulator has been constructed, we would like to run RISC-V programs on it.
|
||||
In the simulation directory, we will find an executable file called ``<...>-<package>-<config>``.
|
||||
We run this executable with our target RISC-V program as a command line argument in one of two ways.
|
||||
One, we can directly call the simulator binary or use make to run the binary for us with extra simulation flags.
|
||||
For example:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
./simulator-<my_sbt_package_name>-<my_config_name> my_program_binary
|
||||
# directly calling the simulation binary
|
||||
./<...>-<package>-<config> my_program_binary
|
||||
|
||||
Alternatively, we can run a pre-packaged suite of RISC-V assembly tests, by adding the make target run-asm-tests. For example
|
||||
# using make to do it
|
||||
make SUB_PROJECT=example BINARY=my_program_binary run-binary
|
||||
|
||||
Alternatively, we can run a pre-packaged suite of RISC-V assembly or benchmark tests, by adding the make target ``run-asm-tests`` or ``run-bmark-tests``.
|
||||
For example:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make run-asm-tests TOP=<my_top_level_name> CONFIG=<my_config_name> SBT_PROJECT=<my_sbt_package_name> MODEL=<my_test_environment>
|
||||
|
||||
or
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make run-asm-tests SUB_PROJECT=example
|
||||
|
||||
|
||||
|
||||
VCS
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
VCS is a proprietry RTL simulator. This guide assumes that the VCS installation is found on our PATH. We run VCS simulations from within the ``sims/vsim`` directory. Therefore, we will start by entering the directory:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
cd sims/vsim
|
||||
|
||||
|
||||
In order to construct the simulator with our custom design, we run the following command within the ``sims/vsim`` directory:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make TOP=<my_top_level_name> CONFIG=<my_config_name> SBT_PROJECT=<my_sbt_package_name> MODEL=<my_test_environment>
|
||||
|
||||
Where ``<my_top_level_name>`` is the class name of the top level design, ``<my_config_name>`` is the name of the class we create for our parameters configuration, ``<my_sbt_package_name>`` is the name of the sbt package the include both our top-level class and our config class, and ``<my_test_environment>`` is the name of the class which defines the test harness for our system.
|
||||
The ``make`` command my have additional parameters (such as ``CONFIG_PACKAGE`` or ``MODEL_PACKAGE``) depending on the complexity of the design and integration with multiple sub-project repositories in the sbt-based build system.
|
||||
|
||||
Common configurations are package using a ``SUB_PROJECT`` make variable. There, in order to simulate a simple Rocket-based example system we can use:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make SUB_PROJECT=example
|
||||
|
||||
Alternatively, if we would like to simulate a simple BOOM-based example system we can use:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make SUB_PROJECT=exampleboom
|
||||
|
||||
|
||||
Once the simulator has been constructed, we would like to run RISC-V programs on it. In the ``sims/vsim`` directory, we will find an executable file called ``TODO``. We run this executable with out target RISC-V program as a command line argument. For example:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
./simulator-<my_sbt_package_name>-<my_config_name> my_program_binary
|
||||
|
||||
Alternatively, we can run a pre-packaged suite of RISC-V assembly tests, by adding the make target run-asm-tests. For example
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make run-asm-tests TOP=<my_top_level_name> CONFIG=<my_config_name> SBT_PROJECT=<my_sbt_package_name> MODEL=<my_test_environment>
|
||||
|
||||
or
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
make run-asm-tests SUB_PROJECT=example
|
||||
|
||||
make SUB_PROJECT=example run-asm-tests
|
||||
make SUB_PROJECT=example run-bmark-tests
|
||||
|
||||
Note: You need to specify all the make variables once again to match what the build gave to run the assembly tests or the benchmarks or the binaries if you are using the make option.
|
||||
|
||||
FPGA Accelerated Simulation
|
||||
---------------------------
|
||||
FireSim enables simulations at 1000x-100000x the speed of standard software simulation. This is enabled using FPGA-acceleration on F1 instances of the AWS (Amazon Web Services) public cloud. There FireSim simulation require to be set-up on the AWS public cloud rather than on our local development machine.
|
||||
FireSim enables simulations at 1000x-100000x the speed of standard software simulation.
|
||||
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 specificied 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.
|
||||
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.
|
||||
|
||||
TODO: Continue from here
|
||||
|
||||
|
||||
|
||||
@@ -1,9 +1,7 @@
|
||||
.. _Getting Started:
|
||||
|
||||
Getting Started
|
||||
================================
|
||||
|
||||
These guides will walk you through the basics of the ReBAR framework:
|
||||
These guides will walk you through the basics of the REBAR framework:
|
||||
|
||||
- First, we will go over the different configurations avaliable.
|
||||
|
||||
@@ -15,8 +13,8 @@ Hit next to get started!
|
||||
:maxdepth: 2
|
||||
:caption: Getting Started:
|
||||
|
||||
ReBAR-Basics
|
||||
Configs-Parameters-Mixins
|
||||
REBAR-Basics
|
||||
Configs-Parameters-Mixins
|
||||
Adding-An-Accelerator-Tutorial
|
||||
Running-A-Simulation
|
||||
rebar-generator-mixins
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
|
||||
|
||||
SoC Generator Config Mix-ins:
|
||||
==============================
|
||||
|
||||
@@ -88,8 +86,8 @@ SiFive Blocks
|
||||
- HasSPIProtocol
|
||||
- HasSPIEndian
|
||||
- HasSPILength
|
||||
- HasSPICSMode
|
||||
- HasPeripherySPIFlash
|
||||
- HasSPICSMode
|
||||
- HasPeripherySPIFlash
|
||||
- HasPeripheryUART
|
||||
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
# You can set these variables from the command line.
|
||||
SPHINXOPTS =
|
||||
SPHINXBUILD = python -msphinx
|
||||
SPHINXPROJ = ReBAR
|
||||
SPHINXPROJ = REBAR
|
||||
SOURCEDIR = .
|
||||
BUILDDIR = _build
|
||||
|
||||
@@ -17,4 +17,4 @@ help:
|
||||
# Catch-all target: route all unknown targets to Sphinx using the new
|
||||
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
|
||||
%: Makefile
|
||||
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
||||
@@ -1,33 +1,37 @@
|
||||
Commericial Software RTL Simulators
|
||||
==============================
|
||||
The ReBAR framework currently supports only the VCS commerical simulator
|
||||
|
||||
VCS
|
||||
-----------------------
|
||||
VCS is a commercial RTL simulator developed by Synopsys. It requires commerical licenses.
|
||||
The ReBAR framework can compile and execute simulations using VCS. VCS simulation will generally compile
|
||||
faster than Verilator simulations.
|
||||
|
||||
`VCS <https://www.synopsys.com/verification/simulation/vcs.html>`__ is a commercial RTL simulator developed by Synopsys.
|
||||
It requires commerical licenses.
|
||||
The REBAR framework can compile and execute simulations using VCS.
|
||||
VCS simulation will generally compile faster than Verilator simulations.
|
||||
|
||||
To run a simulation using VCS, perform the following steps:
|
||||
|
||||
Make sure that the VCS simulator is on your `PATH`.
|
||||
Make sure that the VCS simulator is on your ``PATH``.
|
||||
|
||||
To compile the example design, run make in the ``sims/vsim`` directory.
|
||||
This will elaborate the DefaultExampleConfig in the example project.
|
||||
This will elaborate the ``DefaultRocketConfig`` in the example project.
|
||||
|
||||
An executable called simulator-example-DefaultExampleConfig will be produced.
|
||||
An executable called ``simulator-example-DefaultRocketConfig`` will be produced.
|
||||
This executable is a simulator that has been compiled based on the design that was built.
|
||||
You can then use this executable to run any compatible RV64 code. For instance,
|
||||
to run one of the riscv-tools assembly tests.
|
||||
You can then use this executable to run any compatible RV64 code.
|
||||
For instance, to run one of the riscv-tools assembly tests.
|
||||
|
||||
::
|
||||
./simulator-example-DefaultExampleConfig $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple
|
||||
.. code-block:: shell
|
||||
./simulator-example-DefaultRocketConfig $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple
|
||||
|
||||
If you later create your own project, you can use environment variables to
|
||||
build an alternate configuration.
|
||||
If you later create your own project, you can use environment variables to build an alternate configuration.
|
||||
|
||||
::
|
||||
make PROJECT=yourproject CONFIG=YourConfig
|
||||
./simulator-yourproject-YourConfig ...
|
||||
.. code-block:: shell
|
||||
make SUB_PROJECT=yourproject
|
||||
./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. If you have Synopsys licenses, we recommend using the DVE waveform viewers
|
||||
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.
|
||||
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.
|
||||
|
||||
@@ -3,11 +3,15 @@ FPGA-Based Simulators
|
||||
|
||||
FireSim
|
||||
-----------------------
|
||||
FireSim is an open-source cycle-accurate FPGA-accelerated full-system hardware simulation platform that runs on cloud FPGAs (Amazon EC2 F1).
|
||||
FireSim allows RTL-level simulation at orders-of-magnitude faster speeds than software RTL simulators. FireSim also provides additional device models to allow full-system simulation, including memory models and network models.
|
||||
|
||||
FireSim currently supports running only on Amazon EC2 F1 FPGA-enabled virtual instances on the public cloud. In order to simulate your ReBAR design using FireSim, you should follow the following steps:
|
||||
`FireSim <https://fires.im/>`__ is an open-source cycle-accurate FPGA-accelerated full-system hardware simulation platform that runs on cloud FPGAs (Amazon EC2 F1).
|
||||
FireSim allows RTL-level simulation at orders-of-magnitude faster speeds than software RTL simulators.
|
||||
FireSim also provides additional device models to allow full-system simulation, including memory models and network models.
|
||||
|
||||
Follow the initial EC2 setup instructions as detailed in the `FireSim documentation <http://docs.fires.im/en/latest/Initial-Setup/index.html>`__ .. Then clone your full ReBAR repository onto your Amazon EC2 FireSim manager instance.
|
||||
FireSim currently supports running only on Amazon EC2 F1 FPGA-enabled virtual instances on the public cloud.
|
||||
In order to simulate your REBAR design using FireSim, you should follow the following steps:
|
||||
|
||||
Follow the initial EC2 setup instructions as detailed in the `FireSim documentation <http://docs.fires.im/en/latest/Initial-Setup/index.html>`__.
|
||||
Then clone your full REBAR repository onto your Amazon EC2 FireSim manager instance.
|
||||
|
||||
Enter the ``sims/FireSim`` directory, and follow the FireSim instructions for `running a simulation <http://docs.fires.im/en/latest/Running-Simulations-Tutorial/index.html>`__.
|
||||
|
||||
@@ -3,31 +3,31 @@ Open Source Software RTL Simulators
|
||||
|
||||
Verilator
|
||||
-----------------------
|
||||
Verilator is an open-source LGPL-Licensed simulator maintained by `Veripool <https://www.veripool.org/>`__
|
||||
The ReBAR framework can download, build, and execute simulations using Verilator.
|
||||
|
||||
To run a simulation using verilator, perform the following steps:
|
||||
`Verilator <https://www.veripool.org/wiki/verilator>`__ is an open-source LGPL-Licensed simulator maintained by `Veripool <https://www.veripool.org/>`__.
|
||||
The REBAR framework can download, build, and execute simulations using Verilator.
|
||||
|
||||
To compile the example design, run make in the ``sims/verisim`` directory.
|
||||
This will elaborate the DefaultExampleConfig in the example project.
|
||||
To run a simulation using Verilator, perform the following steps:
|
||||
|
||||
An executable called simulator-example-DefaultExampleConfig will be produced.
|
||||
To compile the example design, run ``make`` in the ``sims/verisim`` directory.
|
||||
This will elaborate the ``DefaultRocketConfig`` in the example project.
|
||||
|
||||
An executable called ``simulator-example-DefaultRocketConfig`` will be produced.
|
||||
This executable is a simulator that has been compiled based on the design that was built.
|
||||
You can then use this executable to run any compatible RV64 code. For instance,
|
||||
to run one of the riscv-tools assembly tests.
|
||||
You can then use this executable to run any compatible RV64 code.
|
||||
For instance, to run one of the riscv-tools assembly tests.
|
||||
|
||||
::
|
||||
./simulator-example-DefaultExampleConfig $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple
|
||||
.. code-block:: shell
|
||||
./simulator-example-DefaultRocketConfig $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple
|
||||
|
||||
If you later create your own project, you can use environment variables to
|
||||
build an alternate configuration.
|
||||
|
||||
::
|
||||
make PROJECT=yourproject CONFIG=YourConfig
|
||||
./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 vcd file (vcd is a standard waveform representation file format) that can be loaded to any common waveform viewer. An open-source vcd-capable waveform viewer is `GTKWave <http://gtkwave.sourceforge.net/>__
|
||||
If you later create your own project, you can use environment variables to build an alternate configuration.
|
||||
|
||||
.. code-block:: shell
|
||||
make SUB_PROJECT=yourproject
|
||||
./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 vcd file (vcd is a standard waveform representation file format) that can be loaded to any common waveform viewer.
|
||||
An open-source vcd-capable waveform viewer is `GTKWave <http://gtkwave.sourceforge.net/>`__.
|
||||
|
||||
Please refer to :ref:`Running A Simulation` for a step by step tutorial on how to get a simulator up and running.
|
||||
|
||||
@@ -1,8 +1,10 @@
|
||||
Simulators
|
||||
=======================
|
||||
|
||||
ReBAR provides support and intergration for multiple simulation flows, for various user levels and requirments.
|
||||
In the majority of cases during a digital design development process, simple software RTL. 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.
|
||||
REBAR provides support and intergration for multiple simulation flows, for various user levels and requirments.
|
||||
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.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
Barstools
|
||||
===============================
|
||||
Barstools is a collection of useful FIRRTL transformations
|
||||
|
||||
Barstools is a collection of useful FIRRTL transformations and Compilers to help the build process.
|
||||
Included in the tools are a MacroCompiler (used to map Chisel memory constructs to vendor SRAMs), FIRRTL transforms (to separate harness and top-level SoC files), and more.
|
||||
|
||||
@@ -1,3 +1,19 @@
|
||||
Chisel
|
||||
===========================
|
||||
TODO: Chisel intro and pointer to chisel bootcamp
|
||||
|
||||
`Chisel <https://chisel.eecs.berkeley.edu/>`__ is an open-source hardware description language embedded in Scala.
|
||||
It supports advanced hardware design using highly parameterized generators and supports things such as Rocket Chip and BOOM.
|
||||
|
||||
After writing Chisel, there are multiple steps before the Chisel source code "turns into" Verilog.
|
||||
First is the compilation step.
|
||||
If Chisel is thought as a library within Scala, then these classes being built are just Scala classes which call Chisel functions.
|
||||
Thus, any errors that you get in compiling the Scala/Chisel files are errors that you have violated the typing system, messed up syntax, or more.
|
||||
After the compilation is complete, elaboration begins.
|
||||
The Chisel generator starts elaboration using the module and configuration classes passed to it.
|
||||
This is where the Chisel "library functions" are called with the parameters given and Chisel tries to construct a circuit based on the Chisel code.
|
||||
If a runtime error happens here, Chisel is stating that it cannot "build" your circuit due to "violations" between your code and the Chisel "library".
|
||||
However, if that passes, the output of the generator gives you an FIRRTL file and other misc collateral!
|
||||
See :ref:`FIRRTL` for more information on how to get a FIRRTL file to Verilog.
|
||||
|
||||
For an interactive tutorial on how to use Chisel and get started please visit the `Chisel Bootcamp <https://github.com/freechipsproject/chisel-bootcamp>`__.
|
||||
Otherwise, for all things Chisel related including API documentation, news, etc, visit their `website <>`__.
|
||||
|
||||
@@ -1,3 +1,12 @@
|
||||
FIRRTL
|
||||
================================
|
||||
|
||||
`FIRRTL <https://github.com/freechipsproject/firrtl>`__ is an intermediate representation of your circuit.
|
||||
It is emitted by the Chisel compiler and is used to translate Chisel source files into another representation such as Verilog.
|
||||
Without going into too much detail, FIRRTL is consumed by a FIRRTL compiler (another Scala program) which passes the circuit through a series of circuit-level transformations.
|
||||
An example of a FIRRTL pass (transformation) is one that optimizes out unused signals.
|
||||
Once the transformations are done, a Verilog file is emitted and the build process is done.
|
||||
|
||||
For more information on please visit their `website <https://freechipsproject.github.io/firrtl/>`__.
|
||||
|
||||
|
||||
|
||||
@@ -1,7 +1,8 @@
|
||||
Tools
|
||||
==============================
|
||||
The ReBAR framework relays heavily on a set of scala-based tools. While the framework attempts to hide the complexities of these tools, the following pages will introduce them, and how we can use them in order to generate flexible designs
|
||||
|
||||
The REBAR framework relays heavily on a set of Scala-based tools.
|
||||
The following pages will introduce them, and how we can use them in order to generate flexible designs.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
7
docs/VLSI/HAMMER.rst
Normal file
7
docs/VLSI/HAMMER.rst
Normal file
@@ -0,0 +1,7 @@
|
||||
HAMMER
|
||||
================================
|
||||
|
||||
`HAMMER <https://github.com/ucb-bar/hammer>`__ is a physical design generator that wraps around vendor specific technologies and tools to provide a single API to create ASICs.
|
||||
HAMMER allows for reusability in ASIC design while still providing the designers leeway to make their own modifications.
|
||||
|
||||
For more information, read the `HAMMER paper <https://people.eecs.berkeley.edu/~edwardw/pubs/hammer-woset-2018.pdf>`__ and see the `GitHub repository <https://github.com/ucb-bar/hammer>`__.
|
||||
@@ -1,8 +1,11 @@
|
||||
VLSI Production
|
||||
================================
|
||||
The ReBAR framework aim to provide wrappers to a general VLSI flow.
|
||||
|
||||
The REBAR framework aim to provide wrappers to a general VLSI flow.
|
||||
In particular, we aim to support the HAMMER flow.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: VLSI Production:
|
||||
|
||||
HAMMER
|
||||
|
||||
14
docs/conf.py
14
docs/conf.py
@@ -1,6 +1,6 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# ReBAR documentation build configuration file, created by
|
||||
# REBAR documentation build configuration file, created by
|
||||
# sphinx-quickstart on Fri Mar 8 11:46:38 2019.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its
|
||||
@@ -51,7 +51,7 @@ source_suffix = '.rst'
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = u'ReBAR'
|
||||
project = u'REBAR'
|
||||
copyright = u'2019, Berkeley Architecture Research'
|
||||
author = u'Berkeley Architecture Research'
|
||||
|
||||
@@ -124,7 +124,7 @@ html_sidebars = {
|
||||
# -- Options for HTMLHelp output ------------------------------------------
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'ReBARdoc'
|
||||
htmlhelp_basename = 'REBARdoc'
|
||||
|
||||
|
||||
# -- Options for LaTeX output ---------------------------------------------
|
||||
@@ -151,7 +151,7 @@ latex_elements = {
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'ReBAR.tex', u'ReBAR Documentation',
|
||||
(master_doc, 'REBAR.tex', u'REBAR Documentation',
|
||||
u'Berkeley Architecture Research', 'manual'),
|
||||
]
|
||||
|
||||
@@ -161,7 +161,7 @@ latex_documents = [
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'rebar', u'ReBAR Documentation',
|
||||
(master_doc, 'rebar', u'REBAR Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
@@ -172,8 +172,8 @@ man_pages = [
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'ReBAR', u'ReBAR Documentation',
|
||||
author, 'ReBAR', 'One line description of project.',
|
||||
(master_doc, 'REBAR', u'REBAR Documentation',
|
||||
author, 'REBAR', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
|
||||
@@ -1,47 +1,18 @@
|
||||
.. ReBAR documentation master file, created by
|
||||
.. REBAR documentation master file, created by
|
||||
sphinx-quickstart on Fri Mar 8 11:46:38 2019.
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
Welcome to ReBAR's documentation!
|
||||
Welcome to REBAR's documentation!
|
||||
=================================
|
||||
|
||||
ReBAR is a a framework for designing and evaluating full-system hardware using agile teams. It is composed of a collection of tools and libraries designed to provide an intergration between open-source and commercial tools for the development of systems-on-chip. New to ReBAR? Jump to the :ref:`rebar-basics` page for more info.
|
||||
|
||||
|
||||
The documentation outline should look like this
|
||||
|
||||
Getting Started:
|
||||
|
||||
ReBAR-Basics
|
||||
Initial-Setup/index
|
||||
Creating-Configuration-Tutorial/index
|
||||
Adding-An-Accelerator-Tutorial/index
|
||||
Running-Simulations-Tutorial/index
|
||||
Building-Chips-Tutorial/index
|
||||
|
||||
Generators:
|
||||
|
||||
Generators/Rocketchip/index
|
||||
Generators/BOOM/index
|
||||
Generators/Hwacha/index
|
||||
|
||||
|
||||
Simulation:
|
||||
Simulation/Open-Source-Simulators/index
|
||||
Simulation/Commercial-Simulators/index
|
||||
Simulation/FPGA-Based-Simulation/index
|
||||
|
||||
|
||||
|
||||
Production:
|
||||
|
||||
Production/VLSI-Physical-Design/index
|
||||
Software/Toolchains/index
|
||||
REBAR is a a framework for designing and evaluating full-system hardware using agile teams.
|
||||
It is composed of a collection of tools and libraries designed to provide an intergration between open-source and commercial tools for the development of systems-on-chip.
|
||||
New to REBAR? Jump to the :ref:`Getting Starting` page for more info.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:caption: Getting Started:
|
||||
:caption: Contents:
|
||||
:numbered:
|
||||
|
||||
Getting-Started/index
|
||||
|
||||
Reference in New Issue
Block a user