Max, what a cool collection of 3D ICs related blogs. They suppose a pretty nice reading before going to sleep for me now ;-)
By the way, back in 2007, I was trying to launch a project with a big company in order to build a new asynchronous 3D FPGA architecture. The project was really interesting and very smart planned. Unfortunately, those were bad times for the company, and there were rumours about IBM going to buy it -- finally, Oracle was the one which absorbed the company I was dealing with: SUN Microsystems :-(
Jack wrote: 33MHz only gives you 30ns and that doesn't seem very long to get off one IC, across a PCB and on to another.
30 ns is plenty of time if you register inputs and outputs at the I/O pads and have point-to-point connections that are less than 12 inches: clock to out is 5-10 ns, propagation delay is another 5-10 ns including reflections, and setup is maybe 5ns, so plenty of time. A 33 MHz PCI bus has that same 30 ns clock period, and since it's a bus it has slower propagation than point-to-point if there are multiple cards, and requires that some wait state logic be done in the same cycle. People do 66 MHz PCI, though you may need custom logic to meet the timing.
Thanks @Max & @Garcia for those explanations. Max, I did not see your 3d ic blog either - a serious problem on EET these days is that if stuff makes it to the home page it is gone within days or less. Fascinating stuff though. How do they make the Vias in the layers?
@Zeeglen: "Sounds similar to a triggered oscillator using an active digital LC delay line"
Yes, the working mechanism is very similar, but in the case of integrated asynchronous circuits, LC delay lines are not an option -- they are just to big and "expensive".
Instead, you must use the intrinsic delay of the logic gates. I order to make accurate logic delay calculations, the best option is using the logical effort theory, developed by Ivan Sutherland and Bob Sproull in the early nineties.
Well, yes, I can specify stuff on a datasheet, but I want to make it as easy as possible for a customer to use my IC. For a start, my ICs would interface to an IC with processor cores on it, which need software. Consequently, the customer isn't going to change that at the drop of a hat because they've invested a lot of money in that software. So, if my IC is not compatible with the processor IC, my IC isn't going to get selected. If I had specified some interface which required the processor IC to be using some sort of balenced, shared clock, sales revenue would have been $0.
Was your PCB full of FGPAs really fully synchronous? 33MHz only gives you 30ns and that doesn't seem very long to get off one IC, across a PCB and on to another. Another path longer than 30ns would then become a Multicycle Path, which IMHO makes the design not fully synchronous (there will be some combination of process corner, voltage, temperature where the path delay is exactly a multiple of 30ns, which is no good unless you have some circuitry to mitigate the resulting metastability). However, I've been designing at the Matlab level for the last 6 years, so perhaps 30ns isn't so short now?
@Zeeglen: "Are you describing an independent clock oscillator that starts up on a trigger so there is always a defined and repeatable time between trigger and first clock edge?"
Well, what I'm describing is a circuit made from logic gates and that includes some "delay" feedback loops -- similar to a ring oscillator, but there are a lot of alternatives for implementing this.
About the defined and repeatable time, this is a very good question. A very clever alternative is having different delay loops, in such a way you can choose the clock period in real time. By this way, you can change the operating speed, but also implement EMI mitigation techniques -- similar to spread spectrum techniques.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.