CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2021-02-18T18:15:12Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/404SSP at last bit - clarification2021-02-18T18:15:12ZIlle, Ondrej, Ing.SSP at last bit - clarificationIt should be clarified whether SSP which occurs just before SP
of CRC delimiter and detect bit error, shall also cause bit error!
ISO spec says that SSP shall be stopped at SP of CRC delimiter!
Therefore if SSP is configured so that it ...It should be clarified whether SSP which occurs just before SP
of CRC delimiter and detect bit error, shall also cause bit error!
ISO spec says that SSP shall be stopped at SP of CRC delimiter!
Therefore if SSP is configured so that it occurs just before SP
of CRC delimiter, it shall IMHO still detect bit error. This is
not the case at the moment. Bit error is detected, captured, but
ignored upon upcoming sample point in CTU CAN FD.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/293Retransmitt counter clear by Set abort2021-02-18T18:15:34ZIlle, Ondrej, Ing.Retransmitt counter clear by Set abortIf TXT Buffer is aborted and it is the buffer which is acutally used for transmission, or it was the last buffer which was used for transmission, retransmitt counter must be cleared, otherwise counter value stays hanging there for next f...If TXT Buffer is aborted and it is the buffer which is acutally used for transmission, or it was the last buffer which was used for transmission, retransmitt counter must be cleared, otherwise counter value stays hanging there for next frames!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/414Linux driver verification2021-05-17T12:30:31ZIlle, Ondrej, Ing.Linux driver verificationCurrently, there are no tests for Linux driver itself. Automated FPGA build
run in CTU synthesizes latest RTL and runs set of communication tests with SJA1000.
This is good basic sanity test that "communication works". This test will not...Currently, there are no tests for Linux driver itself. Automated FPGA build
run in CTU synthesizes latest RTL and runs set of communication tests with SJA1000.
This is good basic sanity test that "communication works". This test will not properly
test following conditions:
1. Error handling, REC/TEC readout towards proper value (there was a bug in driver where
REC/TEC readout was swapped).
2. Arbitration lost handling.
3. Fault-state changes (to active, passive and bus-off, reintegration and joining the bus
back-on).
This task deals with creating set of tests which will run as part of CI pipeline.
These tests shall verify the functionality of Linux driver and all its corner-cases.
Several approaches are possible:
1. Use Qemu + VPCIe framework and do co-simulation of GHDL + Qemu (virtual Linux + RTL simulation).
2. Use some framework for linux driver testing (e.g. SymDrive, Linux driver test...)Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/403CAN Clock2021-06-19T15:53:23ZIlle, Ondrej, Ing.CAN ClockSplit CAN FD IP Core into two clock domains:
1. CAN Clock
2. System Clock
This is needed to meet oscillator tolerance requirements of CAN Bus. If this is not done, then
also Memory bus needs to be clocked from oscillator which meets bit...Split CAN FD IP Core into two clock domains:
1. CAN Clock
2. System Clock
This is needed to meet oscillator tolerance requirements of CAN Bus. If this is not done, then
also Memory bus needs to be clocked from oscillator which meets bit timing requirements on CAN bus!
Typical MCU usage would however require two clock domains!
1. [ ] Update System architecture with decision how it will be done (list all signals crossing CDC, and their CDC handling protocol). Decide about best/worst case clock frequencies ratio!
2. [ ] Update User-guide to take "CAN clock" into account.
3. [ ] Implement the change in RTL.
4. [ ] Debug existing tests.
5. [ ] Create tests / regressions which verify minimal/maximal ratios of clock frequencies.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/435Edge filtering during bus integration2021-09-19T16:09:19ZIlle, Ondrej, Ing.Edge filtering during bus integrationISO11898-1 2015 defines an option to filter detected edges when node is in bus-idle state.
Currently, this is not implemented.ISO11898-1 2015 defines an option to filter detected edges when node is in bus-idle state.
Currently, this is not implemented.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/436Time-base generation by CTU CAN FD2021-09-25T09:49:50ZIlle, Ondrej, Ing.Time-base generation by CTU CAN FDCurrently, CTU CAN FD receives external time-base via Timestamp input.
ISO11898-1 2015 defines that a CAN implementation shall provide such time-base.
The goal of this issue is to implement such time-base as optional block which
could ...Currently, CTU CAN FD receives external time-base via Timestamp input.
ISO11898-1 2015 defines that a CAN implementation shall provide such time-base.
The goal of this issue is to implement such time-base as optional block which
could be included by top-level generic.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/158driver: support for retrieving RX frame timestamp2022-01-04T10:32:19ZMartin Jeřábekdriver: support for retrieving RX frame timestamp* [x] read to skbuf
* [ ] ~~configure support via ioctl~~
* [ ] configure where to sample: SOF/EOF (ioctl?)
* [ ] research drivers counters (time source?), how to pass the timestamp source via device tree
* will need defined bitwidth ...* [x] read to skbuf
* [ ] ~~configure support via ioctl~~
* [ ] configure where to sample: SOF/EOF (ioctl?)
* [ ] research drivers counters (time source?), how to pass the timestamp source via device tree
* will need defined bitwidth to correctly wrap around (few counters will implement full 64 bits)Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/407Adjust driver to read actual number of TXT buffers.2022-01-05T12:03:22ZIlle, Ondrej, Ing.Adjust driver to read actual number of TXT buffers.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/448Clean-up all Vivado synthesis warnings2022-07-18T20:34:42ZIlle, Ondrej, Ing.Clean-up all Vivado synthesis warningshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/416Formal verification of CTU CAN FD2022-11-07T22:51:39ZIlle, Ondrej, Ing.Formal verification of CTU CAN FDThe scope of this issue is following:
1. Build docker image with Symbyosis + GHDL plugin
2. Run formal verification of CTU CAN FD RTL.The scope of this issue is following:
1. Build docker image with Symbyosis + GHDL plugin
2. Run formal verification of CTU CAN FD RTL.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/464xilinx ise-14.7 reports of Gated clock - build is attempt to setup NuttX dri...2023-10-19T18:51:50ZPavel Pisaxilinx ise-14.7 reports of Gated clock - build is attempt to setup NuttX driver development on LX_CPU (LPC4088 + XC6SLX9)The Xst reports
```
WARNING:PhysDesignRules:372 - Gated clock. Clock net
can_fd_instances_for[0].can_fd_inst/bus_sampling_inst/bit_err_detector_inst/r
es_n_inv is sourced by a combinatorial pin. This is not good design practice.
...The Xst reports
```
WARNING:PhysDesignRules:372 - Gated clock. Clock net
can_fd_instances_for[0].can_fd_inst/bus_sampling_inst/bit_err_detector_inst/r
es_n_inv is sourced by a combinatorial pin. This is not good design practice.
Use the CE pin to control the loading of data into the flip-flop.
WARNING:PhysDesignRules:372 - Gated clock. Clock net
can_fd_instances_for[0].can_fd_inst/can_core_inst/fault_confinement_inst/faul
t_confinement_fsm_inst/fc_fsm_res_q_inv is sourced by a combinatorial pin.
This is not good design practice. Use the CE pin to control the loading of
data into the flip-flop.
```
More investigation of troubles found on this old tool-chain is ongoing.
Project build with minimal configuration successfully, frames are sent but acknowledge from other side is weak, works when XCAN is used but when another CTU CAN FD or CAN to USB converter are used then transmission fails. Reception is not successful too.
Setup has chance to easily test CTU CAN FD with NuttX and have environment for NuttX driver development because PiKRON's LX_CPU support is included in NuttX mainline.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/450Add integration guide document2023-12-17T20:35:13ZIlle, Ondrej, Ing.Add integration guide documentCurrently,
there are already two users who were confused about connection of `timestamp` input to all 0xFF
if there is no timestamp in their system. This information is present in System architecture
document, but it is not easy to fin...Currently,
there are already two users who were confused about connection of `timestamp` input to all 0xFF
if there is no timestamp in their system. This information is present in System architecture
document, but it is not easy to find.
It would be good to create separate "Integration" guide document.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/437Transmission delay2023-12-17T20:35:36ZIlle, Ondrej, Ing.Transmission delayCurrently, if there are TXT buffers in Ready state which are validated for transmission,
and previous transmission ends, next frame is transmitted immediately.
A nice-to-have feature would be adding an optional counter which would delay...Currently, if there are TXT buffers in Ready state which are validated for transmission,
and previous transmission ends, next frame is transmitted immediately.
A nice-to-have feature would be adding an optional counter which would delay
transmission of next frame by certain number of bit times (if needed).https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/421Power-down support2023-12-17T20:35:58ZIlle, Ondrej, Ing.Power-down supportCurrently, disabling CTU CAN FD can be done by writing SETTINGS[ENA] = 0.
If node is receiving, it can happen it will be cut-off in the middle of
CAN frame, or or maybe even in the middle of ACK bit.
It would be convenient to add some s...Currently, disabling CTU CAN FD can be done by writing SETTINGS[ENA] = 0.
If node is receiving, it can happen it will be cut-off in the middle of
CAN frame, or or maybe even in the middle of ACK bit.
It would be convenient to add some sort of power-down/disabling support.
The behavior shall be following:
1. User writes a bit to request power-down. CTU CAN FD captures this request.
2. CTU CAN FD waits for bus-idle and no transmissions ready. When it happens,
it indicates that it can be disabled (in status register). Also, it automatically,
pushes Protocol control logic to reset (as if SETTINGS[ENA] = 0).
3. User writes SETTINGS[ENA] = 0.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/387AHB test2023-12-17T20:38:17ZIlle, Ondrej, Ing.AHB testAt the moment there is missing test for AHB wrapper in CTU CAN FD. It would be good to add one (even if primitive one)At the moment there is missing test for AHB wrapper in CTU CAN FD. It would be good to add one (even if primitive one)Test improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/452Add NVC run scripts2023-12-17T20:43:17ZIlle, Ondrej, Ing.Add NVC run scriptsCurrently, NVC compiler is able to compile whole CTU CAN FD,
including TB.
VUnit does not support NVC, but NVC can be manually used by means
of hand-written makefile.
At the moment NVC does not support PSL assertions, so the whole
regr...Currently, NVC compiler is able to compile whole CTU CAN FD,
including TB.
VUnit does not support NVC, but NVC can be manually used by means
of hand-written makefile.
At the moment NVC does not support PSL assertions, so the whole
regression will not switch to NVC yet, but it might be good to
run at least small regression in NVC (feature tests only, since
compliance library is written with GHDL specific VPI).https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/466Test improvements2023-12-17T21:15:57ZIlle, Ondrej, Ing.Test improvementsCoverage analysis towards v2.5 has shown several places where additional tests would be good.
Several were written, others are pending.
Following test would be good to be written / extended:
1. [ ] Extend `retr_limit`, `retr_limit_2` an...Coverage analysis towards v2.5 has shown several places where additional tests would be good.
Several were written, others are pending.
Following test would be good to be written / extended:
1. [ ] Extend `retr_limit`, `retr_limit_2` and `retr_limit_3` to iterate over all available TXT Buffers.
2. [ ] Extend `tst_mem_acc_rx` to write the memory also via March pattern, not only random data pattern. This will give us full toggle coverage on all bits on RX Buffer even if 4096 width is tested.
3. [ ] Attempt to cover simultaneous events in RX Buffer in main TB. RX Buffer is intensively verified by its unit test. This unit test contains a model of RX Buffer, and hits these cases. RX Buffer unit test needs to be re-added to CI run (currently not there after porting to VCS flow) with GHDL. Despite having the concurent comit/read and abort/read covered by RX Buffer unit test, it would be good to cover these situations also in main TB, since code coverage is generated from main TB. Since VCS nor NVC can generate coverage from completely different designs (coverage is hierarchy based), it would be good to hit these cases also in main TB.
4. [ ] Check if GHDL already supports External names. If yes, then generalize the VCS hack for random data deposit in few tests.
5. [ ] Write test that covers "transient state" to Failed transition in case of Bus-off. Iterate over all TXT Buffers.
6. [ ] Write test that covers saturation of SSP delay condition.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/465Optimizations for better coverage2023-12-19T15:48:27ZIlle, Ondrej, Ing.Optimizations for better coverageThe coverage analysis executed with VCS during verification towards v2.5 revealed potential
design optimizations to reduce number of unreachable coverage bins in various blocks.
This is a tracking issue to work on these.
The main point...The coverage analysis executed with VCS during verification towards v2.5 revealed potential
design optimizations to reduce number of unreachable coverage bins in various blocks.
This is a tracking issue to work on these.
The main point is to optimize the code in a way where too generic design patterns cause
lot of unreachable code to be generated. This leads to requirement for tedious exclude files
if high coverage numbers are needed.
Following design patterns causing unreachable design were identified:
1. [ ] Reduce width of counters in Prescaler based on value they can count up-to the most.
This affects, segment counter, prescaler, extension, etc... See from v2.5 exclude file.
2. [ ] Split Protocol control FSM into two FSMs: Protocol control and Error transmission.
Error transmission FSM would handle Error Active/Passive Flag transmission, as well as
moving to "integration" state upon Error condition in ROM mode. A Protocol control FSM
would have a single state, that would indicate that the control over the transmission
is passed to Error transmission FSM. Once error transmission FSM would be over doing
its job, it would signal back to Protocol Control FSM. This would drastically reduce
number of available FSM transitions in FSM coverage.
3. [ ] Rework "Access signaller" in generated register map. Current approach is waaay to
generic. Split the access signaller to "Read" and "Write"
4. [ ] Rework Data MUX in the generated register map. Current approach, where all read data
are concatenated to one large vector and padded by zeroes, causes that there is way
too many toggles that are constant driven. It is very tedious to do the coverage analysis then.
Also, VCS with SX license does not provide the option to automatically exclude constant
driven items. So, it would be better to generate non-generic data mux module that would
have all register values brought in as ports, and the register selection would be done
inside of the generated data mux. Padding by zeroes then could be done in the process
that would mux the registers to "data_out" signal. This would get rid of many uncoverable
toggles.
5. [x] Rework the way that Protocol control FSM gives signals to TXT Buffers. Currently,
`txtb_hw_cmd` has `unlock` that is active together with either of `failed`, `error` or `arbl`.
Due to the design of next state decoder in protocol control FSM, and encoding of `txtb_hw_cmd`,
there are unreachable expressions and branches in the TXT Buffer FSM.
6. [ ] Split Odd and Even TXT Buffer implementation into a separate files. Even
TXT Buffers can never be Backup Buffers, and thus they can never be skipped during TXT Buffer
Backup mode operation. Thus there is lot of unreachable logic that needed to be waived.
7. [x] Make only MSB of init vector configurable via port in `crc_calc`.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/451Add loopback flag to frame in RX Buffer2023-12-19T15:50:21ZIlle, Ondrej, Ing.Add loopback flag to frame in RX BufferCurrently time of transmission can be added to TXT Buffer, but during high bus load
this does not mean that frame will be actually transmitted at this time.
In case of loop-back mode, it would be desirable to known when the frame was ac...Currently time of transmission can be added to TXT Buffer, but during high bus load
this does not mean that frame will be actually transmitted at this time.
In case of loop-back mode, it would be desirable to known when the frame was actually transmitted.
To distinguish loopback frames from regularly received frames, it would be good to add
"Loopback flag" per received frame in RX Buffer.