1. Advanced Digital Design GALS Design Andreas Steininger Vienna University of Technology

2. Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 2 Outline Global synchrony & clock distribution Global synchrony & clock distribution types of synchrony types of synchrony The GALS approach The GALS approach communication communication synchronization synchronization Muller C-Element, Mutex & Arbiter Muller C-Element, Mutex & Arbiter data driven clock & pausable clock data driven clock & pausable clock TMR example with pausible clock TMR example with pausible clock

3. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 3 Even/Odd Synchronizer works for two periodic clocks only with frequency ratio within certain range works for two periodic clocks only with frequency ratio within certain range avoids performance penalty of synchronizers avoids performance penalty of synchronizers largely eliminates potential for metastability largely eliminates potential for metastability for details see [Dally & Tell, The Even/Odd Synchronizer, ASYNC 2010] for details see [Dally & Tell, The Even/Odd Synchronizer, ASYNC 2010]

4. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 4 Types of Synchrony (1) synchronous synchronous identical frequency, constant phase relation identical frequency, constant phase relation classical synchronous system driven by one clock source classical synchronous system driven by one clock source mesochronous mesochronous identical frequency (no accumulating drift) but unknown, constant phase shift (bounded) identical frequency (no accumulating drift) but unknown, constant phase shift (bounded) example: unbalanced clcok tree example: unbalanced clcok tree multisynchronous multisynchronous identical frequency (no accumulating drift) but unknown, varying phase relationship (bounded) identical frequency (no accumulating drift) but unknown, varying phase relationship (bounded) example: jittering PLLs driven by the same source example: jittering PLLs driven by the same source

5. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 5 Types of Synchrony (2) ratiochronous ratiochronous fixed (known) frequency ratio, identical source fixed (known) frequency ratio, identical source example: source clock divided by different values example: source clock divided by different values plesiochronous plesiochronous same nominal clock frequency, mutual (low) drift same nominal clock frequency, mutual (low) drift independent clock sources with same nominal frequency independent clock sources with same nominal frequency heterochronous heterochronous clocks totally unrelated but periodic clocks totally unrelated but periodic independent clock sources with different nominal frequency independent clock sources with different nominal frequency aperiodic aperiodic events arrive totally unrelated to clock events arrive totally unrelated to clock sporadic event (pushbutton) needs to be synchronized sporadic event (pushbutton) needs to be synchronized uncorrelated

6. Synchronization Concepts Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 6 Probability of (not) resolving early enough This is what the “waiting synchronizers” exploit FR can never become zero! Probability of (not) getting into metastability Specialized synchronizers exploit a priori knowledge FR can become zero, if edges properly aligned!

7. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 7 Data Delay Synchronizer delay data to match FF timing requirements delay data to match FF timing requirements need to determine appropriate delay need to determine appropriate delay static, a priori (mesochronous, ratiochronous) static, a priori (mesochronous, ratiochronous) dynamic, by phase measurement & prediction (plesiochronous) dynamic, by phase measurement & prediction (plesiochronous) R data  T data  - estimate R clk

8. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 8 Clock Delay Synchronizer delay R clock to match FF timing requirements delay R clock to match FF timing requirements need to determine appropriate delay need to determine appropriate delay static, a priori (mesochronous, ratiochronous) static, a priori (mesochronous, ratiochronous) dynamic, by phase measurement & prediction (plesiochronous) dynamic, by phase measurement & prediction (plesiochronous) R data R clk  T data  - estimate

9. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 9 Buffering Synchronizer transmitter writes data to buffer with T clk transmitter writes data to buffer with T clk receiver reads data from buffer with R clk receiver reads data from buffer with R clk pointers are maintained to avoid collision pointers are maintained to avoid collision needs clock domain crossing => metastability! needs clock domain crossing => metastability! register w REQ/ACK, FIFO, ring buffer register w REQ/ACK, FIFO, ring buffer buffer size determines elasticity buffer size determines elasticity R data T data R clkT clk Buffer

10. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 10 Global Synchrony? Problem 1: Clock distribution Problem 1: Clock distribution Low-skew clock distribution becomes difficult for large chips and high frequencies Low-skew clock distribution becomes difficult for large chips and high frequencies Clock networks consume a considerable share of the power Clock networks consume a considerable share of the power Problem 2: Clock selection Problem 2: Clock selection SoC contains many IPs, each specified for its own frequency SoC contains many IPs, each specified for its own frequency specific frequencies required for some functions (interface standards, e.g.) specific frequencies required for some functions (interface standards, e.g.) dynamic local changes due to voltage & frequency scaling, clock & power gating dynamic local changes due to voltage & frequency scaling, clock & power gating

