1

Operation Dependent Frequency Scaling UsingDesynchronization

Nitish Srivastava, Student Member, IEEE, and Rajit Manohar, Senior Member, IEEE

Abstract—Asynchronous circuits are inherently more robustthan their synchronous counterparts. Desynchronization is a wayto obtain asynchronous circuits from a synchronous specificationusing standard design tools while improving circuit for variationtolerance, electro-magnetic interference (EMI), and resulting insimilar area, delay, and energy as the synchronous baseline. Thispaper proposes a novel operation-dependent desynchronizationtechnique, which desynchronizes the circuit and improves per-formance beyond the limits of synchronous design. We performa case study of our proposed technique on RISC-V rocket coreand show significant improvement in performance with minimalpower and area overheads.

Index Terms—Asynchronous circuits, desynchronization, fre-quency scaling, synchronous designs, circuit optimizations.

I. INTRODUCTION

ASYNCHRONOUS circuits have several potential benefitsover synchronous circuits. They are less prone to failure

due to process variations, voltage, temperature etc., whichcan reduce the growing timing complexity in digital design.In spite of these benefits, industry has been reluctant tofully migrate to asynchronous methodology due to the costsand risks of leaving synchronous domain, which has a longlegacy of success and sophisticated CAD infrastructure. One ofthe drawbacks of asynchronous design is that standard CADtools for logic synthesis cannot be used for control signals,since those signals must be hazard-free. Asynchronous designslike Quasi Delay Insensitive (QDI) circuits which do notmake assumptions about the timing of different componentshave immature CAD flow. The designing of these circuitsis also very different from synchronous circuits and has asteep learning curve for designers. Bundled data is anotherapproach of designing asynchronous circuits where similarto synchronous design combinational logic blocks are imple-mented using standard CAD tool flow. It uses asynchronoushandshake controllers to control the data transfer betweenmultiple combinational blocks. These designs are not self-timed like QDI circuits as they require the knowledge ofdelays of the combinational blocks. For QDI circuits thedesign itself is delay insensitive and hence the correctnessof the circuits does not depend on supply voltage, operatingtemperature and process variations. Bundled data circuits onthe other hand have local handshake controllers which are

N. Srivastava is with the Department of Electrical and Computer Engineer-ing, Cornell University, Ithaca, NY, 14850 USA e-mail: nks45@cornell.edu(see https://nitish2112.github.io).

R. Manohar is the John C. Malone Professor of Electrical Engineer-ing and a Professor of Computer Science at Yale University. email: ra-jit.manohar@yale.edu (see http://csl.yale.edu/ rajit/)

placed close to the combinational blocks and hence undergosimilar voltage, temperature and process variations as the com-binational block. The closed loop property of the asynchronouscircuits distinguishes them from the synchronous circuits.Asynchronous circuits work on the principle of handshakes. Ifone component takes more time to perform the computation,the rest of the components wait for this computation to finish.Unlike synchronous design where any change in timing ofa component can result in circuit failure. Techniques forautomated conversion of synchronous to asynchronous designsare appealing, because they can address the challenges ofasynchronous design yet provide the benefits of asynchronousdesigns.

Desynchronization [1], [2] and phased-logic [3] are twotechniques that convert synchronous designs to asynchronousones. [3] introduced the notion of phased logic, in which eachsynchronous combinational logic gate is replaced with a smallsequential handshaking asynchronous circuit. [1] and [2] usea fully automated synthesis flow which do not change theoverall structure of the synchronous design and show that theresultant asynchronous circuit has similar delay, and energy ascompared to the original synchronous design, while improvingthe timing variations and EMI at the same time. [1] shows a22% area overhead in the desynchronized circuit, however amost of that overhead comes from using latches instead ofregisters. [4] proposed a desynchronization technique whichuses registers instead of latches and has small controllersto decrease the area overhead of desynchronization. Theirproposed technique showed significant power and energyreduction while similar performance as compared to standarddesynchronization using latches as in [1]. To improve theperformance of a desynchronized circuit, Weaver [5], Proteus[6] and [7] have explored the possibility of converting syn-chronous designs into an aggressively pipelined asynchronousimplementations that can exceed 1 GHz in frequency. Whilethese approaches can improve performance in some cases, thecost in area and power can be significant [8]. [9] designeda multiple clock domain micro-architecture using a globally-asynchronous, locally synchronous (GALS) clocking style tosolve the challenges of globally clocked synchronous systemsand showed a performance degradation of less than 4%.

Traditional asynchronous design methodology has the po-tential to achieve better performance than their synchronouscounterparts, because it is data driven and activate only thosepaths in the design which are needed for certain computation.It is challenging to exploit this property when starting froma detailed synchronous design, because the design is createdwith a global clock in mind and it becomes difficult to

2

determine what operations are in fact data-dependent after thedesign has been transformed by logic synthesis tools. Proteus[6] provides support for conditional send and receive primi-tives as a way to reduce power overhead of the baseline flowwith user-intervention as well as some automation support.[10] proposed a tool for synthesizing asynchronous circuitsusing XSTG specifications. Telescopic units [11] breaks downthe critical paths to operate in two clock cycles instead of one,and uses remaining paths to determine clock frequency of theentire design. Varipipe [12] recognizes the fact that all criticalpaths in a synchronous design are not active at the same timeand designs a control circuitry which changes the clock periodevery cycle based on the largest critical path used by any ofthe operations in the pipeline. However, it uses a central clockpulse generator so the clock tree still needs to be synthesizedand clock issues related to spatial-temporal variations, andEMI are not resolved. [13] proposes a variable delay line anduses Mousetrap controllers [14] to desynchronize synchronouscircuits. However, the study was done on a simple linearpipeline of floating point adder which does not consist ofany forks or joins. [15] proposed a resynthesis techniqueto improve the performance of desynchronized bundled datacircuits. A performance improvement of 25% was shown overthe synchronous baselines. However, the circuits used wereinstruction decode and execution units which are much simplerthan entire processor pipelines.

This paper builds on the desynchronization approach forsynchronous to asynchronous conversion, which is knownto produce asynchronous designs that have about the samearea, delay, and energy of their synchronous baseline, butare inherently closed loop and hence, more robust againstsupply voltage, operating temperature and large scale processvariations [1]. We introduce operation-dependent desynchro-nization, a technique that requires minimal designer effort butresults in improved average-case performance while preservingthe core benefits of desynchronization. Our key contributionsare:

1) We identify the performance limitations in existing desyn-chronization approaches, discussing why similar tech-niques do not provide better performance than the cor-responding synchronous design.

2) We propose a novel desynchronization technique whichdoes not modify the datapath of the synchronous designsimilar to the previous approaches, but can perform betterthan the baseline synchronous design.

