Logo
stable
  • 1. Chipyard Basics
    • 1.1. Chipyard Components
      • 1.1.1. Generators
        • 1.1.1.1. Processor Cores
        • 1.1.1.2. Accelerators
        • 1.1.1.3. System Components:
      • 1.1.2. Tools
      • 1.1.3. Toolchains
      • 1.1.4. Software
      • 1.1.5. Sims
      • 1.1.6. Prototyping
      • 1.1.7. VLSI
    • 1.2. Development Ecosystem
      • 1.2.1. Chipyard Approach
      • 1.2.2. Chisel/FIRRTL
      • 1.2.3. RTL Generators
    • 1.3. Configs, Parameters, Mixins, and Everything In Between
      • 1.3.1. Parameters
      • 1.3.2. Configs
      • 1.3.3. Cake Pattern / Mixin
      • 1.3.4. Additional References
    • 1.4. Initial Repository Setup
      • 1.4.1. Prerequisites
        • 1.4.1.1. Running on AWS EC2 with FireSim
        • 1.4.1.2. Default Requirements Installation
      • 1.4.2. Setting up the Chipyard Repo
      • 1.4.3. Sourcing env.sh
      • 1.4.4. DEPRECATED: Pre-built Docker Image
      • 1.4.5. What’s Next?
      • 1.4.6. Upgrading Chipyard Release Versions
  • 2. Simulation
    • 2.1. Software RTL Simulation
      • 2.1.1. Verilator (Open-Source)
      • 2.1.2. Synopsys VCS (License Required)
      • 2.1.3. Choice of Simulator
      • 2.1.4. Simulating The Default Example
      • 2.1.5. Makefile Variables and Commands
      • 2.1.6. Simulating A Custom Project
      • 2.1.7. Fast Memory Loading
      • 2.1.8. Generating Waveforms
      • 2.1.9. Visualizing Chipyard SoCs
      • 2.1.10. Additional Verilator Options
    • 2.2. FPGA-Accelerated Simulation
      • 2.2.1. FireSim
      • 2.2.2. Running your Design in FireSim
  • 3. Included RTL Generators
    • 3.1. Rocket Chip
      • 3.1.1. Tiles
      • 3.1.2. Memory System
      • 3.1.3. MMIO
      • 3.1.4. DMA
    • 3.2. Rocket Core
    • 3.3. Berkeley Out-of-Order Machine (BOOM)
    • 3.4. Constellation
    • 3.5. Hwacha
    • 3.6. Gemmini
    • 3.7. IceNet
      • 3.7.1. Controller
      • 3.7.2. Send Path
      • 3.7.3. Receive Path
      • 3.7.4. Pause Handler
      • 3.7.5. Linux Driver
      • 3.7.6. Configuration
    • 3.8. Test Chip IP
      • 3.8.1. SimTSI
      • 3.8.2. Block Device Controller
      • 3.8.3. TileLink SERDES
      • 3.8.4. TileLink Switcher
      • 3.8.5. TileLink Ring Network
      • 3.8.6. UART Adapter
      • 3.8.7. SPI Flash Model
    • 3.9. SiFive Generators
      • 3.9.1. Last-Level Cache Generator
      • 3.9.2. Peripheral Devices
    • 3.10. SHA3 RoCC Accelerator
      • 3.10.1. Introduction
      • 3.10.2. Technical Details
      • 3.10.3. Using a SHA3 Accelerator
    • 3.11. CVA6 Core
    • 3.12. Ibex Core
    • 3.13. FFT Generator
      • 3.13.1. Configuration
      • 3.13.2. Usage and Testing
      • 3.13.3. Acknowledgements
    • 3.14. NVDLA
      • 3.14.1. NVDLA Software with FireMarshal
    • 3.15. Sodor Core
    • 3.16. Shuttle RISC-V Core
    • 3.17. Mempress
    • 3.18. Prefetchers
  • 4. Development Tools
    • 4.1. Chisel
    • 4.2. FIRRTL
    • 4.3. Treadle and FIRRTL Interpreter
    • 4.4. Dsptools
    • 4.5. Barstools
      • 4.5.1. Mapping technology SRAMs (MacroCompiler)
        • 4.5.1.1. MacroCompiler Options
        • 4.5.1.2. SRAM MDF Fields
      • 4.5.2. Separating the Top module from the TestHarness module
      • 4.5.3. Macro Description Format
      • 4.5.4. Mapping technology IO cells
    • 4.6. Dromajo
  • 5. VLSI Flow
    • 5.1. Building A Chip
      • 5.1.1. Transforming the RTL
        • 5.1.1.1. Modifying the logical hierarchy
      • 5.1.2. Creating a floorplan
      • 5.1.3. Running the VLSI tool flow
    • 5.2. Core Hammer
      • 5.2.1. Actions
      • 5.2.2. Steps
      • 5.2.3. Hooks
      • 5.2.4. VLSI Flow Control
    • 5.3. Configuration (Hammer IR)
    • 5.4. Tool Plugins
    • 5.5. Technology Plugins
    • 5.6. Using Hammer To Place and Route a Custom Block
      • 5.6.1. Initialize the Hammer Plug-ins
      • 5.6.2. Setting up the Hammer Configuration Files
      • 5.6.3. Building the Design
      • 5.6.4. Running the VLSI Flow
        • 5.6.4.1. Synthesis
        • 5.6.4.2. Place-and-Route
        • 5.6.4.3. Power Estimation
        • 5.6.4.4. Signoff
      • 5.6.5. Customizing Your VLSI Flow in Hammer
        • 5.6.5.1. Advanced Environment Setup
        • 5.6.5.2. Composing a Hierarchical Design
        • 5.6.5.3. Customizing Generated Tcl Scripts
    • 5.7. ASAP7 Tutorial
      • 5.7.1. Project Structure
      • 5.7.2. Prerequisites
      • 5.7.3. Initial Setup
      • 5.7.4. Building the Design
      • 5.7.5. Running the VLSI Flow
        • 5.7.5.1. example-vlsi
        • 5.7.5.2. example-asap7.yml
        • 5.7.5.3. Synthesis
        • 5.7.5.4. Place-and-Route
        • 5.7.5.5. DRC & LVS
        • 5.7.5.6. Simulation
        • 5.7.5.7. Power/Rail Analysis
    • 5.8. Sky130 Commercial Tutorial
      • 5.8.1. Project Structure
      • 5.8.2. Prerequisites
        • 5.8.2.1. Quick Prerequisite Setup
      • 5.8.3. Initial Setup
        • 5.8.3.1. example-vlsi-sky130
        • 5.8.3.2. example-sky130.yml
        • 5.8.3.3. example-tools.yml
      • 5.8.4. Building the Design
      • 5.8.5. Running the VLSI Flow
        • 5.8.5.1. Synthesis
        • 5.8.5.2. Place-and-Route
        • 5.8.5.3. DRC & LVS
        • 5.8.5.4. Simulation
        • 5.8.5.5. Power/Rail Analysis
        • 5.8.5.6. VLSI Flow Control
    • 5.9. Sky130 + OpenROAD Tutorial
      • 5.9.1. Project Structure
      • 5.9.2. Prerequisites
        • 5.9.2.1. Quick Prerequisite Setup
      • 5.9.3. Initial Setup
        • 5.9.3.1. example-vlsi-sky130
        • 5.9.3.2. example-sky130.yml
        • 5.9.3.3. example-openroad.yml
      • 5.9.4. Building the Design
      • 5.9.5. Running the VLSI Flow
        • 5.9.5.1. Synthesis
        • 5.9.5.2. Place-and-Route
        • 5.9.5.3. DRC & LVS
        • 5.9.5.4. VLSI Flow Control
      • 5.9.6. Documentation
    • 5.10. Advanced Usage
      • 5.10.1. Hammer Development and Upgrades
      • 5.10.2. Alternative RTL Flows
      • 5.10.3. Under the Hood
      • 5.10.4. Manual Step Execution & Dependency Tracking
      • 5.10.5. Hierarchical RTL/Gate-level Simulation, Power Estimation
  • 6. Customization
    • 6.1. Heterogeneous SoCs
      • 6.1.1. Creating a Rocket and BOOM System
      • 6.1.2. Adding Hwachas
      • 6.1.3. Assigning Accelerators to Specific Tiles with MultiRoCC
    • 6.2. SoCs with NoC-based Interconnects
      • 6.2.1. Private Interconnects
      • 6.2.2. Shared Global Interconnect
    • 6.3. Integrating Custom Chisel Projects into the Generator Build System
    • 6.4. Adding a custom core
      • 6.4.1. Wrap Verilog Module with Blackbox (Optional)
      • 6.4.2. Create Parameter Case Classes
      • 6.4.3. Create Tile Class
      • 6.4.4. Connect TileLink Buses
      • 6.4.5. Create Implementation Class
      • 6.4.6. Connect Interrupt
      • 6.4.7. Create Config Fragments to Integrate the Core
    • 6.5. RoCC vs MMIO
    • 6.6. Adding a RoCC Accelerator
      • 6.6.1. Accessing Memory via L1 Cache
      • 6.6.2. Adding RoCC accelerator to Config
    • 6.7. MMIO Peripherals
      • 6.7.1. Advanced Features of RegField Entries
      • 6.7.2. Connecting by TileLink
      • 6.7.3. Top-level Traits
      • 6.7.4. Constructing the DigitalTop and Config
      • 6.7.5. Testing
    • 6.8. Dsptools Blocks
      • 6.8.1. Creating a DspBlock
      • 6.8.2. Connecting DspBlock by TileLink
      • 6.8.3. Top Level Traits
      • 6.8.4. Constructing the Top and Config
      • 6.8.5. FIR Testing
    • 6.9. Keys, Traits, and Configs
      • 6.9.1. Keys
      • 6.9.2. Traits
      • 6.9.3. Config Fragments
      • 6.9.4. Chipyard Config Fragments
    • 6.10. Adding a DMA Device
    • 6.11. Incorporating Verilog Blocks
      • 6.11.1. Adding a Verilog Blackbox Resource File
      • 6.11.2. Defining a Chisel BlackBox
      • 6.11.3. Instantiating the BlackBox and Defining MMIO
      • 6.11.4. Defining a Chip with a BlackBox
      • 6.11.5. Software Testing
      • 6.11.6. Support for Verilog Within Chipyard Tool Flows
    • 6.12. Memory Hierarchy
      • 6.12.1. The L1 Caches
      • 6.12.2. The System Bus
      • 6.12.3. The SiFive L2 Cache
      • 6.12.4. The Broadcast Hub
      • 6.12.5. The Outer Memory System
    • 6.13. Chipyard Boot Process
      • 6.13.1. BootROM and RISC-V Frontend Server
      • 6.13.2. The Berkeley Boot Loader and RISC-V Linux
    • 6.14. Adding a Firrtl Transform
      • 6.14.1. The Scala FIRRTL Compiler and the MLIR FIRRTL Compiler
      • 6.14.2. Where to add transforms
      • 6.14.3. Examples of transforms
    • 6.15. IOBinders and HarnessBinders
      • 6.15.1. IOBinders
      • 6.15.2. HarnessBinders
  • 7. Target Software
    • 7.1. FireMarshal
    • 7.2. The RISC-V ISA Simulator (Spike)
      • 7.2.1. Spike-as-a-Tile
    • 7.3. Baremetal RISC-V Programs
  • 8. Advanced Concepts
    • 8.1. Tops, Test-Harnesses, and the Test-Driver
      • 8.1.1. ChipTop/DUT
        • 8.1.1.1. Custom ChipTops
      • 8.1.2. System/DigitalTop
        • 8.1.2.1. BaseSubsystem
        • 8.1.2.2. Subsystem
        • 8.1.2.3. System
        • 8.1.2.4. Tops
      • 8.1.3. TestHarness
      • 8.1.4. TestDriver
    • 8.2. Communicating with the DUT
      • 8.2.1. Using the Tethered Serial Interface (TSI) or the Debug Module Interface (DMI)
        • 8.2.1.1. Primer on the Front-End Server (FESVR)
        • 8.2.1.2. Using the Tethered Serial Interface (TSI)
        • 8.2.1.3. Using the Debug Module Interface (DMI)
        • 8.2.1.4. Starting the TSI or DMI Simulation
      • 8.2.2. Using the JTAG Interface
        • 8.2.2.1. Debugging with JTAG
      • 8.2.3. Example Test Chip Bringup Communication
        • 8.2.3.1. Intro to Typical Chipyard Test Chip
        • 8.2.3.2. Simulation Setup of the Example Test Chip
        • 8.2.3.3. Softcore-driven Bringup Setup of the Example Test Chip after Tapeout
    • 8.3. Debugging RTL
      • 8.3.1. Waveforms
      • 8.3.2. Print Output
      • 8.3.3. Basic tests
      • 8.3.4. Torture tests
      • 8.3.5. Firesim Debugging
    • 8.4. Debugging BOOM
      • 8.4.1. Setting up Dromajo Co-simulation
    • 8.5. Accessing Scala Resources
    • 8.6. Context-Dependent-Environments
      • 8.6.1. Site
      • 8.6.2. Here
      • 8.6.3. Up
    • 8.7. Creating Clocks in the Test Harness
    • 8.8. Managing Published Scala Dependencies
      • 8.8.1. Publishing Local Changes
    • 8.9. Architectural Checkpoints
      • 8.9.1. Generating Checkpoints
      • 8.9.2. Loading Checkpoints in RTL Simulation
  • 9. TileLink and Diplomacy Reference
    • 9.1. TileLink Node Types
      • 9.1.1. Client Node
      • 9.1.2. Manager Node
      • 9.1.3. Register Node
      • 9.1.4. Identity Node
      • 9.1.5. Adapter Node
      • 9.1.6. Nexus Node
    • 9.2. Diplomacy Connectors
      • 9.2.1. :=
      • 9.2.2. :=*
      • 9.2.3. :*=
      • 9.2.4. :*=*
    • 9.3. TileLink Edge Object Methods
      • 9.3.1. Get
      • 9.3.2. Put
      • 9.3.3. Arithmetic
      • 9.3.4. Logical
      • 9.3.5. Hint
      • 9.3.6. AccessAck
      • 9.3.7. HintAck
      • 9.3.8. first
      • 9.3.9. last
      • 9.3.10. done
      • 9.3.11. count
      • 9.3.12. numBeats
      • 9.3.13. numBeats1
      • 9.3.14. hasData
    • 9.4. Register Router
      • 9.4.1. Basic Usage
      • 9.4.2. Decoupled Interfaces
      • 9.4.3. Using Functions
      • 9.4.4. Register Routers for Other Protocols
    • 9.5. Diplomatic Widgets
      • 9.5.1. TLBuffer
      • 9.5.2. AXI4Buffer
      • 9.5.3. AXI4UserYanker
      • 9.5.4. AXI4Deinterleaver
      • 9.5.5. TLFragmenter
      • 9.5.6. AXI4Fragmenter
      • 9.5.7. TLSourceShrinker
      • 9.5.8. AXI4IdIndexer
      • 9.5.9. TLWidthWidget
      • 9.5.10. TLFIFOFixer
      • 9.5.11. TLXbar and AXI4Xbar
      • 9.5.12. TLToAXI4 and AXI4ToTL
      • 9.5.13. TLROM
      • 9.5.14. TLRAM and AXI4RAM
  • 10. Prototyping Flow
    • 10.1. General Setup and Usage
      • 10.1.1. Sources
      • 10.1.2. Generating a Bitstream
      • 10.1.3. Debugging with ILAs on Supported FPGAs
    • 10.2. Running a Design on VCU118
      • 10.2.1. Basic VCU118 Design
      • 10.2.2. Brief Implementation Description + More Complicated Designs
      • 10.2.3. (Legacy) Introduction to the Legacy Bringup Design
      • 10.2.4. Running Linux on VCU118 Designs
        • 10.2.4.1. Building Linux with FireMarshal
        • 10.2.4.2. Setting up the SDCard
        • 10.2.4.3. Transfer and Run Linux from the SDCard
    • 10.3. Running a Design on Arty
      • 10.3.1. Arty100T Instructions
      • 10.3.2. Arty35T Legacy Instructions
      • 10.3.3. Brief Implementation Description and Guidance for Adding/Changing Xilinx Collateral
