Compare the database footprint with library footprint -Skill

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 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.

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))

Bruekers,

Could you please share the full skill code.

Thanks,

Pradeep

Has anybody seen inconsistent results with fileTimeModified()?

Using timeToString(fileTimeModified(axlOSSlash(<valid path to PSM file>))) I see some results match between all computers and some have an off-by-one-hour issue. I suspect it's due to daylight savings time here in the US, but I can't figure it out. The actual file save date is correctly returned on some PCs for a file saved in August, and on others the returned value is one _exactly_ one hour later.

It turns out that the different is 17.2 vs 17.4. 17.4 appears to have fixed the issue. However, Cadence no longer provides a list of functions that were changed (or added or new) with each Allegro version and they tell me there's no change, no it's a mystery. Certainly the support answer of no change does not reconcile with my experience running the functions on the same PC and getting different results under 17.2 and 17.4...

HI Is it possible to share this code at all, Thanks