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

Merge remote-tracking branch 'origin/main' into serial-phits

Browse Source
This commit is contained in:
Jerry Zhao
2024-02-05 12:00:41 -08:00
parent 740f4ebbb3 0c30f9c5e9
commit a23903f10e
18 changed files with 192 additions and 161 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.gitmodules vendored
View File

@@ -1,10 +1,10 @@
[submodule "rocket-chip"]
[submodule "generators/rocket-chip"]
path = generators/rocket-chip
url = https://github.com/chipsalliance/rocket-chip.git
[submodule "testchipip"]
[submodule "generators/testchipip"]
path = generators/testchipip
url = https://github.com/ucb-bar/testchipip.git
[submodule "barstools"]
[submodule "tools/barstools"]
path = tools/barstools
url = https://github.com/ucb-bar/barstools.git
[submodule "tools/torture"]

22
docs/Advanced-Concepts/Chip-Communication.rst
View File

@@ -198,25 +198,3 @@ bringup design).
:language: scala
:start-after: DOC include start: TetheredChipLikeRocketConfig
:end-before: DOC include end: TetheredChipLikeRocketConfig
Softcore-driven Bringup Setup of the Example Test Chip after Tapeout
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. warning::
Bringing up test chips with a FPGA softcore as described here is discouraged.
An alternative approach using the FPGA to "bridge" between a host computer and the test chip is the preferred approach.
Assuming this example test chip is taped out and now ready to be tested, we can communicate with the chip using this serial-link.
For example, a common test setup used at Berkeley to evaluate Chipyard-based test-chips includes an FPGA running a RISC-V soft-core that is able to speak to the DUT (over an FMC).
This RISC-V soft-core would serve as the host of the test that will run on the DUT.
This is done by the RISC-V soft-core running FESVR, sending TSI commands to a ``TSIToTileLink`` / ``TLSerdesser`` programmed on the FPGA.
Once the commands are converted to serialized TileLink, then they can be sent over some medium to the DUT
(like an FMC cable or a set of wires connecting FPGA outputs to the DUT board).
Similar to simulation, if the chip requests offchip memory, it can then send the transaction back over the serial-link.
Then the request can be serviced by the FPGA DRAM.
The following image shows this flow:
.. image:: ../_static/images/chip-bringup.png
In fact, this exact type of bringup setup is what the following section discusses:
:ref:_legacy-vcu118-bringup.

2
docs/Customization/Boot-Process.rst
View File

@@ -74,6 +74,6 @@ mode, thus starting userspace execution.
The easiest way to build a BBL image that boots Linux is to use the FireMarshal
tool that lives in the `firesim-software <https://github.com/firesim/firesim-software>`_
repository. Directions on how to use FireMarshal can be found in the
:fsim_doc:`FireSim documentation <Advanced-Usage/FireMarshal/index.html>`.
:fsim_doc:`FireSim documentation <Advanced-Usage/Workloads/FireMarshal.html>`.
Using FireMarshal, you can add custom kernel configurations and userspace software
to your workload.

14
docs/Customization/Incorporating-Verilog-Blocks.rst
View File

@@ -99,10 +99,16 @@ Instantiating the BlackBox and Defining MMIO
Next, we must instantiate the blackbox. In order to take advantage of
diplomatic memory mapping on the system bus, we still have to
integrate the peripheral at the Chisel level by mixing
peripheral-specific traits into a ``TLRegisterRouter``. The ``params``
member and ``HasRegMap`` base trait should look familiar from the
previous memory-mapped GCD device example.
integrate the peripheral at the Chisel level by instantiating a LazyModule wrapper
that instantiates a TileLink RegisterNode.
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD router
:end-before: DOC include end: GCD router
Within the LazyModule, the ``regmap`` function can be called to attach wires and
registers to the MMIO port.
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala

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