3) We perform a case study of proposed technique onRISC-V processor pipeline from U. C. Berkeley andshow significant improvement in performance and energyefficiency for many benchmarks.

4) We use standard CAD flow for simulation and synthesisin our proposed approach and hence our approach doesnot required a different CAD tool flow.

The rest of the paper is organized as follows: Section IIdiscusses the traditional desynchronization technique on a toyexample and its limitations, Section III describes the pro-posed desynchronization technique, Section IV discusses thedesynchronization of RISC-V processor pipeline along with

X +R.b

L

L.a

Stage 1 Stage 2

clk1 clk2

R.a

r.b

Rb b

aa

L Rb b

aa

L.b

r.a l.a

l.b

left

buffer

right

buffer

delaydelay

two-place

buffer

Fig. 1: Two stage pipeline for multiply accumulate and theasynchronous control to provide the clock

experimental results, followed by conclusions in Section V.

II. STANDARD DESYNCHRONIZATION

Desynchronization techniques that use standard designtools, replace clock network with an asynchronous circuitwhich is responsible for generating the clock signals. At oneextreme, desynchronization results in a design where each one-bit register has its own clock generated by the asynchronouscontrol, which requires as many asynchronous controls as thenumber of registers and can result in high area and poweroverhead. At the other extreme, entire system uses a singleasynchronous controller that generates one clock for all theregisters—which is same as the synchronous baseline. Toreach a balance between the two extremes, researchers oftenuse a single clock for all registers in a pipeline stage butdifferent clocks for different pipeline stages as in [1] or usesome clustering and separation analysis methods to reducethe controller overhead [16]. These techniques reduce areaand power overheads and at the same time desynchronize thecircuit with low design effort.

A. Desynchronization example

We first explain desynchronization based on pipeline stageson a very simple example of a synchronous multiply-accumulate pipeline which multiplies two inputs and accu-mulates the result as shown in Figure 1. We use asynchronousbuffers to design the asynchronous circuit for generatingclock for each stage. There have been many studies ondifferent asynchronous handshake controllers that can be usedfor desynchronization with different Signal Transition Graph(STG) specifications [1]; we simply use one design throughoutthis paper for simplicity, and the technique can be incorporatedinto other designs without difficulty.

The desynchronization controller that we use is a two-placebuffer with input channel L and output channel R and aninitial token (one-bit), as shown in Figure 1. These buffers havetwo ports on the left channel (L), req port (L.b) to receive acommunication token, and ack port (L.a) to acknowledge thesender about the received token. On the right channel (R), thereq port (R.b) sends the token to the buffer connected to theright and the ack port (R.a) receives the acknowledgement. Todesynchronize the two stage multiply-accumulate example, wedesign an asynchronous control having two two-place buffersfor the two stages connected in a ring as shown in Figure1. Each two-place buffer is made up of two one-place buffers

3

where one buffer starts by waiting for a token on the L channeland then sends the token on the r channel, which we denoteas left buffer. The other buffer starts the communication bysending a token on the R channel and then waits for a tokenon the l channel, which we denote as right buffer, as shownin Figure 1. The following equations show the implementationof both left and right buffers in Communicating HardwareProcesses (CHP) language [17]:

∗ [[L.b];L.a+; [∼ L.b];L.a−; r.b+; [r.a]; r.b−; [∼ r.a]]

∗ [R.b+; [R.a];R.b−; [∼ R.a]; [l.b]; l.a+; [∼ l.b]; l.a−]

The first equation implements a left buffer and the secondimplements a right buffer, + denotes a rising transition, -denotes a falling transition, [] denotes a wait till the signalbecomes true, ; denotes the sequential composition and * atthe beginning means that the same process keeps repeatingforever.

In Figure 1, whenever a right buffer makes a positivetransition on the right request wire (R.b), it also providesa positive edge of the clock to the registers in that stage. Adelay line on the right request wire is used to ensure that ittakes at least the maximum logic delay of the sender stage tocomplete a send to the left buffer of the receiver stage. Oncethe send is complete left buffer in receiver stage can pass thattoken to its right buffer which then initiates a send on its Rchannel and also provides a positive clock edge to the registersof that stage. The delay lines ensure that not only the outputof the combinational logic between the two stages is stable butalso that any combinational logic path internal to a pipelinestage is stable.

In general for correct functionality, any two connectedstages in synchronous design will require a delay line betweentheir asynchronous buffers. The delay for these delay line isset by the maximum of the reg-to-reg delay from source tothe destination stages and intra-stage reg-to-reg delay of thesource. The delay of the gates in the asynchronous controllercan also be taken into account when determining the delayof the explicit delay line. In case of non-linear pipelineswhere the output of one synchronous stage can go to multiplestages, different delay lines are placed between any set ofsource destination pair based on the appropriate path delays.The acknowledgement wire ensures that the data has beencorrectly read by the destination registers, and hence a MullerC-element is used to ensure that the source buffer receives theacknowledgement only after all the destination buffers haveacknowledged. When a destination stage receives data fromtwo or more stages, a Muller C-element on req wire is usedto ensure that the input is read only after the data from allthe sources are stable. This construction is also the basis fordesynchronization [1].

The delay lines are sufficient to ensure that the setup timesof flip-flops are satisfied. To ensure that the hold times are alsosatisfied, one can make a buffer as slow as its neighbour orcan use a handshake controller which accounts for hold time[1]. We use the first approach in our design throughout thispaper.

(a) (b)

Fig. 2: (a) Asynchronous control for a single pipeline stageand (b) timed graph showing the largest algorithmic cycle.

slow

fast

S

S

Out

Outglitch

0

1

I0

I1I1

I0

Fig. 3: A slow multiplexer select signal can result in a glitchcausing spurious handshakes

B. Observations on performance

