US20100251196A1 - Method and System for Designing a Structural Level Description of an Electronic Circuit - Google Patents
Method and System for Designing a Structural Level Description of an Electronic Circuit Download PDFInfo
- Publication number
- US20100251196A1 US20100251196A1 US12/816,119 US81611910A US2010251196A1 US 20100251196 A1 US20100251196 A1 US 20100251196A1 US 81611910 A US81611910 A US 81611910A US 2010251196 A1 US2010251196 A1 US 2010251196A1
- Authority
- US
- United States
- Prior art keywords
- data
- control path
- state
- unresolved
- states
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
Definitions
- This invention relates to the field of computerized electronic circuit design and, more particular, to high-level synthesis of structural (e.g. RTL) design description.
- Typical circuit design methodology involves providing an abstracted description of the circuit and transforming it into a physical layout with an aid of a synthesis tool(s).
- the design flow involves various levels of design abstraction and corresponding deriving steps, as will be further detailed with reference to FIG. 1 . This process is time consuming and is subject to human error. The rapidly increasing complexity of modern electronic circuit architecture has often forced designers to employ computer-aided techniques.
- U.S. Pat. No. 5,537,580 discloses a method for fabricating an integrated circuit including the steps of: (a) describing the functionality of an integrated circuit; (b) extracting a register level state machine transition table of the state machine from the hardware description language; (c) generating a logic level state transition table representing the state machine from the register level state machine description; (d) creating a state machine structural netlist representing the state machine from the logic level state transition table; and (e) combining the state machine structural netlist with an independently synthesized structural netlist to create an integrated circuit structural netlist including the state machine to provide a basis for chip compilation, mask layout and integrated circuit fabrication.
- the method results in a synchronous state machine being extracted from a register-transfer (RT) level representation.
- U.S. Pat. No. 6,415,420 discloses a method using at least a portion of a control data flow graph (CDFG) which includes multiple control structures in a computer readable storage medium representing at least a portion of a high level design language (HDL) description of an actual or planned logic circuit to evaluate a need for a sequential state element in the portion of the logic circuit comprising producing a graph structure in the storage medium by providing a path origination node in the storage medium; providing a path destination node in the storage medium; producing respective complete paths between the path origination node and the path destination node by separately concatenating each branch of a first control structure of the CDFG with each branch of a second control structure of the CDFG such that a different respective complete path is produced for each possible combination of a respective branch from the first control structure and a respective branch from the second control structure; associating respective complete paths with respective control statements associated in the CDFG with corresponding branches that have been concatenated with other corresponding branches to produce such respective
- CDFG control data flow graph
- V++ hardware design language
- V++ provides an automatically designed and implemented communications protocol, embedded by a compiler in the design itself. This protocol permits transparent, automatic communication between modules in a hardware design. The protocol generalizes current design practice and impacts neither the cycle time, nor the area, of a typical system. Incorporating this protocol in the language itself frees the designer from the task of writing communications code, and ensures that two communicating modules follow the same low-level protocol.
- each program is directly interpreted as a network of communicating finite state machines.
- the composition of two V++programs is a V++program, with well-defined, deterministic semantics.
- U.S. Pat. No. 6,557,160 discloses a system and method for providing correlation of HDL signal names in the structural gate level description.
- an HDL behavioral description of a circuit is processed by a correlation compiler to identify intermediate signals.
- the behavioral description is modified to specify that the intermediate signals are primary outputs of the circuit.
- the modified behavioral description is then processed by a synthesis tool to generate a structural description corresponding to the modified behavioral description.
- the structural description includes as outputs the identified intermediate signals.
- U.S. Pat. No. 6,591,403 discloses a method and system in support thereof, for specifying hardware description language assertions targeting a diverse set of verification tools to provide verification of a logic design by the set of verification tools.
- the constraints and properties of the logic design are described in the HDL using one or more high-level assertion specification macros representative of the assertions of the logic design.
- the one or more assertion specification macros are stored as components within a specification macro library for later retrieval as needed.
- a specification macro processor Upon reading original HDL source code containing assertion macro calls to the assertion specification macros, a specification macro processor accesses the definitions of the assertion macros stored, if contained within a definition library, and uses these definitions as templates to automatically write expansion HDL code into the HDL source code and to automatically store tool-specific HDL code into corresponding tool-specific modules libraries for later use by one or more verification tools. If definitions of one or more of the assertion macros are not contained with the definition library, they may be written as needed.
- U.S. Pat. No. 6,597,664 discloses a method for specifying and synthesizing a synchronous digital circuit by first accepting a specification of an asynchronous system in which stored values are updated according to a set of state transition rules.
- the state transition rules are specified as a Term Rewriting System (TRS) in which each rule specifies a number of allowable state transitions, and includes a logical precondition on the stored values and a functional specification of the stored values after a state transition in terms of the stored values prior to the state transition.
- TRS Term Rewriting System
- the specification of the asynchronous circuit is converted into a specification of a synchronous circuit in which a number of state transitions can occur during each clock period.
- the method includes identifying sets of state transitions, for example by identifying sets of TRS rules, that can occur during a single clocking period and forming the specification of the synchronous circuit to allow any of the state transitions in a single set to occur during any particular clocking period.
- U.S. Pat. No. 6,604,232 discloses a high-level synthesis method comprising the steps of converting an operating description describing one or more operations to a control data flow graph (CDFG) including one or more nodes representing the one or more operations and one or more I/O branches representing a flow of data, scheduling the CDFG obtained by the converting step, and allocating one or more logic circuits required for executing the CDFG obtained by the scheduling step.
- CDFG control data flow graph
- a portion of the CDFG in the converting step is subjected to logical synthesis in advance to generate a node, and the portion of the CDFG is replaced with that node.
- U.S. Pat. No. 6,675,359 discloses a method and apparatus for recognizing a state machine in circuit design in a high-level IC description language.
- the present invention analyzes high-level IC description language code, such as VHDL and Verilog®, of an IC design and extracts description information corresponding to a state machine.
- the description information can be, for example, the high-level IC description language code corresponding to the state machine, a state diagram of the state machine, a state table for the state machine, or other representation of the state machine.
- the present invention identifies a set of one or more processes as defined by VHDL “process” statements. By identifying one or more clocked processes, one or more transition processes, and one or more output processes, the present invention provides a state machine summary to describe the state machine identified in the high-level IC description language code.
- WO2004/084086 discloses a method for generating descriptions of digital logic from high-level source code specifications is disclosed. At least part of the source code specification is compiled into a multiple directed graph representation comprising functional nodes with at least one input or one output, and connections indicating the interconnections between the functional nodes. Hardware elements are defined for each functional node of the graph and for each connection between the functional nodes. Finally, a firing rule for each of the functional nodes of the graph is defined.
- a method of designing a structural level description of an electronic circuit comprising:
- the automatic processing may be provided for accomplishing a state machine formulation, wherein the states of the state machine include states representing at least combinations of unresolved variables and corresponding transitions satisfying said plurality of rules and predefined design criteria.
- a system for designing a structural level description of an electronic circuit with functional behavior described by a plurality of rules the circuit being specified by data path and control path elements wherein at least one control path element is provided in a form of unresolved variable;
- the system comprising a processor for automatic processing of data path and control path elements for accomplishing a state machine formulation, wherein the states of the state machine include states representing at least combinations of unresolved variables and corresponding transitions satisfying said plurality of rules and predefined design criteria.
- the automatic processing may further comprise:
- the automatic processing may comprise:
- the predefined design criteria comprise criterion of logic contradiction; criterion of data integrity; and criterion of design flow enabling.
- the present invention in some of its aspects, is aimed to provide a novel solution capable of facilitating correctness—preserving educing of the structural level design.
- FIG. 1 illustrates a typical electronic circuit design flow as known in the art.
- FIG. 2 illustrates a process of high-level synthesis in accordance with certain embodiments of the present invention.
- FIGS. 3 a and 3 b illustrate a schematic functional description of an exemplary electronic circuit.
- FIG. 4 illustrates a valid state processor in accordance with certain embodiments of the present invention.
- FIG. 5 illustrates a state machine formulated in accordance with certain embodiments of the present invention.
- FIG. 6 illustrates meta-language description of functional behavior rules in accordance with certain embodiments of the present invention.
- FIG. 1 illustrating a typical electronic circuit design flow as known in the art (e.g. see R. Namballa et al. “Control and Data Flow Graph Extraction for High-Level Synthesis” IEEE Computer Society Annual Symposium on VLSI, 2004).
- the design flow involves various levels of design abstraction.
- the highest level of the design abstraction is a system level specification 101 , which mostly gives its description in a plain natural language.
- the next, lower level is a functional description 103 which specifies the functions of the electronic circuit (e.g. operations, order and dependences thereof) while avoiding the structural details.
- the next abstraction level is a structural description 105 (e.g.
- register transfer level (RTL) description which provides the structuralism of the design and comprises instances of modules (e.g. adders, multipliers, registers, etc.) and interconnections thereof.
- the next level of abstraction is an implementation description 107 (e.g. list of logic gates and the interconnections between them) resulting in a netlist.
- a physical layout 109 virtually places the netlist on a wafer.
- the behavior view (i.e. description of system behavior) of the electronic circuit may be further detailed at the lower levels of abstraction (e.g. as a set of rules and conditions in the functional description, finite state machines at the structural and implementation levels of abstraction, etc.).
- the structural and lower-level descriptions are composed by writing code in a Hardware Description Language (HDL).
- HDL Hardware Description Language
- HDL Hardware Description Language
- the process of translating the system specification into a hardware circuit exhibiting the described behavior may comprise at least the following steps:
- FIG. 2 illustrating a process of high-level synthesis in accordance with certain embodiments of the present invention.
- a circuit (or sub-component of a circuit) can be described in terms of inputs to the circuit, outputs from the circuit, and the processes (and their conditions) which are performed by the circuit and thereby transform the input signals into the output signals.
- the non-limiting example of functional description is further illustrated with reference to FIG. 3 .
- the process of high-level synthesis starts by first obtaining from the functional description control path elements 202 , data paths elements 203 and a set of rules 201 describing functional behavior of the circuit.
- the set of rules may include also conditions comprised in the functional description. Some of the rules may be related to the data path and/or control path elements, while some rules may represent additional behavior constrains introduced by a designer.
- the data path comprises at least one of the following:
- the data path elements may contain variables or signals explicitly controlling other design elements (e.g. bus MSB bit controlling a mux operation).
- the control path comprises elements responsible for operations, like conditionals constructs, loop constructs, sequencing and other notations controlling the data path elements and/or derivates thereof.
- the control path comprises at least one of the following:
- control path elements may be a function from other elements and depend, for example, on values of input data, existence of valid data at inputs or outputs, results of a function applied to the inputs, etc.
- control path may comprise unresolved variables, i.e. having no explicit expression within the data path, control path and/or their combination. It is important to note that in accordance with certain aspects of the present invention, all unresolved variables shall be derived as control path elements.
- the next step of the high-level synthesis is extracting 204 the unresolved variables in accordance with the set of rules 201 .
- This step is followed by valid state processing, wherein at least one input to the processing comprises at least one unresolved variable.
- the valid state processing is further detailed with reference to FIG. 4 and results in definition of valid states of unresolved variables and possible transitions, thus enabling the state machine formulation 206 .
- the formulated state machine is processed to provide corresponding resolution of the variables.
- control path elements may be fully specified for resulting description 207 .
- the processing is providing in a correctness-preserving manner as further detailed with reference to FIG. 4 .
- FIGS. 3 a and 3 b there are illustrated, by way of non-limiting example, a schematic functional description of an exemplary circuit.
- FIG. 3 a schematically illustrates inputs, outputs and the data path structure of the circuit, wherein FIG. 3 b illustrates a relationship of variables thereof.
- the exemplary Flip-Flop circuit 300 has the following elements:
- FIG. 3 b illustrates the relationship of variables for the exemplary circuit with reference to FIG. 3 a and the above requirements.
- variable A influences variable B
- dual directed arrow means that variables A and B influence each other or their influencing state cannot be determined a-priori (e.g. unresolved variables in some situations).
- P1 ( 311 ) and P3 ( 312 ) represent start and end conditions of the circuit operation process.
- control path elements DI, DO, DOV controlled by the control path elements VI, VO, RO, GO, END, DONE and DO.v are no explicit expressions and, hence, are unresolved variables.
- the other control path elements have explicit expression assignments: e.g. DO will sample DI under rule 3 condition supervision, DOV will sample DO under rule 5, DONE is generated according to rule 7, P1 and P3 are generated according to rules 4 and 6 respectively.
- the obtained data path and control path elements are further processed in order to accomplish a state machine formulation.
- the states of the formulated state machine shall represent combinations of unresolved variables facilitating transitions satisfying design rules describing functional behavior of the circuit (e.g. illustrated with reference to FIG. 3 a ).
- the transitions shall also match correctness-preserving design criteria as will be further detailed with reference to FIG. 4 .
- some of the states of the formulated state machine may represent combinations of resolved and unresolved variables and/or some of the states may represent only resolved variables.
- VSP valid state processor
- all data path elements comprised in the data path input shall be related to the same data flow (or its part) and all elements of the processing dataflow (or its part) shall be comprised in said input 401 .
- the control path input shall comprise all unresolved variables controlling input data path elements.
- the data path and the control path inputs may be divided into several parts for sub-processing in a similar manner.
- the VSP asserts probable values (states) for the unresolved variables comprised in the control path input and specifies potential combinations of said values.
- a state table 403 includes possible combinations of probable states (Idle, 1-7) of unresolved variables comprised in the control path input for the exemplary circuit illustrated with reference to FIGS. 3 a and 3 b .
- Each of the illustrated unresolved variables may have 2 states: an active state (denoted as 1) facilitating a flow of the corresponding data path elements, and a passive state (denoted as 0) preventing the flow of the corresponding data path elements.
- the idle state in the state table 403 corresponds to passive states (0) of all of its input elements.
- any of the expressions may be selected for defining the passive state of that variable. If it follows that the resulting state machine cannot be realized, the contradicting expression shall be selected for defining the idle state, and the state generation process shall be re-started. In a case where state machine cannot be realized, a user can promptly alter design specifications.
- the VSP processes all specified combination of probable states of the unresolved variables in order to derive the valid states (combinations) of said variables.
- processing may be provided as following:
- the invention is not bound by the specific algorithm of processing the combination of probable values of the unresolved variables in order to derive the valid states. It should be also noted that in general cases, after and/or during deriving of valid state, the state machine formulation may be done (or reduced thereof) by different known techniques (see e.g. “Formal Hardware Verification with BDDs: An Introduction,” IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing ( PACRIM ), pp. 677-682, 1997).
- the predefined design criteria shall enable correctness-preserving transitions between the valid states.
- the criteria may comprise the following requirements:
- VSP specifies data path elements being controlled by the unresolved variables and, for each of the specified combinations of the probable states of the unresolved variables, analyzes matching of the resulting data flow between a pair of combinations to the design rules and the design criteria, and specifies the valid combinations 405 of the unresolved variables.
- the analysis of resulting data flow shall be provided for all combination of input conditions (including resolved variables and respective probable values of unresolved variables).
- the analysis of the resulting data flow may comprise specification, in respect of each of the specified combinations of the probable states of the unresolved variables, of resulting behavior states of the data path elements 404 in accordance with design rules, and further analysis of matching the resulting behavior states to the design criteria.
- a data path element may have 3 states describing the data flow behavior:
- the resulting behavior states of the data flow elements 404 are illustrated in FIG. 4 by way of non-limiting example:
- the resulting behavior states of the data path elements are defined for each combination of the probable states of the unresolved variables subject to specified design rules.
- the valid state processor may be configured to derive valid states of unresolved variables 405 by processing the resulting behavior states 404 of data path elements in accordance with design criteria.
- state machine used in this patent specification should be expansively construed to cover any kind of a model of sequential behavior composed of states and transitions, when behavior cannot be defined by the knowledge of inputs only, but depends at least on the sequence of input changes.
- the model may be represented in different forms as, for example, finite-state machines, control & data graphs, state diagrams, behavior tables, the models used in PLC languages, Petry-nets, etc.
- a state stores information about the past, i.e. it reflects the input changes from the system start to the present moment.
- a transition indicates a state change and is described by a condition that would need to be fulfilled to enable the transition.
- the state machine illustrated in FIG. 5 comprises the valid states presented as nodes (Idle, 3, 4 and 7 per numeration of FIG. 4 ) and transitions between them presented as arcs connecting the nodes.
- This exemplary state machine corresponds to the valid state derived by the processing illustrated, by way of non-limiting example, with reference to FIG. 4 . Since the variables' dependencies and their explicit expressions in the illustrated example are fairly simple, the state machine may be formulated by identifying possible values of next state of P1 condition.
- P1 logic rises to ‘1’ with GO and returns to ‘0’ with END (rule 4).
- P3 logic raises to ‘1’ with P1 active and END while returning to ‘0’ with !DO.v (rule 6).
- DONE logic raises for a cycle if P3 is active and !DO.v is satisfied (rule 7).
- DO.v, RO and VO are determined easily from the above resulted state machine. DO.v is ‘1’ in states 3 or 7.
- RO is ‘1’ in states 4 or 7.
- VO is ‘1’ in states 3 or 7.
- Table 3 summarizes the transitions illustrated in FIG. 5 .
- the names of states may be assigned in various ways, for example information flow situations (as illustrated in FIG. 5 ), user defined rules, etc.
- State machine inputs are: P1 (which convey GO and END signals in it) and VI.
- the formulated state machine enables resolving of variables having no explicit expressions and fully specifying the control path elements.
- the method disclosed in the present invention may be done entirely automatically, automatically with a designer intervention at any step, and entirely manually and may use any programmable language suitable for design of electronic circuits.
- the principles of the present invention also allow formulation of special language optimized for certain aspects of the present invention.
- FIG. 6 there is illustrated, by way of non-limiting example, functional behavior rules describing design functionality in a meta-language. Connections between the illustrated code lines and the design rules illustrated with reference to FIG. 3 a are the following:
- a structure section 601 comprises behavior rules and conditions related to the data path elements; a control section 602 comprises behavior rules and conditions related to the control path elements and an attributes section 603 comprises design criteria conveys general design information.
- Line 1 corresponds to rule 3: DI will be sampled into DO under P1 control condition.
- Line 2 corresponds to rule 5: DO will be sampled provided VO is asserted. This shows alternative syntax as the VO condition might be detailed in the control section.
- Line 3 corresponds to rule 7: DONE signal is a sampled version of the end condition of P3 control definition.
- Line 4 corresponds to rule 4: P1 is asserted between GO and END signals and the flow associated with this condition is further conditioned by the existence of VI && RO logical combination.
- the virtual indication states that the relevant virtual condition (i.e. VI && RO) is the only condition upon which the input is considered as valid by the outer circuit.
- Line 5 corresponds to rule 6: P3 is asserted between end condition of P1 control condition and the non-validity of the DO data element.
- Line 6 corresponds to rule 8: data cannot be generated inside the circuit nor can it be overwritten and ignored (design criterion of data integrity).
- Line 7 corresponds to rule 9: external condition exists for GO assertion. GO can be asserted only if DONE was asserted after GO previous assertion. This kind of condition limits the possible design state machine transitions.
- Verilog RTL code illustrates, by way of non-limiting example and without general definitions (e.g. module, inputs, outputs), structural level description of the exemplary circuit illustrated with reference to FIG. 3 .
- system may be a suitably programmed computer.
- the invention contemplates a computer program being readable by a computer for executing the method of the invention.
- the invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention.
Abstract
A method and system for designing a structural level description of an electronic circuit with functional behavior described by a plurality of rules, the circuit being specified by data path and control path elements wherein at least one control path element is provided in a form of unresolved variable. The design comprises extracting a plurality of unresolved variables among the control path elements and automated processing of data path and control path elements for accomplishing a state machine formulation, wherein the states of the state machine include states representing at least combinations of unresolved variables and corresponding transitions satisfying said plurality of rules and predefined design criteria.
Description
- The present application is a Continuation of prior U.S. application Ser. No. 11/574,667, filed Sep. 1, 2005, the entirety of which is hereby incorporated by reference.
- This invention relates to the field of computerized electronic circuit design and, more particular, to high-level synthesis of structural (e.g. RTL) design description.
- Typical circuit design methodology involves providing an abstracted description of the circuit and transforming it into a physical layout with an aid of a synthesis tool(s). Generally, the design flow involves various levels of design abstraction and corresponding deriving steps, as will be further detailed with reference to
FIG. 1 . This process is time consuming and is subject to human error. The rapidly increasing complexity of modern electronic circuit architecture has often forced designers to employ computer-aided techniques. - The problem to automate the transformation from system description to physical layout has been recognized in prior art and various systems and methods have been developed to provide a solution.
- For example, U.S. Pat. No. 5,537,580 (Giomi et al.) discloses a method for fabricating an integrated circuit including the steps of: (a) describing the functionality of an integrated circuit; (b) extracting a register level state machine transition table of the state machine from the hardware description language; (c) generating a logic level state transition table representing the state machine from the register level state machine description; (d) creating a state machine structural netlist representing the state machine from the logic level state transition table; and (e) combining the state machine structural netlist with an independently synthesized structural netlist to create an integrated circuit structural netlist including the state machine to provide a basis for chip compilation, mask layout and integrated circuit fabrication. The method results in a synchronous state machine being extracted from a register-transfer (RT) level representation.
- U.S. Pat. No. 6,415,420 (Cheng et al.) discloses a method using at least a portion of a control data flow graph (CDFG) which includes multiple control structures in a computer readable storage medium representing at least a portion of a high level design language (HDL) description of an actual or planned logic circuit to evaluate a need for a sequential state element in the portion of the logic circuit comprising producing a graph structure in the storage medium by providing a path origination node in the storage medium; providing a path destination node in the storage medium; producing respective complete paths between the path origination node and the path destination node by separately concatenating each branch of a first control structure of the CDFG with each branch of a second control structure of the CDFG such that a different respective complete path is produced for each possible combination of a respective branch from the first control structure and a respective branch from the second control structure; associating respective complete paths with respective control statements associated in the CDFG with corresponding branches that have been concatenated with other corresponding branches to produce such respective complete paths; and traversing respective complete paths of the graph information structure to determine whether there is a respective path that is not associated with a respective control statement.
- U.S. Pat. No. 6,421,808 (McGeer et al.) discloses hardware design language V++. V++provides an automatically designed and implemented communications protocol, embedded by a compiler in the design itself. This protocol permits transparent, automatic communication between modules in a hardware design. The protocol generalizes current design practice and impacts neither the cycle time, nor the area, of a typical system. Incorporating this protocol in the language itself frees the designer from the task of writing communications code, and ensures that two communicating modules follow the same low-level protocol. In V++each program is directly interpreted as a network of communicating finite state machines. The composition of two V++programs is a V++program, with well-defined, deterministic semantics.
- U.S. Pat. No. 6,557,160 (Shalish) discloses a system and method for providing correlation of HDL signal names in the structural gate level description. In one embodiment, an HDL behavioral description of a circuit is processed by a correlation compiler to identify intermediate signals. The behavioral description is modified to specify that the intermediate signals are primary outputs of the circuit. The modified behavioral description is then processed by a synthesis tool to generate a structural description corresponding to the modified behavioral description. The structural description includes as outputs the identified intermediate signals.
- U.S. Pat. No. 6,591,403 (Bass et al.) discloses a method and system in support thereof, for specifying hardware description language assertions targeting a diverse set of verification tools to provide verification of a logic design by the set of verification tools. The constraints and properties of the logic design are described in the HDL using one or more high-level assertion specification macros representative of the assertions of the logic design. The one or more assertion specification macros are stored as components within a specification macro library for later retrieval as needed. Upon reading original HDL source code containing assertion macro calls to the assertion specification macros, a specification macro processor accesses the definitions of the assertion macros stored, if contained within a definition library, and uses these definitions as templates to automatically write expansion HDL code into the HDL source code and to automatically store tool-specific HDL code into corresponding tool-specific modules libraries for later use by one or more verification tools. If definitions of one or more of the assertion macros are not contained with the definition library, they may be written as needed.
- U.S. Pat. No. 6,597,664 (Mithal et al.) discloses a method for specifying and synthesizing a synchronous digital circuit by first accepting a specification of an asynchronous system in which stored values are updated according to a set of state transition rules. For instance, the state transition rules are specified as a Term Rewriting System (TRS) in which each rule specifies a number of allowable state transitions, and includes a logical precondition on the stored values and a functional specification of the stored values after a state transition in terms of the stored values prior to the state transition. The specification of the asynchronous circuit is converted into a specification of a synchronous circuit in which a number of state transitions can occur during each clock period. The method includes identifying sets of state transitions, for example by identifying sets of TRS rules, that can occur during a single clocking period and forming the specification of the synchronous circuit to allow any of the state transitions in a single set to occur during any particular clocking period.
- U.S. Pat. No. 6,604,232 (Okada et al.) discloses a high-level synthesis method comprising the steps of converting an operating description describing one or more operations to a control data flow graph (CDFG) including one or more nodes representing the one or more operations and one or more I/O branches representing a flow of data, scheduling the CDFG obtained by the converting step, and allocating one or more logic circuits required for executing the CDFG obtained by the scheduling step. A portion of the CDFG in the converting step is subjected to logical synthesis in advance to generate a node, and the portion of the CDFG is replaced with that node.
- U.S. Pat. No. 6,675,359 (Gilford et al.) discloses a method and apparatus for recognizing a state machine in circuit design in a high-level IC description language. The present invention analyzes high-level IC description language code, such as VHDL and Verilog®, of an IC design and extracts description information corresponding to a state machine. The description information can be, for example, the high-level IC description language code corresponding to the state machine, a state diagram of the state machine, a state table for the state machine, or other representation of the state machine. In one embodiment, the present invention identifies a set of one or more processes as defined by VHDL “process” statements. By identifying one or more clocked processes, one or more transition processes, and one or more output processes, the present invention provides a state machine summary to describe the state machine identified in the high-level IC description language code.
- International Publication No. WO2004/084086 (Möhl et al.) discloses a method for generating descriptions of digital logic from high-level source code specifications is disclosed. At least part of the source code specification is compiled into a multiple directed graph representation comprising functional nodes with at least one input or one output, and connections indicating the interconnections between the functional nodes. Hardware elements are defined for each functional node of the graph and for each connection between the functional nodes. Finally, a firing rule for each of the functional nodes of the graph is defined.
- As any mistake on a step of structural (e.g. register transfer level) design may drastically affect the accuracy of the whole design flow, it would clearly be beneficial to ensure consistency of derived circuit structure.
- According to some aspects of the present invention, there is provided a method of designing a structural level description of an electronic circuit, the method comprising:
-
- (a) obtaining data path and control path elements specifying the electronic circuit, wherein at least one control path element is provided in a form of unresolved variable;
- (b) obtaining plurality of rules;
- (c) extracting a plurality of unresolved variables among the control path elements;
- (d) automatic processing of data path and control path elements for obtaining values of unresolved variables satisfying said plurality of rules and predefined design criteria.
- According to further aspects of the present invention, the automatic processing may be provided for accomplishing a state machine formulation, wherein the states of the state machine include states representing at least combinations of unresolved variables and corresponding transitions satisfying said plurality of rules and predefined design criteria.
- According to further aspects of the present invention, there is provided a system for designing a structural level description of an electronic circuit with functional behavior described by a plurality of rules, the circuit being specified by data path and control path elements wherein at least one control path element is provided in a form of unresolved variable; the system comprising a processor for automatic processing of data path and control path elements for accomplishing a state machine formulation, wherein the states of the state machine include states representing at least combinations of unresolved variables and corresponding transitions satisfying said plurality of rules and predefined design criteria.
- According to further aspects of the present invention, the automatic processing may further comprise:
-
- (a) asserting probable values for unresolved variables among the plurality of unresolved variables and specifying potential combinations of said values;
- (b) specifying data path elements being controlled by said plurality of unresolved variables;
- (c) validating, in respect of each of the specified combinations of values of unresolved variables among the plurality of the unresolved variables, whether said data path elements comply with said plurality of rules and predefined design criteria and, thus giving rise to valid combinations of values of the plurality of unresolved variables to be specified in states of said state machine.
- According to further features of the present invention, the automatic processing may comprise:
-
- (a) asserting probable values for unresolved variables among the plurality of unresolved variables and specifying potential combinations of said values;
- (b) specifying data path elements being controlled by said plurality of unresolved variables;
- (c) defining combinations of resulting states of the data path elements in respect of each specified combination of values of the plurality of unresolved variables in accordance with the plurality of rules;
- (d) validating, in respect of each specified combination of values of unresolved variables among the plurality of unresolved variables, if the corresponding combination of said resulting states of the data path elements meet predefined design criteria, thus giving rise to valid combinations of values of the plurality of unresolved variables to be specified in states of said state machine.
- According to further aspects of the present invention, the predefined design criteria comprise criterion of logic contradiction; criterion of data integrity; and criterion of design flow enabling.
- Thus, the present invention, in some of its aspects, is aimed to provide a novel solution capable of facilitating correctness—preserving educing of the structural level design.
- In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:
-
FIG. 1 illustrates a typical electronic circuit design flow as known in the art. -
FIG. 2 illustrates a process of high-level synthesis in accordance with certain embodiments of the present invention. -
FIGS. 3 a and 3 b illustrate a schematic functional description of an exemplary electronic circuit. -
FIG. 4 illustrates a valid state processor in accordance with certain embodiments of the present invention. -
FIG. 5 illustrates a state machine formulated in accordance with certain embodiments of the present invention. -
FIG. 6 illustrates meta-language description of functional behavior rules in accordance with certain embodiments of the present invention. - In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail, so as not to obscure the present invention. In the drawings and description, identical reference numerals indicate those components that are common to different embodiments or configurations.
- Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as “processing”, “computing”, “calculating”, “determining”, or the like, refer to the action and/or processes of a computer or computing system, or processor or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data, similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.
- Bearing this in mind, attention is drawn to
FIG. 1 illustrating a typical electronic circuit design flow as known in the art (e.g. see R. Namballa et al. “Control and Data Flow Graph Extraction for High-Level Synthesis” IEEE Computer Society Annual Symposium on VLSI, 2004). The design flow involves various levels of design abstraction. The highest level of the design abstraction is asystem level specification 101, which mostly gives its description in a plain natural language. The next, lower level is afunctional description 103 which specifies the functions of the electronic circuit (e.g. operations, order and dependences thereof) while avoiding the structural details. The next abstraction level is a structural description 105 (e.g. register transfer level (RTL) description), which provides the structuralism of the design and comprises instances of modules (e.g. adders, multipliers, registers, etc.) and interconnections thereof. The next level of abstraction is an implementation description 107 (e.g. list of logic gates and the interconnections between them) resulting in a netlist. Aphysical layout 109 virtually places the netlist on a wafer. Introduced in the system description, the behavior view (i.e. description of system behavior) of the electronic circuit may be further detailed at the lower levels of abstraction (e.g. as a set of rules and conditions in the functional description, finite state machines at the structural and implementation levels of abstraction, etc.). Generally, the structural and lower-level descriptions are composed by writing code in a Hardware Description Language (HDL). For that purpose there are several languages known in the art, common among them being Verilog and VHDL, but other syntaxes may be used. - Accordingly, the process of translating the system specification into a hardware circuit exhibiting the described behavior may comprise at least the following steps:
-
- a system-
level design 102 of the functional description from the system description; - a high-
level synthesis 104 of the structural (e.g. RTL) description from the functional description; - a
logic level synthesis 106 resulting in the implementation (e.g. gate level) description, and - a
layout synthesis 108 emulating a real physical location of the registers and gates, e.g. viewing them on a screen or by printable drawings.
- a system-
- Note that the invention is not bound by the specific design flow described with reference to
FIG. 1 . Those versed in the art will readily appreciate that the invention is, likewise, applicable to any design flow comprising educing of the structural level design. - Bearing this in mind, attention is drawn to
FIG. 2 illustrating a process of high-level synthesis in accordance with certain embodiments of the present invention. - Typically, at the functional level of abstraction, a circuit (or sub-component of a circuit) can be described in terms of inputs to the circuit, outputs from the circuit, and the processes (and their conditions) which are performed by the circuit and thereby transform the input signals into the output signals. The non-limiting example of functional description is further illustrated with reference to
FIG. 3 . - In accordance with certain embodiments of the present invention, the process of high-level synthesis starts by first obtaining from the functional description
control path elements 202,data paths elements 203 and a set ofrules 201 describing functional behavior of the circuit. The set of rules may include also conditions comprised in the functional description. Some of the rules may be related to the data path and/or control path elements, while some rules may represent additional behavior constrains introduced by a designer. - Obtaining data path and control path elements from the functional description is well known in the art and described, for example, in Wolf, Wayne, FPGA-Based System Design, Prentice-Hall Publishers, Inc., 2004. This process may be done entirely automatically, automatically with a designer intervention and entirely manually. In certain embodiments of the present invention a designer may start to specify data and control path elements having functional description or alike just in mind.
- The data path comprises at least one of the following:
-
- Operational elements responsible for arithmetic, logical or relational operations, e.g. adders, multiplexers, etc.
- Storage elements representing assignment operations associated with variables and signals e.g. hardware registers, FIFOs, latches, etc.
- Call elements denoting calls to subprogram modules.
- Interfaces, e.g. bus interface, module interface, etc.
- Others may also apply.
- The data path elements may contain variables or signals explicitly controlling other design elements (e.g. bus MSB bit controlling a mux operation).
- The control path comprises elements responsible for operations, like conditionals constructs, loop constructs, sequencing and other notations controlling the data path elements and/or derivates thereof.
- The control path comprises at least one of the following:
-
- variables which control some other element;
- start conditions and end conditions (in pairs or separately);
- unresolved variables;
- data path validity indications;
- others may also apply
- As a result of this process, all design elements shall be specified as data path or control path elements. The control path elements may be a function from other elements and depend, for example, on values of input data, existence of valid data at inputs or outputs, results of a function applied to the inputs, etc. As a result, the control path may comprise unresolved variables, i.e. having no explicit expression within the data path, control path and/or their combination. It is important to note that in accordance with certain aspects of the present invention, all unresolved variables shall be derived as control path elements.
- In accordance with certain embodiments of the present invention, the next step of the high-level synthesis is extracting 204 the unresolved variables in accordance with the set of
rules 201. This step is followed by valid state processing, wherein at least one input to the processing comprises at least one unresolved variable. The valid state processing is further detailed with reference toFIG. 4 and results in definition of valid states of unresolved variables and possible transitions, thus enabling thestate machine formulation 206. The formulated state machine is processed to provide corresponding resolution of the variables. Thus, control path elements may be fully specified for resultingdescription 207. In accordance with certain embodiments of the present invention the processing is providing in a correctness-preserving manner as further detailed with reference toFIG. 4 . - Referring to
FIGS. 3 a and 3 b, there are illustrated, by way of non-limiting example, a schematic functional description of an exemplary circuit.FIG. 3 a schematically illustrates inputs, outputs and the data path structure of the circuit, whereinFIG. 3 b illustrates a relationship of variables thereof. - As illustrated in
FIG. 3 a, the exemplary Flip-Flop circuit 300 has the following elements: -
- DI (Data In) input signal (represents storage element value to be sampled by DO upon certain conditions) 301;
- VI (Valid In)
input signal 302 - “GO”
input signal 303 - “END”
input signal 304 - DO (Data Out) output signal (represents storage element value to be sampled by DOV upon certain conditions) 305
- DOV (Data Out Virtual) external reflected signal (represents storage element which samples DO upon certain conditions) 306
- VO (Valid Out)
output signal 307 - RO (Ready-out)
output signal 309 - “DONE”
output signal 310 - DO.v signal of internal validation of
DO output signal 308
- The following design rules describe the required functional behavior of the exemplary circuit:
-
- 1) Asserting of one clock pulsed “GO” input signal starts off receiving the input data (DI) signal;
- 2) Asserting of one clock pulsed “END” input signal ends off receiving the input data (DI) signal;
- 3) Data must be transferred from the input to the output (from DI to DO) if P1 is true and conditioned with the following: VI input signal is provided together with the RO output signal and must not be transferred otherwise;
- 4) “P1” is defined as “true” the cycle following the “GO” cycle and until end of the “END” cycle;
- 5) An availability of the output data (DO) for further processing is subject to provision of VO signal;
- 6) “P3” is defined as “true” the cycle following last P1 true cycle until DO contains no valid data, i.e. DO.v is false;
- 7) Asserting of one clock pulsed “DONE” signal shall be provided in the cycle following P3 last true cycle.
- The following rules describe design criteria further detailed with reference to
FIG. 4 . -
- 8) Data should not be overridden or generated within the circuit;
- 9) The “GO” signal cannot be re-asserted until assertion of DONE signal (example of design constrains introduced by designer).
- 10) Data should be accepted (thus, sampled from DI into DO) whenever possible and be provided for DOV whenever possible (subject to rule 8).
- Accordingly,
FIG. 3 b illustrates the relationship of variables for the exemplary circuit with reference toFIG. 3 a and the above requirements. - An arrow directed from variable A to variable B means that variable A influences variable B, dual directed arrow means that variables A and B influence each other or their influencing state cannot be determined a-priori (e.g. unresolved variables in some situations).
- In accordance with
rules - Accordingly, from the above functional description of the exemplary circuit, one can derive the data path elements DI, DO, DOV controlled by the control path elements VI, VO, RO, GO, END, DONE and DO.v. Among these control path elements RO, VO and DO.v have no explicit expressions and, hence, are unresolved variables. The other control path elements have explicit expression assignments: e.g. DO will sample DI under
rule 3 condition supervision, DOV will sample DO underrule 5, DONE is generated according torule 7, P1 and P3 are generated according torules - The obtained data path and control path elements are further processed in order to accomplish a state machine formulation. The states of the formulated state machine shall represent combinations of unresolved variables facilitating transitions satisfying design rules describing functional behavior of the circuit (e.g. illustrated with reference to
FIG. 3 a). The transitions shall also match correctness-preserving design criteria as will be further detailed with reference toFIG. 4 . In certain embodiments of the present invention, some of the states of the formulated state machine may represent combinations of resolved and unresolved variables and/or some of the states may represent only resolved variables. - The corresponding valid state processor (VSP) is illustrated in
FIG. 4 by way of non-limiting example. The VSP comprises at least two categories of inputs: -
- a data path input 401 comprising data path elements (DI, DO, DOV) and
- a control path input 402 comprising unresolved variables (RO, VO and DO.v) controlling the data path elements. The control path input may comprise, also, the resolved variables or part of them.
- Please note that all data path elements comprised in the data path input shall be related to the same data flow (or its part) and all elements of the processing dataflow (or its part) shall be comprised in said
input 401. Accordingly, the control path input shall comprise all unresolved variables controlling input data path elements. For a complicated data flow (e.g. split, merged, large, etc.) and/or for a control flow with large amount of unresolved variables, the data path and the control path inputs may be divided into several parts for sub-processing in a similar manner. - The VSP asserts probable values (states) for the unresolved variables comprised in the control path input and specifies potential combinations of said values. In the illustrated example a state table 403 includes possible combinations of probable states (Idle, 1-7) of unresolved variables comprised in the control path input for the exemplary circuit illustrated with reference to
FIGS. 3 a and 3 b. Each of the illustrated unresolved variables may have 2 states: an active state (denoted as 1) facilitating a flow of the corresponding data path elements, and a passive state (denoted as 0) preventing the flow of the corresponding data path elements. - The examples of active and passive states of the unresolved variables for the exemplary circuit illustrated with reference to
FIGS. 3 a and 3 b, are illustrated in Table 1. -
TABLE 1 RO VO DO.v Active state (1) implied possible forces output data implies data data movement (if sampling existence in a VI = 1) storage element Passive state forces DO not to forces DO not to forces DO to be (0) sample DI be sampled empty (no valid data) - The idle state in the state table 403 corresponds to passive states (0) of all of its input elements. In a conflict case (e.g. if there are at least two expressions comprising the same variable, while the same value of the variable may cause different (passive or active) states in different expressions), any of the expressions may be selected for defining the passive state of that variable. If it follows that the resulting state machine cannot be realized, the contradicting expression shall be selected for defining the idle state, and the state generation process shall be re-started. In a case where state machine cannot be realized, a user can promptly alter design specifications.
- In accordance with certain embodiments of the present invention, the VSP processes all specified combination of probable states of the unresolved variables in order to derive the valid states (combinations) of said variables.
- Two combinations of probable states of unresolved variables are considered to be valid if the data flow corresponding to the transition between the states meets predefined design criteria and satisfies predefined design rules describing at least functional behavior of the circuit (referred hereinafter as “legal transition”).
- In accordance with certain embodiments of the present invention, the processing may be provided as following:
-
- a) VSP starts processing from the idle state and processes the combinations of probable values of unresolved variables until found all states enabling a legal transition from the idle state;
- b) VSP continues the processing in respect of all pairs of probable states, wherein one of the states in the pair is the last previously derived valid state, until found all state enabling a legal transition from these states;
- c) VSP repeats the processing in a manner described in b) until no new valid state can be derived.
- It should be noted that the invention is not bound by the specific algorithm of processing the combination of probable values of the unresolved variables in order to derive the valid states. It should be also noted that in general cases, after and/or during deriving of valid state, the state machine formulation may be done (or reduced thereof) by different known techniques (see e.g. “Formal Hardware Verification with BDDs: An Introduction,” IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing (PACRIM), pp. 677-682, 1997).
- In accordance with certain embodiments of the present invention, the predefined design criteria shall enable correctness-preserving transitions between the valid states. The criteria may comprise the following requirements:
-
- eliminate logic contradiction, i.e. the data flow between the valid states shall not cause any simultaneous assertion of a statement and its negation and/or any violation of a design rule (see, e.g., “Foundations of Digital Logic Design” World Scientific, 1998 for a digital logic design introduction);
- keep data integrity of the data flow in accordance with requirements of a specific design (e.g. in bus transaction the data flow between two valid states shall be preserved from data generation and/or data overridden; data flow may not be preserved from occasional data sampling by an interrupt signal thus loosing some data; data flow may not be preserved from a random number generator in which data is generated inside a data path, etc.);
- keep data flow enabling in accordance with requirements of a specific design, i.e. data flow shall be enabled whenever possible subject to design rules (e.g. data flow shall be always enabled if new data is introduced and disabled for other conditions thus eliminating “holes” in the data flow).
- keep various demands and constrains introduced by user as additional design rules and functionality, etc. (e.g. requirements introduced in the rule 9).
- Accordingly, VSP specifies data path elements being controlled by the unresolved variables and, for each of the specified combinations of the probable states of the unresolved variables, analyzes matching of the resulting data flow between a pair of combinations to the design rules and the design criteria, and specifies the
valid combinations 405 of the unresolved variables. The analysis of resulting data flow shall be provided for all combination of input conditions (including resolved variables and respective probable values of unresolved variables). - In accordance with certain embodiments of the present invention, the analysis of the resulting data flow may comprise specification, in respect of each of the specified combinations of the probable states of the unresolved variables, of resulting behavior states of the
data path elements 404 in accordance with design rules, and further analysis of matching the resulting behavior states to the design criteria. - A data path element may have 3 states describing the data flow behavior:
-
- Stop (S) when data movement is not possible;
- Flow (F) when data movement is compulsory; and
- Stop/Flow (S/F) when data movement is possible but not compulsory.
- The resulting behavior states of the data flow
elements 404 are illustrated inFIG. 4 by way of non-limiting example: -
- the states of DOV data path element, corresponding to all combinations of probable states where VO=0 (Idle, 1, 4 and 5) shall be S; and corresponding to all combinations of probable states where VO=1 (2, 3, 6, and 7) shall be F (data flow is compulsory), as availability of the output data (DO) for further processing by an external circuit (DOV sampling) is subject of VO provision, (see
rule # 5 with reference toFIG. 3 ); - the states of DO data path element, corresponding to all combinations of probable states where RO=0 (Idle, 1, 2 and 3) shall be S; and corresponding to all combinations of probable states where RO=1 (4, 5, 6 and 7) shall be S/F (data flow is possible if VI=1), as the data cannot be transferred from the input to the output (from DI to DO) without asserting of RO signal (see
rule # 3 with reference toFIG. 3 ); - the states of DI data path elements are similar to those of DO data path element
- the states of DOV data path element, corresponding to all combinations of probable states where VO=0 (Idle, 1, 4 and 5) shall be S; and corresponding to all combinations of probable states where VO=1 (2, 3, 6, and 7) shall be F (data flow is compulsory), as availability of the output data (DO) for further processing by an external circuit (DOV sampling) is subject of VO provision, (see
- Thus, in accordance with certain embodiments of the present invention, the resulting behavior states of the data path elements are defined for each combination of the probable states of the unresolved variables subject to specified design rules. The valid state processor may be configured to derive valid states of
unresolved variables 405 by processing the resulting behavior states 404 of data path elements in accordance with design criteria. - Bearing this in mind, attention is drawn to non-limiting example of processing the combinations of
unresolved variables 403 and corresponding data flow resulting in the valid combinations of the unresolved variables (valid states) 405. The processing is provided subject to design criteria formulated above and considering given design rules 1-10 detailed with reference toFIG. 3 a and input conditions. The similar reasoning in the square breaks is related to analysis based on behavior states of the data path elements. - Idle State
- Assuming next P1=0 (VI input is not relevant for the Idle state). GO is possible according to design criteria (constrain introduced by a designer in rule (9), educing may be provided, for example, by techniques described in the referred above “Formal Hardware Verification with BDDs: An Introduction,”). Combinations 4-7 fail on logic contradiction with rule (3) as P1=0 means that no information flow is possible.
Combinations Combination 2 fails on data integrity (rule 8) since outer circuit cannot see a valid signal when no data exist in DO [The resulting behavior state of DOV for this combination is “F” meaning that the flow is compulsory. As DO.v=0, no data shall exist in DO, hence the combination fails on data integrity]. Accordingly, when next P1=0, next valid state is Idle again. - Assuming next P1=1. GO is possible according to rule (9) and is compulsory according to rule (4).
Combinations Combinations combination # 4. -
State # 4 - Assuming next P1=0. GO is not possible according to rule (9). Combinations 4-7 fail on logic contradiction with rule (3) as P1=0 means that no flow is possible.
Combination 2 fails on data integrity (rule 8) since outer circuit can't see a valid signal when no data exist in DO. [The resulting behavior state of DOV for this combination is “F” meaning that the flow is compulsory. As DO.v=0, no data shall exist in DO, hence the combination fails on data integrity]. If VI=0, thencombinations Combination 1 fails on design flow enabling (rule 10) since output data is blocked for no purpose. Accordingly, next valid state iscombination # 3. - Assuming next P1=1. If VI=0 then
combinations Combinations combination # 4. If VI=1, then combinations Idle, 2, 4 and 6 fail on data integrity. DO.v must be 1 if new data has been entered [“F” state of DO in state 4 (when VI=1) in 404].Combinations Combination 3 fails on design flow enabling (rule 10) since input data is blocked for no purpose. Accordingly, next valid state iscombination # 7. - In a similar manner the processing is provided for
combinations -
TABLE 2 Next Valid Combinations Valid states Condition Idle 1 2 3 4 5 6 7 States Idle next DI DI DI LC LC LC LC Idle P1 = 0 Idle, Next DF DI DI DI DI DI DI State P1 = 1 #4 State next DI DI DI LC LC LC LC Idle # 4, P1 = 0; VI = 0 State next DI DF DI LC LC LC LC State # 4 P1 = 0; #3 VI = 1 State next DF DI DI DI DI DI DI State # 4, P1 = 1; #4 VI = 0 State next DI DF DI DF DI DF DI State # 4 P1 = 1; #7 VI = 1 State next DI DI DI LC LC LC LC Idle # 7 P1 = 0; VI = 0 State next DI DF DI LC LC LC LC State # 7 P1 = 0; #3 VI = 1 State next DF DI DI DI DI DI DI State # 7 P1 = 1; #4 VI = 0 State next DI DF DI DF DI DF DI State # 7 P1 = 1; #7 VI = 1 State Always DI DI DI LC LC LC LC Idle # 3 - It should be noted that the invention is not bound by the specific structure of the valid state processor and data representation described with reference to
FIG. 4 . Those versed in the art will readily appreciate that the invention is, likewise, applicable to any other processing with equivalent and/or modified functionality which may be consolidated or divided in another manner. - The above processing and deriving of valid states facilitates formulation of behavior state machine illustrated in
FIG. 5 by way of non-limiting example. - It should be noted that the term “state machine” used in this patent specification should be expansively construed to cover any kind of a model of sequential behavior composed of states and transitions, when behavior cannot be defined by the knowledge of inputs only, but depends at least on the sequence of input changes. The model may be represented in different forms as, for example, finite-state machines, control & data graphs, state diagrams, behavior tables, the models used in PLC languages, Petry-nets, etc. A state stores information about the past, i.e. it reflects the input changes from the system start to the present moment. A transition indicates a state change and is described by a condition that would need to be fulfilled to enable the transition.
- The state machine illustrated in
FIG. 5 comprises the valid states presented as nodes (Idle, 3, 4 and 7 per numeration ofFIG. 4 ) and transitions between them presented as arcs connecting the nodes. This exemplary state machine corresponds to the valid state derived by the processing illustrated, by way of non-limiting example, with reference toFIG. 4 . Since the variables' dependencies and their explicit expressions in the illustrated example are fairly simple, the state machine may be formulated by identifying possible values of next state of P1 condition. - P1 logic rises to ‘1’ with GO and returns to ‘0’ with END (rule 4). Next P1 is hence straightforward. P3 logic raises to ‘1’ with P1 active and END while returning to ‘0’ with !DO.v (rule 6). DONE logic raises for a cycle if P3 is active and !DO.v is satisfied (rule 7). DO.v, RO and VO are determined easily from the above resulted state machine. DO.v is ‘1’ in
states states states - The following Table 3 summarizes the transitions illustrated in
FIG. 5 . The names of states may be assigned in various ways, for example information flow situations (as illustrated inFIG. 5 ), user defined rules, etc. State machine inputs are: P1 (which convey GO and END signals in it) and VI. -
TABLE 3 Arc # Arc direction Condition Comments 501 From ‘IDLE to Next P1 = 1 Operation start WAIT_FOR_FLOW condition exists 502 From ‘IDLE to ‘IDLE: Next P1 = 0 503 From WAIT_FOR_FLOW Next P1 = 1 and New data to ACTIVE_FLOW VI = 1 coming in 504 From WAIT_FOR_FLOW Next P1 = 1 and to WAIT_FOR_FLOW: VI = 0 505 From WAIT_FOR_FLOW VI = 1 and next Last data to LAST_FLOW P1 = 0 coming in 506 From WAIT_FOR_FLOW VI = 0 and next to IDLE P1 = 0 507 From ‘ACTIVE_FLOW to Next P1 = 1 and New data ACTIVE_FLOW VI = 1 coming in while old data is taken out 508 From ‘ACTIVE_FLOW to Next P1 = 1 and WAIT_FOR_FLOW VI = 0 509 From ‘ACTIVE_FLOW to VI = 1 and next Last data LAST_FLOW P1 = 0 coming in while old data is taken out 510 From ‘ACTIVE_FLOW VI = 0 and next to IDLE P1 = 0 511 From LAST_FLOW to “always” (no IDLE condition) - Thus, in accordance with certain embodiments of the present invention, the formulated state machine enables resolving of variables having no explicit expressions and fully specifying the control path elements.
- The method disclosed in the present invention may be done entirely automatically, automatically with a designer intervention at any step, and entirely manually and may use any programmable language suitable for design of electronic circuits. The principles of the present invention also allow formulation of special language optimized for certain aspects of the present invention.
- Referring to
FIG. 6 , there is illustrated, by way of non-limiting example, functional behavior rules describing design functionality in a meta-language. Connections between the illustrated code lines and the design rules illustrated with reference toFIG. 3 a are the following: - A
structure section 601 comprises behavior rules and conditions related to the data path elements; acontrol section 602 comprises behavior rules and conditions related to the control path elements and anattributes section 603 comprises design criteria conveys general design information. -
Line 1 corresponds to rule 3: DI will be sampled into DO under P1 control condition. -
Line 2 corresponds to rule 5: DO will be sampled provided VO is asserted. This shows alternative syntax as the VO condition might be detailed in the control section. -
Line 3 corresponds to rule 7: DONE signal is a sampled version of the end condition of P3 control definition. -
Line 4 corresponds to rule 4: P1 is asserted between GO and END signals and the flow associated with this condition is further conditioned by the existence of VI && RO logical combination. The virtual indication states that the relevant virtual condition (i.e. VI && RO) is the only condition upon which the input is considered as valid by the outer circuit. -
Line 5 corresponds to rule 6: P3 is asserted between end condition of P1 control condition and the non-validity of the DO data element. -
Line 6 corresponds to rule 8: data cannot be generated inside the circuit nor can it be overwritten and ignored (design criterion of data integrity). -
Line 7 corresponds to rule 9: external condition exists for GO assertion. GO can be asserted only if DONE was asserted after GO previous assertion. This kind of condition limits the possible design state machine transitions. - The certain embodiments of the present invention facilitate easily structured and short specification of the output structural level description. The following Verilog RTL code illustrates, by way of non-limiting example and without general definitions (e.g. module, inputs, outputs), structural level description of the exemplary circuit illustrated with reference to
FIG. 3 . -
// States encoding {grave over ( )}define IDLE 2’b00 {grave over ( )}define WAIT_FOR_FLOW 2’b01 {grave over ( )}define ACTIVE_FLOW 2’b10 {grave over ( )}define LAST_FLOW 2’b11 // Design registers reg DO, P1, P3, DONE; reg [1:0] state; // Design wires wire DO_valid, RO, VO, next_P1; reg [1:0] next_state; // Information flow through DO always @ (posedge clock or negedge reset) begin if (!reset) DO <= 0; else if (VI && RO) DO <= DI; end // State machine logic controlling DO flow always @ (state or next_P1 or VI) begin case (state) {grave over ( )}IDLE: if (next_P1) next_state = WAIT_FOR_FLOW; else next_state = {grave over ( )}IDLE; {grave over ( )}WAIT_FOR_FLOW: if ( next_P1 && VI) next_state = {grave over ( )}ACTIVE_FLOW; else if ( next_P1 && !VI) next_state = {grave over ( )}WAIT_FOR_FLOW; else if (!next_P1 && VI) next_state = {grave over ( )}LAST_FLOW; else next_state = {grave over ( )}IDLE; {grave over ( )}ACTIVE_FLOW: if (next_P1 && VI) next_state = {grave over ( )}ACTIVE_FLOW; else if ( next_P1 && !VI) next_state={grave over ( )}WAIT_FOR_FLOW; else if (!next_P1 && VI) next_state = {grave over ( )}LAST_FLOW; else next_state = {grave over ( )}IDLE; {grave over ( )}LAST_FLOW: next_state = {grave over ( )}IDLE; endcase end always @ (posedge clock or negedge reset) begin if (!reset) state <= {grave over ( )}IDLE; else state <= next_state; end // Information flow control signals generation assign DO_valid = (state == {grave over ( )}LAST_FLOW) || (state == {grave over ( )}ACTIVE FLOW); assign RO = (state == {grave over ( )}WAIT_FOR_FLOW || (state == {grave over ( )}ACTIVE_FLOW); assign VO = (state == {grave over ( )}LAST_FLOW) || (state == {grave over ( )}ACTIVE_FLOW); // Misc. control generation // GO is valid out of (go, done) assign next_P1 = GO ? 1 : (END ? 0 : P1); always @ (posedge clock or negedge reset) begin if (!reset) begin P1 <= 0; P3 <= 0; end else begin P1 <= next_P1; if (P1 & & END) P3 <= 1; else if (!DO_valid) P3 <= 0; end end // Output signals generation always @ (posedge clock or negedge reset) begin if (!reset) DONE <= 0; else begin if (P3 & & !DO_valid) DONE <= 1; else DONE <= 0; end end - It is to be understood that the invention is not limited in its application to the details set forth in the description contained herein or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Hence, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. As such, those skilled in the art will appreciate that the concept upon which this disclosure is based may readily be utilized as a basis for designing other structures, methods, and systems for carrying out the several purposes of the present invention.
- Those skilled in the art will readily appreciate that various modifications and changes can be applied to the embodiments of the invention as hereinbefore described without departing from its scope, defined in and by the appended claims.
- It will also be understood that the system according to the invention may be a suitably programmed computer. Likewise, the invention contemplates a computer program being readable by a computer for executing the method of the invention. The invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention.
Claims (20)
1. A method of designing a structural level description of an electronic circuit, the method comprising:
(a) obtaining data path and control path elements specifying the electronic circuit, wherein at least one control path element is provided in a form of unresolved variable;
(b) obtaining a plurality of rules describing, at least, a functional behavior of the electronic circuit;
(c) extracting a plurality of unresolved variables among the control path elements;
(d) automated processing data path and control path elements for accomplishing a state machine formulation, wherein the states of the state machine include states representing at least combinations of unresolved variables and corresponding transitions satisfying said plurality of rules and predefined design criteria.
2. The method of claim 1 wherein the automated processing facilitates correctness-preserving educing of the structural level design.
3. The method of claim 1 wherein the predefined design criteria comprise: (a) criterion of logic contradiction; (b) criterion of data integrity; (c) criterion of design flow enabling.
4. The method of claim 1 wherein the predefined design criteria comprise constrains introduced for a special purpose.
5. The method of claim 4 wherein the special purpose is reduction of power consuming of the electronic circuit.
6. The method of claim 1 wherein the structural level description comprises register transfer level description.
7. The method of claim 1 wherein the structural description comprises statements in at least one of the languages selected from a group comprising Verilog, VHDL, SystemVerilog and SystemC description.
8. The method of claim 1 wherein said plurality of unresolved variables includes all unresolved variables comprised among the control path elements.
9. The method of claim 1 wherein the states of the state machine include states representing combinations of resolved and unresolved variables.
10. A method of designing a structural level description of an electronic circuit, the method comprising:
(a) obtaining data path and control path elements specifying the electronic circuit, wherein at least one control path element is provided in a form of unresolved variable;
(b) obtaining plurality of rules;
(c) extracting a plurality of unresolved variables among the control path elements;
(d) automated processing of data path and control path elements for obtaining values of unresolved variables satisfying said plurality of rules and predefined design criteria.
11. The method of claim 10 wherein the predefined design criteria comprise: (a) criterion of logic contradiction; (b) criterion of data integrity; (c) criterion of design flow enabling.
12. The method of claim 10 wherein the predefined design criteria comprise constrains introduced for a special purpose.
13. The method of claim 12 wherein the special purpose is reduction of power consuming of the electronic circuit.
14. The method of claim 10 wherein the structural level description comprises register transfer level description.
15. The method of claim 10 wherein the states of the state machine include states representing combinations of resolved and unresolved variables.
16. A system for designing a structural level description of an electronic circuit with functional behavior described by a plurality of rules, the circuit being specified by data path and control path elements wherein at least one control path element is provided in a form of unresolved variable; the system comprising a processor for automated processing of data path and control path elements for accomplishing a state machine formulation, wherein the states of the state machine include states representing at least combinations of unresolved variables and corresponding transitions satisfying said plurality of rules and predefined design criteria.
17. The system of claim 16 wherein said plurality of unresolved variables includes all unresolved variables comprised among the control path elements.
18. The system of claim 16 wherein the states of the state machine include states representing combinations of resolved and unresolved variables.
19. A computer program comprising computer program code means for performing all the steps of claim 1 when said program is run on a computer.
20. A computer program as claimed in claim 19 embodied on a computer readable medium.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/816,119 US20100251196A1 (en) | 2004-09-02 | 2010-06-15 | Method and System for Designing a Structural Level Description of an Electronic Circuit |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US60642504P | 2004-09-02 | 2004-09-02 | |
PCT/IL2005/000935 WO2006025062A2 (en) | 2004-09-02 | 2005-09-01 | Method and system for designing a structural level description of an electronic circuit |
US57466707A | 2007-04-05 | 2007-04-05 | |
US12/816,119 US20100251196A1 (en) | 2004-09-02 | 2010-06-15 | Method and System for Designing a Structural Level Description of an Electronic Circuit |
Related Parent Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IL2005/000935 Continuation WO2006025062A2 (en) | 2004-09-02 | 2005-09-01 | Method and system for designing a structural level description of an electronic circuit |
US57466707A Continuation | 2004-09-02 | 2007-04-05 |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100251196A1 true US20100251196A1 (en) | 2010-09-30 |
Family
ID=36000438
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/574,667 Expired - Fee Related US7769569B2 (en) | 2004-09-02 | 2005-09-01 | Method and system for designing a structural level description of an electronic circuit |
US12/816,119 Abandoned US20100251196A1 (en) | 2004-09-02 | 2010-06-15 | Method and System for Designing a Structural Level Description of an Electronic Circuit |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/574,667 Expired - Fee Related US7769569B2 (en) | 2004-09-02 | 2005-09-01 | Method and system for designing a structural level description of an electronic circuit |
Country Status (4)
Country | Link |
---|---|
US (2) | US7769569B2 (en) |
EP (1) | EP1784749A2 (en) |
JP (1) | JP2008511894A (en) |
WO (1) | WO2006025062A2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100083204A1 (en) * | 2008-09-26 | 2010-04-01 | Fujitsu Limited | Verification support apparatus, verification support method, and computer product |
US8806403B1 (en) * | 2013-06-21 | 2014-08-12 | Altera Corporation | Efficient configuration of an integrated circuit device using high-level language |
US10489128B2 (en) * | 2015-11-11 | 2019-11-26 | Oracle International Corporation | Type inference optimization |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7703058B2 (en) * | 2006-05-30 | 2010-04-20 | International Business Machines Corporation | Method and system for changing a description for a state transition function of a state machine engine |
US7712060B1 (en) * | 2007-02-27 | 2010-05-04 | Cadence Design Systems, Inc. | Method and system for handling assertion libraries in functional verification |
US7810056B1 (en) * | 2007-02-27 | 2010-10-05 | Cadence Design Systems, Inc. | Method and system for implementing context aware synthesis of assertions |
US20090007038A1 (en) * | 2007-04-05 | 2009-01-01 | Nec Laboratories America, Inc. | Hybrid counterexample guided abstraction refinement |
US7958476B1 (en) * | 2007-07-10 | 2011-06-07 | Magma Design Automation, Inc. | Method for multi-cycle path and false path clock gating |
US8140313B2 (en) * | 2008-01-30 | 2012-03-20 | International Business Machines Corporation | Techniques for modeling variables in subprograms of hardware description language programs |
US7949679B2 (en) * | 2008-03-05 | 2011-05-24 | International Business Machines Corporation | Efficient storage for finite state machines |
US8185850B1 (en) * | 2010-03-23 | 2012-05-22 | Xilinx, Inc. | Method of implementing a circuit design using control and data path information |
US8966416B2 (en) | 2013-03-07 | 2015-02-24 | Cadence Design Systems, Inc. | Finite-state machine encoding during design synthesis |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5537580A (en) * | 1994-12-21 | 1996-07-16 | Vlsi Technology, Inc. | Integrated circuit fabrication using state machine extraction from behavioral hardware description language |
US6415420B1 (en) * | 1999-04-30 | 2002-07-02 | Incentia Design Systems, Inc. | Synthesizing sequential devices from hardware description languages (HDLS) |
US6421808B1 (en) * | 1998-04-24 | 2002-07-16 | Cadance Design Systems, Inc. | Hardware design language for the design of integrated circuits |
US6557160B2 (en) * | 1999-12-21 | 2003-04-29 | Khalil Shalish | Correlation of behavioral HDL signals |
US6591403B1 (en) * | 2000-10-02 | 2003-07-08 | Hewlett-Packard Development Company, L.P. | System and method for specifying hardware description language assertions targeting a diverse set of verification tools |
US6597664B1 (en) * | 1999-08-19 | 2003-07-22 | Massachusetts Institute Of Technology | Digital circuit synthesis system |
US6604232B2 (en) * | 2000-02-18 | 2003-08-05 | Sharp Kabushiki Kaisha | High-level synthesis method and storage medium storing the same |
US6606734B2 (en) * | 2001-06-21 | 2003-08-12 | David J. Greaves | Simulation method and compiler for hardware/software programming |
US6675359B2 (en) * | 1998-08-26 | 2004-01-06 | Michael E.J. Gilford | Recognition of a state machine in high-level integrated circuit description language code |
US20040139153A1 (en) * | 2002-09-24 | 2004-07-15 | Siemens Aktiengesellschaft | Computer and/or software architecture using microkernel and multi-tier concept with component technology |
US20050289486A1 (en) * | 2004-06-24 | 2005-12-29 | International Business Machines Corporation | Equivalence checking of scan path flush operations |
US7237220B2 (en) * | 2004-06-25 | 2007-06-26 | Matsushita Electric Industrial Co., Ltd. | High level synthesis method for semiconductor integrated circuit |
US7383166B2 (en) * | 1999-10-08 | 2008-06-03 | Nec Corporation | Verification of scheduling in the presence of loops using uninterpreted symbolic simulation |
Family Cites Families (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3559728A (en) * | 1968-11-29 | 1971-02-02 | Kooltronic Fan Co | Electronic equipment rack temperature control |
US4197716A (en) * | 1977-09-14 | 1980-04-15 | Halstead Industries, Inc. | Refrigeration system with auxiliary heat exchanger for supplying heat during defrost cycle and for subcooling the refrigerant during a refrigeration cycle |
US4285205A (en) * | 1979-12-20 | 1981-08-25 | Martin Leonard I | Refrigerant sub-cooling |
KR900001842B1 (en) * | 1984-11-15 | 1990-03-24 | 후지쓰 가부시끼가이샤 | Cooling structure of electronic equipment rack |
JPH0770853B2 (en) * | 1987-01-21 | 1995-07-31 | 株式会社日立製作所 | Electronic device cooling system |
GB8724263D0 (en) * | 1987-10-15 | 1987-11-18 | Bicc Plc | Electronic enclosure cooling system |
US5173819A (en) * | 1988-10-05 | 1992-12-22 | Hitachi, Ltd. | Disk apparatus having an improved cooling structure |
US5649428A (en) * | 1993-01-08 | 1997-07-22 | Engelhard/Icc | Hybrid air-conditioning system with improved recovery evaporator and subcool condenser coils |
US5657641A (en) * | 1995-09-13 | 1997-08-19 | Kooltronic, Inc. | Panel mounted cooling system |
US6494050B2 (en) * | 2000-02-18 | 2002-12-17 | Toc Technology, Llc | Computer rack heat extraction device |
US6459579B1 (en) * | 2001-01-03 | 2002-10-01 | Juniper Networks, Inc. | Apparatus and method for directing airflow in three dimensions to cool system components |
US7165112B2 (en) * | 2001-06-22 | 2007-01-16 | Motorola, Inc. | Method and apparatus for transmitting data in a communication system |
US20030042004A1 (en) * | 2001-08-29 | 2003-03-06 | Shlomo Novotny | Interchangeable cartridges for cooling electronic components |
GB0207382D0 (en) * | 2002-03-28 | 2002-05-08 | Holland Heating Uk Ltd | Computer cabinet |
US6668565B1 (en) * | 2002-04-12 | 2003-12-30 | American Power Conversion | Rack-mounted equipment cooling |
US6695577B1 (en) * | 2002-08-13 | 2004-02-24 | American Power Conversion | Fan grill |
US6662576B1 (en) * | 2002-09-23 | 2003-12-16 | Vai Holdings Llc | Refrigeration system with de-superheating bypass |
US7500911B2 (en) * | 2002-11-25 | 2009-03-10 | American Power Conversion Corporation | Exhaust air removal system |
US7752858B2 (en) * | 2002-11-25 | 2010-07-13 | American Power Conversion Corporation | Exhaust air removal system |
US6745590B1 (en) * | 2003-01-13 | 2004-06-08 | American Power Conversion | Condensate removal system |
SE0300742D0 (en) | 2003-03-17 | 2003-03-17 | Flow Computing Ab | Data Flow Machine |
US6859366B2 (en) * | 2003-03-19 | 2005-02-22 | American Power Conversion | Data center cooling system |
US7046514B2 (en) * | 2003-03-19 | 2006-05-16 | American Power Conversion Corporation | Data center cooling |
EP1616237B1 (en) * | 2003-04-14 | 2017-10-25 | Schneider Electric IT Corporation | Environmental monitoring device |
US7033267B2 (en) * | 2003-05-13 | 2006-04-25 | American Power Conversion Corporation | Rack enclosure |
US7112131B2 (en) * | 2003-05-13 | 2006-09-26 | American Power Conversion Corporation | Rack enclosure |
US20060082263A1 (en) * | 2004-10-15 | 2006-04-20 | American Power Conversion Corporation | Mobile data center |
US7259963B2 (en) * | 2004-12-29 | 2007-08-21 | American Power Conversion Corp. | Rack height cooling |
US7603874B2 (en) * | 2005-01-24 | 2009-10-20 | American Power Conversion Corporation | Split power input to chiller |
US7885795B2 (en) * | 2005-05-02 | 2011-02-08 | American Power Conversion Corporation | Methods and systems for managing facility power and cooling |
US7881910B2 (en) * | 2005-05-02 | 2011-02-01 | American Power Conversion Corporation | Methods and systems for managing facility power and cooling |
US7841199B2 (en) * | 2005-05-17 | 2010-11-30 | American Power Conversion Corporation | Cold aisle isolation |
US7406839B2 (en) * | 2005-10-05 | 2008-08-05 | American Power Conversion Corporation | Sub-cooling unit for cooling system and method |
-
2005
- 2005-09-01 EP EP05777758A patent/EP1784749A2/en not_active Withdrawn
- 2005-09-01 JP JP2007529138A patent/JP2008511894A/en active Pending
- 2005-09-01 WO PCT/IL2005/000935 patent/WO2006025062A2/en active Application Filing
- 2005-09-01 US US11/574,667 patent/US7769569B2/en not_active Expired - Fee Related
-
2010
- 2010-06-15 US US12/816,119 patent/US20100251196A1/en not_active Abandoned
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5537580A (en) * | 1994-12-21 | 1996-07-16 | Vlsi Technology, Inc. | Integrated circuit fabrication using state machine extraction from behavioral hardware description language |
US6421808B1 (en) * | 1998-04-24 | 2002-07-16 | Cadance Design Systems, Inc. | Hardware design language for the design of integrated circuits |
US6675359B2 (en) * | 1998-08-26 | 2004-01-06 | Michael E.J. Gilford | Recognition of a state machine in high-level integrated circuit description language code |
US6415420B1 (en) * | 1999-04-30 | 2002-07-02 | Incentia Design Systems, Inc. | Synthesizing sequential devices from hardware description languages (HDLS) |
US6597664B1 (en) * | 1999-08-19 | 2003-07-22 | Massachusetts Institute Of Technology | Digital circuit synthesis system |
US7383166B2 (en) * | 1999-10-08 | 2008-06-03 | Nec Corporation | Verification of scheduling in the presence of loops using uninterpreted symbolic simulation |
US6557160B2 (en) * | 1999-12-21 | 2003-04-29 | Khalil Shalish | Correlation of behavioral HDL signals |
US6604232B2 (en) * | 2000-02-18 | 2003-08-05 | Sharp Kabushiki Kaisha | High-level synthesis method and storage medium storing the same |
US6591403B1 (en) * | 2000-10-02 | 2003-07-08 | Hewlett-Packard Development Company, L.P. | System and method for specifying hardware description language assertions targeting a diverse set of verification tools |
US6606734B2 (en) * | 2001-06-21 | 2003-08-12 | David J. Greaves | Simulation method and compiler for hardware/software programming |
US20040139153A1 (en) * | 2002-09-24 | 2004-07-15 | Siemens Aktiengesellschaft | Computer and/or software architecture using microkernel and multi-tier concept with component technology |
US20050289486A1 (en) * | 2004-06-24 | 2005-12-29 | International Business Machines Corporation | Equivalence checking of scan path flush operations |
US7237220B2 (en) * | 2004-06-25 | 2007-06-26 | Matsushita Electric Industrial Co., Ltd. | High level synthesis method for semiconductor integrated circuit |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100083204A1 (en) * | 2008-09-26 | 2010-04-01 | Fujitsu Limited | Verification support apparatus, verification support method, and computer product |
US8060848B2 (en) * | 2008-09-26 | 2011-11-15 | Fujitsu Limited | Verification support apparatus, verification support method, and computer product |
US8806403B1 (en) * | 2013-06-21 | 2014-08-12 | Altera Corporation | Efficient configuration of an integrated circuit device using high-level language |
US10489128B2 (en) * | 2015-11-11 | 2019-11-26 | Oracle International Corporation | Type inference optimization |
US10896031B2 (en) | 2015-11-11 | 2021-01-19 | Oracle International Corporation | Type inference optimization |
US11163545B2 (en) | 2015-11-11 | 2021-11-02 | Oracle Intemnational Corporation | Type inference optimization |
Also Published As
Publication number | Publication date |
---|---|
EP1784749A2 (en) | 2007-05-16 |
WO2006025062A2 (en) | 2006-03-09 |
WO2006025062A3 (en) | 2006-05-18 |
US20080015838A1 (en) | 2008-01-17 |
US7769569B2 (en) | 2010-08-03 |
JP2008511894A (en) | 2008-04-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7769569B2 (en) | Method and system for designing a structural level description of an electronic circuit | |
US8122398B2 (en) | Conversion of circuit description to an abstract model of the circuit | |
Bhatnagar | Advanced ASIC chip synthesis | |
Barbacci | Instruction set processor specifications (ISPS): The notation and its applications | |
Cerny et al. | SVA: the power of assertions in systemVerilog | |
US6536031B2 (en) | Method for generating behavior model description of circuit and apparatus for logic verification | |
US7231627B2 (en) | Merging a hardware design language source file with a separate assertion file | |
US20070294647A1 (en) | Transferring software assertions to hardware design language code | |
KR100305463B1 (en) | Method and system for the design and simulation of digital computer hardware | |
US8650513B2 (en) | Reducing x-pessimism in gate-level simulation and verification | |
US7350180B1 (en) | Search algorithm for inheriting clock contexts in hardware description language translation tools | |
US11238202B2 (en) | Verifying glitches in reset path using formal verification and simulation | |
US6658630B1 (en) | Method to translate UDPs using gate primitives | |
Kambe et al. | A c-based synthesis system, bach, and its application (invited talk) | |
US20110161897A1 (en) | Method and apparatus for simulating behavioral constructs using indeterminate values | |
US20030237078A1 (en) | Incorporating simulation analysis instrumentation into HDL models | |
US7257786B1 (en) | Method and apparatus for solving constraints | |
Morin-Allory et al. | Efficient and correct by construction assertion-based synthesis | |
Kommuru et al. | ASIC design flow tutorial using synopsys tools | |
IL181273A (en) | Method and system for designing a structural level description of an electronic circuit | |
Yang et al. | HDLs modeling technique for burst-mode and extended burst-mode asynchronous circuits | |
US20230205969A1 (en) | Techniques for modeling and verification of convergence for hierarchical domain crossings | |
Ghofrani et al. | Assertion based verification in TLM | |
CN117149202A (en) | Compiling method, device, equipment, medium and product for hardware description language | |
Lovic et al. | HDLRuby: A Ruby Extension for Hardware Description and its Translation to Synthesizable Verilog HDL |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |