Your SlideShare is downloading. ×
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Tem.10.M
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Tem.10.M

624

Published on

Flowtracer Disturbuted Build & …

Flowtracer Disturbuted Build &
Test Manager

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
624
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Flowtracer /TEM - Test Environment Manager A Collaborative Integrated SystemC-based work flow tool for Distributed ASIC Design and Verification Teams Charles Hart Envision Systems, 1803 Marabu Way, Fremont CA, 94539 /USA hartc_2000@yahoo.com Abstract While recent advancements in process technologies and sophisticated design methods enable true, system-on-a- chip (SoC) designs, the increased complexity of Hardware & Software in these designs levy increasingly demanding verification requirements on design teams. Verification already consumes over half the time and resources that are dedicated to today's 130-90nm SoC designs. SoC and ASIC engineers can expect even greater verification requirements with each new process generation. (V. Berman [1]) At least 80 percent of hardware designed today using hardware design languages (HDLs), like Verilog and VHDL, are designed at the register-transfer logic (RTL) level. Many design teams are finding that RTL descriptions with HDLs are at their limit for handling the size and complexity of today's designs. The issues include simulation times that are too long, verification solutions that are too complex and designs that are too large to describe at the RTL level. (V. Berman [2]) A 'higher level' design verification model is required which allows faster simulation cycle times of a 'higher level' simulation language. One solution is to implement architectural trade-offs on a High-level SystemC model. SystemC is a candidate for the language that will be used at all levels of system and chip design. Using SystemC in conjunction with RTL/Behavioral Design can accelerate this transition. SystemC opens the door for a new method of developing hardware systems and it can benefit current SoC design flows. In this paper, we describe the need for a higher level verification language and the use of more integrated design verification tools. If these tools can be shared between Design and Verification teams, they help to create visualization of processes and test results. This visualization of processes and test results can speed up implementation and management of the Verification Test Plan and the Design Verification Process. Also described is the implementation of an Integrated SystemC-based Verification environment that addresses these issues by using Runtime Design Automation's Flowtracer/EDA and it's Application Layer, the Test Environment Manager (TEM). This environment uses a ( Session based) Verification Methodology using both Assertion-based Verification and Coverage-driven Verification on a Web-browser interface for Distributed Design and Verification Teams. 1 Introduction While recent advancements in process technologies and sophisticated design methods enable true, system-on-a- chip(Soc) designs, the increased complexity of Hardware and Software in these designs levy increasingly demanding verification requirements on design teams. Verification already consumes over half the time and resources that are dedicated to today's 130-90nm SoC designs. SoC and ASIC engineers can expect even greater verification requirements with each new process generation (V. Berman [1]). Moore's Law predicted that
  • 2. the number of transistors per integrated circuit (gate count) would double every 18 to 24 months. Moore's Law has held for thirty years; it looks like it will hold for another ten at least. However, Front-end Verification requirements grow approximately as the square of the gate count - a sobering fact as designers move to next-generation process technologies capable of supporting 100M gates .(V. Berman [2]) (See Figures xx) Figure 1: Relationship between Increasingly Complex Design Flows and Cell Geometries. Note the increase in the number of process steps and handoffs as cell geometries get smaller. At least 80 percent of hardware designed today using hardware-design languages (HDL's), like Verilog and VHDL, are designed at the register-transfer logic (RTL) level. Many design teams are finding that RTL descriptions with HDL's are at or beyond their limit for handling the size and complexity of today's designs. The issues include simulation times that are too long, verification solutions that are too complex and designs that are too large to describe at the register-transfer logic (RTL) level. Along with rising gate counts, engineers face a shift toward software-intensive designs that significantly exacerbates verification complexity. (V. Berman [2]) As a result of the increasing verification complexity and concurrently shortened Design and Verification Cycles, today's verification methodologies, with HDL's only, are not likely to succeed.
  • 3. 2 EDA Environment Reality - Design Challenges (in 2005) Six convergent factors are changing the way EDA tools are used in SoC design. Diverse Tools – Tools from differing EDA vendors are often used together during development. These EDA tools, despite best intentions, were not built to work together. “Many developers and engineering teams using these same design tools get stuck in a rut. They're doing things the same way because it's easier not to change or..{omissis}..because the process works – somewhat.” (A. Raynaud [3]) EDA vendors must move beyond 'point-tool' technologies, and offer customers EDA tools with deeper integration, broader tool functional and interoperability. Aging Project Methodologies – Engineers stitch these EDA tools together, using ad-hoc and legacy scripts, without accounting for intra-tool dependency information. “ 56 % of tools budgets are spent internally – 80%of which is spent stitching tools together. Few vendors currently provide seamless design flows. We view this as one of biggest opportunities for the EDA industry to accelerate growth“. (Deutsche Bank/EE Times [4]) Shortening Project Schedules – Shorter Design and Verification Cycles with increasing design complexity, require more communication between design teams. More communication requires more design time particularly between distributed design teams. Also, there are more interrelated and concurrent design processes that overlap in time; and when things go wrong there is less time for corrective action. Today's Project Schedule Management requires multiple views of interrelated Design and Verification processes including: HDL Source Revision Control, Test Simulation Environment and Verification Test status, and Bug (or Issue Dependency) Tracking to name a few. Cost and time-to-market(CTTM)-”CTTM issues are reaching breaking point. Exploding chip complexity is testing traditional EDA tool flows. Customers are demanding deeper integration with fewer bugs in order to deliver SoC design for the growing wireless and consumer electronics market.” (Deutsche Bank [4]) “Increasing gate counts and greater software content are fueling a dramatic increase in system hardware states. They are driving a need for more effective system-level verification methodologies.” (V. Berman [1]) Design Outsourcing – According to the recent EE Times 2005 EDA Survey; “39% of the respondents indicated that their company outsources some portion of chip design to a third-party provider. {Omissis}.. Historically, a pickup in outsourcing was a reasonable leading indicator for increased design activity— companies utilize third-party vendors to offload incremental demand until the “upturn” looks sustainable, at which point full-time design engineers are hired.”(Deutsche Bank [4]) Distributed design and verification teams, both in different locations or time-zones, working on different pieces of the design are becoming the norm for SoC and ASICs . Design and Verification managers, and engineers need tools to track large amounts of data to communicate and manage a project's progress effectively . Collaborative Products - “Development teams can leverage a variety of collaborative products, such as e- mail and messaging products, discussion forums, workflow process engines, software configuration management, version control and bug-tracking tools, and portals. One problem corporate IT often faces is the 'islands' of development tools and methodologies that may exist within a large company. When building teams across business units or different companies, this can be an obstacle. But there are a few available solutions {omissis}, both in terms of the design building community -- and in working in distributed teams across the Internet.” (C. Fyre [10])
  • 4. Design Verification Challenges and Alternatives The rest of the paper proceeds as follows: First, we describe the need for a higher level verification language and the use of more integrated design verification tools. If these tools can be shared between Design and Verification teams, they help to create visualization of processes and test results. This visualization of processes and test results can speed up implementation and management of the Verification Test Plan and the Design Verification Process. Second, we layout the Software Development Requirements for a Design/Compile/Simulate/Debug Environment using a Virtual Prototyping Flow based on SystemC. The initial step of the functional verification is the creation of an executable specification using SystemC. This bit-true model is bus cycle accurate (or quasi cycle accurate) and provides a flexible software development platform for test and verification. Through the use of Assertion-based testing and Code Coverage this model simultaneously implements both Design Specification Validation and Verification. Further, we prove the efficacy of SystemC-based design flow by using Flowtracer/EDA to implement an integrated Browser-based verification environment (TEM) and it's management tools . The Web browser's scripts, when used in conjunction with CVS and a SQL Database, become a test management infrastructure (Knowledge-base); a tracking system allowing each design or verification engineer to learn how their work integrates with the work of others, while working independently. This shared knowledge helps to remove human variability in build and test environment and increases design verification productivity while minimizing rework. In the end, we summarize the results of the TEM implementation . 3 Set of Alternative Solutions – A Need for Change in approach in Design Verification Goal: Reduce the Verification/Design Gap – Moore's Law: Increasing gates count vs. Verification Effort Productivity: Effort in Design Verification has been increasing for the last years. = transistors/staff-months Problem: It has reached 70% of the total development effort, leaving only 30% for the actual design [5] System level design: Challenges and Requirements
  • 5. One solution to exploding chip gate-counts and the associated verification complexity is to raise the level of abstraction used in verification and use 'higher-level' models, like C/C++, during system-level simulations. But each solution has its own limitations. Basic C language lacks the three fundamental concepts necessary to model hardware designs: Concurrency, Connectivity (Hierarchy) and Time. Also, basic C++ also lacks the necessary features to support the (HVL) productivity cycle: Randomization, Constrainability, Temporal Expressions and Functional Coverage Measurement (J. Bergeron [7]). SystemC and Transaction-Level Modeling (TLM) SystemC is a de facto industry-standard language implemented as a C++ class library, providing both system- level and HDL modeling capabilities. SystemC provides hardware-oriented constructs within the context of C++ as a class library implemented in standard C++. Its use spans design and verification from concept to implementation in hardware and software. SystemC provides an open-source, inter-operable modeling platform which enables the development and exchange of very fast system-level C++ models. It also provides a stable platform for development of system-level tools. SystemC “extends” the C++ language without changing the syntax by using classes. Models are introduced as a means of encapsulating Software and Hardware Behavior and describing hierarchy.` The SystemC Library is a set of C++ classes developed the following concepts : Concurrency – The ability to describe actions that occur at the same time,independently of each other. Hardware systems are inherently concurrent and their components operate in parallel (as events in time); and are defined and executed within the SystemC simulator. In SystemC, parallelism is implemented via processes (SC_METHOD) and software threads (SC_THREAD). Connectivity – The ability to describe a design using simpler blocks then connecting them together. In SystemC, the simpler components are Modules, Ports, Processes, Interfaces, Channels and Events. A module may represent a system, a block, a board, or a chip and the ports may represent the interface, pins, etc. Notion of Time – The ability to represent how the internal state of a design block evolves over time. A model of computation (MOC) is broadly defined by a model of time (real, integer, untimed) and event ordering constraints (globally ordered, partially ordered, etc.) with methods of communication between processes and rules for process activation. Hardware Data Types – These describe arbitrary precision integers, fixed point numbers and 4 valued logic (ie. the data type used for describing a tri-state logic value (0,1,X,Z) - in RTL Hardware Gates) . SystemC is controlled by an industry consortium called OSCI (Open SystemC Initiative). SystemC is currently in the process of becoming an IEEE standard, with an originally targeted completion date of the first quarter of 2005. OSCI was formed in 2000 and took on the development and standardization of SystemC beginning with Version 1.0, which provided RTL and behavioral HDL modeling capabilities. The SystemC 2.0 Library, the current version, added general system-level modeling capabilities with channels, interfaces, and events. In 2003, the SystemC Verification Library (SCV 1.0) was released. SCV, originally based on Cadence's TestBuilder, was rebuilt on top of SystemC and submitted it to the Open SystemC Initiative. TestBuilder provides a C++ signal class, interfacing C++ to an HDL design at the signal level. Layered on SystemC, the SystemC Verification Library (SCV) is a set of C++ classes that provides support for randomization, constraints and temporal expressions. [2] Additional information about the SystemC language, tools, and OSCI (Open SystemC Initiative) organization can be found at: www.systemc.org .
  • 6. Transaction-Level Modeling – Simulation Advantages (Speed and Code Size) In SystemC, Transaction-Level Models(TLM) are used for modeling an executable platform and typically describe Hardware or behavioral simulations of hardware. The TLM model interface is 'Timed Functional' and may or may not be cycle-accurate. (in TEM, TLMs are cycle-accurate). One of SystemC's key advantages in using TLM over RTL is it's simulation speed. Typically, in a head-to-head comparison of RTL language Simulation cycle-times: C has a 25:1 speed advantage, over RTL
  • 7. SystemC TLM has a 100-1000:1 speed advantage, over RTL also in terms of Simulation Code Size (lines of code): SystemC (TLM vs. RTL) TLM models are 10x smaller than RTL: Consequently, they are easier to write and faster to simulate. Flowtracer/EDA : The Work Flow Manager Flowtracer/EDA is a resource management tool that tracks flows consisting of jobs, files and the dependencies between them. It can direct the parallel execution of jobs to bring files up-to-date (like Make) using any of the popular batch queuing systems. It has command-line, X-Windows GUI and Web-based interfaces to review and control flows. The Flowtracer/EDA usage model has two main steps: Plan out a flow by executing a TCL configuration file, Execute that flow by triggering an update process. As the flow executes, it is possible to monitor the progress as jobs pass, fail or wait to be executed. EDA is based on a dependency technology called “Runtime Tracing”,which is the ability to dynamically discover (tool, job or file) dependencies via the operating system, without explicitly being told what they are. This feature, of intercepting behavior dependencies (between tools and compute jobs), is a very important one within an integrated framework of tools like TEM, and essentially automates TEM's dependency management. What is Flowtracer TEM? Test Environment Manager Flowtracer/TEM is an application built on top of Flowtracer EDA. This application has been designed to support the Design Test and Verification engineer. Flowtracer/TEM attempts to unify under a common browser interface the daily activities of Distributed Design and Verification Teams, related to verification of complex hardware and software systems, including the interaction with the revision control system, like CVS, Perforce, SOS, ..etc the interaction with batch processing on the CPU Compute Farm like LSF, SGE, Flowtracer/NC the interaction with a large number of simulation and test runs – of various configurations the interaction with the SQL data used to store historical data about the testing activity Main attributes : TEM + SystemC for Verification Rapid prototyping and Modeling environment High Level Architectural Modeling Implementable modeling – Executable Specification
  • 8. Modular system that integrates disparate tools components needed to manage test sessions. These components include: A relational database MySQL -or- ORACLE A code revision control system CVS A compute farm (local servers) Flowtracer/NC -or- LSF, SGE A bug tracking and requirements system Bugzilla Integrated Design Team e-mailing lists
  • 9. Goals and Benefits of TEM: To Implement a Browser interface, effectively as a Control Panel for Distributed Design Teams,0 to perform the Verification process (via test sessions): where verification jobs can be launched, suspended, rerun or terminated ; and coordinated on a matrix of jobs vs. test processes on: module-by-module basis and by an overall Simulation test bench basis. Allow visualization of project data for the team developers, project leads and managers: bring together a development team that may cross departmental company boundaries or is distributed around the world. Promote clearer verification developer and design team communication, where the need for enhanced collaboration and teamwork is paramount. Modularize Verification testing, into a workflow process construct; consisting of a Build system, Code Revision Control, Bug Tracking and achieve/retrieval of previous test sessions. Automatically handle via a configurable workflow system: Controlling differing Simulations, Simulation's Environment, Compute Resources & Test bench test files used, Test Regression & Code Coverage options. Handle change control which refers to a number of issues: Code changes – (Code Revision Control) Store/checkout of the Simulation and Test bench test files. Achieving – File revisions (CSV) vs. Test results – to keep track of the relevant changes in files that could cause changes in outcomes. Relate test failures to causes for known bugs and automatically record unknown bugs for later broadcast to Verification testers and Design block owners via email. Handle the Simulation Process: Launching the Simulation onto the CPU server farm (via load sharing mechanism) Collecting the Simulation output Parsing the output logs and evaluation of the test Pass/Fail Criteria Relaunching jobs with the “exact environment” of previous test session failures Relate test failures to causes for known bugs and automatically record unknown bugs for later broadcast to Verification testers and Design block owners via email.
  • 10. Test History – Test Analysis: Spanning multiple Sessions Test Results – File Change Analysis between Sessions As part of the Change Analysis Process, Flowtracer/TEM achieves (CVS) File code revisions against (Test Session) results – to keep track of the relevant changes in files that could cause changes in outcomes. In fact, the Change Analysis page, below, is one of the most interesting and powerful features of Flowtracer/TEM. The Change Analysis Process brings together: information about file revisions information about file history (Test file results) information about file dependencies (Test build and Workflow- like Makefiles) First, TEM finds out which files have been modified between test sessions. Then it finds the files that are “upstream” dependencies of the specific test under consideration. Finally TEM finds the intersection of these two sets, to determine which changes are the most likely to be relevant for the change of test behavior that's been observed.
  • 11. Figure: Given the RSA test history above, find the relevant file changes, for a given change in test behavior (pass>fail ,etc) of the RSA Cryptography test, between any two test sessions.
  • 12. Test Management - Adding a New Test Session The instantiation of a New Test Session, adds an entry into the Session Database and also does a local CVS checkout of the SystemC Libraries, Test Session Flow and Test harness/case files required to do the simulation. Prior to the 'Add new session' instantiation, a typical user (or team member) would choose the details of the test run and simulation type by completing the New Session form. Normally test users add a new test session, by filling out the form below, using the browser interface.
  • 13. For a Given - New Session: the CVS Check-Out View determines which set of files while be checked-out by CVS and what type of System Simulation and Tests will be run. In the future, many other views may be possible – using different Simulator or Co-Simulators- Like Verilog or a Direct-C interface. The following page shows only the SystemC 2.1 View, it's tests, SystemC 2.1 Library and the SCV 1.0 Library (renamed here SCV 2.1). .4 Implementation Phase – System Model (Executable Specification -SystemC)
  • 14. These models are an executable specification of the system and are useful for architecture exploration and for algorithm determination and proof. They typically describe both hardware and software components. Here, we layout the requirements for a Design/Compile/Simulate/Debug Environment using a Virtual Prototyping Flow based on SystemC. Page below describes the Virtual Prototyping components and their execution order. 5 TEM Architecture – using SystemC Libraries Because SystemC uses a behavior Transaction Level Modeling (TLM), we construct a transaction level layer, a test harness [tests], common of all test benches for the design-under-verification (DUV). Simulation Test Functions required to implement the test cases identified in the Verification Plan, are built on top of the test harness. The Test Function and the Test Harness together form a test bench. We use as a template for simulation test bench, 18 real-world “examples” supplied by the OCSI SystemC 2.1 Library. TEM consists of 20 test functions and 18 test harnesses, making 18 test benches in total. Figure N: Page below displays 20 classes of tests; which are determined by slicing up a test session based on the test structure. Each test is farther divided into a number of CPU jobs, denoted in Status.
  • 15. 5.1) Hardware and Software Configuration We ran our solution on commodity Linux operating systems, such as Linux Red Hat and SUSE on x86 processors, and Unix, Solaris 10 on Sun Opteron w/AMD64. Solaris 10 required an AMD64 port of the SystemC 2.1 Libraries.[14] Since for SystemC is a C++ development environment, the standard C/C++ development environment is used. A SystemC reference simulator and Class Library (SystemC 2.1) were downloaded from the OSCI Website. The OCSI SystemC 2.1 Library and Test's Makefiles supplied within the original (oct_12_2004.beta), were first modified to support the modified “source code” for the AMD64 port of the SystemC 2.1 Libraries. They were then reorganized to support GNU Gcov based Code Coverage, and later all the SystemC 2.1 Makefiles were translated into TCL flows via both manual (hand translation) and automatic translation of Makefiles into TCL Flows (via vmake). The Tool Command Language (TCL) is a scripting and programming language. The flows were finally modified into a tools framework, consisting of many CGI modules written in TCL, that drive the various component tools of TEM: CVS-Revision Control, Gcov-Code Coverage, Bugzilla-Bug Tracking, mySQL-the SQL Database and the CPU Compute Farm. TEM Configuration Management Much of the work in setting up Frowtracer/TEM goes into writing a good configuration file. The configuration file
  • 16. describes how each TEM component tool controls their environment. The configuration file defines: Which TEM component subsystems are used (e.g CVS – Code Revision control, MySQL -Database, Bug Tracking system, and CPU Compute Farm for batch Processing). How the tests are defined and which Workflow Description file is used (../flows/SCSessionFlow.tcl). Flowtracer/TEM looks at a set of jobs and determines which test these jobs implement. Example of the page that shows the Configuration file for Flowtracer/TEM Our TEM experiment soon proved that building the SystemC2.1 Libraries (oct_12_2004.beta) and test benches,
  • 17. from scratch, was more effective then we previous thought possible. Using the GNU C/C++ compiler GCC 3.4.3, the SystemC 2.1 Libraries build to completion in under 10 minutes, with a P4 x86, and with the SUN Compute server farm in under 5 minutes. The Sun CPU Farm consisting of 2-4 SUN Opteron CPU's running Solaris10 . We used as a template for simulation test bench, 18 real-world “examples” supplied by the OCSI SystemC 2.1 Library. TEM consists of 20 test functions and 18 test harnesses, making 18 test benches in total. A few of the test functions and harnesses were manually modified, to accept parametric input (command-line arguments).The 18 test harnesses finally breakdown into a total of 105 verification tests cases. Each test case is submitted, as a series of single jobs, to the CPU farm for execution. This concludes our discussion of software modifications. Figure 7: The TEM our algorithm, compared with the other applications. 6 Conclusions: TEM Simulation Results We have taken great pains to describe out TEM was setup; now, the payoff, is to discuss our results. Seizing upon this ideal configuration, using SystemC for simulation with no synthesized RTL, we ran four novel experiments: (1) we measured Test Code Coverage, and Disk Usage (per Test Session), the number of assertions over-time and Verification Test Simulation throughput on our SUN CPU farm; (2) we ran on 3 CPU nodes spread throughout an intranet network, and compared them against running locally; (3) we ran 500+ test sessions with a stand-alone SUN CPU farm , at DAC 2005, and compared results against running locally; and (4)
  • 18. we asked (and answered) what would happen if standard web browsers were used instead of local Flowtracer project windows. In general, we were pleased and encouraged with the outcomes of the TEM experiments: which proved that using a higher-level approach to Verification and Simulation Test, simulation cycle-time throughput could be increased while simultaneously giving Distributed Design and Verification Teams an environment for sharing and achieving results. Future Work – with Test Environment Manager While TEM's integration of open-source tools and the SystemC2.1 Libraries has been successfully used in speeding up the Front-end Verification process, it is by no means limited to stitching just together the functionality of Front-end Verification tools. Given the high level of tools integration required throughout a complex SoC design flow, particularly in the 130-90nm and below range, TEM could be used by the Chip Design and Layout Teams to stitch together into one flow the following tools functionality: Physical Synthesis, Timing Analysis, Power and Floor planning, and Place and Route . Acknowledgments: I would like to thank the RTDA Development Team team for their support in the design and implementation of TEM tools components integration needed to manage the test sessions. Runtime Design Automation deserves much of the credit for the final completion of the idea of TEM. Also Gilles Descamps, PhD, ATI Technologies, should be acknowledged, as the originator of the idea (in 2002), of using local web-based Flowtracer/EDA scripts to run jobs and present results to Distributed Design Teams; which later became the basis for the TEM framework. Runtime Design Automation – CTO, Andrea Casotto, PhD. (Flowtracer/ TEM' s primary developer) RTDA Website - Santa Clara CA http://www.rtda.com I would also like to thank Frank A. Kingswood, http://www.kingswood-consulting.co.uk for his assistance in porting the SystemC2.1 Libraries, onto the AMD64 platform. Credits & Trademarks: Open SystemC Initiative (OSCI)- SystemC is a trademark or registered trademark of Open SystemC Initiative, Inc. in the United States and other countries and is used with permission. © 2004 Cadence Design Systems, Inc. All rights reserved. Cadence, the Cadence logo, Verilog & TestBuilder are registered trademarks of Cadence Design Systems, Inc.
  • 19. © 2004 Synopsys a registered trademark of Synopsys, Inc. in the United States and/or other jurisdictions. © 2005 Runtime Design Automation, Inc. Flowtracer/EDA & Flowtracer/TEM are trademarks of Runtime Design Automation, Inc. in the United States and other countries and is used with permission. © 2005 Advanced Micro Devices, Inc. All rights reserved. AMD, the AMD Arrow logo, AMD Opteron, and combinations thereof, are trademarks of Advanced Micro Devices, Inc.. Sun and Solaris10 are registered trademarks of Sun Microsystems Corporation in the United States and/or other jurisdictions. Intel and Pentium 4 are trademarks of Intel Corporation. © 2004 Forte Design Systems. All rights reserved. Forte trademarks and/or service marks may be registered in the United States and/or other jurisdictions. Oracle is a registered trademark of Oracle Corporation in the United States and/or other jurisdictions. Other product and company names used in this presentation are for identification purposes only and may be trademarks of their respective companies. References: [1] Victor Berman, Cadence Design Systems, Inc.,“A Tale of SystemC and SystemVerilog” Methods: System Languages :Chip Design June/July 2005, pp19-21 [2] Victor Berman, Cadence Design Systems, Inc. DVcon 2004 “Raising Level of Abstraction for Design & Verification: SystemC & SystemVerilog in a Multi language Env.” [3] Alian Raynaud, “The New Gate Count: What is Verification's Real Cost”, Electronic Design, ED Online ID #5954, 27 October 2003. [4] EE Times EDA Survey Results, fittedasurvey-fullreport.pdf, Deutsche Bank F.I.T.T, 23 June 2005 [5] Ilkka Tuuomi, “The Lives and Death of Moore's Law”, First Monday, http://www.firstmonday.org/issues/issue7_11/tuomi/#2, 23 July 2005 [6] Gartner DataQuest, www.gartner.com , June 2005. [7] Janick Bergeron, “Writing Testbenches. 2nd Edition, Functional Verification of HDL Models”, Kluwer,2004 (pp189) [8] Mark Creamer, “Nine reasons to adopt SystemC ESL design”, EE Times 16 Sept 2004. URL: http://www.eetimes.com/showArticle.jhtml?articleID=47212187 [9] Alian Clouard, Kshitiz Jain, Frank Ghenassia, Laurent Maillet-Contoz, Jean-Phillippe Strassen “Using Translational Level Models in SoC Design Flow”,Experimental Results – Simulation Figures,pg 57,ST Microelectronis, France- W. Muller, W. Rosenstiel and J. Ruf, SystemC: Methodologies and Applications,
  • 20. Kluwer,2003 [10] Colleen Frye,”Can IT developers work together?”, Application Development Trends Magazine,1 Nov. 2002. [11] Charles S. Hart, “Flowtracer/TEM – Integrated Workflow Tool for ASIC Design & Verification Teams, RTDA DAC2005_Flowtracer_TEM.ppt, MS PowerPoint 2000, June 2005. [12] Tom Katsioulas , “Design Resource Management for Complex Soc Design”, RTDA _PitchTomKat.ppt, MS PowerPoint 2000, Dec. 2003. [13] Ole Blaurock, “A SystemC-Based Modular Design and Verification Framework for C-model Reuse in a HW- SW Co-Design Flow,”icdcsw,vol. 07, no.7, pp.838-843, 24th 2004. Dept. of Computer Science, University of Hamburg, Hamburg, Germary [14] Frank A. Kingswood, “SystemC: Bug 409 - AMD64 patch for SystemC 2.1 (Solaris Opteron),(systemc_2_1.oct_12_2004.beta/Makefile systemc-amd64/Makefile). http://www.kingswood- consulting.co.uk/frank/sc-amd64.patch Charles S. Hart, “SystemC : Bug 447 Fix SystemC 2.1 - AMD64 (x86_64 port) on Solaris10 w/ gcc 3.4.3", https://www.systemc.org/tracker/index.php?aid=447, 10 Jun. 2005. [15] Open SystemC Initiative Website: www.systemc.org. SystemC Language Reference Manual. Included with SystemC 2.0.1 download from www.systemc.org. SystemC User Guide. Included with SystemC 2.0.1 download from www.systemc.org.SystemC 2.1 Library (oct_12_2004.beta) download from www.systemc.org. 2004. [[16] Forte Design Systems, SystemC Training Course, www.forteds.com/SystemC/training/index.asp. , 2004. [17] Cadence TestBuilder 1.3, www.testbuilder.net , Cadence Design Systems, Inc., Sept 2003.

×