RE: [openrisc] Re: JTAG Proxy

["Igor Mohor" <igorm@opencores.org>]

> -----Original Message-----
> From: owner-openrisc@opencores.org
> [mailto:owner-openrisc@opencores.org]On Behalf Of Marko Mlinar
> Sent: 25. september 2002 8:54
> To: Luis Santos
> Cc: openrisc@opencores.org
> Subject: [openrisc] Re: JTAG Proxy
>
>
> On Tuesday 24 September 2002 10:07, Luis Santos wrote:
> > Hi Marko,
> >
> >
> >
> > I'm studying the OR1K and its current implementation: or1200. I'm
> > especially interested on the debugging support it offers. After
> reading the
> > source code of the JTAG Proxy you wrote to GDB I've two questions:
> >
> >
> >
> > 1- For now or1200 doesn't have debugging support as described
> in OR1K. When
> > this support exists how GDB, through the JTAG port (and JTAG proxy),
> > becomes notified that the code reaches a given breakpoint and
> the processor
> > becomes stalled, waiting for debugger activity?  This doesn't
> seem feasible
> > using the protocol currently implemented! As far as I can imagine, to
> > achieve this we need to:
> >  a) Route the StallStat signal to the parallel port and continuously
> > watching it
> this is exactly what we are doing. Igor's debug interface has
> special bit in
> MODER, if I am not mistaken, where you can stall/unstall RISC.
> E.g. you can
> also reset RISC there.

No, It is RISCOP register.


>
> >  b) Change a little the protocol between GDB and the JTAG Proxy
> to inform
> > the debugger when the OR is stalled.
> >
> > Comment this problem/solution scenario please.
> >
> >
> >
> > 2- Is the StallStat (from the RISC Debug Interface) signal
> already present
> > at the parallel port in the Xess binaries that OpenCores is providing?
> >
> >   - If not ... is it very hard to do? I'm not a Verilog programmer...
> see above.
> It is true however that not all debugging capabilities are currently
> available, but basic capabilities are sufficient for almost everyone.
> The only piece missing right now is matchpoint part of or1k architecture.
>
> > 2- Why do you always read the registers twice (jtag_read_reg())?
> The reson is debug I/F. First time you send request, then you read data.
> If data is not available for next time either, one bit is intentionally
> inverted to fail CRC; host should retry then.
> It could not be done otherwise, due to scan chains. See debug I/F
> doc for more
> info.
>
> > 3- When you contact the scan chains through the parallel port
> you read the
> > vector from TDO only after completely write the full input
> vector on TDI.
> > As far as I know the output bits from TDO becomes available at the same
> > time we shit data in through TDI. Does the response become
> buffered in the
> > operating system, so you don't lose it? How this really
> happens? Could you
> > also use the same strategy to shift-in/shift-out 1000 bits?
> For details you should look at jp1.c source (search the cvs,
> don't know the
> exact location, maybe or1k/jtag), but basically you just set what
> you want to
> write to TDI, generate clock and read from TDI.
>
> You are so suspicious -- you should know that these things
> actually work ;)
>
> > Thanks for your time and care,
> >
> >
> >
> >     Luís Santos
> >
> >
> >
> >
> > Luís Eduardo Faria dos Santos-------------------------- lsantos@isec.pt
> > Telf. (ext.): +351 239.790353----------------------- (Gabinete 22): 3036
> >    ___________________________________________
> >      Departamento de Engenharia Informática e de Sistemas
> >      Instituto Superior de Engenharia de Coimbra
> >      Quinta da Nora - Apartado 10057
> >      3031-601 Coimbra
> >      Portugal
>
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml