Answers Database

CADENCE 9404: Known problems and workarounds for Cadence Interface to Xilinx


Record #638

Product Family:  Software

Product Line:  Cadence

Problem Title:
CADENCE 9404: Known problems and workarounds for Cadence Interface to
Xilinx



Problem Description:
Keywords: concept verilog 9404 9502 property tnm pads loc fast
slew_rate

Urgency: standard

General Description:
CADENCE 9404, 9502: Known problems and workarounds for Cadence Interface to Xili
nx


Solution 1:

1.  Attributes or properties on pads do not get translated by concept2xnf (TNM=,
 LOC=, BLKNM=, FAST).
--------------------------------------------------------------

The CONCEPT2XNF program does not support properties of any
kind attached to PADs  There are several workarounds,
depending on the property:

	- TNM:	Put the property on the net between the I/O
		buffer and pad instead (ibuf and ipad, or obuf
		and opad)

	- LOC:	LOC properties for I/O pin locations should be
		attached to the I/O buffers instead.
	
	- FAST: To specify a FAST output, attach the property
		to the appropriate OBUF.  The property must be
		designated as either "slew_rate=fast" (name =
		slew_rate, value = fast) or "apr=fast".

		If you use "slew_rate=fast", you also
		need to make a correction in the
		concept2xnf.prop file
		in the install_dir/share/library/xilinx/data/
		directory:
  		
		Add a colon (":") after the the word,
		"SLEW_RATE" in this
		file:

			SLEW_RATE:	;  {FAST MED}
				 ^
				 |_ add colon here
		
2. TNM attributes attached to user symbol bodies do not get
propagated down through the hierarchy of a design.
--------------------------------------------------------------

	Check the XNF file to see if all the symbol pins have
	the correct directionality (I for input, and O for
	output).

	For example, the PIN record in an XNF file for a
	symbol pin should look like this:

		PIN, I		(input pin)
		PIN, O		(output pin)

	The problem is that by default, all symbol pins are assigned
	a directionality of "output" by concept2xnf unless a FLAG body
	is attached to the pin on your schematic.

	When XNFMERGE propagates the TNM attributes, it stops when
	it encounters a pin that has a direction of "O" (for output)
	and does not look for a lower level.  As a result, the TNM property
	      on the upper level never gets expanded down to the lower level
	      primitives

	To correct this, attach a FLAG body to all pins in the underlying
	schematic that are supposed to be input pins.  Concept2xnf will
	      then know to specify the pin direction for these signals as "I" fo
r
	      input.



3. RLOC_ORIGIN and RLOC_RANGE properties in an XNF file
generated from Concept ignored by XNFMERGE
--------------------------------------------------------------

PROGRAM: Concept2xnf

VERSION: 5.1 (9404 release)

PLATFORM(s): SUN

SHORT DESCRIPTION:   RLOC_ORIGIN and RLOC_RANGE properties ignored by Xnfmerge

XNFMERGE:
Warning 260: User parameter 'RLOC_ORIGIN=R0C0' on non-primitive symbol 48P_1
ignored.


LONG DESCRIPTION:

PROBLEM:

The rloc_origin property is usually attached to a user created symbol which has
"rloc"
specifications in the underlying schematic.  Xnfmerge indicates that the attribu
te is
a user parameter and that it will be ignored.

CAUSE:

In the netlist file, there is an extra '=' in front of the attributes.


Example: (RLOC_ORIGIN).
    .
    .
    SYM,48P_1,al_unit, FILE=al_unit_.xnf,=RLOC_ORIGIN=R0C0
    PIN,OFL,O,OFL,
    PIN,CLK,O,CLK,
    .
    .


An "=" sign in front of a Xilinx property indicates that it is either a user pro
perty
(which is usually ignored), or an X-BLOX property.  RLOC_ORIGIN and
RLOC_RANGE properties are neither, so they should not have a '=' prefix.

