The technical field of this invention is L2 FIFO architecture.
Incoming frames are stored in RXL2 FIFO which is composed of 2 banks. L2 FIFO enables offloading of PRU (Programmable Real-Time Unit: real-time non-preemptive RISC core) to do other tasks by buffering 16-bit data (8-bit at a time) from L1 FIFO. Hence instead of polling every 160 ns (16-bit) for received data, we can poll every 2.56 us (32*8*10).
Each bank has 32 bytes of data, 16 bytes of status and a 5 bit write pointer. There is one status entry per two bytes. The write pointer gives the info about data entry being written. First 8 registers in the bank hold data and next 4 registers has corresponding status.
A status can be volatile or static. A volatile status is one which is not yet complete, and hence can not be parsed.
The parser task might be required to start parsing in the middle of the FIFO based on where it left parsing in the previous run.
The frames are packed contiguously. The buffer does not switch on each EOF.
Efficient parsing of packets using an L2 FIFO hooked to MII interface of ICSS which has 2 banks of data and status (32 and 16 bytes/bank respectively) and non-interleaved. Status informs the parser about SOF/SFD/EOF/Errors etc
These and other aspects of this invention are illustrated in the drawing, in which:
The
Always check status for errors/SOF/EOF, before processing data and updating state variables below. This is mandatory to update error counters etc—advantage with the state machine approach is that PRU utilization is not a function of number of bytes to process. There are states in which we can even skip XIN of new data. For example: SKIP_TILL_EOF, SKIP_PAD_BYTES etc. We spend cycles only when needed and below mentioned variables should be sufficient to save parser context.
State: SOF state_length: 1 read_bytes, fifo_status (last_read_bank, bytes) NextState: SKIP_ADDRESS
State: SKIP_ADDRESS state_length: 12 bytes read_bytes, fifo_status (last_read_bank, bytes) NextState: EthercatType
State: EthercatType state_length: 2 bytes read_bytes, fifo_status (last_read_bank, bytes) NextState: EthercatFrameHeader or SKIP_TILL_EOF
State: EthercatFrameHeader state length: 2 read_bytes, fifo_status (last_read_bank, bytes) NextState: EthercatDataGram or SKIP_TILL_EOF
State: EthercatDataGram state_length: n read_bytes, fifo_status (last_read_bank, bytes) NextState:
EthercatDataGram, SKIP_PAD_BYTES, SKIP_TILL_EOF//In this state read Command, Address and Length and More bit. Skip remaining bytes
In one implementation of the invention:
Accordingly the per byte the code has to do following checks:
The above steps are the least number of cycles spent per byte. Additionally bank change, if done, requires 6 cycles.
In the above steps each step is a cycle except for step 6 which takes 3 cycles (because status pointer should be incremented only once in two bytes). Thus the number of cycles used for 32 byte plain parsing, assuming a bank change once=(9*32+6)*5=1.470 uS.
The above cycles are just for status parsing. We can assume additionally 2 cycles per byte for data parsing (for task initialization, for code pointer storage once in a while, for loop counter increments, for task end etc). This is 2*32*5=320 ns.
Additionally scheduler overhead for context save and restore is 175 ns.
Thus the average frame parse time=1.47+0.32+0.175=1.965 uS.
This number doesn't account for EOF calculations because that is once in a while activity for good frames. But in the worst case of every frame being 2 bytes long, the EOF operation has to be done very frequently, which bumps up this number to ˜2.4 uS.
An alternate and preferable implementation is as follows:
As the first approach shown necessitates byte level parsing, it is very slow. To make it fast, the approach should be to parse status in jumps of two bytes wherever possible. But this mandates that frame parsing code be implemented as SW state machine.
This approach is as follows:
This is shown in the FIGURE, where status is read in block 101. Parser 102 looks for EOF, Bank change or a Volatile status. If not found, control returns to block 101 When found, state machine 103 continues parsing from the start pointer to the end pointer, and updates the state in block 104. When the end pointer is reached, control returns to block 101 to continue parsing.
By this approach, a single byte status parse is only required if EOF is asserted at odd byte location. Otherwise status is parsed for 2 bytes at a time.
Analysis of the second implementation:
By this approach, a single byte status parse is only required if EOF is asserted at odd byte location. Otherwise status is parsed for 2 bytes at a time.
Cycle numbers for this approach are
This application claims priority under 35 U.S.C. 119(e)(1) to Provisional Application No. 61709382 filed 4 Oct. 2012.
Number | Date | Country | |
---|---|---|---|
61709382 | Oct 2012 | US |