Reset mechanism conversion

Methods, circuits, and systems for converting reset mechanisms in a synchronous circuit design into a corresponding asynchronous representation are described. These may operate to convert synchronous state holding blocks that include reset signals to corresponding asynchronous dataflow logic blocks. A replicated reset token at a fraction of the operational frequency of the reset signal may be distributed to the locations of the asynchronous dataflow logic blocks. Additional methods, circuits, and systems are disclosed.

BACKGROUND

Traditional synchronous circuit designs may be represented using a variety of hardware description languages, higher level description languages, netlists, and schematics. All of these synchronous representations define the functionality of the circuits in the presence of a timing signal used to synchronize operations. Synchronous operations have several advantages, including deterministic behavior, simplified design and testing, and portability. However, there are also occasions when it is desirable to make use of asynchronous operations.

DETAILED DESCRIPTION

Example methods and systems for converting a reset mechanism in a synchronous circuit design into a corresponding asynchronous representation will now be described. In the following description, numerous examples having example-specific details are set forth to provide an understanding of example embodiments. It will be evident, however, to one of ordinary skill in the art that the present examples may be practiced without these example-specific details, and/or with different combinations of the details than are given here. Thus, specific embodiments are given for the purpose of simplified explanation, and not limitation.

Some example embodiments described herein may include a method comprising converting a synchronous circuit design having synchronous state holding blocks into an equivalent asynchronous design using a processor. The processor may be used to identify synchronous state holding blocks that include a reset signal. As part of the conversion process, these synchronous state holding blocks may be converted to corresponding asynchronous dataflow logic blocks that include reset inputs.

Nodes in the dataflow graph that describes an asynchronous circuit operate on data values, referred to as tokens. A token may comprise a data item that can flow through a pipeline. A token may comprise a one-bit value or a multi-bit value. In some embodiments, a replicated reset token may be distributed to the asynchronous dataflow logic block locations. The replicated reset token may operate at a fraction of the operational frequency of the reset signal. Conversion of synchronous circuits that can be performed in this way, and in other ways, will now be described.

FIG. 1is a diagram illustrating reset signal120distribution in a synchronous netlist100of a synchronous circuit, according to various embodiments of the invention. The synchronous netlist100may include a number of synchronous state holding blocks150(e.g. flip-flops). A reset signal120may be distributed to reset inputs of the synchronous state holding blocks150. The reset signal120may be used to synchronize the synchronous state holding blocks150by resetting clocks in each of the corresponding clock domains.

FIG. 2is a diagram illustrating reset signal distribution in an asynchronous netlist200corresponding to the synchronous netlist100ofFIG. 1, according to various embodiments of the invention. The asynchronous netlist200may result from conversion of the synchronous netlist100into a functionally equivalent corresponding asynchronous netlist. A high-level flow for the conversion method is shown inFIG. 5and will be described below. Each of the state holding blocks150ofFIG. 1may be converted to an equivalent dataflow logic block250. Dataflow logic blocks that can be used in conversion of synchronous circuits are shown and described below with respect toFIG. 6.

The synchronous to asynchronous conversion operation preformed to convert the synchronous netlist100into the asynchronous netlist200can be effected so that the reset mechanism itself remains unchanged. That is to say, the same reset signal120ofFIG. 1can first be converted to a reset token220and distributed to the reset inputs of the dataflow logic block250in the asynchronous netlist200. However, a drawback of this scheme may relate to the inefficiency introduced by copying the reset token220to a large number of destinations, even though most of the time the reset signal120ofFIG. 1is known to be inactive.

For example, this may result in an increase in power consumption, as well as a problem in routing copies of the reset token220to a large number of destinations. In the worst case, the reset token can be copied to dataflow logic blocks250corresponding to every state holding block150ofFIG. 1including a clock domain that uses the reset signal120. Thus, additional approaches for converting the reset mechanism in a synchronous design into an equivalent asynchronous representation will be described.

FIG. 3is a diagram illustrating reset signal distribution in a modified asynchronous netlist300of the synchronous circuit ofFIG. 1, according to various embodiments of the invention. The modified asynchronous netlist300may be distinguished from the asynchronous netlist200in two ways. First, a replicated reset token320may be distributed through the modified asynchronous netlist300. Second, the dataflow logic block250may be modified as shown with respect to block350ofFIG. 3.

