I see you don't have any responses, so I'll give it a shot. I don't remember the actual math from my coursework, and have no experience with real-world custom ASIC design (let alone anything at all in the "three-digit GHz" range), but the major variables look something like this (in no particular order):
1) transistor size (smaller = faster, but process is more expensive)
2) gate dielectric thickness (smaller = faster, but easier to damage the gate; there's a corollary of this with electric fields across various PCB layer counts, microstrips, etc. that I'm nowhere near prepared to articulate)
3) logic voltage swing (smaller = faster, but less noise immunity)
4) number of logic/buffer gates traversed on the critical path (fewer = faster, but requires wider internal buses or simpler logic)
5) output drive strength (higher = faster, but usually larger, less efficient, and more prone to generating EMI)
6) fanout (how many inputs must be driven by a single output) on the critical path (lower = faster)
Most of these have significant ties to the manufacturing process and gate library, and so aren't necessarily different between a link like PCIe and a CPU or GPU. Some things can be tweaked for I/O pads, but broadly speaking a lot of these vary together across a chip. The biggest exceptions are points #4 and #6. Doing general-purpose math, having flexible program control flow constructs, and being able to optimize legacy instruction sequences on-the-fly (but I repeat myself) unavoidably requires somewhat complex logic with state that needs to be observed in multiple places. Modern processors mitigate this with pipelining, which splits the processing into smaller stages separated by registers that hold on to the intermediate state (pipeline registers). This increases the maximum frequency of the circuit at the cost of requiring multiple clock cycles for an operation to proceed from initiation to completion (but allowing multiple operations to be "in flight" at once).
That being said, what's the simplest possible example of a pipeline stage? Conceptually, it's just a pair of 1-bit registers with no logic between the input of one register and the input of the next one. When the clock ticks, a bit is moved from one register to the next. Chain a bunch of these stages together, and you have something called a shift register. Add some extra wires to read or write the stages in parallel, and a shift register lets you convert between serial and parallel connections.
The big advantage that PCIe (and SATA/SAS, HDMI, DisplayPort, etc.) has over CPUs is that the actual part hooked up to the pairs that needs to run at the link rate is "just" a pair of big shift registers and some analog voodoo to get synchronization between two ends that are probably not running from the same physical oscillator (aka a SERDES block). In some sense it's the absolute optimal case of the "make my CPU go faster" design strategy. Actually designing one of these to reliably run at multi-gigabit rates is a considerable task, but any given foundry will generally have a validated block that can be licensed and pasted into your chip for a given process node.
It makes sense why links can reach higher speeds than CPU cores, but it's not enough explanation for how symbol frequencies got 25x faster while CPU frequencies got 2x faster.
The simple answer to this is that signaling rates were far behind the Pareto frontier of where they could be, and CPU clock rates are pretty much there. CPU clocks are also heat-limited far more than I/O data rates. CPUs are big and burn a lot of power when you clock them faster, while I/O circuits are comparatively small.
Transmitting and receiving high-speed data is actually mostly an analog circuits problem, and the circuits involved are very different than those in doubling CPU speed.
The key factor is how fast units need to ship. In general, the scaling is sub-linear due to
1. reduced per-component costs (volume discounts)
2. less administrative/engineering overhead (ie the salaries/one-off costs get divided among more units)
3. more optimized assembly processes
Assembly labor expenses are directly proportional to how many units need to ship per timeframe. If an assembly worker can assemble 10 units a day, you're shipping 200 units/month. So you can ship 1000 units in 5 months or hire 5 people and ship 1000 units in 1 month.
No, we fully agree it's a hard problem. Which is why we wrote functional software first, and then went into hardware when the existing hardware couldn't support our use cases.
There's problems with the software that need to be solved before we ship, but it's not with the UI side of things. That's not to say that the UI is perfect (it really isn't), but it's functional and more importantly: can be changed at any time, unlike hardware.
If you have hardware and shitty software the only thing that will happen is that your users will be disappointed. You can't change the first reviews or hand-ons "any time". It's a one-shot.
these aren't normal users. linux users choose what others may see as sub-par UX every day because we value other things. and they'll fix it themselves; it's not an apple-style top-down relationship, and I expect it'll iterate fast.
I bought in on the presale, and have been very happy with how you guys have been approaching this project. It's obviously an uphill battle to release this device, but I love the ambition and lack of compromise you guys have in creating a new form factor.
I think you are likely too early to market, making it a hard sell for a mass market in the short term. If you can survive long enough I think you can do well, however.
We've tightened up the numbers a bit, but it's pretty close to a honest amount. 4m would put us well into profitable S1 production + enough runway to develop the next iteration territory.
> I've also seen a16z invest in far less (pitch decks and hand-wave demos). So my read on the feedback is they've made too much progress on one front (enough to show a16z that they're not a compelling seed investment) but not enough progress on the other front (enough to warrant a PMF A round). Doesn't seem like a fun spot to be in.
That's how I feel as well, given feedback from other VCs we've applied at. Amplify told us roughly "too big for a seed, too small for a series A" after five meetings or so.
Bummer I missed the SAFE round. I would consider chipping in as an investor even though I wouldn't feel comfortable purchasing a preorder as a consumer. Wonder if you can structure your next round to include spots for people that missed the train...
Our solution to this is to make the compute modular. In a few years you can plug in a new (off-the-shelf) compute module and have a state of the art PC again.
The Hololens 2's PPD are largely fake. There was a writeup somewhere but it's way, way below the stated number.
Varjo is pretty high up there, and they're able to compete in the clarity department. But their headset is non-portable and only supports Nvidia+Windows (at least last time I checked).
While I haven't verified it, that's Microsoft's own claim so they will have their reasons for citing that number so I won't make a claim one way or the other, but have provided a link to the dispute below(1).
Simula is not a shipping product, which to be fair means I should be comparing it with any announced but not yet shipping product, and probably not with products that were announced 4 years ago.
Explaining it in detail requires more background in electronics, but that's ultimately what it boils down to.
High-end analog front ends can reach the three-digit GHz (non-silicon processes admittedly, but still).