Admit it. Looking into the parasitics extracted and saved as calibre file is immensly difficult to view. Even with a simple circuit, not only are the number of parasitics overwhelming, it is organized in a manner where it is impossible for the user to intuitively acknowledge where the parasitics are generated.
Due to such difficulties, I have decided to hack into the calibre file and try to extract values and parameters of these parasitics and processed for a more user-friendly view. It’s an ongoing process, and I have much yet to accomplish.
First, acquire the calibre model file. The extraction models are all saved in ‘layout.oa’ file. This file is in a remote server so the ‘layout.oa’ file was imported to my local machine via ftp.
We need to analyze this file which requires a hex editor. Any kind of hex editor is fine, and I have used ‘Hex Editor Neo’ free version. It has limited features but browing a hex file and simple searching features are open so its enough for my purpose.
This file is quite long, readable texts appear near at the beginning of the file (check that the scroll has bared been dragged down).
This text seems to be an introductory text where it describes the original components that exist in the schematic file.
If you go down a bit more following the text, there will be a point where it starts to list the actual extracted parasitic components(resistor or cap, in this case since it was RC extraction) along with a mention of the nodes that they are connected to.
↑ This seems to be the pharse that marks the start of parasitic lists.
↑ It now declares the existence of the first par.cap (short for ‘parasitic cap’) which is named “ciP10_VMID_0”. Actually, this parasitic cap’s real name is ‘P10_VMID_0’ and the prefix ‘ci’ seems to be metadata. My guess is that ‘c’ stands for ‘capacitor’ and ‘i’ stands for ‘instance’.
Since this is the ‘first’ capacitor it seems likely that is should explain how this capacitacne should be modeled with. In this case, it would be an ideal capacitor defined in ‘analogLib’. Probably that is why the word ‘analogLib’ appears in this phrase.
After declaring the capacitor model, it needs to defined the two nodes of the capacitor, noted as ‘PLUS’ and ‘MINUS’. In this case, the ‘PLUS’ is ‘P10_VMID_606’ and ‘MINUS’ is ‘0’. There IS a node named ‘0’ so do not be confused.
↑ Take a look at the next par.cap. Weirdly, it only states its name (“ciP10_VMID_1”), and one terminal (“P10_VMID_602”). Where is the other terminal? Well, it turns out that if one terminal is the same as the previous one, it will not declare it again. So in this case the other terminal would also be ‘0’.
↑ here’s another example. again, only one terminal is declared which means that the other terminal is ‘0’.
With this rule in mind, the entire text area regarding parasitic declarance can be clipped and saved as another separate file where it can be processed for later use. To do this, a simple python script was used with the offsets for the staring point and end point of this text area calculated by hand and applied in the script.
Using this python script, the text area containing parasitic RC definition was copied to a separate text file.