Hacker News Reader

Comment by tedunangst | Hacker News Reader

> Another striking advance is the migration in the P-core database from a 'sea of fubs' to a 'sea of cells'. This process of updating the organization of the P-cores substructure moves from tiny, latch-dominated partitions to more extensive and ever larger flop-dominated partitions that are very agnostic as things go.

I like to pretend I know a thing about CPU design, but I have to admit, I have no idea what's going on here.

View on HN

Chip design is SUCH an advanced topic. It's potentially one of the most advanced human disciplines at the moment.

I have a friend[0] that is doing his Electronics Engineering masters in Germany (very prestigious engineering university) and they're studying a freaking Pentium 4. Even for them the cutting edge chip design is black magic.

[0] Ultimate frisbee teammate.

Question: there's a lot of hands-on learning resources on the construction of a simple microcoded processor, or an in-order pipelined processor where the most headache-inducing thing you have to deal with is forwarding results – but is there one on the essential elements of "modern" superscalar OoO, e.g. the circuits that check for hazards and delay dispatching etc.?

It's not that it's magic I would love to learn about: it's that I'd like to know what happens behind the scenes when we say that (for example) "results get reordered in the reorder buffer"!

Is Hennessy and Patterson still the main book used in universities?

I used this last semester for Masters level computer hardware course.

A list + links would be much appreciated!

Replying for a reminder to check later.

Might enjoy this video, though it's a bit basic: https://m.youtube.com/watch?v=NGFhc8R_uO4

Modern chip designs have an enormous amount of logic and therefore standard-cells. And when you are dealing with a huge amount of cell all together, it quickly becomes unmanageable, syntheses tools runtime explode, quality of results declines, results become chaotic, ..

So chip designs are spliced into partitions. Each partition is a part of your design that you synthesized separately. For example you may setup a partition for the core, and you can instantiate it multiple time into a core_cluster partition.

Note that: synthetiser's logical optimizer cannot work on logic across partitions, so you don't want to small partitions (otherwise you will have more manual optimize to do) but you also don't want too big partitions (otherwise runtime and development iteration time increase).

The question is what the good size for a partition ?

* ALU is ~ 10 K cells (synthesis runtime range from few seconds to ~5 min)

* small core (low-end) is ~1M cells (synthesis runtime range from 1~8 hours)

In the Intel terminology: "sea of FUBs" approach is to prefer small partitions, while "sea of cells" approach prefer big partitions.

About the predominance of latch or flop, it's mainly a consequence from the level of manual optimization. (latch are smaller, but harder to manage, and it give diminishing returns with new process node). Same for process-node-specific vs process-node-agnostic.

PS: Most modern designs are "sea of cells" according the Intel terminology

FUB: Functional Unit Block.

It seems that they are moving from higher level (larger) building blocks to lower level (smaller) building blocks to increase efficiency.

The second part of the quote says they're moving from "tiny" to "more extensive" partitions though; it feels confusingly contradictory.

I read it as "fubs were small partitions, but now with the latch boundaries dissolved between fubs, the partitions are bigger (containing flops from many fubs)".

My flop partition is very agnostic about understanding that sentence, as things go.

It is the normal latch to flop migration. Nothing new. /s

Reply on news.ycombinator.com