diff --git a/README.md b/README.md index a1623fea115b56367ec438e972d780b1baa931ae..6b3c9d784306d812356085071ea2dfccd3dd5f12 100644 --- a/README.md +++ b/README.md @@ -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,76 +17,95 @@ 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: +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) -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) -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). -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 +Python 3 and following modules: pyvcd attrs jinja2 parsy pyyaml click yattag json2html -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/) -All tests are automated into two runs: - - Fast - no randomization (seed=0), must pass before merge request is merged. - - Nightly - randomized, runs every night. +All tests are automated into two runs: +- 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: +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 -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) -There are three driver parts: - - network - - platform - - PCI +There are three driver parts: +- 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 diff --git a/src/can_core/protocol_control_fsm.vhd b/src/can_core/protocol_control_fsm.vhd index e5ea93491e0be7d8c02a8769cfb24f4b8461ad05..e1c9fc967edd0330f28c854b3c21c2010125b01c 100644 --- a/src/can_core/protocol_control_fsm.vhd +++ b/src/can_core/protocol_control_fsm.vhd @@ -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'; - - if (tx_data_wbs = DOMINANT and rx_data_nbs = RECESSIVE) then - bit_err_arb_i <= '1'; - end if; + 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; if (is_transmitter = '1' and tran_ident_type = BASE) then tx_dominant <= '1'; diff --git a/test/feature/overload_feature_tb.vhd b/test/feature/overload_feature_tb.vhd index 45a17c93ed2634982477a535d845f4669311b540..6e1a3bb9aa4ff443cdd3f0611083832bc82bc66d 100644 --- a/test/feature/overload_feature_tb.vhd +++ b/test/feature/overload_feature_tb.vhd @@ -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); diff --git a/test/tests_fast.yml b/test/tests_fast.yml index 7e0f98a8ae000915371d2a08fe6e508662136479..e485f3c2cc7c6a21e503bdc6524240c7a6f59d30 100644 --- a/test/tests_fast.yml +++ b/test/tests_fast.yml @@ -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 diff --git a/test/tests_nightly.yml b/test/tests_nightly.yml index 8850c49f3f610ba12e089be5f26458ddca273f26..eb41d869e2cbb557aa7b7035003a8a08b4d7a7c3 100644 --- a/test/tests_nightly.yml +++ b/test/tests_nightly.yml @@ -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