mirror of
https://github.com/lowRISC/ibex.git
synced 2025-04-22 21:07:34 -04:00
Clarifications in icache detailed documentation
The new information is: - Branch addresses must be 16-bit aligned. - Explicitly allow top 16 bits of rdata to change when lower 16 bits contain a compressed instruction. - Explicitly allow the core to drop ready without valid. I've also rejigged the layout slightly, improving (I think!) the description of compressed and uncompressed instructions.
This commit is contained in:
parent
97a50d7f12
commit
56883f19ed
1 changed files with 12 additions and 8 deletions
|
@ -219,12 +219,16 @@ If that happens, the cache drops ``instr_req_o`` and stops making any further re
|
|||
Note that it is possible for ``instr_gnt_i`` and ``instr_pmp_err_i`` to be high on the same cycle.
|
||||
In that case, the error signal takes precedence.
|
||||
|
||||
Fetched instructions are returned to the core using ports ``ready_i``, ``valid_o``, ``rdata_o``, ``addr_o`` and ``err_o``.
|
||||
This interface uses ready/valid handshaking in the usual way (a transaction is signalled by ready and valid being high; if valid goes high, it will remain high and the other output signals will remain stable until the transaction goes through).
|
||||
The one exception is if ``branch_i`` is asserted, which will cause ``valid_o`` to de-assert.
|
||||
Fetched instructions are returned to the core using ports ``ready_i``, ``valid_o``, ``rdata_o``, ``addr_o``, ``err_o`` and ``err_plus2_o``.
|
||||
This interface uses a form of ready/valid handshaking.
|
||||
A transaction is signalled by ready and valid being high.
|
||||
If valid goes high, it will remain high and the other output signals will remain stable until the transaction goes through or is cancelled by ``branch_i`` being asserted.
|
||||
There is no constraint on the behaviour of ``ready_i``.
|
||||
|
||||
The 32-bit wide ``rdata_o`` signal contains instruction data fetched from ``addr_o``.
|
||||
If there is a compressed instruction in the lower 16 bits, the upper 16 bits are unconstrained.
|
||||
This allows fetching an instruction from the top 16 bits of a memory, for example.
|
||||
An instruction is either 16 or 32 bits wide (called *compressed* or *uncompressed*, respectively).
|
||||
The width of an instruction can be calculated from its bottom two bits: an instruction is uncompressed if they equal ``2'b11`` and compressed otherwise.
|
||||
If there is a compressed instruction in the lower 16 bits, the upper 16 bits are unconstrained (and may change even after valid has been asserted).
|
||||
The ``err_o`` signal will be high if the instruction fetch failed (either with ``instr_pmp_err_i`` or ``instr_err_i``); in this case ``rdata_o`` is not specified.
|
||||
|
||||
The ``req_i`` signal tells the cache that the core is awake and will start requesting instructions soon.
|
||||
|
@ -236,10 +240,10 @@ A correctly behaving core should not not assert ``ready_i`` when ``req_i`` is lo
|
|||
|
||||
Inside the cache is an address counter.
|
||||
If ``branch_i`` is asserted then the address counter will be set to ``addr_i`` and the next instruction that is passed to the core will be the one fetched from that address.
|
||||
The address is required to be halfword aligned, so ``addr_i[0]`` must be zero.
|
||||
The cache will also start reading into a new prefetch buffer, storing the current contents into the main cache memory or discarding it (see ``icache_enable_i`` below).
|
||||
On other cycles, the address counter will be incremented every time an instruction is passed to the core.
|
||||
This increment depends on the instruction data (visible at ``rdata_o``): if the bottom bits of the instruction are not ``2'b11``, the instruction is considered to be compressed and the address will be incremented by 2.
|
||||
If the bottom bits of the instruction are ``2'b11`` then the instruction is considered to be uncompressed and the address will be incremented by 4.
|
||||
On cycles where ``branch_i`` is not asserted, the address counter will be incremented when an instruction is passed to the core.
|
||||
This increment depends on the instruction data (visible at ``rdata_o``): it will be 2 if the instruction is compressed and 4 otherwise.
|
||||
Since the contents of ``rdata_o`` are not specified if an instruction fetch has caused an error, the core must signal a branch before accepting another instruction after it sees ``err_o``.
|
||||
|
||||
Because a single instruction can span two 32bit memory addresses, an extra signal (``err_plus2_o``) indicates when an error is caused by the second half of an unaligned uncompressed instruction.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue