Like others in the thread, I'm entranced by the idea. However, the lack of github links for the "open source" of this ASIC have put me right off of becoming a backer. It's a dang shame that we have to spend time & effort in this thread saying 'maybe _this_ is the source -- no, I think it's _that_'.
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.
I love to see GitHub used as a generic term for a hosted repository service. I would enjoy seeing that trademark continue its march to become a completely generic term.
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.
Yes, it's very limited. Personally, I backed for two reasons:
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)
For the first point, I think they are fine: FPGA stands for field-programmable gate array. This is exactly what they make, even though the array is very small.
As for the question, I don't know. But they have a comment section, maybe it's worth asking them directly?
Yeah, that's a bit ridiculous. The smallest commercial FPGA you can buy, as far as I know, is the smallest MachXO2 with 256 LUTs, and that's already in the "a little bit of glue logic" territory. How do they do anything useful with 64 LUTs? With 38 I/Os, you're going to spend all your LUTs just interfacing with them... Am I missing something here?
nah, it will easily fit. not sure about routing ressources though.
=== 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 55
For which you'd want at least two rings, with mutually-prime numbers of inverters - e.g. 53 and 11. But you'll also need a serial-in parallel-out shift register, which I guess you can probably do with a dozen gates. So maybe you could have rings of 41 and 11.
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).
>For which you'd want at least two rings, with mutually-prime numbers of inverters
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.
Well, I understand the principle to be that you use one ring oscillator to sample the state of the other; then you sample the output of the first oscillator on a clock. Phase noise just makes both oscillators more-or-less chaotic. How are you supposed to measure the phase noise?
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.
I believe you only need one ring oscillator: thermal effects pretty much guarantee that phase noise will be present, especially if the ring is short: the shorter the oscillator (very few not gates) the faster it will oscillate, especially with modern silicon.
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.
> I believe you only need one ring oscillator: thermal effects pretty much guarantee that phase noise will be present
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 get that, but the link literally says: "The Open Source FPGA ASIC". With that in the title, I would expect to be able to find the source of the FPGA.
Looks like this has been put together by Efabless themselves. I dont think the rtl would be too different from OpenFPGA(https://github.com/lnis-uofu/OpenFPGA) married to the caravel f/w.
My guess would be that the first prototype that they made was too buggy to publish. The promise is that they will share the final design, and I am fine with that.
(I am not affiliated with the project, but backed it)
Yikes. If I'm understanding that correctly every chip that came back from MPW-1 was more or less unusable - they were all required to gate access to I/Os behind the same management processor provided by the company organising the run, and because that management processor was broken they couldn't configure the I/Os to route through to their own designs.
I get the feeling the image from the link might just be wrong, though. It has 3 identical blocks in the user logic area. That doesn't fit the 8x8 FPGA story. There's no factor of 3 there. Maybe they just used a random example built on the same platform?
Edit: yup, they just picked a pretty picture they had of what was apparently the first design in MPW1. You can browse it here:
I mean...in my mind, that raises more questions. All of the "Additional Cool stuff" to be implies that it was fabbed out on mpw-1 and they have tested it. Why take a random image then if you have die shots or a picture of the GDS?
Then again, the low power consumption picture looks to be measuring the SPI flash? that is far too little pins for the FPGA.
I think it's a great initiative. However, marrying it to Caravel means that it basically a prototype and far away from a standalone product.
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.
are they offering to turn your fpga design into an actual asic?
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)?
No... they are making their own FPGA by fabbing their own ASIC.
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 actually something completely different. :)
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.
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.