chaoyuwa0516的博客

Agile Programming is a highly disciplined methodology used in software engineering. One aspect of the Agile methodology that is applicable to ASIC/FPGA functional verification and particularly important when creating verification environments using an Object Oriented paradigm is the Test Driven Development [2]. This process encourages the creation of a separate unit test for every critical class that is defined in a system. This paper describes the value of using a SystemVerilog unit test framework when creating a functional verification environment. Applying this Agile aspect may help achieve improvements in both quality and productivity. The usage model, the design of a unit test framework created for SystemVerilog (called svunit), and a concrete example of its usage are also presented.

This paper proposes a method called implicit encapsulation for creating layered stimulus models for use in constrained random verification environments. The proposed method relies heavily on the VMM class library – the atomic generator and scenario generator in particular – along with techniques typical of transaction level modeling. A set of generic components and a scalable structure is described that enables the creation of layered protocol stacks in a variety of arrangements. The intended audience includes those verifying medium to large RTL blocks that process layered protocols.

As chip design becomes larger and more complex, verification engineers are expanding constrained-random testing to meet the validation demand. The size and complexity of constraint problems are growing, resulting in performance and capacity issues. This paper discusses the key challenges verification engineers face when writing constraints – how to achieve test goals, how to optimize constraints for performance and how to manage the interaction and code complexity. We use two case studies from the network domain to illustrate these issues.

Today's verification solutions often require complex concurrent streams of stimulus controlled from higher level transactors or scenarios. The VMM 1.1 library has been enhanced to add this capability, and support the management of access to the resources shared by different stimulus streams, i.e. mu

This paper describes the use of the VMM Performance Analyzer to verify the performance of an AXI-based bus arbiter. The goal of performance verification is to verify that the architectural intent of the arbiter is fulfilled. The arbiter must provide specified bandwidth and latency to each bus master. To measure arbiter performance, we used a new VMM Application – the VMM Performance Analyzer. This application allows the collection of arbitrary user-defined performance data into an SQL database. We show how this application was integrated into our existing VMM testbench and how we post-processed the SQL data to quantify the arbiter’s performance.

This paper covers the lessons learned while integrating RAL in an automated register definition flow from Word document specification to Testbench infrastructure genera-tion and RTL implementation. It includes the initial thought process involved in archi-tecting the environment, the choice of a XML repository to close the gap between the RAL format and the Word doc format, the use of a layered approach with constrainable functional configuration defined separately at the transaction generation level and with the RAL classes coupled with a mapping layer at the driver level, and the definition of separate layers of functional coverage instrumentation beyond the native set.

SystemVerilog has gained rapid acceptance as a powerful ASIC and custom IC design and verification language. Are FPGA designers also using SystemVerilog? Which SystemVerilog features have they found useful? This paper answers these questions based on the experiences from several companies that have recently tried using SystemVerilog for designing and verifying FPGA designs. The paper summarizes what has worked well—and what has not work well—at each of these companies.

Part I. Understanding Projects 1. What Are Projects and Why Do They Fail? 5 What is a project? 5; What is project management? 6; Why is it vital to manage projects well? 8; Project killers 9 2. Dead Project Walking – Why some projects must be killed 13 Why dead projects live on 14 Part II. Where are We? 3. Diagnosing an Existing Project 19 Why doing a diagnostic makes sense 19; Getting to the truth 20; Digging into the plan 24; Diagnosing a multicompany programme 28 Part III. Getting the Right Initial Plan 4. Leading Projects 33 The wrong kind of project managers 33; Being the right kind of project manager 34; Give the team responsibility 35; Managing in a matrix 36; Being a team player 37; Overcoming ‘It can’t be done’ 38; Focusing your attention in the right places 41 5. Project Scope and Initiation 44 Introduction 44; Project initiation 45; The Project Charter 48; Creating the Project Charter 48; Get it right early on – it’s cheaper 50; Summary and actions 56 6. Agreeing Objectives 57 Why objectives are important 57; Developing welldefined objectives 59; Good and bad objectives – some examples 61; Summary and actions 65 7. Milestones 66 The problem with bad milestones 67; How to write a good milestone 68; Writing milestones 70; Differences between milestones and gates 70; Summary and actions 74 8. Refining Milestones 76 Do you have the right milestones? 76; How result paths help 76; Setting up result paths 77; Assessing result paths 79; Developing the detail for each milestone 82; Beyond milestones 82; Summary and actions 83 9. Activities/Work Breakdown Structure 85 What is a work breakdown structure? 86; The work breakdown structure underpins much of the planning 89; The rolling wave approach 90; The impact of rolling wave on estimation and contingency 91; Summary and actions 93 10. Assigning Resources 96 Identifying the resources you need 96; Summary and actions 98 11. Time Estimation 100 Why estimation goes wrong 100; Why managing using ‘percentage complete’ doesn’t work 102; A better approach for estimation – work content 106; Producing good estimates 108; Record any assumptions used in estimation 111; Summary and actions 112 12. Resource Availability 114 Estimating task durations from the work content 114; Summary and actions 122 13. Dependencies 124 Different types of dependencies 125; Lag 126; Predecessors and successors 128; Tasks and subtasks 129; Critical path 131; Slack/float 133; Summary and actions 134 14. Risk and Mitigation 136 The problems with simple risk/contingency planning 137; Identifying and managing risks 137; Risk identification 138; Risk assessment 139; Risk reduction 143; Risk management 145; Summary and actions 146 Part IV. Getting the Plan Right 15. Optimizing the Plan 151 Create more realistic resource usage 152; Improve resource usage to shorten the duration of key tasks 153; Reducing task durations on the critical path 157; Working in parallel 157; Optimization and risk 158; Project crashing 160; Developing the project budget 163; Where you end up is where you start 163 Part V. Staying on Track 16. Roles, Responsibilities and Communication 167 Project manager 167; Work package or module managers 169; Project team members 169; Project sponsor 170; Project office 171; Steering group 171; Communication between the roles 172; Project manager’s weekly checklist 175 17. Updating the Plan 178 The update information you need from team members 178; Integrating the updates 179; Updating the plan in practice 181; How often? 182 18. Monitoring Progress 183 Introduction 183; How to monitor progress within a project 184; Earned Value Analysis (EVA) 186; Using EVA to monitor progress 190; Limitations of EVA 193 19. Handling Issues 194 Introduction 194; What is an issue? 195; Prioritizing issues 195; Managing issues 195 20. Controlling Change 197 21. Reporting 201 Reporting down 201; Reporting up 202 22. Project Closure 203 Appendix 1: The Changing Nature of Projects 205 Appendix 2: Project Management Software 211 Appendix 3: Project Management Approaches and Methodologies 219 Appendix 4: Problem-solving Techniques 229 Appendix 5: References and Resources 233 Index 235

Chapter 1: Power Tools for Editing Chapter 2: Understanding Basic Operations Chapter 3: Understanding Regular Expression Syntax Chapter 4: Writing sed Scripts Chapter 5: Basic sed Commands Chapter 6: Advanced sed Commands Chapter 7: Writing Scripts for awk Chapter 8: Conditionals, Loops, and Arrays Chapter 9: Functions Chapter 10: The Bottom Drawer Chapter 11: A Flock of awks Chapter 12: Full-Featured Applications Chapter 13: A Miscellany of Scripts Appendix A: Quick Reference for sed Appendix B: Quick Reference for awk Appendix C: Supplement for Chapter 12

If Chained Implications in Properties Weren't So Hard, They'd Be Easy_pres.pdf

