diff --git a/.gitmodules b/.gitmodules index 4bbfaa97..35addf76 100644 --- a/.gitmodules +++ b/.gitmodules @@ -43,9 +43,6 @@ [submodule "vlsi/hammer"] path = vlsi/hammer url = https://github.com/ucb-bar/hammer.git -[submodule "vlsi/hammer-cad-plugins"] - path = vlsi/hammer-cad-plugins - url = https://github.com/ucb-bar/hammer-cad-plugins.git [submodule "tools/dsptools"] path = tools/dsptools url = https://github.com/ucb-bar/dsptools.git @@ -61,3 +58,12 @@ [submodule "tools/firrtl-interpreter"] path = tools/firrtl-interpreter url = https://github.com/freechipsproject/firrtl-interpreter.git +[submodule "vlsi/hammer-cadence-plugins"] + path = vlsi/hammer-cadence-plugins + url = git@github.com:ucb-bar/hammer-cadence-plugins.git +[submodule "vlsi/hammer-synopsys-plugins"] + path = vlsi/hammer-synopsys-plugins + url = git@github.com:ucb-bar/hammer-synopsys-plugins.git +[submodule "vlsi/hammer-mentor-plugins"] + path = vlsi/hammer-mentor-plugins + url = git@github.com:ucb-bar/hammer-mentor-plugins.git diff --git a/build.sbt b/build.sbt index 8083dc3d..05a80bba 100644 --- a/build.sbt +++ b/build.sbt @@ -147,7 +147,7 @@ lazy val sha3 = (project in file("generators/sha3")) .settings(commonSettings) lazy val tapeout = conditionalDependsOn(project in file("./tools/barstools/tapeout/")) - .dependsOn(chisel_testers) + .dependsOn(chisel_testers, example) .settings(commonSettings) lazy val mdf = (project in file("./tools/barstools/mdf/scalalib/")) diff --git a/common.mk b/common.mk index 442c62f9..112285c2 100644 --- a/common.mk +++ b/common.mk @@ -53,10 +53,12 @@ HARNESS_CONF_FLAGS = -thconf $(HARNESS_SMEMS_CONF) TOP_TARGETS = $(TOP_FILE) $(TOP_SMEMS_CONF) $(TOP_ANNO) $(TOP_FIR) $(sim_top_blackboxes) HARNESS_TARGETS = $(HARNESS_FILE) $(HARNESS_SMEMS_CONF) $(HARNESS_ANNO) $(HARNESS_FIR) $(sim_harness_blackboxes) +# DOC include start: FirrtlCompiler .INTERMEDIATE: firrtl_temp $(TOP_TARGETS) $(HARNESS_TARGETS): firrtl_temp firrtl_temp: $(FIRRTL_FILE) $(ANNO_FILE) cd $(base_dir) && $(SBT) "project tapeout" "runMain barstools.tapeout.transforms.GenerateTopAndHarness -o $(TOP_FILE) -tho $(HARNESS_FILE) -i $(FIRRTL_FILE) --syn-top $(TOP) --harness-top $(VLOG_MODEL) -faf $(ANNO_FILE) -tsaof $(TOP_ANNO) -tdf $(sim_top_blackboxes) -tsf $(TOP_FIR) -thaof $(HARNESS_ANNO) -hdf $(sim_harness_blackboxes) -thf $(HARNESS_FIR) $(REPL_SEQ_MEM) $(HARNESS_CONF_FLAGS) -td $(build_dir)" +# DOC include end: FirrtlCompiler # This file is for simulation only. VLSI flows should replace this file with one containing hard SRAMs MACROCOMPILER_MODE ?= --mode synflops diff --git a/docs/Advanced-Usage/Chip-Communication.rst b/docs/Advanced-Usage/Chip-Communication.rst new file mode 100644 index 00000000..902a32a3 --- /dev/null +++ b/docs/Advanced-Usage/Chip-Communication.rst @@ -0,0 +1,168 @@ +.. _chip-communication: + +Communicating with the DUT +=============================== + +There are two types of DUTs that can be made: `tethered` or `standalone` DUTs. +A `tethered` DUT is where a host computer (or just host) must send transactions to the DUT to bringup a program. +This differs from a `standalone` DUT that can bringup itself (has its own bootrom, loads programs itself, etc). +An example of a tethered DUT is a Chipyard simulation where the host loads the test program into the DUTs memory and signals to the DUT that the program is ready to run. +An example of a standalone DUT is a Chipyard simulation where a program can be loaded from an SDCard by default. +In this section, we mainly describe how to communicate to tethered DUTs. + +There are two ways the host (otherwise known as the outside world) can communicate with a tethered Chipyard DUT: + +* Using the Tethered Serial Interface (TSI) or the Debug Module Interface (DMI) with the Front-End Server (FESVR) to communicate with the DUT +* Using the JTAG interface with OpenOCD and GDB to communicate with the DUT + +The following picture shows a block diagram view of all the supported communication mechanisms +split between the host and the simulation. + +.. image:: ../_static/images/chip-communication.png + +Using the Tethered Serial Interface (TSI) or the Debug Module Interface (DMI) +----------------------------------------------------------------------------- + +If you are using TSI or DMI to communicate with the DUT, you are using +the Front-End Server (FESVR) to facilitate communication between the host and the DUT. + +Primer on the Front-End Server (FESVR) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +FESVR is a C++ library that manages communication +between a host machine and a RISC-V DUT. For debugging, it provides a simple API to reset, +send messages, and load/run programs on a DUT. It also emulates peripheral devices. +It can be incorporated with simulators (VCS, Verilator, FireSim), or used in a bringup sequence +for a taped out chip. + +Specifically, FESVR uses the Host Target Interface (HTIF), a communication protocol, +to speak with the DUT. HTIF is a non-standard Berkeley protocol that uses a FIFO non-blocking +interface to communicate with the DUT. It defines a protocol where you can read/write memory, +load/start/stop the program, and more. Both TSI and DMI implement this HTIF protocol differently +in order to communicate with the DUT. + +Using the Tethered Serial Interface (TSI) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By default, Chipyard uses the Tethered Serial Interface (TSI) to communicate with the DUT. +TSI protocol is an implementation of HTIF that is used to send commands to the +RISC-V DUT. These TSI commands are simple R/W commands +that are able to probe the DUT's memory space. During simulation, the host sends TSI commands to a +simulation stub called ``SimSerial`` (C++ class) that resides in a ``SimSerial`` verilog module +(both are located in the ``generators/testchipip`` project). This ``SimSerial`` verilog module then +sends the TSI command recieved by the simulation stub into the DUT which then converts the TSI +command into a TileLink request. This conversion is done by the ``SerialAdapter`` module +(located in the ``generators/testchipip`` project). In simulation, FESVR +resets the DUT, writes into memory the test program, and indicates to the DUT to start the program +through an interrupt (see :ref:`Chipyard Boot Process`). Using TSI is currently the fastest +mechanism to communicate with the DUT in simulation. + +In the case of a chip tapeout bringup, TSI commands can be sent over a custom communication +medium to communicate with the chip. For example, some Berkeley tapeouts have a FPGA +with a RISC-V soft-core that runs FESVR. The FESVR on the soft-core sends TSI commands +to a TSI-to-TileLink converter living on the FPGA (i.e. ``SerialAdapter``). Then this converter +sends the converted TileLink commands over a serial link to the chip. The following image shows this flow: + +.. image:: ../_static/images/chip-bringup.png + +Using the Debug Module Interface (DMI) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Another option to interface with the DUT is to use the Debug Module Interface (DMI). +Similar to TSI, the DMI protocol is an implementation of HTIF. +In order to communicate with the DUT with the DMI protocol, the DUT needs to contain a Debug Transfer Module (DTM). +The DTM is given in the `RISC-V Debug Specification `__ +and is responsible for managing communication between the DUT and whatever lives on the other side of the DMI (in this case FESVR). +This is implemented in the Rocket Chip ``Subsystem`` by having the ``HasPeripheryDebug`` and ``HasPeripheryDebugModuleImp`` mixins. + During simulation, the host sends DMI commands to a +simulation stub called ``SimDTM`` (C++ class) that resides in a ``SimDTM`` verilog module +(both are located in the ``generators/rocket-chip`` project). This ``SimDTM`` verilog module then +sends the DMI command recieved by the simulation stub into the DUT which then converts the DMI +command into a TileLink request. This conversion is done by the DTM named ``DebugModule`` in the ``generators/rocket-chip`` project. +When the DTM receives the program to load, it starts to write the binary byte-wise into memory. +This is considerably slower than the TSI protocol communication pipeline (i.e. ``SimSerial``/``SerialAdapter``/TileLink) +which directly writes the program binary to memory. +Thus, Chipyard removes the DTM by default in favor of the TSI protocol for DUT communication. + +Starting the TSI or DMI Simulation +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All default Chipyard configurations use TSI to communicate between the simulation and the simulated SoC/DUT. Hence, when running a +software RTL simulation, as is indicated in the :ref:`Software RTL Simulation` section, you are in-fact using TSI to communicate with the DUT. As a +reminder, to run a software RTL simulation, run: + +.. code-block:: bash + + cd sims/verilator + # or + cd sims/vcs + + make CONFIG=LargeBoomConfig run-asm-tests + +FireSim FPGA-accelerated simulations use TSI by default as well. + +If you would like to build and simulate a Chipyard configuration with a DTM configured for DMI communication, then you must create a +top-level system with the DTM (``TopWithDTM``), a test-harness to connect to the DTM (``TestHarnessWithDTM``), as well as a config to use that top-level system. + +.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala + :language: scala + :start-after: DOC include start: DmiRocket + :end-before: DOC include end: DmiRocket + +In this example, the ``WithDTMTop`` mixin specifies that the top-level SoC will instantiate a DTM (that by default is setup to use DMI). +The rest of the mixins specify the rest of the system (cores, accelerators, etc). +Then you can run simulations with the new DMI-enabled top-level and test-harness. + +.. code-block:: bash + + cd sims/verilator + # or + cd sims/vcs + + make CONFIG=dmiRocketConfig TOP=TopWithDTM MODEL=TestHarnessWithDTM run-asm-tests + +Using the JTAG Interface +------------------------ + +The main way to use JTAG with a Rocket Chip based system is to instantiate the Debug Transfer Module (DTM) +and configure it to use a JTAG interface (by default the DTM is setup to use the DMI interface mentioned above). + +Creating a DTM+JTAG Config +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +First, a DTM config must be created for the system that you want to create. +This step is similar to the DMI simulation section within the :ref:`Starting the TSI or DMI Simulation` section. +First, you must make a top-level system (``TopWithDTM``) and test-harness (``TestHarnessWithDTM``) that instantiates +and connects the DTM correctly. The configuration is very similar to a DMI-based configuration. The main difference +is the addition of the ``WithJtagDTM`` mixin that configures the instantiated DTM to use the JTAG protocol as the +bringup method. + +.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala + :language: scala + :start-after: DOC include start: JtagRocket + :end-before: DOC include end: JtagRocket + +Building a DTM+JTAG Simulator +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After creating the config, call the ``make`` command like the following to build a simulator for your RTL: + +.. code-block:: bash + + cd sims/verilator + # or + cd sims/vcs + + make CONFIG=jtagRocketConfig TOP=TopWithDTM MODEL=TestHarnessWithDTM + +In this example, the simulation will use the config that you previously specified, as well as set +the other parameters that are needed to satisfy the build system. After that point, you +should have a JTAG enabled simulator that you can attach to using OpenOCD and GDB! + +Debugging with JTAG +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Please refer to the following resources on how to debug with JTAG. + +* https://github.com/chipsalliance/rocket-chip#-debugging-with-gdb +* https://github.com/riscv/riscv-isa-sim#debugging-with-gdb diff --git a/docs/Advanced-Usage/DTM-Debugging.rst b/docs/Advanced-Usage/DTM-Debugging.rst deleted file mode 100644 index 787a73ab..00000000 --- a/docs/Advanced-Usage/DTM-Debugging.rst +++ /dev/null @@ -1,47 +0,0 @@ -Debugging with DTM/JTAG -=============================== - -By default, Chipyard is not setup to use the Debug Test Module (DTM) to bringup the core. -Instead, Chipyard uses TSI commands to bringup the core (which normally results in a faster simulation). -TSI simulations use the SimSerial interface to directly write the test binary into memory, while the DTM -executes a small loop of code to write the test binary byte-wise into memory. -However, if you want to use JTAG, you must do the following steps to setup a DTM enabled system. - -Creating a DTM/JTAG Config -------------------------------------------- - -First, a DTM config must be created for the system that you want to create. -This involves specifying the SoC top-level to add a DTM as well as configuring that DTM to use JTAG. - -.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala - :language: scala - :start-after: DOC include start: JtagRocket - :end-before: DOC include end: JtagRocket - -In this example, the ``WithDTMTop`` mixin specifies that the top-level SoC will instantiate a DTM. -The ``WithJtagDTM`` will configure that instantiated DTM to use JTAG as the bringup method (note: this can be removed if you want a DTM-only bringup). -The rest of the mixins specify the rest of the system (cores, accelerators, etc). - -Starting the DTM Simulation -------------------------------------------- - -After creating the config, call the ``make`` command like the following: - -.. code-block:: bash - - cd sims/verilator - # or - cd sims/vcs - - make CONFIG=DTMBoomConfig TOP=TopWithDTM MODEL=TestHarnessWithDTM - -In this example, this will use the config that you previously specified, as well as set the other parameters that are needed to satisfy the build system. -After that point, you should have a JTAG enabled simulation that you can attach to using OpenOCD and GDB! - -Debugging with JTAG -------------------------------------------------------- - -Please refer to the following resources on how to debug with JTAG. - -* https://github.com/chipsalliance/rocket-chip#-debugging-with-gdb -* https://github.com/riscv/riscv-isa-sim#debugging-with-gdb diff --git a/docs/Advanced-Usage/index.rst b/docs/Advanced-Usage/index.rst index 2a8824b2..4864ce7a 100644 --- a/docs/Advanced-Usage/index.rst +++ b/docs/Advanced-Usage/index.rst @@ -8,5 +8,5 @@ They expect you to know about Chisel, Parameters, Configs, etc. :maxdepth: 2 :caption: Advanced Usage: - DTM-Debugging + Chip-Communication Resources diff --git a/docs/Customization/Firrtl-Transforms.rst b/docs/Customization/Firrtl-Transforms.rst new file mode 100644 index 00000000..808082e0 --- /dev/null +++ b/docs/Customization/Firrtl-Transforms.rst @@ -0,0 +1,97 @@ +.. _firrtl-transforms: + +Adding a Firrtl Transform +========================= + +Similar to how LLVM IR passes can perform transformations and optimizations on software, FIRRTL transforms can +modify Chisel-elaborated RTL. +As mentioned in Section :ref:`firrtl`, transforms are modifications that happen on the FIRRTL IR that can modify a circuit. +Transforms are a powerful tool to take in the FIRRTL IR that is emitted from Chisel and run analysis or convert the circuit into a new form. + +Where to add transforms +----------------------- + +In Chipyard, the FIRRTL compiler is called multiple times to create a "Top" file that contains the DUT and a "Harness" file containing the test harness, which instantiates the DUT. +The "Harness" file does not contain the DUT's module definition or any of its submodules. +This is done by the ``tapeout`` SBT project (located in ``tools/barstools/tapeout``) which calls ``GenerateTopAndHarness`` (a function that wraps the multiple FIRRTL compiler calls and extra transforms). + +.. literalinclude:: ../../common.mk + :language: make + :start-after: DOC include start: FirrtlCompiler + :end-before: DOC include end: FirrtlCompiler + +If you look inside of the `tools/barstools/tapeout/src/main/scala/transforms/Generate.scala `__ file, +you can see that FIRRTL is invoked twice, once for the "Top" and once for the "Harness". If you want to add transforms to just modify the DUT, you can add them to ``topTransforms``. +Otherwise, if you want to add transforms to just modify the test harness, you can add them to ``harnessTransforms``. + +For more information on Barstools, please visit the :ref:`Barstools` section. + +Examples of transforms +---------------------- + +There are multiple examples of transforms that you can apply and are spread across the FIRRTL ecosystem. +Within FIRRTL there is a default set of supported transforms located in https://github.com/freechipsproject/firrtl/tree/master/src/main/scala/firrtl/transforms. +This includes transforms that can flatten modules (``Flatten``), group modules together (``GroupAndDedup``), and more. + +Transforms can be standalone or can take annotations as input. Annotations are used to pass information between FIRRTL transforms. This includes information on +what modules to flatten, group, and more. Annotations can be added to the code by +adding them to your Chisel source or by creating a serialized annotation ``json`` file and adding it to the FIRRTL compiler +(note: annotating the Chisel source will automatically serialize the annotation as a ``json`` snippet into the build system for you). +**The recommended way to annotate something is to do it in the Chisel source, but not all annotation types have Chisel APIs**. + +The example below shows two ways to annotate the signal using the ``DontTouchAnnotation`` +(makes sure that a particular signal is not removed by the "Dead Code Elimination" pass in FIRRTL): + +* use the Chisel API/wrapper function called ``dontTouch`` that does this automatically for you (more `dontTouch `__ information): +* directly annotate the signal with the ``annotate`` function and the ``DontTouchAnnotation`` class if there is no Chisel API for it (note: most FIRRTL annotations have Chisel APIs for them) + +.. code-block:: scala + + class TopModule extends Module { + ... + val submod = Module(new Submodule) + ... + } + + class Submodule extends Module { + ... + val some_signal := ... + + // MAIN WAY TO USE `dontTouch` + // how to annotate if there is a Chisel API/wrapper + chisel3.dontTouch(some_signal) + + // how to annotate WITHOUT a Chisel API/wrapper + annotate(new ChiselAnnotation { + def toFirrtl = DontTouchAnnotation(some_signal.toNamed) + }) + + ... + } + +Here is an example of the ``DontTouchAnnotation`` when it is serialized: + +.. code-block:: json + + [ + { + "class": "firrtl.transforms.DontTouchAnnotation", + "target": "~TopModule|Submodule>some_signal" + } + ] + +In this case, the specific syntax depends on the type of annotation and its fields. +One of the easier ways to figure out the serialized syntax is to first try and find a Chisel +annotation to add to the code. Then you can look at the collateral that is generated from the +build system, find the ``*.anno.json``, and find the proper syntax for the annotation. + +Once ``yourAnnoFile.json`` is created then you can add ``-faf yourAnnoFile.json`` to the FIRRTL +compiler invocation in ``common.mk``. + +.. literalinclude:: ../../common.mk + :language: make + :start-after: DOC include start: FirrtlCompiler + :end-before: DOC include end: FirrtlCompiler + +If you are interested in writing FIRRTL transforms please refer to the FIRRTL documentation located here: +https://github.com/freechipsproject/firrtl/wiki. diff --git a/docs/Customization/Incorporating-Verilog-Blocks.rst b/docs/Customization/Incorporating-Verilog-Blocks.rst new file mode 100644 index 00000000..64f064f8 --- /dev/null +++ b/docs/Customization/Incorporating-Verilog-Blocks.rst @@ -0,0 +1,186 @@ +.. _incorporating-verilog-blocks: + +Incorporating Verilog Blocks +============================ + +Working with existing Verilog IP is an integral part of many chip +design flows. Fortunately, both Chisel and Chipyard provide extensive +support for Verilog integration. + +Here, we will examine the process of incorporating an MMIO peripheral +(similar to the PWM example from the previous section) that uses a +Verilog implementation of Greatest Common Denominator (GCD) +algorithm. There are a few steps to adding a Verilog peripheral: + +* Adding a Verilog resource file to the project +* Defining a Chisel ``BlackBox`` representing the Verilog module +* Instantiating the ``BlackBox`` and interfacing ``RegField`` entries +* Setting up a chip ``Top`` and ``Config`` that use the peripheral + +Adding a Verilog Blackbox Resource File +--------------------------------------- + +As before, it is possible to incorporate peripherals as part of your +own generator project. However, Verilog resource files must go in a +different directory from Chisel (Scala) sources. + +.. code-block:: none + + generators/yourproject/ + build.sbt + src/main/ + scala/ + resources/ + vsrc/ + YourFile.v + +In addition to the steps outlined in the previous section on adding a +project to the ``build.sbt`` at the top level, it is also necessary to +add any projects that contain Verilog IP as dependencies to the +``tapeout`` project. This ensures that the Verilog sources are visible +to the downstream FIRRTL passes that provide utilities for integrating +Verilog files into the build process, which are part of the +``tapeout`` package in ``barstools/tapeout``. + +.. code-block:: scala + + lazy val tapeout = conditionalDependsOn(project in file("./tools/barstools/tapeout/")) + .dependsOn(chisel_testers, example, yourproject) + .settings(commonSettings) + +For this concrete GCD example, we will be using a ``GCDMMIOBlackBox`` +Verilog module that is defined in the ``example`` project. The Scala +and Verilog sources follow the prescribed directory layout. + +.. code-block:: none + + generators/example/ + build.sbt + src/main/ + scala/ + GCDMMIOBlackBox.scala + resources/ + vsrc/ + GCDMMIOBlackBox.v + +Defining a Chisel BlackBox +-------------------------- + +A Chisel ``BlackBox`` module provides a way of instantiating a module +defined by an external Verilog source. The definition of the blackbox +includes several aspects that allow it to be translated to an instance +of the Verilog module: + +* An ``io`` field: a bundle with fields corresponding to the portlist of the Verilog module. +* A constructor parameter that takes a ``Map`` from Verilog parameter name to elaborated value +* One or more resources added to indicate Verilog source dependencies + +Of particular interest is the fact that parameterized Verilog modules +can be passed the full space of possible parameter values. These +values may depend on elaboration-time values in the Chisel generator, +as the bitwidth of the GCD calculation does in this example. + +**Verilog GCD port list and parameters** + +.. literalinclude:: ../../generators/example/src/main/resources/vsrc/GCDMMIOBlackBox.v + :language: verilog + :start-after: DOC include start: GCD portlist + :end-before: DOC include end: GCD portlist + +**Chisel BlackBox Definition** + +.. literalinclude:: ../../generators/example/src/main/scala/GCDMMIOBlackBox.scala + :language: scala + :start-after: DOC include start: GCD blackbox + :end-before: DOC include end: GCD blackbox + +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 PWM device example. + +.. literalinclude:: ../../generators/example/src/main/scala/GCDMMIOBlackBox.scala + :language: scala + :start-after: DOC include start: GCD instance regmap + :end-before: DOC include end: GCD instance regmap + +Advanced Features of RegField Entries +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +One significant difference from the PWM example is in the peripheral's +memory map. ``RegField`` exposes polymorphic ``r`` and ``w`` methods +that allow read- and write-only memory-mapped registers to be +interfaced to hardware in multiple ways. + +* ``RegField.r(2, status)`` is used to create a 2-bit, read-only register that captures the current value of the ``status`` signal when read. +* ``RegField.r(params.width, gcd)`` "connects" the decoupled handshaking interface ``gcd`` to a read-only memory-mapped register. When this register is read via MMIO, the ``ready`` signal is asserted. This is in turn connected to ``output_ready`` on the Verilog blackbox through the glue logic. +* ``RegField.w(params.width, x)`` exposes a plain register (much like those in the PWM example) via MMIO, but makes it write-only. +* ``RegField.w(params.width, y)`` associates the decoupled interface signal ``y`` with a write-only memory-mapped register, causing ``y.valid`` to be asserted when the register is written. + +Since the ready/valid signals of ``y`` are connected to the +``input_ready`` and ``input_valid`` signals of the blackbox, +respectively, this register map and glue logic has the effect of +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. + +Defining a Chip with a GCD Peripheral +--------------------------------------- + +As with the PWM example, a few more pieces are needed to tie the system together. + +**Composing traits into a complete cake pattern peripheral** + +.. literalinclude:: ../../generators/example/src/main/scala/GCDMMIOBlackBox.scala + :language: scala + :start-after: DOC include start: GCD cake + :end-before: DOC include end: GCD cake + +Note the differences arising due to the fact that this peripheral has +no top-level IO. To build a complete system, a new ``Top`` and new +``Config`` objects are added in a manner exactly analogous to the PWM +example. + +Software Testing +---------------- + +The GCD module has a slightly more complex interface, so polling is +used to check the status of the device before each triggering read or +write. + +.. literalinclude:: ../../tests/gcd.c + :language: scala + :start-after: DOC include start: GCD test + :end-before: DOC include end: GCD test + +Support for Verilog Within Chipyard Tool Flows +---------------------------------------------- + +There are important differences in how Verilog blackboxes are treated +by various flows within the Chipyard framework. Some flows within +Chipyard rely on FIRRTL in order to provide robust, non-invasive +transformations of source code. Since Verilog blackboxes remain +blackboxes in FIRRTL, their ability to be processed by FIRRTL +transforms is limited, and some advanced features of Chipyard may +provide weaker support for blackboxes. Note that the remainder of the +design (the "non-Verilog" part of the design) may still generally be +transformed or augmented by any Chipyard FIRRTL transform. + +* Verilog blackboxes are fully supported for generating tapeout-ready RTL +* HAMMER workflows offer robust support for integrating Verilog blackboxes +* FireSim relies on FIRRTL transformations to generate a decoupled + FPGA simulator. Therefore, support for Verilog blackboxes in FireSim + is currently limited but rapidly evolving. Stay tuned! +* Custom FIRRTL transformations and analyses may sometimes be able to + handle blackbox Verilog, depending on the mechanism of the + particular transform + +As mentioned earlier in this section, ``BlackBox`` resource files must +be integrated into the build process, so any project providing +``BlackBox`` resources must be made visible to the ``tapeout`` project +in ``build.sbt`` diff --git a/docs/Customization/index.rst b/docs/Customization/index.rst index c0432e73..cd52a499 100644 --- a/docs/Customization/index.rst +++ b/docs/Customization/index.rst @@ -15,5 +15,7 @@ Hit next to get started! Heterogeneous-SoCs Adding-An-Accelerator + Incorporating-Verilog-Blocks Memory-Hierarchy Boot-Process + Firrtl-Transforms diff --git a/docs/Software/Spike.rst b/docs/Software/Spike.rst index 015ec5b2..5c022471 100644 --- a/docs/Software/Spike.rst +++ b/docs/Software/Spike.rst @@ -1,4 +1,23 @@ The RISC-V ISA Simulator (Spike) ================================= -.. attention:: This article is a stub. Fill it out! +Spike is the golden reference functional RISC-V ISA C++ sofware simulator. +It provides full system emulation or proxied emulation with `HTIF/FESVR `__. +It serves as a starting point for running software on a RISC-V target. +Here is a highlight of some of Spikes main features: + +* Multiple ISAs: RV32IMAFDQCV extensions +* Multiple memory models: Weak Memory Ordering (WMO) and Total Store Ordering (TSO) +* Privileged Spec: Machine, Supervisor, User modes (v1.11) +* Debug Spec +* Single-step debugging with support for viewing memory/register contents +* Multiple CPU support +* JTAG support +* Highly extensible (add and test new instructions) + +In most cases, software development for a Chipyard target will begin with functional simulation using Spike +(usually with the addition of custom Spike models for custom accelerator functions), and only later move on to +full cycle-accurate simulation using software RTL simulators or FireSim. + +Spike comes pre-packaged in the RISC-V toolchain and is available on the path as ``spike``. +More information can be found in the `Spike repository `__. diff --git a/docs/Tools/FIRRTL.rst b/docs/Tools/FIRRTL.rst index 23f39f16..b850b39e 100644 --- a/docs/Tools/FIRRTL.rst +++ b/docs/Tools/FIRRTL.rst @@ -1,3 +1,4 @@ +.. _firrtl: FIRRTL ================================ diff --git a/docs/VLSI/Advanced-Usage.rst b/docs/VLSI/Advanced-Usage.rst new file mode 100644 index 00000000..c7e1bae2 --- /dev/null +++ b/docs/VLSI/Advanced-Usage.rst @@ -0,0 +1,54 @@ +.. _advanced-usage: + +Advanced Usage +============== + +Alternative RTL Flows +--------------------- +The Make-based build system provided supports using Hammer without using RTL generated by Chipyard. To push a custom verilog module through, one only needs to append the following environment variables to the ``make buildfile`` command (or edit them directly in the Makefile). + +.. code-block:: shell + + CUSTOM_VLOG= + VLSI_TOP= + +``CUSTOM_VLOG`` breaks the dependency on the rest of the Chipyard infrastructure and does not start any Chisel/FIRRTL elaboration. ``VLSI_TOP`` selects the top module from your custom Verilog files. + +Under the Hood +-------------- +To uncover what is happening under the hood, here are the commands that are executed: + +For ``make syn``: + +.. code-block:: shell + + ./example-vlsi -e /path/to/env.yml -p /path/to/example.yml -p /path/to/inputs.yml --obj_dir /path/to/build syn + +``example-vlsi`` is the entry script as explained before, ``-e`` provides the environment yml, ``-p`` points to configuration yml/jsons, ``--obj_dir`` speficies the destination directory, and ``syn`` is the action. + +For ``make par``: + +.. code-block:: shell + + ./example-vlsi -e /path/to/env.yml -p /path/to/syn-output-full.json -o /path/to/par-input.json --obj_dir /path/to/build syn-to-par + ./example-vlsi -e /path/to/env.yml -p /path/to/par-input.json --obj_dir /path/to/build par + +A ``syn-to-par`` action translates the synthesis output configuration into an input configuration given by ``-o``. Then, this is passed to the ``par`` action. + +For more information about all the options that can be passed to the Hammer command-line driver, please see the Hammer documentation. + +Manual Step Execution & Dependency Tracking +------------------------------------------- +It is invariably necessary to debug certain steps of the flow, e.g. if the power strap settings need to be updated. The underlying Hammer commands support options such as ``--to_step``, ``--from_step``, and ``--only_step``. These allow you to control which steps of a particular action are executed. + +Make's dependency tracking can sometimes result in re-starting the entire flow when the user only wants to re-run a certain action. Hammer's build system has "redo" targets such as ``redo-syn`` and ``redo-par`` to run certain actions without typing out the entire Hammer command. + +Say you need to update some power straps settings in ``example.yml`` and want to try out the new settings: + +.. code-block:: shell + + make redo-par HAMMER_REDO_ARGS='-p example.yml --only_step power_straps' + +Simulation +---------- +With the Synopsys plugin, RTL and gate-level simulation is supported using VCS. While this example does not implement any simulation, refer to Hammer's documentation for how to set it up for your design. diff --git a/docs/VLSI/HAMMER.rst b/docs/VLSI/HAMMER.rst deleted file mode 100644 index c0c77824..00000000 --- a/docs/VLSI/HAMMER.rst +++ /dev/null @@ -1,58 +0,0 @@ -Core HAMMER -================================ - -`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 `__ and see the `GitHub repository `__. - -Actions -------- - -Actions are the top-level tasks Hammer is capable of executing (e.g. synthesis, place-and-route, etc.) - -Steps -------- - -Steps are the sub-components of actions that individually addressable in Hammer (e.g. placement in the place-and-route action). - -Hooks -------- - -Hooks are modifications to steps or actions that are programmatically defined in a Hammer configuration. - -Tool Plugins -============ - -Hammer supports separately managed plugins for different CAD tool vendors. -The types of tools (in there hammer names) supported currently include: - -* synthesis -* par -* drc -* lvs -* sram_generator -* pcb - -In order to configure your tool plugin of choice, you will need to set several configuration variables. -First, you should select which specific tool you want to use by setting ``vlsi.core._tool`` to the name of your tool. -For example ``vlsi.core.par_tool: "innovus"``. -You will also need to point hammer to the folder that contains your tool plugin by setting ``vlsi.core._tool_path``. -This directory should include a folder with the name of the tool as specified previously, which itself includes a python file ``__init__.py`` and a yaml file ``defaults.yml`` specifying the default values for any tool specific variables. -In addition you can also customize the version of the tools you use by setting ``..version`` to a tool specific string. -Looking at the tools ``defaults.yml`` will inform you if there are other variables you would like to set for your use of this tool. - -The ``__init__.py`` file should contain a variable, ``tool``, that points to the class implementing this tools Hammer support. -This class should be a subclass of ``HammerTool``, which will be a subclass of ``HammerTool``. - -Technology Plugins -================== - -Hammer supports separately managed plugins for different technologies. - -Configuration -============= - -To configure a hammer flow the user needs to supply a yaml or json configuration file the chooses the tool and technology plugins and versions as well as any design specific configuration APIs. - -You can see the current set of all available Hammer APIs `here `__. diff --git a/docs/VLSI/Hammer.rst b/docs/VLSI/Hammer.rst new file mode 100644 index 00000000..11d80a07 --- /dev/null +++ b/docs/VLSI/Hammer.rst @@ -0,0 +1,71 @@ +.. _hammer: + +Core Hammer +================================ + +`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 `__ and see the `GitHub repository `__ and associated documentation. + +Hammer implements a VLSI flow using the following high-level constructs: + +Actions +------- + +Actions are the top-level tasks Hammer is capable of executing (e.g. synthesis, place-and-route, etc.) + +Steps +------- + +Steps are the sub-components of actions that individually addressable in Hammer (e.g. placement in the place-and-route action). + +Hooks +------- + +Hooks are modifications to steps or actions that are programmatically defined in a Hammer configuration. + +Configuration (Hammer IR) +========================= + +To configure a Hammer flow, supply a set ``yaml`` or ``json`` configuration files that chooses the tool and technology plugins and versions as well as any design specific configuration options. Collectively, this configuration API is referred to as Hammer IR and can be generated from higher-level abstractions. + +The current set of all available Hammer APIs is codified `here `__. + +Tool Plugins +============ + +Hammer supports separately managed plugins for different CAD tool vendors. You may be able to acquire access to the included Cadence, Synopsys, and Mentor plugins repositories with permission from the respective CAD tool vendor. +The types of tools (by Hammer names) supported currently include: + +* synthesis +* par +* drc +* lvs +* sram_generator +* pcb + +Several configuration variables are needed to configure your tool plugin of choice. + +First, select which tool to use for each action by setting ``vlsi.core._tool`` to the name of your tool, e.g. ``vlsi.core.par_tool: "innovus"``. + +Then, point Hammer to the folder that contains your tool plugin by setting ``vlsi.core._tool_path``. +This directory should include a folder with the name of the tool, which itself includes a python file ``__init__.py`` and a yaml file ``defaults.yml``. Customize the version of the tool by setting ``..version`` to a tool specific string. + +The ``__init__.py`` file should contain a variable, ``tool``, that points to the class implementing this tool. +This class should be a subclass of ``HammerTool``, which will be a subclass of ``HammerTool``. The class should implement methods for all the tool's steps. + +The ``defaults.yml`` file contains tool-specific configuration variables. The defaults may be overridden as necessary. + +Technology Plugins +================== + +Hammer supports separately managed technology plugins to satisfy NDAs. You may be able to acquire access to certain pre-built technology plugins with permission from the technology vendor. Or, to build your own tech plugin, you need at least a ``.tech.json`` and ``defaults.yml``. An ``__init__.py`` is optional if there are any technology-specific methods or hooks to run. + +The `ASAP7 plugin `__ is a good starting point for setting up a technology plugin because it is an open-source example that is not suitable for taping out a chip. Refer to Hammer's documentation for the schema and detailed setup instructions. + +Several configuration variables are needed to configure your technology of choice. + +First, choose the technology, e.g. ``vlsi.core.technology: asap7``, then point to the location with the PDK tarball with ``technology..tarball_dir`` or pre-installed directory with ``technology..install_dir`` and (if applicable) the plugin repository with ``vlsi.core.technology_path``. + +Technology-specific options such as supplies, MMMC corners, etc. are defined in their respective ``vlsi.inputs...`` configurations. Options for the most common use case are already defined in the technology's ``defaults.yml`` and can be overridden by the user. diff --git a/docs/VLSI/Tutorial.rst b/docs/VLSI/Tutorial.rst new file mode 100644 index 00000000..7c2e0d2f --- /dev/null +++ b/docs/VLSI/Tutorial.rst @@ -0,0 +1,140 @@ +.. _tutorial: + +ASAP7 Tutorial +============== +The ``vlsi`` folder of this repository contains an example Hammer flow with the SHA-3 accelerator and a dummy hard macro. This example tutorial uses the built-in ASAP7 technology plugin and requires access to the included Cadence and Mentor tool plugin submodules. Cadence is necessary for synthesis & place-and-route, while Mentor is needed for DRC & LVS. + +Project Structure +----------------- + +This example gives a suggested file structure and build system. The ``vlsi/`` folder will eventually contain the following files and folders: + +* Makefile + + * Integration of Hammer's build system into Chipyard and abstracts away some Hammer commands. + +* build + + * Hammer output directory. Can be changed with the ``OBJ_DIR`` variable. + * Will contain subdirectories such as ``syn-rundir`` and ``par-rundir`` and the ``inputs.yml`` denoting the top module and input Verilog files. + +* env.yml + + * A template file for tool environment configuration. Fill in the install and license server paths for your environment. + +* example-vlsi + + * Entry point to Hammer. Contains example placeholders for hooks. + +* example.v + + * Verilog wrapper around the accelerator and dummy hard macro. + +* example.yml + + * Hammer IR for this tutorial. + +* extra_libraries + + * Contains collateral for the dummy hard macro. + +* generated-src + + * All of the elaborated Chisel and FIRRTL. + +* hammer, hammer--plugins, hammer--plugin + + * Core, tool, tech repositories. + +Prerequisites +------------- + +* Python 3.4+ +* numpy and gdspy packages +* Genus, Innovus, and Calibre licenses +* For ASAP7 specifically: + + * Download the `ASAP7 PDK `__ tarball to a directory of choice but do not extract it + * If you have additional ASAP7 hard macros, their LEF & GDS need to be 4x upscaled @ 4000 DBU precision. They may live outside ``extra_libraries`` at your discretion. + +Initial Setup +------------- +In the Chipyard root, run: + +.. code-block:: shell + + ``./scripts/init-vlsi.sh asap7`` + +to pull the Hammer & plugin submodules. Note that for technologies other than ``asap7``, the tech submodule must be added in the ``vlsi`` folder first. + +Pull the Hammer environment into the shell: + +.. code-block:: shell + + cd vlsi + export HAMMER_HOME=$PWD/hammer + source $HAMMER_HOME/sourceme.sh + +Building the Design +------------------- +To elaborate the ``Sha3RocketConfig`` (Rocket Chip w/ the accelerator) and set up all prerequisites for the build system to push just the accelerator + hard macro through the flow: + +.. code-block:: shell + + make buildfile MACROCOMPILER_MODE='--mode synflops' CONFIG=Sha3RocketConfig VLSI_TOP=Sha3AccelwBB + +The ``MACROCOMPILER_MODE='--mode synflops'`` is needed because the ASAP7 process does not yet have a memory compiler. Therefore, flip-flop arrays are used instead. + +The ``CONFIG=Sha3RocketConfig`` selects the target generator config in the same manner as the rest of the Chipyard framework. This elaborates a Rocket Chip with the Sha3Accel module. + +The ``VLSI_TOP=Sha3AccelwBB`` indicates that we are only interested in physical design of the accelerator block. If this variable is not set, the entire SoC will be pushed through physical design. Note that you should not set the ``TOP`` variable because it is used during Chisel elaboration. + +For the curious, ``make buildfile`` generates a set of Make targets in ``build/hammer.d``. It needs to be re-run if environment variables are changed. It is recommended that you edit these variables directly in the Makefile rather than exporting them to your shell environment. + +Running the VLSI Flow +--------------------- + +example-vlsi +^^^^^^^^^^^^ +This is the entry script with placeholders for hooks. In the ``ExampleDriver`` class, a list of hooks is passed in the ``get_extra_par_hooks``. Hooks are additional snippets of python and TCL (via ``x.append()``) to extend the Hammer APIs. Hooks can be inserted using the ``make_pre/post/replacement_hook`` methods as shown in this example. Refer to the Hammer documentation on hooks for a detailed description of how these are injected into the VLSI flow. + +The ``scale_final_gds`` hook is a particularly powerful hook. It dumps a Python script provided by the ASAP7 tech plugin, an executes it within the Innovus TCL interpreter. This hook is run after ``write_design`` because the ASAP7 PDK requires post-par GDSs to be scaled down by a factor of 4. + +example.yml +^^^^^^^^^^^ +This contains the Hammer configuration for this example project. Example clock constraints, power straps definitions, placement constraints, and pin constraints are given. Additional configuration for the extra libraries and tools are at the bottom. + +First, set ``technology.asap7.tarball_dir`` to the absolute path of where the downloaded the ASAP7 PDK tarball lives. + +Synthesis +^^^^^^^^^ +.. code-block:: shell + + ``make syn`` + +Post-synthesis logs and collateral are in ``build/syn-rundir``. The raw QoR data is available at ``build/syn-rundir/reports``, and methods to extract this information for design space exploration are a WIP. + +Place-and-Route +^^^^^^^^^^^^^^^ +.. code-block:: shell + + ``make par`` + +After completion, the final database can be opened in an interactive Innovus session via ``./build/par-rundir/generated-scripts/open_chip``. + +Intermediate database are written in ``build/par-rundir`` between each step of the ``par`` action, and can be restored in an interactive Innovus session as desired for debugging purposes. + +Timing reports are found in ``build/par-rundir/timingReports``. They are gzipped text files. + +DRC & LVS +^^^^^^^^^ +To run DRC & LVS, and view the results in Calibre: + +.. code-block:: shell + + make drc + ./build/drc-rundir/generated-scripts/view-drc + make lvs + ./build/lvs-rundir/generated-scripts/view-lvs + +Some DRC errors are expected from this PDK, as explained in the `ASAP7 plugin readme `__. diff --git a/docs/VLSI/index.rst b/docs/VLSI/index.rst index 44303769..0f5d32d5 100644 --- a/docs/VLSI/index.rst +++ b/docs/VLSI/index.rst @@ -2,11 +2,13 @@ VLSI Flow ================================ The Chipyard framework aims to provide wrappers for a general VLSI flow. -In particular, we aim to support the HAMMER physical design generator flow. +In particular, we aim to support the Hammer physical design generator flow. .. toctree:: :maxdepth: 2 :caption: VLSI Flow: Building-A-Chip - HAMMER + Hammer + Tutorial + Advanced-Usage diff --git a/docs/_static/images/chip-bringup.png b/docs/_static/images/chip-bringup.png new file mode 100644 index 00000000..b7ed0226 Binary files /dev/null and b/docs/_static/images/chip-bringup.png differ diff --git a/docs/_static/images/chip-communication.png b/docs/_static/images/chip-communication.png new file mode 100644 index 00000000..4492bd8b Binary files /dev/null and b/docs/_static/images/chip-communication.png differ diff --git a/generators/example/src/main/resources/vsrc/GCDMMIOBlackBox.v b/generators/example/src/main/resources/vsrc/GCDMMIOBlackBox.v new file mode 100644 index 00000000..9104ae87 --- /dev/null +++ b/generators/example/src/main/resources/vsrc/GCDMMIOBlackBox.v @@ -0,0 +1,48 @@ +// DOC include start: GCD portlist +module GCDMMIOBlackBox + #(parameter WIDTH) + ( + input clock, + input reset, + output input_ready, + input input_valid, + input [WIDTH-1:0] x, + input [WIDTH-1:0] y, + input output_ready, + output output_valid, + output reg [WIDTH-1:0] gcd + ); +// DOC include end: GCD portlist + + localparam S_IDLE = 2'b00, S_RUN = 2'b01, S_DONE = 2'b10; + + reg [1:0] state; + reg [WIDTH-1:0] tmp; + + assign input_ready = state == S_IDLE; + assign output_valid = state == S_DONE; + + always @(posedge clock) begin + if (reset) + state <= S_IDLE; + else if (state == S_IDLE && input_valid) + state <= S_RUN; + else if (state == S_RUN && tmp == 0) + state <= S_DONE; + else if (state == S_DONE && output_ready) + state <= S_IDLE; + end + + always @(posedge clock) begin + if (state == S_IDLE && input_valid) begin + gcd <= x; + tmp <= y; + end else if (state == S_RUN) begin + if (gcd > tmp) + gcd <= gcd - tmp; + else + tmp <= tmp - gcd; + end + end + +endmodule // GCDMMIOBlackBox diff --git a/generators/example/src/main/scala/ConfigMixins.scala b/generators/example/src/main/scala/ConfigMixins.scala index 9d92d896..7d7e74af 100644 --- a/generators/example/src/main/scala/ConfigMixins.scala +++ b/generators/example/src/main/scala/ConfigMixins.scala @@ -87,6 +87,14 @@ class WithPWMAXI4Top extends Config((site, here, up) => { Module(LazyModule(new TopWithPWMAXI4()(p)).module) }) +/** + * Class to specify a top level BOOM and/or Rocket system with a TL-attached GCD device + */ +class WithGCDTop extends Config((site, here, up) => { + case BuildTop => (clock: Clock, reset: Bool, p: Parameters) => + Module(LazyModule(new TopWithGCD()(p)).module) +}) + /** * Class to specify a top level BOOM and/or Rocket system with a block device */ diff --git a/generators/example/src/main/scala/GCDMMIOBlackBox.scala b/generators/example/src/main/scala/GCDMMIOBlackBox.scala new file mode 100644 index 00000000..891fe1c9 --- /dev/null +++ b/generators/example/src/main/scala/GCDMMIOBlackBox.scala @@ -0,0 +1,98 @@ +package example + +import chisel3._ +import chisel3.util._ +import chisel3.core.{IntParam, Reset} +import freechips.rocketchip.amba.axi4._ +import freechips.rocketchip.subsystem.BaseSubsystem +import freechips.rocketchip.config.{Parameters, Field} +import freechips.rocketchip.diplomacy._ +import freechips.rocketchip.regmapper.{HasRegMap, RegField} +import freechips.rocketchip.tilelink._ +import freechips.rocketchip.util.UIntIsOneOf + +// DOC include start: GCD blackbox +class GCDMMIOBlackBox(w: Int) extends BlackBox(Map("WIDTH" -> IntParam(w))) with HasBlackBoxResource { + val io = IO(new Bundle { + val clock = Input(Clock()) + val reset = Input(Bool()) + val input_ready = Output(Bool()) + val input_valid = Input(Bool()) + val x = Input(UInt(w.W)) + val y = Input(UInt(w.W)) + val output_ready = Input(Bool()) + val output_valid = Output(Bool()) + val gcd = Output(UInt(w.W)) + }) + + addResource("/vsrc/GCDMMIOBlackBox.v") +} +// DOC include end: GCD blackbox + +// DOC include start: GCD instance regmap +case class GCDParams(address: BigInt, beatBytes: Int, width: Int) + +trait GCDModule extends HasRegMap { + implicit val p: Parameters + def params: GCDParams + val clock: Clock + val reset: Reset + + val impl = Module(new GCDMMIOBlackBox(params.width)) + + // How many clock cycles in a PWM cycle? + val x = Reg(UInt(params.width.W)) + val y = Wire(new DecoupledIO(impl.io.y)) + val gcd = Wire(new DecoupledIO(impl.io.gcd)) + val status = Cat(impl.io.input_ready, impl.io.output_valid) + + 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 + + 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 cake +class GCD(c: GCDParams)(implicit p: Parameters) + extends TLRegisterRouter( + c.address, "gcd", Seq("ucbbar,gcd"), + beatBytes = c.beatBytes)( + new TLRegBundle(c, _))( + new TLRegModule(c, _, _) with GCDModule) + +trait HasPeripheryGCD { this: BaseSubsystem => + implicit val p: Parameters + + private val address = 0x2000 + private val portName = "gcd" + private val gcdWidth = 32 + + val gcd = LazyModule(new GCD( + GCDParams(address, pbus.beatBytes, gcdWidth))(p)) + + pbus.toVariableWidthSlave(Some(portName)) { gcd.node } +} + +trait HasPeripheryGCDModuleImp extends LazyModuleImp { + implicit val p: Parameters + val outer: HasPeripheryGCD +} + +// DOC include end: GCD cake diff --git a/generators/example/src/main/scala/RocketConfigs.scala b/generators/example/src/main/scala/RocketConfigs.scala index 0acf7284..615111df 100644 --- a/generators/example/src/main/scala/RocketConfigs.scala +++ b/generators/example/src/main/scala/RocketConfigs.scala @@ -34,13 +34,22 @@ class RoccRocketConfig extends Config( // DOC include start: JtagRocket class jtagRocketConfig extends Config( new WithDTMTop ++ // use top with dtm - new freechips.rocketchip.subsystem.WithJtagDTM ++ // add jtag/DTM module to coreplex + new freechips.rocketchip.subsystem.WithJtagDTM ++ // add jtag+DTM module to coreplex new WithBootROM ++ new freechips.rocketchip.subsystem.WithInclusiveCache ++ new freechips.rocketchip.subsystem.WithNBigCores(1) ++ new freechips.rocketchip.system.BaseConfig) // DOC include end: JtagRocket +// DOC include start: DmiRocket +class dmiRocketConfig extends Config( + new WithDTMTop ++ // use top with dtm + new WithBootROM ++ + new freechips.rocketchip.subsystem.WithInclusiveCache ++ + new freechips.rocketchip.subsystem.WithNBigCores(1) ++ + new freechips.rocketchip.system.BaseConfig) +// DOC include end: DmiRocket + // DOC include start: PWMRocketConfig class PWMRocketConfig extends Config( new WithPWMTop ++ // use top with tilelink-controlled PWM @@ -57,6 +66,13 @@ class PWMAXI4RocketConfig extends Config( new freechips.rocketchip.subsystem.WithNBigCores(1) ++ new freechips.rocketchip.system.BaseConfig) +class GCDRocketConfig extends Config( // add MMIO GCD module + new WithGCDTop ++ + new WithBootROM ++ + new freechips.rocketchip.subsystem.WithInclusiveCache ++ + new freechips.rocketchip.subsystem.WithNBigCores(1) ++ + new freechips.rocketchip.system.BaseConfig) + class SimBlockDeviceRocketConfig extends Config( new testchipip.WithBlockDevice ++ // add block-device module to peripherybus new WithSimBlockDeviceTop ++ // use top with block-device IOs and connect to simblockdevice diff --git a/generators/example/src/main/scala/Top.scala b/generators/example/src/main/scala/Top.scala index 94bed0de..b7f1a500 100644 --- a/generators/example/src/main/scala/Top.scala +++ b/generators/example/src/main/scala/Top.scala @@ -53,6 +53,16 @@ class TopWithPWMAXI4Module(l: TopWithPWMAXI4) extends TopModule(l) //--------------------------------------------------------------------------------------------------------- +class TopWithGCD(implicit p: Parameters) extends Top + with HasPeripheryGCD { + override lazy val module = new TopWithGCDModule(this) +} + +class TopWithGCDModule(l: TopWithGCD) extends TopModule(l) + with HasPeripheryGCDModuleImp + +//--------------------------------------------------------------------------------------------------------- + class TopWithBlockDevice(implicit p: Parameters) extends Top with HasPeripheryBlockDevice { override lazy val module = new TopWithBlockDeviceModule(this) diff --git a/scripts/init-submodules-no-riscv-tools.sh b/scripts/init-submodules-no-riscv-tools.sh index 8cd6ced3..627c9285 100755 --- a/scripts/init-submodules-no-riscv-tools.sh +++ b/scripts/init-submodules-no-riscv-tools.sh @@ -16,14 +16,18 @@ git config submodule.toolchains/esp-tools.update none git config --global submodule.experimental-blocks.update none # Disable updates to the FireSim submodule until explicitly requested git config submodule.sims/firesim.update none -# Disable updates to the hammer-cad-plugins repo -git config submodule.vlsi/hammer-cad-plugins.update none +# Disable updates to the hammer tool plugins repos +git config submodule.vlsi/hammer-cadence-plugins.update none +git config submodule.vlsi/hammer-synopsys-plugins.update none +git config submodule.vlsi/hammer-mentor-plugins.update none git submodule update --init --recursive #--jobs 8 # unignore riscv-tools,catapult-shell2 globally git config --unset submodule.toolchains/riscv-tools.update git config --unset submodule.toolchains/esp-tools.update git config --global --unset submodule.experimental-blocks.update -git config --unset submodule.vlsi/hammer-cad-plugins.update +git config --unset submodule.vlsi/hammer-cadence-plugins.update +git config --unset submodule.vlsi/hammer-synopsys-plugins.update +git config --unset submodule.vlsi/hammer-mentor-plugins.update # Renable firesim and init only the required submodules to provide # all required scala deps, without doing a full build-setup diff --git a/scripts/init-vlsi.sh b/scripts/init-vlsi.sh index 89f9ac56..bbc562d4 100755 --- a/scripts/init-vlsi.sh +++ b/scripts/init-vlsi.sh @@ -1,11 +1,15 @@ #!/usr/bin/env bash -# exit script if any command fails +# exit script if any command fails set -e set -o pipefail # Initialize HAMMER and CAD-plugins git submodule update --init --recursive vlsi/hammer -git submodule update --init --recursive vlsi/hammer-cad-plugins +git submodule update --init --recursive vlsi/hammer-cadence-plugins +git submodule update --init --recursive vlsi/hammer-synopsys-plugins +git submodule update --init --recursive vlsi/hammer-mentor-plugins # Initialize HAMMER tech plugin -git submodule update --init --recursive vlsi/hammer-"$1"-plugin +if [[ $1 != *asap7* ]]; then + git submodule update --init --recursive vlsi/hammer-$1-plugin +fi diff --git a/tests/gcd.c b/tests/gcd.c new file mode 100644 index 00000000..a89abf65 --- /dev/null +++ b/tests/gcd.c @@ -0,0 +1,42 @@ +#include "mmio.h" + +#define GCD_STATUS 0x2000 +#define GCD_X 0x2004 +#define GCD_Y 0x2008 +#define GCD_GCD 0x200C + +unsigned int gcd_ref(unsigned int x, unsigned int y) { + while (y != 0) { + if (x > y) + x = x - y; + else + y = y - x; + } + return x; +} + +// DOC include start: GCD test +int main(void) +{ + uint32_t result, ref, x = 20, y = 15; + + // wait for peripheral to be ready + while ((reg_read8(GCD_STATUS) & 0x2) == 0) ; + + reg_write32(GCD_X, x); + reg_write32(GCD_Y, y); + + + // wait for peripheral to complete + while ((reg_read8(GCD_STATUS) & 0x1) == 0) ; + + result = reg_read32(GCD_GCD); + ref = gcd_ref(x, y); + + if (result != ref) { + printf("Hardware result %d does not match reference value %d\n", result, ref); + return 1; + } + return 0; +} +// DOC include end: GCD test diff --git a/vlsi/Makefile b/vlsi/Makefile index 519d1448..cc61b957 100644 --- a/vlsi/Makefile +++ b/vlsi/Makefile @@ -18,22 +18,30 @@ include $(base_dir)/variables.mk # vlsi types and rules ######################################################################################### sim_name ?= vcs # needed for GenerateSimFiles, but is unused -tech_name ?= -tech_dir ?= $(vlsi_dir)/hammer-$(tech_name)-plugin/$(tech_name) +tech_name ?= asap7 +tech_dir ?= $(if $(filter $(tech_name), asap7), $(vlsi_dir)/hammer/src/hammer-vlsi/technology/$(tech_name), $(vlsi_dir)/hammer-$(tech_name)-plugin/$(tech_name)) SMEMS_COMP ?= $(tech_dir)/sram-compiler.json SMEMS_CACHE ?= $(tech_dir)/sram-cache.json SMEMS_HAMMER ?= $(build_dir)/$(long_name).mems.hammer.json MACROCOMPILER_MODE ?= -l $(SMEMS_CACHE) -hir $(SMEMS_HAMMER) OBJ_DIR ?= $(vlsi_dir)/build -ENV_YML ?= $(vlsi_dir)/bwrc-env.yml -INPUT_CONFS ?= example.yml $(dir $(tech_dir))/bwrc.yml +ENV_YML ?= $(vlsi_dir)/env.yml +INPUT_CONFS ?= example.yml HAMMER_EXEC ?= ./example-vlsi +VLSI_TOP ?= $(TOP) ######################################################################################### # general rules ######################################################################################### -ALL_RTL = $(TOP_FILE) $(TOP_SMEMS_FILE) $(extra_v_includes) -extra_v_includes = $(build_dir)/EICG_wrapper.v +ALL_RTL = $(TOP_FILE) $(TOP_SMEMS_FILE) +extra_v_includes = $(build_dir)/EICG_wrapper.v $(vlsi_dir)/example.v +ifneq ($(CUSTOM_VLOG), ) + VLSI_RTL = $(CUSTOM_VLOG) + VLSI_BB = /dev/null +else + VLSI_RTL = $(ALL_RTL) $(extra_v_includes) + VLSI_BB = $(sim_top_blackboxes) +endif .PHONY: default verilog default: all @@ -74,14 +82,17 @@ $(SRAM_CONF): $(SRAM_GENERATOR_CONF) # synthesis input configuration ######################################################################################### SYN_CONF = $(OBJ_DIR)/inputs.yml -GENERATED_CONFS = $(SYN_CONF) $(SRAM_CONF) +GENERATED_CONFS = $(SYN_CONF) +ifeq ($(CUSTOM_VLOG), ) + GENERATED_CONFS += $(if $(filter $(tech_name), asap7), , $(SRAM_CONF)) +endif -$(SYN_CONF): $(ALL_RTL) $(extra_v_includes) $(sim_top_blackboxes) +$(SYN_CONF): $(VLSI_RTL) $(VLSI_BB) mkdir -p $(dir $@) echo "synthesis.inputs:" > $@ - echo " top_module: $(TOP)" >> $@ + echo " top_module: $(VLSI_TOP)" >> $@ echo " input_files:" >> $@ - for x in $(ALL_RTL) $(extra_v_includes) `cat $(sim_top_blackboxes)`; do \ + for x in $(VLSI_RTL) `cat $(VLSI_BB)`; do \ echo ' - "'$$x'"' >> $@; \ done diff --git a/vlsi/README.md b/vlsi/README.md deleted file mode 100644 index aa07dd0f..00000000 --- a/vlsi/README.md +++ /dev/null @@ -1,9 +0,0 @@ -This is the starting point for a vlsi flow from this repository. - -This flow will not work without the necessary CAD and technology plugins for HAMMER. - -If you are a UCB-affiliate, you may be able to acquire access to the tech-plugins. - -# Initial Setup Instructions (For All technologies) -Run the `init-vlsi.sh` script to pull correct versions of hammer, hammer-cad-plugins, and the hammer-tech-plugins -```scripts/init-vlsi.sh TECH_NAME``` \ No newline at end of file diff --git a/vlsi/env.yml b/vlsi/env.yml new file mode 100644 index 00000000..c4e63038 --- /dev/null +++ b/vlsi/env.yml @@ -0,0 +1,13 @@ +# Base path to where Mentor tools are installed +mentor.mentor_home: "" +# Mentor license server/file +mentor.MGLS_LICENSE_FILE: "" +# Base path to where Cadence tools are installed +cadence.cadence_home: "" +# Cadence license server/file +cadence.CDS_LIC_FILE: "" +# Base path to where Synopsys tools are installed +synopsys.synopsys_home: "" +# Synopsys license server/files +synopsys.SNPSLMD_LICENSE_FILE: "" +synopsys.MGLS_LICENSE_FILE: "" diff --git a/vlsi/example-vlsi b/vlsi/example-vlsi index 3f65d9a5..a17f4f0c 100755 --- a/vlsi/example-vlsi +++ b/vlsi/example-vlsi @@ -1,4 +1,5 @@ #!/usr/bin/env python3 +import os import hammer_vlsi from hammer_vlsi import CLIDriver, HammerToolHookAction @@ -8,12 +9,60 @@ from typing import Dict, Callable, Optional, List def example_place_tap_cells(x: hammer_vlsi.HammerTool) -> bool: x.append(''' # TODO +# Place custom TCL here ''') return True +def example_add_fillers(x: hammer_vlsi.HammerTool) -> bool: + x.append(''' +# TODO +# Place custom TCL here +''') + return True + +def example_tool_settings(x: hammer_vlsi.HammerTool) -> bool: + x.append(''' +# TODO +# Place custom TCL here +''') + return True + +def scale_final_gds(x: hammer_vlsi.HammerTool) -> bool: + """ + Scale the final GDS by a factor of 4 + """ + x.append(''' +# Write script out to a temporary file and execute it +set fp [open "{script_file}" "w"] +puts -nonewline $fp "{script_text}" +close $fp +if {{ [catch {{ exec python3 {script_file} }} msg] }} {{ + puts "$::errorInfo" +}} +'''.format(script_text=x.technology.scale_gds_script(x.output_gds_filename), script_file=os.path.join(x.run_dir, "gds_scale.py"))) + return True + + class ExampleDriver(CLIDriver): def get_extra_par_hooks(self) -> List[HammerToolHookAction]: - return [hammer_vlsi.HammerTool.make_replacement_hook("place_tap_cells", example_place_tap_cells)] + extra_hooks = [ + + # Default set of steps can be found in the CAD tool plugin's __init__.py + + # make_pre_insertion_hook will execute the custom hook before the specified step + hammer_vlsi.HammerTool.make_pre_insertion_hook("route_design", example_add_fillers), # SYNTAX: make_pre_insertion_hook("EXISTING_STEP", INSERTED_HOOK) + # make_post_insertion_hook will execute the custom hook after the specified step + hammer_vlsi.HammerTool.make_post_insertion_hook("init_design", example_tool_settings), + # make_replacement_hook will replace the specified step with a custom hook + hammer_vlsi.HammerTool.make_replacement_hook("place_tap_cells", example_place_tap_cells), + # make_removal_hook will remove the specified step from the flow + hammer_vlsi.HammerTool.make_removal_hook("place_bumps"), + # The target step in any of the above calls may be a default step or another one of your custom hooks + + # This is an example of a technology-supplied hook (look in hammer/src/hammer-vlsi/technology/asap7/__init__.py) + hammer_vlsi.HammerTool.make_post_insertion_hook("write_design", scale_final_gds) + ] + return extra_hooks if __name__ == '__main__': ExampleDriver().main() diff --git a/vlsi/example.v b/vlsi/example.v new file mode 100644 index 00000000..dbc7bec5 --- /dev/null +++ b/vlsi/example.v @@ -0,0 +1,65 @@ +// Sha3Accel w/ a blackbox (a dummy DCO) included inside + +module Sha3AccelwBB( // @[:example.TestHarness.Sha3RocketConfig.fir@135905.2] + input clock, // @[:example.TestHarness.Sha3RocketConfig.fir@135906.4] + input reset, // @[:example.TestHarness.Sha3RocketConfig.fir@135907.4] + output io_cmd_ready, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input io_cmd_valid, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input [6:0] io_cmd_bits_inst_funct, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input [63:0] io_cmd_bits_rs1, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input [63:0] io_cmd_bits_rs2, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input io_mem_req_ready, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + output io_mem_req_valid, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + output [39:0] io_mem_req_bits_addr, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + output [7:0] io_mem_req_bits_tag, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + output [4:0] io_mem_req_bits_cmd, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + output [63:0] io_mem_req_bits_data, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input io_mem_resp_valid, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input [7:0] io_mem_resp_bits_tag, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input [63:0] io_mem_resp_bits_data, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + output io_busy, // @[:example.TestHarness.Sha3RocketConfig.fir@135909.4] + input [13:0] col_sel_b, + input [15:0] row_sel_b, + input [7:0] code_regulator, + input dither, + input sleep_b, + output dco_clock +); + Sha3Accel sha3 ( + .clock(clock), + .reset(reset), + .io_cmd_ready(io_cmd_ready), + .io_cmd_valid(io_cmd_valid), + .io_cmd_bits_inst_funct(io_cmd_bits_inst_funct), + .io_cmd_bits_rs1(io_cmd_bits_rs1), + .io_cmd_bits_rs2(io_cmd_bits_rs2), + .io_mem_req_ready(io_mem_req_ready), + .io_mem_req_valid(io_mem_req_valid), + .io_mem_req_bits_addr(io_mem_req_bits_addr), + .io_mem_req_bits_tag(io_mem_req_bits_tag), + .io_mem_req_bits_cmd(io_mem_req_bits_cmd), + .io_mem_req_bits_data(io_mem_req_bits_data), + .io_mem_resp_valid(io_mem_resp_valid), + .io_mem_resp_bits_tag(io_mem_resp_bits_tag), + .io_mem_resp_bits_data(io_mem_resp_bits_data), + .io_busy(io_busy) + ); + ExampleDCO dco ( + .col_sel_b(col_sel_b), + .row_sel_b(row_sel_b), + .code_regulator(code_regulator), + .dither(dither), + .sleep_b(sleep_b), + .clock(dco_clock) + ); +endmodule + +module ExampleDCO ( + input [13:0] col_sel_b, + input [15:0] row_sel_b, + input [7:0] code_regulator, + input dither, + input sleep_b, + output clock +); +endmodule diff --git a/vlsi/example.yml b/vlsi/example.yml new file mode 100644 index 00000000..d8ca594b --- /dev/null +++ b/vlsi/example.yml @@ -0,0 +1,134 @@ +# Technology Setup +# Technology used is ASAP7 +vlsi.core.technology: asap7 +# Specify dir with ASAP7 tarball +technology.asap7.tarball_dir: "" + +vlsi.core.max_threads: 12 + +# General Hammer Inputs + +# Hammer will auto-generate a CPF for simple power designs; see hammer/src/hammer-vlsi/defaults.yml for more info +vlsi.inputs.power_spec_mode: "auto" +vlsi.inputs.power_spec_type: "cpf" + +# Specify clock signals +vlsi.inputs.clocks: [ + {name: "clock", period: "1ns", uncertainty: "0.1ns"} +] + +# Generate Make include to aid in flow +vlsi.core.build_system: make + +# Power Straps +par.power_straps_mode: generate +par.generate_power_straps_method: by_tracks +par.blockage_spacing: 2.0 +par.generate_power_straps_options: + by_tracks: + strap_layers: + - M3 + - M4 + - M5 + - M6 + - M7 + - M8 + - M9 + track_width: 5 + track_spacing: 0 + track_start: 10 + power_utilization: 0.05 + power_utilization_M8: 1.0 + power_utilization_M9: 1.0 + +# Placement Constraints +# For ASAP7, all numbers must be 4x larger than final GDS +vlsi.inputs.placement_constraints: + - path: "Sha3AccelwBB" + type: toplevel + x: 0 + y: 0 + width: 300 + height: 300 + margins: + left: 0 + right: 0 + top: 0 + bottom: 1.08 #must be at least this number + - path: "Sha3AccelwBB/dco" + type: hardmacro + x: 108 + y: 108 + width: 128 + height: 128 + orientation: r0 + top_layer: M9 + +# Pin placement constraints +vlsi.inputs.pin_mode: generated +vlsi.inputs.pin.generate_mode: semi_auto +vlsi.inputs.pin.assignments: [ + {pins: "*", layers: ["M5", "M7"], side: "bottom"} +] + +# Paths to extra libraries +vlsi.technology.extra_libraries_meta: ["append", "deepsubst"] +vlsi.technology.extra_libraries: + - library: + nldm liberty file_deepsubst_meta: "local" + nldm liberty file: "extra_libraries/example/ExampleDCO_PVT_0P63V_100C.lib" + lef file_deepsubst_meta: "local" + lef file: "extra_libraries/example/ExampleDCO.lef" + gds file_deepsubst_meta: "local" + gds file: "extra_libraries/example/ExampleDCO.gds" + corner: + nmos: "slow" + pmos: "slow" + temperature: "100 C" + supplies: + VDD: "0.63 V" + GND: "0 V" + - library: + nldm liberty file_deepsubst_meta: "local" + nldm liberty file: "extra_libraries/example/ExampleDCO_PVT_0P77V_0C.lib" + lef file_deepsubst_meta: "local" + lef file: "extra_libraries/example/ExampleDCO.lef" + gds file_deepsubst_meta: "local" + gds file: "extra_libraries/example/ExampleDCO.gds" + corner: + nmos: "fast" + pmos: "fast" + temperature: "0 C" + supplies: + VDD: "0.77 V" + GND: "0 V" + +# Because the DCO is a dummy layout, we treat it as a physical-only cell +par.inputs.physical_only_cells_mode: append +par.inputs.physical_only_cells_list: + - ExampleDCO + +# SRAM Compiler compiler options +vlsi.core.sram_generator_tool: "sram_compiler" +# You should specify a location for the SRAM generator in the tech plugin +vlsi.core.sram_generator_tool_path: [] +vlsi.core.sram_generator_tool_path_meta: "append" + +# Tool options. Replace with your tool plugin of choice. +# Genus options +vlsi.core.synthesis_tool: "genus" +vlsi.core.synthesis_tool_path: ["hammer-cadence-plugins/synthesis"] +vlsi.core.synthesis_tool_path_meta: "append" +synthesis.genus.version: "1813" +# Innovus options +vlsi.core.par_tool: "innovus" +vlsi.core.par_tool_path: ["hammer-cadence-plugins/par"] +vlsi.core.par_tool_path_meta: "append" +par.innovus.version: "191" +par.innovus.design_flow_effort: "standard" +par.inputs.gds_merge: true +# Calibre options +vlsi.core.drc_tool: "calibre" +vlsi.core.drc_tool_path: ["hammer-mentor-plugins/drc"] +vlsi.core.lvs_tool: "calibre" +vlsi.core.lvs_tool_path: ["hammer-mentor-plugins/lvs"] diff --git a/vlsi/extra_libraries/example/ExampleDCO.gds b/vlsi/extra_libraries/example/ExampleDCO.gds new file mode 100644 index 00000000..9990b41c Binary files /dev/null and b/vlsi/extra_libraries/example/ExampleDCO.gds differ diff --git a/vlsi/extra_libraries/example/ExampleDCO.lef b/vlsi/extra_libraries/example/ExampleDCO.lef new file mode 100644 index 00000000..ad850e2c --- /dev/null +++ b/vlsi/extra_libraries/example/ExampleDCO.lef @@ -0,0 +1,379 @@ +VERSION 5.6 ; +BUSBITCHARS "[]" ; +DIVIDERCHAR "/" ; + +MACRO ExampleDCO + CLASS BLOCK ; + ORIGIN 0 0 ; + FOREIGN ExampleDCO 0 0 ; + SIZE 128.0 BY 128.0 ; + SYMMETRY X Y ; + PIN VDD + DIRECTION INOUT ; + USE POWER ; + PORT + LAYER M7 ; + RECT 32.96 124.0 33.6 128.0 ; + END + END VDD + PIN VSS + DIRECTION INOUT ; + USE GROUND ; + PORT + LAYER M5 ; + RECT 93.12 124.0 93.76 128.0 ; + END + END VSS + PIN col_sel_b[13] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 113.28 4.0 113.664 ; + END + END col_sel_b[13] + PIN col_sel_b[11] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 107.648 4.0 108.032 ; + END + END col_sel_b[11] + PIN col_sel_b[5] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 90.752 4.0 91.136 ; + END + END col_sel_b[5] + PIN col_sel_b[12] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 110.464 4.0 110.848 ; + END + END col_sel_b[12] + PIN col_sel_b[10] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 104.832 4.0 105.216 ; + END + END col_sel_b[10] + PIN col_sel_b[9] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 102.016 4.0 102.4 ; + END + END col_sel_b[9] + PIN col_sel_b[8] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 99.2 4.0 99.584 ; + END + END col_sel_b[8] + PIN col_sel_b[7] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 96.384 4.0 96.768 ; + END + END col_sel_b[7] + PIN col_sel_b[6] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 93.568 4.0 93.952 ; + END + END col_sel_b[6] + PIN col_sel_b[4] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 87.936 4.0 88.32 ; + END + END col_sel_b[4] + PIN col_sel_b[3] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 85.12 4.0 85.504 ; + END + END col_sel_b[3] + PIN col_sel_b[2] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 82.304 4.0 82.688 ; + END + END col_sel_b[2] + PIN col_sel_b[1] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 79.488 4.0 79.872 ; + END + END col_sel_b[1] + PIN col_sel_b[0] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 76.672 4.0 77.056 ; + END + END col_sel_b[0] + PIN row_sel_b[14] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 71.04 4.0 71.424 ; + END + END row_sel_b[14] + PIN row_sel_b[13] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 68.224 4.0 68.608 ; + END + END row_sel_b[13] + PIN row_sel_b[12] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 65.408 4.0 65.792 ; + END + END row_sel_b[12] + PIN row_sel_b[11] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 62.592 4.0 62.976 ; + END + END row_sel_b[11] + PIN row_sel_b[10] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 59.776 4.0 60.16 ; + END + END row_sel_b[10] + PIN row_sel_b[9] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 56.96 4.0 57.344 ; + END + END row_sel_b[9] + PIN row_sel_b[8] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 54.144 4.0 54.528 ; + END + END row_sel_b[8] + PIN row_sel_b[7] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 51.328 4.0 51.712 ; + END + END row_sel_b[7] + PIN row_sel_b[6] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 48.512 4.0 48.896 ; + END + END row_sel_b[6] + PIN row_sel_b[5] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 45.696 4.0 46.08 ; + END + END row_sel_b[5] + PIN row_sel_b[4] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 42.88 4.0 43.264 ; + END + END row_sel_b[4] + PIN row_sel_b[3] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 40.064 4.0 40.448 ; + END + END row_sel_b[3] + PIN row_sel_b[2] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 37.248 4.0 37.632 ; + END + END row_sel_b[2] + PIN row_sel_b[1] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 34.432 4.0 34.816 ; + END + END row_sel_b[1] + PIN row_sel_b[0] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 31.616 4.0 32.0 ; + END + END row_sel_b[0] + PIN code_regulator[7] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 28.8 4.0 29.184 ; + END + END code_regulator[7] + PIN code_regulator[6] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 25.984 4.0 26.368 ; + END + END code_regulator[6] + PIN code_regulator[5] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 23.168 4.0 23.552 ; + END + END code_regulator[5] + PIN code_regulator[4] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 20.352 4.0 20.736 ; + END + END code_regulator[4] + PIN code_regulator[3] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 17.536 4.0 17.92 ; + END + END code_regulator[3] + PIN code_regulator[2] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 14.72 4.0 15.104 ; + END + END code_regulator[2] + PIN code_regulator[1] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 11.904 4.0 12.288 ; + END + END code_regulator[1] + PIN code_regulator[0] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 9.088 4.0 9.472 ; + END + END code_regulator[0] + PIN row_sel_b[15] + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 73.856 4.0 74.24 ; + END + END row_sel_b[15] + PIN dither + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 0.0 6.272 4.0 6.656 ; + END + END dither + PIN sleep_b + DIRECTION INPUT ; + USE SIGNAL ; + PORT + LAYER M5 ; + RECT 9.792 0.0 10.176 4.0 ; + END + END sleep_b + PIN clock + DIRECTION OUTPUT ; + USE SIGNAL ; + PORT + LAYER M4 ; + RECT 124.0 70.864 128.0 71.248 ; + END + END clock + OBS + LAYER M1 ; + RECT 4.0 4.0 124.0 124.0 ; + LAYER M2 ; + RECT 4.0 4.0 124.0 124.0 ; + LAYER M3 ; + RECT 4.0 4.0 124.0 124.0 ; + LAYER M4 ; + RECT 4.0 4.0 124.0 124.0 ; + LAYER M5 ; + RECT 4.0 4.0 124.0 124.0 ; + LAYER M6 ; + RECT 4.0 4.0 124.0 124.0 ; + LAYER M7 ; + RECT 4.0 4.0 124.0 124.0 ; + LAYER M8 ; + RECT 0.0 0.0 128.0 128.0 ; + LAYER M9 ; + RECT 0.0 0.0 128.0 128.0 ; + LAYER Pad ; + RECT 0.0 0.0 128.0 128.0 ; + END +END ExampleDCO + +END LIBRARY diff --git a/vlsi/extra_libraries/example/ExampleDCO_PVT_0P63V_100C.lib b/vlsi/extra_libraries/example/ExampleDCO_PVT_0P63V_100C.lib new file mode 100644 index 00000000..53d981eb --- /dev/null +++ b/vlsi/extra_libraries/example/ExampleDCO_PVT_0P63V_100C.lib @@ -0,0 +1,142 @@ +library (ExampleDCO_PVT_0P63V_100C) { + technology (cmos); + date : "Mon Sep 2 16:01:59 2019"; + comment : "Generated by dotlibber.py"; + revision : 0; + delay_model : table_lookup; + simulation : true; + capacitive_load_unit (1,pf); + voltage_unit : "1V"; + current_unit : "1mA"; + time_unit : "1ns"; + pulling_resistance_unit : "1kohm"; + nom_process : 1; + nom_temperature : 100; + nom_voltage : 0.630000; + voltage_map(VDD, 0.630000); + voltage_map(VSS, 0.000000); + operating_conditions("PVT_0P63V_100C") { + process : 1; + temperature : 100; + voltage : 0.630000; + } + default_operating_conditions : PVT_0P63V_100C; + lu_table_template (constraint_template_3x3) { + variable_1 : related_pin_transition; + variable_2 : constrained_pin_transition; + index_1 ("0.0002, 0.0004, 0.0006"); + index_2 ("0.0002, 0.0004, 0.0006"); + } + lu_table_template (delay_template_8x8) { + variable_1 : input_net_transition; + variable_2 : total_output_net_capacitance; + index_1 ("0.0001, 0.0002, 0.0003, 0.0004, 0.0005, 0.0006, 0.0007, 0.0008"); + index_2 ("0.0011, 0.0022, 0.0033, 0.0044, 0.0055, 0.0066, 0.0077, 0.0088"); + } + + + type (bus_13_to_0) { + base_type : array ; + data_type : bit ; + bit_width : 14 ; + bit_from : 13 ; + bit_to : 0 ; + downto : true ; + } + + + type (bus_15_to_0) { + base_type : array ; + data_type : bit ; + bit_width : 16 ; + bit_from : 15 ; + bit_to : 0 ; + downto : true ; + } + + + type (bus_7_to_0) { + base_type : array ; + data_type : bit ; + bit_width : 8 ; + bit_from : 7 ; + bit_to : 0 ; + downto : true ; + } + cell (ExampleDCO) { + dont_use : true; + dont_touch : true; + is_macro_cell : true; + + pg_pin (VDD) { + pg_type : primary_power; + voltage_name : VDD; + } + + pg_pin (VSS) { + pg_type : primary_ground; + voltage_name : VSS; + } + + pin (clock) { + direction : output; + clock : true; + max_capacitance : 0.02; + related_power_pin : VDD; + related_ground_pin : VSS; + } + + bus ( col_sel_b ) { + bus_type : bus_13_to_0; + direction : input; + capacitance : 0.006; + max_transition : 0.04; + + pin ( col_sel_b[13:0] ) { + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + + bus ( row_sel_b ) { + bus_type : bus_15_to_0; + direction : input; + capacitance : 0.006; + max_transition : 0.04; + + pin ( row_sel_b[15:0] ) { + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + + bus ( code_regulator ) { + bus_type : bus_7_to_0; + direction : input; + capacitance : 0.006; + max_transition : 0.04; + + pin ( code_regulator[7:0] ) { + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + + pin (dither) { + direction : input; + capacitance : 0.006; + max_transition : 0.04; + related_power_pin : VDD; + related_ground_pin : VSS; + } + + pin (sleep_b) { + direction : input; + capacitance : 0.006; + max_transition : 0.04; + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + +} diff --git a/vlsi/extra_libraries/example/ExampleDCO_PVT_0P77V_0C.lib b/vlsi/extra_libraries/example/ExampleDCO_PVT_0P77V_0C.lib new file mode 100644 index 00000000..374b1899 --- /dev/null +++ b/vlsi/extra_libraries/example/ExampleDCO_PVT_0P77V_0C.lib @@ -0,0 +1,142 @@ +library (ExampleDCO_PVT_0P77V_0C) { + technology (cmos); + date : "Mon Sep 2 16:01:59 2019"; + comment : "Generated by dotlibber.py"; + revision : 0; + delay_model : table_lookup; + simulation : true; + capacitive_load_unit (1,pf); + voltage_unit : "1V"; + current_unit : "1mA"; + time_unit : "1ns"; + pulling_resistance_unit : "1kohm"; + nom_process : 1; + nom_temperature : 0; + nom_voltage : 0.770000; + voltage_map(VDD, 0.770000); + voltage_map(VSS, 0.000000); + operating_conditions("PVT_0P77V_0C") { + process : 1; + temperature : 0; + voltage : 0.770000; + } + default_operating_conditions : PVT_0P77V_0C; + lu_table_template (constraint_template_3x3) { + variable_1 : related_pin_transition; + variable_2 : constrained_pin_transition; + index_1 ("0.0001, 0.0002, 0.0003"); + index_2 ("0.0001, 0.0002, 0.0003"); + } + lu_table_template (delay_template_8x8) { + variable_1 : input_net_transition; + variable_2 : total_output_net_capacitance; + index_1 ("0.0003, 0.0004, 0.0005, 0.0006, 0.0007, 0.0008, 0.0009, 0.001"); + index_2 ("0.0011, 0.0022, 0.0033, 0.0044, 0.0055, 0.0066, 0.0077, 0.0088"); + } + + + type (bus_13_to_0) { + base_type : array ; + data_type : bit ; + bit_width : 14 ; + bit_from : 13 ; + bit_to : 0 ; + downto : true ; + } + + + type (bus_15_to_0) { + base_type : array ; + data_type : bit ; + bit_width : 16 ; + bit_from : 15 ; + bit_to : 0 ; + downto : true ; + } + + + type (bus_7_to_0) { + base_type : array ; + data_type : bit ; + bit_width : 8 ; + bit_from : 7 ; + bit_to : 0 ; + downto : true ; + } + cell (ExampleDCO) { + dont_use : true; + dont_touch : true; + is_macro_cell : true; + + pg_pin (VDD) { + pg_type : primary_power; + voltage_name : VDD; + } + + pg_pin (VSS) { + pg_type : primary_ground; + voltage_name : VSS; + } + + pin (clock) { + direction : output; + clock : true; + max_capacitance : 0.02; + related_power_pin : VDD; + related_ground_pin : VSS; + } + + bus ( col_sel_b ) { + bus_type : bus_13_to_0; + direction : input; + capacitance : 0.006; + max_transition : 0.04; + + pin ( col_sel_b[13:0] ) { + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + + bus ( row_sel_b ) { + bus_type : bus_15_to_0; + direction : input; + capacitance : 0.006; + max_transition : 0.04; + + pin ( row_sel_b[15:0] ) { + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + + bus ( code_regulator ) { + bus_type : bus_7_to_0; + direction : input; + capacitance : 0.006; + max_transition : 0.04; + + pin ( code_regulator[7:0] ) { + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + + pin (dither) { + direction : input; + capacitance : 0.006; + max_transition : 0.04; + related_power_pin : VDD; + related_ground_pin : VSS; + } + + pin (sleep_b) { + direction : input; + capacitance : 0.006; + max_transition : 0.04; + related_power_pin : VDD; + related_ground_pin : VSS; + } + } + +} diff --git a/vlsi/hammer b/vlsi/hammer index a27886fb..1b07b9a3 160000 --- a/vlsi/hammer +++ b/vlsi/hammer @@ -1 +1 @@ -Subproject commit a27886fb42c121f3ba5f684acaf5856b2ec293e1 +Subproject commit 1b07b9a378c2936389b95f7ee1436e1f492d55e2 diff --git a/vlsi/hammer-cad-plugins b/vlsi/hammer-cad-plugins deleted file mode 160000 index 72809f53..00000000 --- a/vlsi/hammer-cad-plugins +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 72809f538c4bbe91c103de52e92baad9df6d8f9a diff --git a/vlsi/hammer-cadence-plugins b/vlsi/hammer-cadence-plugins new file mode 160000 index 00000000..06ce365b --- /dev/null +++ b/vlsi/hammer-cadence-plugins @@ -0,0 +1 @@ +Subproject commit 06ce365b36e4b8520372968a5ef2a301afe8d5d6 diff --git a/vlsi/hammer-mentor-plugins b/vlsi/hammer-mentor-plugins new file mode 160000 index 00000000..33ccdccf --- /dev/null +++ b/vlsi/hammer-mentor-plugins @@ -0,0 +1 @@ +Subproject commit 33ccdccf2c04a26cceeeb03a29b9cfad38908328 diff --git a/vlsi/hammer-synopsys-plugins b/vlsi/hammer-synopsys-plugins new file mode 160000 index 00000000..e0ace734 --- /dev/null +++ b/vlsi/hammer-synopsys-plugins @@ -0,0 +1 @@ +Subproject commit e0ace7345e98e11b17ce550550c902782010e032