Number eight of a series

1. Number eight of a series Drinking from the Firehose Many chips from one – Specification in the Mill™ CPU Architecture

2. The Mill CPU The Mill is a new general-purpose commercial CPU family. The Mill has a 10x single-thread power/performance gain over conventional out-of-order superscalar architectures, yet runs the same programs, without rewrite. • This talk will explain: • configurable architecture strategy • attributed specification • operation set specification • component configuration at core/chip/board levels • automatic tool generation

3. Talks in this series Encoding The Belt Memory Prediction Metadata and speculation Execution Security Specification … You are here Slides and videos of other talks are at: MillComputing.com/docs

4. The Mill Architecture Specification and configuration New with the Mill: Family members built from specifications Reusable components Instruction set built by composing attributes Fully regular instruction set Mechanically generated bit-level encoding Entropy-optimal encoding throughout Configuration-specific generated tool sets Asm, sim, debugger, compiler, … Generated hardware Verilog from specification addsx(b2, b5)

5. Caution! Gross over-simplification! This talk tries to convey an intuitive understanding to the non-specialist. The reality is more complicated.

6. Specification Unlike other talks in this series… This talk does not describe the Mill architecture It describes how the operation set and particular family member micro-architectures are specified. It describes, and demonstrates, some of the software tools built from the specifications. It describes how the specification supports manual creation of Mill hardware.

7. Specification Unlike other talks in this series… This talk does not describe the Mill architecture The specification tools are for internal use in creation of Mill CPUs; the tools are not intended to be products. By use of these tools, we can create new Mill chip products more quickly and at lower cost than usual. The intended audience includes tool designers and software developers interested in advanced design.

8. Specification The Mill is a family of member CPUs sharing an abstract operation set and micro-architecture. abstract Mill CPU architecture specification driven family members Tin Copper Silver Gold Members differ in concrete operation set and micro-architecture.. Designers describe a concrete member by writing a specification.

9. Specification Software automatically creates system software, verification tests, documentation, and a hardware framework for the new member from the specification. abstract Mill CPU architecture specification driven family members Tin Copper Silver Gold data driven tools compiler asm debugger sim HWgen

10. C++ compiler masquerade assembly language The Mill assembler syntax is C++. Suitably disguised.

11. Two-pass assemblers Traditional assemblers have two passes. The first pass treats the source as a program in a meta-language, usually a macro language, and interprets that program to produce a different source program in machine language. The second pass translates the program in machine language to binary and produces the executable file. source file load module first pass second pass machine language macro language binary

12. The Mill assembler uses the C++ compiler The first pass is the C++ compiler, which translates the assembly language source program to an executable. The second pass is the execution of the C++ program, to emit binary and produce the executable file. source file load module C++ compiler execution program C++ binary source file load module first pass second pass machine language macro language binary

13. C++ is Mill assembly language? Each assembler operation is a C++ function call. conventional assembler Mill assembler add b3,b5 jump loop loop: add(b3,b5) br("loop") L("loop") A Mill instruction is a C++ statement comprising operations separated by commas add(b0, 3), store(*b5, b7), br("loop“); operations instruction

14. C++ as meta-language Each call of an asm function emits that operation. for(inti = 1; i < 5; ++i) add(b0, i); gives the same machine code as: add(b0, 1); add(b0, 2); add(b0, 3); add(b0, 4); As in a macro assembler, in Mill assembler you can meta-program what your program will be.

15. Demo: extend a core The test case contains this code fragment: con(w(fpemu::st2bin32("3.0"))); con(w(fpemu::st2bin32("5.0"))); addb(b0, b1); nop(); nop(); nop(); However: the Tin CPU does not support native floating-point

16. Demo: extend a core Build for Tin – fail

17. Demo: create new “Demo” member like Tin Copy code tree Tin -> Demo Clear old files from new tree Tell builder tool to use new member Create new specification from Tin spec

18. Demo: update Demo member with FPU Populate execution pipeline slot with floating point

19. ISA design by composition attributes The semantic pieces of operations

20. Operation attributes A Mill operation invocation comprises a core operation and values for some number of attributes. addus(b3, 17) core operation add attribute value unsigned integer saturating b3 – third belt position 17 - literal domain overflow opand0 imm0 Specific attribute values are supplied by the operation mnemonic or by an argument to the operation function. There are ~50 attributes. Only a handful are meaningful for any particular operation.

21. Attribute values Most attributes are enumerations: enumdirectionCode {leftward, rightward}; enumcondSenseCode {allSense, falseSense, trueSense}; enumoverflowCode {excepting, modulo, saturating, widening}; enumdomainCode{binFloat, boolean, decFloat, logical, pointers, signedInt, unsignedInt}; Attribute values can be specified individually, or as bitsets with a selection of values of the same attribute.

22. Mnemonics Each opcode and attribute value has a text string nick. value nick leftward rightward signedInt unsignedInt l r s u Spec software concatenates the nicks of the opcode and attributes to make the assembler mnemonic automatically. shiftrsoperation is shift, right, signed There are ~120 core ops and ~1000 mnemonics.

23. Attribute semantics Besides its type, each attribute has three choices: • how values are expressed in assembler source • by mnemonic, based on the function name • by parameter, based on explicit argument • derived from other attributes, not in source • how values are encoded in target binary code • pinned in a single bit field in all formats • direct in different bit fields in different formats • merged into an opcode super-field • uncoded, for internal use only • how the set of permitted values is determined • universal, same for all slots for all members • by member, same for all slots on a given member • by slot, may vary based on available entropy

24. A candidate operation Semantics of the new operation: #define N = 7 uint16_t NEWOP (uint16_t a, uint16_t b) { return (a << N) + b + 1; } Assembler: shift add increment Any ALU can do this in one cycle Pick a name: Pick a value for N:

25. Demo: define a new opcode Add new opcode – opAttr.hh Add printname – opAttr.cc Add traits – attrTraits.cc

26. Argument signatures Some attributes get their value from the function arguments in the operation, rather than the mnemonic. arg kind meaning exuArg immArg bitArg offArg exu-side belt position small immediate constant bit number load/store offset Argument nicks are concatenated into signatures. signature arguments, in order exuBitSig baseOffWidthfSig exuExuExuSig belt position, bit number address base, offset, width three belt positions Ops are uniquely identified by their mnemonic and signature

27. Operation patterns Operations are defined as patterns, not individually. • An operation pattern comprises: • the core operation and its encoding block • the argument list • all meaningful values for all mnemonic attributes Each pattern defines all the operations that result from the cross-product of attribute values: the models. opPattern(exuBlock, addOp) << floats << roundings << exuArg << exuArg; This defines 12 models: six different rounding modes for each of binary and decimal floating point There are around a thousand models.

28. What attributes for our new operation? What domain? signedInt? unsignedInt? What about overflow? ignore it? mark result as an error? saturate to maximal value? produce a double-width result? Where to encode it? exuBlock? What arguments? exuArg, exuArg?

29. Demo: define a new operation Add specification – opSpecs.cc Add sim implementation build sim

30. Say how – or say what? specification Hardware development made easy.

31. Abstract Mill-ness The Mill is a family of member CPUs sharing an abstract operation set and micro-architecture. abstract Mill operation set micro-architecture

32. Abstract Mill-ness The Mill is a family of member CPUs sharing an abstract operation set and micro-architecture. abstract Mill operation set micro-architecture

33. Specifications make concrete from abstract The Mill is a family of member CPUs sharing an abstract operation set and micro-architecture. abstract Mill operation set concrete Mill chips specifications micro-architecture Monocore ... Crimson

34. Why specification/configuration? Creating a CPU by hand is fabulously expensive. Much of CPU implementation is repetitive, error-prone, tedious and wasteful. Often the design winds up sub-optimal because it’s too much trouble to change it yet again The Mill team knew it lacked the resources to implement – and re-implement – a moving target from scratch So we got the software to do it • can address multiple markets efficiently • fast pivots for new chips • economy for company and customers Result:

35. Concrete Mill chips Each concrete chip is specified as a set of components, including cores, caches, memory controllers, etc. “Crimson” chip concrete Mill chips Monocore ... Crimson

36. Concrete Mill chips Each concrete chip is specified as a set of components, including cores, caches, memory controllers, etc. “Crimson” chip “Copper” core caches Copper core Silver core ...

37. Concrete Mill cores The component cores in turn specify still more nested components. “Copper” core caches decoders specRegs ALUs Belt ...

38. Recursive specification Big parts have little parts, within each to excite ’em; and little parts have smaller parts, and so ad infinitum Apologies to Jonathan Swift It’s components, all the way down!

39. Component parameters Components have parameters to define their function. belt size = 16 predictor exit table size = 2048 latency = 2 … cache bank count = 4 line width = 64 evict policy = LRU way count = 4 … Components of the same kind but different parameter values can be collected in palettes for reuse in designing other Mills.

40. Behind components • Behind each component kind is hand-written software: • An emulation function sits in the simulator. • It defines what the component does in the machine. • A generator function sits in the generator. • It emits the Verilog starting point for hardware. The emulation function is definitive; if the hardware doesn’t match the simulator then the simulator is right.

41. Clock domains The Mill sim is event-driven at pico-second accuracy. All components reside in a clock domain. By default sub-components reside in the domain of their parent. Xtal components create top-level clock domains. PLL components link different domains. The ratio registers are in MMIO space for program control. A simulated Mill program can use simulated MMIO to control the simulated hardware and change the simulated clock rate that it itself is running under.

42. Memory hierarchy Components that derive from the memLevel type can be hooked together to model the memory hierarchy. The connections are streams of requests and responses. Each component only deals with the stream. It does not know or care what is on the other end. The streams use predictive throttling for congestion control, similar to network message methods. Streams run at full speed, without handshaking delay.

43. Demo: try it out run sim - ivan/build/testAsm.sim

44. Other roads… There are other architectures that provide operation specification. These differ significantly from the Mill. purpose: add special-purpose embedded operations form optimal subsets for family members encoding: reserved bit patterns, manually selected automatically generated optimal-entropy specification: one-at-a-time manual process pattern-based orthogonal generation

45. Summary: The Mill: Defines operations by composing attributes Tool produces cross-product of attributes Defines members by component lists Recursive composition – mix and match Compact notation expresses clock, memory Says what connects to what, tool creates “how”.

46. Shameless plug For technical info about the Mill CPU architecture: MillComputing.com/docs To sign up for future announcements, white papers etc. MillComputing.com/mailing-list