Commit 66e901d6 authored by Ille, Ondrej, Ing.'s avatar Ille, Ondrej, Ing.

test: Modify headers of unit tests to comply standard test header format.

parent 284ae16b
......@@ -43,10 +43,19 @@
-- @TestInfoStart
--
-- @Purpose:
-- Main environment for reference test.
-- Testbench for reference test.
--
-- Reference test reads CAN Frame and bit sequence generated by transmission
-- of this frame by referrence CAN FD controller.
-- @Verifies:
-- @1. Reception of random CAN frames by CTU CAN FD as transmited by reference
-- CAN implementation.
--
-- @Test sequence:
-- @1. Read CAN frame (ID, Data, DLC, RTR/BRS/FDF flags) and recorded bit
-- sequence according to this frame from file set.
-- @2. Transmit this bit sequence by bit stream generator. CTU CAN FD receives
-- CAN frame.
-- @3. Read received CAN frame from DUT and compare this CAN frame with frame
-- read from file set. If frames are not equal, throw an error!
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
......
......@@ -44,16 +44,37 @@
--
-- @Purpose:
-- Sanity test simulates real bus operation with 4 CTU CAN FD Cores connected
-- on CAN Bus. Real bus topology with signal delay is implemented via
-- "signalDelayer". Random bit noise is inserted to the bus simulation.
-- Each node is clocked with different clock, to cover clock jitter and clock
-- uncertainty of real bus controllers!
-- on CAN Bus.
--
-- @Verifies:
-- @1. TODO: What does this test verify??
-- @1. Communication of CTU CAN FD with real bus delay between units.
-- @2. Communication with various topologies (Star, Bus, Tree)
-- @3. Response to errors (bit flips on bus) injected to simulation.
-- @4. Data consitency of communication (what has been send by 1 node must
-- be received by all other nodes)!
--
-- @Test sequence:
-- @1. TODO: Describe test sequence!
-- @1. Restart all nodes and configure bit timing. Turn all nodes on. Wait
-- until integration is over.
-- @2. Generate random frames and insert them to each CTU CAN FD instance for
-- transmission. Store each frame that was pushed to each of CTU CAN FDs
-- to auxiliarly memory (so called TX memory which monitors what all has
-- been sent!) for each node.
-- @3. Poll on RX Buffer and read out frames. Store read out frames in
-- auxiliarly memories (RX memories) for each node.
-- @4. Repeat generation of frames until RX memories are filled. Inject random
-- bit noise to the bus.
-- @5. When RX memories are filled, compare content of RX memories with TX
-- memories of each other node! Each frame which was sent by a Node must
-- be received by each other node (CAN bus needs to guarantee data
-- consistency). If a frame which was sent is not found in RX memories
-- of each other node, error is detected!
--
-- @Notes:
-- Real bus topology with signal delay is implemented via "signalDelayer".
-- Random bit noise is inserted to the bus simulation. Each node is clocked
-- with different clock, to cover clock jitter and clock uncertainty of real
-- bus controllers!
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
......@@ -406,6 +427,7 @@ architecture behavioral of sanity_test is
-- Additionally we modify the identifiers to have first N bits matching
-- (N is random), so that arbitration is lost in random bit. With absolutely
-- random identifiers arbitration is usually lost very soon (first 3 bits).
-- The reason behind this is to excercise arbitration behavior more heavily!
----------------------------------------------------------------------------
procedure correct_identifiers(
signal rand_ctr : inout natural range 0 to RAND_POOL_SIZE;
......
......@@ -45,6 +45,11 @@
-- @Purpose:
-- Simple test of can_top_apb, performing register read/write via APB.
--
-- @Verifies:
-- @1. Read transactions to CTU CAN FD via APB.
-- @2. Write transactions to CTU CAN FD via APB.
-- @3. 32 bit and 16 bit transactions.
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
-- Revision History:
......
......@@ -45,6 +45,30 @@
-- @Purpose:
-- Unit test for bit stuffing and bit destuffing circuits.
--
-- @Verifies:
-- @1. Functionality of Bit Stuffing and Bit Destuffing modules.
-- @1. Insertion of stuff bits after 5 bits of equal consecutive value.
-- @2. Discarding of stuffing bits after 5 bits of equal consecutive value.
-- @3. Fixed bit stuffing and Fixed bit destuffing. Stuff bit is inserted
-- after 4 bits regardless of bit value.
-- @4. Stuff Error detection if 6-th equal consecutive bit is received.
-- @5. Recursive behaviour of bit stuffing (stuff bit counts as first bit in
-- the next sequence of equal consecutive bits).
-- @6. Insertion of Stuff bit upon change from non-fixed to fixed bit stuffing
-- (modeling insertion of stuff bit before stuff count field of CAN FD
-- frame).
--
-- @Test sequence:
-- @1. Generate random bit sequence. Randomize whether at some point of the
-- sequence, switch to fixed bit stuffing will occur.
-- @2. Calculate expected sequence after bit stuffing (SW model).
-- @3. Apply sequence on inputs of Bit Stuffing. Compare output of bit
-- stuffing with expected bit coming out of SW model.
-- @4. Stuffed sequence is destuffed with bit destuffing and compared with
-- original generated sequence. Random stuff error is inserted. A check
-- if bit error is detected is executed.
--
-- @Notes:
-- Unit test makes use of bit stuffing/destuffing symmetry. Random data are
-- generated on input of bit stuffing. Data are stuffed and compared with
-- reference SW model. Then data are destuff_enable and output is compared with
......
......@@ -45,14 +45,17 @@
-- @Purpose:
-- Unit test for the CRC circuit.
--
-- Unit test generates bit sequence 10 to 620 bits long as well as random
-- drv_fd_type setting. Then it precalculates the CRC values by calc_crc pro-
-- cedure. Afterwads it emulates reception of this sequence on input of CRC
-- circuit. Sync signal is used for enable transition. Simple rx trigger signal
-- is used as trigger signal for processing input data. After the calculation,
-- software precalculated CRC and CRC from DUT are compared! If mismatch occurs
-- error is detected and test fails. Whole procedure is repeated "iterations"
-- times.
-- @Verifies:
-- @1. Calculation of CRC15, CRC17 and CRC21 according to 11898-1:2015.
-- @2. Calculation of CRC15, CRC17 and CRC21 according to CAN FD specification
-- 1.0 (non-iso version with different intialization vectors).
--
-- @Test sequence:
-- @1. Generate random bit sequence between 10 and 620 bits long. Generate
-- random setting of ISO/NON-ISO.
-- @2. Calculate expected CRC results for this bit sequence (SW model).
-- @3. Apply generated bit sequence to inputs of CRC module.
-- @4. Compare results of SW model and CRC value on DUT outputs.
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
......
......@@ -45,6 +45,18 @@
-- @Purpose:
-- Unit test for the Interrupt manager.
--
-- @Verifies:
-- @1. Interrupt enable, Interrupt mask and capturing of interrupts by Interrupt
-- Manager module.
--
-- @Test sequence:
-- @1. Generate random setting of Interrupt manager module (Interrupt enables,
-- Interrupt masks).
-- @2. Generate random inputs to Interrupt manager. Calculate expected results
-- of Interrupt manager (SW model).
-- @3. Compare results of Interrupt manager with SW model.
--
-- @Notes:
-- Random interrupt source signals are generated in the testbench. Periodically
-- random setting of interrupt generator is used. Then test waits and evaluates
-- whether interrupt prediction (int_test_ctr) matches the actual number of
......
......@@ -43,7 +43,19 @@
-- @TestInfoStart
--
-- @Purpose:
-- Unit test for the message filter circuit
-- Unit test for the frame filters circuit.
--
-- @Verifies:
-- @1. Bit filter functionality (Filter value and filter mask).
-- @2. Range filter functionality (Low and High thresholds).
--
-- @Test sequence:
-- @1. Generate random bit values, bit masks for bit filters and low-high
-- thresholds for range filter.
-- @2. Generate random CAN ID and frame and identifier type on input of Frame
-- filters.
-- @3. Calculate whether frame shall pass filters (SW model).
-- @4. Check whether output of frame filters equals to output of SW model.
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
......
......@@ -45,6 +45,12 @@
-- @Purpose:
-- Unit test for the prescaler circuit.
--
-- @Verifies:
-- @1. TODO
--
-- @Test sequence:
-- @1. TODO
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
-- Revision History:
......
......@@ -43,10 +43,33 @@
-- @TestInfoStart
--
-- @Purpose:
-- Unit test for Protocol Control. The architecture of this test is depicted
-- in picture below. It is inherited from original Protocol Control testbench
-- created during implementation of the CAN FD IP Core. This testbench only
-- tests the state machine of protocol control!
-- Unit test for Protocol Control FSM.
--
-- @Verifies:
-- @1. CAN 2.0 frame with Base identifier format.
-- @2. CAN FD frame with Base identifier format.
-- @3. CAN 2.0 frame with Extended identifier format.
-- @4. CAN FD frame with Extended identifier format.
-- @5. Basic frame formats transmission and reception by Protocol control FSM.
--
-- @Test sequence:
-- @1. Generate random frame on input of Protocol Control 1.
-- @2. Calculate expected bit sequence (frame) on the CAN bus including
-- ACK and EOF (SW model)!
-- @3. Transmitt the frame by Protocol control 1 DUT and record transmitted
-- bit sequence! Protocol control 2 DUT receives the bit sequence.
-- @4. Compare if Expected bit sequence (SW model output) is equal to
-- recorded one.
-- @5. Compare if Generated frame (data,ident,type of frame...) inserted to
-- Protocol control 1 for transmission is equal to received frame by
-- Protocol control 2.
-- @6. Loop points 1 to 6 until the number of iterations was reached!
--
-- @Notes:
-- The architecture of this test is depicted in picture below. It is inherited
-- from original Protocol Control testbench created during implementation of
-- the CAN FD IP Core. This testbench only tests the state machine of protocol
-- control!
--
-- Following features of are NOT tested here:
-- - bit stuffing and destuffing (frames transmitted from protocol control
......@@ -90,18 +113,6 @@
-- Error if
-- not matching
--
--
-- Test sequence:
-- 1. Generate random frame on input of Protocol Control 1
-- 2. Calculate expected bit sequence (frame) on the CAN bus including
-- ACK and EOF!
-- 3. Transmitt the frame and record the bit sequence!
-- 4. Compare if Expected bit sequence is equal to recorded one
-- 5. Compare if Generated frame (data,ident,type of frame...) is equal
-- to received one!
-- 6. If points 4 or 5 give mismatch increase error counter
-- 7. Loop points 1 to 6 until the number of iterations was reached!
--
-- Note that since additional function for buidling CAN frame in "SW" is used
-- it verifies the protocol control towards errors which can be not detected
-- when both PC1 and PC2 have the error. E.g if PC has missing bit then it
......
......@@ -45,8 +45,36 @@
-- @Purpose:
-- Unit test for the RX Buffer circuit.
--
-- @Verifies:
-- @1. Storing protocol to RX Buffer (store metadata, store data word, reception
-- valid, reception abort).
-- @2. Storing of Metadata, Identifier and Data words to RX Buffer.
-- @2. Reading protocol from RX Buffer. Reading of CAN frame from RX Buffer.
-- @3. Over-run detection by RX Buffer (frame is discarded when overrun is
-- detected).
-- @4. Simultaneous commit and finishing read of frame from RX Buffer.
--
-- @Test sequence:
-- @1. Generate random CAN frames on input of RX Buffer. Emulate storing protocol
-- as if coming from CAN Core. Randomize whether abort will be issued.
-- (As if error frame was occured). Randomize time between frames. Randomize
-- timestamp capturing in SOF or EOF.
-- @2. If Overrun is signalled or frame abort is issued, discard the frame. If
-- frame storing finished succesfully, store the frame also to auxiliarly
-- memory (Input memory). This memory contains what all has been stored to
-- RX Buffer.
-- @3. Read frames from RX Buffer with random gaps between (emulate read
-- protocol). If frame is read, store it to auxiliarly memory (Output memory).
-- Output memory contains what all has been read from RX Buffer.
-- @4. When Input memory is filled, stop generating CAN frames to RX Buffer.
-- Wait until all frames are read from RX Buffer and compare contents of
-- Input memory and Output memory (everything what was succesfully stored
-- to RX Buffer must be also in the same order read from RX Buffer). This
-- verifies proper pointer handling.
-- @Notes:
-- Following test instantiates RX Buffer. Stimuli generator generates input
-- frames as CAN_Core would do. Then it checks whether frame was stored into
-- frames as CAN Core would do. Then it checks whether frame was stored into
-- the buffer! Another process reads the data as user would do by memory access.
-- Both, data written into the buffer, and data read from the buffer are stored
-- into test memories (in_mem,out_mem). When test memory is full content of
......
......@@ -45,6 +45,12 @@
-- @Purpose:
-- Unit test for TX Arbitrator circuit
--
-- @Verifies:
-- @1. TODO
--
-- @Test sequence:
-- @1. TODO
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
-- Revision History:
......
......@@ -45,6 +45,12 @@
-- @Purpose:
-- Unit test for the TX Buffer circuit
--
-- @Verifies:
-- @1. TODO
--
-- @Test sequence:
-- @1. TODO
--
-- @TestInfoEnd
--------------------------------------------------------------------------------
-- Revision History:
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment