This material contains trade secrets or otherwise confidential information owned by Siemens Industry Software Inc. or its affiliates (collectively, "SISW"), or its licensors. Access to and use of this information is strictly limited as set forth in Customer's applicable agreement with SISW. This material may not be copied, distributed, or otherwise disclosed outside of Customer's facilities without the express written permission of SISW, and may not be used in any way not expressly authorized by SISW.

This document is for information and instruction purposes. SISW reserves the right to make changes in specifications and other information contained in this publication without prior notice, and the reader should, in all cases, consult SISW to determine whether any changes have been made. SISW disclaims all warranties with respect to this document including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement of intellectual property.

The terms and conditions governing the sale and licensing of SISW products are set forth in written agreements between SISW and its customers. SISWs

End User License Agreement

may be viewed at:

www.plm.automation.siemens.com/global/en/legal/online-terms/index.html

.

No representation or other affirmation of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of SISW whatsoever.

TRADEMARKS:

The trademarks, logos, and service marks ("Marks") used herein are the property of Siemens or other parties. No one is permitted to use these Marks without the prior written consent of Siemens or the owner of the Marks, as applicable. The use herein of third party Marks is not an attempt to indicate Siemens as a source of a product, but is intended to indicate a product from, or associated with, a particular third party. A list of Siemens' trademarks may be viewed at:

www.plm.automation.siemens.com/global/en/legal/trademarks.html

.
The registered trademark Linux

is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis.

Table of Contents

Project Overview

IC Design Overview

Introduction

Circuit Overview

Task Overview

Library and Design File Locations

Processing Cores Flow Review

Processing the gps_baseband Core

Processing the processor_core

Processing the Chip Top Level

Notes

Presentations

NOTES:

Project Overview 2

Introduction 2

Circuit Overview 2

Task Overview 3

Library and Design File Locations 4

DELETE THIS AND FOLLOWINGLab: General Lab Format (Heading 2) 5

Objectives (Heading 3) 5

Introduction (Heading 3) 5

Directions (Heading 3) 5

Exercise 2: Tables, Graphics, and Boxes (Heading 3 Exercises) 7

Exercise 3: Icon Text Boxes (Heading 3 Exercises) 9

Lab: Introduction to Calibre (Example With Lab Conventions) 10

Introduction 10

Lab Conventions 10

Exercise 1: Invoke DESIGNREV (Heading 3 Exercises) 11

Icon Text Boxes (Note/Info/Hint/Caution) 13

NOTES: 14

Project Overview

IC Design Overview Introduction

Before we foray into the world of designing for test, lets go back to the very beginning and touch upon a few points.

Lets first look at a

very simplistic high-level

product development process.

First, when beginning a brand new design, there is a set of functionality that the design is incepted to perform. This is expressed in some kind of functional specification. This specification grows from a nebulous this is what I want it to do, possibly inclusive of some initial I/O signals, to these are the required sub-functions that need to be incorporated to build the overall functionality.

Great, there is now a high level high-level description of the required inputs/outputs and overall functionality. We will not discuss details such as schedules, etc.

The sub-functional blocks are designed at the register transfer level (RTL) and simulated. The design environment can be very dynamic, especially when operating on the leading edges of technology. Once the RTL has been completed, and the functionality, and other items, have been verified through simulation, the RTL then can go different ways, depending on a companys organization, process and procedures, and workflows.

The specific process or procedure, procedure, or workflow a company uses is not important to the next evolutionary stage of the design. The insertion of test IP to ensure the silicon is rigorously tested before packaging, after packaging, in-circuit testing, etc. Additionally, with the continued advancement of the technology nodes, in both size and structure, advancements in packaging, and security and safety requirements, we are presented with an ever changing ever-changing landscape of constraints.

In the short time you are with us, we will only be focused on the insertion of IP predominently predominantly from the manufacturing and test perspective.

Whats on the DFT horizon and beyond will be a bold adventure for those who choose to ask the question, What if we did it this way?. The frontier of DFT continues to be pushed as advances in technology and creativity on the design side grows grow.

After all, who could have imagined and believed, 25 years ago that prosthetic limbs controlled by the muscles and thoughts would exist and be affordable?

Introduction

For this project, your task is to fulfill the role of a DFT engineer. The scope of the role is to insert the required test hardware and generate patterns using the Tessent Hierarchical DFT/ATPG methodology.

Your design team has completed the functional aspects of the design; synthesis, verified it functions per the design specification (simulation), and that all timing has been closed using a static timing analysis tool. These are the two requirements that must be met before inserting any test logic.

