How to use the "set_refinement_resilience" settings after design files are updated.

Hi.

If you created your refinement files before you added set_refinement_resilience, then it's possible that the refinement file has not saved checksums for the refinement, meaning it has no link to the checksums that are stored in the coverage files. Also, the vRefine files do have a setting inside them that determines whether or not to use the checksums, this might be stuck "off" if your refinements pre-date the set_refinement_resilience.

If the hints above don't help, I'd recommend filing a support ticket, as it's likely we'd need to see your actual files, and you probably don't want to share those on the public forum.

Hi Stephen,

Thanks for your quick reaction.

No, I put in the "set_refinement_resilience_setting" when I I was updating the refinement files after more or less the last regression run before the previous tapeout.

Also I do a lot of copy-and-paste work in the refinement files for equivalent modules for which 1 or more pins could be excluded because these are active in e.g. test mode. That WoW goes faster then doing this manually than via the IMC gui (gui updates are sometimes very slow). Therefore I guess that the checksums are incorrect after certain time but I think that once the refinement file is ready I can load it in IMC after the coverage db is loaded and re-write the refinement file (new file) in which all checksums are updated,

Questions:

1. Can the checksums be rewritten when saving the refinement files on a certain release of the design (so save the exclusions to a new refinement file when ready?)

2. Regressions were run with the "set_refinement_resilience" set in the .ccf files, does this mean that by rewriting the refinement files (via IMC) the checksums are updated in the saved (new) refinement files and could become a fresh new start for the next design release?

3. Off-topic question: if I excluded a toplevel signal which has connections downwards in design is there a possibility that all lower level 1-to-1 pin connections are excluded automatically too? This would be very useful & save quite some work!

Hmm... So are you editing the XML vRefine file when you "copy and paste" or are you entering the exclusions in Tcl and using IMC to convert those to vRefine XML? If you edit the XML directly, I am not expecting the refinement resilience to work at all and I honestly don't know how the tool would react to hand edits when the checksums are involved.

That said, if there are checksums in the XML and you haven't suppressed them with the XML flag to turn off checksum checks, then I would have expected warnings in the GUI about "orphan" rules whose checksums don't match the RTL. If you don't get any orphan rules then it's likely that you've disabled the checksums inside the XML. If this has happened, I don't think IMC would recalculate the checksums and update the XML (answering your point 2). Can you look for the text "<information csCheck=”true”/>" in your vRefine; if csCheck is not there or is false, you're not using the checksums.

As regards the slow GUI refresh when doing exclusions, this was a known problem because the GUI recalculates all the grades hierarchically after every exclusion. We added a toolbar button to "freeze" the grade calculations so that when you're making lots of exclusions you turn off the updates, and once you're done and want to check the grades you un-freeze it. I don't immediately recall which version we added that feature; if you don't see the button in the GUI you might try updating to a newer MDV (imc) package, you can do this without re-running simulations, as the simulator and IMC versions are decoupled.

Hi Stephen, when doing a grep in all my (manually edited) .vRefine files I see indeed csCheck="true" in all vrefine files.

Yes, I edit the .vrefine files by hand when I want to add equivalent excludes for the same type of modules with different labels (off course). This works faster then doing this all the way via the IMC gui which reacts slowly and takes a lot of time to do it in the official, correct, way.

Yes, I am getting "orphan" warnings when after a design update, followed by the subsequent regressions and building a new coverage db, I read in IMC the created refinement files based on the previous design release.

So, in my refinement files the checksums are enabled and  when doing the following steps:

1. Load in IMC the coverage db;

2. Read in the (manually edited) refinement file in which the checksums are enabled;

3. Solve all the orphan warnings (combination of manual edits and/or edits via IMC);

4. Add new excludes, delete excludes of removed RTL, done manually by editing the refinement file but also via the "dirty rules" possibility in IMC;

Then the question is, if after all manual edits and/or edits via IMC are done, I load once more the refinement file & save consecutively all excludes in a brand new refinement file if that new file contains the correctchecksums. from that moment on updating the refinement files should by done via IMC (if the reaction time issue is improved).

Regarding the "Freeze" button I see indeed a "Freeze Exclusions" button and when pushed I hoped to see that when I select a (sub) module from which I want to select the block, toggle or expression I hoped that these views were produced faster. Sofar, I cannot see an improvement regarding reaction times.

But maybe I should start IMC again, load the refinement file, freeze exclusions and continue adding exclusions.

Hi Peter.

Sorry, I missed the notification of your last reply. So if the freeze GUI button isn't helping, I'm going to guess that you're suffering because of a know problem in the interaction between IMC's GUI widget library and remote desktop software. We've seen this on a few customer networks, particularly with Exceed on Demand, and it appears to be a problem with an interaction between the GUI's animated effects / redraws, and the image compression technology in the EoD X server. We have an app note describing the system settings that you need to use to cure this, perhaps you can check it out and see if it helps? IMC performance with EoD

As regards the resilience flow itself, what you're doing is so far from any supported use model that I honestly have no idea if it would ever work! 

Hi Stephen,

Last week I raised a ticket at Cadence about the usage of the set_refinement_resilience option, sofar I updated my refinement files via the IMC gui. to assure that manual edits to these files are moved out by writing the files after the last updates.

In that way I see no warnings about manual edits anymore when loading the refinement file in IMC. So I guess also that the checksums are updated when writing finally the refinement file out. Sofar I noticed that the checksum is updated.

However when loading the clean refinement file on a covergage db coming from a newer design release I still am confronted with orphan errors. I sent my findings to Cadence and I hope after the weekend to get a clue how to circumvent the orphan error problem.

I am still confronted by the slow responsiveness of IMC even when I use the freeze button so also that problem is still not solved. I will take a look at the link you put in your last message, sofar Cadence support did not mention to the app you are referring to. Sofar they only the explained the freeze button usage.