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

📝 Slightly update LSU timing diagrams

Browse source
This commit is contained in:
Florian Zaruba 2017-05-29 16:41:08 +02:00
parent 809f7f05b5
commit be9d35da29
2 changed files with 13 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/architecture.md
View file

@ -113,6 +113,6 @@ The LSU of the core takes care of accessing the data memory. Load and stores on
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 take 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.
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.

24
docs/timing_diagrams.md
View file

@ -23,18 +23,18 @@ Basic D$ Memory Request:
D$ Miss followed by another request (a hit in that case):
<script type="WaveDrom">
{signal: [
{name: 'clk', wave: 'P....|.........'},
{name: 'data_index', wave: 'x.234|....x....', data: ['index', 'index', 'index']},
{name: 'data_tag', wave: 'x..2x|....34x..', data: ['tag', 'tag', 'tag']},
{name: 'data_wdata', wave: 'x.234|....x....', data: ['data', 'data', 'data']},
{name: 'data_req', wave: '0.1..|....0....'},
{name: 'data_gnt', wave: '0.1.0|...10....'},
{name: 'tag_valid', wave: '0..10|....1.0..'},
{name: 'kill_req', wave: '0....|.........'},
{name: 'data_rvalid', wave: '0....|...1..0..'},
{name: 'data_rdata', wave: 'x....|...234x..', data: ['rdata', 'rdata', 'rdata']},
{name: 'data_we', wave: 'x.234|....x....', data: ['we', 'we', 'we']},
{name: 'data_be', wave: 'x.234|....x....', data: ['be', 'be', 'be']}
{name: 'clk', wave: 'P.....|.........'},
{name: 'data_index', wave: 'x.234.|....x....', data: ['index', 'index', 'index']},
{name: 'data_tag', wave: 'x..23x|....4x...', data: ['tag', 'tag', 'tag']},
{name: 'data_wdata', wave: 'x.234.|....x....', data: ['data', 'data', 'data']},
{name: 'data_req', wave: '0.1...|....0....'},
{name: 'data_gnt', wave: '0.1.0.|...10....'},
{name: 'tag_valid', wave: '0..1.0|0...10...'},
{name: 'kill_req', wave: '0.....|.........'},
{name: 'data_rvalid', wave: '0.....|..1..0...'},
{name: 'data_rdata', wave: 'x.....|..234x...', data: ['rdata', 'rdata', 'rdata']},
{name: 'data_we', wave: 'x.234.|....x....', data: ['we', 'we', 'we']},
{name: 'data_be', wave: 'x.234.|....x....', data: ['be', 'be', 'be']}
]}
</script>