Multiple Clock Domains (MCD) Arvind with Nirav Dave

1. Multiple Clock Domains (MCD) Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology

2. Plan • Why Multiple Clock Domains • 802.11a as an example • How to represent multiple clocks in Bluespec • MCD syntax • Synchronizers • Putting it all together http://csg.csail.mit.edu/Korea

3. Cyclic Extend Controller Scrambler Encoder Interleaver Mapper IFFT Review: 802.11a Transmitter Operates on 1-4 packets at a time headers 24 Uncoded bits data Converts 1-4 packets into a single packet A lot of compute; n cycles/packet n depends on the IFFT implementation; for the superfolded version n 51 http://csg.csail.mit.edu/Korea

4. headers data Cyclic Extend Controller Scrambler Encoder Interleaver Mapper IFFT Analyzing Rates Relative rates: f/52 f f/13 Can we run these parts at different speeds (i.e. clock frequencies) and have them interact safely? http://csg.csail.mit.edu/Korea

5. Power-Area tradeoff • The power equation: P = ½ CV2f • V and f are not independent; one can lower the f by lowering V – linear in some limited range • Typically we run the whole circuit at one voltage but can run different parts at different frequencies • We can often increase the area, i.e., exploit more parallelism, and lower the frequency (power) for the same performance http://csg.csail.mit.edu/Korea

6. IFFT for 802.11a • The supefolded IFFT implementation uses the least area and the frequency is still low • need to produce a symbol every 4seconds, i.e., at a frequency of 250KHz • so the superfolded pipeline must run at 52x250KHz  13MHz http://csg.csail.mit.edu/Korea

7. headers data Cyclic Extend Controller Scrambler Encoder Interleaver Mapper IFFT Multiple Clock Domains may save power Relative rates: f/52 f f/13 One would actually want to explore many relative frequency partitionings to determine the real area/power tradeoff http://csg.csail.mit.edu/Korea

8. Plan • Why Multiple Clock Domains • 802.11a as an example • How to represent multiple clocks in Bluespec • MCD syntax • Synchronizers • Putting it all together http://csg.csail.mit.edu/Korea

9. Associating circuit parts with a particular clock Two choices to split the design: • Partition State • Rules must operate in multiple domains • Partition Rules • State Elements must have methods in different clock domains It is very difficult to maintain rule atomicity with multi-clock rules. Therefore we would not examine “Partitioned State” approach further http://csg.csail.mit.edu/Korea

10. Partitioning Rules A method in each domain Methods in red and green domains Only touched by one domain http://csg.csail.mit.edu/Korea

11. Handling Module Hierarchy Methods added to expose needed functionality http://csg.csail.mit.edu/Korea

12. We need a primitive MCD synchronizer: for example FIFO • enq one on clock and deq/first/pop on another • full/empty signals are conservative approximations • may not be full when full signal is true • We’ll discuss implementations later http://csg.csail.mit.edu/Korea

13. headers data Cyclic Extend Controller Scrambler Encoder Interleaver Mapper IFFT Back to the Transmitters http://csg.csail.mit.edu/Korea

14. Domains in the Transmitter let controller <- mkController(); let scrambler <- mkScrambler_48(); let conv_encoder <- mkConvEncoder_24_48(); let interleaver <- mkInterleaver(); let mapper <- mkMapper_48_64(); let ifft <- mkIFFT_Pipe(); let cyc_extender <- mkCyclicExtender(); rule controller2scrambler(True); stitch(controller.getData,scrambler.fromControl); endrule … many such stitch rules … These colors are just to remind us about domains function Action stitch(ActionValue#(a) x, function Action f(a v)); action let v <- x; f(v); endaction endfunction http://csg.csail.mit.edu/Korea

15. Coloring the rules? All methods in the same domain rule controller2scrambler(True); stitch(controller.getData, scrambler.fromControl); endrule rule scrambler2convEnc(True); stitch(scrambler.getData, conv_encoder.putData); endrule rule mapper2ifft(True); stitch(mapper.toIFFT, ifft.fromMapper); endrule Using different domains… http://csg.csail.mit.edu/Korea

16. Domain Crossing rule mapper2ifft(True); stitch(mapper.toIFFT, ifft.fromMapper); endrule inline stitch rule mapper2ifft(True); let x <- mapper.toIFFT(); ifft.fromMapper(x) endrule Different methods in an action are on different clocks – we need to change the clock domains http://csg.csail.mit.edu/Korea

17. Introduce a domain crossing module let m2ifftFF <- mkSyncFIFO(size,clkGreen, clkRed); Many such synchronizers In real syntax, one clock value is passed implicitly http://csg.csail.mit.edu/Korea

18. split Fixing the Domain Crossing rule mapper2ifft(True); let x <- mapper.toIFFT(); ifft.fromMapper(x) endrule rule mapper2fifo(True); stitch(mapper.toIFFT, m2ifftFF.enq); endrule rule fifo2ifft(True); stitch(pop(m2ifftFF), ifft.fromMapper); endrule let m2ifftFF <- mkSyncFIFO(size,clkGreen,clkRed); synchronizer syntax is not quite correct http://csg.csail.mit.edu/Korea

19. Similarly for IFFT to CyclicExt let ifft2ceFF <- mkSyncFIFO(size,clkRed,clkBlue); rule ifft2ff(True); stitch(ifft.toCyclicExtender, ifft2ceFF.enq); endrule rule ff2cyclicExtender(True); stitch(pop(ifft2ceFF), cyc_extender.fromIFFT); endrule Now each rule is associated with exactly one clock domain! http://csg.csail.mit.edu/Korea

20. Plan • Why Multiple Clock Domains • 802.11a as an example • How to represent multiple clocks in Bluespec • MCD syntax • Synchronizers • Putting it all together http://csg.csail.mit.edu/Korea

21. MCD Syntax in BSV:point of view • Automate the simplest things • Make it easy to do simple things • Make it safe to do the more complicated things http://csg.csail.mit.edu/Korea

22. Clock Domains: The Simplest case • Only one domain • Need never be mentioned in BSV source • Synthesized modules have an input port called CLK • This is passed to all interior instantiated modules http://csg.csail.mit.edu/Korea

23. The Clock type • Clock is an ordinary first-class type • May be passed as parameter, returned as result of function, etc. • Can make arrays of them, etc. • Can test whether two clocks are equal Clock c1, c2; Clock c = (b ? c1 : c2); // b must be known at compile time http://csg.csail.mit.edu/Korea

24. Instantiating moduleswith non-default clocks • Example: instantiating a register with explicit clock • Modules can also take clocks as ordinary arguments, to be fed to interior module instantiations Clock c = … ; Reg# (Bool) b <- mkReg (True, clocked_by c); http://csg.csail.mit.edu/Korea

25. The clockOf() function • May be applied to any BSV expression, and returns a value of type Clock • If the expression is a constant, the result is the special value noClock • noClock values can be used on in any domain • The result is always well-defined • Expressions for which it would not be well-defined are illegal http://csg.csail.mit.edu/Korea

26. The clockOf() function • Example • c, c1 and c2 are all equal • Can be used interchangeably for all purposes Reg# (UInt# (17)) x <- mkReg (0, clocked_by c); let y = x + 2; Clock c1 = clockOf (x); Clock c2 = clockOf (y); http://csg.csail.mit.edu/Korea

27. A special clock • Each module has a special “default” clock • The default clock will be passed to any interior module instantiations (unless otherwise specified) • It can be exposed in any module as follows: Clock c <- exposeCurrentClock; http://csg.csail.mit.edu/Korea

28. We actually want “gated” clocks • Often, big circuits do not do useful work until some boolean condition holds • We can save power by combining the boolean condition with the clock (i.e. clock gating) g Big Circuit f gating signal clk input to be continued http://csg.csail.mit.edu/Korea