Last visit was: Tue Nov 24, 2020 11:22 am
It is currently Tue Nov 24, 2020 11:22 am



 [ 15 posts ] 
 Ideas for making use of the free chips offer 
Author Message

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
.
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.


Sat Jul 18, 2020 11:21 am

Joined: Sat Jul 18, 2020 5:59 pm
Posts: 2
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.


Sat Jul 18, 2020 6:02 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
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.


Sat Jul 18, 2020 6:11 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 172
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.


Sat Jul 18, 2020 10:00 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1239
Location: Canada
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?

_________________
Robert Finch http://www.finitron.ca


Sun Jul 19, 2020 4:44 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
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.


Sun Jul 19, 2020 6:36 am

Joined: Sat Jul 18, 2020 5:59 pm
Posts: 2
Quote:
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.


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

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


Sun Jul 19, 2020 12:47 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
Ah, thanks! So by my way of thinking, that comes out as a 4x4mm chip looking like a tiny BGA.
Quote:
Wafer-level packaging consists of extending the wafer fab processes to include device interconnection and device protection processes. Most other kinds of packaging do wafer dicing first, and then put the individual die in a plastic package and attach the solder bumps. Wafer-level packaging involves attaching the top and bottom outer layers of packaging and the solder bumps to integrated circuits while still in the wafer, and then dicing the wafer.


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


Sun Jul 19, 2020 3:35 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 172
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.


Sun Jul 19, 2020 10:35 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
(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.


Mon Jul 20, 2020 7:39 am

Joined: Mon Oct 07, 2019 2:41 am
Posts: 172
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.


Mon Jul 20, 2020 10:08 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
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.


Tue Jul 21, 2020 7:40 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
In fact, the first public cut of the automated flow has just been announced. See
https://github.com/efabless/openlane#overview


Tue Jul 21, 2020 8:31 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1239
Location: Canada
Quote:
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.

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.

_________________
Robert Finch http://www.finitron.ca


Sun Jul 26, 2020 7:07 pm WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1494
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.


Sun Jul 26, 2020 7:40 pm
 [ 15 posts ] 

Who is online

Users browsing this forum: Bing [Bot], CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software