The "=" prefixes are written to the XNF file because there is an error in the
concept2xnf.prop file, which contains the information used by concept2xnf for
property translation:
.
.
.
USE_RLOC:	  =USE_RLOC=;		{ Xblox }
COUNT_TO:	  =COUNT_TO=;		{ Xblox }
RLOC_ORIGIN:	  =RLOC_ORIGIN=;	{ Xblox } <= Problem with extraneous "="
 prefix
RLOC_RANGE:	  =RLOC_RANGE=;        { Xblox } <= Problem with extraneous "="
prefix
ASYNC_VAL:	  =ASYNC_VAL=;		{ Xblox }
SYNC_VAL:	  =SYNC_VAL=;		{ Xblox }
.
.
.

SOLUTION:

Delete the '=' in front of the RLOC_ORIGIN and RLOC_RANGE
entries in the concept2xnf.prop file directly or delete those found in the XNF f
ile.



4. Verilog-XL simulator unable to recognize signal names declared in lower case.

--------------------------------------------------------------------------------


This may be because the Verilog simulation netlist has
signal and instance names converted from lower case to upper case.

PROGRAM: XNF2Verilog

VERSION:n/a

PLATFORM(s): sun4, hp

SHORT DESCRIPTION:

Verilog-XL simulator is unable to recognize signal names declared in lower case.

This may be because the Verilog simulation netlist has
signal and instance names converted from lower case to upper case.


LONG DESCRIPTION:

PROBLEM:

The problem is usually seen in designs done in Synopsys, when signal
names are declared in lower case in the original Verilog source file.
Case is preserved by Synopsys, syn2xnf, and xnfmerge.
However, if Synopsys happens to target X-BLOX modules in the design,
X-BLOX will convert the lower case names to upper case.

Often, the user will already have a test bench that he/she uses for
behavioral simulation, and this test bench will have all signals declared
in lower case. Since Verilog is case-sensitive, the original .stim
testbench file with the lowercase net names will be useless for simulating
the backannotated .v file, because it will contain the net names in
uppercase characters.


SOLUTION:

The best solution is to only use upper case for signal and instance names
to avoid any of these types of problems in the first place. If a design
does contain mixed or lower case names, use the following command to
change the case:

	>dd conv={ucase,lcase} < {input file} > {output file}

example on converting from uppercase to lowercase:

	>dd conv=lcase < oldfile.v > newfile.v

where oldfile.v is the input file and newfile.v is the output file.



5. Doing block mode designs in Concept (supporting FILE= blocks, Memgen blocks)
-------------------------------------------------------------------------------

PROGRAM:  Concept

VERSION:  v1.7 or later, 9404 release or later

PLATFORM(s):  Sun, HP

SHORT DESCRIPTION:  Doing block mode designs in Concept

ERROR MESSAGE:

chips_prt not found for block, or no schematic found for
block

LONG DESCRIPTION:

PROBLEM:

Referencing non-schematic blocks (FILE=) in Concept

CAUSE:

In the Xilinx Interface to Concept User Guide, there is a
single reference to doing block mode designs in Concept on
p.2-20. This section describes using funcnet to generate the
symbol for a non-schematic block; however, this only applies
to XNF blocks generated by a Cadence tool (from a Concept or
Composer schematic, or from the Cadence synthesis tool, Synergy).

This does *not* work if the XNF file originates from some other
third party vendor, as that party may be using primitives which
the Cadence tools do not support.

SOLUTION:

The procedure you must follow in this (and most) cases is to
create a "parts" file (part_cn) for the block by typing the
following in Concept:
	
1."edit design.part" 	to create a part drawing for the block
			called "design"

2. "add drawing"	to add a drawing body to this part
			drawing

3. "attr"		to activate adding attributes

4. Select the drawing body and add both an "ABBREV = <design>"
   and a "TITLE= d<esign_description>" property to the part
   drawing.

5. do a "write" to save the part drawing.


ALSO:
You will also need to build a symbol body for the XNF block. If
you are using the SCALD methodology, as opposed to making it
VHDL compliant), you will need to add the
property, INPUT_LOAD=*,* to each *input* pin on the symbol. so that the
the direction of the pin in the XNF file's PIN record will be written
out correctly.	Type:

1.  "pr" 		to activate adding properties