11. Globally Synchronous Design whole design is „isochronic“ whole design is „isochronic“ time conveyed by clock transitions time conveyed by clock transitions system-wide co-ordination of activities system-wide co-ordination of activities  assumes perfect clock distribution 11

12. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 12 Clock Distribution TRG src TRG snk t CO t pd t CO valid valid valid synchronous approach: clock skew 1 setup violation *

13. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 13 Clock Distribution TRG src TRG snk t CO t pd t CO valid alid alid synchronous approach: clock skew 2 hold violation *

14. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 14 Clock Distribution TRG src t CO t pd valid valid asynchronous approach: REQ delay REQ completion detection ACK TRG src TRG snk t CO valid ACK *

15. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 15 Clock Distribution TRG src t CO t pd valid valid asynchronous approach: ACK delay REQ completion detection ACK TRG snk ACK TRG src t CO valid *

16. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 16 Clock Distribution TRG src t CO t pd alid alid asynchronous approach: data delay ACK REQ completion detection TRG src TRG snk t CO valid ACK *

17. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 17 The GALS Approach SoC is clearly structured into IPs anyway SoC is clearly structured into IPs anyway run each at its desired individual frequency => synchronous islands run each at its desired individual frequency => synchronous islands efficient, well understood efficient, well understood communication between IPs communication between IPs has to bridge clock boundaries has to bridge clock boundaries may run over larger distances may run over larger distances => asynchronous paradigm (handshake- based) better suited for composition => asynchronous paradigm (handshake- based) better suited for composition Globally Asynchronous Locally Synchronous (GALS) First mention in PhD thesis by Chapiro / Stanford 84

18. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 18 A GALS Example CPU 2GHz PCI-IF 533MHz DSP 2,7GHz USB-IF 24MHz

19. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 19 Communication in GALS Boundary Synchronizers Boundary Synchronizers direct data exchange direct data exchange controlled by handshake => synchronizer controlled by handshake => synchronizer Shared Memory Shared Memory data exchange decoupled through memory data exchange decoupled through memory shared memory needs arbitration shared memory needs arbitration Dual-Clock FIFOs Dual-Clock FIFOs data exchange buffered through FIFO-queue data exchange buffered through FIFO-queue status flags need synchronization status flags need synchronization Local Clock Stretching Local Clock Stretching direct data exchange direct data exchange sender can halt receiver clock while data in transition sender can halt receiver clock while data in transition

20. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 20 Boundary Synchronizers data moving over clock domain boundary data moving over clock domain boundary metastability problems metastability problems => need to insert handshake => need to insert handshake …with synchronizers …with synchronizers and (optional) buffers and (optional) buffers control flow sender / receiver strongly coupled control flow sender / receiver strongly coupled handshake loop limits speed handshake loop limits speedS0xff14 CPU 2GHz DSP 2,7GHz S *

21. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 21 Shared Memory perfect decoupling of data path perfect decoupling of data path potential metastability problems at arbitration logic potential metastability problems at arbitration logic potential blocking through arbitration potential blocking through arbitration low speed, high efforts => rarely used low speed, high efforts => rarely used CPU 2GHz shared memory Arbi- tration 0xff14 DSP 2,7GHz *

22. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 22 Clocked FIFO good decoupling of data path good decoupling of data path potential metastability problems with pointer mgmt. potential metastability problems with pointer mgmt. potential blocking through full / empty potential blocking through full / empty high speed, high efforts (reg array) high speed, high efforts (reg array) CPU 2GHz reg array 0xff14 DSP 2,7GHz *S Pointer mgmt empty full

23. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 23 Pausible Clocking SRC: request SNK to stop clock SRC: request SNK to stop clock SNK: acknowldege stopping of clock open data latch (safe now!) SNK: acknowldege stopping of clock open data latch (safe now!) SRC: release SNK clock blocking SRC: release SNK clock blocking SNK: release ACK, close data latch start clocking (data stable now!) SNK: release ACK, close data latch start clocking (data stable now!) CPU 2GHz DSP 2,7GHz * pausible clock latch 0xff14

24. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 24 Pausible Clocking coupling of data path coupling of data path potential metastability problems with pausible clock potential metastability problems with pausible clock potential blocking through handshake for pausing potential blocking through handshake for pausing high speed, moderate efforts (pausible clock) high speed, moderate efforts (pausible clock) receiver clock distribution delay may cause problems receiver clock distribution delay may cause problems CPU 2GHz 0xff14 DSP 2,7GHz * pausible clock latch

25. Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 25 Fundamental Asynchronous Building Blocks will be needed for pausible clocking (and others) …

26. Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 26 Muller C-Element RS reset set a b y IF a = b THEN y = a ELSE hold y C ab y C a b y David Eugene Muller (1924 – 2008), Professor at Univ. of Illinois: Muller, D. E.; Bartky, W. S. (1959), "A Theory of Asynchronous Circuits", Proc. Int'l Symp. Theory of Switching, Part 1 (Harvard Univ. Press): 204–243

27. Function of a MCE consider a MCE with n inputs AND for transitions AND for transitions need a  on all inputs for a  output need a  on all inputs for a  output need a  on all inputs for a  output need a  on all inputs for a  output n-of-n threshold gate n-of-n threshold gate change output only if all inputs agree on changing change output only if all inputs agree on changing voter voter keep old state until agreement on change keep old state until agreement on change memory element memory element storage loop like D-latch, different input stack storage loop like D-latch, different input stack Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 27 *

28. Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 28 Muller C-Element: Circuit [Sutherland] [Martin] [van Berkel]

29. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 29 Mutual Exclusion purpose: purpose: decide order of asynchronous events decide order of asynchronous events function: function: handle pairs of request_in / grant_out handle pairs of request_in / grant_out requests may arrive in any order requests may arrive in any order MUTEX must activate only one grant_out at a time (respond to the first requester) MUTEX must activate only one grant_out at a time (respond to the first requester) problem: problem: resolve concurrent requests => metastability problem resolve concurrent requests => metastability problem r1 r2 g1 g2

30. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 30 MUTEX: Circuit SR-latch g1’ g2’ r1 r2 g1 g2 „Metastability filter“: e.g., lo-threshold inverter [from D. J. Kinniment „Synchronization and Arbitration in Digital Systems“, Wiley] V out,latch t V th,inv V meta BUT: Doesn’t a lo-threshold inverter produce glitches? * V out,inv

31. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 31 Popular MUTEX Implem. C.L. Seitz, Ideas about arbiters, Lambda, 1 (fi rst quarter):10–14, 1980. * SR-latch metastability filter

32. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 32 MUTEX: Operation g1’ g2’ r1 r2 g1 g2 V out,FF t V th,inv V meta r1 g1 r2 g2 4-phase protocol

33. MUTEX vs. Synchronizer Synchronizer Synchronizer purpose: purpose: “safeness”: “safeness”: important: important: freedom: freedom: circuit: circuit: MUTEX MUTEX purpose: purpose: “safeness”: “safeness”: important: important: freedom: freedom: circuit: circuit: Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 33 synchronize asynchronous input serialize concurrent requests fast resolution in both directions never activate both grants final decision not important infinite resolution time flip flop (special design) SR-latch plus metastability filter * time safe value safe

34. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 34 Arbiter: Principle purpose: purpose: manage access of clients to shared ressource(s) manage access of clients to shared ressource(s) method: method: handle pairs of request_in / grant_out handle pairs of request_in / grant_out on the client side on the client side on the ressource side on the ressource side client requests may arrive in any order client requests may arrive in any order arbiter must assign one ressource to only one client at a time (respond to the first requester) arbiter must assign one ressource to only one client at a time (respond to the first requester) => needs Mutual Exclusion (MUTEX)

35. Arbiter: Function Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 35 C1r C2r C1g C2g R1g R1r Client 1 Client 2 Common Resource 1 can have more than two clients: “multiway arbiter” can have more than one resource * PhD Naqvi: Fault Tolerant NoC (incl. Arbiter)

36. Arbiter: Operation Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 36 C1r R1r C2r R1g C1g C2g *

37. Arbiter: Circuit Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 37 MUTEX client 1 client 2 Common Resource R1g R1r C C r1 r2 g1 g2 C1r C2r C1g C2g allow one request at a time only delay request until previous cycle finished merge requests relay grant to requester keep grant alive until resource disables it *

38. Tree Arbiter Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 38 C1r C2r C1g C2g R1g R1r Client 1 Client 2 Common Resource can add further tree levels to handle more clients C1r C2r C1g C2g R1g R1r C1r C2r C1g C2g R1g R1r Client 3 Client 4

39. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 39 Data-Driven Clocking Principle: Principle: as soon as new data arrive => start clocking as soon as new data arrive => start clocking determine number k of clock cycles required to process new data determine number k of clock cycles required to process new data stop clocking after k cycles, wait for next data stop clocking after k cycles, wait for next data Properties: Properties: need to switch clock on and off => beware spurious clock pulses! need to switch clock on and off => beware spurious clock pulses! no metastability problem: data stable as soon as consumer clock starts no metastability problem: data stable as soon as consumer clock starts potential for power saving potential for power saving useful for very specific applications only (no pipe!) useful for very specific applications only (no pipe!)

40. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 40 Data-Driven Clock: Circuit CLK out  CLK half period deter- mined by  CLK half period deter- mined by  

41. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 41 Data-Driven Clock: Circuit  C REQ ACK CLK out REQ ACK transition on REQ answered by transition on CLK out transition on REQ answered by transition on CLK out min CLK half period deter- mined by  min CLK half period deter- mined by  CLK out  metastability? *

42. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 42 Pausible Clocking Principle: Principle: producer requests consumer‘s clock to pause producer requests consumer‘s clock to pause data are provided to input register during idle time data are provided to input register during idle time consumer‘s clock may resume consumer‘s clock may resume free running („pausible clock“) free running („pausible clock“) with one cycle only („stoppable clock“) with one cycle only („stoppable clock“) Properties: Properties: need to switch clock on and off => beware spurious clock pulses! => beware of clock tree delays! need to switch clock on and off => beware spurious clock pulses! => beware of clock tree delays! producer controls consumer‘s clock (blocking!) producer controls consumer‘s clock (blocking!) applications must be able to cope with paused clock applications must be able to cope with paused clock

43. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 43 Pausible Clock: Circuit  C REQ ACK CLK out REQ ACK inverter generates next REQ from ACK inverter generates next REQ from ACK self-oscillation self-oscillation CLK out  *

44. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 44 Pausible Clock: Circuit  C REQ’ ACK’ external unit can safely stop CLK by activating REQ’ external unit can safely stop CLK by activating REQ’ … and gets ACK’ as a response … and gets ACK’ as a response CLK out REQ’ ACK’ Mu- tex  metastability? *

45. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 45 Pausible Clock: Circuit C REQ’ ACK’ external unit can safely stop CLK by activating REQ’ external unit can safely stop CLK by activating REQ’ … and gets ACK’ as a response … and gets ACK’ as a response CLK out Mu- tex *  timing loop control loop redraw: replace inverters by inverted C-element output

46. Lecture "Advanced Digital Design"© A. Steininger / TU Vienna 46 Pausible Clock: n Clients C REQ1 ACK1 CLK out Mu- tex for more external sources an arbiter can be added before the Mutex for more external sources an arbiter can be added before the Mutex Arb- iter REQ2 ACK2 R. Mullins and S. Moore “Demystifying Data-Driven and Pausible Clocking Schemes”, Proc. 13th Intl. Symp. on Advanced Research in Asynchronous Circuits and Systems (ASYNC), 2007 pp. 175–185 

47. Pausible Clock vs. Crystal pros: pros: cheap to implement internally cheap to implement internally no extra pins no extra pins no mechanical issues (acceleration) no mechanical issues (acceleration) stoppable stoppable cons: cons: arbiter is no standard cell arbiter is no standard cell frequency is not as stable (PVT) frequency is not as stable (PVT) frequency is not as high frequency is not as high lacking tool support lacking tool support Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 47

48. Stoppable Crystal Clock? simply gating crystal clock to stop it simply gating crystal clock to stop it …leads to glitches …leads to glitches need a synchronizer for the stop input need a synchronizer for the stop input Gain of stoppable clock solution versus pure synchronizer (REQ/ACK) approach? Gain of stoppable clock solution versus pure synchronizer (REQ/ACK) approach? Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 48 clk_in clk_out stop sync * [R. Najvirt, A. Steininger. Equivalence of Clock Gating and Synchronization with Applicability to GALS Communication. PATMOS 2014]

49. Metastability Comparison pausible clock (ring oscillator) pausible clock (ring oscillator) can be safely stopped through mutex can be safely stopped through mutex phase adapts to gate signal upon start => no metastability issue phase adapts to gate signal upon start => no metastability issue stoppable clock (crystal oscillator) stoppable clock (crystal oscillator) could be safely stopped through mutex could be safely stopped through mutex phase does NOT adapt to gate signal upon start => metastability issue phase does NOT adapt to gate signal upon start => metastability issue cannot use mutex, since BOTH edges of gate need sync cannot use mutex, since BOTH edges of gate need sync Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 49