@@ -3,14 +3,15 @@
MMIO Peripherals
==================
The easiest way to create a MMIO peripheral is to use the ``TLRegisterRouter`` or ``AXI4RegisterRouter`` widgets, which abstracts away the details of handling the interconnect protocols and provides a convenient interface for specifying memory-mapped registers. Since Chipyard and Rocket Chip SoCs primarily use Tilelink as the on-chip interconnect protocol, this section will primarily focus on designing Tilelink-based peripherals. However, see ``generators/chipyard/src/main/scala/example/GCD.scala`` for how an example AXI4 based peripheral is defined and connected to the Tilelink graph through converters.
The easiest way to create a MMIO peripheral is to follow the GCD TileLink MMIO example. Since Chipyard and Rocket Chip SoCs primarily use Tilelink as the on-chip interconnect protocol, this section will primarily focus on designing Tilelink-based peripherals. However, see ``generators/chipyard/src/main/scala/example/GCD.scala`` for how an example AXI4 based peripheral is defined and connected to the Tilelink graph through converters.
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.
To create a MMIO-mapped peripheral, you will need to specify a ``LazyModule`` wrapper containing the TileLink port as a Diplomacy Node, as well as an internal ``LazyModuleImp`` class that defines the MMIO's implementation and any non-TileLink I/O.
For this example, we will show how to connect a MMIO peripheral which computes the GCD.
The full code can be found in ``generators/chipyard/src/main/scala/example/GCD.scala``.
In this case we use a submodule ``GCDMMIOChiselModule`` to actually perform the GCD. The ``GCDModule`` class only creates the registers and hooks them up using ``regmap``.
In this case we use a submodule ``GCDMMIOChiselModule`` to actually perform the GCD. The ``GCDTL`` and ``GCDAXI4`` classes are the ``LazyModule`` classes which construct the TileLink or AXI4 ports, wrapping the inner ``GCDMMIOChiselModule``.
The ``node`` object is a Diplomacy node, which connects the peripheral to the Diplomacy interconnect graph.
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
@@ -19,8 +20,9 @@ In this case we use a submodule ``GCDMMIOChiselModule`` to actually perform the
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD instance regmap
:end-before: DOC include end: GCD instance regmap
:start-after: DOC include start: GCD router
:end-before: DOC include end: GCD router
Advanced Features of RegField Entries
-------------------------------------
@@ -41,15 +43,31 @@ triggering the GCD algorithm when ``y`` is written. Therefore, the
algorithm is set up by first writing ``x`` and then performing a
triggering write to ``y``. Polling can be used for status checks.
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD instance regmap
:end-before: DOC include end: GCD instance regmap
.. note::
In older versions of Chipyard and Rocket-Chip, a ``TLRegisterRouter`` abstrat
class was used to abstract away the construction of the ``TLRegisterNode`` and
``LazyModule`` classes necessary to construct MMIO peripherals. This was removed,
in favor of requiring users to explicitly construct the necessary classes.
This matches more closely how standard ``Modules`` and ``LazyModules`` are
constructed, making it clearer how a MMIO peripheral fits into the ``Module``
and ``LazyModule`` design patterns.
Connecting by TileLink
----------------------
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.
Notice how we can create an analogous AXI4 version of our peripheral.
The key to connecting to the TileLink Diplomatic graph is the construction of the TileLink node for this peripheral.
In this case, since the peripheral acts as a manager of some register-mapped address space, it uses the ``TLRegisterNode`` object.
The parameters to the ``TLRegisterNode`` object specify the size of the managed space, the base address, and the port width.
Within the register-mapped peripheral, the control registers can be mapped using the ``node.regmap`` function, as described above.
A similar procedure is followed for both AXI4 and TileLin peripherals.
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
@@ -62,24 +80,18 @@ Top-level Traits
----------------
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.
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`` abstract class containst the TileLink node representing the peripheral's I/O.
For a simple memory-mapped peripheral, connecting the peripheral's TileLink node must be connected to the relevant bu.
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD lazy trait
:end-before: DOC include end: GCD lazy trait
Note that the ``GCDTL`` class we created from the register router is itself a ``LazyModule``.
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.
Also observe how we have to place additional AXI4 buffers and converters for the AXI4 version of this peripheral.
Peripherals which expose I/O can use `InModuleBody` to punch their I/O to the `DigitalTop` module.
In this example, the GCD module's ``gcd_busy`` signal is exposed as a I/O of DigitalTop.
Constructing the DigitalTop and Config
--------------------------------------

2
docs/Generators/Hwacha.rst
View File

@@ -5,7 +5,7 @@ The Hwacha project is developing a new vector architecture for future computer s
The Hwacha project is inspired by traditional vector machines from the 70s and 80s, and lessons learned from our previous vector-thread architectures such as Scale and Maven
The Hwacha project includes the Hwacha microarchitecture generator, as well as the ``XHwacha`` non-standard RISC-V extension. Hwacha does not implement the RISC-V standard vector extension proposal.
For more information on the Hwacha project, please visit the `Hwacha website <http://hwacha.org/>`__.
For more information on the Hwacha project, please visit the `Hwacha website <https://bar.eecs.berkeley.edu/projects/hwacha.html>`__ or search for "Krste Asanovic Hwacha" on Google Scholar for publications.
To add the Hwacha vector unit to an SoC, you should add the ``hwacha.DefaultHwachaConfig`` config fragment to the SoC configurations. The Hwacha vector unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the `System Bus` (i.e., directly to the L2 cache).

14
docs/Prototyping/VCU118.rst
View File

@@ -47,20 +47,6 @@ After the harness is created, the ``BundleBridgeSource``'s must be connected to
This is done with harness binders and io binders (see ``fpga/src/main/scala/vcu118/HarnessBinders.scala`` and ``fpga/src/main/scala/vcu118/IOBinders.scala``).
For more information on harness binders and io binders, refer to :ref:`Customization/IOBinders:IOBinders and HarnessBinders`.
(Legacy) Introduction to the Legacy Bringup Design
--------------------------------------------------
.. warning::
The bringup VCU118 design described here is designed for old versions of Chipyard SoCs, pre-1.9.1.
The key difference is that these designs rely on a clock generated on-chip to synchronize the slow serialized-TileLink interface.
After Chipyard 1.9.1, the FPGA host is expected to pass the clock to the chip, instead of the other way around.
A new bringup solution will be developed for post-1.9.1 Chipyard designs.
An example of a more complicated design used for Chipyard test chips can be viewed in ``fpga/src/main/scala/vcu118/bringup/``.
This example extends the default test harness and creates new ``Overlays`` to connect to a DUT (connected to the FMC port).
Extensions include another UART (connected over FMC), I2C (connected over FMC), miscellaneous GPIOS (can be connected to anything), and a TSI Host Widget.
The TSI Host Widget is used to interact with the DUT from the prototype over a SerDes link (sometimes called the Low BandWidth InterFace - LBWIF) and provide access to a channel of the FPGA's DRAM.
.. Note:: Remember that since whenever a new test harness is created (or the config changes, or the config packages changes, or...), you need to modify the make invocation.
For example, ``make SUB_PROJECT=vcu118 CONFIG=MyNewVCU118Config CONFIG_PACKAGE=this.is.my.scala.package bitstream``.
See :ref:`Prototyping/General:Generating a Bitstream` for information on the various make variables.

2
docs/TileLink-Diplomacy-Reference/NodeTypes.rst
View File

@@ -134,7 +134,7 @@ to handle TileLink requests, it is usually much easier to use a register node.
This type of node provides a ``regmap`` method that allows you to specify
control/status registers and automatically generates the logic to handle the
TileLink protocol. More information about how to use register nodes can be
found in :ref:`TileLink-Diplomacy-Reference/Register-Router:Register Router`.
found in :ref:`TileLink-Diplomacy-Reference/Register-Node:Register Node`.
Identity Node
-------------

15
docs/TileLink-Diplomacy-Reference/Register-Router.rst → docs/TileLink-Diplomacy-Reference/Register-Node.rst
View File

@@ -1,4 +1,4 @@
Register Router
Register Node
===============
Memory-mapped devices generally follow a common pattern. They expose a set
@@ -10,10 +10,7 @@ While designers can manually instantiate a manager node and write the logic
for exposing registers themselves, it's much easier to use RocketChip's
``regmap`` interface, which can generate most of the glue logic.
For TileLink devices, you can use the ``regmap`` interface by extending
the ``TLRegisterRouter`` class, as shown in :ref:`mmio-accelerators`,
or you can create a regular LazyModule and instantiate a ``TLRegisterNode``.
This section will focus on the second method.
For TileLink devices, you can use the ``regmap`` interface of the ``TLRegisterNode``.
Basic Usage
-----------
@@ -32,7 +29,7 @@ The default value is 4 bytes. The ``concurrency`` argument is the size of the
internal queue for TileLink requests. By default, this value is 0, which means
there will be no queue. This value must be greater than 0 if you wish to
decoupled requests and responses for register accesses. This is discussed
in :ref:`TileLink-Diplomacy-Reference/Register-Router:Using Functions`.
in :ref:`TileLink-Diplomacy-Reference/Register-Node:Using Functions`.
The main way to interact with the node is to call the ``regmap`` method, which
takes a sequence of pairs. The first element of the pair is an offset from the
@@ -123,12 +120,12 @@ output for write.
In order to use this variant, you need to set ``concurrency`` to a value
larger than 0.
Register Routers for Other Protocols
Register Nodes for Other Protocols
------------------------------------
One useful feature of the register router interface is that you can easily
One useful feature of the register node interface is that you can easily
change the protocol being used. For instance, in the first example in
:ref:`TileLink-Diplomacy-Reference/Register-Router:Basic Usage`, you could simply change the ``TLRegisterNode`` to
:ref:`TileLink-Diplomacy-Reference/Register-Node:Basic Usage`, you could simply change the ``TLRegisterNode`` to
and ``AXI4RegisterNode``.
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/RegisterNodeExample.scala

2
docs/TileLink-Diplomacy-Reference/index.rst
View File

@@ -28,5 +28,5 @@ A detailed specification of the TileLink 1.7 protocol can be found on the
NodeTypes
Diplomacy-Connectors
EdgeFunctions
Register-Router
Register-Node
Widgets

191
generators/chipyard/src/main/scala/example/GCD.scala
View File

