Capture to Allegro Interface

1. Capture to Allegro Interface Tim Brandis and Moji Friedholf

2. What is the Capture to Allegro interface? • Before the 9.2.1 release, Capture used the third party interface to create a netlist, a unused pin list, and many device files. • With the 9.2.1 release, Capture uses a modified version of the Concept netlister (called PXLLite) to produce three ASCII files. • The new interface does not use device properties, instead all the part properties are placed into the PSTCHIP.DAT file. • All of the net properties are included in the PSTXNET.DAT file. • The PSTXPRT.DAT file (the expanded part list) lists each reference designator and the sections assigned to it.

3. CONFIGURATION FILE • The configuration file specifies net, part (function), component instance and component definition properties. This mapping determines which properties may be netlisted from Capture to Allegro or back annotated from Allegro to Capture. If a Capture property is not included in the configuration file it is not passed to Allegro. Similarly, if an Allegro property is not listed in the file, it does not get back annotated to Capture. • The configuration file is divided into four sections, written in a Windows .INI format. • ComponentDefinitionProps Allegro component definition properties, output in PSTCHIP.DAT file • ComponentInstanceProps Allegro component instance properties, output in PSTSPRT.DAT file • netprops Allegro net properties, output in the PSTXNET.DAT file • functionprops Allegro function properties, output in the PSTXPRT.DAT file • You can have many different configuration files. All you need do is specify which file you want to use in the Setup dialog box. • A list of typical properties used with Allegro may be found in the Capture-Allegro filter of the property editor. This filter is built on the PREFPROP.TXT file, which is copied to your Capture directory during installation.

4. Why did we make the change? What do we get with the new interface? • The third party interface gets the job done but the connection between the schematic and board file is tenuous at best. Back annotation was unstable and would often crash. • The third part interface was quite lax in checking for correct properties and could create a netlist that would require a lot of work to bring into Allegro. • The PXLLite interface allows Capture access to a robust back annotation process, design reuse modules (for 14.1), and constraint management (for 15.0).

5. What are the costs of the new interface? • Tighter integration with Allegro requires that a lot more work occurs on the front end. In the old interface this work would be done at the Allegro end. • Use of Concept style netlister requires the user to deal with legacy Concept/Allegro integration issues. • The interface is still, in many ways, in its infancy. Issues are appearing as more an more customers create netlists from real world designs • Our customers (and the support engineers) have to learn a new interface that has completely different requirements.

6. What are customers going to see that are familiar with the old interface. • Boards that use to work in 9.2 will likely be unable to run through the new interface without a number of errors. • Engineers on the schematic side are going to be spending more time creating netlists since the interface is nitpicky. • Engineers on the board side are going to be spending less time fixing problems with the netlists. • If a customer has made significant investments in creating libraries to work with the third party interface are going to have to rework their libraries.

7. What are the major problems? • DEVICE properties dealt with differently between the two interfaces. (Errors: Alg0011, Alg0013, Alg0014, Alg0016) • Parts with multiple power pins that have the same name are going to cause errors. (Errors: Alg0045, Alg0050) • Parts without pin numbers will cause errors. (Error: Alg0031)

8. DEVICE properties • Problem: • The third party interface all parts had to have a DEVICE property that would specify which device file the part information would end up in. In most cases all parts that shared the same PCB footprint would share the same DEVICE property. • The PXLLite interface considers that all parts with the same DEVICE property are the same part. • Consequence: • If a customer has setup a design for the third party interface and they netlist it in the PXLLite interface all parts that share the same device property but are not exactly the same will flag and error. • Solution: • Remove the device properties from the design

9. Power pins with the same name • Problem: • Concept requires that all power pins on a part have unique pin names. • Consequence: • This was not a requirement in the old interface and has never been a requirement within Capture. Many parts in the Capture supplied libraries are actually build with multiple power pins that are the same name. • Solution • An ISR has been released that fixes this error.

10. Parts with no pin numbers • Problem: • The PXLlite interface requires that all parts have pin name and pin numbers. • Consequence: • This was not a requirement of the old interface and customers may have spent a lot of time creating libraries that will not work with the new interface. This is primarily a problem with two or three terminal devices. • Solution: • Go into the library and add pin numbers to all pins on all parts.

11. Other issues that may come up • Parts with conflicting value of Power Pin visible. • Lower case reference designator names crash Allegro netin. • Primitive names with trailing spaces • Parts with no pins cause netlist error. • Power pin visibility. (Error: Alg0048) • Invalid Characters. (Error: Alg0037, Alg0038, ALG0051, Alg0052) • All pins on the part are power pins. (Error: Alg0053) • No Connect pins: (Error: Alg0049)

12. Invalid Characters • As per latest doc of ConceptHDL Library Reference Manual, the following are invalid character for pin names as well as net names in Flow: PCRNUM 403634 • 1. All Extended character set • 2. / • 3. ; • 4. ! • 5. < • 6. > • 7. : • 8. \ • 9. " • 10. , • Currently if we see Capture-Allegro flow few of these chars are valid too Ex: <, >. • Once if we start supporting Vector pins, < and > will become invalid chars in pin names.

13. When in doubt use the help • The online help for this release is quite good. Reasonably clear descriptions and a number of good examples. Pretty much anything you might have a question about is covered in the manual.