An efficient implementation of reactivity for modeling hardware in the scenic design environment

Liao, Stan; Tjiang, Steve; Gupta, Rajesh K.

doi:10.1145/266021.266037

Cited by 75 publications

(37 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Developed at Synopsys in the late 1990s, primarily by Stan Liao, SystemC was originally called Scenic [34] and was intended to replace Verilog and VHDL as the main system description language for synthesis (see Arnout [2] for some of the arguments for SystemC). SystemC is not so much a language as a C++ library along with a set of coding rules, but this is exactly its strength.…”

Section: Systemcmentioning

confidence: 99%

Formal Property Verification

Edwards¹

2017

Electronic Design Automation for IC System Design, Verification, and Testing

View full text Add to dashboard Cite

After a few decades of research and experimentation, registertransfer dialects of two standard languages-Verilog and VHDL-have emerged as the industry standard starting point for automatic large-scale digital integrated circuit synthesis. Writing RTL descriptions of hardware remains a largely human process and hence the clarity, precision, and ease with which such descriptions can be coded correctly has a profound impact on the quality of the final product and the speed with which the design can be created.While the efficiency of a design (e.g., the speed at which it can run or the power it consumes) is obviously important, its correctness is usually the paramount issue, consuming the majority of the time (and hence money) spent during the design process. In response to this challenge, a number of so-called verification languages have arisen. These have been designed to assist in a simulation-based or formal verification process by providing mechanisms for checking temporal properties, generating pseudorandom test cases, and for checking how much of a design's behavior has been exercised by the test cases.Through examples and discussion, this report describes the two main design languages-VHDL and Verilog-as well as SystemC, a language currently used to build large simulation models; SystemVerilog, a substantial extension of Verilog; and OpenVera, e, and PSL, the three leading contenders for becoming the main verification language.

show abstract

Section: Systemcmentioning

confidence: 99%

Formal Property Verification

Edwards¹

2017

Electronic Design Automation for IC System Design, Verification, and Testing

View full text Add to dashboard Cite

show abstract

“…Reactivity can provide one with the capability to kill or reset a transaction before the transaction completes. This is analogous -but for transactions -to the reactive features for processes that were present in the earlier versions of SystemC through the "wait" and "watching" syntactic constructs [3]. The "watching" constructed was later dropped from SystemC due to lack of use.…”

Section: Introductionmentioning

confidence: 93%

“…These watching-and-waiting statements have been using exceptions to throw special conditions designating reset conditions [3]. For this purpose, we follow a similar pattern and we introduce a new wait macro, which we call MYWAIT :…”

Section: Reactivity Through Exceptions and Architectural Patternsmentioning

confidence: 99%

Reactivity in SystemC Transaction-Level Models

Doucet

Shyamasundar

Krüger

et al.

Hardware and Software: Verification and Testing

View full text Add to dashboard Cite

Abstract. SystemC is a popular language used in modeling systemon-chip implementations. To support this task at a high level of abstraction, transaction-level modeling (TLM) libraries have been recently developped. While TLM libraries are useful, it is difficult to capture the reactive nature of certain transactions with the constructs currently available in the SystemC and TLM libraries. In this paper, we propose an approach to specify and verify reactive transactions in SystemC designs. Reactive transactions are different from TLM transactions in the sense that a transaction can be killed or reset. Our approach consists of: (1) a language to describe reactive transactions that can be translated to verification monitors, (2) an architectural pattern to implement reactive transactions, and (3) the verification support to verify that the design does not deadlock, allows only legal behaviors and is always responsive. We illustrate our approach through an example of a transactional memory system where a transaction can be killed or reset before its completion. We identify the architectural patterns for reactive transactions. Our results demonstrate the feasibility of our approach as well as support for a comprehensive verification using RuleBase/NuSMV tools.

show abstract

“…Behavioral descriptions typically describe hardware, or hardware/software systems, as multiple threads of computation that communicate via a message-passing or shared-memory paradigm [13,4,14,17,5]. As in CFSM frameworks, designers of behavioral descriptions still need to manage the interactions between concurrent computations explicitly.…”

Section: Comparison To Other High-level Frameworkmentioning

confidence: 99%

Synthesis of operation-centric hardware descriptions

Hoe¹,

Arvind²

IEEE/ACM International Conference on Computer Aided Design. ICCAD - 2000. IEEE/ACM Digest of Technical Papers (Cat. No.00CH3714

View full text Add to dashboard Cite

Most hardware description frameworks, whether schematic or textual, use cooperating finite state machines (CFSM) as the underlying abstraction. In the CFSM framework, a designer explicitly manages the concurrency by scheduling the exact cycle-by-cycle interactions between multiple concurrent state machines. Design mistakes are common in coordinating interactions between two state machines because transitions in different state machines are not semantically coupled. It is also difficult to modify one state machine without considering its interaction with the rest of the system. This paper presents a method for hardware synthesis from an "operation centric" description, where the behavior of a system is described as a collection of "atomic" operations in the form of rules. Typically, a rule is defined by a predicate condition and an effect on the state of the system. The atomicity requirement simplifies the task of hardware description by permitting the designer to formulate each rule as if the rest of the system is static.An implementation can execute several rules concurrently in a clock cycle, provided some sequential execution of those rules can reproduce the behavior of the concurrent execution. In fact, detecting and scheduling valid concurrent execution of rules is the central issue in hardware synthesis from operation-centric descriptions. The result of this paper shows that an operation-centric framework offers significant reduction in design time, without loss in implementation quality.

show abstract

An efficient implementation of reactivity for modeling hardware in the scenic design environment

Cited by 75 publications

References 15 publications

Formal Property Verification

Formal Property Verification

Reactivity in SystemC Transaction-Level Models

Synthesis of operation-centric hardware descriptions

Contact Info

Product

Resources

About