Multiple Clock Domains (MCD) Arvind with Nirav Dave
280 likes | 450 Vues
Multiple Clock Domains (MCD) Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology. Plan. Why Multiple Clock Domains 802.11a as an example How to represent multiple clocks in Bluespec MCD syntax Synchronizers Putting it all together.
Multiple Clock Domains (MCD) Arvind with Nirav Dave
E N D
Presentation Transcript
Multiple Clock Domains (MCD) Arvind with Nirav Dave Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology
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
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
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
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
IFFT for 802.11a • The supefolded IFFT implementation uses the least area and the frequency is still low • need to produce a symbol every 4seconds, i.e., at a frequency of 250KHz • so the superfolded pipeline must run at 52x250KHz 13MHz http://csg.csail.mit.edu/Korea
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
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
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
Partitioning Rules A method in each domain Methods in red and green domains Only touched by one domain http://csg.csail.mit.edu/Korea
Handling Module Hierarchy Methods added to expose needed functionality http://csg.csail.mit.edu/Korea
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
headers data Cyclic Extend Controller Scrambler Encoder Interleaver Mapper IFFT Back to the Transmitters http://csg.csail.mit.edu/Korea
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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