2.  click on an input pin to select it.  This causes a rectangular
    box to appear.

3.  type "INPUT_LOAD=*,*" and hit return.  (properties must be entered
    as "name=value" pairs, and *,* is entered as a dummy value)

4.  move the box to where you want the property to appear on the
    page and click again to put it in that location

5.  type "sh pr" to display all the properties on the symbol to
    verify that you have done this properly.


The design is then ready to for processing by concept2xnf.

Note that adding the FILE= attribute is no longer needed for
XNF blocks.


6. Accessing patches
--------------------

Cadence provides software patches through SourceLink on their
World Wide Web site. SourceLink is a customer support information
service for Cadence customers. SourceLink  allows you to directly
access the call tracking database used by CADENCE AE's in the CRC.
This database includes known problems & solutions (KP&S), patches, &
HOT fixes.

SourceLink allows users to search the call tracking database for
an existing solution to their particular problem prior to calling
their CADENCE AE.  The information in this database is up-to-date
within 24 hours. It is available to all Cadence customers who
have a current software maintenance agreement.

SourceLink is part of the World Wide Web and is accessible via the Mosaic
navigator.  Patches are located in the Solving Problems area under
the 9404 "pic" directory.

To access patches from this site,
Connect to the World Wide Web Site:

		http://sourcelink3.Cadence.COM/
Navigate to:

	Sourcelink / Solving Problems / Patches & Hot Fixes / 9404 / pic

The latest patches as of 8/1/95 are:

	xilVerilogLib05.00-s002.t.Z
	xilNetList05.00-s005sun4.t.Z
	PicTools03.30-s004sun4.t.Z

You need to have an account in order to access the patch area on this
web site.



Getting Started With SourceLink
-------------------------------
First, you need an Internet connection and the Mosaic navigator on a workstation
.
Mosaic is in the public domain and is available for the Sun, HP700,
IBM RS/6000, DECstation, SUN Solaris and DEC Alpha AXP platforms.

Copy Mosaic from ftp.ncsa.uiuc.edu via anonymous FTP.
Mosaic is in the /Web/Mosiac/Unix/binaries/2.4 directory.
If you've never used FTP before, ask your system administrator for help.
 >>>>>>>>>>>>>>>>>>>>>>>>>

 How to Sign up for SourceLink

 1.  Start Mosaic
	The NCSA home page appears
 2.  Select the File - Open URL command
 3.  In the form that appears, type
	http://www.cadence.com
 4.  Click on the Open Button
	The Cadence World Wide Web home page appears
 5.  Click on the Service icon, and click on the SourceLink icon.
	You can now read about SourceLink, see a sneak preview, and sign up
	for an	account on-line.
 6.  Fill out the sign-up form, and follow the other instructions you
	receive on-line.

For help in accessing SourceLink, call the Cadence Customer Response Center


7. Cadence Verilog-XL: driving GSR, GR and GTS in Verilog simulation



7. Creating TIMEGRPs in Concept
-------------------------------------------------------------------------------
PROGRAM: Concept

VERSION: 1.7, 9404 release

PLATFORM(s): all

SHORT DESCRIPTION: How to create timegrps in Concept


LONG DESCRIPTION:

	PROBLEM:  There is no automatic support for user-defined
		  timegrps in Concept

	CAUSE: 	  In Concept, a timegrp is specified as a
		  property attached to a TIMEGRP symbol, and
		  only property names defined in the concept2xnf.prop
		  are recognized by the concept2xnf translator.

		  The concept2xnf.prop file shipped with the interface
		  only supports timegrps named "GRP01", GRP02"... "GRP10".
		  Defining user-specified TIMEGRPs requires some
		  additional steps.

	SOLUTION:

1. Make a copy of the concept2xnf.prop file in your design
directory.  The default file is located in

	install_dir/share/library/xilinx/data

2. Add an entry in the local concept2xnf.prop file for each timegrp that you are

going to define

Example:
	LEDPADS:	=LEDPADS=;

This defines a symbol property called LEDPADS which will be written out to the
XNF in the format,

	=LEDPADS=xxxxxx;




End of Record #638