Chipyard
  • 9. TileLink and Diplomacy Reference
  • 9.3. TileLink Edge Object Methods
  • Edit on GitHub

9.3. TileLink Edge Object Methods

The edge object associated with a TileLink node has several helpful methods for constructing TileLink messages and retrieving data from them.

9.3.1. Get

Constructor for a TLBundleA encoding a Get message, which requests data from memory. The D channel response to this message will be an AccessAckData, which may have multiple beats.

Arguments:

  • fromSource: UInt - Source ID for this transaction

  • toAddress: UInt - The address to read from

  • lgSize: UInt - Base two logarithm of the number of bytes to be read

Returns:

A (Bool, TLBundleA) tuple. The first item in the pair is a boolean indicating whether or not the operation is legal for this edge. The second is the A channel bundle.

9.3.2. Put

Constructor for a TLBundleA encoding a PutFull or PutPartial message, which write data to memory. It will be a PutPartial if the mask is specified and a PutFull if it is omitted. The put may require multiple beats. If that is the case, only data and mask should change for each beat. All other fields must be the same for all beats in the transaction, including the address. The manager will respond to this message with a single AccessAck.

Arguments:

  • fromSource: UInt - Source ID for this transaction.

  • toAddress: UInt - The address to write to.

  • lgSize: UInt - Base two logarithm of the number of bytes to be written.

  • data: UInt - The data to write on this beat.

  • mask: UInt - (optional) The write mask for this beat.

