Open Source Chip Design panel in 50 minutes

Open Hardware Summit 2021 live stream:

I host an open source hardware chip design panel including @jkridner at 3 PM US EDT today (50 minutes from now)

FYI - we also have a Open Chips group on this forum server:

Slides:

Hello,

I am on one hour and 17 minutes of the video and I am just replying to say the air tester/testing bucket is neat. Not only can one test w/ the bucket but also other sensors with specific processors.

I went to a H.S. in Baton Rouge, LA that was shutdown due to asbestos in '96. So, this is not only an issue in South Africa or in a Mill, Factory, or Plant in the US, pollution also solves life by ending it too early. I have seen many sensors that can handle such pollutants. It is a neat and productive way to end specific carcinogens before they can enter human lives.

Seth

P.S. Personally, my grandfather worked in mills and plants that produced a heavy amount of asbestos. He lived a fruitful life until the cancers grew and mutated his cells. If before the work began he was notified of the issues at hand, I am sure things would have been different. The plants and shipyards would not have been producing such toxins which lead to premature death. Anyway, lesson learned but in specific locales around the world and still in the US, pollutants and toxins are available and a byproduct of normal things we use constantly. Now, I do not proclaim to have evidence of a better way or if the world can deal with the lack of petroleum produced items like plastics but there should be and should have been better guidelines.

I think with the ease of access to specific sensors, this should not take place any longer, e.g. as people, I am sure of it, would love to not be introduced to toxins without their permission.

Hello,

I know you guys and gals are super busy as of now. Well, w/ the BeagleV coming out and other items in life taking place (COVID, social life, etc, etc, etc), I saw the RTL Chip category.

Register Transfer Level is what RTL is in length, right? So, I guess I will read and finish the presentation.

Are people looking to mfg. these chips are just find Open Source chips and chipsets to use in the BeagleV or Beagleboard.org style of Linux SBCs? I have been very curious as to how to install multiple different chips outside of what is currently offered on the BBB and the likeness…

I mean…I am reading an older book from '15 where this fellow put a DSP on the Cape he produced. Are the beagleboard.org persons looking to get DSPs or another type of Open Source chip no matter the type?

I am asking b/c I am ‘slow to the table’ but I like to stay and eat. Ha.

Seth

P.S. That last sentence is a nice joke about me not offering too much but liking to stick around to figure things out (sort of). I just thought if you guys knew of a way to allow me to help, someone would say so. In the meantime, I will review some sources and research the topics of Open Source RTL chips. Who knows? I may come up w/ something interesting.

Regarding RTL, I was confused about this term for a long time. Javier Serrano of CERN and OSHWA is working on guidance document for open source FPGA projects and wrote the following explanation. Please note that the document I copied this from is still just a draft and will be improved before being posted to oshwa.org:

Best practices for sharing FPGA designs

OSHWA and the FOSSi Foundation have teamed up to provide guidance for those of you who would like to share FPGA/HDL designs under an open-source paradigm in an efficient way, enabling others to reproduce your work, use it, modify it and feed back improvements. We are making no assumptions regarding your level of proficiency in FPGA design. If you already have some experience, feel free to skip over the quick intro and nomenclature sections.

A quick introduction to FPGAs

Field Programmable Gate Arrays (FPGA) are an important part of many hardware designs. An FPGA is a chip which can be configured to perform any logic function within the limits of its resources and the ability of the designer.

The inside of an FPGA can be very loosely described as a “sea” of configurable gates, flip-flops and interconnect. In the old days, designers used chips from e.g. the 7400-series to design a Printed Circuit Board (PCB) which would carry out a given logic function. This was cumbersome and inflexible. A change of functionality often required a modification of the PCB and long delays to wait for manufacturing. With FPGAs, changes in functionality which don’t affect the pinout do not need a redesign of the PCB. You just reconfigure the FPGA with an appropriate bitstream.

The configuration bitstream is the result of applying a set of tools to the design sources, which are typically text files containing Hardware Description Language (HDL) designs.

Nomenclature

The following is by no means meant as normative. It is just a list of terms you may read in these guidelines or elsewhere, with their most commonly accepted meaning. I.e., this section is only meant to help you navigate the world of FPGA design if you are new to it.

When a designer writes HDL code they are not “programming”, but actually “describing” a circuit. This is what the ‘D’ in HDL stands for. Different statements and blocks in HDL describe different parts of a circuit. A piece of circuit does not “happen” before or after another one. They just exist at the same time in different parts of the FPGA silicon. Therefore, we don’t use words like “execute” for a bitstream, because they convey some kind of sequential running of instructions as in software. For similar reasons, some prefer configuring an FPGA (i.e., loading a bitstream) to programming an FPGA, although the latter is very much used as well.

Some of the HDL you can write is not synthesizable, meaning that there is no clear circuit equivalent to it. These non-synthesizable HDL constructs (for example instructions to read and write from a file) are typically used for writing testbenches, which are used during simulation in a computer. The synthesizable part of HDL is sometimes referred to as RTL (Register Transfer Level) code, although strictly speaking you can write synthesizable HDL which is not RTL.

An increasing number of people use the word “gateware” to refer to HDL code, in particular RTL. This is in reaction to the use of the term “firmware” for RTL. Why do we need a new word? Well, imagine a situation in which you designed a PCIe board which contains an FPGA. The PCIe board is hosted in a PC running GNU/Linux, and you communicate with it using Linux device drivers, libraries and programs. These drivers, libraries and programs fall squarely under the software heading. Now imagine your board also contains a small microcontroller running bare-metal (no operating system) code. There would be broad consensus to call this code firmware. An increasingly popular practice in FPGA design is to describe a processor in HDL, using some of the gates and flip-flops in the FPGA to “create” that processor. Now if you need to distinguish the HDL code that implements the processor from the code running in it, you may want to avoid using the word firmware for both. This is where a word like gateware comes in handy. In short, whenever you read “gateware” you can interpret it to mean “HDL code” or “RTL code”.

The problem is there are not really any Linux-capable open source chips being manufactured currently. (the only open source commercial chip I can think of is the Parallax Propeller microcontroller). There are some open source RISC-V cores such as what the OpenHW Group is working on:

No company has yet made a chip using their Linux-capable CVA6 core yet.

Beyond that, there is so many more design blocks (often called “IP”) in a System-on-Chip (SoC) for all sorts of peripheral controllers needed for a modern Linux system. The majority of that is still proprietary and is licensed from giants like Synopsys and Cadence.

BeagleBoard.org would love to find others than want to make a truly open SoC a reality. This will be an iterative process where more and more of the IP in a SoC is open source. The CPU core is probably the best place to start. This will be an expensive and long process, so we are very interested to find partners. I’m not sure exactly how we will reach the end goal but I am hoping to find others that want to start planning a roadmap.

Please join our open chips group to continue the discussion:

Hello @DrewFustini ,

Seth here. I posted some announcements in that forum heading already. Thank you for this article. I will watch the video soon and follow the links.

Seth

P.S. RTL, HDL, and verilog must be similar in what end goal is met. Anyway, off to learn more…yes sir.