CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2018-12-11T19:33:28Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/47Github mirror2018-12-11T19:33:28ZIlle, Ondrej, Ing.Github mirrorCreate a mirror repo and add it to GITHUBCreate a mirror repo and add it to GITHUBIlle, Ondrej, Ing.Ille, Ondrej, Ing.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/84Generate VHDL registers from IP-XACT2018-12-09T16:30:04ZIlle, Ondrej, Ing.Generate VHDL registers from IP-XACTIn actual state (8.2.2018) the VHDL package file is generated by pyXact, C header file is generated by pyXact and Lx documentation.
The aim of this task is to create an extension of pyXact and additionally generate VHDL structure which ...In actual state (8.2.2018) the VHDL package file is generated by pyXact, C header file is generated by pyXact and Lx documentation.
The aim of this task is to create an extension of pyXact and additionally generate VHDL structure which will include all registers
(maybe two structures, one for read, one for write direction). The process for memory access to these structures must be generated
and instantiated as a sub-module in the can-fd registers.
Such a module would on one side need a memory bus, on the other side, two register structures (one for written and second for read data).
Generated memory access processes would also generate reset values. It would use the same generated address and bitfield constants as it is using now!
The instance of this module would then connect to Driving bus, Status bus and other signals which are driven from/to the registers.
The actual question is how to deal with the side-effects which set the signals at the moment. These are following:
1. Interrupt_vector_erase -> This wont be a problem by that time since interrupt vector erase by read will be replaced.
2. Generic support such as "sup_filtB", I dont know any way how to set this dependency in IP-XACT.
3. RX_buff_read_first -> How should we read data from the RX FIFO then?? I assume this will be a problem, since we cant afford to create a
next register for moving to the next word by user write. This would create additional delay on the data read!
Logically the next step after this task would be to replace the Driving Bus and status bus in the whole design by these two structures and use attributes of these structures instead of local aliases. This would allow to drop the index documentation and it would simplify the design, since delection of an element from the registers would immediately reflect to missing element in the structure and thus
problem in compilation of any file which would need it!ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/109Extend pyxact generator with VHDL access generation2018-12-09T16:30:04ZIlle, Ondrej, Ing.Extend pyxact generator with VHDL access generationWishlisthttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/209Remove regmap gen files from project.2018-12-08T17:04:16ZIlle, Ondrej, Ing.Remove regmap gen files from project.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/195TX Buffer explicit memory2018-10-31T20:22:24ZIlle, Ondrej, Ing.TX Buffer explicit memoryAs RX Buffer FIFO contains explicit inferred RAM wrapper, it might be good to do it the same way in TXT Buffers,
to use one entity wrappers for all RAMs / BRAMs. This wrapper might in future be replaced by hard-core RAM IP.As RX Buffer FIFO contains explicit inferred RAM wrapper, it might be good to do it the same way in TXT Buffers,
to use one entity wrappers for all RAMs / BRAMs. This wrapper might in future be replaced by hard-core RAM IP.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/26Avalon master interface2018-10-30T17:50:26ZIlle, Ondrej, Ing.Avalon master interfaceAdd Avalon Master interface which will serve for DMA implementation on RX Buffers.Add Avalon Master interface which will serve for DMA implementation on RX Buffers.DMAhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/145Fault confinement test2018-10-29T22:12:25ZIlle, Ondrej, Ing.Fault confinement testImplement test which will emulate each point from Fault confiment
chapter of CAN FD specification and check that error counters
are increased, decreased properly!Implement test which will emulate each point from Fault confiment
chapter of CAN FD specification and check that error counters
are increased, decreased properly!ISO conformance testinghttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/146Error and overload frame test2018-10-29T22:10:58ZIlle, Ondrej, Ing.Error and overload frame testProtocol control unit test does NOT include testing of Error frame nor Overload frame test!
Create a test which would verify proper behaviour during error frame and during Overload frame!
Create additional test which will verify that a...Protocol control unit test does NOT include testing of Error frame nor Overload frame test!
Create a test which would verify proper behaviour during error frame and during Overload frame!
Create additional test which will verify that all types of errors are detected and verified
(e.g. CRC, ACK, FORM, STUFF, BIT)...ISO conformance testinghttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/193Release 2.1 cleanup2018-10-05T17:07:34ZIlle, Ondrej, Ing.Release 2.1 cleanupClean all the remaining troubles and do the Release...Clean all the remaining troubles and do the Release...https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/127Documentation clarification2018-10-04T18:57:06ZIlle, Ondrej, Ing.Documentation clarificationThe aim of this issue is to make sure all parts of documentation describe the behaviour of Core exactly.
Up to now there are following issues known within this topic:
13. Update DRV Bus and Status bus description!The aim of this issue is to make sure all parts of documentation describe the behaviour of Core exactly.
Up to now there are following issues known within this topic:
13. Update DRV Bus and Status bus description!https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/190Update licence header2018-09-28T15:22:43ZIlle, Ondrej, Ing.Update licence headerActual header is improper for Released version of the Core. It should contain both Martin Jerabek and Ondrej Ille as Core authors and Mr. Pisa and Mr. Novak as advisors. This should be easy to modify since there is a script exesting for ...Actual header is improper for Released version of the Core. It should contain both Martin Jerabek and Ondrej Ille as Core authors and Mr. Pisa and Mr. Novak as advisors. This should be easy to modify since there is a script exesting for this :)https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/135Rename some register fields to "look familiar" or be more descriptive2018-09-28T13:48:13ZMartin JeřábekRename some register fields to "look familiar" or be more descriptive1. In binary fields, avoid ambiguous names. For example: FRAME_TYPE (0 means FD or 1 means FD?) -> FRAME_FDTYPE (or, if we want to be less verbose - FDF).
2. A philosophic question - should the names be long and descriptive, or short?
3....1. In binary fields, avoid ambiguous names. For example: FRAME_TYPE (0 means FD or 1 means FD?) -> FRAME_FDTYPE (or, if we want to be less verbose - FDF).
2. A philosophic question - should the names be long and descriptive, or short?
3. In documentation, always mention the meaning of the shortcut (the full register name).
- STATUS (SR)
- RBS -> RXNE (RX Not Empty)
- TBS -> TXNF (TX Not Empty)
- DO(S) (Data Overrun Status)
- ET -> EF (Error Frame / Error Transmitted?)
- ES -> EW (Error Warning)
- BS -> IDLE/BI (Bus Idle)
- SETTINGS (CR?)
- INT_LOOP - looks like it concerns interrupts but doesn't (maybe just LOOP)
- INT (ISR,IESR,IECR,IMSR,IMCR):
- ~~RI -> FRI / RFI~~
- ~~TI -> FTI / TFI~~
- RFI -> RXFI (RX Full Interrupt)
- RBNEI -> RXNEI (RX Not Empty Interrupt)
- EWL
- EWL_LIMIT -> EW_LIMIT / EWL
- RX_STATUS
- RX_EMPTY -> RXE
- RX_FULL -> RXF
- TX_COMMAND
- TXIn -> TXBn ? What does the I stand for?
- FRAME_FORM_W
- ID_TYPE -> EFF/ID_EXTENDED (Extended Frame Format)
- FR_TYPE -> FDF/FR_FDhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/181RX Buffer RAM pipeline2018-09-27T23:15:05ZIlle, Ondrej, Ing.RX Buffer RAM pipelineReplace RX Buffer RAM output with clocked access to inferr BRAMs on Xilinx devices.Replace RX Buffer RAM output with clocked access to inferr BRAMs on Xilinx devices.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/143CI/CD: generate documentation and publish to Pages2018-09-25T22:21:28ZMartin JeřábekCI/CD: generate documentation and publish to PagesA nice-to-have when the core is public and final.A nice-to-have when the core is public and final.Continuous integrationMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/169Message filter feature test2018-09-21T17:28:07ZIlle, Ondrej, Ing.Message filter feature testAdd feature test which will verify usage of each message filter (A,B,C and Range). Simple
implementation with 4 * 2 frames (one passing, one failing frame for each filter) in single
iteration.
Thisway, code coverage for Memory registers...Add feature test which will verify usage of each message filter (A,B,C and Range). Simple
implementation with 4 * 2 frames (one passing, one failing frame for each filter) in single
iteration.
Thisway, code coverage for Memory registers will improve + new mechanism of ANDed RX Buffer
commands will be verified.Test maintenancehttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/174Form error detection in delim_ack2018-09-19T14:54:36ZIlle, Ondrej, Ing.Form error detection in delim_ackIt turned out that delim_ack state of Protocol Control is missing detection of Form Error on CRC Delimiter and ACK Delimiter! This
has to be performed in CRC Delimiter and acknowledge delimiter.It turned out that delim_ack state of Protocol Control is missing detection of Form Error on CRC Delimiter and ACK Delimiter! This
has to be performed in CRC Delimiter and acknowledge delimiter.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/176TXBHCI is triggered on wrong state transitions2018-09-18T17:40:11ZMartin JeřábekTXBHCI is triggered on wrong state transitionsScenario:
a) wrongly configured bitrate for can5 (can4 active)
* for 50x lower bitrate (500k vs 10k) it does happen
* for 2x higher bitrate (500k vs 1m) it does *not* happen
b) can5 is alone on the bus
-> send one frame
Observe...Scenario:
a) wrongly configured bitrate for can5 (can4 active)
* for 50x lower bitrate (500k vs 10k) it does happen
* for 2x higher bitrate (500k vs 1m) it does *not* happen
b) can5 is alone on the bus
-> send one frame
Observed:
```
[ 1472.532024] ctucanfd 43c70000.CTU_CAN_FD can5: ctucan_start_xmit: using TXB#0
[ 1472.544982] ctucanfd 43c70000.CTU_CAN_FD can5: TXBHCI
[ 1472.556189] ctucanfd 43c70000.CTU_CAN_FD can5: TXI: TXB#0: status 0x2
[ 1472.562603] ctucanfd 43c70000.CTU_CAN_FD can5: BUG: TXB not in a finished state!
[...]
[ 1472.637677] ctucanfd 43c70000.CTU_CAN_FD can5: TXBHCI
[ 1472.648884] ctucanfd 43c70000.CTU_CAN_FD can5: TXI: TXB#0: status 0x1
[ 1472.655298] ctucanfd 43c70000.CTU_CAN_FD can5: BUG: TXB not in a finished state!
[...]
[ 1472.668772] ctucanfd 43c70000.CTU_CAN_FD can5: ctucan_err_interrupt: ISR = 0x00000804
[ 1472.676588] ctucanfd 43c70000.CTU_CAN_FD can5: error_warning
[...]
[ 1472.719369] ctucanfd 43c70000.CTU_CAN_FD can5: ctucan_err_interrupt: ISR = 0x00000810
[ 1472.727184] ctucanfd 43c70000.CTU_CAN_FD can5: epi: state = 2
[ 1472.733082] ctucanfd 43c70000.CTU_CAN_FD can5: error_passive
```
In other words, TXBHCI is triggered when it shouldn't. It is independent of era/erw/erp state. Untested in bus-off state.
TODO:
- how is TXBHCI generated?
- what happens with TXB status when an error is detected?
- watch it by zlogan, look into RTLMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/128Bus off time2018-09-15T12:25:48ZIlle, Ondrej, Ing.Bus off timeAccording to CAN FD specification, each controller should wait at least 128 occurrences of 11 consecutive bits before transfer from BUS OFF to ERROR ACTIVE.
Actual implementation can force transition from BUS OFF to ERROR ACTIVE by eras...According to CAN FD specification, each controller should wait at least 128 occurrences of 11 consecutive bits before transfer from BUS OFF to ERROR ACTIVE.
Actual implementation can force transition from BUS OFF to ERROR ACTIVE by erasing error counters via CTR_PRES register.
This however does corrupt this rule and allows the controller to come back to life sooner than the spec allows it. This might be desirable for testing purposes, thus this approach won't be removed.
However, to be compliant with the standard, there must exist a way how to restart the controller (from BUS OFF to ERROR ACTIVE) while adhering to CAN Standard. Additional counter must be added to count occurences of 11 consecutive bits (could be separate counter or the one in "operationControl". From SW point of view two bits must be added. REQUEST bit to perform the BUS-OFF to ERROR ACTIVE, and STATUS bit to inform about the final transition upon completion of 128 * 11 condition.
Such a commands could be implemented in COMMAND register and status in FAULT_STATE register, since there are reserved bits available.Bug fixinghttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/170Unify "others" clause!2018-09-15T12:25:48ZIlle, Ondrej, Ing.Unify "others" clause!Search through Protocol control and operation control and make sure that in all cases
"others" on enumerated types is handled in the same way!Search through Protocol control and operation control and make sure that in all cases
"others" on enumerated types is handled in the same way!Bug fixinghttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/59Synthesis warning research2018-09-15T12:25:48ZIlle, Ondrej, Ing.Synthesis warning researchSearch through all the synthesis warnings and resolve them if possible.Search through all the synthesis warnings and resolve them if possible.Bug fixing