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. ...@@ -5,7 +5,8 @@ Supports ISO and NON-ISO versions of CAN FD protocol.
## License ## 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. CTU CAN FD linux driver is published under GPLv2 license.
...@@ -16,76 +17,95 @@ purposes has to obtain CAN protocol license from Bosch. ...@@ -16,76 +17,95 @@ purposes has to obtain CAN protocol license from Bosch.
## Design ## Design
CTU CAN FD RTL is written in VHDL with no vendor specific libraries/components required. 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: 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) [![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)
Functional description of CTU CAN FD is in datasheet: 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) [![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 To simulate CTU CAN FD following dependencies are needed:
CTU CAN FD verification is done in GHDL + VUnit + GTKWave combination. Verification is done
on RTL (no gate level sims so far...).
Custom GHDL with wave dumping speed-up is used: GHDL, VHDL simulator with custom changes:
[GHDL](https://github.com/Blebowski/ghdl). [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). [Vunit](https://github.com/mjerabek/vunit).
There are following types of tests: Python 3 and following modules: pyvcd attrs jinja2 parsy pyyaml click yattag json2html
Unit tests - own testbench for each module
Feature tests - common testbench
Sanity test - One testbench
Reference test - One testbench
Test architecture is further described in: TODO. For simulation environment, there is a docker image available at:
[Simulation docker](https://gitlab.com/canfd/server-tools/container_registry).
Each test/testbench has common header which is used to collect what has been verified: 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) ## Verification
For now GCov is used to collect code coverage in GHDL and its results are shown in: 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 - 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.
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)
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/) [![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: All tests are automated into two runs:
- Fast - no randomization (seed=0), must pass before merge request is merged. - Fast - no randomization (seed=0), must pass before merge request is merged.
- Nightly - randomized, runs every night. - Nightly - randomized, runs every night. Should be debugged before release.
Results of latest test run + logs are available under: 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) [![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. 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 ## Synthesis
CTU CAN FD has been synthesized into Xilinx and Intel FPGAs. BRAMs were inferred for 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 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 ## Linux driver
CTU CAN FD has SocketCAN Linux driver which is described in: 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) [![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: There are three driver parts:
- network - Network
- platform - Platform
- PCI - PCI
Driver has been tested on two boards: 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) - [![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)
Operation up to 5 Mbits was tested (depending on physical layer transceiver type). 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 ## RTL release package
CTU CAN FD RTL is postprocessed via script which removes PSL assertions and some signals intended 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:
only for verification purposes. RTL release package from latest sources is available in:
TODO TODO
...@@ -1606,7 +1606,6 @@ begin ...@@ -1606,7 +1606,6 @@ begin
------------------------------------------------------------------- -------------------------------------------------------------------
when s_pc_ide => when s_pc_ide =>
rx_store_ide_i <= '1'; rx_store_ide_i <= '1';
bit_err_disable <= '1';
crc_enable <= '1'; crc_enable <= '1';
txtb_ptr_d <= 1; txtb_ptr_d <= 1;
alc_id_field <= ALC_IDE; alc_id_field <= ALC_IDE;
...@@ -1631,13 +1630,14 @@ begin ...@@ -1631,13 +1630,14 @@ begin
if (ide_is_arbitration = '1') then if (ide_is_arbitration = '1') then
is_arbitration_i <= '1'; is_arbitration_i <= '1';
bit_err_disable <= '1';
if (tx_data_wbs = DOMINANT and rx_data_nbs = RECESSIVE) then
bit_err_arb_i <= '1';
end if;
else else
is_control <= '1'; is_control <= '1';
end if; end if;
if (tx_data_wbs = DOMINANT and rx_data_nbs = RECESSIVE) then
bit_err_arb_i <= '1';
end if;
if (is_transmitter = '1' and tran_ident_type = BASE) then if (is_transmitter = '1' and tran_ident_type = BASE) then
tx_dominant <= '1'; tx_dominant <= '1';
......
...@@ -207,9 +207,10 @@ package body overload_feature is ...@@ -207,9 +207,10 @@ package body overload_feature is
CAN_wait_sample_point(iout(1).stat_bus, false); CAN_wait_sample_point(iout(1).stat_bus, false);
end loop; end loop;
-- This is to make sure that we are in last bit of EOF for both nodes. -- This is to cover possibility that sample point of one bit before end
-- In case of tight timing, this can lead to Errors! -- of EOF in Node 2 did not pass yet! We want to be also in last bit
CAN_wait_sample_point(iout(2).stat_bus, false); -- 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! -- Now we should be in one bit before the end of EOF!
force_bus_level(DOMINANT, so.bl_force, so.bl_inject); force_bus_level(DOMINANT, so.bl_force, so.bl_inject);
......
...@@ -88,6 +88,7 @@ feature: ...@@ -88,6 +88,7 @@ feature:
retr_limit_2: retr_limit_2:
retr_limit_3: retr_limit_3:
one_shot: one_shot:
overload:
no_sof_tx: no_sof_tx:
rec_saturation: rec_saturation:
rx_settings_rtsop: rx_settings_rtsop:
...@@ -118,7 +119,6 @@ feature: ...@@ -118,7 +119,6 @@ feature:
tx_cmd_set_ready: tx_cmd_set_ready:
tx_priority: tx_priority:
iterations: 1 iterations: 1
overload:
reference: reference:
default: default:
<<: *default <<: *default
......
...@@ -78,6 +78,7 @@ feature: ...@@ -78,6 +78,7 @@ feature:
alc_ide: alc_ide:
alc_rtr_r0: alc_rtr_r0:
btr: btr:
timeout: 200 ms
iterations: 1 iterations: 1
btr_fd: btr_fd:
iterations: 3 iterations: 3
...@@ -120,6 +121,7 @@ feature: ...@@ -120,6 +121,7 @@ feature:
retr_limit_2: retr_limit_2:
retr_limit_3: retr_limit_3:
one_shot: one_shot:
overload:
no_sof_tx: no_sof_tx:
rec_saturation: rec_saturation:
rx_settings_rtsop: rx_settings_rtsop:
...@@ -152,7 +154,6 @@ feature: ...@@ -152,7 +154,6 @@ feature:
tx_cmd_set_ready: tx_cmd_set_ready:
tx_priority: tx_priority:
iterations: 5 iterations: 5
overload:
sanity: sanity:
default: default:
<<: *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