I'm reasonably certain the answer to this question no, but will pose it anyway, hoping to stimulate some thought.Can an attachment (axlDBCreateAttachment) to a symbol be accessed in the design where the symbol is referenced?We know that an attachment can exist in a .dra or .brd file. It appears as the axl*Attachment functions only support accessing the attachment at the same level where it is created.Attachments look to be a very interesting vehicle for several purposes. One thought was to use them to manage revision history. In a scenario such as this, it would be useful to interrogate the design in which the symbols are placed and peruse their revision attachments. But it appears as if you would have to dump the symbols and then open each of the .dra files. Not a pleasant thought.Anyone have any additional thoughts?
Hi Charlie,How have you been? I thought about somthing like this a few months back, but never got the time to investigate this.I believe you if you say that you can't access symbol level attachements, which in a way is in line with the hierarchy architecure for Allegro platform tools. What I mean is that once the symbol is instantiated, it becomes a different component with unique attributes etc. Kind of like hierarchical block in ConceptHDL.A solution could be to create an attachement in the board file that tracks all components by refdes and their respective symbol revision. In other words, after you placed a compmonent you go out and find the revision of the symbol (where ever that comes from; i.e File system like ADW or systems like Windchill or Agile ;-)) add update the brd revision attachment list. Similarly you then can write startup routines that check the database symbol revision against the PDM system.Think about linking padstacks, shapes and all the other good stuff and you have a pretty good solution in place that ensures consistent symbol usage.I'll investigate this a bit over the next weeks and let you know if their is a way in SKILL to access this type of info. This shouldn't be to hard to do.Andy
As a followup to this, it does appear as if the attachments are actuallly NOT carried forward from the symbol into the design. if the symbols are dumped from the design, the resulting .dra contains no attachments, even though the original .dra file did.Andy,Yes there are a number of other ways to track revisions. We are currently doing that today and have been for many years. We can tell the user today that they have out-of-date symbols by comparing the library revs with the revin the database. What is doesn't tell them is exactly what changed from revision to revsion (the history). We were hoping to embed this within the symbol itself using the attachment. We can extend the functionality using additional properties and scripts. This just looked to be an intriguing solution.Let me know if you find anything useful.
While attachments are carried from the dra to psm they are not imported into a board when the symbol is loaded into a design.
Are the any thoughts of changing that behavior?
There have been no requests in this area.
PCR 4015565 has been filed to request this enhancement. If there are others out there that would see value in this addition, please add you names to the list. Here is a description of the requested PCR.Description: Attachments made to symbols using the axlDBCreateAttachment function arenot carried forward into the parent design. If we dump the librariesfrom a design, the resulting .dra file do not have the attachments, eventhough they were in the original symbol when it was created andsusequently placed in the board.We would like to see this functionality implemented. Specifically, wewould like the attachments to be made available in the symbol defintionobject in Allegro and the axlDBGetAttachment function to be updated toallow a symbol DBID object to be passed to allow the retrieval of theattachments on that object. This would require that theaxlGBGetAllAttachments function be enhanced to allow similarfunctionality.
This is great. Thanks Charlie. Count me in!