Verification of the IBM RISC System/6000 by a dynamic biased pseudo-random test program generator

Aharon, Avihai; Dorfman, B.; Gofman, Emanuel; Leibowitz, M.; Schwartzburd, V.; Bar-David, A.

doi:10.1147/sj.304.0527

Cited by 75 publications

(28 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Various solutions have been previously proposed to tackle the design verification problem [2,3,4,5]. Many of these solutions involve an automated test generator based on some form of pseudo random selection scheme to create test cases.…”

Section: Related Workmentioning

confidence: 99%

Using Genetic Evolutionary Software Application Testing to Verify a DSP SoC

Cheng

Lim

Sun³

et al. 2008

4th IEEE International Symposium on Electronic Design, Test and Applications (Delta 2008)

View full text Add to dashboard Cite

IntroductionDesign verification of system-on-chips (SoCs) is expensive and time consuming. It accounts for up to 70% of resources in a typical design project [1]. Designing digital signal processor (DSP) SoCs create further verification complexities given the range of applications and end products DSPs are employed within.In order to test a DSP design more effectively, consideration must be given to how the DSP will be used and their intended applications. The eventual real-life usages of a DSP determine the particular design features and functions that are needed in the DSP. It is these design functionalities and their complexities that must be verified in-depth. Therefore, any effective verification strategy must incorporate extensive testing with application functions.To demonstrate this, the software application level verification methodology (SALVEM) [7,8] is employed to test the Tsinghua University Application Specific DSP (THUASDSP2004) [9]. The SALVEM technique was successfully used on other SoC previously [7,8]. The aim of this paper is to describe the application of SALVEM on a real world DSP SoC; thus demonstrate its feasibility and usefulness for DSP testing. Furthermore, for verification of the DSP, SALVEM is enhanced by an automated test generator that uses genetic evolutionary methods to create tests. The THUASDSP2004 DSP is an ideal candidate for SALVEM. It was designed specifically for multimedia applications and contains common DSP function blocks such as high performance mathematical and fast data transfer units, along with other specialized modules. These DSP architectural features are to be tested by SALVEM to enhance the design and verification quality of the DSP SoC.The reminder of this paper is as follows. Section 2 summarizes related work in design verification. Section 3 describes the DSP SoC design. The SALVEM verification approach and test generator are outlined in sections 4 and 5 respectively. Section 6 provides experimental results before the paper is concluded. Related WorkVarious solutions have been previously proposed to tackle the design verification problem [2,3,4,5]. Many of these solutions involve an automated test generator based on some form of pseudo random selection scheme to create test cases. The advantage with this approach is that many test cases can be created quickly with minimal effort. However, testing may not be optimized or effective. Due to the inherently random nature of such tests, similar functions may be repeatedly tested or other important test functions overlooked. Ideally, the tests generated should cover as much of the previously untested and critical design functions.Furthermore, hardware DSP designs require special verification considerations. Some DSP design and modeling environments like Matlab or Simulink do not describe the true hardware design implementation that will be eventually tape-out. They focus on high level DSP algorithmic validation, but the actual hardware design is not tested directly [10]

show abstract

Section: Related Workmentioning

confidence: 99%

Using Genetic Evolutionary Software Application Testing to Verify a DSP SoC

Cheng

Lim

Sun³

et al. 2008

4th IEEE International Symposium on Electronic Design, Test and Applications (Delta 2008)

View full text Add to dashboard Cite

show abstract

“…Early on, these test programs were either manually developed or derived from code fragments from previous machines. Random test case generation was also used to explore subtle errors [15] and was refined to produce tests targeted at specific conditions.…”

Section: ) Test Program Generationmentioning

confidence: 99%

EDA in IBM: past, present, and future

Darringer

Davidson

Hathaway

et al. 2000

IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst.

View full text Add to dashboard Cite

Abstract-Throughout its history, from the early four-circuit gate-array chips of the late 1960s to today's billion-transistor multichip module, IBM has invested in tools to support its leading-edge technology and high-performance product development. The combination of demanding designs and close cooperation among product, technology, and tool development has given rise to many innovations in the electronic design automation (EDA) area and provided IBM with a significant competitive advantage. This paper highlights IBM's contributions over the last four decades and presents a view of the future, where the best methods of multimillion gate ASIC and gigahertz microprocessor design are converged to enable highly productive system-on-a-chip designs that include widely diverse hardware and software components.

show abstract

“…It provides a cheap way to take advantage of the billion-cycles-a-day simulation-capacity of networked workstations available in many big design organizations. Sophisticated systems have been developed that are biased towards corner cases, thus improving the quality of the tests significantly [1]. Another source of test stimuli, thanks to advances in simulator and emulator technology, is existing application and system software.…”

Section: Introductionmentioning

confidence: 99%

“…Various coverage metrics have been proposed to address this problem. These include code coverage metrics from software testing [1,4,7], finite state machine coverage [16,17,23], architectural event coverage [17], and observability-based metrics [12]. A shortcoming of all these metrics is that the relationship between the metric and detection of classes of design errors is not well understood.…”

Section: Introductionmentioning

confidence: 99%