Extracting_from_Allegro 转换到PADS

2013年10月19日 13:32
评论(1) / 浏览(2276) / 下载(0)


Quick Guide to using the Allegro to ExpeditionPCB translator.

Nigel Aves, September 2004.

File History

(Rev A)      Extracting data from Allegro







General Note.

The SKILL scripts are common to both Translator and DFL-mode. However, the SKILL script does take longer to execute in “One Way” mode, the reason for this is that it’s important that the “cell” information is created with all cells at “0” degree rotation.  Because of this (and in the One-way only SKILL) we check to ensure that all the required information is at “0” degree and if it’s not we automatically place a cell at “0” degree rotation for extraction. (This limitation does not exist for DFL-mode).


The Allegro side of Translation.

Load the Allego.brd file that needs to be translated into Allegro. The SKILL scripts supplied with the release already have built in the ability to generate the files required to run the translator. After loading the SKILL files instead of DCAD OUT you must use MAIN OUT.

skill load “dfl_main.il”

main out



Choose “One Way” from the dialogue.

When the following dialogue appears


choose “Cancel” . The Via Identification File is used as a “last resort” to manually specify the padstack names of vias, fiducials and mounting holes. Typically this file is not needed now as we have spent a lot of development time identifying these objects automatically.

Once the SKILL script has finished running you will find that it has create the required _MGC directory and all the needed files for the translator. (Under no circumstances must the devices directory be moved or deleted, this is the directory that contains all the electrical data that the PDB is built from. It’s also worth mentioning that designs should be translated from different root directories to ensure that only the devices for that design are in the \devices directory)


Extracting the rules_tmp.dcf  and ecsetaudit.rpt

Major changes have been programmed into both DFL-mode and the translator for the translation of High Speed rules. Cadence has adopted the Electrical Spreadsheet as their de-facto standard for entering these types of rules. Because they are more complete and understandable we are now adopting the ability to read an extracted (exported) electrical spreadsheet.

To do this :-

1/ Setup >> Electrical Constraints Spreadsheet  << In Allegro (Designer or Expert)

2/ File >> Export >> Constraints  << Constraints Spreadsheet

Please note that this file should be written into the \work directory just created by the initial SKILL scripts. The file MUST be called rules_tmp.dcf

This file contains all of the High Speed rules and defines all pin pairs with rules. From this file we are able to extract “Electrical Nets” and from this we are able to process any rules against these nets. The downside of process Electrical nets is that the formulas dialogue becomes almost impossible to comprehend.

3/ Audit >> Electrical Csets   << Constraints Spreadsheet

Please note that this file should be written into the \work directory just created by the initial SKILL scripts. The file MUST be called ecsetaudit.rpt (this is the default name no matter what the job is called)

This file contains all information that we need, to correctly set the topologies on a net if it has been created using SpectraQuest.

You have now finished all of the tasks required on the Allegro side.



 Workaround Corner

We have discovered a problem on certain designs where ExpeditionPCB thinks there is a miss-match between the number of pins on a cell and the number of pins reported in the PDB editor. This causes a problem if trying to edit a cell, as it will not allow you to save the cell. (A real pain if you have spent ages editing it!).

Workaround 1. Go into the PDB and manually change the active cell name by appending an ‘_X’ to the end. Save and Exit. This will cause an error to be reported during forward annotation, ignore the error. Open up the cell for editing in cell editor and perform a save. Re-open PDB, change the cell name back to original, Save and Close, all OK.


However, if you have more than two or three cells exhibiting this problem then follow this procedure.


Workaround 2. This is worst case because you need to start the translation from the beginning again. Import the padstack.hkp as normal and then close down the Import ASCII dialogue. Under “Setup” choose Library Services. This will pop-up a dialogue that allows you to also import the cell.hkp and pdb.hkp. Bring the cells in first and then the PDB. You’ll discover that by using this method there are no issues with the pin number miss-matches. 


Notes on the generated PDB

All the information gathered for generating the PDB comes directly from the Allegro database. This can cause problems if the PDB is to be shared and placed in a central Library. Because the PDB is generated from the Allegro database directly all the signal names associated to pins is from that design, therefore it is not a generic PDB. At the present time there is no workaround for this limitation so after the design is translated but before merging with a central library please spend time editing the PDB and correcting any issues.

If the design is front ended from DX_Designer then it should be possible to use the PDB driving the design. Ensure that all the required PDB entries are in the Central library and then run a forward annotate. 




We have an outstanding issue that in Allegro they define “0” sized pads, we have not corrected all of the possible cases, what we do is make them as small as possible (1 DBU) and put a message in the log file.

HKP error messages are not the best in the world; sometimes you get an exact line number and other times a section is reported. Read the message carefully and try to find the error. Beware of editing HKP files. These files must contain NO formatting errors.

Typical errors are when we have a padstack defined but used as multiple types (mounting hole, fiducial, via, padstack). This is the most common of problems found when importing padstacks and cells. The best solution is to copy to a new name (Round020_MT from Round020) and then make the required changes to the cell.hkp file. (Typically you can import the padstack.hkp and make these changes using the Padstack editor in ExpeditionPCB. Now you can run the cell.hkp and from the messages easily track down the padstacks that need to be changed.)


If this is your first experience with 2004(.1) – DFL-mode; please note that the SKILL scripts must now be run from an Allegro recognized SKILL directory. This can be the active directory that the .brd file is located in or typically the Allegro generated directory PCBENV .


During the translation process the cells generated do contain all the relevant information from Allegro. (Notes etc).


To successfully translate a “board outline” the element in Allegro must be contiguous, unfortunately we have discovered many designs where this is not true. Please check the board outline in Allegro to ensure that there are no gaps.



1楼 评论时间:2015年9月2日 21:30 回复


  • 评论
allegro × 67
PADS × 44
转换 × 2

浏览(1120) / 评论(2) / 2013年11月26日 10:23

浏览(6832) / 评论(5) / 2013年10月19日 13:42

浏览(2268) / 评论(0) / 2013年10月7日 11:31

浏览(850) / 评论(0) / 2013年10月17日 12:09

浏览(1196) / 评论(1) / 2013年10月22日 12:38

浏览(1157) / 评论(0) / 2013年10月29日 21:56

浏览(1301) / 评论(0) / 2013年10月25日 15:20

浏览(866) / 评论(0) / 2013年10月29日 14:16

浏览(3365) / 评论(0) / 2013年10月7日 11:46

浏览(1495) / 评论(0) / 2013年10月17日 13:00