github-mirrors/cva6
1
0
Fork 0
mirror of https://github.com/openhwgroup/cva6.git synced 2025-04-24 06:07:19 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

📝 Add further clarification on timings

Browse source
This commit is contained in:
Florian Zaruba 2017-05-07 15:05:01 +02:00
parent a752a78cfd
commit ab08a4e228
2 changed files with 83 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

3
docs/architecture.md
View file

@ -69,6 +69,7 @@ The FU are not supposed to have inter-unit dependencies for the moment, e.g.: ev
| 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.
TODO: Details about comparisons and branches.
@ -125,4 +126,4 @@ Table 3 describes the signals that are used by the LSU.
The protocol that is used by the LSU to communicate with a memory works as follows:
The LSU provides a valid address in data_addr_o and sets data_req_o high. The memory then answers with a data_gnt_i 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 address may be changed in the next cycle by the LSU. In addition, the data_wdata_o, data_we_o and data_be_o signals may be changed as it is assumed that the memory has already processed and stored that information. After receiving a grant, the memory answers with a data_rvalid_i set high if data_rdata_i is valid. This may happen one or more cycles after the grant has been received. Note that data_rvalid_i must also be set when a write was performed, although the data_rdata_i has no meaning in this case.
The LSU provides a valid address in data_addr_o and sets data_req_o high. The memory then answers with a data_gnt_i 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 address may be changed in the next cycle by the LSU. In addition, the data_wdata_o, data_we_o and data_be_o signals may be changed as it is assumed that the memory has already processed and stored that information. After receiving a grant, the memory answers with a data_rvalid_i set high if data_rdata_i is valid. This may happen one or more cycles after the grant has been received. Note that data_rvalid_i must also be set when a write was performed, although the data_rdata_i has no meaning in this case. Check the [timing diagrams](timing_diagrams/#memory-interface) for further details.

81
docs/timing_diagrams.md
View file

@ -46,3 +46,84 @@ Fast back to back memory response:
]}
</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: [
{name: 'clk', wave: 'P..........'},
{name: 'operator_i', wave: 'x.2x34x.5x.', data: ['op1', 'op2', 'op3', 'op4']},
{name: 'operand_a_i', wave: 'x.2x34x.5x.', data: ['a1', 'a2', 'a3', 'a4']},
{name: 'operand_b_i', wave: 'x.2x34x.5x.', data: ['b1', 'b2', 'b3', 'b4']},
{name: 'trans_id_i', wave: 'x.2x34x.5x.', data: ['t1', 't2', 't3', 't4']},
{name: 'fu_ready_o', wave: '0..1..0.1..'},
{name: 'fu_valid_i', wave: '0.101.0.10.'},
{name: 'fu_valid_o', wave: '0..1.0.1.0.', data: ['pa1', 'pa3', 'pa3', 'pa4']},
{name: 'fu_trans_id_o', wave: 'x..23x.45x.', data: ['t1', 't2', 't3', 't4']},
{name: 'fu_result_o', wave: 'x..23x.45x.', data: ['r1', 'r2', 'r3', 'r4']},
]}
</script>