@@ -4,6 +4,7 @@ import chisel3._
import chisel3.util._
import chisel3.experimental.{IntParam, BaseModule}
import freechips.rocketchip.amba.axi4._
import freechips.rocketchip.prci._
import freechips.rocketchip.subsystem.BaseSubsystem
import org.chipsalliance.cde.config.{Parameters, Field, Config}
import freechips.rocketchip.diplomacy._
@@ -36,27 +37,24 @@ class GCDIO(val w: Int) extends Bundle {
val busy = Output(Bool())
}
trait GCDTopIO extends Bundle {
class GCDTopIO extends Bundle {
val gcd_busy = Output(Bool())
}
trait HasGCDIO extends BaseModule {
val w: Int
val io = IO(new GCDIO(w))
trait HasGCDTopIO {
def io: GCDTopIO
}
// DOC include start: GCD blackbox
class GCDMMIOBlackBox(val w: Int) extends BlackBox(Map("WIDTH" -> IntParam(w))) with HasBlackBoxResource
with HasGCDIO
{
class GCDMMIOBlackBox(val w: Int) extends BlackBox(Map("WIDTH" -> IntParam(w))) with HasBlackBoxResource {
val io = IO(new GCDIO(w))
addResource("/vsrc/GCDMMIOBlackBox.v")
}
// DOC include end: GCD blackbox
// DOC include start: GCD chisel
class GCDMMIOChiselModule(val w: Int) extends Module
with HasGCDIO
{
class GCDMMIOChiselModule(val w: Int) extends Module {
val io = IO(new GCDIO(w))
val s_idle :: s_run :: s_done :: Nil = Enum(3)
val state = RegInit(s_idle)
@@ -90,70 +88,106 @@ class GCDMMIOChiselModule(val w: Int) extends Module
}
// DOC include end: GCD chisel
// DOC include start: GCD instance regmap
trait GCDModule extends HasRegMap {
val io: GCDTopIO
implicit val p: Parameters
def params: GCDParams
val clock: Clock
val reset: Reset
// How many clock cycles in a PWM cycle?
val x = Reg(UInt(params.width.W))
val y = Wire(new DecoupledIO(UInt(params.width.W)))
val gcd = Wire(new DecoupledIO(UInt(params.width.W)))
val status = Wire(UInt(2.W))
val impl = if (params.useBlackBox) {
Module(new GCDMMIOBlackBox(params.width))
} else {
Module(new GCDMMIOChiselModule(params.width))
}
impl.io.clock := clock
impl.io.reset := reset.asBool
impl.io.x := x
impl.io.y := y.bits
impl.io.input_valid := y.valid
y.ready := impl.io.input_ready
gcd.bits := impl.io.gcd
gcd.valid := impl.io.output_valid
impl.io.output_ready := gcd.ready
status := Cat(impl.io.input_ready, impl.io.output_valid)
io.gcd_busy := impl.io.busy
regmap(
0x00 -> Seq(
RegField.r(2, status)), // a read-only register capturing current status
0x04 -> Seq(
RegField.w(params.width, x)), // a plain, write-only register
0x08 -> Seq(
RegField.w(params.width, y)), // write-only, y.valid is set on write
0x0C -> Seq(
RegField.r(params.width, gcd))) // read-only, gcd.ready is set on read
}
// DOC include end: GCD instance regmap
// DOC include start: GCD router
class GCDTL(params: GCDParams, beatBytes: Int)(implicit p: Parameters)
extends TLRegisterRouter(
params.address, "gcd", Seq("ucbbar,gcd"),
beatBytes = beatBytes)(
new TLRegBundle(params, _) with GCDTopIO)(
new TLRegModule(params, _, _) with GCDModule)
class GCDTL(params: GCDParams, beatBytes: Int)(implicit p: Parameters) extends ClockSinkDomain(ClockSinkParameters())(p) {
val device = new SimpleDevice("gcd", Seq("ucbbar,gcd"))
val node = TLRegisterNode(Seq(AddressSet(params.address, 4096-1)), device, "reg/control", beatBytes=beatBytes)
class GCDAXI4(params: GCDParams, beatBytes: Int)(implicit p: Parameters)
extends AXI4RegisterRouter(
params.address,
beatBytes=beatBytes)(
new AXI4RegBundle(params, _) with GCDTopIO)(
new AXI4RegModule(params, _, _) with GCDModule)
override lazy val module = new GCDImpl
class GCDImpl extends Impl with HasGCDTopIO {
val io = IO(new GCDTopIO)
withClockAndReset(clock, reset) {
// How many clock cycles in a PWM cycle?
val x = Reg(UInt(params.width.W))
val y = Wire(new DecoupledIO(UInt(params.width.W)))
val gcd = Wire(new DecoupledIO(UInt(params.width.W)))
val status = Wire(UInt(2.W))
val impl_io = if (params.useBlackBox) {
val impl = Module(new GCDMMIOBlackBox(params.width))
impl.io
} else {
val impl = Module(new GCDMMIOChiselModule(params.width))
impl.io
}
impl_io.clock := clock
impl_io.reset := reset.asBool
impl_io.x := x
impl_io.y := y.bits
impl_io.input_valid := y.valid
y.ready := impl_io.input_ready
gcd.bits := impl_io.gcd
gcd.valid := impl_io.output_valid
impl_io.output_ready := gcd.ready
status := Cat(impl_io.input_ready, impl_io.output_valid)
io.gcd_busy := impl_io.busy
// DOC include start: GCD instance regmap
node.regmap(
0x00 -> Seq(
RegField.r(2, status)), // a read-only register capturing current status
0x04 -> Seq(
RegField.w(params.width, x)), // a plain, write-only register
0x08 -> Seq(
RegField.w(params.width, y)), // write-only, y.valid is set on write
0x0C -> Seq(
RegField.r(params.width, gcd))) // read-only, gcd.ready is set on read
// DOC include end: GCD instance regmap
}
}
}
class GCDAXI4(params: GCDParams, beatBytes: Int)(implicit p: Parameters) extends ClockSinkDomain(ClockSinkParameters())(p) {
val node = AXI4RegisterNode(AddressSet(params.address, 4096-1), beatBytes=beatBytes)
override lazy val module = new GCDImpl
class GCDImpl extends Impl with HasGCDTopIO {
val io = IO(new GCDTopIO)
withClockAndReset(clock, reset) {
// How many clock cycles in a PWM cycle?
val x = Reg(UInt(params.width.W))
val y = Wire(new DecoupledIO(UInt(params.width.W)))
val gcd = Wire(new DecoupledIO(UInt(params.width.W)))
val status = Wire(UInt(2.W))
val impl_io = if (params.useBlackBox) {
val impl = Module(new GCDMMIOBlackBox(params.width))
impl.io
} else {
val impl = Module(new GCDMMIOChiselModule(params.width))
impl.io
}
impl_io.clock := clock
impl_io.reset := reset.asBool
impl_io.x := x
impl_io.y := y.bits
impl_io.input_valid := y.valid
y.ready := impl_io.input_ready
gcd.bits := impl_io.gcd
gcd.valid := impl_io.output_valid
impl_io.output_ready := gcd.ready
status := Cat(impl_io.input_ready, impl_io.output_valid)
io.gcd_busy := impl_io.busy
node.regmap(
0x00 -> Seq(
RegField.r(2, status)), // a read-only register capturing current status
0x04 -> Seq(
RegField.w(params.width, x)), // a plain, write-only register
0x08 -> Seq(
RegField.w(params.width, y)), // write-only, y.valid is set on write
0x0C -> Seq(
RegField.r(params.width, gcd))) // read-only, gcd.ready is set on read
}
}
}
// DOC include end: GCD router
// DOC include start: GCD lazy trait
@@ -164,7 +198,8 @@ trait CanHavePeripheryGCD { this: BaseSubsystem =>
val gcd_busy = p(GCDKey) match {
case Some(params) => {
val gcd = if (params.useAXI4) {
val gcd = pbus { LazyModule(new GCDAXI4(params, pbus.beatBytes)(p)) }
val gcd = LazyModule(new GCDAXI4(params, pbus.beatBytes)(p))
gcd.clockNode := pbus.fixedClockNode
pbus.coupleTo(portName) {
gcd.node :=
AXI4Buffer () :=
@@ -174,18 +209,14 @@ trait CanHavePeripheryGCD { this: BaseSubsystem =>
}
gcd
} else {
val gcd = pbus { LazyModule(new GCDTL(params, pbus.beatBytes)(p)) }
val gcd = LazyModule(new GCDTL(params, pbus.beatBytes)(p))
gcd.clockNode := pbus.fixedClockNode
pbus.coupleTo(portName) { gcd.node := TLFragmenter(pbus.beatBytes, pbus.blockBytes) := _ }
gcd
}
val pbus_io = pbus { InModuleBody {
val busy = IO(Output(Bool()))
busy := gcd.module.io.gcd_busy
busy
}}
val gcd_busy = InModuleBody {
val busy = IO(Output(Bool())).suggestName("gcd_busy")
busy := pbus_io
busy := gcd.module.io.gcd_busy
busy
}
Some(gcd_busy)

2
generators/icenet

Submodule generators/icenet updated: d6a471f218...ab30e23e8e

2
generators/rocket-chip

Submodule generators/rocket-chip updated: 749a3eae96...8026b6bc9a

2
generators/rocket-chip-blocks

Submodule generators/rocket-chip-blocks updated: 212c7b070b...3dddfe9f5b

16
scripts/init-submodules-no-riscv-tools-nolog.sh
View File

@@ -69,6 +69,8 @@ cd "$RDIR"
# path to temporarily exclude during the recursive update
for name in \
toolchains/*-tools/* \
generators/cva6 \
generators/nvdla \
toolchains/libgloss \
generators/sha3 \
generators/gemmini \
@@ -101,6 +103,20 @@ cd "$RDIR"
# Non-recursive clone to exclude riscv-linux
git submodule update --init generators/sha3
# Non-recursive clone to exclude cva6 submods
git submodule update --init generators/cva6
git -C generators/cva6 submodule update --init src/main/resources/cva6/vsrc/cva6
git -C generators/cva6/src/main/resources/cva6/vsrc/cva6 submodule update --init src/axi
git -C generators/cva6/src/main/resources/cva6/vsrc/cva6 submodule update --init src/axi_riscv_atomics
git -C generators/cva6/src/main/resources/cva6/vsrc/cva6 submodule update --init src/common_cells
git -C generators/cva6/src/main/resources/cva6/vsrc/cva6 submodule update --init src/fpga-support
git -C generators/cva6/src/main/resources/cva6/vsrc/cva6 submodule update --init src/riscv-dbg
git -C generators/cva6/src/main/resources/cva6/vsrc/cva6 submodule update --init src/register_interface
git -C generators/cva6/src/main/resources/cva6/vsrc/cva6 submodule update --init --recursive src/fpu
# Non-recursive clone to exclude nvdla submods
git submodule update --init generators/nvdla
git -C generators/nvdla submodule update --init src/main/resources/hw
# Non-recursive clone to exclude gemmini-software
git submodule update --init generators/gemmini
git -C generators/gemmini/ submodule update --init --recursive software/gemmini-rocc-tests

2
tools/rocket-dsp-utils

Submodule tools/rocket-dsp-utils updated: 194455223a...272cee3c83

5
variables.mk
View File

@@ -26,6 +26,7 @@ HELP_PROJECT_VARIABLES = \
HELP_SIMULATION_VARIABLES = \
" BINARY = riscv elf binary that the simulator will run when using the run-binary* targets" \
" BINARIES = list of riscv elf binary that the simulator will run when using the run-binaries* targets" \
" BINARIES_DIR = directory of riscv elf binaries that the simulator will run when using the run-binaries* targets" \
" LOADMEM = riscv elf binary that should be loaded directly into simulated DRAM. LOADMEM=1 will load the BINARY elf" \
" LOADARCH = path to a architectural checkpoint directory that should end in .loadarch/, for restoring from a checkpoint" \
" VERBOSE_FLAGS = flags used when doing verbose simulation [$(VERBOSE_FLAGS)]" \
@@ -288,6 +289,10 @@ override get_out_name = $(shell basename $(dir $(1)))
override LOADMEM = 1
endif
ifneq ($(BINARIES_DIR),)
override BINARIES = $(shell find -L $(BINARIES_DIR) -type f -print 2> /dev/null)
endif
#########################################################################################
# build output directory for compilation
#########################################################################################

4
vlsi/Makefile
View File

@@ -100,8 +100,8 @@ $(SMEMS_HAMMER): $(TOP_SMEMS_FILE)
$(SRAM_GENERATOR_CONF): $(SMEMS_HAMMER)
mkdir -p $(dir $@)
echo "vlsi.inputs.sram_parameters: '$(SMEMS_HAMMER)'" >> $@
echo "vlsi.inputs.sram_parameters_meta: [\"transclude\", \"json2list\"]">> $@
echo "vlsi.inputs.sram_parameters: '$(SMEMS_HAMMER)'" > $@
echo "vlsi.inputs.sram_parameters_meta: [\"transclude\", \"json2list\"]" >> $@
$(SRAM_CONF): $(SRAM_GENERATOR_CONF)
cd $(vlsi_dir) && $(HAMMER_EXEC) -e $(ENV_YML) $(foreach x,$(INPUT_CONFS) $(SRAM_GENERATOR_CONF), -p $(x)) --obj_dir $(build_dir) sram_generator