After desynchronizing the multiply-accumulate pipeline, wedo not observe any improvement in performance. The reasonis even though the delay of the accumulate stage is small,the overall cycle time (time for a complete handshake in theasynchronous ring) is still determined by the longest delayi.e. delay through the multiplier. Thus the desynchronizedpipeline achieves the same performance as the synchronouscounterpart. We realize that any desynchronization technique,whether based on pipeline stages as in [1] or clustering andseparation analysis as in [16], which does not change thesynchronous logic itself and just tries to alter the clock networkcannot perform better than the original synchronous circuit.The worst-case timing path in the clocked implementation is areg-to-reg path that still exists in the design and must appear aspart of some delay line in the system. It is well-known that thethroughput of an asynchronous system where the system hasand-causality (as is the case for the asynchronous controllers)is determined by the maximum cycle mean of the timed eventgraph [18]. Figure 2 shows an asynchronous buffer with atoken connected via wires to an empty buffer on its left andusing a delay to an empty buffer on its right and part of thecorresponding timed event graph. There is a simple cycle witha cycle mean corresponding to the delay line—and hence, themaximum reg-to-reg delay between the two desynchronizationregions. Therefore, for any synchronous design, the largestlogic delay will show up in some cycle in the event rulegraph and hence the throughput will always be limited by themaximum of all the reg-to-reg delays in the circuit—which isthe clock period of the original synchronous circuit.

III. PROPOSED APPROACH

The clock period of a synchronous circuit is set by thelongest path between two registers known as the critical path.When there are a small number of critical paths that areprimarily limiting performance, synchronous designers usepipelining, retiming, clock domain crossing, dynamic time

4

borrowing and various other techniques to improve throughput.These techniques, however, come with the cost of significantdesign effort, area and energy and also may not always befeasible.

A. Design modularity

Most complex designs consist of a large collection ofmodules. Even though timing characterization requires globalanalysis, a chip is broken down into modules for ease ofunderstanding and design. Many times most of the criticalpaths lie in a subset of modules which may not be neededall the time and the active state of those modules can also bedetermined based on the operations being performed in thecurrent cycle. Our proposed operation-dependent desynchro-nization technique focuses on exploiting this observation.

When confronted with a slow module, a designer couldmake major architectural changes to ensure that the slowmodule is no longer on the critical path. Examples of thisinclude re-pipelining the design, or operating the module ina separate clock domain and using clock domain conversionlogic, etc. However, these are very intrusive changes andrequire significant effort. Also, given two modules A and B,with A running at a frequency slightly higher than B, whilehaving many critical paths in B, a designer might have topipeline all of those paths or compromise the frequency of theoverall system. Neither of these are good options if the designeffort, area, energy and power overheads of pipelining cannotbe justified—especially if module B is infrequently used. Thesituation is even worse when the design has a large numberof modules.

In synchronous designs, satisfying timing constraints stat-ically for all paths is a hard constraint which is requiredto run the whole design on a single clock. Current syn-chronous design tools have support for clock gating registersin individual modules to save power and energy when theyare not needed. Designers use valid bits or enable bits toindicate when a section of the logic in their design can beclock gated. While this is highly effective at reducing powerconsumption, it does not help with performance. If we canexploit the information about the active state of the modules,one can imagine designing a clock that can vary its frequencyfrom one cycle to the next based on the dynamic informationabout the active components in the design. This kind ofdynamic frequency scaling can improve the performance ofsynchronous circuits which are designed using single clock.However, designing such a centralized clock is not an easytask since the frequency for each clock cycle is a function ofthe global state of all the modules on that cycle. The set ofpossible configurations that must be considered grows quicklywith the number of modules in the system.

B. Operation-Dependent Desynchronization

Instead, we propose a novel, distributed technique thataccomplishes the same goal that we call operation-dependentdesynchronization. Using only information about a moduleand the operations for which it is active, we create a simplehandshake controller that permits the global system throughput

to dynamically increase when modules that contain the criticalpath are not active. The technique is scalable, and circuitoverhead grows linearly with number of regions where thetechnique is applied.

First of all the synchronous design is partitioned intodesynchronization regions and a two-place buffer is used toprovide clock to each region instead of pipeline stages as instandard desynchronization (Section II). A desynchronizationregion consists of a single module or a group of modules inthe synchronous design. Figure 4 shows a simple example withfive regions each of which has some registers and some com-binational logic. These regions can consist of any synchronousdesign which involves single clock with positive edge triggeredlogic. We will not discuss generated clocks, multiple clocksand latch based designs in this paper, but the proposed tech-niques are generic enough to be adapted for these designs withminor modifications. The regions can however consist of anynumber of pipeline stages connected in any form. All registersin a region are provided the same clock; however, registersin different regions are provided different clocks. The clocksare generated from the asynchronous control shown in Figure4(b). The buffers of different regions communicate with eachother via handshakes based on the topology of the synchronousdesign. If the modules in a region send data to some othermodule in a different region then there exists a communicationchannel between the asynchronous buffers for the two regions.The request wire on the R channel of the buffer of any regionis used as clock for all the modules in that region. To ensurecorrect data delivery a delay line is placed on the request wirebetween the buffers of the sender and receiver stage so that thecommunication token is received by the receiver stage onlyafter the delay requirement corresponding to largest reg-to-reg path in the sender or between the sender and receiverstage is satisfied. Designing a delay line with a predictabledelay is a thoroughly studied problem. A recent reference thatdescribes how to synthesize delay lines that track the delay ofthe combinational logic they are supposed to match is [19]. Alower power and mixed-signal solution for long delay lines is[20].

The performance of this desynchronized design is stilllimited by the worst case reg-to-reg delay as the largestcycle in the timing graph is the one that corresponds to thelongest critical path. To go beyond this performance limit, wemake use of the active state of the different desynchronizationregions. For each region, we assume that we can use theoperations being performed in the synchronous circuit toidentify whether or not the modules in that region are activein the current clock cycle or not. When a module is inactive,its state does not change and hence any path that originatefrom the registers in the module can be ignored when settingthe delay of that region. We replace single delay lines witha set of delay lines and multiplexers which pick the rightdelay line depending upon whether a module is idle or notas shown in Figure 4. This permits the design to operate ata higher frequency, in situations when the part of the systemthat contains the critical path is idle.

Even when all the modules are active, it is possible thatcertain critical paths in a module are required for a particular

5

operation, but can be ignored most of the time. For example, acritical path through multiplier in an in-order pipeline can beignored when there are no multiply instructions in the pipeline.In these scenarios, frequency can still be increased even ifall the modules are active and one can imagine having extradelay lines corresponding to these fast frequencies and logicto determine when such critical paths are inactive.

