6. IP information register case study
6.3. IPs designed for the test setup
All of the IPs designed for the test setup are fitted with IP information registers.
6.3.1. Nios II monitor
As the name suggests, the Nios II monitor is used to probe the activity of a Nios II processor.
And as was already mentioned in chapter four, the source code of the Nios II processor is encrypted. This leads to the reality that the information registers cannot be placed inside the processor and the monitor has to be external.
The register layout for the monitor itself can be seen in Table 6.1. Unused registers are marked with a dash. The monitor has all the required IP information registers as well as eight optional registers, of which three are used for creating logs of the processor’s activity.
Table 6.1 - Nios II monitor information register layout
Offset R/W/C Name Description
0x00 R IIR1 header A 32-bit header that inverts itself on reads
0x01 R IIR type value: 101
vendor:TUT, library:TUT, name: Nios II monitor, version: 0.2
… R ...
0x0C R VLNV
0x0D - - -
0x0E R/W Log register pointer
0x0F R/C Reads Number of reads done to the Nios II monitor 0x10 R/C Writes Number of writes done to the Nios II monitor 0x11 R/C Faulty reads Number of reads with faulty address
0x12 R/C Faulty writes Number of writes with faulty address
0x13 R/C CPU longest wait Longest time in cycles the CPU has waited for memory access
0x14 R/C CPU mem stall log Log storing the events when the CPU was stalled waiting for memory access
0x15 R/C CPU I rd log Log storing the events when the CPU was reading instructions from external memory
0x16 R/C CPU D rw log Log storing the events when the CPU was writing or reading data to or from external memory
These types of log registers are further described in the next sub-chapter.
6.3.1.1. Log registers
There are two main types for the log registers. The first one is an event based in which one event includes a timestamp and the accompanying data for the event. The accompanying data can be excluded if the event log register stores only the timestamps of an event and the event can be identified implicitly. The second one is a periodic log with a custom sized log interval and only the data is stored for the intervals. For example an error log is event based and a utilization log is periodic.
The logging functionality can be controlled by writing specific words to specific registers. The logging can be disabled, enabled, cleared and the log mode can be set. The log register commands are described in Table 6.2.
Table 6.2 - Log register commands
Code Command Description
0x00 disable logging -
0x01 enable logging -
0x02 clear the log -
0x03 disable automatic clear Disables automatic clearing of log contents after a full read
0x04 enable automatic clear Enables automatic clearing of log contents after a full read
0x05 enable linear log mode -
0x06 enable fifo log mode -
0x07 read log memory Next reads will read the log’s contents 0x08 read log status Next reads will read the log’s status
Table 6.3 - Log status structure
* log size = 128 words
The log mode of these registers can be set to either a linear mode or a FIFO mode. In the linear mode, the memory reserved for the log is filled from the beginning and when the end has been reached the logging is stopped. In the FIFO mode, the memory is used as a FIFO so when the whole log memory is filled, the values at the beginning of the log will be replaced with new ones.
There is a possibility that a component reading an event based log can miss data by first reading the entire log and after this manually clearing it. This happens because additional events can be written to the log during the clock cycles after the log is read and it is cleared. To ensure that no logged data is lost by clearing the log manually, an automatic clear after a full read can be enabled.
b31..b11 b10..b03* b02 b01 b00
- log fill amount log overflow log auto clear log enable
The content for an event based log is described in Table 6.4. The example logr shown in the table has eight words of data for each event and there are 32 events in the log. The contents of a periodic log described in Table 6.5 .
Table 6.4 - Example of event based log content
Event Word Content
Table 6.5 - Example of periodic log content
Period Word Content
The XD GPU is a VGA display controller and a 2D graphics processing unit (GPU) which is still early in development [arvio11]. It is inspired by old video game consoles and their pixel processing units (PPU), and has a fixed resolution of 640x480. Unlike today’s GPUs, the PPUs
did not have frame buffers and the graphics were generated at the same time the pixel line was displayed on the television or monitor.
XD GPU uses only two line buffers to store the generated graphics. The line buffers are used the same way as double buffered frame buffers are used. The next line of graphics is generated at the same time as the previous one is being displayed.
Information registers were added to the GPU after its design. Besides the required registers, the IIR block has registers to log the activity of the CPU’s and GPU’s access to the shared SRAM. This log functionality is used in the third part of the case study. The register layout for the IIR block can be seen in Table 6.6.
Table 6.6 - XD GPU information register layout
Offset R/W/C Name Description
0x00 R IIR1 header A 32-bit header that inverts itself on reads
0x01 R IIR type binary value: 110
vendor: liHard, library: gfx, name: xd_gpu, version: 0.2
… R ...
0x0B R VLNV
0x0C - - -
0x0D R Frames from reset Incrementing frame number starting from exit of reset state on the main FSM (not system or IP reset)
0x0E R/C Faulty writes Number of writes with faulty address 0x0F R/C Faulty reads Number of reads with faulty address 0x10 R/W Frames to capture Frames to capture on the log
components have to have access to a 512 kB SRAM [issi01], a controller was implemented which has the logic to arbitrate the access rights to the memory.
There is a SOPC memory controller for the SRAM chip on the DE2 provided by Terasic, but this
“controller” can only use the chip at 50 MHz which is half of the full 100 MHz frequency the chip can operate under. The chip can operate at full speed by adding extra timing information for the Quartus II fitter and generating a 5 ns write pulse.
Memory controllers normally do not have registers which to configure and have only one address space which spans the whole of the underlying memory. Therefore it was logical to house the information registers for the controller on a whole new Avalon slave port, while retaining the other port solely for the underlying memory. The layout for the information registers can be seen in Table 6.7.
Table 6.7 - SRAM information register layout
Offset R/W/C Name Description
0x00 R IIR1 header A 32-bit header that inverts itself on reads
0x01 R IIR type binary value: 000
vendor: liHard, library: storage, name:
sram_2x_access, version: 0.2
… R ...
0x0E R VLNV
0x0F - - -
0x10 R/C Mem. writes Writes done to the SRAM (lower bytes of value) 0x11 R/C Mem. writes Writes done to the SRAM (upper bytes of value) 0x12 R/C Mem. reads Reads done to the SRAM (lower bytes of value) between frames. A screenshot of the demo can be seen in Figure 6.3.