DATOS SOBRE PERFIL DE LAS PERSONAS MALTRATADORAS Y DE LOS MAYORES VÍCTIMAS DEL MALTRATO.

The examples so far have been for a generic nand gate. Now lets look at a model for a real part family. We will use the 54/74xx01 family. Our models are technol- ogy independent, so one model may represent any number of parts that have iden- tical functionality but differ only in timing.

We call the model in Figure 2.7 STD01. STD01 is also a nand gate, but in this case it has an open collector output. The example comes from the Free Model Foundry library. Line numbers have been added for reference.

28 Chapter 2 Tour of a Simple Model

--- -- File Name: std01.vhd

--- -- Copyright (C) 1998 Free Model Foundry

--

-- This program is free software; you can redistribute it and/or modify -- it under the terms of the GNU General Public License version 2 as -- published by the Free Software Foundation.

--

-- MODIFICATION HISTORY: --

-- version | author | mod date | changes made -- V1.0 R. Munden 98 APR 02 Initial release

--- -- PART DESCRIPTION: -- -- Library: STND -- Technology: 54/74XXXX -- Part: STD01 --

-- Description: 2-input positve-NAND gate with open-collector output

--- LIBRARY IEEE; USE IEEE.std_logic_1164.ALL; -- 1 USE IEEE.VITAL_timing.ALL; -- 2 USE IEEE.VITAL_primitives.ALL; -- 3 LIBRARY FMF; USE FMF.gen_utils.ALL; -- 4 --- -- ENTITY DECLARATION

--- ENTITY std01 IS -- 5 GENERIC ( -- 6 -- tipd delays: interconnect path delays

tipd_A : VitalDelayType01 := VitalZeroDelay01; -- 7 tipd_B : VitalDelayType01 := VitalZeroDelay01; -- 8 -- tpd delays

tpd_A_YNeg : VitalDelayType01 := UnitDelay01; -- 9 -- generic control parameters

MsgOn : BOOLEAN := DefaultMsgOn; -- 10 XOn : Boolean := DefaultXOn; -- 11 InstancePath : STRING := DefaultInstancePath; -- 12 -- For FMF SDF technology file usage

TimingModel : STRING := DefaultTimingModel -- 13 ); -- 14 PORT ( -- 15 B : IN std_ulogic := ‘U’; -- 16 A : IN std_ulogic := ‘U’; -- 17 YNeg : OUT std_ulogic := ‘U’ -- 18 ); -- 19 ATTRIBUTE VITAL_LEVEL0 of std01 : ENTITY IS TRUE; -- 20 END std01; -- 21 --- -- ARCHITECTURE DECLARATION

--- ARCHITECTURE vhdl_behavioral of std01 IS -- 22 ATTRIBUTE VITAL_LEVEL1 of vhdl_behavioral : ARCHITECTURE IS TRUE; -- 23 SIGNAL B_ipd : std_ulogic := ‘U’; -- 24 SIGNAL A_ipd : std_ulogic := ‘U’; -- 25

Figure 2.7 Complete VITAL model of a nand gate component MAG02 8/18/04 3:02 PM Page 28

The first thing to note about the model in Figure 2.7 is that we have taken 114 lines to describe a simple nand gate for which a synthesizable model could have been written in just one line. Of these 114 lines, only 53 are actual VHDL/VITAL code. The rest are comments and white space. The different requirements of component models and synthesis models justify this huge disparity. Lets look at all the details.

2.6 Finishing Touches 29 BEGIN -- 26 --- -- Wire Delays --- WireDelay : BLOCK -- 27 BEGIN -- 28 w_1: VitalWireDelay (B_ipd, B, tipd_B); -- 29 w_2: VitalWireDelay (A_ipd, A, tipd_A); -- 30 END BLOCK; -- 31 --- -- VITALBehavior Process

--- VITALBehavior1 : PROCESS(A_ipd, B_ipd) -- 32 -- Functionality Results Variables

VARIABLE YNeg_zd : std_ulogic := ‘U’; -- 33 -- Output Glitch Detection Variables

VARIABLE Y_GlitchData : VitalGlitchDataType; -- 34 BEGIN -- 35 --- -- Functionality Section

--- YNeg_zd := VitalNAND2(a=> A_ipd, b => B_ipd, -- 36 Resultmap => STD_wired_and_rmap); -- 37 --- -- Path Delay Section

--- VitalPathDelay01 ( -- 38 OutSignal => YNeg, -- 39 OutSignalName => "YNeg", -- 40 OutTemp => YNeg_zd, -- 41 XOn => XOn, -- 42 MsgOn => MsgOn, -- 43 Paths => ( -- 44 0 => (InputChangeTime => A_ipd’LAST_EVENT, -- 45 PathDelay => tpd_A_Yneg, -- 46 PathCondition => TRUE ), -- 47 1 => (InputChangeTime => B_ipd’LAST_EVENT, -- 48 PathDelay => tpd_A_Yneg, -- 49 PathCondition => TRUE ) ), -- 50 GlitchData => Y_GlitchData ); -- 51 END PROCESS; -- 52 END vhdl_behavioral; -- 53

The first 22 lines are comments. We start by documenting the name of the file as discussed earlier. Then comes a copyright statement. You are going to want to share your models and your coworkers are going to want to use them. The copy- right states who owns the model and what rights are reserved. Even if you intend to retain no rights at all to the model, you should explicitly say so here.

Models change over time. As with any other software, there needs to be a way to determine the revision of a particular copy. It is also helpful to have some idea what changed from one revision to the next. Therefore, in the header, we have a MODIFICATION HISTORYblock. This describes the version number, the author or editor of that version, the release date, and a brief summary of the changes made. If somebody contacts you about a problem with a model, the first thing you will want to know is the version number.