The proposed modification in the reset token may comprise a reduction in the operational frequency of the reset token220by a fixed (e.g., 8), or programmable factor to generate the replicated reset token320. This can be implemented by the introduction of special circuitry to handle the operational frequency conversion at the input point where the reset signal120is initially be received. The operational frequency conversion may be performed by using a wrap-around counter or other methods known in the art. At the reset token destination, such as the location of the dataflow logic block250ofFIG. 2, an upsampler340, as shown in block350and described in more detail with respect toFIG. 9, upsamples the reset token320by the same factor and provides it to the dataflow logic block250.

FIG. 4is a diagram illustrating synchronous and asynchronous reset token distributions in an asynchronous circuit400, according to various embodiments of the invention. Some of the state holding blocks in the asynchronous circuit400, for example, the logic circuits480, may receive asynchronous reset signals485, whereas others, such as the logic circuits460, may be synchronized with synchronous reset signals465. According to example embodiments, the asynchronous reset signal465may be provided by frequency divider440, which divides the operational frequency of a synchronous reset signal420. The resulting fraction may be a fixed number (e.g., 8) or a programmable variable.

The asynchronous reset signal485may be produced from the asynchronous reset signal430using the clock converter450. Since the asynchronous reset signal485may not be in the same clock domain as the logic circuits480, an interface circuit such as the clock converter450may be used to convert the operational frequency of the asynchronous reset signal485into the operational frequency of a clock domain corresponding to the logic circuits480.

In some example embodiments, the clock converter450may, in addition, perform the role of the frequency divider440and divide the converted frequency of the asynchronous signal by the same fraction. The logic circuits460and480may be designated as part of an asynchronous netlist resulting from conversion of synchronous netlists comprising state holding blocks. The process of converting synchronous netlists to asynchronous netlists will be described in the followingFIGS. 5 to 7.

FIG. 5is a block diagram illustrating a system500for converting a synchronous netlist to an asynchronous netlist, according to various embodiments of the invention. An input to the system500may be described in an existing hardware-description language (HDL)510such as Verilog512, VHDL514, or any other language that may be supported by the synchronous synthesis tools506. Existing tools501can be used to simulate the high-level description, as well as synthesize it into a synchronous netlist (block515) in a variety of formats including electronic design interchange format (EDIF) such as EDIF200.

An EDIF reader tool502has been implemented that takes the EDIF as input, as well as a table that specifies “black-box” modules in the EDIF (e.g. the EDIF cell name “AND2” which comprises a two-input AND gate, etc.) and some details about the EDIF format that may vary from one synthesis tool to the other. The conversion from EDIF into a standardized netlist format may be done in a standard process507. The final output of the EDIF reader tool502may be a synchronous netlist508. The synchronous netlist508may then be converted to an asynchronous netlist504using the synchronous to asynchronous conversion module503. The resulting asynchronous implementation may be equivalent to the synchronous one in terms of the computations performed.

As is known in the art, the .conf file in tool502may comprise a configuration file used to specify the output format of the synthesis tool, while the .xl file may be a library file containing the description of the library elements used by the synthesis tool. The .anf file contains the resulting synchronous netlist508. Any file formats can be used to specify this information, or the information could be built into the conversion tool507itself. The synchronous netlist508may then be converted to an asynchronous netlist504using the synchronous to asynchronous conversion module503, the asynchronous format, for example, in the form of a dataflow graph. The resulting asynchronous implementation may be equivalent to the synchronous one in terms of the computation performed.

The described conversion system may operate to generate annotations that translate the performance characteristics of the asynchronous implementation back into the synchronous domain using an annotation generator505for validating the timing design of the dataflow graph according to the specifications of the original synchronous representation. This can be performed, for example, by the simulation block520.

The conversion system500described above enables the conversion of a synchronous netlist into an asynchronous implementation, as well as the generation of an annotation that maps the performance characteristics from the asynchronous domain into the synchronous domain. The synchronous netlist may be converted into other formats, in addition to a dataflow graph, including the detailed description of the implementation of the dataflow graph using Verilog or VHDL, or even other high-level languages such as SystemC, Handel C, or C augmented with message-passing operations. The details of the language are not restrictive, as will be evident to a person of ordinary skill in the art after reading this disclosure.

The target asynchronous netlist represents circuits that can be implemented efficiently as fine-grained asynchronous pipelines or synchronous dataflow pipelines. The target netlist may be represented as a dataflow graph.