Your goal is to create the a do file that can be run when Tessent is invoked, or run internal to Tessent Shell, or a run file that can be executed at the OS prompt when the active terminal window is focused on one of the design directories.

The only guidance that is provided is a collection of enumerated directories that align with the processes discussed during lecture and when reviewing ODT material. , comments in the different run/do starter files provideproviding some direction as to what you need to add to the file, and asking questions of your mentors. Steps are also enumerated in the run/dofiles. These are also well documented. To aid, the descriptions of what needs to be added are often expressed using keywords that you can use to search the documentation.

It is your responsibility to utilize all the resources available to you to complete the processing of the two physical hierarchical blocks, gps_baseb and and process or_core, and the top level chip . These include, but are not limited to, the lessons learned in class, the documentation, the Siemens SW Support Center Portal, conversions with your mentor during Office hours, Tessent introspection commands to gather information about the contents of the design, and the Xcellerator academy. If you get stuck on something, you can also send email to thea mentor so you can make progress instead of waiting for office hours.

You are also encouraged to watch as the different files are written to the TSDBs as this will help you understand which commands write to which areas of a TSDB. This will expand your understanding of how strings added to the commands influence the naming of items in the TSDB. For example, the design_id switch value usepair used during the execution of the set_context or read_design commands.

As you run the tools, you are encouraged to review the results in the logfile generated for the runs that completescomplete successfully to gainet an understandingappreciation of everything the tool is doing.

Working through this project successfully and earning the Tessent Scan and ATPG tool badges are the requirements for completion of this Internship. We expect that you can complete Scan & ATPG, MBIST, TestKompress, and possibly IJTAG.

Circuit Overview

This design is hierarchical and is comprised ofcomprises three physical blocks. There are two wrapped cores in the design. One of the cores is instantiated twice in the top leveltop-level chip.

One of the cores only contains logic while the other core contains both logic and memories.

The chip-level instanstiatesinstantiates one instance of the core named processor_core and two instances of the core named gps_baseband.

There is logic at the chip-level as well that needs to be tested.

Task Overview

The core named

gps_baseband

is a logic onlylogic-only wrapped core in which you need to add EDT and standard OCC. The following block diagram summarizes this statement graphically.

The core named

processor_core

is a logic only wrapped core in which you need to add EDT and standard OCC, and since the block has memories, MemoryBIST needs to be implemented. The following block diagram summarizes this statement graphically. (it has memories too and so MBIST is required)

In keeping with the concepts of Hierarchical scan and ATPG, the cores can be processed in any order you choose, but must be processed

before

processing the chip-level design.

After the two cores have been processed - insertion of test IP, patterns generated and verified to be free of timing issues - the design top, the chip level of the design, is to be processed.

Processing the chip-level design includes the insertion of standard OCC, EDT, boundary scan, and a test access mechanism (acronym TAM). You Sshould have finished running need to process all the wrapped cores first before running top-level.

As part of the TAM insertion, you will create modal signals that are used during the retargeting process of the core level patterns to the chip level.

The following image summarizes the chip-level view of the IP that needs to be inserted as well as the physical blocks and the DFT circuitry that was inserted.

Library and Design File Locations

The project files are contained in a compressed tarfile named

intern_data.tgz

in the HOME directory.

The files need to be extracted using the Linux OS command:

tar xzvf intern_data.tgz, in a terminal window.

The terminal window is accessed by selecting:

Applications > Favorites > Termina

l.

This will create the main directory in which you will be working:

$HOME/intern_data/HierarchicalFlow

.

These directories have many subdirectories and files. You will be editing the files with the suffix: _starter. The starter files contain the directions, hints, and sometimes the commands that will accomplish the task at hand. You will need to complete the files following the directions and using the documentation and help.

The directory tree looks like:

Processing Cores Flow Review

Without MemoryBIST

With MemoryBIST

The following was extracted from the Tessent MemoryBIST course

Processing the gps_baseband Core

The actuall instructions for the necessary commands are included in the starter files. The instructions are presented in terms of the actions we want the tools to carry out. We suggest that you make a copy of the starter file and edit the copy, so you will have the original one in case you want or need to start over or have some other reference need.

Using the directory map above, navigate to the gps_baseband core project directory beneath wrapped_cores.

You will find directories prefixed with a number. These represent the framework for processing the gps_baseband steps.

