17.11.2012 Views

Soft-Core Processor Design - CiteSeer

Soft-Core Processor Design - CiteSeer

Soft-Core Processor Design - CiteSeer

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

the computer keyboard was pressed, which provided a good test case because of the random<br />

nature of the input. The ultimate test was a small game developed for the Nios development board<br />

which used four input buttons available on the development board as the interrupt source, an LCD<br />

display, two 7-segment LED displays and the UART to communicate with the user. Finally, when<br />

the UT Nios benchmark set was defined, the programs in the set were run on various system<br />

configurations as described in the previous chapter.<br />

6.2. <strong>Design</strong> Analysis<br />

During the UT Nios development process the timing analysis capabilities of Quartus II were<br />

used to guide the design optimizations. We use the same method to identify the critical paths in<br />

the current UT Nios implementation. Analyzing the two hundred longest paths we identified<br />

several groups of paths:<br />

• Paths going from the operands and control signals in the O/X pipeline registers,<br />

through the ALU adder, to the data bus, to the register file write multiplexer, and<br />

finally to one of the following: the PC, the PPC, the operands in the O/X pipeline<br />

registers through the data forwarding logic, or the register file. These paths are the<br />

result of the data load operations. The memory address is calculated in the ALU adder<br />

and sent to the data bus, the returned data is selected by the register file write<br />

multiplexer, and forwarded to different destinations in the datapath.<br />

• Paths going from the operand in the O/X pipeline registers, through the control unit to<br />

the instruction bus. These paths correspond to testing a skip condition on a register<br />

value, and deciding whether the next instruction should be read, or the prefetch unit<br />

should be flushed due to the control-flow instruction in the operand stage.<br />

• Paths going from the control signals in the O/X pipeline registers, through the control<br />

unit to the control registers, back to the register file address handler, and to the register<br />

file. These paths correspond to the control signals directing the update of the CWP<br />

field in the control registers module. The new value of the CWP is then used to<br />

calculate the address of the register currently being read from the register file<br />

• Paths going from the instruction register through the instruction decoder to the register<br />

file address handler and the register file. These paths correspond to the OP code bits<br />

used to choose between the outputs of the two instruction decoder memory modules.<br />

Based on the result of the instruction decoding, the address of the register to be read is<br />

calculated and forwarded to the register file.<br />

80

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!