Clear – Open-Source FPGA ASIC
groupgets.com
groupgets.com
In my view, actually showing your source (with all its warts and TODOs) is something you need to do from the moment you're out in public talking about how your product is Open Source, not hopefully sometime later. Basically, we've arrived at the moment where either your open source is on github, or it needs to be treated as not open source. Otherwise, especially if the fulfillment end goes pear shaped, it's way too easy to fall into a trap where the source simply never gets released despite all your initial intentions.
There are more options than GitHub for publishing source code. If anything, publishing on GitHub is an instant strike against openness, because Microsoft should not be trusted. Even GitLab would be a better place to publish, iff only as a mirror.
So, yes, I agree. Lack of readily available source code on even the lowest common denominator hosting service should be a huge red flag when evaluating any project like this.
1. It will add a nice open-source reference design for a (small) FPGA that is compatible with the open-source SkyWater PDK. I am sure someone will take it and improve upon.
2. I am curious to try building a small batch of my own chips on this process (for a hobby project), but while I am somewhat comfortable with designing digital logic, I am less confident in my ability to take a chip and be able to communicate with it. By paying ~$80, I will be getting half of the experience (which would cost ~$10k otherwise)
As for the question, I don't know. But they have a comment section, maybe it's worth asking them directly?
Edit: if this is the right project, then I see most of the I/Os aren't actually user I/Os in this design. https://github.com/Manarabdelaty/Caravel-OpenFPGA-EF
=== CPU8BIT2 ===
Number of wires: 319
Number of wire bits: 3029
Number of public wires: 38
Number of public wire bits: 209
Number of memories: 0
Number of memory bits: 0
Number of processes: 0
Number of cells: 79
$_DFF_PP0_ 24
$lut 55Maybe a modulator for some obscure LED protocol that would probably be just fine in software on a 50 cent MCU anyway.
But it is something that's never been done before, or at least has rarely been done this cheap.
A hardware true random number generator using ring oscillators
Would it work? How could you avoid entrainment between the two rings?
I tried this using a handful of TTL chips and a breadboard, but I'm not good at this kind of thing, and it didn't work (or rather, I couldn't prove it was working).
Why?
I was under the impression that all that mattered was the phase noise in the ring oscillators (and therefore the phase drift)?
Also, not sure why would you need a shift register?
Just something that samples the output of the TRNG on a pin at a reasonably low freq and bitbangs what it gets on an output pin hooked up to the RX pin a serial-USB thingie should do the trick.
Yes, you could use a serial-USB chip, and collect one bit at a time. So you're right, there's no need for a shift register.
Mutually prime: isn't it desirable that the sampling oscillator runs substantially slower than the sampled oscillator? You don't want successive samples to be from the same cycle of the sampled oscillator. I'm handwaving about mutual primality; but I'm thinking that you want to maximise the length of cycle over which the two oscillators would be expected to coincide, absent phase noise. I suppose having more inverters in each ring would increase the influence of phase noise, and increase the combined cycle length.
And I still don't know how you avoid the two oscillators becoming entrained - they can influence one-another through the supply line.
You then sample it using the crystal clock but at a slow pace (say 1kHz).
You are correct that you may see some sort of self-synchronization effect between the sampler loop and the ring osc., especially given that it's pretty much impossible to know what the FPGA routing and placement tools will do.
The trick here is that yes: the random numbers you're going to get out of these types of potentially intertwined systems is of very low quality from a uniformity perspective: you absolutely can't use the output directly because statistically speaking, it has very low entropy.
But from a true random number generation perspective, these time series of bit do contain some entropy of the completely unpredictable kind (generated by a truly random physical process).
And therefore, if you use this low-entropy stream of bit, some of which are pretty much guaranteed to be impossible to predict and feed them to - say - a stream cipher, you're going to get something that is both truly (as opposed to pseudo) random and uniform.
Clearly, you don't do that last part on the FPGA/CPLD but in software, on the other side of the USB bridge.
OK, that seems to be a different model, that I wasn't aware of. The model that I described can be thought of as a jittery oscillator sampling another jittery oscillator.
> the shorter the oscillator (very few not gates) the faster it will oscillate, especially with modern silicon.
Yabbut surely the more inverters in the loop, the more jitter per cycle? I thought that the jitter in ring oscillators was ultimately down to the unpredictability of switching speed in gates. So the more gates in the loop, the more jitter. Is this wrong?
> these time series of bit do contain some entropy
Yes. The output is biased. So you have to debias it (or "distill" it); for a hardware circuit, I'd have thought a hardware debiaser would be more sensible than running it through a software-driven stream cipher. Instead use the Von Neumann debiaser, which as I recall can be implemented with a couple of gates.
Ah - now I remember why you need a shift register! The Von Neuman circuit doesn't output bits regularly; it compares successive pair of bits, and outputs a bit only when the inputs differ. With a heavily biased input stream, its output will be quite slow.
[Edit] For added jitteriness, you can build up a chain of oscillators, each sampling the next. If you have plenty of gates, I suspect you can make a raw source with a lot of entropy to distill.
[Edit Edit] The stream cipher serves as a whitener; the Von Neumann circuit doesn't do that. You still have to encrypt or hash the output to obliterate any patterns the Von Neumann circuit doesn't address - which is lots.
I cannot find it here: https://efabless.com/projects/shuttle_name/MPW-1
Nor here (since I think it is by efabless?) https://github.com/orgs/efabless/repositories
(I am not affiliated with the project, but backed it)
Look at the picture in it versus in the link:
https://groupgets-files.s3.amazonaws.com/Efabless/open-sourc...
They are different. Also, if you go to https://vlsicad.ucsd.edu/Publications/Conferences/383/c383.p...
Figure 6: You can find the image from the link (top left), and the on ehtat you linked (bottom left), so they are two different projects.
https://groupgets-files.s3.amazonaws.com/Efabless/open-sourc...
They are different.
Also, if you go to https://vlsicad.ucsd.edu/Publications/Conferences/383/c383.p...
Figure 6: You can find the image from the link (top left), and the on ehtat you linked (bottom left), so they are two different projects.
Edit: yup, they just picked a pretty picture they had of what was apparently the first design in MPW1. You can browse it here:
https://siliconpr0n.org/map/gsky/mpw1-00010001/mz_mit10x/
Almost certainly not the actual FPGA design.
Then again, the low power consumption picture looks to be measuring the SPI flash? that is far too little pins for the FPGA.
Would be great to see a path to a real OSHW ASIC. That would require either a substantially larger crowd funding initiative or somehow setting up an ecosystem with fixed die and package options for OSHW IC products.
I don't think the costs would be as high as everyone thinks, but the effort and time investment would be significant.
i mean, am i missing something or did they slap "ASIC" on that product just for good measure in case someone isnt looking for "FPGA" (so for SEO reasons)?
I agree it's confusing but it is what they called it. It's like an old Xilinx 2064 with a risc-V added on top, except the chip itself is OSSHW, not just the board.
This is a show case for eFabless that uses SkyWater PDK to build actual ASICs on a 130nm process. They are making a toy 8x8 FPGA, just so that people can play with an FPGA ASIC that was custom manufactured for that group buy.