Each of these numbered directories havehas one, or more starter scripts into which you will need to add the required commands toand run successfully before moving on to the next step of the process. We have chosen this format for the project as you have two or 3 days to create, debug, and run the scripts.

In the first step you will use the tools to insert the embedded deterministic (EDT) and on-chip clock controller (OCC) into the design.

You will be using the Tessent Quick Synthesis tool. The Tessent Quick Synthesis tool automatically synthesizes (RTL to gate) the test IP when the check_design_rules or the extract ICL commands are executed. In a production environment, an industry standard synthesis tool will be used. Also, you will not be using any layout extraction tools during the project. So in the above two flow chart diagrams, you will take the path coming out below the Synthesis option step. I.e. no separate TSDB View Creation step is used.

In the third step, you will insert the standard scan, including insert the scan chains, etc.

The fourth step contains multiple sub-steps. First, you will generate the graybox view for the core. This is a necessary step to prepare the core for retargeting. The remaining sub-steps are used to create patterns for the internal and external modes for the stuck-at and transition fault types. Recall that the stuck-at only requires one clock to capture a fault, while the transition delay requires two, a launch and a capture.

The last sub-step is to run the Tessent- generated testbenches simulations. This uses a simulation environment to ensure that there are no mismatches between the expected results created using the event model during ATPG and a simulation that contains timing parameters for the design.

The final step in the process occurs in a design flow after the design has been placed and routed, and interconnect and loading delays are extracted and annotated to the netlist or a support file.

As you process the design, review the contents of the tsdb_outdir directory to get an understanding of how the TSDB automatically manages the directories and files.

Processing the processor_core

The processor_core core project follows the same format as the gps_baseband core project. There will be starter files for each step and sub-step of the test IP generation, insertion, and pattern generations. The starter files will require you to add all the commands, and the directions are stated from a higher-levelhigher level perspective. For example, you may see something like, Add all the commands necessary to set the proper context and load the design and library files. You will need to use what you learned when you processed the gps_baseband.

Also, this core has embedded memories that are to be tested using the Tessent MemoryBIST technology. Since it has embedded memories that are tested using the Tessent MemoryBIST technology, there are two pattern generationIP insertion and verification steps. One for the MemoryBIST as it is controlled by IJTAG and uses the Pattern Specification to create the patterns, including the testbenches. The other, as in the gps_baseband, is for the scan inserted designlogic-test portion of the design. Note that the scan patterns are generated and verified in step 5, 5.generate_atpg_patterns.

The first step requires the memory BIST IP to be specified and inserted, followed by a second pass to specify the EDT and OCC IP. Once the IP has been inserted in terms of RTL, the RTL willould be synthesized. As previously stated, you will use the Tessent built-in synthesis tool for the intermediate synthesis steps. In an actual design environment, you will be using the corporate approved synthesis tool, such as Design Compiler (DC).

Once the IP has been synthesized, the next step is to insert the scan logic. As with the gps_baseband, you will add the commands necessary for the tool to create and insert the scan chains. Additionally, since the processor_core has memories and uses memory BIST, it is necessary to tell the tool about them and how to process them. Remember that the MBIST logic is scan testable.

Once you have completed these tasks, you will have a scan insertedscan-inserted design that can now be used by the ATPG tool to generate the test patterns.

As you saw when processing the gps_baseband core, the ATPG process first requires the generation of a graybox view of the design.

This is then followed by the generation of stuck-at (1 and 0) and transition delay patterns for both the internal and external modes. In addition to the binary patDB pattern format that is used to retarget the core patterns to the chip level for manufacturing test, you will generate the parallel and serial test benches to confirm there are no mismatches between the event drivenevent-driven ATPG process and Verilog simulations that include circuit timing.

Once these scan pattern sets are created and checked for mismatches, the patterns for the memoryBIST are created using the PatternSpecification to create the patterns, then validate through simulation using the testbench that is created automatically as part of the process.

The final step in the process occurs in a design flow after the design has been placed and routed, and interconnect and loading delays are extracted and annotated to the netlist or a support file.

As you can see, the basic processing steps for each core isare the same. Additional steps will be required when a core has additional IP, as this one has an embedded memory. This holds true for other IP that uses basic IJTAG control, or more detailed IJTAG control, such as the Tessent Streaming Scan Network (SSN), 2.5/3 D die stacking, in- system testing, etc.

Additional information

The following is a list of the DFT control signals that you are to use.

Logic Test:

ltest_en

scan_en, edt_update, test_clock

These are created from source nodes: scan_enable edt_update test_clock_u

