Abort current Command in Encounter-Console

Hello,

There is no way to suspend a running command to check the status of a run.

Perhaps you could use commands in prototyping mode to understand/guage your design status before launching a more detailed job.

What command would you like to suspend?

Regards,
Elvis

Hi,

Thanks for the quick reply.

It's mostly NanoRoute. For example, when the numer of drc-violations stays constant over 6-7 iterations or when you changed your floorplanning and thought you had made room for routing and suddendly, the drc-violations tripple or something like that.

I know, that I can tell NanoRoute to brake the routing, when it encounters too many violations or tell it the exact number of iterartions to run. But to do it that way is very inconvenient and time-consuming. It would really like to have the opportunity to let NanoRoute run with 'full force' and then just interrupt it, when I see, that it is hardly making any progress.

You already answered my question, so this is rather a hint for the developpers ;-)

Bye

Hi PNR,

If you are not already doing the following, it can help:

generateTracks
globalRoute
setNanoRouteMode -drouteStartIteration 0
setNanoRouteMode -drouteEndIteration 1
detailRoute
saveDesgin dr1.enc
setNanoRouteMode -drouteStartation 2
setNanoRouteMode -drouteEndIteration 19
detailRoute
saveDesign dr19.enc
setNanoRouteMode -drouteStartIteration 20
setNanoRouteMode -drouteEndIteration default
detailRoute

#set back to default, if not eco route (e.g. in Celtic flow) will not work!
setNanoRouteMode drouteStartIteration default


After saying this, I ready miss the little program that companion Silicon Ensemble. Siliocn Ensemble can write out a db every few minutes, and that little program can view these results (with congestion map). I find this very useful as the "area that cause the congestion" can be in a very different location as the final congestion map. For example, somewhere in the layout has congestion. During search-and-repair, the congestion can "drift/Expand". When the congestion drift toward some macros (esp at the corner), the congestion become worse, and that is what you get at the end of routing. Instead of resolving the congestion at the corner of the macro, it is more effective to solve it at the root cause; but this is possible if you can see the root cause in the first place. A pity that SOC does not provide users this useful methodology to resolve congestion.

However, note that we can throw out intermediate db during optDesign, so if final congestion map and global congestion map are matching, it is a way to detech root cause of congestino.


Regards,
Eng Han