[Libre-soc-dev] Litex-OPENTitan clarification

[Luke Kenneth Casson Leighton]

On 10/5/20, Cole Poirier <colepoirier at gmail.com> wrote:

>> 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!

:)

i rhink the lesson from the bsv pinmux and from opentitan is: for
god's sake stay away from templating of HDL.

verilog can't read JSON or CSV files. bluespec can't read them either.

the result: hopelessly unreadable code.

by using pyrhon to generate the AST of the pinmux we stand a chance of
readability.

what we *might* be able to do is use the devicetree generation etc.
aspect of opentitan.


>> > 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?

we're not doing the nov skywater 130nm.
we are using Staf EuroPractices 180nm, Dec 2nd deadline.
>> 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?

JTAG Boundary scan it's officially calked.

> 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"

yep that needs converting to nmigen.

> Should I create a bug report for this?

yes please.