CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2019-10-09T19:42:19Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/318Remove CAN ID from can_top_level.2019-10-09T19:42:19ZIlle, Ondrej, Ing.Remove CAN ID from can_top_level.Remove CAN ID generic from CAN_top_level.vhdRemove CAN ID generic from CAN_top_level.vhdISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/316Stuff counter when SOF is not transmitted2019-10-07T18:40:07ZIlle, Ondrej, Ing.Stuff counter when SOF is not transmittedWhen CTU CAN FD joins transmission as a result of sampling Dominant bit in third bit of Intermission
or during Bus idle, it does not transmitt SOF, this is fine and according to standard.
But it does not account this (received) SOF in C...When CTU CAN FD joins transmission as a result of sampling Dominant bit in third bit of Intermission
or during Bus idle, it does not transmitt SOF, this is fine and according to standard.
But it does not account this (received) SOF in Counter of equal consecutive bits in Bit Stuffing module.
Therefore if CAN frame with first 5 bits of ID dominant is transmitted, transmitter which joined the
communication (without SOF), inserts Stuff bit after 5 bits of ID. Other transmitter which did transmitt
SOF, will insert Stuff bit after 4 bits of ID and therefore detect Stuff Error on 5th bit of ID.
This behaviour is OK according to standard and there is an exception that Stuff bit during arbitration
shall not increment error counters. Question is, should we implement some workaround on top of existing
standard @pisa ? @beranj25 ? @jnovak ?ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/315TX Arbitrator - extend arbitration2019-10-02T19:57:50ZIlle, Ondrej, Ing.TX Arbitrator - extend arbitrationA bug was revealed in current TXT Buffer validation mechanism. When node starts
transmitting frame as a result of sampling dominant in Bus idle or third bit of intermission,
there will be not enough time for TXT Buffer RAM to provide Ide...A bug was revealed in current TXT Buffer validation mechanism. When node starts
transmitting frame as a result of sampling dominant in Bus idle or third bit of intermission,
there will be not enough time for TXT Buffer RAM to provide Identifier word on its output,
since at the same cycle Protocol control is issuing "Lock" and also preloading TX shift
register with Base ID value. But at this time TX Arbitrator is still using its own pointer
(it is not locked yet), therefore data provided to protocol control (as Base ID) are in
reality Timestamp or Frame format words...
This bug was revealed on 28.9 during writing TC, for ALC register and it can manifestate
itself in very different scenarios...
(maybe this too: https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/issues/313)
I have a solution for this:
1. Extend TXT buffer validation process to load also Identifier word to capture register.
2. TX shift register will load ID from capture register, not from TXT Buffer RAM.
Together, TX arbitrator FSM will have 3 new states:
**Idle** - No frame is "Selected", this is to replace default "Load lower timestamp" state.
In this state, there will be no access to memory. This is a preparation for
gating access to RAMs only when data truly needs to be read (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/issues/302)
**Select ID** - Loading ID to capture registers.
**Validated** - After TXT Buffer was validated, TX Arbitrator will stay here until selected
TXT Buffer was changed or there is no buffer available anymore or Lock command arrives.
This is also a preparation for solution of previously mentioned issue.
Note that drawback of this is: 29 more DFFs. But we dont care since: https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/issues/261
will in the end save 128 - 16 = 112 DFFs!
1. [ ] Describe the changes in System architecture (TX Arbitrator FSM diagram, use-cases).
2. [ ] Implement changes in RTL.
3. [ ] Verify that changes did fix the problem by cherry-picking feature test for ALC which is
currently being written!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/306Synchronization edge by Time Quanta2019-12-02T19:30:08ZIlle, Ondrej, Ing.Synchronization edge by Time QuantaAdd gating which will detect synchronization edges only when Time Quanta is active!
Right now synchronisation edge is detected with System clock period, captured and processed
when Time Quanta Edge is active. This exposes potential vuler...Add gating which will detect synchronization edges only when Time Quanta is active!
Right now synchronisation edge is detected with System clock period, captured and processed
when Time Quanta Edge is active. This exposes potential vulerability when short sub-time-quanta
glitches will be applied that these will in the end cause resynchronisation!!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/305Set Abort + Retransmitt counter2019-10-05T10:25:45ZIlle, Ondrej, Ing.Set Abort + Retransmitt counterWhen TXT Buffer FSM moves to Aborted, and this buffer was used for last transmission, Retransmitt counter should
be cleared. This TODO is further explained in TX arbitrator section.When TXT Buffer FSM moves to Aborted, and this buffer was used for last transmission, Retransmitt counter should
be cleared. This TODO is further explained in TX arbitrator section.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/303Block BTR and BTR_FD during operation2019-12-06T16:41:31ZIlle, Ondrej, Ing.Block BTR and BTR_FD during operationCAN FD ISO standard says that bus timing parameters must be protected from being changed when CAN bus
communication is ongoing...
So far we can write to BTR and BTR_FD at any time. IP-xact generator can be extended by more "lock" signal...CAN FD ISO standard says that bus timing parameters must be protected from being changed when CAN bus
communication is ongoing...
So far we can write to BTR and BTR_FD at any time. IP-xact generator can be extended by more "lock" signals.
Right now single lock signal is used. Lock signal can be specified as value in Vendor Extensions of IP-XACT.
This-way write to BTR and BTR_FD will be gated by value of SETTTINGS[ENA]ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/302Extend TXT Buffer and RX Buffer RAMs2021-02-06T13:22:58ZIlle, Ondrej, Ing.Extend TXT Buffer and RX Buffer RAMsRight now, read is executed every clock cycle from these RAMs.
This is not desirable and "CE" or "RE" signal shall be added.
Thisway, RAM will load data only when CE is high and keep previous data on its output.
This needs to be added t...Right now, read is executed every clock cycle from these RAMs.
This is not desirable and "CE" or "RE" signal shall be added.
Thisway, RAM will load data only when CE is high and keep previous data on its output.
This needs to be added to TXT Buffer RAM and RX Buffer RAM. Inferred RAM wrapper must
be extended by these signals. CE signals shall be separate for each port.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/298TXT Buffer changed handling2019-10-09T19:57:56ZIlle, Ondrej, Ing.TXT Buffer changed handlingCurrent implementation of TXT Buffer changed detection in TX Arbitrator
detects TXT Buffer changed for whole duration of frame and thus prevents
modifying Retransmitt counter in the CAN frame directly after retransmitt
counter was cleare...Current implementation of TXT Buffer changed detection in TX Arbitrator
detects TXT Buffer changed for whole duration of frame and thus prevents
modifying Retransmitt counter in the CAN frame directly after retransmitt
counter was cleared by TXTB change detected.
Check this, verify behaviour, and correct!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/285Event Logger removal2019-08-04T12:00:18ZIlle, Ondrej, Ing.Event Logger removalHi,
in the last meeting we touched the topic of Event Logger removal.
Pros:
1) Still needs work on RTL
2) No support in driver. No standard interface in kernel.
3) Not verified on user level (only TB)
This creates an additional overhea...Hi,
in the last meeting we touched the topic of Event Logger removal.
Pros:
1) Still needs work on RTL
2) No support in driver. No standard interface in kernel.
3) Not verified on user level (only TB)
This creates an additional overhead which is not needed right now. If we ever decide
to go back, we can still check out the latest version in history of GIT and re-add it.
What do you think should we remove Event logger completely?
@jerabma7 @furavikt @pisa ??ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/278ISO compliant SSP config2019-08-04T11:53:39ZIlle, Ondrej, Ing.ISO compliant SSP configAccording to ISO can fd spec. SSP offset should be configured from beginning of bit time in user interface. Right now it is configured from Sample point.
1. [x] Change description in IPxact.
2. [ ] Subtract tseg1 duration from ssp offse...According to ISO can fd spec. SSP offset should be configured from beginning of bit time in user interface. Right now it is configured from Sample point.
1. [x] Change description in IPxact.
2. [ ] Subtract tseg1 duration from ssp offset in reg.map. This can be done in ssp module inside of bus_sampling.
3. [x] Add DBT time Quanta edge to bus sampling forcing ssp shift reg to shift only when aligned to time quanta. Thisway the value in ssp offset will change from clock cycles to time quanta.
4. [x] Describe a section in the docs on how to configure SSP. Preferably with some diagrams.
After this issue is resolved, viktor may implement ssp_cfg test. Note that adding ssp support to driver is not blocked by this issue since ssp_offset field will not change. Only its meaning will change...ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/272Sampling and Bit Error detection modularization2019-02-28T17:28:09ZIlle, Ondrej, Ing.Sampling and Bit Error detection modularizationRe-write the ugly long case statements for bit error detection and bus sampling
into a separate sub-modules. For bus sampling add generic on pipeline insertion
and set this to true. This should be preparation for removal of this pipeline...Re-write the ugly long case statements for bit error detection and bus sampling
into a separate sub-modules. For bus sampling add generic on pipeline insertion
and set this to true. This should be preparation for removal of this pipeline
stage to have only two sample triggers!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/266Event Logger: Add message filter results2019-03-14T18:00:53ZIlle, Ondrej, Ing.Event Logger: Add message filter resultsAdd Message filter results as Event Logger Trigger and Event Logger Events.Add Message filter results as Event Logger Trigger and Event Logger Events.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/265Create DLC decoder entity2019-02-26T17:56:41ZIlle, Ondrej, Ing.Create DLC decoder entityAdd entity which will decode input DLC to number of bytes in CAN Frame.
Inputs:
1. DLC (3 .. 0 vector)
2. Frame Type: CAN 2.0 Frame or CAN FD Frame (std_logic). Use NORMAL_CAN, FD_CAN constants to distinguish.
Outputs:
1. Number of byte...Add entity which will decode input DLC to number of bytes in CAN Frame.
Inputs:
1. DLC (3 .. 0 vector)
2. Frame Type: CAN 2.0 Frame or CAN FD Frame (std_logic). Use NORMAL_CAN, FD_CAN constants to distinguish.
Outputs:
1. Number of bytes in a frame(5 .. 0 vector)
2. DLC Valid output.
The behaviour of entity is like so:
1. For CAN Frames decode DLC (0000,0001,...,0111) as expected.
2. For CAN Frames decode DLCS 1*** as 8.
3. For CAN Frames DLCs which are higher than 1000 will have DLC valid output set to '0' to indicate that this is
invalid DLC combination.
4. For CAN FD Frame decode all DLCs as defined in CAN FD spec.
Entity name:
sth like: can_dlc_to_bc_decoder
Architecture naming: please use RTL.ISO optimizationsIng. Viktor FúraIng. Viktor Fúrahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/261Re-work SSP shift register to a counter2019-12-01T23:09:26ZIlle, Ondrej, Ing.Re-work SSP shift register to a counterModify SSP shift register to counter.
This will work like so:
1. Counter starts upon first entrance of Data Sample point to original SSP shift register.
(First entrance after switching to Secondary Sampling)
2. When counter elapses, t...Modify SSP shift register to counter.
This will work like so:
1. Counter starts upon first entrance of Data Sample point to original SSP shift register.
(First entrance after switching to Secondary Sampling)
2. When counter elapses, this creates first "secondary sample".
3. Each next sample is then delayed by amount of "Bit time" since the distance between two
Secondary Sample Points is equal to length of Bit time.
The question is how to determine length of Bit time... Adding all the bit time segments
and multiplying by Time Quanta is not very efficient.
It could be done like so:
1. Between r0 and BRS bits there will be another measurement (could be on the same counter!)
which will measure length between two sample points. This will be stored in separate
register and used as delay value. This is OK, since there is definitely no re-synchronisation
between r0 and BRS.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/260Add Secondary sampling point to Status Bus2019-02-08T17:24:42ZIlle, Ondrej, Ing.Add Secondary sampling point to Status BusTo test SSP offset in feature test, it is beneficial to add secondary sampling point to
Status Bus. If Both: Data Sample and Secondary Sampling point are in Status Bus (which is
accessible from feature test), then SSP_CFG can be tested l...To test SSP offset in feature test, it is beneficial to add secondary sampling point to
Status Bus. If Both: Data Sample and Secondary Sampling point are in Status Bus (which is
accessible from feature test), then SSP_CFG can be tested like so:
Feature test has TRV_DELAY of 22 (hardcoded in Feature testbench).
1. Configure SSP Offset, and SSP source. This will give overral delay between Data and Secondary sample.
2. Wait till Data sample (on Status Bus).
3. Wait till Secondary sample and measure that number of clock cycles in between corresponds to
Expected delay.
Examine all three options:
1. TRV_DELAY only (equal to 22 in feature test)
2. TRV_DELAY + SSP_OFFSET
3. SSP_OFFSET only.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/259CAN address dependency2019-03-18T21:19:13ZIlle, Ondrej, Ing.CAN address dependencyRemove Address depenency of 0x3 in CTU CAN FD Address map.
1. [x] Remove from Memory Registers implementation
2. [x] Remove from CAN Test lib.
3. [x] Remove from documentation.
4. [x] Remove from Driver
5. [x] Wait for Martin Jerabek to...Remove Address depenency of 0x3 in CTU CAN FD Address map.
1. [x] Remove from Memory Registers implementation
2. [x] Remove from CAN Test lib.
3. [x] Remove from documentation.
4. [x] Remove from Driver
5. [x] Wait for Martin Jerabek to remove the upper address bits from Vivado components.
This should not be a blocker, if the address stays in the component, it the accesses
will be executed anyway since those address bits will be "Don't care".
The behaviour in these bits should be "Don't care".ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/257Retransmission counter clear2019-03-14T18:28:08ZIlle, Ondrej, Ing.Retransmission counter clearThis task should add the possibility to distinguish between retransmit counter clear
by error frame / arbitration.
Right now, retransmitt options are:
RTRLE - Retransmit limit enable (0-1)
RTRTH - Retransmit threshold (0-15).
With th...This task should add the possibility to distinguish between retransmit counter clear
by error frame / arbitration.
Right now, retransmitt options are:
RTRLE - Retransmit limit enable (0-1)
RTRTH - Retransmit threshold (0-15).
With these options, we can configure the device to following behavior:
1. RTRLE = 0. Retransmit limit disabled. Device attempts to retransmit forever.
2. RTRLE = 1, RTRTH > 0. Retransmit limit enabled. The device will retransmit only RTRTH times.
This means that if RTRTH = 2, the device will attempt 3 transmissions (regular + 2 retransmissions).
3. RTRLE = 1, RTRTH = 0. Retransmitt limit enabled, but 0 retransmissions are allowed. This
is the so-called "Single shot mode".
Right now each retransmission is treated as equal (either due to arbitration loss or error frame)
The aim of this task is to add configuration bit (preferably to SETTINGS register) which will
differentiate this behavior for retransmissions due to arbitration lost or error frame.
Two behavior can be like so:
1. Both are treated equal (as till now).
2. When arbitration is lost, this is not considered as "retransmission". Thus transmissions of the
same frame due to arbitration loss will be infinite.
I leave it up to the implementer how to name this bit however, I would like to have the default
behavior (reset value) the same as now (all retransmissions treated equally).ISO optimizationsIng. Viktor FúraIng. Viktor Fúrahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/245FIFO watermark2019-03-14T18:42:24ZIlle, Ondrej, Ing.FIFO watermarkAdd FIFO watermark functionality.
Functionality shall be sth like this:
- FIFO Watermark level configurable
When FIFO word count is above the watermark, watermark status is asserted. If it drops below, it is de-asserted.
Interrupt from...Add FIFO watermark functionality.
Functionality shall be sth like this:
- FIFO Watermark level configurable
When FIFO word count is above the watermark, watermark status is asserted. If it drops below, it is de-asserted.
Interrupt from Watermark shall be derived. We shall think if this should be level-based, or interrupt is
captured only when water-mark is reached.
This might be a handy feature for future DMA implementation.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/244Split MODE, SETTINGS, COMMAND, STATUS register2019-02-04T19:15:53ZIlle, Ondrej, Ing.Split MODE, SETTINGS, COMMAND, STATUS registerThe aim of this task is to split MODE, SETTINGS, COMMAND, STATUS INTO at least two (possibly 3) registers.
I propose:
1. MODE + SETTINGS
2. STATUS
3. COMMAND
I know that having it 32bit would be better, however, this has one small flaw...The aim of this task is to split MODE, SETTINGS, COMMAND, STATUS INTO at least two (possibly 3) registers.
I propose:
1. MODE + SETTINGS
2. STATUS
3. COMMAND
I know that having it 32bit would be better, however, this has one small flaw. Register map generator
can't split the initial table (page 50) for a region into several pages! So if we have too many memory words in one
region, the documentation will get messy... It will overflow the page and won't be split automatically.
If we want to add more registers, splitting page should be added to register map generator.
Part of this issue should be also fixing all the relevant accesses in HW and DRIVER. Since most of accesses are 32-bit
there will be some issues when e.g. CMD register is accessed over address of MODE register etc.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/241Align TIMESTAMP to 64 bit Address2019-01-10T19:02:58ZIlle, Ondrej, Ing.Align TIMESTAMP to 64 bit AddressMove TIMESTAMP_HIGH and TIMESTAMP_LOW registers to be aligned to 64 bit address.Move TIMESTAMP_HIGH and TIMESTAMP_LOW registers to be aligned to 64 bit address.ISO optimizations