[Libre-soc-dev] [Libre-soc-bugs] [Bug 503] New: Create new repo for gdb-adaptor program

[Luke Kenneth Casson Leighton]

On Fri, Sep 25, 2020 at 5:26 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Fri, Sep 25, 2020, 09:14 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:

> > completing that jtagremote client/server is such a small but
> > significant and immediately-needed task, that could have been done in
> > parallel with when i was working on the pinouts.
> >
>
> IIRC this is the jtagremote code that I'm currently working on,

ahh sorry, i misunderstood.

> unless I
> misunderstood and jtagremote is something other than an interface between
> jtag and gdb. I'm just implementing it in a way where it also is the
> implementation of gdb's remote protocol in nmigen.

ahh that's where the confusion comes in.

jacob: the priority *really is* on jtagremote, not on gdb.  the gdb
protocol is a distraction that will delay getting those two
client-server functions done and implementing the jtagremote protocol.
that should literally be about 20-30 minutes work, if that: a unit
test about another 20-30 minutes.

adding the gdb protocol to that will at least double the amount of
time, and would involve a level of abstraction that is itself a major
distraction, which i suspect would greater than triple the amount of
time.

we really, really need to do what's needed and very little else, at
this point.  i know it's nice to think in terms of code that has
re-useability and levels of abstraction that save time later, and
ordinarily if we weren't under deadline conditions i'd be really happy
with the idea.

however right now, right before a deadline, even the *discussion* of
anything else other than what's needed to meet that deadline is
actually detrimental.


apologies i was so focussed on the IOconn split (which was
mind-bending) yesterday that i didn't yet vocalise the plans
semi-forming in my head at the time.  see this:
https://gitlab.com/Chips4Makers/c4m-jtag/-/tree/master/c4m/cocotb/jtag

that's the code that Staf wrote which understands SVF file-formats
and, using cocotb, sends bitpatterns "at" at JTAG master.

my thinking was to actually cut - separate/isolate - the use of cocotb
(remove all @cocotb.coroutine) from that code by way of the jtagremote
format over a client-server socket pair.

(sigh i just noticed the developers of cocotb decided to violate
conventions by operator-overloading "__le__" and using it as an
assignment.... argh... leaving that aside...)

here for example would be "self.jtagremoteclient.set_clock_bit_and_send()"
https://gitlab.com/Chips4Makers/c4m-jtag/-/tree/master/c4m/cocotb/jtag

the Timer can be replaced with a timer.sleep(1/(period*4))

lines 40, 42 and 44 would be replaced with just
"self.jtagremoteclient.set_those_bits_but_do_not_send()"

oh wait, i think that file c4m_jtag.py is a test program (written to
be able to test the svfcototb.py file [1], so that would be
self.jtagremoteserver above.

i'm slightly confused, it needs a bit more thought, or just to "get on
with it" if you know what i mean.

where to put the code... it does warrant creating its own repo at some
point (although it's going to be quite small), however can you please
just put things into soc/debug for now.
https://git.libre-soc.org/?p=soc.git;a=tree;f=src/soc/debug;hb=HEAD

so please: start with the client-server code (each should be no more
than 20 lines of code), then implement the jtagremote protocol client
and server (each, again, no more than 20 lines) plus a "straight" unit
test, no nmigen involved (which should be no more than 50-60 lines)
and a "nmigen" test (again, no more than 50-60 lines)

this should take no longer than about 2 hours to do.

l.

[1] https://gitlab.com/Chips4Makers/c4m-jtag/-/blob/master/c4m/cocotb/jtag/c4m_jtag_svfcocotb.py