CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2019-02-02T14:08:41Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/248tests: output does not respect verbosity settings2019-02-02T14:08:41ZMartin Jeřábektests: output does not respect verbosity settingsAfter switching to VUnit log lib, messages with all error levels are printed. In turn, the files with results are too huge and cannot be deployed to gitlab pages.
In the old vunit-enhancements branch it was solved by calling:
* show_all...After switching to VUnit log lib, messages with all error levels are printed. In turn, the files with results are too huge and cannot be deployed to gitlab pages.
In the old vunit-enhancements branch it was solved by calling:
* show_all(logger, display_handler);
* hide(logger, display_handler, debug); ...
I will look into it.Martin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/239Regmap gen saturation fix.2019-01-08T20:13:20ZIlle, Ondrej, Ing.Regmap gen saturation fix.Add fix for register map generator which will return all zeroes on read_data when adress in data_mux is saturated.Add fix for register map generator which will return all zeroes on read_data when adress in data_mux is saturated.ISO optimizationsIlle, Ondrej, Ing.Ille, Ondrej, Ing.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/223driver: disabling DOI during RX handling in NAPI: to do or not to do2019-03-07T14:31:48ZMartin Jeřábekdriver: disabling DOI during RX handling in NAPI: to do or not to doAs I'm describing this particular bit of implementation in the thesis, I intended to write *why* this behavior (i.e. disabling DOI for RX handling) is necessary, but realized I can not justify it enough.
Originally it was introduced bec...As I'm describing this particular bit of implementation in the thesis, I intended to write *why* this behavior (i.e. disabling DOI for RX handling) is necessary, but realized I can not justify it enough.
Originally it was introduced because I thought it's the cause of #183, but that proved to be false (I just needed to clear DOR flag too). The argument that it is better to be reading the data than to handle DOI sounds weak to me - we're not on a slow high realtime cpu. Moreover, about the only place where the overrun could occur is between the RXBNEI and reading all the frames, and we would really want to be informed about the overrun. Plus some other process might take over the NAPI process, or the SW RX queue might become full, in which case the NAPI stays queued, but stopped.
It is now clear that the current approach is wrong. An alternative is to disable/reenable DOI in the polling routine. That does not sound too bad. The DOR flag would be checked after reading all the available frames, so that performance shouldn't be significantly hurt (one extra bus access).
There might be, however, a situation, when continuous data are streamed on CAN and DOR is used by the protocol to detect that a frame will be missing. Due to HW queuing, it can only be used to mean that "somewhere in the near future", a frame (or more) went missing, not "exactly after this frame" some went missing. IMHO this is an useless problem, as nobody sane would be leveraging this mechanism
On second reading, the "after reading all the frames, check for overrun" part sounds a bit ridiculous. It still might make sense when max work quota is reached, but would still be problematic if the thread is preempted (for a non-short time). That might not happen with current NAPI implementation, but who knows ...
**So in conclusion**: remove the special handling and keep it just in ISR, then test that it really works (it should)Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/222driver: rx: skb alloc vs metadata fetch from fifo2019-03-07T14:31:46ZMartin Jeřábekdriver: rx: skb alloc vs metadata fetch from fifoIf the allocation fails, store the read word into driver's data. On next try, use the stored word instead of reading it again. Do not discard the partial frame.
This is a better solution to implementing RX FIFO peek register in HW, sugg...If the allocation fails, store the read word into driver's data. On next try, use the stored word instead of reading it again. Do not discard the partial frame.
This is a better solution to implementing RX FIFO peek register in HW, suggested by Mr. Pisa. I thought that we had an issue for the PEEK register, but I didn't find it.
To be implemented after the PCI driver is merged, which will probably be after I finish writing the thesis.Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/219Create wave file for registers2019-01-06T16:02:56ZIlle, Ondrej, Ing.Create wave file for registersAdd new wave file with all register values as they are implemented after automatic generation of register map.Add new wave file with all register values as they are implemented after automatic generation of register map.Test improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/208add registers for reading current timestamp2019-01-02T15:24:10ZMartin Jeřábekadd registers for reading current timestampStrictly speaking the timestamp is from external source, which should provide CPU access to the value itself (either read-only or dead-write). However, the engineers at Xilinx apparently reasoned similarly when designing Xilinx CAN and t...Strictly speaking the timestamp is from external source, which should provide CPU access to the value itself (either read-only or dead-write). However, the engineers at Xilinx apparently reasoned similarly when designing Xilinx CAN and the counter value is inaccessible there - at all. So it would be nice to have read-only access to it via the CAN core in case the integrator forgets to make it accessible from the counter directly again. As a bonus, it will be simpler to handle the timestamps in Linux driver, because it will not have to depend on an external timer.
Will be useful for #158.ISO optimizationsIlle, Ondrej, Ing.Ille, Ondrej, Ing.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/204SSP offset2019-01-06T10:30:16ZIlle, Ondrej, Ing.SSP offsetImplement additional SW offset to Measured secondary sampling point.
Measured SSP OFFSET (trv_delay), can be still read from TRV_DELAY.
Higher bits of trv_delay register can be used for offset and offset control.
Following options for S...Implement additional SW offset to Measured secondary sampling point.
Measured SSP OFFSET (trv_delay), can be still read from TRV_DELAY.
Higher bits of trv_delay register can be used for offset and offset control.
Following options for SSP offset:
1. Use only measured value
2. Use only SW offset.
3. Use measured value + SW offset.
Addition of trv_delay and SW SSP offset will be realized inside Bus Sampling
module, since shift registers for secondary sampling are implemented there.ISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/200Bring-up GHDL functional coverage.2019-02-02T11:15:18ZIlle, Ondrej, Ing.Bring-up GHDL functional coverage.The aim of this task is to bring up functional coverage with GHDL.
Main topics are:
1. [x] Write simple PSL cover statement into some of RTL codes.
2. [x] Execute test which activates this point.
3. [x] Show that PSL point was activated ...The aim of this task is to bring up functional coverage with GHDL.
Main topics are:
1. [x] Write simple PSL cover statement into some of RTL codes.
2. [x] Execute test which activates this point.
3. [x] Show that PSL point was activated in a coverage output.
4. [x] Add PSL coverage gatherhing settings to config file
5. [x] Create PSL statement directly to directory with functional coverage without copyingFunctional coveragehttps://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/188swap set/reset priority for DOI2019-01-02T16:21:31ZMartin Jeřábekswap set/reset priority for DOIContinuation of #187.
APB is access OK, but the problem would still occur on AXI/Avalon (or whichever bus which has one-cycle transactions). As a solution it would be enough to swap set/reset priority for DOI. The SW/HW race condition w...Continuation of #187.
APB is access OK, but the problem would still occur on AXI/Avalon (or whichever bus which has one-cycle transactions). As a solution it would be enough to swap set/reset priority for DOI. The SW/HW race condition which it would introduce is still here, so nothing is lost.
Tasks:
- [x] change implementation
- [x] modify tests
- [x] modify documentationISO optimizationshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/187Examine consecutive write data overrun and clear interrupt2018-09-11T14:51:27ZIlle, Ondrej, Ing.Examine consecutive write data overrun and clear interruptUpon overrun on RX Buffer, clear overrun flag is set. It is possible that if two consecutive memory
accesses to CMD[CDO] and INT_STAT (write to clear interrupt by overrun), this interrupt won't be cleared, since
overrun is cleared two cl...Upon overrun on RX Buffer, clear overrun flag is set. It is possible that if two consecutive memory
accesses to CMD[CDO] and INT_STAT (write to clear interrupt by overrun), this interrupt won't be cleared, since
overrun is cleared two clock cycles later.
Create testbench which will resolve this possibility!https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/183driver: stuck in interrupt on RX buffer overrun2019-01-02T17:33:21ZMartin Jeřábekdriver: stuck in interrupt on RX buffer overrunMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/182Test linux driver on real HW2019-03-14T19:52:59ZMartin JeřábekTest linux driver on real HWThis is a direct continuation of #162. The question is - as this requires the bitstream, should this be run from CAN_FD_IP_Core pipeline or from zynq-can-sja1000-top?This is a direct continuation of #162. The question is - as this requires the bitstream, should this be run from CAN_FD_IP_Core pipeline or from zynq-can-sja1000-top?ISO conformance testingMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/172Code coverage improvements2018-07-21T17:02:07ZIlle, Ondrej, Ing.Code coverage improvementsActual implementation of test logic is using standard "if" clause which is no very good since,
in case of error multiple lines are not executed and code coverage gets into red numbers.
The aim of this task is to use "assert" statement w...Actual implementation of test logic is using standard "if" clause which is no very good since,
in case of error multiple lines are not executed and code coverage gets into red numbers.
The aim of this task is to use "assert" statement where possible for implementation of tests.
This would cause (in case of feature tests) loss of generality since "o.outcome" can not be
asserted by assert statement! Possible solution for this problem might be rewriting the
tests to assume that test will fail by default and that when condition is satisfied, outcome
is set to desired value!Test maintenancehttps://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/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/168RX Buffer commands filtration2018-07-10T12:33:07ZIlle, Ondrej, Ing.RX Buffer commands filtrationAdd AND gates on ALL commands which are applied on RX Buffer. Use outcome of Message filter as
second input to AND gate. Note that first command comes at the end of control field when
ID is already received and Mesage filter output is e...Add AND gates on ALL commands which are applied on RX Buffer. Use outcome of Message filter as
second input to AND gate. Note that first command comes at the end of control field when
ID is already received and Mesage filter output is evaluated! All commands are thus applied
when Message filter contains valid values (even rec_abort). rec_ident_in is erased only in SOF
and data are invalid between SOF and ID reception. There are no Commands during this time.Bug fixinghttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/167Data length code test2018-07-14T21:43:23ZIlle, Ondrej, Ing.Data length code testAdd feature test, which will generate CAN 2.0 Frames with DLC < 8 and verify that all 8 bytes
of Data are sent! Then generate CAN Frame with DLC > 8, send it, and verify that only 8 bytes
were sent and received!Add feature test, which will generate CAN 2.0 Frames with DLC < 8 and verify that all 8 bytes
of Data are sent! Then generate CAN Frame with DLC > 8, send it, and verify that only 8 bytes
were sent and received!Test maintenancehttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/164Reference test problem2018-06-29T09:28:12ZIlle, Ondrej, Ing.Reference test problemAt the moment, reference test does not have the test properly specified, which causes RX buffer unit
test to be executed instead of reference test!At the moment, reference test does not have the test properly specified, which causes RX buffer unit
test to be executed instead of reference test!Bug fixinghttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/163Add sync. chain attributes.2018-07-09T12:08:01ZIlle, Ondrej, Ing.Add sync. chain attributes.VHDL attributes should be set on input synchronisation chain in busSync module like so:
https://forums.xilinx.com/t5/Timing-Analysis/Setting-ASYNC-REG-in-VHDL-for-Two-Flop-Synchronizer/td-p/700175
This can be done by TCL constraints fi...VHDL attributes should be set on input synchronisation chain in busSync module like so:
https://forums.xilinx.com/t5/Timing-Analysis/Setting-ASYNC-REG-in-VHDL-for-Two-Flop-Synchronizer/td-p/700175
This can be done by TCL constraints file, but it is better to have it in VHDL file defined explicitly.Bug fixing