CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2019-02-03T13:43:57Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/221RX Buffer unit test failure2019-02-03T13:43:57ZIlle, Ondrej, Ing.RX Buffer unit test failureRX Buffer unit test failed during one of my local debug runs.
Unfornunately, I did not reporduce it, NOR backed-up the seeds. The aim of this task is to execute
very intense RX Buffer unit test and make sure that it works properly.
It mi...RX Buffer unit test failed during one of my local debug runs.
Unfornunately, I did not reporduce it, NOR backed-up the seeds. The aim of this task is to execute
very intense RX Buffer unit test and make sure that it works properly.
It might be useful to create PSL functional coverage statements first:
https://gitlab.fel.cvut.cz/illeondr/CAN_FD_IP_Core/issues/201Test improvementshttps://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/220TXT Buffer functional coverage2019-02-02T12:31:58ZIlle, Ondrej, Ing.TXT Buffer functional coverageImplement functional coverage for TXT Buffer.
At least following situations should be covered:
1. [x] Buffer in each FSM state (empty, ready, tx_prog, ab_prog, aborted, failed, OK).
2. [x] Buffer set ready command.
3. [x] Buffer set abo...Implement functional coverage for TXT Buffer.
At least following situations should be covered:
1. [x] Buffer in each FSM state (empty, ready, tx_prog, ab_prog, aborted, failed, OK).
2. [x] Buffer set ready command.
3. [x] Buffer set abort and simultaneous HW command from CAN Core (this is what victor writes test for).Functional coveragehttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/258Achieve TXT Buffer hazard coverage2019-02-02T12:28:20ZIlle, Ondrej, Ing.Achieve TXT Buffer hazard coverageCurrent TXT Buffer hazard coverage test did not achieve coverage of the hazard situation.
Resolve thisCurrent TXT Buffer hazard coverage test did not achieve coverage of the hazard situation.
Resolve thisTest improvementshttps://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/251ci: fail if there are unconfigured tests2019-01-29T21:27:24ZMartin Jeřábekci: fail if there are unconfigured testsIn case we forget to add a test to config (fast, nightly), the test fw prints a warning but the pipeline succeeds. In such a case it should fail instead.
In case it is used for debugging (as mentioned in #249), it should be configurable...In case we forget to add a test to config (fast, nightly), the test fw prints a warning but the pipeline succeeds. In such a case it should fail instead.
In case it is used for debugging (as mentioned in #249), it should be configurable via commandline switch. The debug job would specify this switch. The default should be to fail, i.e. return nonzero.Martin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/252ci: automatically update/check component.xml before merge2019-01-29T20:48:12ZMartin Jeřábekci: automatically update/check component.xml before mergeSee https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/merge_requests/206#note_36870.
It would be nice to check the vivado (and quartus?) component files to contain all the source files.
Options:
1. Only check that the file is up-to-dat...See https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/merge_requests/206#note_36870.
It would be nice to check the vivado (and quartus?) component files to contain all the source files.
Options:
1. Only check that the file is up-to-date. Fail if it is not. It would require that everyone can run the generate script (shouldn't be problematic).
2. Generate it automatically and commit it. That is problematic though, I wouldn't go this way.Martin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/202TXT Buffer hazard test2019-01-23T21:04:19ZIlle, Ondrej, Ing.TXT Buffer hazard testImplement test-case which will verify that TX Buffer datapath is hazard free.
Such a test case should do following things in a loop (e.g 50 times in single iteration):
1. Insert frame to TXT Buffer
2. Mark the buffer as ready.
3. Immed...Implement test-case which will verify that TX Buffer datapath is hazard free.
Such a test case should do following things in a loop (e.g 50 times in single iteration):
1. Insert frame to TXT Buffer
2. Mark the buffer as ready.
3. Immediately send set_abort command.
4. Readout status of the buffer.
5. If the buffer is "aborted", check that no transmission is in progress (e.g. via STATUS), throw an error if not.
6. If the buffer is "abort in progress" check that transmission is in progress, and wait till its end. Throw an error if not.
7. If buffer is in any other state, throw an error.Test improvementsIng. Viktor FúraIng. Viktor Fúrahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/256Bitrate 1 Mbit / 10 Mbit fails with the master2019-01-23T16:36:09ZPavel PisaBitrate 1 Mbit / 10 Mbit fails with the masterI experience problem with data bitrate higher than 8 Mbit/s for longer time on PCI express card and I have tested code on Zynq some time ago and I think that the limitation has been exactly the same. Commit 1c639ac6a479e3e80a782de275ddba...I experience problem with data bitrate higher than 8 Mbit/s for longer time on PCI express card and I have tested code on Zynq some time ago and I think that the limitation has been exactly the same. Commit 1c639ac6a479e3e80a782de275ddba897d0bc0da was tested on PCI express card. The measured propagation delay is 10 on the given HW. It has been 11 at least sometimes with design working with 1Mb/s + 10Mb/s.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/255failing test: tb_rx_buf_unit_test2019-01-23T10:35:13ZMartin Jeřábekfailing test: tb_rx_buf_unit_testhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/jobs/27861https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/jobs/27861https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/242create vivado component generator2019-01-23T10:34:18ZMartin Jeřábekcreate vivado component generatorhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/246Add generic endian swapper module2019-01-21T11:19:47ZIlle, Ondrej, Ing.Add generic endian swapper moduleImplement generic endian swapper modules. These will replace the current endian_swap functtion
for synthesizable code!
Two modules will be implemented:
1. Endian swapper driven by generic.
2. Endian Swapper driven by input signal (swap/...Implement generic endian swapper modules. These will replace the current endian_swap functtion
for synthesizable code!
Two modules will be implemented:
1. Endian swapper driven by generic.
2. Endian Swapper driven by input signal (swap/not-swap).
Endian swapper should have two parameters:
1. Group count (Number of bytes)
2. Group size (Number of bits within a group)
Input will be a vector with "Group count" * "Group size"Wishlisthttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/85Make use oof VHDL function/procedure overloading2019-01-20T19:21:02ZIlle, Ondrej, Ing.Make use oof VHDL function/procedure overloadingThe actual implementation of CAN Test framework does not make use
of function overloading. This is especially interesting for functions
such as "FUNC_NAME" which takes signals as inputs and "FUNC_NAME_v"
which takes variables as inputs.The actual implementation of CAN Test framework does not make use
of function overloading. This is especially interesting for functions
such as "FUNC_NAME" which takes signals as inputs and "FUNC_NAME_v"
which takes variables as inputs.Wishlisthttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/233Add timestamp support to driver2019-01-20T17:24:55ZIlle, Ondrej, Ing.Add timestamp support to driverAdd Support for reading timestamp to low-level driver.
First rework in:
https://gitlab.fel.cvut.cz/illeondr/CAN_FD_IP_Core/merge_requests/179
must be merged so that we don't get more conflicts...Add Support for reading timestamp to low-level driver.
First rework in:
https://gitlab.fel.cvut.cz/illeondr/CAN_FD_IP_Core/merge_requests/179
must be merged so that we don't get more conflicts...Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/213Timestamp register feature test2019-01-20T16:36:10ZIlle, Ondrej, Ing.Timestamp register feature testAdd small feature test reading from TIMESTAMP registers which will store value of an external timestamp,
read value from these registers (several times), and check that timestamp is matching the value read
from the registers.
Feature of...Add small feature test reading from TIMESTAMP registers which will store value of an external timestamp,
read value from these registers (several times), and check that timestamp is matching the value read
from the registers.
Feature of reading the value of timestamp from register first must be implemented in:
https://gitlab.fel.cvut.cz/illeondr/CAN_FD_IP_Core/issues/208Test improvementsIng. Viktor FúraIng. Viktor Fúrahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/232Add Timestamp support to CAN Testlib2019-01-20T16:31:12ZIlle, Ondrej, Ing.Add Timestamp support to CAN TestlibAdd support for reading timestamp into CANTest lib.
In: test/lib/CANTestlib.vhd add function: CAN_read_timestamp.
This function will read from TIMESTAMP_LOW_ADR and TIMESTAMP_HIGH_ADR, concatenate the values to
one std_logic_vector, an...Add support for reading timestamp into CANTest lib.
In: test/lib/CANTestlib.vhd add function: CAN_read_timestamp.
This function will read from TIMESTAMP_LOW_ADR and TIMESTAMP_HIGH_ADR, concatenate the values to
one std_logic_vector, and return this vector (as a variable assignment). Since VHDL does not have
64 bit int type, returning as std_logic_vector(63 downto 0) is enough. Also in SW_CAN_Frame_type
this is used as timestamp reference.
Also, add proper function header with comments and argument explanation as in the other functions.
This function will be then used by timestamp test.Test improvementsIng. Viktor FúraIng. Viktor Fúrahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/206Create basic test library2019-01-19T23:18:00ZIlle, Ondrej, Ing.Create basic test libraryUse VUnit "log" and "check" library all over the testcases:
1. [x] Add includes for "log" and "check" library. Resolve all things that must be changed in run.py script.
2. [x] Change all TCs to use VUnit log function.
3. [x] Remove old ...Use VUnit "log" and "check" library all over the testcases:
1. [x] Add includes for "log" and "check" library. Resolve all things that must be changed in run.py script.
2. [x] Change all TCs to use VUnit log function.
3. [x] Remove old log function in CANTestlib and all related structs. Think about severities.
4. [x] Use Check library to replace explicit "if" comparisons.Test improvementshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/218testbench performance regression2019-01-19T21:57:29ZMartin Jeřábektestbench performance regressionSomewhere between Dec 9 and Dec 10, the nightly tests time jumped from 20 min to over 40 min (which is failing on timeout). This might be due to extracting parts of the code into entities (which is a good thing for synthesis).
I'll run ...Somewhere between Dec 9 and Dec 10, the nightly tests time jumped from 20 min to over 40 min (which is failing on timeout). This might be due to extracting parts of the code into entities (which is a good thing for synthesis).
I'll run it under profiler some time an look if there are any obvious problems.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/247Debian DKMS driver package build to ease update when kernel is updated.2019-01-18T22:58:15ZPavel PisaDebian DKMS driver package build to ease update when kernel is updated.https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/230CAN FD TX Bit Error detection optimization2019-01-18T17:25:43ZIlle, Ondrej, Ing.CAN FD TX Bit Error detection optimizationStatement of a problem:
CAN FD Transceiver in Data Bit-Rate must detect BIT Error. If value transmitted in Sync differs
from value in Sample Point, Bit error should be detected.
Since Data Bit-Rate might be fast enough, secondary sampl...Statement of a problem:
CAN FD Transceiver in Data Bit-Rate must detect BIT Error. If value transmitted in Sync differs
from value in Sample Point, Bit error should be detected.
Since Data Bit-Rate might be fast enough, secondary sampling mechanism is employed?
What does it mean for Bit error detection in this case?
RX value sampled by delayed sampling point must be compared with TX Data value at the time
of regular sampling point (or TX value that corresponds to the bit where original non-delayed
sample point was).
Secondary sampling point is implemented via shift register where sampling point is piped into this
register. Shift register output at index of ssp_offset is taken as delayed sampling point.
This is OK to create delayed sampling point. Could be optimized somehow, but that is not the point now.
Another shift register is used to store value of TX Data. Shit register output at index of ssp_offset
is taken and this gives us the original TX value at the time of regular sampling point.
What could be optimized is this second shift-register. We don't need to remember whole bit-stream per
clock cycle. We only need to remember values sent in SYNC segments. Proposal is to create small
cache/buffer FIFO-like where upon TX, new data will be appended to the end and upon active
delayed sampled point last data will be read. In Shift-register only the last data are read anyway.
If not, then we missed something and did not execute Bit Error comparison on a bit anyway...
Actually both shift registers have 130 entries. Removing one of them would lower the resource usage
or maybe allow extending the other one...ISO optimizations