Returns:

A (Bool, TLBundleA) tuple. The first item in the pair is a boolean indicating whether or not the operation is legal for this edge. The second is the A channel bundle.

9.3.3. Arithmetic

Constructor for a TLBundleA encoding an Arithmetic message, which is an atomic operation. The possible values for the atomic field are defined in the TLAtomics object. It can be MIN, MAX, MINU, MAXU, or ADD, which correspond to atomic minimum, maximum, unsigned minimum, unsigned maximum, or addition operations, respectively. The previous value at the memory location will be returned in the response, which will be in the form of an AccessAckData.

Arguments:

  • fromSource: UInt - Source ID for this transaction.

  • toAddress: UInt - The address to perform an arithmetic operation on.

  • lgSize: UInt - Base two logarithm of the number of bytes to operate on.

  • data: UInt - Right-hand operand of the arithmetic operation

  • atomic: UInt - Arithmetic operation type (from TLAtomics)

Returns:

A (Bool, TLBundleA) tuple. The first item in the pair is a boolean indicating whether or not the operation is legal for this edge. The second is the A channel bundle.

9.3.4. Logical

Constructor for a TLBundleA encoding a Logical message, an atomic operation. The possible values for the atomic field are XOR, OR, AND, and SWAP, which correspond to atomic bitwise exclusive or, bitwise inclusive or, bitwise and, and swap operations, respectively. The previous value at the memory location will be returned in an AccessAckData response.

Arguments:

  • fromSource: UInt - Source ID for this transaction.

  • toAddress: UInt - The address to perform a logical operation on.

  • lgSize: UInt - Base two logarithm of the number of bytes to operate on.

  • data: UInt - Right-hand operand of the logical operation

  • atomic: UInt - Logical operation type (from TLAtomics)

Returns:

A (Bool, TLBundleA) tuple. The first item in the pair is a boolean indicating whether or not the operation is legal for this edge. The second is the A channel bundle.

9.3.5. Hint

Constructor for a TLBundleA encoding a Hint message, which is used to send prefetch hints to caches. The param argument determines what kind of hint it is. The possible values come from the TLHints object and are PREFETCH_READ and PREFETCH_WRITE. The first one tells caches to acquire data in a shared state. The second one tells cache to acquire data in an exclusive state. If the cache this message reaches is a last-level cache, there won’t be any difference. If the manager this message reaches is not a cache, it will simply be ignored. In any case, a HintAck message will be sent in response.

Arguments:

  • fromSource: UInt - Source ID for this transaction.

  • toAddress: UInt - The address to prefetch

  • lgSize: UInt - Base two logarithm of the number of bytes to prefetch

  • param: UInt - Hint type (from TLHints)

Returns:

A (Bool, TLBundleA) tuple. The first item in the pair is a boolean indicating whether or not the operation is legal for this edge. The second is the A channel bundle.

