[Libre-soc-dev] Litex-OPENTitan clarification

[Cole Poirier]

On Sat, Oct 3, 2020 at 4:14 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> On Sat, Oct 3, 2020 at 6:30 AM Cole Poirier <colepoirier at gmail.com> wrote:
> > Have you outlined our direct, based-on-our-needs python version on the wiki
> > or a bug report?
>
> check the creation date on these:
> https://bugs.libre-soc.org/show_bug.cgi?id=8
> https://bugs.libre-soc.org/show_bug.cgi?id=50

Lol! You've been working on it since the start! Hilarious!

> > Or is this something that is deferred until our bugzilla
> > review after the code freeze deadline?
>
> realistically, it's "after".

As in after our winter/spring 2021 130nm skywater tapeout?

> > > if the OpenTITAN / lowRISC team had consulted us, sought our input,
> > > and looked for ways to collaborate, i would not be asking that
> > > question.
> > Am I correct in recalling that they used your pinmix work?
>
> no - they saw the announcement that i'd created a BSV one for the IIT
> Madras Team, and went, "hmmm, we will do this too".  they _could_ have
> gone "we will do this too... *and we will include the IIT Madras Team,
> etc. etc. and basically make something like litex for EVERYONE to use
> not just us".

Oy! The lack of communication/attempt to collaborate makes me sad.

> iitex is... very close to being the perfect "system chip generator"
> except it is really annoying that, being based on migen, you make one
> single mistake and it can be hours to days wasted because migen has
> *zero* typechecking / safety features.

Hmmm... that makes sense. At least the starting template for us is
already 'near perfect', just in the wrong language.

> > Besides the work on icache.py and the related wb_get work, what else can I
> > be working on that would be helpful?
>
> unit tests for mmu, icache and dcache.  getting to be comfortable with
> it, if we're going to put it into the chip for Dec 2 it needs some
> serious focus.

Understood.

> adding a test of IO pins to debug/test/test_jtag_tap.py.  i *think*
> these are "standard-defined JTAG behaviour".  need to work out the
> code (or find IEEE JTAG documentation)
>
> some commands here:
> https://gitlab.com/Chips4Makers/c4m-jtag/-/blob/master/c4m/nmigen/jtag/tap.py#L344
>
> and here you can see the Muxes being created:
> https://gitlab.com/Chips4Makers/c4m-jtag/-/blob/master/c4m/nmigen/jtag/tap.py#L443


Sorry I'm not clear on what this entails? Is it a unit test to make
sure our JTAG implementation is spec conformant?

Saw this in your email that followed the above one "found this, written by staf:
https://gitlab.com/Chips4Makers/c4m-jtag/-/blob/master/test/nmigen/cocotb/controller/test.py#L99"

Should I create a bug report for this? or does one already exist?

Cole