Answers Database

M1.4 Cadence Concept interface: Frequently asked questions


Record #2223

Product Family:  Software

Product Line:  Cadence

Problem Title:
M1.4 Cadence Concept interface:	Frequently asked questions


Problem Description:
Keywords:  hdl direct, concept, concept2xil, concept2xnf, unified,
	   size, iterated, instance

Urgency:  Standard

General Description:

This solution answers some commonly asked questions about
the M1 Cadence/Xilinx interface.


Solution 1:


> 1. Why do we need to convert existing XACTstep 5.2.1
> Concept design files to the M1 Concept Unified Libraries
> before using M1?  Aren't they both Unified Libraries?


ANSWER:

The libraries in the two releases are actually different.
Whereas the XACT 5.2.1 / Cadence 9404 through 9604 releases
supported both the HDL Direct and SCALD methodologies AND the
SIZE property, M1 Concept Unified libraries only support
HDL Direct Methodology, and do NOT support SIZE at all.

If you need to make use of XC4000X architecture-specific
features, you will need to use the M1 libraries with
CONCEPT2XIL because 4000X is not supported by this pre-M1
Concept interface.

If you are only targeting 4000E and 5200 designs, you can
continue to use the pre-M1 Unified Libraries with the
CONCEPT2XNF netlister.



> 2. Is "concept2xil" distributed by Cadence or Xilinx?
> Do we need any license to use this translator?


ANSWER:

Cadence is currently distributing this netlister,
as well as the XIL2CDS board level simulation support utility.

CONCEPT2XIL, XIL2CDS, and their subprograms use a Concept
schematic editor license.



> 3. Does Cadence 97A include "concept2xnf" support?
> If it is included in Cadence 97A, which families does it
> support?


ANSWER:

Concept2xnf and the pre-M1 Unified libraries for Concept
will continue to be shipped in 97a, and will be treated as a
separate vendor in the Cadence interface.  It will exist
in a separate area from the M1 libraries and the
concept2xil/xil2cds netlisters.

This pre-M1/XACT version of the interface will
continue to support the same families it already does
at this time--2k, 3k, 5k, 7k, 4k/e/l.  (There is also
tactical support for 9k on the Xilinx ftp site.)
However, there will be no new support added for XC4000X or
any other architectures released thereafter, and only
limited bug fix support.


> If it is available in 97A, can we use "concept2xnf" on
> designs which do not use LogiBLOX?


ANSWER:

LogiBLOX is really not the only limiting factor here--
you must also be translating a design which is targeting the
XACT (pre-M1) Concept Unified libraries.



> 4. Why isn't the SIZE property supported in the M1 software
> flow?


ANSWER:

Xilinx had to support the HDL Direct methodology to be
consistent with directions in Cadence's technology. There
were issues with the SIZE property when used in conjunction
with the HDL Direct methodology.

Cadence recommended that Xilinx not support the SIZE property
because it would require that all the simulation
models be rewritten from scratch, using bit-wise operators
to comply with HDL Direct requirements. Doing this would have
slowed down simulation compile times considerably because
more time would have to be spent expanding these bit-wise
operations.  Moreover, an alternate technique to achieve the
same functionality was available in the form of Iterated
Instances.



> 5. If we use HDL direct, what do we need to do with
> existing macros that depend on the SIZE property?


ANSWER:

In a design using HDL Direct methodology, any Xilinx
LIBRARY macros will just need to be retargeted to the M1
Concept library counterpart, which will have the appropriate
("SIZE-less") implementation.  This is just a matter of
modifying your master.local and global.cmd files to point
to the M1 Concept libraries.  (The global.cmd file must
be modified as well because the names of the libraries
for the same architectures are different from those in
the pre-97A/pre-M1 releases of Cadence and Xilinx software.)

USER macros:
You must convert these manually by removing all references to
SIZE properties, and you must use the ITERATED INSTANCE
methodology instead.  The ITERATED INSTANCE methodology and
other changes required to convert SCALD designs to HDL Direct
compliance is documented in the Cadence HDL Direct User Guide,
as well as the Cadence conversion guide on the Xilinx web site
(exact location indicated at the end of this document).

You should NOT be using the SIZE property at all if you are
using HDL Direct methodology and the M1 Concept libraries.



> 6. Are there any other restrictions we need to be aware of
> with respect to the HDL direct flow? (For example, illegal
> characters and components?)
>
> What about \G extensions for global signals, FLAG bodies
> and \I extensions for interface signals, and MERGE bodies?


ANSWER:

You must follow Verilog naming conventions and HDL Direct
Methodology rules (see conversion guide and HDL Direct User
Guide section on Converting SCALD designs to HDL Direct).

The use of \G extensions for global signals, FLAG bodies
and \I extensions for interface signals, and MERGE bodies
for creating buses out of individual nets and buses
corresponds to the SCALD methodology.

In HDL Direct methodology,

- global signals use a "/" prefix
- INPORTS, OUTPORTS, and IOPORTS from the "hdl_direct_lib" are
  used to mark the signals that interface between different
  levels of hierarchy
- CONCAT bodies from the hdl_direct_lib library are used
  instead of MERGE bodies from the standard library.

See the HDL Direct users guide for more information on this
topic.



> 7. A previous version of the M1 Conversion Guide specified
> that "concept2xnf" had to be used to translate existing
> designs.  Is this still correct?


ANSWER:

The earlier, m1.1.1a version of the M1 Conversion Guide
described a WORKAROUND for processing existing Concept
designs using a combination of CONCEPT2XNF and the M1 core
tools. This was the recommended flow at the time because
the M1 Cadence interface translators and libraries were not
available at that time, and is still a valid flow in M1.

In the M1.2.11 release and thereafter, if you do not convert
your designs to the M1 Concept libraries, you can continue to
process these designs using CONCEPT2XNF.  What you lose by not
converting your design is support for XC4000X-specific
features, and the ability to generate a Verilog netlist
for your design directly from your schematics, after a single
pre-processing step using CONCEPT2XIL, the M1 Concept
netlister.



> 8. Can we develop new designs using existing pre-M1 designs
> as a starting point?


ANSWER:

The only way to do this is to first retarget the original
design to the appropriate M1 Concept architecture library.
You should not mix pre-M1 libraries with the M1 libraries
in the same design.

For example, if the design is for an XC4000E device, you must
retarget the design to the Concept xce4000e library in your
global.cmd file.  The pad library (xpads_hdl or xpads_scald)
must also be retargeted to the M1 Concept "xcepads" library,
and you must also include the hdl_direct_lib library in your global.cmd as well.


You must also update your master.local file to point to
the location of the M1 Concept libraries for your target
architecture.  Open up each sheet of the design in Concept and
rewrite (re-save) each sheet to update your design.

After that you should be able to add whatever new logic
you need to the design. The (Xilinx Manual Cadence Interface/Tutorial Guide) des
cribes all the changes needed in
detail.

The Cadence appendix to the M1 Conversion Guide can be found
on the Xilinx Web site at:

    http://www.xilinx.com

Select: Answers - Expert Journals - Cadence - Announcements.




End of Record #2223