I would like to generate the comparison report of database footprint with library footprint if any mismatch available.
Is there a way to take if it possible means can anyone please guide me or share me the skill code please.
I'm also interested in doing this but I don't have the solution either. Not all of it, anyway.
One way would be to put a property in the library footprint, like "V1.0" which is incremented when the footprint is touched. But that seems like more hassle than it's worth and doesn't guarantee that property is always maintained properly. So my strategy would be to find the date/time the footprint was added to the board and compare with the save date/time of the library footprint.
One required piece is knowing when a footprint was instantiated in the board. Querying properties of a component, and it's compdef, I don't see anything that reports the timestamp that could help with this task. Sorry.
The other piece is figuring out the timestamp of the library footprint. This isn't bad. The footprint's DBID gives the package name while the footprint path can be found from axlGetVariable("psmpath"). Don't forget that multiple paths can be given in that env var. From this the absolute path to the library footprint can be built. Be careful to note that the type of footprint changes the file extension (PSM, BSM, etc.). Finally fileTimeModified() gives the library footprint's timestamp. So that piece is relatively easy and gets us halfway there.
I've ever implemented such timestamp check, but it is far from fail-safe. There are possible differences of 1-10 seconds (PSM filetimestamp =! version_id), and even 3600s if you are lucky.
The biggest issue is that when the PSM files are loaded in the a BRD the padstack (and ssm's) are loaded from the external PAD/SSM files. If these files have been changed between DRA release and starting the BRD, the symbol which is actually placed in the BRD file shall not the same as the original DRA. So, the actual padstacks inside the PSM/DRA files are not used (only name,xy,rotation).
I believe the best way is to make some sort of metadata file of the actual DRA file, pin locations, padstacks, props etc. (do this at the moment of saving the DRA file)
Then this data can be used to check the placed symbols in a design. Another advantage is that when the symbol has a new savedate your footprint check can still pass.
If you have time to spare then you can even implement some sort of severity level; change on pin location/padstack = high, assy layer = low. etc.
I was stupidly looking at the components and compdef list, when I should have been looking at symbols and symdef list. Each symdef has the following properties: VERSION_ID and LIBRARY_PATH. Those have the information I was looking for.
algroskill.pdf says that VERSION_ID is used to tell if a symbol needs to be updated. I find that it's the save date of the footprint file, which is not when the footprint was instantiated on the board as I guessed. But that's still a piece of information we can work with.
I do see minor variation of the VERSION_ID versus the modified date of the library footprint if they should be the same, but only by a few seconds. Enough to ignore with high confidence that all will be well. Alternatively if I place a footprint, then update the library footprint, I find the VERSION_ID timestamp of the symdef in the board and the result of fileTimeModified() on the library footprint are different. So that's the other part we need to make this work.
Now moving onto the reply that was posted earlier...
I see how that could be a problem, but I expect it's good enough for me. We have a library structure where a development and test library is pushed to various production locations, so there is adequate delay between a footprint being saved in the library and then being able to instantiate it in the board that I don't see a problem. Or else I've misunderstood the possible severity of the issue you're sharing.
I will start with a simple implementation and see how it goes. My rough code seems to be working OK but it may turn out there are issues with more widespread use of the code.
This biggest issue with the footprint mechanism of Cadence is that the padstack figure data is not taken from the PSM but from the actual padstack files. You can test this, try to place a PSM file without any padstack library defined. It will raise errors about missing padstacks.
So, lets say you create a footprint today. What you see in your footprint editor is what you will get on the board(s).
But, if somehow the padstack file (PAD or SSM!) is being altered next week then, from this week, all new board designs that use this footprint, will have the altered padstack as well.
And the 'fun' part is that if you open the original footprint DRA you will still see the old padstack. Once you do a refresh of the padstack/shape symbols in the footprint editor you will see suddenly the new padstacks.
So back to the filedate vs. version_id,
The minor difference is the time difference between creating the actual psm data in memory (which sets the version_id value) and writing it to a file. So if you store these files on a network location the time stamp can differ more than when saving it to a local drive.
To minimize the false-calls I've implemented a 2nd step. If the filedate and local version_id are more than 10 but less than 3600s apart then i use extracta to extract the actual version_id from the PSM file.
extr_opt = axlDMOpenFile("ALLEGRO_TEXT", axlTempFile( t ), "w") fprintf(extr_opt "BOARD\nVERSION_ID\nEND\n")fname = get_filename(extr_opt)axlDMClose(extr_opt)
foreach symbol definition:
LibFile = or( axlDMFindFile("ALLEGRO_PACKAGE_DB" SymDef->name "r") axlDMFindFile("ALLEGRO_SHAPE_DB" SymDef->name "r") axlDMFindFile("ALLEGRO_FLASH_DB" SymDef->name "r") axlDMFindFile("ALLEGRO_MECHANICAL_DB" SymDef->name "r") axlDMFindFile("ALLEGRO_FORMAT_DB" SymDef->name "r") )
cid = ipcBeginProcess(lsprintf("extracta -q -s -k -r \\\"%s\\\" \\\"%s\\\" " LibFile fname))ipcWait(cid 5 5)lib_verID = atoi(ipcReadProcess(cid 20))
Could you please share the full skill code.