Commit b21533ed authored by Ille, Ondrej, Ing.'s avatar Ille, Ondrej, Ing.

Merge branch '205-ssp-offset-feature-test' into 'master'

Resolve "SSP offset feature test"

Closes #205

See merge request !313
parents 381d95c6 7f81dd28
Pipeline #14775 failed with stages
in 169 minutes and 51 seconds
......@@ -5,7 +5,8 @@ Supports ISO and NON-ISO versions of CAN FD protocol.
## License
CTU CAN FD is published under MIT license shown in: [![License](https://img.shields.io/badge/License--black.svg)]( https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/blob/master/LICENSE)
CTU CAN FD is published under MIT license shown in:
[![License](https://img.shields.io/badge/License--black.svg)]( https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/blob/master/LICENSE)
CTU CAN FD linux driver is published under GPLv2 license.
......@@ -16,7 +17,7 @@ purposes has to obtain CAN protocol license from Bosch.
## Design
CTU CAN FD RTL is written in VHDL with no vendor specific libraries/components required.
CTU CAN FD is fully synchronous design.
CTU CAN FD is fully synchronous design. CTU CAN FD is written with frequent usage of clock enables to allow inferred clock gating on ASIC.
Architecture of CTU CAN FD is described in:
[![System architecture](https://img.shields.io/badge/System_architecture--blue.svg)]( http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/ctu_can_fd_architecture.pdf)
......@@ -24,48 +25,64 @@ Architecture of CTU CAN FD is described in:
Functional description of CTU CAN FD is in datasheet:
[![Datasheet](https://img.shields.io/badge/Datasheet--blue.svg)]( http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/Progdokum.pdf)
CTU CAN FD is written with frequent usage of clock enables (FPGA) allowing inferred clock gating.
## Dependencies
## Verification
CTU CAN FD verification is done in GHDL + VUnit + GTKWave combination. Verification is done
on RTL (no gate level sims so far...).
To simulate CTU CAN FD following dependencies are needed:
Custom GHDL with wave dumping speed-up is used:
GHDL, VHDL simulator with custom changes:
[GHDL](https://github.com/Blebowski/ghdl).
Custom Vunit is used which allows starting GTKWave interactively when simulation run starts:
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](https://github.com/mjerabek/vunit).
Python 3 and following modules: pyvcd attrs jinja2 parsy pyyaml click yattag json2html
For simulation environment, there is a docker image available at:
[Simulation docker](https://gitlab.com/canfd/server-tools/container_registry).
## Verification
CTU CAN FD verification is done in GHDL + VUnit + GTKWave combination. Verification is done
on RTL (no gate level sims so far...).
There are following types of tests:
Unit tests - own testbench for each module
Feature tests - common testbench
Sanity test - One testbench
Reference test - One testbench
- 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.
Test architecture is further described in: TODO.
Test architecture is further described in:
TODO.
Each test/testbench has common header which is used to collect what has been verified: TODO.
Each test/testbench has common header which is used to collect what has been verified (call it VRM if you want...):
TODO.
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)
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)
For now GCov is used to collect code coverage in GHDL and its results are shown in:
[![coverage report](https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/badges/master/coverage.svg)](http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/coverage/)
All tests are automated into two runs:
- Fast - no randomization (seed=0), must pass before merge request is merged.
- Nightly - randomized, runs every night.
- Fast - no randomization (seed=0), must pass before merge request is merged.
- Nightly - randomized, runs every night. Should be debugged before release.
Results of latest test run + logs are available under:
[![pipeline status](https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/badges/master/pipeline.svg)](http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/tests_fast.xml)
At the moment, CTU CAN FD compliance towards ISO1198-1:2015 has not been proven.
It is intended for future to build testbench with test sequences described in ISO16845-1:2016.
## Synthesis
CTU CAN FD has been synthesized into Xilinx and Intel FPGAs. BRAMs were inferred for
TX and RX buffers. CTU CAN FD reached about 100 MHz of maximal frequency. Synthesis
results are shown in: TODO.
results are shown in:
TODO.
## Linux driver
......@@ -73,19 +90,22 @@ CTU CAN FD has SocketCAN Linux driver which is described in:
[![Linux driver](https://img.shields.io/badge/Linux_driver--blue.svg)](http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/driver_doc/ctucanfd-driver.html)
There are three driver parts:
- network
- platform
- PCI
- Network
- Platform
- PCI
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)
- [![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)
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.
## RTL release package
CTU CAN FD RTL is postprocessed via script which removes PSL assertions and some signals intended
only for verification purposes. RTL release package from latest sources is available in:
CTU CAN FD RTL is postprocessed via script which removes PSL assertions and some signals intended only for verification purposes. This is done to save simulation time in systems where CTU CAN FD is integrated (there are hundreds of PSL cover points and PSL assertions). RTL release package from latest sources is available in:
TODO
......@@ -1606,7 +1606,6 @@ begin
-------------------------------------------------------------------
when s_pc_ide =>
rx_store_ide_i <= '1';
bit_err_disable <= '1';
crc_enable <= '1';
txtb_ptr_d <= 1;
alc_id_field <= ALC_IDE;
......@@ -1631,13 +1630,14 @@ begin
if (ide_is_arbitration = '1') then
is_arbitration_i <= '1';
bit_err_disable <= '1';
else
is_control <= '1';
end if;
if (tx_data_wbs = DOMINANT and rx_data_nbs = RECESSIVE) then
bit_err_arb_i <= '1';
end if;
else
is_control <= '1';
end if;
if (is_transmitter = '1' and tran_ident_type = BASE) then
tx_dominant <= '1';
......
......@@ -207,9 +207,10 @@ package body overload_feature is
CAN_wait_sample_point(iout(1).stat_bus, false);
end loop;
-- This is to make sure that we are in last bit of EOF for both nodes.
-- In case of tight timing, this can lead to Errors!
CAN_wait_sample_point(iout(2).stat_bus, false);
-- This is to cover possibility that sample point of one bit before end
-- of EOF in Node 2 did not pass yet! We want to be also in last bit
-- of EOF of Node 2, because only then we get Overload frame!
wait for 400 ns;
-- Now we should be in one bit before the end of EOF!
force_bus_level(DOMINANT, so.bl_force, so.bl_inject);
......
......@@ -88,6 +88,7 @@ feature:
retr_limit_2:
retr_limit_3:
one_shot:
overload:
no_sof_tx:
rec_saturation:
rx_settings_rtsop:
......@@ -118,7 +119,6 @@ feature:
tx_cmd_set_ready:
tx_priority:
iterations: 1
overload:
reference:
default:
<<: *default
......
......@@ -78,6 +78,7 @@ feature:
alc_ide:
alc_rtr_r0:
btr:
timeout: 200 ms
iterations: 1
btr_fd:
iterations: 3
......@@ -120,6 +121,7 @@ feature:
retr_limit_2:
retr_limit_3:
one_shot:
overload:
no_sof_tx:
rec_saturation:
rx_settings_rtsop:
......@@ -152,7 +154,6 @@ feature:
tx_cmd_set_ready:
tx_priority:
iterations: 5
overload:
sanity:
default:
<<: *default
......
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