Commit 47b98c84 authored by Ille, Ondrej, Ing.'s avatar Ille, Ondrej, Ing.

doc: Improve readme.

parent 1a5f4c28
Pipeline #15613 canceled with stages
......@@ -35,7 +35,7 @@ GHDL, VHDL simulator with custom changes:
GTKWave, Waveform viewer:
[GTKWave](http://gtkwave.sourceforge.net/)
Vunit, VHDL unit test framework, with modifications allowing to start simulation interactively when simulation run starts:
Vunit, VHDL unit test framework, with modifications allowing to start GTKWave interactively when simulation run starts:
[Vunit](https://github.com/mjerabek/vunit).
Python 3 and following modules: pyvcd attrs jinja2 parsy pyyaml click yattag json2html
......@@ -50,16 +50,16 @@ CTU CAN FD verification is done in GHDL + VUnit + GTKWave combination. Verificat
on RTL (no gate level sims so far...).
There are following types of tests:
- Unit tests - Testbench for each module
- Feature tests - Common testbench for many test-cases
- Sanity test - One testbench, different configurations
- Reference test - One testbench, different file sets.
- Unit tests - Verify functionality of some modules stand-alone. Testbench for each module.
- Feature tests - Verify features of CTU CAN FD. Common testbench for many test-cases
- Sanity test - Real bus simulation (with delays, transceiver, noise). One testbench, different configurations.
- Reference test - Verify reception from reference CAN controller. One testbench, different file sets.
Test architecture is further described in:
TODO.
Each test/testbench has common header which is used to collect what has been verified (call it VRM if you want...):
TODO.
[![Verification items](https://img.shields.io/badge/Verification_Items--yellow.svg)](http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/VRM.html)
There is PSL functional coverage and PSL assertions available in:
[![functional coverage](https://img.shields.io/badge/functional%20coverage--orange.svg)](http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/functional_coverage/functional_coverage_report.html)
......@@ -96,13 +96,18 @@ There are three driver parts:
Driver has been tested on two boards:
- [![PCI board](https://img.shields.io/badge/PCI_board--blue.svg)](https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd)
- [![Xilinx Zynq board](https://img.shields.io/badge/Zynq_board--blue.svg)](https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top)
- [![Xilinx Zynq board](https://img.shields.io/badge/Zynq_board--blue.svg)](https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top) (Used for automated tests)
Operation up to 5 Mbits was tested (depending on physical layer transceiver type).
## Linux driver tests
This is weak part of the project at the moment. Linux driver was debugged and tested manually against Kvaser devices, CANoe and other CAN FD controllers. However, there are no written tests for the driver itself (apart from compiling it without error). In future QEMU + VPCIE + GHDL cosimulation is planned.
Linux driver was debugged and tested manually against Kvaser devices, CANoe and other CAN FD controllers. Regular communication
and handling of Error states were debugged manually. There is an automated emulator at CTU FEE pulling latest CTU CAN FD
RTL, synthesizing into Xilinx Zynq FPGA, running PetaLinux, loading SocketCAN driver and running CAN/CAN FD communication (500 Kbit/s Nominal bit rate, 4 Mbit Data bit rate) with randomly generated frames between CTU CAN FDs and FD tolerant SJA1000. Results can be found at:
[![FPGA Emulator tests](https://img.shields.io/badge/FPGA_Emulator_Tests--cyan.svg)](https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top/pipelines)
However, there are no written tests for the driver itself (apart from compiling it without error and passing Linux kernels checkpatch which is required for pipeline to pass). In future QEMU + VPCIE + GHDL cosimulation is planned.
## RTL release package
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment