The container always provides outputs that correspond to having read some memory mapped resource. When you're executing, mostly these are not needed, but they do no harm.
The container's inputs control when it writes the mapped resources, as described below.
Name | What You Should Provide To It |
Address | The effective address computed by the current instruction, if it is a load or store. Irrelevant otherwise. |
Write Requested | Should be 1 when the current instruction is a store, 0 otherwise. |
Data In | The contents of the source register on a store. Irrelevant otherwise. |
IsRFE | Should be 1 if the current instruction is an
rfe , 0 otherwise. |
Exception | Should be 1 if an exception/interrupt/trap is being raised during this instruction, 0 otherwise. |
NewEPC | Should be the PC of the currently executing instruction. |
NewCause | If Exception is asserted, should be the exception cause number. Irrelevant otherwise. |
Memory Size | This is attached to the Sz output of the Memory
Interface component in your model (which provides the size of physical memory). |
If your inputs are connected like this, and work, the container will handle setting the EPC, Cause, and Status registers correctly when Exception is asserted. It will also cause the correct mapped resource to be written by store instructions whose effective addresses name such a resource.
Name | Meaning |
WasHandled | The container "owns" memory addresses 0x40000000 through 0x4000003f. If 1, the EffectiveAddress input was for an address in that range. |
HandlerAddrOut | The current value of the Handler Address register. |
StatusOut | The current value of the Status Register. |
BaseRegOut | The current value of the Memory Base Register. |
LengthOut | The current value of the Memory Length Register. |
EPC Out | The current value of the EPC register. |
Read Out | Assuming the EffectiveAddress is a valid mapped resource address, the current value of that resource. Undefined otherwise. |