9.3.6. AccessAck

Constructor for a TLBundleD encoding an AccessAck or AccessAckData message. If the optional data field is supplied, it will be an AccessAckData. Otherwise, it will be an AccessAck.

Arguments

  • a: TLBundleA - The A channel message to acknowledge

  • data: UInt - (optional) The data to send back

Returns:

The TLBundleD for the D channel message.

9.3.7. HintAck

Constructor for a TLBundleD encoding a HintAck message.

Arguments

  • a: TLBundleA - The A channel message to acknowledge

Returns:

The TLBundleD for the D channel message.

9.3.8. first

This method take a decoupled channel (either the A channel or D channel) and determines whether the current beat is the first beat in the transaction.

Arguments:

  • x: DecoupledIO[TLChannel] - The decoupled channel to snoop on.

Returns:

A Boolean which is true if the current beat is the first, or false otherwise.

9.3.9. last

This method take a decoupled channel (either the A channel or D channel) and determines whether the current beat is the last in the transaction.

Arguments:

  • x: DecoupledIO[TLChannel] - The decoupled channel to snoop on.

Returns:

A Boolean which is true if the current beat is the last, or false otherwise.

9.3.10. done

Equivalent to x.fire() && last(x).

Arguments:

  • x: DecoupledIO[TLChannel] - The decoupled channel to snoop on.

