Answers Database ** OBSOLETE ** VERILOG-XL: 4000E setup/hold violations on WCLK Record #955 Product Family: Software Product Line: Cadence Product Part: xnf2verilog Problem Title: ** OBSOLETE ** VERILOG-XL: 4000E setup/hold violations on WCLK Problem Description: Extraneous timing violations on the WCLK pin of the 4000E dual port and synchronous RAM components may be flagged on XC4000E Verilog netlists generated by versions of the BETA ES-Verilog interface for the 4KE and 5K architectures downloaded before March 13, 1996. There were two bugs fixed in the archive made available on March 13, 1996. 1. The first was a bug in the modeling of the delay of the clock net connected to the 4ke RAM WCLK pin in the ram16x1d.v, ram32x1d.v, ram16x1s.v, and ram32x1s.v models. There are two delays associated with the net connected to the WCLK pin on these RAM symbols. One delay is associated with the output PIN of a buffer that sources the net going to the RAM WCLK pin, and the other delay is the delay associated with the RAM WCLK "PIN" record. CLOCKNET | | --------|>-----------------|WCLK | BUF delay1 | | +------------+                                 RAM                              |<--delay2-->|        XNF for "BUF":        SYM, buf_name, BUF, LIBVER=2.0.0,        PIN, O, O, CLOCKNET, delay1       XNF for "RAMD" (or "RAMS"):        SYM, ram_name, RAMD LIBVER=2.0.0,        PIN, WCLK, I, CLOCKNET, delay2 XNF2VERILOG incorrectly lumped delay1 and delay2 together as the net delay of the net attached to the WCLK pin, when in fact delay2 is actually part of the block delay through the RAM itself. The addition of delay2 to the setup requirement value caused the clock signal to appear slower than it actually was. The correct interpretation of the delay on the WCLK pin is to treat it as part of the *block delay* from the WCLK pin to the DPO and SPO pins, according to the XNF Specification v6.0. It is *not* part of the WCLK net delay. 2. The second was a bug in the timing checks was that setup and hold violations were flagged against the data and WCLK pins in the 4000E synchronous and dual port RAM models even when the WE signal was inactive. The models were fixed in the archive dated March 13, 1996. Solution 1: To fix the problem, you must either download and install the latest version of the esv4ke5k.t.Z.uu archive from ftp.xilinx.com, which should be dated March 13, 1996 or later, or install the 9504 release from Cadence. The esv4ke5k.t.Z.uu archive contains : a. xnf2verilog v9504-1.30v or later b. revised synchronous and dual port ram models-- ram16x1d.v, ram32x1d.v, ram16x1s.v, and ram32x1s.v --which have a revised timing check section (1 has been changed to -1 in the $setuphold function call argument lists for the hold value multiplier). These models are also available in the ES-Verilog archives found on the XACTstep v5.2.1 Core Tools for Sun and HP workstations. c. Verilog-XL must be invoked using two special options, +neg_tchk and +splitsuh, so that Verilog-XL will accept the negative delay values used in the corrected timing model. On the Sun4 platform, a patched version of Verilog-XL, v2.2.8, is required to fix a core dump problem when the +neg_tchk option is specified. The core dump problem when Verilog-XL is invoked with the +neg_tchk option is specific to the Sun4 version of Verilog-XL and was not a problem on the HP version. The Sun4 version of the Verilog-XL patch is included in esv4ke5k.t.Z.uu. The problem is also fixed in the 9504 release from Cadence--this includes the fixed version of xnf2verilog, the ram models, and the Verilog-XL executable. If a configurable version of Verilog-XL is required, you must download two additional archives and install these instead of the Verilog-XL executable in this archive (SunOS executables):      vconfig03.23-p007sun4.t.Z.uu      verilogxl02.20-s018sun4.t.Z.uu End of Record #955 - Last Modified: 11/22/96 18:40

For the latest news, design tips, and patch information on the Xilinx design environment, check out the Technical Tips!