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

[Chris Ziomkowski <chris@asics.ws>]

> Well in real system doesn't matter if CPU takes more
> or less cycles to do an exception since serial port is
> completely independent. So I don't understand
> what is the relation between serial port and CPU's
> exceptions?

Well, I got the impression from the way the simulator
was written, that the UART clock was executing
synchronously with the CPU clock. If that isn't true,
then you are correct, it is like taking a random number
of a random sequence. One is no more random than
the other.

However, if this was a correct implementation of the
UART, then it could make a difference during porting
of the OS. Buffer overflows could occur in one case
that would not occur in the other.

It makes sense to try and keep this as close to the
actual hardware as possible.

On a separate note, I have several more questions
regarding the debug unit:

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?

*) 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.

*) 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.

*) 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.

*** 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.. ***

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.

*) 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.

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.

In order to make this simulator useful as a real
porting tool for OS'es, we need to have it match
the Or1200 implementation. Otherwise, the OS
port on the simulator could be a largely wasted
effort.

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
are currently in the fetch pipeling.) This will probably
be more than 1 in the general scenario.

Thanks for your help,

Chris
chris@asics.ws