Re: [openrisc] Address pipeline during exception...

["Damjan Lampret" <lampret@opencores.org>]

> Well, I got the impression from the way the simulator

UART clock can be different. In fact it is better that is simulated as
different clock since this is most likely to be the case in real system.

>
> DIR register:
>
> *) At what point is the instruction injected into the core?
> I have made the following assumption in the simulator:
> The register can be written by the debug interface at
> any time. If the CPU is currently stalled, then the
> instruction will be executed immediately. If the CPU
> is running, then the instruction will be executed as
> soon as the debug interface stalls the CPU. How
> close is this to the actual implementation?

It is pretty similar. Basically when DIR is written, CPU takes that
instruction in next cycle and executes it. Or to be more precise, CPU takes
DIR instruction instead of fetching it from memory (fetched insn is
ignored). CPU doesn't need to be stalled.

>
> *) Executing a jump or branch in the DIR register does
> not implement a delay slot, but instead acts as if the
> jump instruction was injected followed by a nop, and
> both were executed in one go.

Putting branch insn in DIR will result in a delay slot. Instruction in delay
slot is the one that is fetched from memory. As you see it is important to
properly insert insns in DIR. I wouldn't complicate HW too much since DIR is
meant only for special development/debugging and developer of a debugger
should know details how to insert insn properly.

>
> *) In the event that virtual memory is enabled in the cpu
> when it is stalled, and the DIR instruction accesses this
> virtual memory. the mmu fetch will occur on the next
> cycle, whether due to another DIR write or due to
> unstalling the CPU. Note that this could involve a page table miss.

Not sure if I understand. Fetches are done independtly of DIR. And if DIR'ed
insn is a load/store, DTLB miss or DMMU page fault exceptions can occur.

>
> *) All exceptions, including page table miss, will not be
> executed until the CPU is unstalled. Exceptions will be
> disabled immediately however if an exception occurs
> as a result of the DIR instruction.

Exceptions as a result of DIR'ed insns are generated same way as for fetched
insns.

>
> *** These assumptions (about exception generation/
> execiution) are not internally consistent, however they
> seemed to follow what the simulator was doing. I need
> to understand how this actually works in the Or1200
> implementation.. ***

OR1200 is just implementation of OpenRISC 1000. So instead of or1ksim to
simulate OR1200, it should really simulate OpenRISC 1000 architecture (and
not specific implementation). You should not try to simulate OR1200 internal
pipeline. You should simulate OR1K architecture instead with insn safely
assumed to execute in one clock cycle etc. If OR1K architecture manual does
not precisely define how something should be handled, don't rely on OR1200
implementation. Instead OR1K architecture manual should be corrected to
precisely define architecture.

>
> For the DVR[0-7] registers, I have made the following
> assumption:
>
> *) The debug unit will execute the breakpoint exception
> before executing the instruction which has triggered
> the breakpoint.

Only if breakpoint exception is enabled. (Otherwise watchpoint is signaled
to development I/F - but this is invisible to software running on OpenRISC)

>
> *) The exception to this is the breakpoint that is
> configured to watch the data on the data lines of
> a load or store command. In this case, the
> exception will be generated AFTER the load or
> store command has executed.

Yes.

>
> Damjan, I was wondering if you could provide me
> with a description of how the Or1200 pipelining
> has been implemented, so that I can make the
> simulator conform to the Or1200 implementation
> as close as possible.

Please make it conform to OR1K architecture instead. This way future
implementations will be able to use your simulator w/o any changes (in fact
you should not even look at OR1200 spec, just look at OR1K architecture
manual). Again, please add whatever is missing in architecture - I'm sure a
lot of details can be added. Please don't be afraid to add !

> I am interested in the pipelining so I can figure out
> exactly how many commands to execute after an
> exception has been recognized. (i.e. how many

We have precise syncronous exceptions. Meaning if exception is caused by
insn A, following insns B, C etc won't be executed. This is defined by
architecture and is irrelevant to OR1200 or to superscalar implementation
etc. Also async exceptions like interrupts are recognized between executed
insns so insns before execute stage are discarded.

You should look at OR1K architecture or your or1ksim as if it doesn't have
any pipeline. Instruction is fetched, decoded, executed in one complete
cycle.

For more information how exceptions in OpenRISC 1000 are defined, please
have a look at any modern RISC such as MIPS, PowerPC etc. All modern RISCs
have virtually same exception model.

regards,
Damjan