50. Time safe or value safe? Time safe Time safe need result at given point in time need result at given point in time accept the risk that FF has not yet decided accept the risk that FF has not yet decided example: synchronizer example: synchronizer Value safe Value safe take result only after decision take result only after decision accept that there is no time bound for this accept that there is no time bound for this example: mutex example: mutex 50 FR = 0

51. How far you can get… use the original circuit for pausible clocking use the original circuit for pausible clocking this will allow MS free switching on and off this will allow MS free switching on and off add a C-element to the timing loop add a C-element to the timing loop this will eventually adjust CLK out to ref CLK, if ref CLK is slightly slower than free running clock this will eventually adjust CLK out to ref CLK, if ref CLK is slightly slower than free running clock delay  guarantees min pulse width after switching on delay  guarantees min pulse width after switching on Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 51 C REQ’ ACK’ CLK out Mu- tex  ref CLK * C

52. Practical Implementation use 3 parallel loops to allow for more resolution time use 3 parallel loops to allow for more resolution time [R. Najvirt, A. Steininger. How to synchronize a Pausible Clock to a Reference, ASYNC 2015] Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 52 *

53. Conventional TMR Advantages: Advantages: mask all single faults mask all single faults Drawbacks: Drawbacks: single clock source single clock source no recovery no recovery Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 53

54. GALS-TMR Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 54 use independent clock => avoid single point of failure use independent clock => avoid single point of failure cannot do concurrent voting, since operation not in sync cannot do concurrent voting, since operation not in sync use voting over FF state at predefined intervals instead use voting over FF state at predefined intervals instead PhD Lechner: Fault Tolerant GALS Architecture

55. GALS-TMR Details every n th clock cycle every n th clock cycle stop own clock stop own clock synchronize with others synchronize with others perform recovery step perform recovery step Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 55

56. Summary (1) The generally used MTBU formula does not assume any knowledge about the input signal and its relation to the clock. In practice, such knowledge can often be exploited to optimize the synchronizer. The generally used MTBU formula does not assume any knowledge about the input signal and its relation to the clock. In practice, such knowledge can often be exploited to optimize the synchronizer. Synchrony is not a binary property, there is a range of globally synchronous, mesochronous, plesiochronous and heterochronous systems. Synchrony is not a binary property, there is a range of globally synchronous, mesochronous, plesiochronous and heterochronous systems. Asynchronous systems are tolerant against delays, while synchronous systems are not. The GALS approach therefore makes long-term communication asynchronous, while retaining the efficient and well proven synchronous paradigm for locally restricted islands. Asynchronous systems are tolerant against delays, while synchronous systems are not. The GALS approach therefore makes long-term communication asynchronous, while retaining the efficient and well proven synchronous paradigm for locally restricted islands. Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 56

57. Summary (2) GALS allows choosing the most appropriate clock for each island. GALS allows choosing the most appropriate clock for each island. Communication in GALS can be based on synchro- nizers, shared memory, FIFO or pausible clocking. Communication in GALS can be based on synchro- nizers, shared memory, FIFO or pausible clocking. A data driven clock is activated on demand only when data arrives to be processed. A data driven clock is activated on demand only when data arrives to be processed. A pausible clock can be stopped on demand. This is useful in GALS when moving data from one domain to the other, as it confines the potential for metastability to the arbiter. A pausible clock can be stopped on demand. This is useful in GALS when moving data from one domain to the other, as it confines the potential for metastability to the arbiter. Even a fault-tolerant TMR solution based on pausible clocks can be implemented that avoids the clock source as a single point of failure. Even a fault-tolerant TMR solution based on pausible clocks can be implemented that avoids the clock source as a single point of failure. Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 57

58. Summary (3) For the Muller C-Element, if both inputs match the output will assume the same value. For the Muller C-Element, if both inputs match the output will assume the same value. The purpose of a MUTEX element is to select one among two (or more) possibly concurrent client requests. It may remain undecided for an arbitrary time, but never select more than one clients. The purpose of a MUTEX element is to select one among two (or more) possibly concurrent client requests. It may remain undecided for an arbitrary time, but never select more than one clients. The purpose of an arbiter is to grant access to one (or more) resource(s) shared between two (or more) clients. Again access must be granted to one client at a time only. The purpose of an arbiter is to grant access to one (or more) resource(s) shared between two (or more) clients. Again access must be granted to one client at a time only. Lecture "Advanced Digital Design"© A. Steininger & M. Delvai / TU Vienna 58