CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2020-10-31T22:14:25Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/389Datasheet clean-up vol. 22020-10-31T22:14:25ZIlle, Ondrej, Ing.Datasheet clean-up vol. 2Additionally, following things can be cleaned in Datasheet:
1. Rename LOM mode to BMM mode (in CAN standard it is bus monitoring mode)
2. Provide initialization/deinitialization sequence.
3. Add better description of filters (how to dis...Additionally, following things can be cleaned in Datasheet:
1. Rename LOM mode to BMM mode (in CAN standard it is bus monitoring mode)
2. Provide initialization/deinitialization sequence.
3. Add better description of filters (how to distuiguish betwen Base and Extended frames)
4. Add RTR suppression for frame filters.Test improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/388No synchronisation for transmitter during data bit-rate2020-10-29T20:15:41ZIlle, Ondrej, Ing.No synchronisation for transmitter during data bit-rateCurrently, transmitter does not synchronize during data bit rate
only if there is SSP. If SSP is not used during data bit rate by
transmitter, it still re-synchronizes, which is wrong!Currently, transmitter does not synchronize during data bit rate
only if there is SSP. If SSP is not used during data bit rate by
transmitter, it still re-synchronizes, which is wrong!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/386driver: updates based on v6 patches review2020-10-26T11:34:23ZPavel Pisadriver: updates based on v6 patches reviewhttps://lkml.org/lkml/2020/10/22/249https://lkml.org/lkml/2020/10/22/249https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/385specification: inconsisten names for timestamp in the frame buffer2020-10-28T16:40:04ZPavel Pisaspecification: inconsisten names for timestamp in the frame bufferTIMESTAMP_L_W has field TIME_STAMP_31_0
TIMESTAMP_U_W has field TIMESTAMP_L_W
Why? I was drenched in shame when I have read "This is crazy" in review referencing to automatically generated structures. Yes, it is possible to argue that ...TIMESTAMP_L_W has field TIME_STAMP_31_0
TIMESTAMP_U_W has field TIMESTAMP_L_W
Why? I was drenched in shame when I have read "This is crazy" in review referencing to automatically generated structures. Yes, it is possible to argue that the tool generates consistent constructs for all registers even that it has not significant meaning when it is full 32-single value one. But when you have no explanation for mismatch of names of the fields then it is a worse.
Please, consider what can be done with this. It can be marked as issue WontFix for 2.0 version, but should stay open and considered for some resolution.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/384Error counter reset after protocol exception2020-10-22T20:59:20ZIlle, Ondrej, Ing.Error counter reset after protocol exceptionWhen IUT detects protocol exception, it shall enter integration, but
it shall keep REC/TEC values unchanged.
Right now, upon leaving integration, error counters are reset. This needs
to be done only after device is started (when still i...When IUT detects protocol exception, it shall enter integration, but
it shall keep REC/TEC values unchanged.
Right now, upon leaving integration, error counters are reset. This needs
to be done only after device is started (when still in bus-off)ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/383doc: coorect QEMU doc/can.txt url.2020-10-21T23:31:54ZPavel Pisadoc: coorect QEMU doc/can.txt url.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/382Update readme to mention QEMU emulation and Intel DE0-Nano-SoC support2020-10-21T23:27:05ZPavel PisaUpdate readme to mention QEMU emulation and Intel DE0-Nano-SoC supporthttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/381dff entity name seems to conflict with Quartus Prime reserved primitve name2020-10-17T12:03:21ZPavel Pisadff entity name seems to conflict with Quartus Prime reserved primitve nameThe synthesis for PCIe board and Intel SoC run by Quartus reports next problem
Warning (12018): Entity "dff" will be ignored because it conflicts with Quartus Prime primitive name File: /home/pi/fpga/altera/db4cgx15/pcie-ctu_can_fd/mod
...The synthesis for PCIe board and Intel SoC run by Quartus reports next problem
Warning (12018): Entity "dff" will be ignored because it conflicts with Quartus Prime primitive name File: /home/pi/fpga/altera/db4cgx15/pcie-ctu_can_fd/mod
ules/ctu_can_fd/src/common/dff.vhd Line: 50
I am not sure by what kind of component/entity is instance replaced. May it be that it is totally harmless warning but I would vote for rename anyway.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/380PSL problems in TXT Buffer2020-10-27T20:05:31ZIlle, Ondrej, Ing.PSL problems in TXT BufferResolve problems with PSL expression in TXT Buffer FSM. Probably dont use
string concatenation within PSL report!Resolve problems with PSL expression in TXT Buffer FSM. Probably dont use
string concatenation within PSL report!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/379Classical CAN version2021-05-28T19:43:16ZIlle, Ondrej, Ing.Classical CAN versionWhen PEX = 0 and FD Enabled = 0 bits are configured, device shall be conformant to "Classical CAN" config.
This is not true at the momemnt. In this config, recessive FDF bit causes form error (instead in Classical
CAN Config, it shall be...When PEX = 0 and FD Enabled = 0 bits are configured, device shall be conformant to "Classical CAN" config.
This is not true at the momemnt. In this config, recessive FDF bit causes form error (instead in Classical
CAN Config, it shall be accepted as recessive, but frame shall be still considered as CAN 2.0 received frame!)
Also, other reserved bits shall be accepted even if they are recessive!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/378CRC Error in CAN FD Frames2020-10-06T18:24:14ZIlle, Ondrej, Ing.CRC Error in CAN FD FramesReceiver of CAN FD frame shall accept two recessive bits as ACK.
If receiver of CAN FD frame detect CRC error it shall signal it at first bit of EOF.
This means that during waiting it accepts CRC Delim + 2 ACK bits + ACK delim. Therefore...Receiver of CAN FD frame shall accept two recessive bits as ACK.
If receiver of CAN FD frame detect CRC error it shall signal it at first bit of EOF.
This means that during waiting it accepts CRC Delim + 2 ACK bits + ACK delim. Therefore
it shall start transmission of error frame 4 bits after the end of CRC field.
Currently CTU CAN FD start transmission of Error flag after 3 bits only!
This is bug and it shall be fixed.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/377Passive Error flag - possible bug2020-10-01T22:38:56ZIlle, Ondrej, Ing.Passive Error flag - possible bugISO 11898-1 2015 states:
Passive error flags initiated by receivers shall not be able to prevail over any activity on the bus.
Therefore, error-passive receivers shall always wait for 6 subsequent equal bits after detecting an error
con...ISO 11898-1 2015 states:
Passive error flags initiated by receivers shall not be able to prevail over any activity on the bus.
Therefore, error-passive receivers shall always wait for 6 subsequent equal bits after detecting an error
condition. The passive error flag is complete when these 6 equal bits have been detected.
This is currently not the case with CTU CAN FD. Error passive receivers who transmitt passive error flag
will simply go on, transmitt passive error flag and after passive error flag wait for recessive bit
(as also with Active Error flag). No counting of 6 consecutive bits of equal value is done! Also,
ISO compliance test which tests this (7.5.1) does not reveal this issue, because it super-imposes passive
error flag with active error flag. Therefore CTU CAN FD will finish passive error flag sooner than it has
detected 6 consecutive bits of equal polarity, but it will wait on recessive bit before proceeding with
error delimiter. So the incorrect behavior is not revealed by the test.
If we consider following:
Error passive CTU CAN FD detects error as receiver and transmitts passive error flag. No other nodes see
any error, so they continue transmitting. No bit error is detected by CTU CAN FD, since reception of dominant
bits during passive error flag does not cause bit error. CTU CAN FD finishes its passive error flag and
detects recessive bit in coincidence with some transmitted bit by other nodes. Therefore CTU CAN FD proceeds
to error delimiter! Other nodes are still in their regular frame transmission. During error delimiter, CTU
CAN FD will detect form error, because other nodes will transmit at least one dominant bit due to bit stuffing.
So CTU CAN FD will restart next passive error flag and have un-wanted increments of REC!
Note: Probably 7.5.5 will detect this issue!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/376TEC increment after ACK error in Error Passive state2020-10-07T16:43:40ZIlle, Ondrej, Ing.TEC increment after ACK error in Error Passive stateAccording to ISO 11898-1 2015 TEC shall be incremented if transmitter sends an error frame.
This has following exception:
If the transmitter is error-passive and detects an ACK error because of not detecting a dominant
ACK and does not...According to ISO 11898-1 2015 TEC shall be incremented if transmitter sends an error frame.
This has following exception:
If the transmitter is error-passive and detects an ACK error because of not detecting a dominant
ACK and does not detect a dominant bit while sending its passive error flag.
However, the current implementation is only looking at ACK error in passive error state! it does
NOT at all consider the second part of the exception. Test 8.6.18 is specifically designed to
detect this situation.
The behavior shall be following:
If there is dominant bit detected during passive error flag and it DUT detects dominant bit, it shall
not detect bit error nor increment error counter.
However, if ACK Error occured in Error Passive state and DUT starts transmitting passive error
flag due to this ACK error, then receiving dominant bit during consecutive passive error flag shall lead to
increment of TEC by 8!
So this is exception in TEC increment during passive error flag. Error frame probably still does
not have to be retransmitted, only TEC shall be incremented!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/375Vivado component build broken by reference to ctu_can_fd_rtl library intead o...2020-09-30T14:56:35ZPavel PisaVivado component build broken by reference to ctu_can_fd_rtl library intead of work automatic selfreference.The separation of libraries to ctu_can_fd_rtl and ctu_can_fd_tb
```
-Library work;
-use work.id_transfer.all;
...
+Library ctu_can_fd_rtl;
+use ctu_can_fd_rtl.id_transfer.all;
...
```
breaks Vivado build using based on CTU_CAN_FD_1_0 c...The separation of libraries to ctu_can_fd_rtl and ctu_can_fd_tb
```
-Library work;
-use work.id_transfer.all;
...
+Library ctu_can_fd_rtl;
+use ctu_can_fd_rtl.id_transfer.all;
...
```
breaks Vivado build using based on CTU_CAN_FD_1_0 component.
```
ERROR: [Synth 8-4169] error in use clause: package 'id_transfer' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/d52f/bus
_sampling/bit_err_detector.vhd:59]
ERROR: [Synth 8-4169] error in use clause: package 'can_constants' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/d52f/b
us_sampling/bit_err_detector.vhd:60]
ERROR: [Synth 8-4169] error in use clause: package 'can_components' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/d52f/
bus_sampling/bit_err_detector.vhd:61]
ERROR: [Synth 8-4169] error in use clause: package 'can_types' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/d52f/bus_s
ampling/bit_err_detector.vhd:62]
ERROR: [Synth 8-4169] error in use clause: package 'cmn_lib' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/d52f/bus_sam
pling/bit_err_detector.vhd:63]
ERROR: [Synth 8-4169] error in use clause: package 'drv_stat_pkg' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/d52f/bu
s_sampling/bit_err_detector.vhd:64]
ERROR: [Synth 8-4169] error in use clause: package 'reduce_lib' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/d52f/bus_
sampling/bit_err_detector.vhd:65]
ERROR: [Synth 8-4169] error in use clause: package 'can_fd_register_map' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/
d52f/bus_sampling/bit_err_detector.vhd:67]
ERROR: [Synth 8-4169] error in use clause: package 'can_fd_frame_format' not found in library 'ctu_can_fd_rtl' [/builds/canbus/zynq/zynq-can-sja1000-top/system/src/top/ipshared/
d52f/bus_sampling/bit_err_detector.vhd:68]
```
I am not sure about the best solution. Inside library, the reference to itself can still use work, because work is a keyword. Some more discussion on a Vivado discussion pages
https://forums.xilinx.com/t5/Design-Entry/VHDL-Package-in-Vivado/td-p/835945
Other Vivado library discussion
https://forums.xilinx.com/t5/Synthesis/Using-libraries-in-Vivado/td-p/816436
Quartus/Intel FPGA tools build accepts library reference to its actual name without any issue.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/374Testbench unification2021-04-23T20:59:39ZIlle, Ondrej, Ing.Testbench unificationAt the moment, there are several different testbenches for CTU CAN FD:
Unit tests - each own TB
Feature - One TB, many tests
Sanity - One TB, no tests
Reference - One TB, different tests based on data sets.
Compliance - One TB,...At the moment, there are several different testbenches for CTU CAN FD:
Unit tests - each own TB
Feature - One TB, many tests
Sanity - One TB, no tests
Reference - One TB, different tests based on data sets.
Compliance - One TB, different tests.
The aim of this task is to merge Feature, Reference and Compliance tests into
a single TB, this would be then the main TB of CTU CAN FD. Unit and Sanity tests
can be kept separate.Test improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/373Test framework cleanup2020-09-20T14:58:37ZIlle, Ondrej, Ing.Test framework cleanupAs most of the tests were re-written and RTL changed extensively, conversions of TCL
files to GHW files with TCL parser is not needed anymore. The aim of this task is to
remove it.As most of the tests were re-written and RTL changed extensively, conversions of TCL
files to GHW files with TCL parser is not needed anymore. The aim of this task is to
remove it.Test improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/372Reintegration - counter clear!2020-10-11T14:59:51ZIlle, Ondrej, Ing.Reintegration - counter clear!According to ISO spec, CAN FD enabled node shall restart integration/reintegration counter shall be restarted
when there is a synchronisation edge! At the moment, CTU CAN FD does not implement this feature. This shall
be implemented.According to ISO spec, CAN FD enabled node shall restart integration/reintegration counter shall be restarted
when there is a synchronisation edge! At the moment, CTU CAN FD does not implement this feature. This shall
be implemented.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/371Bus-off management2020-10-31T21:45:01ZIlle, Ondrej, Ing.Bus-off managementIt might be good to add option which will keep TXT Buffers in Ready state when node
goes to bus-off (instead of going to TX failed). This could be a configurable option
in MODE register.It might be good to add option which will keep TXT Buffers in Ready state when node
goes to bus-off (instead of going to TX failed). This could be a configurable option
in MODE register.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/370Split sources into two libs2020-09-15T15:41:21ZIlle, Ondrej, Ing.Split sources into two libsTest improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/369Source code decoupling2020-09-15T15:43:54ZIlle, Ondrej, Ing.Source code decouplingTo make design + TB more modular, following can be done:
1. [x] Split VHDL sources into TB and RTL libraries, avoid using implicit "work" library.
2. [ ] Provide VUnit replacement package, which would allow running TBs also without Vunit.To make design + TB more modular, following can be done:
1. [x] Split VHDL sources into TB and RTL libraries, avoid using implicit "work" library.
2. [ ] Provide VUnit replacement package, which would allow running TBs also without Vunit.Test improvements