inside vhdl

Developing VITAL-Compliant VHDL Models Functionally complex devices require equally sophisticated HDL models. VITAL's compliance can assist the designer in creating precise descriptions of functionality and timing characteristics. by Arkadi Poliakov and Anatoli Sokhatski

Up to now designers have employed the VITAL standard mostly for functionally simple ICs--but we imagine a bright future in which that will change. To bring VITAL to bear on more complicated designs, we had to solve problems in describing such complex behavior as multibit bidirectional buses and specific timing parameters. We developed our approach while designing VITAL level-0-compliant VHDL models of an Integrated Device Technology (IDT) FIFO memory family IC for the Free Model Foundation (FMF; www.vhdl.org/fmf/). We gathered source data from IDT data sheets including timing parameters, the VITAL specification, and the FMF guidelines for VHDL VITAL models. We also prepared timing data in the SDF files. Here we focus on two specific aspects--entity declaration and architecture body structure--of describing functionally complex devices in the VITAL standard.

Entity declaration
The models structure entity declaration in accordance with VITAL level 0 and the FMF requirements. We presented generics by input delays (tipd prefix), propagation input-output port delays (tpd), and timing constraints (tsetup, thold, tperiod, twidth).

Preparing entity declaration, we came across two problems. First, IDT data sheets describe timing parameters united in groups; for example: tA (access time), CLKA posedge to A0-A35, and CLKB posedge to B0-B35. It's possible to present the generic and SDF definition for each path. To decrease the model volume we left one representative, tpd_CLKA_A0, and used an alias declaration in the architecture:

ALIAS tA : VITALDelayType01 IS tpd_CLKA_A0;

We further used tA for parameter access.

Second, IDT data sheets describe tSKEW parameters that aren't timing constrained but that they use to determine behavior. For example: If the skew time between CLKA and CLKB is more than tSKEW1 and the FIFO isn't full, then the IRA flag will be deasserted at the second CLKA positive edge--else it occurs in the third edge.

The same is for tSKEW2 and the almost-full flag. Actually, tSKEW1 and tSKEW2 present delays on the internal comparators. In contrast, SDF and VITAL determine tSKEW time only as a strict timing constraint for proper functionality. Such a limitation doesn't suit the parameters. Thus we had to declare model components SKEW1 and SKEW2, and describe the component VITAL device parameters as tdevice_SKEW1, tdevice_SKEW2. In the SDF file we had to declare the SKEW1 and SKEW2
instances for the VITALBuf cell type.

Architecture body
The architecture body structure follows the FMF requirements and correlates with VITAL level-1 structure, which allows the designer to simplify description and make it more reliable (see the figure).

Wire Delay Block reflects external interconnect delays to the input ports. We also had to declare skew components, which are artificial: they're assigned only to transfer tdevice_SKEW parameters to the model:

SKEW components 

SKEW1: VITALBuf (OpenOut, OpenIn, 

	(tdevice_SKEW1, tdevice_SKEW1));

SKEW2: VITALBuf (OpenOut, OpenIn, 

	(tdevice_SKEW2, tdevice_SKEW2));

The behavior block allows designers to unite scalar port in buses and separates the behavioral part from the others. The block structure appears below.

VITAL behavior:	

BLOCK

<Port list and port map>

<Zero-delayed output signal declarations>

<Constant, type, internal signal, procedures

declarations>

<Timing checking section>

<Functionality section>

<Path delay section> 

END BLOCK

Two main differences characterize the external port list in the entity declaration and the block port list that we used in the FIFO models. First, entity scalar ports like A0, A1 are united into buses. Second, two ports serve as bidirectional entity ports: The first input port, such as A_ipd, models input interconnect delay; the second output port, such as A, drives the value of the bidirectional port.

The zero-delayed output signal declaration section describes zero-delayed signals for each output and bidirectional port. The behavioral description shows declarations for internal registers and wires, additional constants, types, and procedures. The timing-checking section is presented as process timing checks, which contains VITAL behavior-block input signals in a sensitivity list. The functionality description, which consists of process and assignment statements, calculates output zero-delayed signals and internal signals.

The path delay section models a delay between internal zero-delayed output signals and external output signals. We used the VITAL procedures VITALPathDelay, VITALPathDelay01, and VITALPathDelay01Z. The section consists of processes for scalar output ports and generate statements for the bus.

VITAL outcomes

The pros and cons of the standardization model development process are well known. The VITAL standard is on the right track toward the precision timing description of complex devices, but still could use improvements.

We widely applied VITAL package procedures and extended the VITAL level-1 model structure, which helped us create level-0 models with complex functionality. However, we ran into some difficulties in describing internal delays in VITAL models and further assembling SDF files. It's necessary to be careful while describing tSKEW timing, because in some cases the VITAL and SDF semantics of this parameter don't correspond to data sheet semantics. Model style standardization also requires additional effort. For example, the FMF requirement to use capital letters for keywords doesn't make the code more readable. The experience of programming and HDL language application proves it.

The result of our work is that more than a half of the VITAL model code consists of VITAL procedure calls. For the IDT FIFO memory model with 16 scalar inputs, 6 outputs, and 2 36-bit bidirectional buses with 2600 lines of its VHDL code, only 1000 lines represent directly functional descriptions, while 1100 lines represent VITAL procedure calls. It would be great to have options in CAD tools that could generate VITAL descriptions.

In using Cadence's Leapfrog, Modeltech's V-system, and Synopsys's VSS VHDL simulators, we came across some problems working with VITAL and SDF. For example, Leapfrog didn't generate an error message when checking a VITAL-0 entity that contains constant declarations; V-system and VSS didn't completely check the correspondence between SDF parameters and VHDL generics.

Another problem arises in the selection of timing parameter types. VITAL's description contains information about three values of timing parameters: minimum, typical, maximum. Timing parameters are loaded from SDF at the elaboration phase; it's possible to use minimum or typical or maximum values simultaneously for all timings. Using various combinations of values conjures a special issue of dynamic timing verification.

Excerpts from VHDL models for IDT FIFO memory can be viewed at www.isdmag.com/articles/vital.html. The SDF file structure appears in the excepts at www.isdmag.com/articles/hdlmodels.html (see "Making Verilog Models Compatible with VHDL VITAL Level-0 Models," May, p. 62).

The authors would like to thank Alex Pejenkov for his ideas in the development of VITAL models of IDT FIFO memory chips.

Arkadi Poliakov is senior CAE consulting engineer at Seva Technologies, Inc. in Fremont, Calif. He has more than 25 years of experience in the development of digital simulation systems and in university teaching in Russia.

Anatoli Sokhatski is senior CAE consulting engineer at Seva. Also from Russia, he has more than 15 years' experience in the development of CAD tools and teaching in that country.

To voice an opinion on this or any Integrated System Design article, please email your message to jeff@isdmag.com.