[Libre-soc-dev] OpenPOWER Course video, differences between FPGA and ASIC

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Thu, Oct 14, 2021 at 12:10 PM Andrey Miroshnikov
<andrey at technepisteme.xyz> wrote:
>
> On 08/10/2021 19:51, lkcl wrote:
> > https://ftp.libre-soc.org/course_18oct2021/
> > https://m.youtube.com/watch?v=hzbLEEjJdOI
> >
> > this video will be part of the 40 hour Open Curriculum on OpenPOWER, to run from the 18th October.  the course is to be announced at the OpenPOWER 2021 Summit.
> Interesting way to teach the course, provide some explanation, then let
> the learner explore the code, wiki, mailing list, archives on their own
> and with email/IRC support.
>
> > it is quite long at 1h20m and goes into detail on some of the key differences when doing an FPGA and an ASIC.
> Watched the video, and now I have a much better overview for both the
> chip itself and the workflow.
> Nearer to the end it got a bit more difficult (probably because I try to
> take in the code instead of just listening to your points).
>
> I came up with a couple of questions:
> (apologies in advance if I missed explanations for these points
> somewhere on the wiki)
>
> # Why is the Libre-SOC core HDL called "TestIssuer"?

because it's in no way intended for production use (it says so at
the top of the module, issuer.py)  it's a test.  it issues instructions.
therefore test... issuer.  TestIssuer.

>  From the comments I figured it's because "TestIssuer" issues (or loads
> and executes) instructions from the "TestMemory" module, however that
> sounds like an application for a SIM/FPGA test run (where you have a
> known, controlled machine code already loaded).

not quite: it's more to indicate it's not for production use.

> # What is the plan with Litex class duplication for I/O/OE extension?
> You explained in the last 20min of the video that the Litex peripheral
> classes for UART/I2C/SPI had to be duplicated to allow adding the extra
> signals needed for the I/O pads.

yes.

> Does this mean we have our own branch/fork of Litex?

ah no.  i duplicated the relevant modules, shoved them into libresoc.py,
and that's it.  that's as far as it goes.

now, will litex *pick up* those modules and incorporate them into
mainstream litex?

answer: this is extremely unlikely because florent has been so obstructive
(he's reached three strikes with me) that we will not use litex for future
projects.

> If so, is it maintainable in the long run?

doesn't matter because it's snapshotted against a specific revision.

> # Do you plan to use the Libre-SOC pinset for KiCAD schematic symbol and
> PCB footprint generation?

that's entirely at the discretion of anyone wishing to do that.
however, personally,
i would prefer it to be auto-generated (and that can be done pretty easily)

> https://gitlab.com/kicad/libraries/kicad-footprint-generator

yes i've done that in the past (about 8 years ago).

l.