[openrisc] Re: [bender] architecture simulator

[Marko Mlinar <markom@opencores.org>]

Chris Ziomkowski wrote:
> 
> You Wrote:
> ----------
> > I think best way for us to build a arch. simulator is to connect
> > gdb to simulator via or1k TAP.
> 
> I don't have a problem modelling the Debug unit of the architecture,
> as this functionality has to be implemented anyway and it isn't
> significantly more difficult to do it according to spec.
> 

> If it turns out that modelling the Debug unit is causing us to
> miss this goal, then I'll abandon it, do whatever is most
> expedient, and come back to it later.

I mentioned this solution, because I believe it is the fastest one.
Truely, you would have to implement risc debug interface (at start
only part of it would be sufficent). As I see it we have two options:
create an architectural simulator with risc debug interface or
add an interface gdb-or1ksim.

Second option would require a week of my work, first one few hours;
you would have same amount of work in both cases, I believe, and we
have to do first option anyway.
Look, what I propose it to have simple interface to gdb:

unsigned int or1ksim_read_reg (int sprno);
void or1ksim_write_reg (int sprno, unsigned int data);
void or1ksim_init ();
void or1ksim_done ();

spr = special purpose register.

JTAG and debug interface are designed in such a way, so that all
functionality can be accesed via SPRs (no counting boundary scan and
wishbone).

These functions asynchroneously read/write from spr registers.
Refer to or1k arch spec, but I believe there are some changes
from last doc (GRP mapping into SPR,...). If you have any question
ask to openrisc. I (or anybody else) will answer you question there. 
> I am hesitant at this time to commit to doing an architectural
> model of a JTAG controller, UART, or memory controller for realism
> sake. I don't have a problem doing this after RTEMS is safely
> underway.
I think we should skip JTAG at this point. We can do it when I am
going to test my remote debugger.

> When you say "Or1k TAP" I'm not exactly sure what you have in mind.
> Can you elaborate? Perhaps we're thinking the same thing.
I think I cleared this point above.

Is this solution OK to you?

I think we should start right away.
We can work in parallel - most of gdb functionality is available,
but not tested (I don't have a simulator :))) so I have hard time
debugging), but basic functionality should work (breakpoints,...).
I will put my latest version of gdb to cvs shortly.

regards,
	Marko