github-mirrors/cva6
1
0
Fork 0
mirror of https://github.com/openhwgroup/cva6.git synced 2025-04-22 13:17:41 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

Remove old and merged documentation

Browse source
This commit is contained in:
Florian Zaruba 2018-01-25 10:58:04 +01:00
parent 440e89a719
commit 90aec89a2f
No known key found for this signature in database
GPG key ID: E742FFE8EC38A792
18 changed files with 1 additions and 20780 deletions
Download patch file Download diff file Expand all files Collapse all files

118
docs/old_doc/architecture.md
View file

@ -1,118 +0,0 @@
# General Architecture
## Scoreboarding
The scoreboards main purpose is to decouple the check for data (WAW, WAR) and structural hazards and issue instructions to the various functional units. It does so by taking full responsibility for instruction issue and execution. This also includes detecting the two aforementioned hazards.
The scoreboard enables utilization of all available functional units as well as efficient usage of pipelined functional units which take a couple of cycles before the instruction finishes. The scoreboard tracks all instructions which are currently being processed in all functional units.
Because the scoreboard is in full control over the functional units it also controls the forwarding path and write back of all functional units.
1. **Issue**: If a functional unit for the instruction is free and no other active instruction has the same destination register, the scoreboard issues the instruction to the functional unit. If a WAW hazard is present, the instruction issue will stall until the hazard has been cleared. Should the issue stage stall the instruction buffer in the ID stage fills until it is full.
2. **Read operand**: The scoreboard monitors the availability of the source operands. A source operand is available if no earlier issued active instruction is going to write it. When the source operands are available (either through the register file or through a forwarding path from any of the other functional units or an already completed instruction), the scoreboard tells the FUs to proceed to read the operands. The scoreboard resolves RAW hazards dynamically in this step.
3. **Execution**: The FU begins execution upon receiving operands. When the result is ready, it notifies the scoreboard. Any instruction can take multiple cycles.
4. **Write Back**: Once the scoreboard is aware that the functional unit has completed execution, it commits the result in-order to either the architectural register file, CSR register file, floating point register file or data memory. If there are no structural dependencies on the write path the scoreboard can write more than one result at a time.
The scoreboard maintains a connection to each functional unit and each architectural state holding element. For Ariane there is the plan to include the following FUs: ALU, Multiplier and LSU. If it should turn out to be necessary additional ALUs or multipliers can be easily added.
**TODO: Detailed Bookkeeping**
> While it will be possible that the execute stage houses more than one ALU or multiplier, this is not going to be the case for the load store unit (LSU). The current assumption will be, that the LSU is like any other functional unit (using a variable amount of cycles to perform its operation), but it should also be in full control over the data memories state. It therefore takes a special role in the whole design.
Register addresses can be of type: CSR, Regfile (x0,.., x31), None (immediate), current PC
**TODO: Register Encoding, OP encoding**
### Exception Propagation
In order to simplify hardware design exceptions are only considered at commit time. Therefore, the scoreboard provides an exception field. If an exception has been present prior to issue (for example in the fetch or decode step) it has been propagated to this point. An instruction that has the exception flag set is considered as completed by the scoreboard and can be retired as soon as every instruction prior to this one has been committed.
### Scoreboard Implementation
The scoreboard is implemented as a circular buffer with two pointers. The first pointer being the commit point. Everything above this pointer is save to be reused for new instructions arriving. The issue pointer points to the top of the buffer, e.g.: always to the latest issued instruction. The scoreboard therefore keeps track of instruction ordering.
### Functional Units
The FU are not supposed to have inter-unit dependencies for the moment, e.g.: every FU must be able to perform its operation independently of every other unit. The following interface is proposed to keep maximum interoperability. A minimum set of port definitions would be:
| **Signal** | **Direction** | **Description** |
|-------------|---------------|--------------------------------------------------|
| clk_i | Input | Global clock signal |
| rst_ni | Input | Reset the functional unit to a specific state |
| operator_i | Input | Operation to perform |
| operand_a_i | Input | Operand A |
| operand_b_i | Input | Operand B |
| result_o | Output | Result Output |
| valid_i | Input | Data is valid from ID/Scoreboard |
| ready_o | Output | Ready signal to ID/Scoreboard |
| valid_o | Output | Data is valid to WB/Scoreboard |
| trans_id_i | Input | Transaction ID for the operation to perform |
| trans_id_o | Output | Transaction ID at which to write back the result |
Refer to the [timing diagram](timing_diagrams/#functional-unit) section for further detail.
### Branches
Branches are handled by the branch unit in co-operation with the ALU. It is a little bit specially in the sense that it does not have a write back port to the scoreboard. Actually, the only thing the branch unit writes is PC + 4 (or + 2 in the compressed case) to the destination register. To save write back ports the ALU does this addition and the write back port of the ALU is used to write back to register *rd*. In summary, what this means is - branch instructions (including jumps) are another form of ALU instruction. They can only be performed if the ALU is ready (as the current ALU is single cycle this means always). Furthermore the exception write back port of the ALU is used to signal mis-aligned branch target exceptions (e.g.: an exception which occurs if the branch target is not aligned to a half-word boundary).
The branch unit maintains two more connections to different parts of the processor:
1. The issue and read operand stage: The issue stage will block if it issued a branch instruction which is currently not resolved. Therefore the branch unit will signal the issue and read operand stage that it just resolved a branch. This is only done if it was indeed a branch and not an instruction where branch-prediction just thought it was a branch.
2. To the PCGEN stage where it signals whether this instruction was a branch, a taken and mis-predicted branch, a un-taken and mis-predicted branch, a taken and correctly predicted branch or an un-taken and correctly predicted branch. If it was a mis-predict the front-end (everything from issue to PCGEN) of the processor is flushed and PCGEN starts re-fetching from the newly calculated PC (which is correct).
### LSU
Loads can be issued immediately while stores need to wait for the commit signal from the scoreboard. They are kept in a store address queue (SAQ) for the time being.
### Commit Point
The scoreboard is the only way to update the architectural state. This simplifies the controller design significantly since this is the only point where an exception is known to be taken.
### Issue Window
Currently the idea is to not speculate past branches or jumps. So the issue window is the size of a basic block. Theoretically it could be possible to speculate past one branch.
If the scoreboard encounters a branch it does not accept new instructions from ID. Executes the branch instruction. In the next cycle the speculated pc is compared to the calculated PC. If they match the scoreboard starts to issue instructions again. If not, a miss-predict is signaled and all fetched instructions are killed prior to the execute stage. The pipeline fills from the new address. Branch prediction data structures are updated accordingly.
## Load Store Unit
The load store unit is similar to every other functional unit. In addition, it has to manage the interface to the data memory. In particular, it houses the DTLB (Data Translation Lookaside Buffer) and the page table walker (PTW). It arbitrates the access to data memory, giving precedence to PTW lookups. This is done in order to un-stall TLB misses as soon as possible. A high level block diagram of the LSU can be found here:
![LSU Block Diagram](fig/lsu_blockdiagram.png)
The LSU can issue load request immediately while stores need to be kept back as long as the scoreboard does not issue a commit signal: This is done because the whole processor is designed to only have a single commit point (the commit stage). Because issuing loads to the memory hierarchy does not have any semantic side effects the LSU can issue them immediately. Totally in contrast to the nature of a store: Stores alter the architectural state and are therefore placed in a store buffer only to be committed in a later step by the commit stage. Sometimes this is also called **posted-store** because the store request is posted to the store queue and waiting for entering the memory hierarchy as soon as the commit signal goes high and the memory interface is not in use.
Therefore, upon a load, the LSU also needs to check its SAQ for potential data words. Should it find uncommitted data it stalls, since it can’t satisfy the current request. This means:
- Two loads to the same address are allowed. They will return in issue order.
- Two stores to the same address are allowed. They are issued in-order by the scoreboard and stored in the SAQ as long as the scoreboard didn’t give the grant to commit them.
- A store followed by a load to the same address can only be satisfied if the store has already been committed (marked as committed in the SAQ). Otherwise the LSU stalls until the scoreboard commits the instruction. We cannot guarantee that the store will eventually be committed (e.g.: an exception occurred).
For the moment being, the LSU does not handle misaligned accesses (e.g.: access which are not aligned at a 64 bit boundary). It simply issues a misaligned exception and lets the exception handler resolve the LD/ST. Furthermore, it can issue a load access exception.
If an exception was signaled by the WB stage, the LSU kills all entries in its store queue except those that have been marked as committed.
The LSU of the core takes care of accessing the data memory. Load and stores on words (32 bit), half words (16 bit) and bytes (8 bit) are supported.
## D$ Interface
| **Signal** | **Width (bit)** | **Direction** | **Description** |
|---------------|-----------------|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| address_index | 12 | Out | Index into cache (send in cycle 0) |
| address_tag | 44 | Out | Tag of cache (send in cycle 1:$) |
| data_wdata | 64 | Out | Data to write into cache |
| data_req | 1 | Out | Requesting a new transfer |
| data_we | 1 | Out | This transfer is a write |
| data_be | 8 | Out | Byte enable for the write transfer |
| tag_valid | 1 | Out | Tag is valid |
| kill_req | 1 | Out | Kill the outstanding request |
| data_gnt | 1 | In | The request was granted, the sender can assume that it is safe to change the index, byte enable and write enable flag |
| data_rvalid | 1 | In | Returned data is valid, the sender can now change the tag and tag request signals. Rvalid is also asserted for a write, in that case it just means that the tag can be changed |
| data_rdata | 64 | In | Read data, this data is valid if the rvalid flag is asserted |
The protocol that is used by the LSU to communicate with a cache works as follows:
The LSU provides a valid index in *address_index* and sets *data_req* high. The memory then answers with a *data_gnt* set high as soon as it is ready to serve the request. This may happen in the same cycle as the request was sent or any number of cycles later. After a grant was received, the index may be changed in the next cycle by the LSU. In addition, the *data_wdata*, *data_we* and *data_be* signals may be changed as it is assumed that the memory has already processed and stored that information. After receiving a grant, the LSU provides the tag information by setting the *address_tag* and asserting the *tag_valid* signal. The memory answers with a *data_rvalid* set high if *data_rdata* is valid. The tag information may be unconditionally send by the LSU the cycle after it received a grant, e.g.: the cache needs to make sure that it is able to process the request. The cache can combinatorially use the tag address and tag signals (e.g.: doing tag comparison with it). This process may happen one or more cycles after the grant has been received. Note that *data_rvalid* must also be set when a write was performed, although the *data_rdata* has no meaning in this case. Check the [timing diagrams](timing_diagrams/#memory-interface) for further details.
Furthermore, the LSU can kill the last outstanding request for which it should send the tag to the D$. It can do so by asserting *kill_req* with *tag_valid* at the same time. In that case the D$ will ignore the *address_tag* signal and clear its internal structures, ready to accept a new request in the same cycle.

209
docs/old_doc/block_details.md
View file

@ -1,209 +0,0 @@
# Block Details
The processor has 5-stages:
## Next PC Generation (PC Gen)
PC gen is responsible for generating the next program counter. All program counters are logical addressed. If the logical to physical mapping changes a fence instruction should flush the pipeline, caches (?) and TLB.
This stage contains speculation on the next branch target as well as the information if the branch target is taken or not. In addition, it provides ports to the branch history table (BHT) and branch target buffer (BTB).
If the branch target buffer decodes a certain PC as a jump the BHT decides if the branch is taken or not.
Because of the various state-full memory structures this stage is split into two pipeline stages. It also provides a handshaking signal to the decode stage to stall the pipeline if this should be necessary (back-pressure).
The next PC can originate from the following sources:
1. Exception (including interrupts): This also means to figure out to which exception handler the delegate registers are pointing to. If an exception is taken, disable interrupts.
2. Debug
3. Request from execute stage (jump, branch) which was not detected as one by the BHT.
4. Predicted PC (BHT and BTB)
5. Environment Call (`ecall) instruction. Read the CSRs to figure out where to jump.
6. Miss-predict: This triggers a pipeline flush and the PC Gen stage starts fetching from there.
### BTB and BHT
Currently all branch prediction data structures reside in a single register like file. It is indexed with the appropriate number of bits from the PC and contains information about the predicted target address as well as the outcome of a two (actually configurable) saturation counter. The prediction result is used in the subsequent stage to jump (or not).
For a future version a more accurate predictor might be necessary (gshare, tournament,...).
## Instruction Fetch (IF)
In the IF stage we already know the physical PC. The request of the instruction is on its way to the instruction memory. We know the result of the BHT and can set the next PC accordingly. At the end of this stage the instruction PC is passed on to the ID stage. Retrieved instructions are stored in an instruction queue.
It is possible that a TLB or cache miss occurred. If this is the case the IF stage signals that it is not ready. The pipeline in the direction of the ID stage will empty itself.
### ITLB
### Instruction Queue
The instruction queue is part of the IF stage. Its purpose is to decouple the instruction fetch unit as much as possible from the rest of the pipeline.
## Instruction Decode (ID)
The ID stage contains the instruction decode logic (including the planned compressed decoder) as well as the register files (CSR, floating point and regular register file). The decoded instruction is committed to the scoreboard. The scoreboard decides which instruction it can issues next to the execute stage.
### Decoder
The decoder's purpose is to expand the 32 bit incoming instruction stream to set the right values in the scoreboard, e.g.: which functional unit to activate, setting wright path and reading the destination, *src1* and *src2* register.
The current privilege level is not checked in the decoder since there could be an operation in progress that sets the privilege level to the appropriate level.
### Scoreboard
The scoreboard's purpose was described in detail in the architecture section.
![Scoreboad](./fig/scoreboard.png)
The field functional unit can be of the following types:
- CSR: Modify the CSR register using OP, OP can be of type:
+ MRET (check the current privilege level against the mret instruction, are we allowed to execute it?)
+ SRET (same as above but with sret)
+ URET (same as above but with uret)
+ ECALL (make an environment call)
+ WRITE (writing a CSR, we need to flush the whole pipeline after a write)
+ READ (we can simply continue with the execution, the worst that could happen is an access fault if we do not have the right privilege level)
+ SET (atomic set, flush the whole pipeline)
+ CLEAR (atomic clear, flush the whole pipeline)
- ALU: Use the ALU to perform OP
+ ADD, SUB, etc. all arithmetic instructions. ALU always writes to the register file
- LSU: Use the LSU to perform OP
+ LD, SD, LBU, etc. Loads are writing to the register file, stores are committed as soon as the store address and store data is known.
- MULT: Use the Multiplier to perform OP
+ MULT, DIV, etc. all multiplier instructions are writing to the register file.
The scoreboard also contains all exception information which occurred during execution. In particular those fields are:
- exception cause
- additional information like illegal instruction and faulting address
- if it is valid or not
If an exception already occurred in IF or ID the corresponding instruction is not executed anymore. Additionally a valid exception is never overwritten. For example an instruction fetch access fault is never overwritten by a load store access fault.
### Issue
The issue stage itself is not a real stage in the sense that it is pipelined, it is still part of the decode stage. The purpose of the issue stage is to find out whether we can issue the current top of the scoreboard to one of the functional units. It therefore takes into account whether the any other FU has or is going to write the destination register of the current instruction and whether or not the necessary functional unit is currently busy. If the FU is not busy and there are no dependencies we can issue the instruction to the execute stage.
### Compressed Decoder
The compressed decoders purpose is to expand a compressed instruction (16 bit) to its 32 bit equivalent.
## Execute Stage (EX)
### Read Operands
The read operands stage is still part of the scoreboard but conceptually lies at the boundary between ID and EX. The operands where read in the previous cycle but we can still use forwarding to get the source operands from either:
1. Register file
2. Scoreboard (Forwarding)
4. Immediate field
The scoreboard and forwarding are mutually exclusive. The selection logic is a classical priority selection giving precedence to results form the scoreboard/FU over the register file.
To obtain the right register value we need to poll the scoreboard for both source operands.
### Write-Back
The write-back stage writes the results from the FU back to the scoreboard. They are committed in-order in the next stage.
## Commit Stage (Commit)
The commit stage is the single commit point in the whole architecture. Everything prior to this stage was just computed in a temporary fashion. This is also the only point where an exception can occur.
The commit stage is entirely decoupled from the rest of the pipeline. It has access to the scoreboard which issues finished instructions in-order to the commit stage.
### CSR Register File
The CSR register file contains all registers which are not directly related to arithmetic instructions. It contains the following registers supervisor registers:
| **Register** | **Address** | **Description** |
|--------------|-------------|-----------------------------------------------------------|
| sstatus | 0x100 | Supervisor status register |
| sedeleg | 0x102 | Supervisor exception delegation register (maybe external) |
| sideleg | 0x103 | Supervisor interrupt delegation register (maybe external) |
| sie | 0x104 | Supervisor interrupt-enable register (maybe external) |
| stvec | 0x105 | Supervisor trap handler base address |
| sscratch | 0x140 | Scratch register for supervisor trap handler |
| sepc | 0x141 | Supervisor exception program counter |
| scause | 0x142 | Supervisor trap cause |
| stval | 0x143 | Supervisor bad address or instruction |
| sip | 0x144 | Supervisor interrupt pending (maybe external) |
| sptbr | 0x180 | Page-table base register |
| tlbflush | ? | Flush TLB |
| cflush | ? | Flush Cache |
And the following machine mode CSR registers:
| **Register** | **Address** | **Description** |
| ------------------- | -------------- | ------------------------------------------------------ |
| mvendorid | 0xF11 | Vendor ID |
| marchid | 0xF12 | Architecture ID |
| mimpid | 0xF13 | Implementation ID |
| mhartid | 0xF14 | Hardware thread ID |
| mstatus | 0x300 | Machine status register |
| medeleg | 0x302 | Machine exception delegation register (maybe external) |
| mideleg | 0x303 | Machine interrupt delegation register (maybe external) |
| mie | 0x304 | Machine interrupt-enable register (maybe external) |
| mtvec | 0x305 | Machine trap handler base address |
| mscratch | 0x340 | Machine register for machine trap handler |
| mepc | 0x341 | Machine exception program counter |
| mcause | 0x342 | Machine trap cause |
| mtval | 0x343 | Machine bad address or instruction |
| mip | 0x344 | Machine interrupt pending (maybe external) |
| mcycle | 0xB00 | Machine cycle counter |
| minstret | 0xB02 | Machine instruction-retired counter |
| Performance Counter | 0xB03 -- 0xB9F | Machine performance-monitoring counter |
We need to be careful when altering some of the register. Some of those registers would potentially lead to different behavior (e.g.: mstatus by enabling address translation).
## MMU
## LSU
### Memory Arbiter
The memory arbiter's purpose is to arbitrate the memory accesses coming/going from/to the PTW, store queue and load requests. On a flush it needs to wait for all previous transactions to return. We currently do not have another way to squash load and stores that already went into the memory hierarchy.
### Store Queue
The store queue keeps track of all stores. It has two entries: One is for already committed instructions and one is for outstanding instructions. On a flush only the instruction which has the already committed instruction saved persists its data. But on a flush it can't request further to the memory since this could potentially stall us indefinitely because of the property of the memory arbiter (see above).
The store queue works with physical addresses only. At the time when they are committed the translation is correct. Furthermore the store queue directly outputs the address and value of the instruction it is going to commit since any subsequent store also needs to check for the address.
# Cache
## Interface
```verilog
input logic clk,
input logic rst_n,
// Data Port (TLB or CORE )
input logic [DATA_WIDTH-1:0] data_wdata_i,
input logic data_req_i,
input logic [BE_WIDTH-1:0] data_be_i,
input logic data_we_i,
input logic [ADDR_WIDTH-1:0] data_add_i,
input logic data_abort_i,
input logic [ID_WIDTH-1:0] data_ID_i,
output logic data_gnt_o,
output logic [DATA_WIDTH-1:0] data_r_rdata_o,
output logic data_r_valid_o,
input logic [ID_WIDTH-1:0] data_r_ID_o,
input logic data_r_gnt_i,
//Service Port (32bit)
input logic conf_req_i,
input logic [31:0] conf_addr_i,
input logic conf_wen_i,
input logic [31:0] conf_wdata_i,
input logic [3:0] conf_be_i,
input logic [PE_ID_WIDTH-1:0] conf_id_i,
output logic conf_gnt_o,
output logic conf_r_valid_o,
output logic conf_r_opc_o,
output logic [PE_ID_WIDTH-1:0] conf_r_id_o,
output logic [31:0] conf_r_rdata_o,
```

4742
docs/old_doc/fig/ariane_overview.pdf
View file

File diff suppressed because one or more lines are too long

BIN
docs/old_doc/fig/ariane_overview.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 152 KiB

414
docs/old_doc/fig/ld_pipeline_diagram.svg
View file

@ -1,414 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 18.1.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="Ebene_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
viewBox="0 0 841.9 595.3" enable-background="new 0 0 841.9 595.3" xml:space="preserve">
<text transform="matrix(1 0 0 1 73.5869 71.7238)" font-family="'Arial-BoldMT'" font-size="11.9996">ADDI </text>
<text transform="matrix(1 0 0 1 106.2856 71.7238)" font-family="'ArialMT'" font-size="11.9996">x2, 200</text>
<text transform="matrix(1 0 0 1 73.5869 86.1233)" font-family="'Arial-BoldMT'" font-size="11.9996">LD </text>
<text transform="matrix(1 0 0 1 106.2856 86.1233)" font-family="'ArialMT'" font-size="11.9996">x1, 0(x2)</text>
<text transform="matrix(1 0 0 1 73.5869 100.5227)" font-family="'Arial-BoldMT'" font-size="11.9996">ADDI </text>
<text transform="matrix(1 0 0 1 106.2856 100.5227)" font-family="'ArialMT'" font-size="11.9996">x3, 10</text>
<text transform="matrix(1 0 0 1 73.5869 114.9226)" font-family="'Arial-BoldMT'" font-size="11.9996">ADD </text>
<text transform="matrix(1 0 0 1 106.2856 114.9226)" font-family="'ArialMT'" font-size="11.9996">x4, x1, x3 </text>
<g>
<rect x="325.2" y="75.9" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 333.3423 85.2322)" font-family="'ArialMT'" font-size="7.9997">EX2</text>
</g>
<g>
<g>
<rect x="167.7" y="61.8" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 169.25 71.0896)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="199.2" y="61.8" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 211.377 71.0891)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="230.7" y="61.8" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 242.4375 71.8903)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="262" y="61.8" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 270.1816 71.0891)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="293.5" y="61.8" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 299.4727 71.0891)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
</g>
<g>
<line fill="none" x1="199.2" y1="42.8" x2="199.2" y2="314.8"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="199.2" y1="42.8" x2="199.2" y2="45.3"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="199.2" y1="50.3" x2="199.2" y2="309.8"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="199.2" y1="312.3" x2="199.2" y2="314.8"/>
</g>
</g>
<g>
<line fill="none" x1="513.9" y1="47.4" x2="513.9" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="513.9" y1="47.4" x2="513.9" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="513.9" y1="54.9" x2="513.9" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="513.9" y1="317" x2="513.9" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="482.4" y1="47.4" x2="482.4" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="482.4" y1="47.4" x2="482.4" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="482.4" y1="54.9" x2="482.4" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="482.4" y1="317" x2="482.4" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="450.9" y1="47.4" x2="450.9" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="450.9" y1="47.4" x2="450.9" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="450.9" y1="54.9" x2="450.9" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="450.9" y1="317" x2="450.9" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="419.5" y1="47.4" x2="419.5" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="419.5" y1="47.4" x2="419.5" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="419.5" y1="54.9" x2="419.5" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="419.5" y1="317" x2="419.5" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="388" y1="47.4" x2="388" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="388" y1="47.4" x2="388" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="388" y1="54.9" x2="388" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="388" y1="317" x2="388" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="356.5" y1="47.4" x2="356.5" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="356.5" y1="47.4" x2="356.5" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="356.5" y1="54.9" x2="356.5" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="356.5" y1="317" x2="356.5" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="325" y1="47.4" x2="325" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="325" y1="47.4" x2="325" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="325" y1="54.9" x2="325" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="325" y1="317" x2="325" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="293.6" y1="47.4" x2="293.6" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="293.6" y1="47.4" x2="293.6" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="293.6" y1="54.9" x2="293.6" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="293.6" y1="317" x2="293.6" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="262.1" y1="47.4" x2="262.1" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="262.1" y1="47.4" x2="262.1" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="262.1" y1="54.9" x2="262.1" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="262.1" y1="317" x2="262.1" y2="319.5"/>
</g>
</g>
<g>
<line fill="none" x1="230.6" y1="47.4" x2="230.6" y2="319.5"/>
<g>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="230.6" y1="47.4" x2="230.6" y2="49.9"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" stroke-dasharray="5.0387,5.0387" x1="230.6" y1="54.9" x2="230.6" y2="314.4"/>
<line fill="none" stroke="#000000" stroke-width="0.5" stroke-miterlimit="10" x1="230.6" y1="317" x2="230.6" y2="319.5"/>
</g>
</g>
<g>
<rect x="293.5" y="164.3" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="63" height="14.4"/>
<text transform="matrix(1 0 0 1 317.4888 173.6374)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<text transform="matrix(1 0 0 1 538.5186 90.2898)" font-family="'Arial-ItalicMT'" font-size="9.9997">Two cycle memory access. The cache is </text>
<text transform="matrix(1 0 0 1 538.5186 102.2898)" font-family="'Arial-ItalicMT'" font-size="9.9997">physically indexed and virtually tagged.</text>
<text transform="matrix(1 0 0 1 538.5186 178.8156)" font-family="'Arial-ItalicMT'" font-size="9.9997">Multicycle memory access. Address translation</text>
<text transform="matrix(1 0 0 1 538.5186 190.8152)" font-family="'Arial-ItalicMT'" font-size="9.9997">is perforemd in the same cycle.</text>
<text transform="matrix(1 0 0 1 538.5186 261.1848)" font-family="'Arial-ItalicMT'" font-size="9.9997">Same as option one but the addressing of the </text>
<text transform="matrix(1 0 0 1 538.5186 273.1843)" font-family="'Arial-ItalicMT'" font-size="9.9997">cache needs to be delayed until the whole address</text>
<text transform="matrix(1 0 0 1 538.5186 285.1838)" font-family="'Arial-ItalicMT'" font-size="9.9997">has successfully been translated.</text>
<text transform="matrix(1 0 0 1 180.6938 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">1</text>
<text transform="matrix(1 0 0 1 211.998 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">2</text>
<text transform="matrix(1 0 0 1 243.5039 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">3</text>
<text transform="matrix(1 0 0 1 274.8086 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">4</text>
<text transform="matrix(1 0 0 1 306.7168 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">5</text>
<text transform="matrix(1 0 0 1 338.0215 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">6</text>
<text transform="matrix(1 0 0 1 369.3257 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">7</text>
<text transform="matrix(1 0 0 1 400.6304 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">8</text>
<text transform="matrix(1 0 0 1 432.5586 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">9</text>
<text transform="matrix(1 0 0 1 461.083 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">10</text>
<text transform="matrix(1 0 0 1 496.5762 46.7029)" fill="#808080" font-family="'ArialMT'" font-size="9.9997">11</text>
<text transform="matrix(1 0 0 1 73.5869 157.241)" font-family="'Arial-BoldMT'" font-size="11.9996">ADDI </text>
<text transform="matrix(1 0 0 1 106.2856 157.241)" font-family="'ArialMT'" font-size="11.9996">x2, 200</text>
<text transform="matrix(1 0 0 1 73.5869 171.6404)" font-family="'Arial-BoldMT'" font-size="11.9996">LD </text>
<text transform="matrix(1 0 0 1 106.2856 171.6404)" font-family="'ArialMT'" font-size="11.9996">x1, 0(x2)</text>
<text transform="matrix(1 0 0 1 73.5869 186.0403)" font-family="'Arial-BoldMT'" font-size="11.9996">ADDI </text>
<text transform="matrix(1 0 0 1 106.2856 186.0403)" font-family="'ArialMT'" font-size="11.9996">x3, 10</text>
<text transform="matrix(1 0 0 1 73.5869 200.4397)" font-family="'Arial-BoldMT'" font-size="11.9996">ADD </text>
<text transform="matrix(1 0 0 1 106.2856 200.4397)" font-family="'ArialMT'" font-size="11.9996">x4, x1, x3 </text>
<text transform="matrix(1 0 0 1 73.5869 242.5451)" font-family="'Arial-BoldMT'" font-size="11.9996">ADDI </text>
<text transform="matrix(1 0 0 1 106.2856 242.5451)" font-family="'ArialMT'" font-size="11.9996">x2, 200</text>
<text transform="matrix(1 0 0 1 73.5869 256.9445)" font-family="'Arial-BoldMT'" font-size="11.9996">LD </text>
<text transform="matrix(1 0 0 1 106.2856 256.9445)" font-family="'ArialMT'" font-size="11.9996">x1, 0(x2)</text>
<text transform="matrix(1 0 0 1 73.5869 271.344)" font-family="'Arial-BoldMT'" font-size="11.9996">ADDI </text>
<text transform="matrix(1 0 0 1 106.2856 271.344)" font-family="'ArialMT'" font-size="11.9996">x3, 10</text>
<text transform="matrix(1 0 0 1 73.5869 285.7434)" font-family="'Arial-BoldMT'" font-size="11.9996">ADD </text>
<text transform="matrix(1 0 0 1 106.2856 285.7434)" font-family="'ArialMT'" font-size="11.9996">x4, x1, x3 </text>
<g>
<g>
<rect x="199.1" y="75.9" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 200.6792 85.2322)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="230.6" y="75.9" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 242.8062 85.2322)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="262.1" y="75.9" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 273.8667 86.0329)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
</g>
<g>
<rect x="230.5" y="90.3" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 232.0361 99.6155)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="262" y="90.3" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 274.1631 99.615)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="293.5" y="90.3" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 305.2236 100.4162)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="262" y="104.7" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 263.4893 113.9983)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="293.4" y="104.7" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 305.6162 113.9983)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="324.9" y="104.7" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 336.6768 114.7995)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="356.5" y="75.9" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 362.4316 85.2322)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="388" y="90.3" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 393.9575 99.615)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="419.6" y="104.7" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 425.5645 113.9983)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="293.4" y="75.9" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 301.6104 85.2322)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="325" y="90.3" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 333.1406 99.615)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="356.5" y="104.7" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 364.6465 113.9983)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<g>
<rect x="167.7" y="150.2" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 169.2759 159.4948)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="199.2" y="150.2" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 211.4033 159.4948)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="230.7" y="150.2" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 242.4639 160.2956)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="262" y="150.2" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 270.2075 159.4948)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="293.5" y="150.2" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 299.4985 159.4948)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
</g>
<g>
<g>
<rect x="199.2" y="164.3" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 200.7051 173.6374)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="230.6" y="164.3" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 242.8325 173.6374)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="262.1" y="164.3" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 273.8926 174.4387)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
</g>
<g>
<rect x="230.5" y="178.7" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 232.062 188.0207)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="262" y="178.7" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 274.1895 188.0202)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="293.5" y="178.7" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 305.2495 188.8215)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="262" y="193.1" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 263.5151 202.404)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="293.4" y="193.1" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 305.6426 202.4035)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="325" y="193.1" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 336.7026 203.2048)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="325" y="178.7" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 333.167 188.0202)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="419.5" y="193.1" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 427.6777 202.4035)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="419.2" y="164.4" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 425.1416 173.758)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="450.9" y="178.7" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 456.8691 188.0202)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="482.4" y="193.1" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 488.375 202.4035)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="356.5" y="164.3" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="63" height="14.4"/>
<text transform="matrix(1 0 0 1 380.4199 173.6374)" font-family="'ArialMT'" font-size="7.9997">EX2</text>
</g>
<g>
<rect x="325.2" y="246.7" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 333.4326 256.007)" font-family="'ArialMT'" font-size="7.9997">EX2</text>
</g>
<g>
<g>
<rect x="167.8" y="232.5" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 169.3408 241.864)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="199.3" y="232.5" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 211.4678 241.864)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="230.8" y="232.5" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 242.5283 242.6653)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="262.1" y="232.5" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 270.272 241.864)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="293.6" y="232.5" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 299.5635 241.864)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
</g>
<g>
<g>
<rect x="199.2" y="246.7" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 200.77 256.007)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="230.7" y="246.7" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 242.897 256.0066)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="262.2" y="246.7" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 273.9575 256.8078)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
</g>
<g>
<rect x="230.6" y="261.1" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 232.127 270.3899)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="262.1" y="261.1" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 274.2539 270.3899)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="293.6" y="261.1" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 305.3145 271.1906)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="262.1" y="275.5" fill="#FCF8CE" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 263.5801 284.7732)" font-family="'ArialMT'" font-size="7.9997">PCGEN</text>
</g>
<g>
<rect x="293.5" y="275.5" fill="#FECB37" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 305.707 284.7727)" font-family="'ArialMT'" font-size="7.9997">IF</text>
</g>
<g>
<rect x="325" y="275.5" fill="#52A3DB" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 336.7676 285.5739)" font-family="'ArialMT'" font-size="7.9997">ID</text>
</g>
<g>
<rect x="388" y="246.7" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 393.998 256.0066)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="419.6" y="261.1" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 425.5234 270.3899)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="451.2" y="275.5" fill="#BDCCD4" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 457.1309 284.7727)" font-family="'ArialMT'" font-size="7.9997">CMIT</text>
</g>
<g>
<rect x="293.5" y="246.7" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 301.7012 256.0066)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="325" y="261.1" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 333.2314 270.3899)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="387.7" y="275.5" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 395.8506 284.7727)" font-family="'ArialMT'" font-size="7.9997">EX1</text>
</g>
<g>
<rect x="356.5" y="246.7" fill="#7FBB48" stroke="#000000" stroke-miterlimit="10" width="31.5" height="14.4"/>
<text transform="matrix(1 0 0 1 364.6465 256.007)" font-family="'ArialMT'" font-size="7.9997">EX3</text>
</g>
</svg>
Side by side

Before

Width:  |  Height:  |  Size: 25 KiB

3883
docs/old_doc/fig/lsu_blockdiagram.pdf
View file

File diff suppressed because one or more lines are too long

BIN
docs/old_doc/fig/lsu_blockdiagram.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 24 KiB

4124
docs/old_doc/fig/scoreboard.pdf
View file

File diff suppressed because one or more lines are too long

BIN
docs/old_doc/fig/scoreboard.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 16 KiB

7061
docs/old_doc/fig/uvm_fu_tb.ai
View file

File diff suppressed because one or more lines are too long

BIN
docs/old_doc/fig/uvm_fu_tb.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 22 KiB

18
docs/old_doc/ideas.md
View file

@ -1,18 +0,0 @@
# Ideas
## Dual Issue Implementation
By widening the fetch interface to 64bit we could theoretically fetch two and more instructions with a single fetch. Doubling the (compressed) decoder would result in a dual issue architecture.
## Power-down Mode
The CSR’s APB interface would allow for storing the CPU state (registers, CSR registers, etc.) to a state retentive memory when the core is in complete power down.
## Input silencing of ALU
## Performance counters
- Miss-predicts
- Mem Arbiter full
- Store Queue full
- Scoreboard full

87
docs/old_doc/index.md
View file

@ -1,87 +0,0 @@
# Ariane RISC-V CPU
This document describes the 5-stage, single issue Ariane CPU which implements the 64bit RISC-V instruction set. It is conformant to the I,M and C extensions as specified in Volume I: User-Level ISA V2.1 as well as the draft privilege extension 1.10. It implements three privilege levels M, S, U to fully support a Unix-like operating system.
## Scope and Purpose
The purpose of the core is to run a full OS at reasonable speed and IPC. To achieve the necessary speed (targeting 1.6ns cycle time in UMC65) the core features a 5-stage pipelined design. In order to increase the IPC the CPU features a scoreboarding technique that should hide the rather long latency to the data RAM (cache) by issuing independent instructions.
The instruction RAM has (or L1 instruction cache) an access latency of 1 cycle on a hit, while accesses to the data RAM (or L1 data cache) have a longer latency of 2 cycles on a hit.
![Ariane Block Diagram](fig/ariane_overview.png)
## Planned Limitations
Ariane is not going to support floating points and atomic operations. No user mode interrupts are supported as well.
## Instructions
- Integer computation (immediate-register): ADDI/SLTI[U], ANDI/ORI/XORI, SLLI/SRLI/SRAI
- Integer computation (register-register): ADD/SLT/SLTU, AND/OR/XOR, SLL/SRL, SUB/SRA, MUL/DIV/REM
- Operations on PC (PC-immediate): LUI, AUIPC
- Control Transfer: J, JAL, JALR
- Conditional Branches: BEQ/BNE, BLT[U], BGE[U]
- Load and Stores
- Memory instructions: FENCE.I (flush D$ and I$, kill pipeline), SFENCE.VM (flush TLB)
- System Instructions: CSRR[..], RDCYCLE, RDTIME, RDINSTRET, ECALL, EBREAK, WFI, MRET/SRET/URET
## ToDo Section:
Things that need to be done (in no particular order):
<!-- - Scoreboard testbench -->
- Decode
- Branch prediction, detailed block diagram (support in scoreboard)
- Processor front-end, detailed design
- Commit stage, detailed design (especially concerning CSR register, APB interface)
- LSU detailed design
- Debug
- Instruction tracer
- Controller
## File Headers
For the time being everything is restricted with all rights reserved:
```
// Author: <name>, ETH Zurich
// Date: <date>
// Description: Lorem Impsum...
//
// Copyright (C) 2017 ETH Zurich, University of Bologna
// All rights reserved.
//
// This code is under development and not yet released to the public.
// Until it is released, the code is under the copyright of ETH Zurich and
// the University of Bologna, and may contain confidential and/or unpublished
// work. Any reuse/redistribution is strictly forbidden without written
// permission from ETH Zurich.
//
// Bug fixes and contributions will eventually be released under the
// SolderPad open hardware license in the context of the PULP platform
// (http://www.pulp-platform.org), under the copyright of ETH Zurich and the
// University of Bologna.
//
```
# Timing Diagrams
The documentation scheme allows you to insert timing diagrams written in [WaveJSON](https://github.com/drom/wavedrom/wiki/WaveJSON). To do so:
Insert [WaveJSON](https://github.com/drom/wavedrom/wiki/WaveJSON) source inside HTML ``<body>`` wrapped with ``<script>`` tag:
```html
<script type="WaveDrom">
{ signal : [
{ name: "clk", wave: "p......" },
{ name: "bus", wave: "x.34.5x", data: "head body tail" },
{ name: "wire", wave: "0.1..0." },
]}
</script>
```
<script type="WaveDrom">
{ signal : [
{ name: "clk", wave: "p......" },
{ name: "bus", wave: "x.34.5x", data: "head body tail" },
{ name: "wire", wave: "0.1..0." },
]}
</script>

3
docs/old_doc/js/ariane.js
View file

@ -1,3 +0,0 @@
$('body').ready(function() {
WaveDrom.ProcessAll();
});

1
docs/old_doc/js/default.js
View file

File diff suppressed because one or more lines are too long

2
docs/old_doc/js/wavedrom.min.js vendored
View file

File diff suppressed because one or more lines are too long

52
docs/old_doc/synthesis.md
View file

@ -1,52 +0,0 @@
# Synthesis Results
## UMC65 WC
### Scoreboard
Synthesized @ 0.4 ns, worst case, UMC65:
| **Type** | **Flip-flop based, 8 entries** | **Latch based, 8 entries** | **Flip-flop based, 4 entries** | **Latch based, 4 entries** |
|---------------|--------------------------------|----------------------------|--------------------------------|----------------------------|
| Sequential | 18125 | 11620 | 12143 | 6649 |
| Combinatorial | 27333 | 20821 | 19717 | 9438 |
| Buffer | 1863 | 1000 | 2694 | 594 |
| **Total** | **45568 (~32 kGE)** | **32441 (~23 kGE)** | **31861 (~23 kGE)** | **16088 (~ 11 kGE)** |
### ALU
| **Type** | **1.6 ns, worst case, UMC65** |
|---------------|-------------------------------|
| Sequential | 0 |
| Combinatorial | 9019 |
| Buffer | 582 |
| **Total** | **9019 (~6.4 kGE)** |
### BTB
Synthesized @ 1.1 ns, worst case, UMC65
| **Type** | **64 entries** | **32 entries** |
|---------------|---------------------|---------------------|
| Sequential | 4288 | 2113 |
| Combinatorial | 7901 | 5923 |
| Buffer | 342 | 2276 |
| **Total** | **55490 (~39 kGE)** | **29327 (~20 kGE)** |
### TLB
Synthesized @ 0.6 ns, worst case, UMC65
| **Type** | **32 entries** | |
|---------------|---------------------|---|
| Sequential | 14185 | |
| Combinatorial | 18607 | |
| Buffer | 2642 | |
| **Total** | **32793 (~23 kGE)** | |
The address generation unit has a delay of 0.4 ns (WC).
## STM28 FDSOI

67
docs/old_doc/timing_diagrams.md
View file

@ -92,71 +92,6 @@ Aborted D$ request (with a new back to back request):
]}
</script>
<!-- ## LSU
- **Multicycle D$ access**: Making the path to the cache a multicycle path. This will give enough headroom for the memories to propagate their output.
<script type="WaveDrom">
{signal: [
{name: 'clk', wave: 'P.................'},
{name: 'lsu_clk', wave: 'HlHlHlHlHlHlHlHlHl'},
{name: 'operator', wave: 'x.2.3.4.x.5.x.....', data: ['ST', 'LD', 'ST', 'LD']},
{name: 'vaddr', wave: 'x.2.3.4.x.5.x.....', data: ['vaddr1', 'vaddr2', 'vaddr3', 'vaddr4']},
{name: 'valid', wave: '0.1.....0.1.0.....'},
{name: 'ready', wave: '1.....0...1.0...1.'},
{name: 'paddr', wave: 'x.2.3.x.4.x.5.x...', data: ['paddr1', 'paddr3', 'paddr3', 'paddr4']},
{name: 'translation_valid', wave: '0.1...0.1.0.1.0...'},
{name: 'data_addr', wave: 'x.2.3.x.4...5.x...', data: ['paddr1', 'paddr3', 'paddr3', 'paddr4']},
{name: 'data_wdata', wave: 'x.2.x...4...x.....', data: ['wdata1', 'wdata2', 'wdata3']},
{name: 'data_req', wave: '0.1...0.1.....0...'},
{name: 'data_gnt', wave: '0.1...0...1...0...'},
{name: 'data_rvalid', wave: '0...1...0...1.0.1.'},
{name: 'data_rdata', wave: 'x.....3.x.......5.', data: ['rdata2', 'rdata4']},
{name: 'data_we', wave: '0.1.0...1...0.....'},
{name: 'data_be', wave: 'x.2.3.x.4...5.x...', data: ['be1', 'be2', 'be3', 'be4']}
]}
</script>
- **Extra MMU stage**: Splitting the path after address generation. With the headroom gained we could deskew the ld/st path again.
<script type="WaveDrom">
{signal: [
{name: 'clk', wave: 'P.............'},
{name: 'operator', wave: 'x.234x.5x.....', data: ['ST', 'LD', 'ST', 'LD']},
{name: 'vaddr', wave: 'x.234x.5x.....', data: ['va1', 'va2', 'va3', 'va4']},
{name: 'valid', wave: '0.1..0.10.....'},
{name: 'ready', wave: '1....0.10.1...'},
{name: 'paddr', wave: 'x..23x.4x.5x..', data: ['pa1', 'pa3', 'pa3', 'pa4']},
{name: 'translation_valid', wave: '0..1.0.10.10..'},
{name: 'data_addr', wave: 'x..23x.4x.5x..', data: ['pa1', 'pa3', 'pa3', 'pa4']},
{name: 'data_wdata', wave: 'x..2x..4x.....', data: ['wd1', 'wd2', 'wd3']},
{name: 'data_req', wave: '0..1.0.10.....'},
{name: 'data_gnt', wave: '0..1.0.10.10..'},
{name: 'data_rvalid', wave: '0...1.0.10..10'},
{name: 'data_rdata', wave: 'x....3x.....5x', data: ['rd2', 'rd4']},
{name: 'data_we', wave: '0..10..10.....'},
{name: 'data_be', wave: 'x..23x.4x.5x..', data: ['be1', 'be2', 'be3', 'be4']}
]}
</script>
- Making the D$ **virtually indexed and physically tagged**. This will hide the latency of address translation.
<script type="WaveDrom">
{signal: [
{name: 'clk', wave: 'P.............'},
{name: 'operator', wave: 'x.234x.5x.....', data: ['ST', 'LD', 'ST', 'LD']},
{name: 'vaddr', wave: 'x.234x.5x.....', data: ['va1', 'va2', 'va3', 'va4']},
{name: 'valid', wave: '0.1..0.10.....'},
{name: 'ready', wave: '1....0.10.1...'},
{name: 'paddr', wave: 'x..23x.4x.5x..', data: ['pa1', 'pa3', 'pa3', 'pa4']},
{name: 'translation_valid', wave: '0..1.0.10.10..'},
{name: 'data_addr', wave: 'x..23x.4x.5x..', data: ['pa1', 'pa3', 'pa3', 'pa4']},
{name: 'data_wdata', wave: 'x..2x..4x.....', data: ['wd1', 'wd2', 'wd3']},
{name: 'data_req', wave: '0.1.0..10.....'},
{name: 'data_gnt', wave: '0.1.0..10.10..'},
{name: 'data_rvalid', wave: '0..1.0..10.10.'},
{name: 'data_rdata', wave: 'x...3x.....5x.', data: ['rd2', 'rd4']},
{name: 'data_we', wave: '0..10..10.....'},
{name: 'data_be', wave: 'x..23x.4x.5x..', data: ['be1', 'be2', 'be3', 'be4']}
]}
</script> -->
## Functional Unit
<script type="WaveDrom">
{signal: [
@ -176,4 +111,4 @@ Aborted D$ request (with a new back to back request):
## LSU
![Ariane Block Diagram](fig/ld_pipeline_diagram.svg)
![Ariane Block Diagram](fig/ld_pipeline_diagram.svg)