FMF models track history through comments in the header. This is for docu- mentation purposes only. During development, you could use a software revision control system such as RCS or CVS to make it easier to record the actual code changes. This could be particularly beneficial during the development of very large models where there are multiple developers involved.

The part description section of the header states in which library the part has been placed. It tries to indicate the technology, if relevant, and it gives the name of the model. Finally, there is a one-line description of the part’s function.

Major sections of the model are separated by comment banners. These may be indented but are extended to the full 80 character width of the format. As men- tioned, models should always be limited to 80 characters in width to facilitate print- ing and online viewing. The banners indicate the nature of the following section of code. Indented comments describe subsections of code or groups of generics or variables.

This model in Figure 2.6 has three lines of generic control parameters on lines 10, 11, and 12:

-- generic control parameters

MsgOn : BOOLEAN := DefaultMsgOn; -- 10 XOn : BOOLEAN := DefaultXOn; -- 11 InstancePath : STRING := DefaultInstancePath; -- 12

The generic MsgOnis a boolean that controls message generation should a glitch be detected in the VitalPathDelay procedure. If there were timing constraint pro- cedures, they would also read the value of MsgOn. Because a model may contain several VitalPathDelay procedures, it is convenient to control all of them through a generic.

The next generic, XOn, controls the generation of ‘X’s on the output if a glitch is detected.

The last of the three generics, InstancePath, is a string that becomes part of the warning or error message produced by a timing constraint procedure when a violation is detected. Although this model does not have any timing constraints, we still include the generic.

30 Chapter 2 Tour of a Simple Model

The last line in the generic list, 13,

-- For FMF SDF technology file usage

TimingModel : STRING := DefaultTimingModel -- 13

declares a very important generic. The TimingModelgeneric is used for selecting the section of the timing file that corresponds to the part number used in the design for each instance of each component. A TimingModel property or attribute is attached to the component symbol in the schematic. The schematic’s VHDL net- lister will copy the value of the attribute to the generic map of the instance in the netlist. When the mk_sdf program (a free utility used to generate the SDF file, described in more detail in Chapter 12) reads the netlist, it picks out the value and uses it to match a section in the timing file for the model. It then uses the information from the timing file to create an entry for the instance in the SDF file for the design. We will look at SDF in Chapter 4 and the formats for timing files Chapter 12.

Port, signal, and variable declarations are made one per line. Indentations are set to four spaces. We always use spaces instead of tabs. Tabs may be set to any- thing by the reader or printer. By using spaces, we can control the formatting and be sure the model will print legibly.

Except for WireDelayblocks, always try to use named associations. For example, on lines 36 and 37 we write

YNeg_zd:= VitalNAND2(a=> A_ipd, b => B_ipd, -- 36 Resultant => STD_wired_and_rmap); -- 37

in which we specify that A_ipdis associated with a, and so on. Although this makes the model easier to understand, there is another important reason. Many of the VITAL functions and procedures have default parameters set in them. Because not all parameters always need to be passed during the call, named association is required to ensure the values given are passed to the right parameters. In Figure 2.6, the VitalNAND2 function was called without the Resultmapparameter. The function defaulted to outputting one of (‘U’, ‘X’, ‘0’, ‘1’), which is normal for an output that can drive both high and low. In Figure 2.7, Resultmap gets STD_wired_and_rmap from the FMF.gen_utils package and the output is mapped to one of (‘U’, ‘X’, ‘0’, ‘Z’). This is correct for an open collector output that can drive low but not high.

2.7

Summary

A component model is quite different than a synthesizable model. Component behavior is modeled at as high a level of abstraction as practical. Formatting and readability are more important in a component model because it is likely to see wider circulation and have a longer useful life. The use of standard interfaces, specifically std_ulogic, is required to ensure that all component models can easily be integrated into board-level simulations.

Unlike synthesizable models, component models are used to verify timing. They include the simulation of propagation delays and interconnect delays and the checking of timing constraints. Taking advantage of the VITAL standard allows the models to use generics to bring in the actual timing values through SDF files. By maintaining all timing values external to a model, it can be technology independ- ent. As processes evolve and new speed grades become available, the timing file can be updated without the need to modify a tested model.

32 Chapter 2 Tour of a Simple Model

In Part II we examine the standards adhered to in component modeling and the many supporting packages that make life easier for the component modeler. These standards are from the IEEE. They include VHDL, VITAL, and SDF. The packages covered are the IEEE VITAL packages and some packages written expressly for com- ponent modeling from the Free Model Foundry.

Chapter 3 covers several IEEE and FMF packages that are used in writing com- ponent models. The Standard Logic 1164 package is discussed. Particular attention is given to the VITAL packages. These include VITAL Timing, VITAL Primitives, and VITAL Memory. Four packages from FMF are also reviewed.

Chapter 4 provides a basic tutorial on the Standard Delay Format as it applies to component modeling. The overall file format is described. The capabilities of SDF and its syntax are explored.

Chapter 5 describes the organization and requirements of VITAL models. The different requirements for level0 and level1 models are provided. The mapping of SDF to VITAL generics is explained. The sections of a VITAL model are described along with the order in which they must appear.

Chapter 6 is a detailed examination of modeling delays within and between com- ponents. The use of VITAL path delay procedures is unraveled. Different delay modes and how they relate to glitch detection are explained. The trade-offs between distributed delays and pin-to-pin delays are discussed.

Chapter 7 discloses the truth behind VITAL truth tables and state tables and their employment in component modeling. VITAL memory tables are not forgotten. This chapter reveals the differences between truth tables and state tables, how to create them, and when each is appropriate. It also touches on memory tables.

In Chapter 8, timing constraints are defined and the essentials of constraint modeling are described. Each type of timing constraint is explained, along with its usage.

P A R

T

II