Finally, we note that in many synchronous designs, de-termining the active state of a module is not a challengingtask. This information is often present in the design in theform of valid signals which are used by design tools forpower optimizations like clock gating etc., or can be easilydetermined by identifying the operations for example, bymatching opcodes in processor pipelines, current cycle countand pipeline initiation interval in case of CGRAs etc. Manyof the modules have pipelined datapaths with valid signals orhave fixed latency which can also be used to determine theactive state of the modules as shown in Figure 5. FSM onthe left corresponds to a module which has a fixed latencyand hence by using an incrementing counter it can be easilydetermined when the module is active or idle. The FSM on theright corresponds to the module which has valid signals in eachpipeline stage. Here idle state of a module can be determinedby combining the valid signals from different stages usingOR logic. The only design overhead that the synchronousdesigners have to pay is to create a small finite state machineas shown in Figure 5 which generates information about theactive state of a module based on operations in the pipelineor various valid signals from different modules. Further, theoutput of the finite state machine responsible for selecting thedelay line using multiplexers should be faster than the fastestof all the delay lines that are input to this multiplexer. Asshown in Figure 3, if the output of the finite state machinegoing into the multiplexer select signal is slower, then a glitchcan appear on the multiplexer output resulting into undesiredhandshakes between the asynchronous controllers. However,this is not a problem most of the time as the logic delay ofthe combinational logic for select signals based on the currentfinite state machine state is quite small as compared to thedelay lines determining the clock period.

IV. CASE STUDY: RISC-V ROCKET CORE

To demonstrate the proposed operation-dependent desyn-chronization technique, we did not want to create our ownsynchronous design and then use it to show improvementsand hence we are demonstrating this idea on the open-sourceimplementation of RISC-V rocket core developed at U. C.Berkeley [21]. We synthesize the RISC-V core using SynopsysDesign Compiler (compile_ultra) and generate standardcell netlist and timing reports using a low power 28nm library.The timing reports show that with a 28nm technology node, thedesign is able to achieve a clock period of 1.8ns i.e. 555 MHzand most of the critical paths are in the floating point unit(FPU), some in the mul-div unit of the core and few inthe control unit corresponding to branch instructions. Ignoringthese units/paths help us achieve a clock period of around1.3ns i.e. a frequency of 770 MHz. As all the instructions in

any application need not be floating point, multiply/divide orbranch, ignoring the slower modules/paths when they are notused can potentially improve the average-case performance.

To determine the desynchronization regions, we first extracta graph whose vertices represent different modules in thedesign, edges represented the existence of a reg-reg pathbetween the two modules and weight on the edges representthe longest reg-reg path delay between the two modules asshown in Figure 6(a). The self-edges represent the longestreg-reg delay within a module. If the self-edge contains apath which can be easily detected at run-time, and the restof the paths have delay significantly less than the self-edge,the self-edge is deprecated to the next largest critical path andtwo delay lines are assigned for these two different criticalpaths. For example, in Figure 6(a), the core module hadcritical paths corresponding to branch instructions which weresignificantly larger than other paths and hence the self-edge(shown as dotted arrow) is deprecated to the second largestdelay of 1.3ns (shown as solid arrow) and an extra delay lineof 1.8ns is added in the asynchronous control. To constructthe module graph, we wrote a python script which parsesthe netlist obtained after the synthesis using Synopsys DesignCompiler. It creates a list of different modules in the designusing the module definitions in the Verilog netlist and thendetermines all reg-to-reg paths between two modules. It thencreates the module graph by assigning a node to each moduleand connecting the nodes using edges when there is reg-to-reg path between two modules. Then weights on the edgesare assigned using the delay of the longest reg-to-reg pathbetween two modules from the timing reports.

Next, this graph is split into three different regions such thateach region gets its own local asynchronous clock generator.Splitting of the graph into different regions is not automated atthis point and has to be done manually. One could use sophis-ticated separation analysis and clustering techniques as in [16]for finding the desynchronization regions that would minimizethe overall controller area. However, for RISC-V rocket core,we assign the modules which are conceptually closer i.e. sharethe same opcode or similar functionality to a single region. Forexample, different units in the floating point unit are assignedto a single region as it becomes easier to detect the activestate of the region just based on the opcode, resulting insmall detection circuit. Since the operations being performedinside the ALU like add, bitwise-and/or/xor, comparisons allresulted in a critical path less than 1.3ns, all of them arecombined together with the Core and assigned to a singledesynchronization region. In case, the critical paths in the ALUhad been significantly different for different operations, onecould split different operations inside the ALU into differentregions as well. In our case, since multiply and divide werethe only operations that had significantly larger critical paths,they are assigned to a different desynchronization region.

The next challenge was to determine when these regionsare active. After studying the RISC-V rocket core design,we realized that the active state of the FPU can be easilydetermined by inspecting the valid bits of the pipeline stagesin the FPU as shown in Figure 5(b). For multiply/divideinstructions, we used the valid bit in the val/rdy interface

6

(a) (b)

A

L R

D

L R

E

L R

B

L R

C

L R

C

C

C

C

C C

(c)

slow

fast

A D

B C E

Fig. 4: (a) Synchronous designs with 5 modules (b) asynchronous controller for clock generation (c) MUX to skip the delaysbetween the modules.

Init

IncCount

ResetCount

in_validcount = latency

Init

ModuleActive

in_valid

anystagevalid

nostagevalid

(a) (b)

Fig. 5: Finite State Machine for (a) modules with fixed latency(b) modules with valid signals. The shaded region representsthe states in which the module is active, in valid is the signalwhich tells whether an input will be fed to the module in thenext cycle or not.

of the multiply/divide module and the pipeline latency tocreate an FSM as shown in Figure 5(a) and used opcodematching for branch instructions. As the cycle period needs tobe scaled up before the instruction enters these modules/paths,a small opcode matching logic was placed in the Fetch stage,which can predict ahead of time whether the instruction isfloating point, multiply/divide or branch and the frequency canbe scaled before the instruction actually gets executed. Thistechnique however has its own drawback—for example, evenwhen the floating-point/multiply/divide/branch instruction isstalled due to some dependency, the processor would still runat a lower frequency even though these units/paths are notbeing used. For simplicity, we use this approach; howeverone can use more complex logic that only indicate whetherthe module/path is going to be active in the very next clockcycle or not. Next, we design the asynchronous handshakecontrollers for the three regions. Figure 6(c) shows the delaylines for region A corresponding to the maximum reg-to-regdelay inside the Core when branch logic is active, when it isinactive, and the maximum reg-to-reg delay of its neighborsB and C. Similarly, delay lines for region B correspond to themaximum reg-to-reg delay within region B and of the neighborA and for region C correspond to maximum reg-to-reg delaywithin C and of neighbor A. To desynchronize the rocket corewe implement the three asynchronous controllers, all the delaylines, C-elements and multiplexers shown in Figure 6(c). Theactive bit from the designed FSMs are used as the selectsignals for the multiplexers. This results in dynamic scaling up