Returns:

A Boolean which is true if the current beat is the last and a beat is sent on this cycle. False otherwise.

9.3.11. count

This method take a decoupled channel (either the A channel or D channel) and determines the count (starting from 0) of the current beat in the transaction.

Arguments:

  • x: DecoupledIO[TLChannel] - The decoupled channel to snoop on.

Returns:

A UInt indicating the count of the current beat.

9.3.12. numBeats

This method takes in a TileLink bundle and gives the number of beats expected for the transaction.

Arguments:

  • x: TLChannel - The TileLink bundle to get the number of beats from

Returns:

A UInt that is the number of beats in the current transaction.

9.3.13. numBeats1

Similar to numBeats except it gives the number of beats minus one. If this is what you need, you should use this instead of doing numBeats - 1.U, as this is more efficient.

Arguments:

  • x: TLChannel - The TileLink bundle to get the number of beats from

Returns:

A UInt that is the number of beats in the current transaction minus one.

9.3.14. hasData

Determines whether the TileLink message contains data or not. This is true if the message is a PutFull, PutPartial, Arithmetic, Logical, or AccessAckData.

Arguments:

  • x: TLChannel - The TileLink bundle to check

Returns:

A Boolean that is true if the current message has data and false otherwise.

Previous Next

© Copyright 2019, Berkeley Architecture Research. Revision b7644b24.

Built with Sphinx using a theme provided by Read the Docs.
Read the Docs v: stable
Versions
latest
stable
1.10.0
1.9.1
1.9.0
1.8.1
1.8.0
1.7.1
1.7.0
1.6.2
1.6.1
1.6.0
1.5.0
1.4.0
1.3.0
1.2.0
1.1.0
1.0.0
main
Downloads
On Read the Docs
Project Home
Builds