[Libre-soc-dev] Litex-OPENTitan clarification

[Luke Kenneth Casson Leighton]

On 10/5/20, Cole Poirier <colepoirier at gmail.com> wrote:
> On Sun, Oct 4, 2020 at 6:52 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
>>
>> On 10/5/20, Cole Poirier <colepoirier at gmail.com> wrote:
>>
>> 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.
>
> Jesus! indeed seems like an insurmountable headache!

yyep :)

actually it's not so bad.  the actual pinmux and associated control
regs is what is missing entirely from open source except in opentitan.

reason: nobody has bern doing ASICs until recently, and FPGAs well um
you just reconfigure the bitstream and compile in different
peripherals, what the hell would you need to waste LUTs on a pinmux
for??

>> what we *might* be able to do is use the devicetree generation etc.
>> aspect of opentitan.
>
> Interesting, is this the LUT in the bootloader that lists the memory
> addresses of all peripherals?

it does a lot more than that.

or, is supposed to.

it is supposed to hugelt simplify driver development by moving the
configuration of the driver out of c code and into devicetree where
things like the memory address and IRQ number are specified.

this as predicted is horseshit.

if over the past 30 years there are 50,000 unique I2C and SPI
peripheral ICs out there doing temperature sensing, accelerometers
touchscreens audio and so on then there has to be 50,000 drivers
written in c (devicetree only added because you have to).

the "promised reuse" of devicetree only happens if out of those 50,000
peripheral ICs, two completely disparate product designers happen to
talk to each other rather than each chucking a crapload of patches up
on a random site somewhere because they were "forced" to comply with
copyright law.

>> >> > 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.
>
> I know. Note I specifically said 2021, and referred to skywater 130nm
> as you (or staf, I forget which) mentioned we might do another 1 or 2
> additional tapeouts *after* the Euro 180 nm 2 DEC tapeout. I assume
> this is to test things like the scoreboard scheduling, and the
> SMP/cache-coherency, and GPU workload (and ... ?) prior to the Fall
> 2021 40/45 nm quad-core CPU-GPU-VPU commercial product tapeout?

don't know.  probably.  too much to decide there.  too much distraction.

> So, to clarify, you want the nmigen-litex to be discussed after the
> Euro 2 DEC tapeout?

yes.

> Additionally, what are our responsibilities between 30 OCT code freeze
> and 2 DEC tapeout?

testing. simulation. mmu. dcache. icache.  jtag.

l.