.
As noted elsewhere, Google are sponsoring an offer to make chips for free, with few strings attached. This might be an opportunity to do something with homebrew CPU architectures!

My understanding of the offer is this:
- up to 40 designs will be fabricated for free
- if they get more than 40 submissions they will choose which to make
- successful projects will get of the order of a hundred assembled (and tested?) parts
- the chips are 16 mm^2, with 10 mm^2 free for use and the rest a RISC-V supervisor
- there are 40 I/Os, it's a 130nm process, and it might even be 5V tolerant
- the project must be open source and on github
- the aim is to pipeclean an open source design flow
- the design flow isn't yet quite final
- the first chip run is in November

I would imagine any design would need to be well-debugged to have a chance of working first time, and therefore should probably be done in FPGA first.

So, even if unsuccessful as a chip project submission, one will already have done something interesting on FPGA.

I nominate the Gigatron. Menloparkinnovation did a DE10nano implementation here https://forum.gigatron.io/viewtopic.php?f=4&t=55 . I've actually stripped out the DE10nano specific code and was successful in getting it breadboarded with R2R DACs.

Welcome! And thanks for the link to the FPGA Gigatron... an interesting idea to be sure.

I was chatting with @revaldinho and the idea which came up was an array of communicating OPC cores - like an array of transputers, each with a small amount of private memory. We don't have concrete ideas for the communication channel, at present, although it would probably be word-wide and might involve (shallow) FIFOs. Unlike transputers, OPC cores don't have communications primitives so there's some work to do. A possible idea is to use smaller simpler OPCs as communication processors. Anyhow, we think we should be able to fit a modest array on an LX9 FPGA, and a larger one on a free chip.

What I would like to see instead of this free chip offer, is a free information (both hardware and software) CPLD like device, but at higher level of logic blocks, 2 or 4 bits wide and a two phase
clock (latches not flip flips). Kind of a bitslice devepment kit.
Ben.

Sounds like a golden opportunity, but I don’t think I could have anything ready fast enough. It would take time just to learn how to convert code to the PDK. There’s several cores I’d be interested in seeing as a chip. C64 VIC-II replacement IC for instance. Or a Math co-processor. The 65832 processor.
I’m wondering what is the “RISC-V supervisor”? Is it an actual RISC-V processing core? Because of the limited I/Os there might need to be onchip ROM / RAM to use the RISC-V core.
40 I/Os is pretty limiting – meaning muxed I/O may be necessary. What kind of package is available?

Indeed, the RISC-V is a full-on microcontroller with RAM and ROM. It has the job of powering up the project, maybe of setting up I/O multiplexing.

I don't know what package might be used. Or even if it might have more than 40 I/Os - my understanding is that the project gets 40 I/Os, and it's possible there are more for the RISC-V. There might well be a JTAG port for example.

It's certainly more work to make a chip than to make an FPGA, but it's pretty much a superset of the work. So if a project can't be got ready in time to run on FPGA then it can't be ready as a chip project.

And, my feeling is, if a project can be got running on FPGA and is then adequate in performance and power consumption, there's not much further advantage in trying to make a chip.

I'm sure a big part of the process will be getting to understand the PDK and how to use it. Anyone who hasn't made a chip will have some things to learn! It might be though that it's a more or less unattended flow from HDL to layout data. And whether or not a project is selected, or ready in time, that learning process of getting to chip data might be of personal value.

https://youtu.be/EczW2IWdnOM?t=3830

Wafer Chip Scale package. Hopefully it's something Kicad already has a board geometry for.

Ah, thanks! So by my way of thinking, that comes out as a 4x4mm chip looking like a tiny BGA.


That's a nice size to place on a 40-DIL carrier for retro or breadboard compatibility.

Sounds like it is just a way to Brag about how great a RISC V cpu is.
Look at this design, now with C64 I/O. NOW with USB-2029 because
we have 1 I/O pin for other stuff. (+- POWER,GND,IO all on one pin)
You have risc cpu, that kills all fancy cpu designs. IO pins limit you
to a 8/16 bit cpu. Some fancy I/O device can't compete with the cheap
chinese USB stuff. A TV games console is out because you can't find a
TV anymore. Threaded code (FIG FORTH) cpu with taged data (LISP)
would make a intersting cpu.
Ben.
PS: 1 pin I/O would use some sort of charge pulse for power and data.

(I can't see how the RISC-V supervisor detracts from the project it shares a chip with. As ever, if you don't see the merit in something, you can leave it to those who do.)

What I'd quite like to get around to is to summarise how much logic and how much RAM you get per sq mm in this process.

There is of course no need to make use of all of the 10 sq mm allowance, or indeed to make use of all the I/Os.

Until somebody plays with the tools, that is a good question about ram/rom.
What little I have seen about chip development it is all low level stuff, draw your transistors
and wires. Here is inverter, here is a nor gate, here is a latch.
Any thing more is big $$$ for the development software, simulation software and information.

According to the video, the aim is to make a pretty automated flow (which is what we aimed to do too, when I was working in the chip business: it's potentially a great advantage, to be able to take updates to the design only a week or two before shipping. We did this by building a process to build the chip.)

Indeed, the value of this exercise to the likes of Google is the production of an automated flow.

In fact, the first public cut of the automated flow has just been announced. See
https://github.com/efabless/openlane#overview

I like the idea and wouldn't mind working on such a project. I'm actually working on something simiar at the moment. I worked on something similar to this and managed an array of 56 cores (Butterfly cpu) on a good size (200,000LC) FPGA. IIRC the network routers (networking components) were significantly larger (1,000LUTs?) than the processing cores. They had 16-entry deep receive fifo's, no transmit fifos. They allowed transfer of data in a two or three dimensional grid. Transfers were 4-bits per clock for x,y and 3-bits per clock for z directions.
Nodes contained a router, 8kB data and instruction memories, and the processing core.
I've been itching to get back to working on a port of TinyBasic used as the shell for this computing grid. Each node doesn't require a lot of ROM if it has sufficient RAM. Only enough rom needs to be present for bootstrapping.
40 I/Os would be enough to allow several high-speed serial channels to allow chips to be networked together.

Interesting! Yes, we're now thinking of bringing out links to allow chips to be connected. Perhaps a 2x2 array of compute nodes, with 8 bidirectional links (2 in each compass direction)

We're thinking serial links, synchronous, with a shared clock from offchip, perhaps 10MBit/s, perhaps 32 bit words in a 35 bit packet, with a 2 bit acknowledge packet, like the original Transputer links (but word-sized, and synchronous.)

The OPC cores are very small so we expect RAM to dominate. We're thinking of various possibilities for managing the communication, ranging from doing it all in software to having a second plane of OPC codes doing only comms.