Operators in the dataflow graph receive tokens on their inputs and produce tokens on their outputs. The change in the value of the token may be used to compute results. Connectivity between operators may be specified by arrows that correspond to communication channels along which tokens can be sent and received. Communication channels may not be buffered, so that sending and receiving a token on a channel corresponds to rendezvous synchronization. The basic building blocks of a dataflow graph are shown in and described now with respect toFIG. 6

FIG. 6is a diagram illustrating asynchronous dataflow blocks600for converting a synchronous netlist to a corresponding asynchronous netlist, according to various embodiments of the invention. A unit that can be used for computation may comprise a function block601, which has an arbitrary number of inputs and one output. The function block601receives tokens from at least some of its inputs, computes a specified function, and produces the result of the function as an output token on its output. There can be many different types of function blocks that vary in the number of inputs they have, and in the operations they perform. A source604may comprise an operator that generates an infinite stream of tokens on its output that always have the same value. A sink605may comprise an operator that consumes any input token.

A copy606is block that replicates the token received on its input to all its outputs. An initial block607begins by transmitting a token on its output, and thereafter copies any input token to its output. These blocks601,604,605,606, and607repeatedly receive tokens on their respective inputs, and send tokens on their respective outputs. The merge block602has two types of inputs: data inputs (like every other block), and a control input608. The value of the control input608specifies the data input from which a token may be received. This token may then be sent on the output of the merge block602.

A split block603has a dual function. It receives a control value on its control input609, and a data value on its data input. It sends the data value on the output channel specified by the value of the control input. As is known in the art, a data flow graph may comprise a graphical representation of the flow of data through an information system, such as an asynchronous circuit or gate array. As described above, the various elements shown inFIG. 6may comprise the basic building blocks for constructing data flow graphs, some of which are described below.

FIG. 7is a diagram illustrating a synchronous state holding block700, according to various embodiments of the invention. In converting the synchronous netlist507ofFIG. 5into the asynchronous netlist504ofFIG. 5, when the synchronous netlist507contains a state holding block, perhaps comprising a positive edge-triggered flip-flop and combination logic, the transformation may be performed in two operations, as follows: (1) replace every combinational logic gate with a dataflow function block (e.g., dataflow function block601ofFIG. 6), where the function implements the truth-table of the logic gate; and (2) replace every state holding block (e.g., the positive edge-triggered flip-flop) with an initial block (e.g., initial block607ofFIG. 6) having an initial token that corresponds to the initial value of the flip-flop. The resulting asynchronous dataflow graph may be a valid implementation of the synchronous circuit, and the operations described above would produce this graph. In the case of state holding blocks coupled to gated clocks, such as the state holding block700inFIG. 7, coupled to a data input701and a clock enable (CE) signal703, the conversion may be performed, for example, by eliminating the gating and using a multiplexer(MUX)-transformation as described below with respect toFIG. 8

FIG. 8is a diagram illustrating an asynchronous equivalent800of the state holding block shown inFIG. 7, according to various embodiments of the invention. The asynchronous equivalent800of the state holding block700includes the MUX805(e.g., the merge dataflow block602ofFIG. 6). The original output Q, i.e., the output Q of the state holding block700of FIG.7,may be connected to the “0” input of the MUX805. The original input802, i.e., the input701ofFIG. 7, may be connected to the “1” input of the MUX805. Finally, the original CE signal, i.e., the CE signal703ofFIG. 7may be connected to the control input804of the MUX805.

The asynchronous equivalent800implements the same computation as the original state holding block700ofFIG. 7. In other words, the MUX805implements processing in which the output does not depend on the value of some of the input signals. For example, when the CE signal connoted to the control input804is low, the output of the MUX does not depend on the signal802. Similarly, when CE signal is high, the output does not depend on the value of signal Q.

FIG. 9is a diagram illustrating modified asynchronous dataflow block900of the state holding blocks250shown inFIG. 2, according to various embodiments of the invention. The modified asynchronous dataflow block900may be considered as a modified version of an initial block. The modified asynchronous dataflow block900may include an initial block940that corresponds to the state holding block250as well as other blocks that perform frequency conversion, including an upsampler960, a local reset value register950, and a MUX970. The input token910and the output token920may comprise the original input and output tokens of the state holding block250ofFIG. 2and the replicated reset token930represents the replicated reset signal distributed to the reset input of the state holding block250.