There are some simple tricks that every design engineer should know to facilitate the usage of SystemVerilog Assertions. Although this paper is not intended to be a comprehensive tutorial on SystemVerilog Assertions, it is worthwhile to give a simplified definition of a property and the concurrent assertion of a property. 1.1 What is an assertion? An assertion is basically a "statement of fact" or "claim of truth" made about a design by a design or verification engineer. An engineer will assert or "claim" that certain conditions are always true or never true about a design. If that claim can ever be proven false, then the assertion fails (the "claim" was false). Assertions essentially become active design comments, and one important methodology treats them exactly like active design comments. More on this in Section 2. A trusted colleague and formal analysis expert[1] reports that for formal analysis, describing what should never happen using "not sequence" assertions is even more important than using assertions to describe always true conditions. 1.2 What is a property? A property is basically a rule that will be asserted (enabled) to passively test a design. The property can be a simple Boolean test regarding conditions that should always hold true about the design, or it can be a sampled sequence of signals that should follow a legal and prescribed protocol. For formal analysis, a property describes the environment of the block under verification, i.e. what is legal behavior of the inputs. 1.3 Two types of SystemVerilog assertions SystemVerilog has two types of assertions: (1) Immediate assertions (2) Concurrent assertions Immediate assertions execute once and are placed inline with the code. Immediate assertions are not exceptionally useful except in a few places, which are detailed in Section 3.

Topics covered This book focusses on the portion of SystemVerilog that is intended for representing hardware designs in a manner that is both simulatable and synthesizable. Chapter 1 presents a brief overview of SystemVerilog and the key enhancements that it adds to the Verilog language. Chapter 2 discusses the enhancements SystemVerilog provides on where design data can be declared. Packages, $unit, shared variables and other important topics regarding declarations are covered. Chapter 3 goes into detail on the many new data types SystemVerilog adds to Verilog. The chapter covers the intended and proper usage of these new data types. Chapter 4 presents user-defined data types, a powerful enhancement to Verilog. The topics include how to create new data type definitions using typedef and defining enumerated type variables. Chapter 5 looks at using structures and unions in hardware models. The chapter also presents a number of enhancements to arrays, together with suggestions as to how they can be used as abstract, yet synthesizable, hardware modeling constructs. Chapter 6 presents the specialized procedural blocks, coding blocks and enhanced task and function definitions in SystemVerilog, and how these enhancements will help create models that are correct by design. Chapter 7 shows how to use the enhancements to Verilog operators and procedural statements to code accurate and deterministic hardware models, using fewer lines of code compared to standard Verilog. Chapter 8 provides guidelines on how to use enumerated types and specialized procedural blocks for modeling Finite State Machine (FSM) designs. This chapter also presents a number of guidelines on modeling hardware using 2-state logic. Chapter 9 examines the enhancements to design hierarchy that SystemVerilog provides. Significant constructs are presented, including nested module declarations and simplified module instance declarations. Chapter 10 discusses the powerful interface construct that SystemVerilog adds to Verilog. Interfaces greatly simplify the representation of complex busses and enable the creation of more intelligent, easier to use IP (intellectual property) models.

STANDARD FOR PROPERTY SPECIFICATION VOLTAGE (PSL) 1. Overview 1.1 Scope This standard defines the property specification language (PSL), which formally describes electronic system behavior. This standard specifies the syntax and semantics for PSL and also clarifies how PSL interfaces with various standard electronic system design languages. 1.2 Purpose The purpose of this standard is to provide a well-defined language for formal specification of electronic system behavior, one that is compatible with multiple electronic system design languages, including IEEE Std 1076™ (VHDL), IEEE Std 1364™ (Verilog®), IEEE P1800™1 (SystemVerilog®), and IEEE P1666™ (SystemC), to facilitate a common specification and verification flow for multi-language and mixedlanguage designs. 1.2.1 Background The complexity of Very Large Scale Integration (VLSI) has grown to such a degree that traditional approaches have begun to reach their limitations, and verification costs have reached 60%–70% of development resources. The need for advanced verification methodology, with improved observability of design behavior and improved controllability of the verification process, has become critical. Over the last decade, a methodology based on the notion of “properties” has been identified as a powerful verification paradigm that can assure enhanced productivity, higher design quality and, ultimately, faster time to market and higher value to engineers and end-users of electronics products. Properties, as used in this context, are concise, declarative, expressive and unambiguous specifications of desired system behavior, that are used to guide the verification process. IEEE Std 1850 PSL is a standard language for specifying electronic system behavior using properties. PSL facilitates property-based verification using both simulation and formal verification, thereby enabling a productivity boost in functional verification.