of frequency when instructions being executed on the RISC-Vcore are integer arithmetic/load-store instructions which do notinvolve floating point, multiply, divide, or branch calculationhardware, as shown in the waveform in Figure 7.

To create the asynchronous controller, we design the buffers,delay lines and multiplexer in CHP language and translatethem to the production rules manually as described in [17].After thorough testing using our in-house production rulesimulator, we combine them together and modify the RISC-Vrocket core to use the asynchronous control to provide clockfor different regions. The signals from the designed FSMs arethen connected to the asynchronous control. This joint timedsimulation of asynchronous circuits with synthesized RTL isfacilitated by an integrated simulation tool developed inter-nally that combines a custom asynchronous logic simulatorwith Synopsys VCS. The sdf (Standard Delay Format) fileproduced by the design compiler was used to model the actualgate delays in the design. To make sure that one does not haveto rely on our in-house production rule simulator or integratedsimulation tool, we redesigned all the controllers by re-writingthe production rules in verilog and used Synopsys VCS to testthe entire design.

For all our experiments we used the timing reports generatedafter the synthesis using Design Compiler. However, as theplacement and routing can change the delays of various paths,in a complete flow the proposed desynchronization techniqueshould be applied using post place and route timing reports.Maintaining the delay values is important for the proposeddesynchronization technique to work and hence to achievethat a three step placement approach can be adopted. In thefirst step, the design should go through place and route andthe timing reports should be obtained. These timing reportsshould be used to determine the desynchronization regions. Inthe second step, the synchronous design should go through theplace and route again, but this time asynchronous controllerswith empty cells for delay lines should be placed next to eachdesynchronization region. Local clock tree networks shouldalso be generated to distribute the clock within differentdesynchronization regions. In the last step, delay values shouldbe obtained based on the timing reports from the second stepand delay lines should be placed in the empty cells. Since theentire circuit except the delay lines is placed and routed inthe second step and then delay lines are placed accordingly inthe third step, this three-step placement mitigates convergenceissues.

7

(c)

C

B

A

C

L R

L

RLR

B A

C

C

b

a

b

a

b

a

b

a

b

b

a

a

clkB clkAclkC

1.8

1.3

1.8

1.7

1.8

1.3

1.8

1.7

1.8

1.3

1.8

1.3

1.8

1.7

1.3

Fig. 6: Desynchronization of RISC-V core: (a) shows the module graph, (b) shows the desynchronization regions and clockperiod required for each of them and (c) shows the asynchronous control for clock-generation

1.3 ns 1.8 ns

Fig. 7: Waveform showing the change in clock frequency whenthe muxsel signal goes high

We test and evaluate our design on all the benchmarksprovided in the RISC-V test suite and some from the MiBenchembedded benchmark suite [22]. Figure 8a shows as a fractionof number of cycles how many time a branch or mul/divideor a floating point instruction is being executed in any ofthe processor pipeline stages and Figure 8b shows the per-formance improvement for various benchmarks. It can beseen from Figure 8b that the performance improvement ofint multiply, towers, radix sort, and dhrystone are all > 20%.This is because these benchmarks use integer data-types andhence do not use floating point instructions and also haveless branch and divide instructions. Integer vector-vector add,bitcount, float multiply and matrix multiplication achieve aperformance improvement of 12-17%. This is because thefirst two benchmarks use integer data-types and are not veryheavy in branches, the last two on the other hand use floatingpoint data-types but still have fair fraction of instructionswhich are neither floating point nor a branch or divide. Intmedian, int quicksort, dijkstra and stringsearch, all achievea performance improvement less than 10% as all of thesehad lots of forward and backward branches. Float median,float quick sort, float vector-vector add, float basicmath, FFTand sparse matrix-vector multiplication, all had a lot morefloating point instructions as compared to other floating pointbenchmarks which resulted in a performance improvementof less than 10%. Overall, we achieve a geometric meanimprovement of 12.9% for integer benchmarks and 6.5% forfloating point benchmarks. From Figures 8b and 8a it can beseen that the benchmarks which have less number of floatingpoint, branch and multiply/divide instructions achieve moreperformance improvement. Table I shows the size of data-setsfor different benchmarks.

In terms of area, gate counts for both synchronous processorand asynchronous control are provided in Table II. The tableshows that additional number of gates required to attain this

int median

int multiply

int qsort

towers

int vvadd

dijkstra

stringsearch

rsortdhrystone

bitcount

float median

float multiply

float qsort

float vvadd

basicmath

fft spmvmm

Benchmarks

0.0

0.2

0.4

0.6

0.8

1.0

Instruction types

OTHER B/D FP B/D + FP

(a) Instruction breakdown: B/D and FP are the fraction of times onlybranch/mul-divide instructions and only floating point instruction are inthe pipeline respectively. B/D+FP is the fraction when both branch/mul-divide and floating point instructions are in the pipeline, OTHERSrepresent the remaining instructions

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM GM GM

Benchmarks

0

5

10

15

20

25

30

Perform

ance improvement (%

)

IntegerFloating Point

(b) Percentage improvement in performance for various benchmarks

Fig. 8: Instruction breakdown and performance improvementfor various benchmarks in RISC-V and MiBench suites

performance improvement is just 0.3% and is very smallcompared to the original RISC-V design.

We performed a thorough power-estimation of both syn-chronous and desynchronized designs using the value changedump (vcd) files produced by our simulations and the time-based power analysis in Synopsys Prime-Time. Figure 9 showsthe power consumption of synchronous and desynchronized

8

TABLE I: Dataset sizes for different benchmarks

Benchmark Suite Data-type Dataset sizeMedian RISC-V float 400

int 400Multiply RISC-V float 100

int 100Qsort RISC-V float 2048

int 2048Towers RISC-V int 7 discsVvadd RISC-V float 300

