inside hdl

Making Verilog Models Compatible with VHDL VITAL Level 0 Models Verilog and VHDL are both here to stay. Translating between the two languages may be necessary, but it doesn't have to be painful. by Yuri Tatarnikov

Early in the '80s, the drive to create a single language for the description of digital systems at the behavioral, RT, and gate levels was of such vital importance for the design of military electronics that the Department of Defense created VHDL, an extremely powerful language, and mandated its use for military design. But life tends to complicate our intentions: Verilog already existed and had gained approval from engineers, designers, and scientists alike. The dream of standardizing on a single powerful language failed.

So designers now have the choice--and sometimes the curse--of two very well organized and well supported languages. They have their own followers and adherents who constantly argue their respective advantages. Perhaps the division pleases the marketers, but it causes a whole lot of problems for those who use it to model, simulate, or synthesize designs.

To attempt to meet the requirements of the two hostile sides, the manufacturers of standard devices must create both Verilog and VHDL models. A problem of significant importance immediately emerges: how to create models that contain exactly the same features.

We'd like to offer some tips on how to create compatible Verilog and VHDL models for the same device, based on our experience. The style described exhibits general characteristics that can serve both board and chip design and verification. Specifically, we highlight several critical conversion issues--modeling skew and timing equivalency in particular--for engineers who deal with chip-level Verilog behavior and timing modeling for PC-board verification.

Mapping for timing equivalency

Integrated Device Technology, Inc. asked Seva Technologies to develop both VHDL VITAL level 0 and compatible Verilog models for 78 FIFOs across 23 families. The models had to represent the behavior and timing of the chips used for board verification, satisfy the demands of board design and verification, and use an identical SDF file.

Fortunately, the Free Model Foundry (FMF; formerly the Free Model Foundation) has already issued several articles and a style guide for writing VHDL models with such features (see the FMF pages on the VHDL International Web site, http://vhdl.org/fmf/). Therefore we focused our contribution to modeling style mainly on Verilog models. Creating Verilog models that fully reflect all the features of the restricted style of VHDL models was the ideal approach.

Our VHDL models have a number of significant features. The models represent the behavior of the chip by specifying interface and internal timing characteristics, in particular the timing requirements for inputs (clock frequency range, pulse duration, and setup and hold time). They identify timing thresholds between inputs (which define differences in chip behavior) and switching times between inputs and outputs (access time, enable time, and propagation delays); they also separate the timings from the models in the SDF file. The models can represent PCB interconnect delays as chip port delays. Finally, we implement operations with timings using IEEE VITAL primitives and VITAL timing packages, as well as the ff_package, gen_utils, and conversions from FMF.

In order to implement those features, the VHDL models include the following constructs: generic parameters, representing all the timing quantities; declaration of intermediate signals mapped to chip ports (intended to include buffers with delays to model the PCB interconnect delays as chip port delays); a timing check section (VITAL procedure call statements that check the timings); a functionality (behavioral) section, which operates the intermediate signals only; and a path delay section (VITAL procedure call statements) that models buffers (see the table).

Excerpts from IDT 723642 FIFO memory models in VHDL and Verilog can be viewed at www.isdmag.com/articles/hdlmodels.html.

initial begin	// extracting minimal tSKEW1 value

#1		// non-zero value should be specified

	tBuffIn1 = $time; 

	BuffIn1 <= 1'b0;	// creates event on gate input

	@(BuffOut1);	// waiting for event on gate output

	tSKEW1 = $time - tBuffIn1;	// this is SKEW1 value

end

The SDF file was created from memory data sheet information and includes the minimum, typical, and maximum values of delays. For all standard components the manufacturer should provide an SDF file to go with the behavioral model.

Mapping of constructs in VHDL and Verilog is generally rather straightforward. The only exception is back annotation of timing data, which has no clear reflection in SDF. In our case the skew time defines the behavioral peculiarities of IDT chips. The section below describes how to deal with modeling skew.

Modeling skew

Note how the IDT memory data sheet addresses the issue of skew time: " tSKEW1 is the minimum time between the rising CLKA edge and a rising CLKB edge for IRB to transition to high in the next cycle. If the time between the rising edge of CLKA and the rising edge of CLKB is less than tSKEW1 , then IRB may transition to high one cycle later than shown in the timing diagram."

The data sheet isn't referring to the SDF skew time, which specifies the maximum allowable time between two signals, beyond which the behavior becomes unreliable; tSKEW1 is just a time threshold, any value of which is valid for behavior. Consideration of the SDF definition led us to create an artificial cell of type Vitalbuf inside the behavioral model and add delay of this gate to the SDF. In this case we needed two time delays, so we created two cells (gates) with the instantiation names SKEW1 and SKEW2 .

reg BuffIn1, BuffIn2;

wire BuffOut1, BuffOut2;

time tBuffIn1, tBuffIn2;

	Vitalbuf SKEW1 (BuffOut1, BuffIn1);

	Vitalbuf SKEW2 (BuffOut2, BuffIn2);

Unresolved issues

Several unresolved issues still complicate the design of compatible VHDL and Verilog models, often hampering developers from creating truly portable models.

Verilog simulators should show the back-annotated information from the SDF for the specified parameters. Currently, the Verilog XL simulator shows the values assigned to specparams only during their declaration, a habit that is bound to confuse even the most experienced designers.

During the design of these models we used three Verilog simulators: Simucad III, Modeltech, and Verilog-XL. We can't complain about their implementation of the semantics of Verilog constructs, but we faced different procedures of back annotation and different levels of SDF maintenance. That variation prevented us from designing truly portable Verilog models that these simulators could simulate without any changes (to be fair, VHDL simulators suffer the same problem).

It would be useful to extend the syntax of the SDF file with a construct that allows the description of the timing data without reserved meaning. The user could then apply the data towards any purpose, as we have done with skew.

Yuri Tatarnikov is a project manager at Seva Technologies, Inc. in Fremont, Calif. He was the founder and director of the VHDL Users Group in Russia, as well as an author of the hardware description language MODIS-V78, which is the Russian state standard, and the MODIS-VES simulator, which was the most distributed simulator in the former Soviet Union from 1980 to 1989.

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

integrated system design  May 1999