Support earthquake relief in China

From:http://en.wikipedia.org/wiki/2008_Sichuan_earthquake

The 2008 Sichuan earthquake (Chinese: 四川大地震), which measured at 8.0 Ms according to the China Seismological Bureau, and 7.9 Mw according to USGS, occurred at 14:28:01.42 CST (06:28:01.42 UTC) on 12 May 2008 in Sichuan province of China. It was also known as the Wenchuan earthquake (Chinese: 汶川大地震), after the earthquake's epicenter in Wenchuan County in Sichuan province. The epicenter was 80 kilometres (50 mi) west-northwest of Chengdu, the capital of Sichuan, with a depth of 19 kilometres (12 mi).[2] The earthquake was felt as far away as Beijing (1,500 km away) and Shanghai (1,700 km away), where office buildings swayed with the tremor.[5] The earthquake was also felt in nearby countries.
Official figures (as of May 22, 10:00 CST) state that 51,151 are confirmed dead, including 50,651 in Sichuan province, and 288,431 injured.[4] Tens of thousands are missing, approximately 14,000 of them buried, and eight provinces were affected.[6] The earthquake left about 4.8 million people homeless.[7] It was the deadliest and strongest earthquake to hit China since the 1976 Tangshan earthquake, which killed over 240,000 people.

Support earthquake relief in China

http://www.google.com/chinaearthquake/

Cadence NC simulator teaching<1>_Get Help

0. Get HELP

You can display a list of options for any of the simulator tools and utilities by typing the tool or

utility name followed by the -help option.

The -help option displays a list of the command options for the specified tool with a brief

description of each option.

Syntax:

% tool_name -help

September 200350Product Version 5.1

NC-Verilog Simulator Help

Getting Help

Examples:

% ncvlog -help

% ncvhdl -help

% ncelab -help

% ncsim -help

% ncupdate –help

0.1 Getting Help on Simulator Commands

To get help on simulator (ncsim) commands: Use the help command.

ncsim> help [help_options] [command | all [command_options]]

Examples:

ncsim> help database

ncsim> help database –statement

ASIC verification

ASIC verification


-"Anything that can go wrong - Will"-Murphy

What is my next step to be performed?

Now Lets start with an assumption that anything may go wrong

What are the various areas can things go wrong?

* List down the areas in the flow that things can go wrong and derive a methodology to verify at each and every stage.
* List down all your uncertainities that could potentially happen and how to model it and how to constrain and verify up-front.

Lets Explore and re-visit each and every area in the Design flow to cover potential risk

* Functional Verification (RTL level , Gate level)
* Formal Verification
* Static Timing Analysis
* Physical Verification
* Power Simulation
* Thermal Simulation
* Noise Simulation
* Test Simulation
* Emulation
* Hardware proto-type
* Hardware Software co-simulation
* Transistor level Simulation

Now lets Venture in to each area and insure it

Functional Verification:

* TLM(Transaction Level Modelling)
* Linting
* RTL Simulation ( Enivronment involving : stimulus generators, monitors, response checkers, transactors)
* Gate level Simulation
* Mixed-signal simulations
* Regression

How Much Did I cover in the functional part - What is my Coverage Metric? and what are the methodologies used?

* Is the verification tests covered pin-pointed tests or tests with random seeds to cover all the corner-cases.
* Code-coverage
* Line coverage
* Functional coverage

Formal Verification:

* Equivalence checkers

# RTL versus Gate
# Pre-layout versus post-layout Netlist

* Assertion based property checkers(Mathematical techniques to allow larger state space coverage)

Timing Verification:

* With whom the Chip is talking to (To know the Interface Timing's)
* What is the Timing-budgets with in the chip, and how to constrain it within each I.P. and finally analysing and sigining for Timing-targets
* How to address the timing targets with varying process parameters(on-chip variation) what is the optimal derating number to be set so that variations are addressed.
* Steps to minimize the clock-jitter.

Physical Verification:

Is my design process friendly ?

* DRC (Design Rule Check)
* LVS
* Antenna Checks
* ERC
* ESD checks
* Speed monitor's

Noise Simulation:

How Noisy is my design so need to perform noise simulations addressing these areas

* Simultaneous Switching Noise (SSN)
* Package Noise
* EMI Noise
* Power-ground noise
* Cross-talk noise
* Analog Noise
* Substrate noise

Power Simulations:

Is my design meeting power-targets

* IR drop analysis
* Dynamic power simulations

Power related methodologies
# Optimum location for De-caps
# Multiple Voltage domains
# Multi Vt design
# DVFS (Dynamic Voltage and Frequency scaling)
# Clock-gating Techniques
# Power Management Unit (to shut-off when not required)
# Level-Shifters across cross-voltage domains

Thermal Simulations

Study the thermal targets and mechanism to reduce

Test Simulations

Is my design testable once chip comes out, methodologies to identify the problematic areas

* Boundary Scan
* Memory BIST simulations
* Tester specific vector generation and simulations
* Tester vector compression techniques to reduce tester time
* At-speed testing mechanism's
* Scan-shift and scan-capture methodologies
* IDDQ testing
* Wafer Level Burn-in Tests to know Known Good Dies(KGD)
* Wire pull tests
* DC parameter tests
* AC parameter tests
* Path-delay tests
* Delay tests
* Transition fault testing

Addressing DSM and Yield Issues

* Redundant via's
* Spacing non critical areas to be lithography friendly
* Wire widening
* Metal Filling
* Metal Slotting

Emulation:

Emulates the functional behaviour of the design. Synthesizable assertions are mapped to emulators to perform at system speeds.

Hardware prototype:

Proto-typing the system requirements in a programmble FPGA's

Inspite of all the Verification Methodologies and Strategies if things goes wrong, how to address that in the design - Methodologies to reduce cost & time

* Spare-gates
* Redundant rows/columns in the memories
* Redundant vias
* Built-in self repair memories
* Focussed Ion Beam Methodologies

Debussy Interface in Verilog

Overview Debussy is a debugging system developed by Novas Software. Riviera-PRO can work with Debussy in two modes: Post-processing Mode In the post-processing mode simulation and debugging are two separate stages. First, Riviera-PRO is used to simulate the design. During simulation Riviera-PRO dumps required data (i.e. signal waveforms) to a Fast Signal Database (FSDB). Once the simulation process is over, the design can be loaded into Debussy. Debussy will read the signal history from the FSDB database created by Riviera-PRO. Dumping data to the FSDB database can be controlled either directly from Verilog source code (with FSDB tasks) or with macro commands. Macro commands (and FSDB tasks) can be invoked interactively from the Console or placed in macro files. Interactive Mode In the interactive mode Riviera-PRO acts as a slave application for Debussy and can be controlled directly from the Debussy GUI. Debussy sends commands to Riviera-PRO and reads simulation data from it. Using the interactive mode requires some initial setup such as compiling the project in Riviera-PRO, verifying the list of available PLI application and preparing the debussy.rc file (templates are available). NOTE: Riviera-PRO for Solaris and Riviera-PRO for Linux uses version 6.1 of the FSDB writer module (developed by Novas Software). Riviera-PRO for Windows uses FSDB writer module version 5.4. This is the latest version provided by Novas on this platform. Contents: Post-processing Mode Interactive Mode Debussy Resource File Supported FSDB Tasks Post-processing Mode Dumping FSDB databases from Verilog designs is controlled with FSDB tasks. Tasks can either be placed directly in Verilog source code, used in a macro file (alongside regular macro commands) or issued interactively from the Console. To control writing data to the FSDB database, place the appropriate tasks directly in the source code, for example: initial $fsdbDumpvars(0, V_BJACK_tb); Refer to Debussy documentation for details on using FSDB tasks. If you do not want to modify your Verilog source code, you can call FSDB tasks directly from the Console, for example: asim V_BJACK_tb $fsdbDumpfile("simdata.fsdb") $fsdbDumpvars(0, V_BJACK_tb) run -all Simulation data is automatically flushed to the FSDB database when simulation is finished with the endsim command. The simulation process can be automated with a macro file. The macro can include all supported FSDB tasks. NOTE: FSDB tasks are located in the libfsdbwriter.so (Unix, Linux) or fsdbwriter.dll (Windows) library. This library must be included in the list of PLI applications for the FSDB tasks to work. To check PLI applications available to Riviera-PRO, select Tools | Simulation Options from the menu, go to the Verilog tab and click the PLI Applications button. By default, the libfsdbwriter.so (Unix, Linux) or fsdbwriter.dll (Windows) library is included in the list of PLI applications. Interactive Mode Before using Debussy with Riviera-PRO in the interactive mode, the environment should be set up in Riviera-PRO. In Verilog designs this requires creating a library, compiling Verilog source files, checking the list of PLI applications visible from the current directory and changing the hierarchy separator to Verilog-like. Debussy can then be started with the start_debussy script (delivered with Riviera-PRO). Both Riviera-PRO and Debussy should work in the same directory (referred to as the project directory). Compiling Source Files in Riviera-PRO Compilation should be run in the project directory. The directory can be selected in the system shell before Riviera-PRO is started with the rungui script or directly in the Riviera-PRO environment (with the Change Directory command from the File menu). After selecting the directory, create a new library and set is as the default working library. The name of the default working library is displayed in the Library combo box in the Console. After creating the library, you can compile project source files. Use the Compile command from the Compilation menu or the alog macro command. If you want to use line debug, make sure the -dbg switch is passed to alog. Changing the Hierarchy Separator To ensure proper communication between Riviera-PRO and Debussy, the hierarchy separator must be changed from VHDL like to Verilog like. To change the separator, choose Simulation Options from the Simulation menu and choose Verilog like on the General tab. Verifying the List of PLI Applications Tasks for writing FSDB database reside in the libfsdbwriter.so (Unix, Linux) or fsdbwriter.dll (Windows) library. This library should be included in the list of PLI applications visible from the current directory. To check PLI applications available to Riviera-PRO, select Tools | Simulation Options from the menu, go to the Verilog tab and click the PLI Applications button. The libfsdbwriter.so (Unix, Linux) or fsdbwriter.dll (Windows) library is by default included in the list of PLI applications. If it was removed from the list, use the Add button to restore the default. The project data is now ready. You can quit Riviera-PRO and start Debussy. Debussy should be started from the project directory, otherwise configuration settings stored in the project directory will not be available. Starting Debussy Debussy can be started with the start_debussy script included with Riviera-PRO. The script is located in the etc/ subdirectory of the Riviera-PRO installation directory. Command line switches for Debussy can be passed directly to start_debussy, for example: /etc/start_debussy -f run.f NOTE: The run.f file contains a list of project source files. Before starting Debussy, the start_debussy script checks if the project directory contains the debussy.rc file. If the file cannot be found, the script copies the template verilog.rc file to the project directory and renames it debussy.rc. The verilog.rc file included with Riviera-PRO includes additional sections that make Riviera-PRO visible to Debussy. NOTE: If the project directory already contains the debussy.rc file, the script will not overwrite it. If the debussy.rc file does not include sections required by Riviera-PRO you can either: Close Debussy, rename the debussy.rc file and start Debussy again with the start_debussy script. The script will copy the template debussy.rc file to the current directory, as described above. Add add the appropriate sections manually. See Debussy Resource File for details. Starting the Interactive Mode To switch Debussy to the interactive mode, use the Interactive Mode command from the Tools menu. Debussy will display an additional taskbar. Clicking the Run/Continue button will initialize Riviera-PRO. Note that the Riviera-PRO console replaces the Debussy console. The console is fully interactive. It displays messages from Riviera-PRO and it can also be used to enter Riviera-PRO macro commands or invoke FSDB tasks. After switching to the interactive mode, call the $fsdbDumpvars task: $fsdbDumpvars This tells Riviera-PRO to dump signal change information to the FSDB file. Simulation data from the FSDB file is then read by Debussy. You can now select Active Annotation from the Source menu to see how Debussy annotates the source code with simulation data generated by Riviera-PRO. For further details on using Debussy refer to Debussy documentation. NOTE: To check if Riviera-PRO is the default simulator for the interactive mode choose Tools | Options | Preferences from the Debussy menu and then select the Simulation tab in the Preferences window. Riviera-PRO is listed under the name Aldec. Debussy Resource File The debussy.rc resource file contains Debussy configuration settings. The file is automatically created in the directory you run Debussy from. The template debussy.rc files are located in the etc/ subdirectory of the Debussy installation directory. The files are renamed vhdl.rc and verilog.rc. The verilog.rc file contains settings required in Verilog designs. The verilog.rc file is automatically copied to the current directory and renamed debussy.rc if you start Debussy with the start_debussy script: start_debussy The start_debussy script is located in the etc/ subdirectory of Riviera-PRO installation directory. If the debussy.rc file already exists in the current directory, the start_debussy script will not overwrite it. If the original debussy.rc does not contain entries required by Riviera-PRO, you can either add the required entries manually or rename the original debussy.rc file and run start_debussy again. A list of changes that have to be applied to the debussy.rc file to enable integration of Debussy and Riviera-PRO is shown below. Note that different settings are required for VHDL and Verilog. This application note lists only changes required for Verilog designs. See a separate application note for VHDL. In the [ThirdParty] section, add Aldec to the vendor list: [ThirdParty] ThirdPartySimTool = vendor1 vendor2 aldec Additionally, you can set Riviera-PRO to be the default simulator by setting the thirdpartyIdx key in the [Simulation] section to the index of Aldec in ThirdPartySimTool list. In the above example it is 2 (list items are counted from 0): [Simulation] simType = aldec thirdpartyIdx = 2 The following sections have to be added to the debussy.rc file that is going to be used with Verilog designs. [aldec] TPLanguage = Verilog TPName = Aldec TPPath = //etc/vsad TPOption = -init AddImportArgument = FALSE LineBreakWithScope = FALSE StopAfterCompileOption = "" TPPath contains the full path to the vsad script located in the etc/ subdirectory of the Riviera-PRO installation directory. Optionally, user defined commands can be set: [UserButton.aldec] Button1 = "Dump All Signals" "$fsdbDumpvars\n" Button2 = "Next 1000 Time" "run 1000\n" Button3 = "Next ? Time" "run ${Arg:Next Time}\n" Button4 = "Show Variable" "examine ${SelVar}\n" Button5 = "Force Variable" "force -freeze ${SelVar} ${Arg:New Value} 0\n" Button6 = "Release Variable" "noforce ${SelVar}\n" Button7 = "Deposit Variable" "force -deposit ${SelVar} ${Arg:New Value} 0\n" Button8 = "Dump Now" "$fsdbDumpflush" Button9 = "Dump Off" "$fsdbDumpoff\n" Button10 = "Dump On" "$fsdbDumpon\n" Supported FSDB Tasks The following FSDB tasks are supported in Verilog (for detailed usage information, refer to Debussy documentation): $fsdbDumpfile $fsdbDumpvars $fsdbDumpvarsToFile // only one argument is supported (i.e. the filename with the dumpscope) $fsdbDumpMem, $fsdbDumpMemNow $fsdbDumpon $fsdbDumpoff $fsdbDumpflush $fsdbVersion The following tasks are currently not supported: $fsdbAutoSwitchDumpfile, $fsdbSwitchDumpfile, $fsdbDumpStrength. Except for placing the tasks in the HDL source code, you can also invoke equivalent macro commands or tasks from the Console or from a macro file. (The names of the commands are the same as the names of the tasks, without the initial $ sign.)

I am confusing!

I feel very upset today, because i am not sure about my future.
I think that i will be Ok!
Because I believe that famous saying:"I came, I suffered, but I survived!"

weekly plan-6.23-6.29

1) continue to forget zz
2)forget all the unhappy things
3)complete the PCI presentation fluntly
4)study the P_ARB module and make it clear
5)summarize the P_ARB module
6)study someting about investment
7)come on,happily!
You can make it, and do it well.

(fwd)Use SystemVerilog for coverage metrics

SystemVerilog constructs suit RTL design, high-level modeling, testbench creation, and assertion specification.

Thomas L Anderson, Cadence Design Systems, San Jose, CA; Edited by Charles H Small and Brad Thompson -- EDN, 3/29/2007

The design-and-verification industry is at the intersection of two important trends in the design and verification of SOC (system-on-chip) devices: the adoption of SystemVerilog HDVL (hardware-description and -verification language) and the increasingly critical role for coverage metrics. The interest in System Verilog is understandable; this IEEE-standard language has the features for RTL (register-transfer-level) design, high-level modeling, testbench creation, and assertion specification (Reference 1).

SystemVerilog also provides constructs for design-and-verification engineers to specify functional coverage points—conditions that designers must exercise for complete verification of the design. Designers increasingly use functional coverage to supplement traditional code coverage. The primary driver for this evolution is the widespread use of constrained-random-stimulus generation.

Traditional verification plans typically include a list of design features or tests that verify features and test status. This approach has worked well with handwritten, directed tests because of the clear correspondence between features and tests. However, verification consists of writing and running each test in simulation, perhaps after turning on some code coverage to help identify features you may have missed in the plan.

Constrained-random-stimulus generation requires a different approach, in which each automatically generated test can exercise many features and parts of the design. A modern verification plan lists features, functional coverage points for the features, and coverage status. You gauge verification closure by the number of coverage points you exercise rather than the number of tests you complete.

