CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2020-12-12T20:53:53Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/394RX Buffer status extension2020-12-12T20:53:53ZIlle, Ondrej, Ing.RX Buffer status extensionImplement status bit which will be 1 when READ_DATA points to start of new frame in RX Buffer.
This allows to add recover if user gets lost in reading RX Buffer (without flushing the buffer).
1. [ ] Add feature in register map.
2. [ ] I...Implement status bit which will be 1 when READ_DATA points to start of new frame in RX Buffer.
This allows to add recover if user gets lost in reading RX Buffer (without flushing the buffer).
1. [ ] Add feature in register map.
2. [ ] Implement in RTL
3. [ ] Document
4. [ ] Write testISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/391Fix hard synchronization upon SOF start2020-11-21T16:52:24ZIlle, Ondrej, Ing.Fix hard synchronization upon SOF startIf dominant bit starts in bus idle after sample point of third bit of intermission
and DUT has pending transmission, DUT shall executed hard sync (because, from flow
of time on bus, it is still in third bit of intermission).
But DUT PC ...If dominant bit starts in bus idle after sample point of third bit of intermission
and DUT has pending transmission, DUT shall executed hard sync (because, from flow
of time on bus, it is still in third bit of intermission).
But DUT PC FSM is already in s_pc_sof. This means that it reacts to resynchronisation.
This can be fixed that hard sync will be valid also during SOF, but this approach must
be analyzed first.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/390Extend reintegration2020-11-05T20:02:20ZIlle, Ondrej, Ing.Extend reintegrationReintegration shall last at least 128*11 recessive bits.
If reintegration counter is configured only to 128, this condition is satisfied.
But in reality, if device oscillator is off, then it might actually calculate
128 * 11 consecutive...Reintegration shall last at least 128*11 recessive bits.
If reintegration counter is configured only to 128, this condition is satisfied.
But in reality, if device oscillator is off, then it might actually calculate
128 * 11 consecutive bits earlier than the tester (remember its all recessive bits,
so no resynchronization) and retransmitt earlier.
Good approach how to avoid this, is to demand 129 consecutive recessive repetitions
of 11 consecutive recessive bits.ISO optimizationshttps://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/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/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/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/360Fix TX/RX simultaneous trigger2020-07-09T13:46:25ZIlle, Ondrej, Ing.Fix TX/RX simultaneous triggerIf PH2 is shortened to 0, prescaler trigger_generator module shall delay consecutive TX trigger
by 1 clock cycle. This is not working properly, fix this.If PH2 is shortened to 0, prescaler trigger_generator module shall delay consecutive TX trigger
by 1 clock cycle. This is not working properly, fix this.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/359Prescaler bug-fixes2020-05-23T09:31:40ZIlle, Ondrej, Ing.Prescaler bug-fixesFollowing issues should be resolved in prescaler:
1. [x] When detecting negative phase error should there be a -1 in calculation?
2. [x] When detective negative resynchronisation with phase error <=Following issues should be resolved in prescaler:
1. [x] When detecting negative phase error should there be a -1 in calculation?
2. [x] When detective negative resynchronisation with phase error <=ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/357Non-synchronisation on dominant transmitted bit2020-05-06T19:40:16ZIlle, Ondrej, Ing.Non-synchronisation on dominant transmitted bitAn exception to re-synchronisation rule is not to perform resync with positive phase error
when node does transmitt dominant bit.
In current implementation, this exception is driven in protcol control fsm when
node is transmitter and it...An exception to re-synchronisation rule is not to perform resync with positive phase error
when node does transmitt dominant bit.
In current implementation, this exception is driven in protcol control fsm when
node is transmitter and it does transmit dominant bit.
This however does not cover all cases of dominant bit transmission! E.g. when node
transmitts an error frame it also does transmitt dominant bit (it does not even have
to be transmitter) and it should NOT perform positive resynchronisation!
This should be fixed although there is no test for this in compliance sequence
(if e.g. node is receiver).ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/355Fix REC decrement2020-04-17T19:39:42ZIlle, Ondrej, Ing.Fix REC decrementAccording to ISO11898-1:2015 REC shall be decremented by 1 upon succesfull reception of frame. This means up to succesfull transmission of ACK bit!
This point in CAN frame is different than Frame validation which is one bit before end of...According to ISO11898-1:2015 REC shall be decremented by 1 upon succesfull reception of frame. This means up to succesfull transmission of ACK bit!
This point in CAN frame is different than Frame validation which is one bit before end of EOF! This means that Frame can be
"succesfully received", REC decremented (after ACK) and e.g. form error occuring in first bit of EOF causing the frame not to
be validated (no valid reception will be signaled, no frame will be stored in RX Buffer)!
In CTU CAN FD, the moment of REC decrement is the same as the moment of frame validation and that is last bit of EOF.
7.6.7 of ISO16845-1 2016 is specifically designed to catch this issue as it expects first decrement of REC after ACK and then increment by 1 due to form error on ACK delimiter, thus leaving REC unchanged after the frame is over!
In current implementation of CTU CAN FD the point of decrement will never occur, and REC will only be incremented. This is a bug.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/354Fix Overload delimiter lenght2020-04-14T17:52:10ZIlle, Ondrej, Ing.Fix Overload delimiter lenghtOverload delimiter should have length of 8 bits, not 7!Overload delimiter should have length of 8 bits, not 7!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/353Split Err_Ovr_delim_too_long2020-10-31T21:16:26ZIlle, Ondrej, Ing.Split Err_Ovr_delim_too_longPC FSM state indicating Error / Overload delimiter is too long is common for both Error flag and Overload flag.
After this state, PC FSM goes to Error delimiter regardless of the fact whether this was Error or Overload flag!
In this sta...PC FSM state indicating Error / Overload delimiter is too long is common for both Error flag and Overload flag.
After this state, PC FSM goes to Error delimiter regardless of the fact whether this was Error or Overload flag!
In this state, even after too long Overload delimiter, device will signal that DUT is transmitting Error frame (which
is not true) in status registers.
Strictly speaking this does not mind, because behaviour of DUT with respect to standard is met (in both cases error counters
are incremented accordingly) -> TODO: What if device is not transmitter nor receiver in case of overload flag? Can this happen?
This should be resolved like so:
1. [ ] Create two PC fsm states for too long flag (Overload/Error)
2. [ ] Describe changes in PC FSM diagram in spec.
The behaviour of overload too long will be nearly the same as Error too long, with following differences:
1. Error will signal Error frame is transmitted, Overload will signal overload is transmitted.
2. After this states ends, Error too long will go to error delimiter, Overload will go to overload delimiter.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/321Fix active error overload flag signalling2019-10-09T19:57:52ZIlle, Ondrej, Ing.Fix active error overload flag signallingSignalling of active error flag, overload flag shall not be active in Passive Error flag!Signalling of active error flag, overload flag shall not be active in Passive Error flag!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/320Edge based EWL Interrupt2019-10-16T21:01:38ZIlle, Ondrej, Ing.Edge based EWL InterruptImplement EWL Interrupt to be edge based, not level-based.Implement EWL Interrupt to be edge based, not level-based.ISO optimizations