All Projects → chipsalliance → sv-tests

chipsalliance / sv-tests

Licence: ISC License
Test suite designed to check compliance with the SystemVerilog standard.

Programming Languages

SystemVerilog
227 projects
python
139335 projects - #7 most used programming language
javascript
184084 projects - #8 most used programming language
CSS
56736 projects
HTML
75241 projects
Makefile
30231 projects

Projects that are alternatives of or similar to sv-tests

sphinxcontrib-hdl-diagrams
Sphinx Extension which generates various types of diagrams from Verilog code.
Stars: ✭ 37 (-75%)
Mutual labels:  rtl, verilog, hdl, symbiflow
hdl-tools
Facilitates building open source tools for working with hardware description languages (HDLs)
Stars: ✭ 56 (-62.16%)
Mutual labels:  rtl, verilog, hdl
virtio
Virtio implementation in SystemVerilog
Stars: ✭ 38 (-74.32%)
Mutual labels:  rtl, verilog, hdl
SpinalCrypto
SpinalHDL - Cryptography libraries
Stars: ✭ 36 (-75.68%)
Mutual labels:  rtl, verilog
FPGA-USB-Device
FPGA-based USB-device controller to implement USB-CDC, USB-HID, etc.
Stars: ✭ 29 (-80.41%)
Mutual labels:  rtl, verilog
async fifo
A dual clock asynchronous FIFO written in verilog, tested with Icarus Verilog
Stars: ✭ 117 (-20.95%)
Mutual labels:  verilog, hdl
OpenROAD-flow-scripts
OpenROAD's scripts implementing an RTL-to-GDS Flow. Documentation at https://openroad-flow-scripts.readthedocs.io/en/latest/
Stars: ✭ 124 (-16.22%)
Mutual labels:  rtl, verilog
hwt
VHDL/Verilog/SystemC code generator, simulator API written in python/c++
Stars: ✭ 145 (-2.03%)
Mutual labels:  rtl, verilog
vboard
Virtual development board for HDL design
Stars: ✭ 32 (-78.38%)
Mutual labels:  verilog, hdl
ofdm
Chisel Things for OFDM
Stars: ✭ 23 (-84.46%)
Mutual labels:  rtl, verilog
cocotb-bus
Pre-packaged testbenching tools and reusable bus interfaces for cocotb
Stars: ✭ 20 (-86.49%)
Mutual labels:  verilog, hdl
symbolator
HDL symbol generator
Stars: ✭ 123 (-16.89%)
Mutual labels:  verilog, hdl
OpenLane
OpenLane is an automated RTL to GDSII flow based on several components including OpenROAD, Yosys, Magic, Netgen, Fault and custom methodology scripts for design exploration and optimization.
Stars: ✭ 548 (+270.27%)
Mutual labels:  rtl, verilog
PyChip-py-hcl
A Hardware Construct Language
Stars: ✭ 36 (-75.68%)
Mutual labels:  rtl, verilog
blarney
Haskell library for hardware description
Stars: ✭ 81 (-45.27%)
Mutual labels:  rtl, verilog
Hard-JPEG-LS
FPGA-based JPEG-LS image compressor.
Stars: ✭ 52 (-64.86%)
Mutual labels:  rtl, verilog
cnn open
A hardware implementation of CNN, written by Verilog and synthesized on FPGA
Stars: ✭ 157 (+6.08%)
Mutual labels:  rtl, verilog
gateware-ts
Hardware definition library and environment for designing and building digital hardware for FPGAs, using only open source tools
Stars: ✭ 83 (-43.92%)
Mutual labels:  verilog, hdl
cpu11
Revengineered ancient PDP-11 CPUs, originals and clones
Stars: ✭ 120 (-18.92%)
Mutual labels:  verilog, hdl
VGChips
Video Game custom chips reverse-engineered from silicon
Stars: ✭ 86 (-41.89%)
Mutual labels:  verilog, hdl

SystemVerilog Tester

License Build Status

The purpose of this project is to find all the supported and missing SystemVerilog features in various Verilog tools.

The report generated from the last passing master build can be viewed on a dedicated dashboard: Grid

History of the builds is also tracked and can be seen on a separate page: History

Running

Initialize the submodules:

git submodule update --init --recursive

Install all the python dependencies and make sure the installed binaries can be called.

pip3 install --user -r conf/requirements.txt
export PATH=~/.local/bin:$PATH

Build tools (optional, tools from PATH can be used):

make -k runners

And then just run:

make generate-tests -j$(nproc)
make -j$(nproc)

This should generate many log files for all the tools/tests combinations and an out/report.html file with a summary of the tested features and tools.

If you don't want to generate the report file, but are interested in just running all the tests, you can run:

make tests

Adding new test cases

Adding a new test case is a two step process. First you create the test case itself which should use only a minimal required subset of SystemVerilog to test a particular feature. Additionally each test should cover only a single feature. If the test must use several features, each of those must be also covered in separate test cases.

After creating a new test case it must be correctly tagged:

  • name - must be unique and should be directly related to what the test case covers.
  • description - should provide a short description that will be visible in the report page.
  • should_fail_because - must be used if the test is expected to fail and should contain the reason of failure.
  • files - is a list of files used by this test case, can be omitted to use only the main file with metadata.
  • incdirs - can be used to provide a list of include directories, can be omitted to use only the default ones.
  • top_module - optional, allows to specify which module is the top one.
  • tags - tag must be used to specify which part of SystemVerilog specification this test case covers.
  • defines - provides a list of macros for preprocessor. If the test case uses several SystemVerilog features, only the feature directly tested should be included in tags. List of existing tags is located in conf/lrm.conf.

Finally the file containing the test case and metadata should be placed in tests/chapter-([0-9]+)/ subdirectory based on the tags fields specified earlier.

Importing existing tests from a test suite/core/tool

  1. Add the tests as a submodule to this repository via git submodule add <git_url> third_party/<category>/<name>. If you want to add tests from a tool that is already in third_party/tools you can skip this step.

  2. Add a new tag named <name> to conf/lrm.conf together with a short description.

  3. Generate wrapper .sv files by either:

    • Adding a new config to conf/generators/meta-path/ that will be used by generators/path_generator.
    • Adding a new generator script to generators/ that will create required wrappers.

    First method works well with test suites in which each test case is contained in a separate Verilog file. If the test suite provides metadata that must be processed or you are importing an IP core then you should create custom generator script.

    Use tag that you added in the previous step.

Adding a new tool

  1. Make the tool available from Anaconda by either:

    If the tool is already available as a conda package you can skip this step.

  2. Add the conda package as a dependency in conf/environment.yml.

  3. Add the tool as a submodule to this repository via git submodule add <git_url> third_party/tools/<name>.

  4. Add a target for building and installing the tool manually in tools/runners.mk

  5. Create a new runner script in tools/runners/<name>.py that will contain a subclass of BaseRunner named <name>. This subclass will need to at least implement the following methods:

    • __init__ to provide general information about the tool.
    • prepare_run_cb to prepare correct tool invocation that will be used during tests.

    If the new tool is a Python library, reimplement run and other supporting methods instead of implementing prepare_run_cb.

Supported tools

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].