SystemVerilog provides all the features necessary to develop both handwritten tests and constrained-random testbenches and to track progress toward closure. Most simulators have built-in code coverage for the new design constructs that SystemVerilog introduces. Thus, code-coverage metrics are available for designs taking advantage of the language's advanced RTL features.

SystemVerilog provides several powerful specification methods for functional coverage. The first is cover property, which is part of the SVA (SystemVerilog Assertions) subset of the language. SVA's assertion features, including temporal sequences, are also available for functional coverage. For example, Listing 1 ensures that the simulator exercises the two extremes—one and five cycles—of a request-acknowledge handshake. Both simulators and many formal-analysis tools support the cover-property construct. If formal analysis can prove that a coverage point is unreachable, a design bug may be blocking important functions from being exercised. If formal analysis instead provides a trace showing how to reach a coverage point, this trace can provide a good hint on how to write or generate a test.

Beyond individual coverage properties, you sometimes must track ranges of values. SystemVerilog provides the cover-group construct, which is not part of SVA, to perform this function. For example, Listing 2 tracks the payload sizes of incoming packets on a network interface and ensures the coverage of corner cases of empty, minimum, and maximum payloads. SystemVerilog also provides the cross construct to measure cross-coverage between two coverage points. This feature allows the tracking of combinations of coverage metrics. For example, Listing 3 specifies an enumerated type for four packet classes for the network interface, adds a cover point to track the packet classes, and crosses the packet types with the payload sizes.