The upsampler960converts the operational frequency of the replicated reset tokens930back to its original frequency (e.g., substantially the same as the operational frequency of the reset signal). The upsampler960may also update the local reset value register950with the current value965of the replicated reset token (e.g., the upsampled replicated reset token). The upsampler960may be implemented by one or more counters as is known by one of ordinary skill in the art. In an example embodiment, two or more of the modified asynchronous dataflow block900may operate to share upsamplers and/or local reset value registers950.

The MUX970may be controlled by the local reset value at its control input980. For example, when the local reset value is logically true, the MUX970may produce a MUX output token with the same value as the initial token (e.g., the previous value of the input945of the initial t block940), which may then be copied by the initial block940to the output token920. Otherwise, the MUX970may produce a MUX output token with the same value as the input token910just received. Operation in a reverse fashion (e.g., a logical false reset value produces a MUX output token with the same value as the input token) is also possible. This MUX output may be copied to output token920by the initial block940.

FIG. 10is a flow diagram illustrating a method1000of converting a reset mechanism in a synchronous circuit design into a corresponding asynchronous representation, according to various embodiments of the invention. At operation1010, a processor (e.g. the processor1160ofFIG. 11) may identify synchronous state holding blocks150ofFIG. 1that include reset signals such as the reset signal120ofFIG. 1, connected to their reset inputs. At decision block1015, if the processor can not identify such a state holding block, the method1000may be terminated. Otherwise, at operation1020, the synchronous to asynchronous converter module503ofFIG. 5may convert each of the synchronous state holding blocks150to corresponding asynchronous dataflow logic block250ofFIG. 2that includes a reset input that receives the reset signal220ofFIG. 2.

At operation1030, the replicated reset token320may be distributed to the location of the asynchronous dataflow logic blocks350ofFIG. 3. The operational frequency of the replicated reset token320ofFIG. 3may be a fraction of the operational frequency of the reset signal120ofFIG. 1. Some of the synchronous state holding blocks such as the ones included in logic circuits480of theFIG. 4, may be identified by the processor1160ofFIG. 11as having an asynchronous reset signal (e.g., a synchronous reset signal485ofFIG. 4). The clock converter450ofFIG. 4may convert the operational frequency of the asynchronous reset signal430ofFIG. 4to an operational frequency of a clock domain corresponding to the asynchronous state holding blocks included in the logic circuits480. Any of the methodologies discussed above, and in other parts of this description, may be executed by a processor1160of a system1100discussed below.

FIG. 11shows, a diagram illustrating a system1100, according to various embodiments of the present invention. The system1100comprises a set of instructions that can be executed to cause the system1100to perform any one or more of the methodologies discussed herein. In alternative embodiments, the system1100may operate as a standalone device or may be connected (e.g., networked) to other systems. In a networked deployment, the system1100may operate in the capacity of a server or a client system in a server-client network environment or as a peer system in a peer-to-peer (or distributed) network environment. System1100may be realized as a specific machine in the form of a computer.

The system1100may be a server computer, a client computer, a personal computer (PC), a tablet PC, or any system capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that system. Further, while only a single system is illustrated, the term “system” shall also be taken to include any collection of systems that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example system1100may include the processor1160(e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory1170and a static memory1180, all of which communicate with each other via a bus1108. The system1100may further include a video display unit1110(e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)). The system1100also may include an alphanumeric input device1120(e.g., a keyboard), a cursor control device1130(e.g., a mouse), a disk drive unit1140, a signal generation device1150(e.g., a speaker), and a network interface device1190.

The disk drive unit1140may include a machine-readable medium1122on which may be stored one or more sets of instructions (e.g., software)1124embodying any one or more of the methodologies or functions described herein. The instructions1124may also reside, completely or at least partially, within the main memory1170and/or within the processor1160during execution thereof by the system1100, with the main memory1170and the processor1160also constituting machine-readable media. The instructions1124may further be transmitted or received over a network1182via the network interface device1190.

Various embodiments for converting reset mechanisms in a synchronous circuit design into a corresponding asynchronous representation have been described. Implementing such circuits may result in reduced power consumption, reduced die area, and increased processing speed. Although the present embodiments have been described, it will be evident that various modifications and changes may be made to these embodiments. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.