edt_clock, shift_capture_clock

These are created from other signals

Testing memories with multi-load ATPG patterns:

memory_bypass_en

Scan Tested network that is to be tested during logic test:

tck_occ_en

Hierarchical DFT:

int_ltest_en, ext_ltest_en, int_mode, ext_mode

Processing the Chip Top Level

Review

In your role as the DFT/ATPG engineer, you will complete the design by adding the necessary test logic, such as the on-chip clock controller and EDT circuitry, defining the modes and the associated control signals required to test the hierarchical blocks from the chip IO boundary, and other things such as boundary scan.

The top leveltop-level design has been named chip_top for this project. The name will typically be more descriptive in an actual design environment.

At this juncture, all the functional elements and interconnect required for the design are available and integrated using the chip_top netlist as the framework. For example, when you review the netlist, you will find one instance of the processor_core and two instances of the gps_baseband.

Recall that a physical block is a completed core that includes the place and route, and pattern sets necessary to test the individual cores.

You will be adding statementscommands that will add the necessary test IP and define the control signals to control the tests. At the tester, you only have access to the I/O pads of the die. The RTLrtl test IP and control signals that Tessent synthesizes allows the patterns that were generated for the physical cores to be be tested at the chip IO boundary. This is called pattern retargeting.

During the retargeting process, the tool uses ICL and PDL to describe the hierarchical interconnect and control signals necessary at each hierarchical boundary. This is all used to formulate the Tessent Core Description, the TCD file.

As with the gps_baseband and processor_core scripts, these are also numbered and, as you progress to the final steps of the process, have been partially to completely completed as the commands you are using are essentially the same, the only change is focus.

You will start with inserting boundary scan followed by the EDT and OCC ciruitry, followed by the EDT and OCC circuitry. As there arent any RAM or ROM modules at the top level, there will be no MemoryBIST insertion. You will then use the Tessent Quick Synthesis engine to synthesize the gate representation of the design. Once that has been done, you will insert the scan logic, then proceed to generating the ATPG patterns and the retargeted ATPG patterns.

As a reminder, the Quick Synthesis is a Tessent tool used for debug type purposes. Always use an industry standard tool to synthesize the gate level design files used to fabricate the silicon.

Given the fact that you have generated and simulated many patterns, the post-layout ATPG pattern generation scripts are complete. You are encouraged to delve into them and understand how the modes are specified for the different test modes, such as setting the proper modes and static dft signals. The simulation tool included in your VlabVLab is Questa Sim.

As the top level post-layout scripts will create patterns that test not only the top level logic, but also the individual cores, you may find that the scripts dont complete successfully. If this happens, read the messages very carefully, the issue might not be related to any of the processing at the top level and may actually be an issue with one, or both, of the cores.

Notes

1. As you progress through the processing of the physical cores and the top level device, you will find commands that are common to each step. We suggest that you leverage these.

2. Read all the comments in the run/dofiles as there are hints and additional guidance.

3. Whenever you see the hash symbol, #, followed by two blank lines in the run/dofiles, you are expected to insert commands that perform the functionality described in the comment.

4. The angle brackets, < > (less than/greater than), in the run/dofiles imply that you need to replace them with a command, switch, or string.

5. Remember to complete the DFT, BIST, and ATPG processing, you must complete and/or execute the run/do files in the numbered sub-directories for each of the wrapped cores and the the top-leveltop level chip directory.

DELETE THIS AND FOLLOWINGLab: General Lab Format (Heading 2)

Objectives (Heading 3)

In this section describe the objective of the lab and what the student will be doing. (

Normal

)

At the end of this lab you should be able to do the following: (

Normal

)

• List the standard formats and styles used in a lab workbook (

  Bulleted

  )

• View the styles and format for headings, body, tables, and graphics while reading this template and while modifying the lab workbook you are updating (

  Bulleted

  )

Introduction (Heading 3)

Include general introductory information here. For example, you can provide specific information needed to complete the lab, describe a specific scenario, or provide a graphic that will be useful for the student. If the student needs to know specific file names and directories, list them in this section. (

Normal

)

• Numbered or lettered steps indicate that the student will perform some action. Paragraphs without numbers only provide supplemental information or ask questions to think about. (

  Bulleted

  )

• Numbered steps are a base action. If there are lettered steps below a number, these lettered steps provide all the details of how to perform the numbered step. (

  Bulleted

  )

Directions (Heading 3)

• Reduce your document to the standard formats contained in this template, which you can view as you work (Format > Styles and FormattingShow: Formatting in use). Do not add new formatting. (

  Bulleted

  )

• For general paragraph text use the

  Normal

  paragraph format. This paragraph format has the appropriate font, font size, and spacing that is consistent with the student workbooks used for customer training.

• The items in bold in the General Lab Format section of the template indicate format types.

1. Provide the specific instructions here. (

   1. List Number

   )

First-level list numbered body text (

L1 Body Numbered

)

2. Instructions can be a list of steps as in this example.

3. Second-level numbered list (

   a. List Letter

   )

Second-level list numbered body text (

L2 Body Numbered

)

1. Second-level item in list

2. Third-level numbered list (

   i. List Roman

   )

Third-level numbered body text (

L3 Body Numbered

)

1. Third-level item in list

2. Second-level item

3. Instructions can be in paragraph form.

4. Or instructions can be in the format of a non-ordered list with bullets.

• First-level bulleted list (

  Bulleted

  )

First-level bulleted body text (

Bullet L1 Body

)

• First-level item in list

o

Second-level bullet list (

Bulletedhollow

)

Second-level bulleted body text (

Bullet L2 Body

)

o

Second-level item in list

• First-level item in list

  
  
  

Code Listing looks like this:

(Code)

Line 1

Line 2

Line 3

Use the Code font plus Bold for commands or code that the student actually types. (Code + Bold)

Exercise 1: Title Format (Heading 3 Exercises)

This new heading format eliminates the need for a List of Exercises section in each of the labs. It mimics the format of the Student Workbook.

1. Choose the

   Heading 3 Exercises

   style so that Exercise titles may be included in the table of contents (new as of August, 2006).

2. You can copy your entire workbook into this template to obtain the all of the

   standard formatting selections

   and the new Table of Contents.

3. Or cut-and-paste this Table of Contentsand an example of

   Heading 3 Exercises

   formatinto your workbook.

Exercise 2: Tables, Graphics, and Boxes (Heading 3 Exercises)

Table Formats (Heading 4)

Following is an example of a table with a standard grid structure. The table headings are

Table Text + Bold

, and the cell contents are

Table Text

.

Following are two less structured examples that take less space, and are easy to read:

2. Set up the display to see some User Draft layers containing previously-defined template graphics. (

   List Number

   )

General tab (

L1 Body Numbered

)

Board Template-1 Enabled (

L2 Body Numbered

)

Board Template-2 Enabled

Board Template-3 Enabled

Board Outline Disabled

Route Border Disabled

5. Using the same Polar Array Placement command, place some Wire Bond connectors: (

   List Number

   )

Origin Location X 0 (

L1 Body Numbered

)

Origin Location Y 0

Side Top

Radius 2225

Start angle 155

Sector angle 2.5

Additional Rotation 180

Place parts on Radius Cell origin

In the List of Ref Des field P*

Box Outlines (Heading 4)

Outlining text instead of using a screen capture graphic is not recommended; but if you must enclose text in a box, use the following style:

Example Transcript in the format

File Contents Box

:

# Loading work.picdram1_multi_bist_picdram3_block

# Loading work.picdram3

# run -all ; exit

# 100 Testing system inputs.

# 2450 Testing bist logic.

# 182350 Simulation finished.

# ** Note: $finish : ../../mbist/picdram1_multi_tb.v(263)

# Time: 182350 ns Iteration: 0 Instance: /picdram1_multi_tb

Graphics (Heading 4)

Insert graphics into paragraphs or lists with the

Normal

format. Generally, you should center the graphic, and use the

Caption + Centered

paragraph format for any captions as shown on the next page:

Completed Board Outline

Exercise 3: Icon Text Boxes (Heading 3 Exercises)

See the last section in this lab template to copy and paste where you need Note, Information, Caution, and Hint boxes. It is included at the end, so you can find it quickly when you need to copy and paste.

Following is an example lab excerpt which contains standard formatting and styles.

Lab: Introduction to Calibre (Example With Lab Conventions)

Introduction

In this lab, you will learn how to invoke DESIGNrev and launch the various Calibre Interactive tools from DESIGNrev. You will run pre-set LVS and DRC learning how to view a discrepancy using Calibre RVE. You will also explore how to obtain help for the various Calibre tools. Finally, you will be encouraged to experiment with polygon creation in DESIGNrev to enable you to edit layout designs in future labs.

Several concepts and procedures have not, yet, been thoroughly explained in the lecture, but you will be given enough information to perform the necessary tasks. You will obtain a deeper understanding of these concepts in later lectures and labs.