Ultimately, the SOC-tapeout decision must take into account all coverage metrics. Although functional coverage is the primary method, code coverage has value as a backup to identify areas of the design with no functional coverage due to an incomplete verification plan. The project team needs to merge together code- and functional-coverage results to assess verification progress and help determine verification closure. Coverage is critical for modern, constrained-random verification. Without effective metrics, no reliable way exists to gauge status and manage progress. In addition to its other features and benefits, SystemVerilog provides support for functional coverage. By including coverage in the verification plan from the start of the project and taking advantage of SystemVerilog, the SOC team can employ a complete plan-to-closure methodology that greatly increases the chances for a successful product.

Saving Power Technologies in ASIC Design

Many kinds of technologies are used in saving power in ASIC design.
Clock gating
Operand isolation
Multi-vt libraries
Multi-supply voltage
Power shutoff
Power shutoff w/ state retention
Power shutoff w/ always on buffer
Voltage/frequency scaling
RTL power estimation
Substrate biasing
Other (please specify)

Basic knowledge of Wimax(1)

WiMax offers a rich feature set and flexibility, which also increases the complexity of service deployment and provisioning for fixed and mobile networks.

Let us take a look at the WiMax Management Information Base (MIB).

Figure 2: WiMax Management Information Base [Intel.Com]

The above figure shows the management reference model for BWA (Broadband Wireless Access ) networks. This consists of a Network Management System (NMS), some nodes, and a database. BS and SS managed nodes collect and store the managed objects in an 802.16 MIB format. Managed objects are made available to NMS' using the Simple Network Management Protocol (SNMP).

When a customer subscribes to the WiMax service, the service provider asks the customer for the service flow information. This would include number of UL / DL connections with the data rates and QoS parameters. The customer also needs to tell the kind of applications that he proposes to run.

The service provider then proceeds to pre-provision the services and enters the information in the Service Flow Database.