Change of RX data read from RX buffer
This modification involves changing architecture of the RX FIFO buffer. The RX FIFO buffer has actually parallel data interface from the IP Core (whole CAN frame is available in parallel). Once the frame is properly received (EOF field), the signal „rec_valid“ starts loading the frame into the RX buffer. The frame is stored in following up to 20 clock cycles, 32-bit word per clock cycle. The other part of the RX Buffer has only one 32-bit word at a time available. This word corresponds to address of the „read_pointer“ value. „read_pointer“ is incremented by each read on Avalon Interface. Read of the frame is performed by repetitive read from the same address.
The aim of this modification is to create the same interface between RX Buffer and registers (Avalon) as between RX Buffer and CAN Core. This involves modifying the register map of the IP Core. Offset on the Avalon bus will be added to the read pointer and it will create direct address to the RAM memory of RX Buffer. Avalon Adress must be added combinationally to the read pointer value, to be able to get the data on the output of the RAM in the next clock cycle. The multiplexor must be created to drive the RAM address based on the Avalon address range. Actual implementation moves to the next word in the memory (increments read pointer) by performing the Avalon read. Additional bit must be added to register map. Writing logic 1 into this bit will increment the value of the pointer to point to the first word of next CAN frame. Thus user would be responsible for erasing the frame from RX buffer after reading it!
An optional inference of the RX Buffer via VHDL generic must be added during this step. This option will allow to either inferr or not inferr the RX buffer. In the case of the buffer presence the Avalon address will create the RAM address based on chosen register. In the absence of the RX buffer the Avalon address would create the offset in the parallel interface on the ouput of CAN Core. In case of Buffer absence the user is responsible for reading the frame soon enough before the Core erases it at the SOF of next frame!