In this first lab, all procedural steps contain full step-by-step instructions and information. As you gain practice in performing common procedures, the labs will provide less instruction on those procedures. The labs will inform you when they will no longer give detailed step-by-step instructions for a procedure and they will reference the most recent lab step that provided those instructions.

Lab Conventions

In order to make labs as simple and clear as possible, the instructions use the following conventions:

• You usually just click mouse buttons unless specifically told to do otherwise.

o

LMB: left mouse button (default)

o

RMB: right mouse button

o

MMB: middle mouse button

• Numbered or lettered steps have you perform some action. Paragraphs without numbers only provide supplemental information or ask questions for you to think about.

• Numbered steps are a base action. If there are lettered steps below a number, these lettered steps provide all the details of how to perform the numbered step. Therefore, if you already know how to do the numbered step, you may safely skip the lettered steps, unless you are specifically told otherwise. (It would be a good idea to at least skim the lettered steps, even if you already know how to perform the base operation.)

For example:

If you already know how to go outside, you can just go outside. If you do not know or remember how to get outside, you could follow the lettered steps to get there. Notice that even though you know how to get outside you might not have gone out through the front doors, so it would still be a good idea to skim the lettered steps to make sure you end up at the expected place.

• In the early exercises all steps are provided. Once you have done a task, you will simply be told to do it, with maybe a little reminder of how it was done.

• You should leave the tools up and running as you move from exercise to exercise. The exercises usually build on each other. On the other hand, you can close the tools after a lab (full block of exercises). If you are specifically told to close a tool or application between exercises you should do so.

• If you ever have any problems or questions about a lab, feel free to ask your instructor for help.

Exercise 1: Invoke DESIGNREV (Heading 3 Exercises)

In this exercise you will invoke DESIGNrev from the command line, load the palette, and load a GDSII design.

1. From a UNIX shell, change your directory to

   lab1

   .

   
   
   

cd $HOME/using_calbr/lab1

6. Launch DESIGNrev.

   
   
   

$MGC_HOME/bin/calibredrv

This will open the initial DESIGNrev window.

Now you will load the GSDII file.

7. Choose Menu:

   File > Open Layout

   .

8. Select

   lab1.gds

   , by double-clicking.

This loads the layout design you will be using for the first parts of this lab.

Next, you load the layer properties file. This file gives the various layers names (rather than just numbers) and gives the layers their expected colors.

9. Load the layer properties. (Menu:

   Layer > Load Layer Properties

   )

This opens the Load Layer Properties dialog box.

10. Select the

    layer_props.txt

    file.

11. Choose

    OPEN

    in the dialog box to load the layer properties.

The DESIGNrev window should look similar to the following:

In a later exercise, you will review how to work in the DESIGNrev environment; for now, you are ready to launch Calibre Interactive.

Icon Text Boxes (Note/Info/Hint/Caution)

The following icon text boxes are for you to use in developing your document. The text format is

Note Text

. Copy and paste the box where you need it; then modify the text.

The length of a note should not exceed ten lines. If you need more than ten lines, create a section instead. Refer to the tech pubs

Stylebook for Documentation at Mentor Graphics

for additional guidelines and examples.

Presentations

Unlike the other tools you used in prior rotations, Scan and ATPGDesign for Test is very automated. As such, there really arent objective metrics such as coding up and testing functionality of a module, schematic drawing styles, minimizing the size of a board, or working in the analog space at t=0+ digital signals have analog behavior to improve the quality of a signal in a high-speed system.

You will find your presentations for the TessentScan and ATPG rotation will most probably be a bit more subjective as you all should get the same results unless you experiment with some of the command switches and switch/value pairs.

For your presentations, please include the following as appropriate to your experience:

• Summary of expectations

• Approach taken

• What was the reasoning

• Strengths and weaknesses of the approach

• Outside research to better understand the silicon technologies (e.g. memories, etc.)

• Challenges/issues/problems encountered

• i.e. any simulation mismatches, other warnings, or errors

• Summary of the debug thought processes and techniques employed

Tools used to debug (e.g. Tessent Visualizer, tkdiff, etc.)

• Summary of Tasks accomplished (e.g. Video training and labs, project, etc.)

• Results

• i.e. pattern count, test coverage, etc.

• any surprises?

• Key takeaways / future considerations / lessons learned

• Summary of Badges earned by each team member

• Please follow the style used previously, in which each member of the team has time to share.

Part Number: xxxxxx