Verification Methodologies in a TLM-to-RTL Design Flow

Kasuya,; Abebe, Tesfaye

doi:10.1109/dac.2007.375152

Cited by 11 publications

(6 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Therefore, our assertion suite minimizes the Design-Verification phase and enhances Time-to-Market factor. The second noteworthy work which matches closely to ours is the mechanism and IP created by Atsushi Kasuya et al [4]. In order to employ their verification process, they developed 'NSCa', a native assertion mechanism in SystemC environment.…”

Section: Related Worksupporting

confidence: 55%

A re-usable verification framework of Open Core Protocol (OCP)

Zhang

Ahmed

Mohamed

2009

2009 Joint IEEE North-East Workshop on Circuits and Systems and TAISA Conference

View full text Add to dashboard Cite

Open Core Protocol (OCP) establishes itself as the only non-proprietary, openly licensed, core-centric protocol that is used to support "plug-and-play" SOC (System-On-Chip) design practices. Designer can reuse OCP-compliance IP cores based on system integration and verification approach in multiple designs without reworking, reducing the development time and cutting down overall design costs. This paper addresses the development of a reusable verification framework of OCP. Assertion-based verification was chosen in order to enforce the flow. An OCP System Verilog monitor which was developed in house is used to verify the OCP SystemC TL1 (Cycle-accurate Level) design. The monitor can also be reused for OCP designs described at different abstraction level and thus dramatically reduce the time needed for OCP functional verification. With proper configuration of this monitor along with our System Verilog Assertion suite, we have found a potential bug in the OCP TL1 implementation which awaits confirmation of the OCP-IP group.

show abstract

Section: Related Worksupporting

confidence: 55%

A re-usable verification framework of Open Core Protocol (OCP)

Zhang

Ahmed

Mohamed

2009

2009 Joint IEEE North-East Workshop on Circuits and Systems and TAISA Conference

View full text Add to dashboard Cite

show abstract

“…System Verilog Assertions have been used for SystemC descriptions [6]. SystemC specific transaction level assertions have also been developed [8,3]. There is a growing vendor tool support for SystemC modeling and verification.…”

Section: Related Workmentioning

confidence: 99%

Predictive runtime verification of multi-processor SoCs in SystemC

Şen¹,

Ogale

Abadir³

2008

Proceedings of the 45th Annual Design Automation Conference

View full text Add to dashboard Cite

Concurrent interaction of multi-processor systems result in errors which are difficult to find. Traditional simulationbased verification techniques remove the concurrency information by arbitrary schedulings. We present a novel simulation-based technique for SystemC that preserves and exploits concurrency information. Our approach is unique in that we can detect potential errors in an observed execution, even if the error does not actually occur in that execution. We identify synchronization constructs in SystemC and develop predictive techniques for temporal assertion verification and deadlock detection. Our automated potential deadlock detection algorithm works on SystemC programs with semaphores, locks, wait and notify synchronizations and has less overhead compared with assertion verification. We patched SystemC kernel to implement our solution and obtained favorable results on industrial designs.

show abstract

“…On the other hand, Native SystemC assertion (NSCa) [12] provides a feature to indicate high-level events, such as a method call, by pointcut-like syntax. Since NSCa provides only an assertion verification feature, it is not an alternative to ASystemC.…”

Section: Related Workmentioning

confidence: 99%

ASystemC

Endoh

2011

Proceedings of the Tenth International Conference on Aspect-Oriented Software Development Companion

View full text Add to dashboard Cite

Hardware-design requirements are becoming increasingly complex. Accordingly, the hardware developer is also beginning to use modern programming languages instead of traditional hardware description languages. However, modularity of the current hardware design has not changed from that of the traditional design.In this paper, we first conducted empirical investigation by interviews with real-world developers of circuit products, and confirmed that there exist cross-cutting concerns in actual products. The cross-cutting concerns fall into two types: one in common with software development and one specific to hardware design. In light of these results, this paper proposes ASystemC, an AOP extension for the hardware description language SystemC. ASystemC provides AOP features based on the AspectJ-like pointcut-advice mechanism. The design principle of ASystemC is practicality; we designed ASystemC to accept existing SystemC source code, and to weave aspects by using source-to-source conversion that outputs human-readable SystemC code. This design allows a user to utilize not only existing codes but also the existing knowledge and development process, as much as possible. As a result, ASystemC does not require modification of the existing source code review process and source analysis/manipulation tools, even if there is a developer unfamiliar with ASystemC in a development team. In addition, we confirmed the practicality and flexibility of ASys-temC through case studies: estimation of circuit size by using simulation, feature-configurable products and LTL verification. These cases are abstracted from actual problems in our products. They require not only code-level changes but also structural changes. Languages KeywordsAspect-oriented programming, SystemC, Hardware description language SpecC[6] and SystemC [17].Nevertheless, the modularity of hardware development has not changed from that of the traditional design method, called register transfer language (RTL). RTL adopts a simple hierarchical module structure; a large module is constructed by connecting primitive modules ports. An RTL user needs to be aware of a final circuit structure. For example, since RTL's ports are represented like chip ports, they are assigned (connected) by wire. SystemC provides more abstract communication between modules, such as channels, which are represented as method calls. In this way, abstraction of communication is improved by SystemC. On the other hand, the SystemC module structure itself is not changed from RTL's; both are simply hierarchical, like object-oriented programming 1 .Previous reports on cross-cutting concerns in hardware development include [5], that pointed out reset and clock supply as a cross-cutting concern in hard-ware design, proposing an experimental pointcut-and-advice mechanism for hardware description language. To cite another example, [1] proposed ADH, which is an aspect-oriented language for hardware design. However, to our knowledge, there is no production-level aspect-oriented language for hardware design.

show abstract

Verification Methodologies in a TLM-to-RTL Design Flow

Cited by 11 publications

References 0 publications

A re-usable verification framework of Open Core Protocol (OCP)

A re-usable verification framework of Open Core Protocol (OCP)

Predictive runtime verification of multi-processor SoCs in SystemC

ASystemC

Contact Info

Product

Resources

About