For today: - Patterns figured out. - Assign patterns "Machine vocabulary" - high level machine description (utl) not cycle level time - not general actor network > implementable machine (no unbounded queues) - subsets of kpn and transactors to describe machine eventually refine utl to rtl it becomes a finite state machine (fsm) unit with single controller diamond controller implies control all other stuff synchronously. "Hardware Pattern Language" BHPL 0.5 overview - top layer (app-to-utl mapping layer) implementable actor layer - next layer (utl-utl transformation layer) too big, too slow - next layer (utl-rtl transformation layer) drop out utl, now a notion of clock (behavioral rtl) - next layer (rtl implementations), components - rtl-to-technology mapping how about register retiming? non architected state doesn't come in until rtl domain utl-to-rtl you start adding microarchitecture stuff not true. it starts from the utl level. if you start with a big one, it's all in, but now if you start breaking the utl into smaller pieces you are adding architected state rtl is cycle by cycle behavior locally synchronous combinational circuits stay in the lowest layer because this needs to be with the sequential logic as well "Decoupled Units" utl doesn't imply decoupling even though you do a good design there is a high probability to make it slow consequences add some extra constraints? requirements? you have a decoupled set of components, what do you do? a list of potential synchronization mechanisms which are applicable. unless shared memory truly multiported, you need to decoupled "Pipelined operator" one should talk about the loop because there could be a loop "Multicycle operator" long critical path. more general pattern. issue rate issue rate. "Controller patterns" different dimensions of organizing things "Memory patterns" "Network patterns" Comments on patterns - where are the arbitration patterns? communication patterns. it is actually in the network. what you might have, you build and have an arbiters. how do you build arbiters? - network, memory, controllers? there's a vocabulary. patterns are related to these things. - going back to vocabularies. patterns are talking about different levels of memories, networks, channels. - pattern is a problem solution pair - solution side of a pattern - it doesn't need to be a primitive - we lay down the primitives first, patterns are describing the primitives. - we are labeling a pattern with a solution - helper pattern for vocabulary? Assigning patterns ilia: unrolling (one of the striping example, generic one) rimas: in-order pipeline engine, time-multiplexing (task graph mapped) greg: systolic array (utl-utl level, utl-to-rtl level?) n-dimension unrolling? scott: network switches (decoupled through shared memory) i got a network? you can build it through memory/shared memory for high radix, decoupling henry: decoupled units in parallel, shared access to the memory hierarchy. bunch of cryptography modules, shared dma resources. yunsup: rtl-to-technology building register files and vector register files (stream buffers) chris f: clock boundary crossing chris c: micro-coded engine