![]() |
|
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
|
![]() |
![]() |
Answers Database
M1.4 Cadence Concept interface: Frequently asked questions![]() Record #2223
Product Family: Software M1.4 Cadence Concept interface: Frequently asked questions Problem Description: 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) describes all the chang es 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 - Last Modified: 04/21/98 12:00 |
For the latest news, design tips, and patch information on the Xilinx design environment, check out the Technical Tips! |