O'Reilly - JavaScript Pocket Reference 2nd Edition.chm

Rampant.TechPress.Oracle.SQL.Internals.Handbook.pdf

Scalable.Internet.Architectures

Teach Yourself Programming with PERL in 24 Hours, FOURTH EDITION

Regular.Expression.Pocket.Reference.2nd.Edition

Programming.Embedded.Systems.With.C.and.Gnu.Development.Tools.

.Cisco.IOS.Cookbook.2nd.Edition

The New Reality Of Wall Street

Graphical design notations have been with us for a while. For me, their primary value is in communication and understanding. A good diagram can often help communicate ideas about a design, particularly when you want to avoid a lot of details. Diagrams can also help you understand either a software system or a business process. As part of a team trying to figure out something, diagrams both help understanding and communicate that understanding throughout a team. Although they aren't, at least yet, a replacement for textual programming languages, they are a helpful assistant. Many people believe that in the future, graphical techniques will play a dominant role in software development. I'm more skeptical of that, but it's certainly useful to have an appreciation of what these notations can and can't do. Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community. The UML has become not only the dominant graphical notation within the OO world but also a popular technique in non-OO circles.

Writing Excel Macros with VBA

OReilly.Perl.Cookbook

The second edition of Teach Yourself TCP/IP in 14 Days expands on the very popular first edition, bringing the information up-to-date and adding new topics to complete the coverage of TCP/IP. The book has been reorganized to make reading and learning easier, as well as to provide a more logical approach to the subject. New material in this edition deals with installing, configuring, and testing a TCP/IP network of servers and clients. You will see how to easily set up UNIX, Linux, and Windows NT servers for all popular TCP/IP services, including Telnet, FTP, DNS, NIS, and NFS. On the client side, you will see how to set up DOS, Windows, Windows 95, and WinSock to interact with a server. Examples and tips throughout these sections make the process easy and clear. Also added in this edition of Teach Yourself TCP/IP in 14 Days are new sections on DNS, NFS, and NIS. These network services have become popular with the growth of large TCP/IP networks, so we show you how to configure and use them all. A new section on the latest version of IP updates the treatment of the base protocols to 1996 standards.

Unix Shell Programming is a tutorial aimed at helping Unix and Linux users get optimal performance out of their operating out of their operating system. It shows them how to take control of their systems and work efficiently by harnessing the power of the shell to solve common problems. The reader learns everything he or she needs to know to customize the way a Unix system responds. The vast majority of Unix users utilize the Korn shell or some variant of the Bourne shell, such as bash. Three are covered in the third edition of Unix Shell Programming. It begins with a generalized tutorial of Unix and tools and then moves into detailed coverage of shell programming. Topics covered include: regular expressions, the kernel and the utilities, command files, parameters, manipulating text filters, understanding and debugging shell scripts, creating and utilizing variables, tools, processes, and customizing the shell.

This book uses different typefaces to help you differentiate between Perl code and regular English, and also to help you identify important concepts. l Actual Perl code is typeset in a special monospace font. You'll see this font used in listings and the Input-Output examples, as well as in code snippets. In the explanations of Perl features, commands, filenames, statements, variables, and any text you see on the screen also are typeset in this font. l Command input and anything that you are supposed to enter appears in a bold monospace font. You'll see this mainly in the Input-Output examples. l Placeholders in syntax descriptions appear in an italic monospace font. Replace the placeholder with the actual filename, parameter, or whatever element it represents. l Italics highlight technical terms when they first appear in the text and are sometimes used to emphasize important points.

Perl Debugged provides the expertise and solutions developers require for coding better, faster, and more reliably in Perl. Focusing on debugging, the most vexing aspect of programming in Perl, this example-rich reference and how-to guide minimizes development, troubleshooting, and maintenance time resulting in the creation of elegant and error-free Perl code.