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

Andrey Miroshnikov andrey at technepisteme.xyz
Thu Oct 14 12:03:10 BST 2021

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"?
Searching for "class TestIssuer" I found a few interesting modules in 
"soc/src/soc/simple/issuer.py". There's the "TestIssuer" class which 
uses "TestIssuerInternal", which itself uses "NonProductionCore" found 
in "core.py". Are all of those used in LS180?

 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).

# 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.
Does this mean we have our own branch/fork of Litex? If so, is it 
maintainable in the long run?

# Do you plan to use the Libre-SOC pinset for KiCAD schematic symbol and 
PCB footprint generation?
I like the point you made about re-using the same pinmux definition file 
throughout the workflow, however haven't seen mention of it being used 
for PCB software (such as KiCAD). Is anyone working on this and/or is it 
a low-priority task? Doing a quick internet search showed a few options 
for generating KiCAD library symbols:

Hopefully these questions might be helpful before the course is properly 


More information about the Libre-soc-dev mailing list