Bedrock generated documentation: https://berkeleylab.github.io/Bedrock/
Bedrock is largely an accumulation of Verilog codebase written over the past several years at LBNL. It contains platform-independent Verilog, and whatever it takes to get it onto FPGA platforms like Xilinx etc.
It is currently a conglomerate of code broken into the following subdirectories:
- dsp: Various Digital Signal Processing algorithms implemented in platform-independent (portable) Verilog, and their test benches; modules include DDS, Down-conversion, Up-conversion, CIC Filters, Low-Pass filters, High-Pass filters, Mixers
- cordic: A self contained Verilog implementation of a CORDIC; includes several operating modes that can be selected at build-time or run-time
- rtsim: Real-Time simulation of various components of an RF system like a resonant cavity, its Electrical and Mechanical modes, ADCs, Cables, Piezos etc.
- cmoc: Verilog implementation of an RF controller, that connects to either a real world ADCs or simulated components within rtsim
- badger: A real-time Ethernet/IP/UDP packet responder core in fabric
- fpga_family: Several FPGA specific constraint files and hooks for vendor-specific features
- localbus: Documentation and features related to the on-chip localbus that is widely used within bedrock
- board_support: Several board specific pin mapping related files
- projects: Instantiated projects that build and synthesize bit files that go on FPGAs sitting on various boards that talk various platforms
A few comments regarding the codebase
- All software is set up to easily run on *nix systems.
- Currently everything is built using GNU Make. We are on an active lookout for other methods, if they're actually better for us.
- iverilog is used for simulation. We are slowly starting to use Verilator as well (see badger)
- Xilinx tools are used for synthesis, and starting to support YoSys (again see badger)
- This repository is connected to Gitlab CI. All simulation based tests run automatically upon every commit on the continuous integration server. This helps us move faster (without breaking things). A helpful subset of those tests can be run locally on your workstation via selftest.sh.
Bedrock is structured in such a way to make use of traditional *nix
tools, such as make
and grep
, shell and python scripts from the
command-line. This makes it easy to automate the build process, customize
steps, and gives flexibility to add hooks for generating code, stubs,
definitions and much more.
However, there are valid cases for using a graphical, interactive interface such as: analyzing elaborated, synthesized or implemented design schematic; adding/removing placement constraints; customizing a block design; customizing an IP core from a vendor.
Bedrock keeps all the vendor-specific generated files in a _<VENDOR_NAME>
directory in the synthesis directory. So, for instance, when synthesizing
a design for Xilinx
, Bedrock scripts will create a directory called
_xilinx
with the unmodified vendor files within.
In this way, after the vendor project file is created (see the build-tools discussion for details), one can simply invoke the vendor tool manually with the project file name as the argument.
For instance, if using Vivado, one can use the following command to open a project in Graphical mode:
vivado <PROJECT_DIRECTORY>/_xilinx/<TOP_LEVEL_DESIGN_NAME>/<TOP_LEVEL_DESIGN_NAME>.xpr
in which <PROJECT_DIRECTORY>
is the directory in which you invoked
make
and <TOP_LEVEL_DESIGN_NAME>
is the bitstream name without the
.bit
extension.
Required:
- GNU Make
- iverilog
- Python
Recommended:
- GTKWave
- Xilinx Vivado
- Verilator
- YoSys
Full list: see dependencies.txt and Dockerfile.
See our first take here
See LICENSE.