int 300Dijkstra MiBench int 100 nodesStringsearch MiBench int 60Rsort RISC-V int 2048Dhrystone RISC-V int size 50, runs 500Bitcount MiBench int 7500 iters, 7 funcsBasicmath MiBench float –FFT MiBench float 32Spmv RISC-V float 1000 × 1000, density 0.01Matrix-mult RISC-V float 6 × 6

TABLE II: Gate count for the RISC-V processor pipeline,designed FSM and asynchronous circuit

Logic Number of GatesFSM 103

Async Control 150RISC-V Core + FPU 79,116

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM

Benchmarks

0

2

4

6

8

10

Power (m

W)

Sync Async

Fig. 9: Power consumption of synchronous pipeline and desyn-chronized pipeline

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM

Benchmarks

0

2

4

6

8

10

12

14

16

18

Power (m

W)

DVFS Async

Fig. 10: Power consumption of synchronous pipeline anddesynchronized pipeline, where the synchronous pipeline isrunning at a higher voltage and frequency (DVFS state) tomatch the performance of desynchronized pipeline for eachbenchmark

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM

Benchmarks

0

10000

20000

30000

40000

50000

60000

70000

80000

En

erg

y E

ffic

ien

cy (ops/uJ) DVFS Async

Fig. 11: Energy efficiency (#dynamic instructions/Energy)of synchronous pipeline and desynchronized pipeline, wherethe synchronous pipeline is running at a higher voltage andfrequency (DVFS state) to match the performance of desyn-chronized pipeline for each benchmark

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM GM GM

Benchmarks

0

2

4

6

8

10

12

14Performance improvement (%

)

IntegerFloating Point

(a) Performance improvement of the desynchronized design running atlower voltage and frequency to achieve same power as synchronousdesign.

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM

Benchmarks

0

20000

40000

60000

80000

100000

En

erg

y E

ffic

ien

cy (ops/uJ) Sync Async

(b) Energy efficiency (#dynamic instructions/Energy) comparison ofsynchronous design and desynchronized design running at lower volt-age and frequency to achieve same power consumption as synchronousdesign.

Fig. 12: Performance and energy efficiency comparison of syn-chronous pipeline and desynchronized pipeline where desyn-chronized pipeline is running at a lower voltage and frequencyto have the same power consumption as the synchronouspipeline

9

pipelines. Since, increasing frequency at the same voltage toget higher performance also increases the power consumption,the desynchronized version is consuming more power thansynchronous design. From Figure 9, it can be seen that theincrease in power is as high as 20-30% for int-multiply, int-vvadd, towers, rsort and dhrystone benchmarks, for whichour technique provides the best performance results as well.For the benchmarks with low performance improvement, thepower consumption also does not increase much.

To perform a fair comparison between the synchronousand desynchronized version, for each benchmark we used theDVFS voltage-frequency curve as in [23] to scale up thevoltage and frequency of synchronous design and estimatethe power consumption when both synchronous and desyn-chronized designs achieve the same performance as shown inFigure 10. Here, the desynchronized circuit is operating at1V supply voltage and clock frequencies of 555 MHz, 588MHz and 770 MHz (corresponding to 1.8ns, 1.7ns and 1.3nstiming paths). For synchronous design as different benchmarksrequired different voltages and frequencies in order to matchthe performance of the desynchronized design, voltage andfrequency numbers for all the benchmarks not provided. Theoriginal original supply voltage and clock frequency overwhich DVFS scaling was performed was 1V and 555 MHz.To compare the synchronous and desynchronized designs forenergy efficiency which is defined as number of instruc-tions executed per unit µJ , we used the power consumptionfrom Figure 10 and execution time to determine the energyconsumption for desynchronized design and the synchronousdesign running at higher frequency and voltage. We usedthe dynamic instruction count and the energy consumption todetermine the energy efficiency for the two designs as shownin Figure 11. As one can see, desynchronized design is moreenergy efficient than the synchronous design running at highervoltage and frequency to achieve same performance.

In order to compare the synchronous and desynchronizeddesigns under same power consumption, we scaled down thevoltage and frequency of the desynchronized design using [23]and estimated the performance and energy efficiency of thetwo designs. Figure 12a shows the performance improve-ment of desynchronized design running at lower voltage andfrequency over the synchronous design with same powerconsumption. Here synchronous design is operating at 1Vsupply voltage and 555 MHz clock frequency. Figure 12bshows energy efficiency for both synchronous design and thedesynchronized design running at lower voltage and frequency.It can be seen that under same power consumption, desynchro-nized design has a higher performance and energy efficiencythan the synchronous design. For all our experiments, powerconsumption does not include clock tree network. As clockis one of the major components of power consumption insynchronous designs (around 40%) [24], we expect that thedesynchronized design will have lower power consumptionthan the synchronous design.

To compare our proposed approach against the previouswork of telescopic units [11], we evaluated the performanceimprovement of all of the benchmarks using telescopic unitsand compared it with the performance improvement of our

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM GM GM

Benchmarks

0

5

10

15

20

25

30

Perform

ance improvement

over Telescopic (%)

Integer Floating Point

Fig. 13: Performance improvement over Telescopic Units

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM GM GM

Benchmarks

0

2

4

6

8

10

12

14

Performance improvement (%

)

IntegerFloating Point

(a) Performance improvement of the desynchronized design over ClockDomain Crossing.

int median

int multiply

int qsort

towers

int vvadd

dijkstra

Stringsearch

rsortDhrystone

Bitcount

float median

float multiply

float qsort

float vvadd

basicmath

FFTSPMV

MM

Benchmarks

0

10000

20000

30000

40000

50000

60000

70000

80000

Energy Efficiency (ops/uJ) CDC Async

(b) Energy efficiency (#dynamic instructions/Energy) of synchronousdesign with three clock domains and desynchronized pipeline.

Fig. 14: Performance and energy efficiency comparison ofdesynchronized design over Clock Domain Crossing whereregions A, B and C in Figure 6 are put in different clockdomains and are connected using synchronizers.

proposed approach. From Figure 13, it can be seen that ourproposed approach is able to outperform telescopic units inall the cases. The reason behind this is quite simple – sincetelescopic units runs the design at a high frequency and usestwo cycles instead of one for slow operations, it can increasethe time taken for a slow operation and if the application isfull of operations that require the slow clock, it can cause anegative impact on the performance. Telescopic units is knownto improve overall throughput only when the long latencypaths have low occurrence probability [11] which is not truefor these benchmarks. The proposed approach, on the otherhand uses the exact amount of delay that would be required for

10

any operation and hence does not over or under estimate thedelay requirements. To compare our design against varipipe[12], we realize that varipipe has the potential to achievethe same performance as our proposed design. However, ituses a centralized clock generator, and delay lines from allunits have to be combined centrally, whereas our scheme isdistributed and only requires the interaction between delaylines of communicating blocks. Further, a centralized clockgenerator also doesn’t solve the issues of spatial-temporalvariations and EMI in the clock and lacks the key benefits ofdesynchronization as shown in [1]. To compare our proposedmethodology with Multiple clock domains or Clock DomainCrossing (CDC), we realize that CDC assigns different clocksto different regions of the circuit and use synchronizers tocommunicate signals between different clock domains. CDCis good for the designs where the communication betweendifferent clock domains is less. However, for the processordesign like RISC-V core, keeping FPU and main core indifferent clock domains is not beneficial as the FPU can befrequently used by many benchmarks and adding synchro-nizer increases latency of FPU which in turn decreases thethroughput. For example, if an instruction is dependent ona floating point instruction whose latency increases due tothe overhead of synchronizers, the performance of the systemwill suffer. However, for an approach like ours there is nooverhead of synchronizers. Further, CDC requires intrusivedesign changes, for example if there is some combinationallogic on the path from one register in one clock domain toanother register in another clock domain, a register has to beplaced after the combinational logic to avoid the probabilityof failure due to glitches [25]. Due to the potential problemsof metastability, the integration of different clock domains isconsidered much more difficult compared to the integration ofvarious asynchronous modules [24]. Figure 14a and 14b showthe performance improvement of the desynchronized RISC-V core over the design with multiple clock domains. Thedesign with multiple clock domains consists of three clockdomains for each of the regions A, B, and C in Figure 6. Atwo cycle synchronizer delay is modeled between any twoclock domains. As we can see the desynchronized designoutperforms design with multiple clock domains and alsohas a better energy efficiency. Dynamic time borrowing isanother technique where registers are split into latches andthese latches are moved around to balance the combinationalpath delay in each stage, so that the circuit achieves theaverage case performance instead of worst case performance.However, dynamic time borrowing adds a lot many timingconstraints which sometimes makes the synthesis process moredifficult [26], while our proposed approach does not add tothe complexity of the synthesis process. In dynamic timeborrowing, for any latch in the system the data must arrivein time to be properly captured and as time for data arrival isa function of all the previous pipeline stages, a worst case dataarrival analysis is done which requires calculating the timingof all the stages that share a path. The complexity grows forthe circuits that have loops [26]. To compare our proposedapproach against [4], we realize that this work focuses ondesynchronizing a synchronous circuit with negligible area

overhead and potential power consumption reduction. How-ever, it achieves the same performance as the synchronouscounterpart. This work is orthogonal to our work since it doesnot focus of dynamically skipping the critical paths which arenot active, however, the technique in [4] combined with ourtechnique can provide potential savings in power and high-performance at the same time. TonyChopper [27] provided adesynchronization package that uses the standard cell librariesand reduces the leakage power. However, it results into adesynchronized circuit which could be 2.4× slower thansynchronous baseline and can have an area overhead as largeas 2.4× which is very high as compared to 0.3% area overheadin our proposed approach.

Although we have shown the application of the proposeddesynchronization technique in the context of microproces-sors, it can also be applied to complex synchronous circuitsespecially those generated through high-level synthesis (HLS).HLS takes source program in languages like C, C++, OpenCLetc and generates hardware circuits in the form of HDLsfor both FPGAs and ASICs. This high-level specificationmany times consists of if-else branches and HLS generatescircuit for both true and false branches. The circuit forthese branches becomes active based on the dynamic branchcondition. If both the branches have different critical paths,one can think of using the branch condition to determinethe active state of the two branches and put the branchesin different desynchronization regions. For circuits designedwith Register-Transfer Level (RTL), if certain hardware blockis conditionally used, then the designer can provide a signalindicating the active state of the block and the proposedtechnique can be used for dynamically scaling the frequencyto achieve better performance.

V. CONCLUSION

In this paper, we discussed the reasons that restrict tra-ditional desynchronization techniques from improving theperformance of synchronous designs. We proposed a noveloperation-dependent desynchronization technique, which usesthe information about active modules in a synchronous designand dynamically scales frequency to achieve a higher through-put. As achieving a higher frequency for every part of thedesign is essential to improve overall throughput, the proposedtechnique provides a way to combine various designs builtunder different constraints without sacrificing performance.

ACKNOWLEDGMENT

This research was supported in part by NSF Awards#1065307.

REFERENCES

[1] J. Cortadella, A. Kondratyev, L. Lavagno, and C. P. Sotiriou, “Desyn-chronization: Synthesis of asynchronous circuits from synchronousspecifications,” IEEE Trans. on Computer-Aided Design of IntegratedCircuits and Systems, vol. 25, no. 10, pp. 1904–1921, 2006.

[2] N. Andrikos, L. Lavagno, D. Pandini, and C. P. Sotiriou, “A fully-automated desynchronization flow for synchronous circuits,” in DesignAutomation Conference, 2007. DAC’07. 44th ACM/IEEE. IEEE, 2007,pp. 982–985.

11

[3] D. H. Linder and J. Harden, “Phased logic: Supporting the synchronousdesign paradigm with delay-insensitive circuitry,” IEEE Transactions onComputers, vol. 45, no. 9, pp. 1031–1044, 1996.

[4] F. Bertrand, A. Cherkaoui, J. Simatic, A. Maure, and L. Fesquet, “Car:On the highway towards de-synchronization,” in Electronics, Circuitsand Systems (ICECS), 2017 24th IEEE International Conference on.IEEE, 2017, pp. 339–343.

[5] A. Smirnov, A. Taubin, and M. Karpovsky, “Automated pipelining inasic synthesis methodology: Gate transfer level,” in IWLS 2004 thirteenthinternational workshop on logic and synthesis. Citeseer, 2004.

[6] P. A. Beerel, G. D. Dimou, and A. M. Lines, “Proteus: An asic flow forghz asynchronous designs,” IEEE Design and test of Computers, vol. 28,no. 5, pp. 36–51, 2011.

[7] R. Manohar, “Systems and methods for performing automated conver-sion of representations of synchronous circuit designs to and from repre-sentations of asynchronous circuit designs,” 2009, uS Patent 7,610,567.

[8] F. Akopyan, C. Otero, and R. Manohar, “Hybrid synchronous-asynchronous tool flow for emerging vlsi design.” IEEE, 2016.

[9] G. Semeraro, G. Magklis, R. Balasubramonian, D. H. Albonesi,S. Dwarkadas, and M. L. Scott, “Energy-efficient processor design usingmultiple clock domains with dynamic voltage and frequency scaling.”High-Performance Computer Architecture, pp. 29–40, 2002.

[10] F. Mendes, T. Curtinhas, D. L. Oliveira, H. A. Delsoto, and L. A.Faria, “A novel tool for synthesis by direct mapping of asynchronouscircuits from extended stg specifications,” in VLSI Design and 201817th International Conference on Embedded Systems (VLSID), 2018 31stInternational Conference on. IEEE, 2018, pp. 451–452.

[11] L. Benini, E. Macii, M. Poncino, and G. De Micheli, “Telescopic units:A new paradigm for performance optimization of vlsi designs,” IEEETrans. on Computer-Aided Design of Integrated Circuits and Systems,vol. 17, no. 3, pp. 220–232, 1998.

[12] N. Toosizadeh, S. G. Zaky, and J. Zhu, “Varipipe: low-overhead variable-clock synchronous pipelines,” in Computer Design, 2009. ICCD 2009.IEEE International Conference on. IEEE, 2009, pp. 117–124.

[13] J. Xu and H. Wang, “Desynchronize a legacy floating-point adder withoperand-dependant delay elements,” in Circuits and Systems (ISCAS),2011 IEEE International Symposium on. IEEE, 2011, pp. 1427–1430.

[14] M. Singh and S. M. Nowick, “Mousetrap: High-speed transition-signaling asynchronous pipelines,” IEEE Trans. on Very Large ScaleIntegration (VLSI) Systems, vol. 15, no. 6, pp. 684–698, 2007.

[15] A. Saifhashemi, D. Hand, P. A. Beerel, W. Koven, and H. Wang,“Performance and area optimization of a bundled-data intel processorthrough resynthesis,” in Asynchronous Circuits and Systems (ASYNC),2014 20th IEEE International Symposium on. IEEE, 2014, pp. 110–111.

[16] A. Davare, K. Lwin, A. Kondratyev, and A. Sangiovanni-Vincentelli,“The best of both worlds: The efficient asynchronous implementation ofsynchronous specifications,” in Proceedings of the 41st annual DesignAutomation Conference. ACM, 2004, pp. 588–591.

[17] A. J. Martin, “Synthesis of asynchronous vlsi circuits,” CALIFORNIAINST OF TECH PASADENA DEPT OF COMPUTER SCIENCE, Tech.Rep., 2000.

[18] S. M. Burns, “Performance analysis and optimization of asynchronouscircuits,” 1991.

[19] A. Moreno and J. Cortadella, “Synthesis of all-digital delay lines,”in Asynchronous Circuits and Systems (ASYNC), 2017 23rd IEEEInternational Symposium on. IEEE, 2017, pp. 75–82.

[20] Y. Chen, R. Manohar, and Y. Tsividis, “Design of tunable digital delaycells,” in Custom Integrated Circuits Conference (CICC), 2017 IEEE.IEEE, 2017, pp. 1–4.

[21] K. Asanovic, R. Avizienis, J. Bachrach, S. Beamer, D. Biancolin,C. Celio, H. Cook, D. Dabbelt, J. Hauser, A. Izraelevitz et al., “Therocket chip generator,” EECS Department, U. C. Berkeley, Tech. Rep.UCB/EECS-2016-17, 2016.

[22] M. R. Guthaus, J. S. Ringenberg, D. Ernst, T. M. Austin, T. Mudge, andR. B. Brown, “Mibench: A free, commercially representative embeddedbenchmark suite,” in Workload Characterization, 2001. WWC-4. 2001IEEE International Workshop on. IEEE, 2001, pp. 3–14.

[23] “TI-DVFS,” http://www.ti.com/lit/an/slva646/slva646.pdf.[24] M. Krstic, E. Grass, and X. Fan, “Asynchronous and gals design-

overview and perspectives,” in CAS (NGCAS), 2017 New Generationof. IEEE, 2017, pp. 85–88.

[25] S. Churiwala and S. Garg, Clock Domain Crossing (CDC). New York,NY: Springer New York, 2011, pp. 73–89.

[26] V. G. Oklobdzija, V. M. Stojanovic, D. M. Markovic, and N. M. Nedovic,Digital System Clocking: High-Performance and Low-Power Aspects.Piscataway, NJ, USA: IEEE Press, 2003.

[27] Z. Wang, X. He, and C. M. Sechen, “Tonychopper: A desynchronizationpackage,” in Proceedings of the 2014 IEEE/ACM International Confer-ence on Computer-Aided Design. IEEE Press, 2014, pp. 446–453.

Nitish Srivastava Nitish Srivastava (S’18) receivedthe B.Tech degree from Indian Institute of Technol-ogy, Kanpur, India in the department of ElectricalEngineering in 2014. Since 2014, he is a PhD stu-dent in the Department of Electrical and ComputerEngineering at Cornell University.

His current research interests are spatial hardwarefor high performance computing, FPGAs and circuitdesign.

Rajit Manohar Rajit Manohar (M’98-SM’10) is theJohn C. Malone Professor of Electrical Engineeringand Professor of Computer Science at Yale. Hereceived his B.S. (1994), M.S. (1995), and Ph.D.(1998) from Caltech. He was on the Cornell fac-ulty from 1998 to 2016, where he was a StephenH. Weiss Presidential Fellow. He has been on theYale faculty since 2017, where his group conductsresearch on the design, analysis, and implementationof self-timed systems. He founded the ComputerSystems Lab at both Cornell and Yale. He is the

recipient of an NSF CAREER award, nine best paper awards, nine teachingawards, and was named to MIT technology review’s top 35 young innovatorsunder 35 for contributions to low power microprocessor design. His workincludes the design and implementation of a number of self-timed VLSI chipsincluding the first high-performance asynchronous microprocessor, the firstmicroprocessor for sensor networks, the first asynchronous dataflow FPGA,the first radiation hardened SRAM-based FPGA, and the first deterministiclarge-scale neuromorphic architecture.