You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding liberty opcond, the problem is that some models use 1.9 in operating condition, but that is different to the voltage map, in order to support multi-voltage implementation, some tools rely on pg-pin voltage for linking, while others non MV-aware just assume single voltage by using operating condition alone. To avoid linking inconsistency, these should match in libraries modeling pg-pins.
sram_1rw1r_32_256_8_sky130_TT_1p9V_25C.lib
I removed the nominal voltage/temp/process and made the voltage map the same as the operating conditions.
Was going to test at least the syntax before pushing the change.
Regarding liberty opcond, the problem is that some models use 1.9 in operating condition, but that is different to the voltage map, in order to support multi-voltage implementation, some tools rely on pg-pin voltage for linking, while others non MV-aware just assume single voltage by using operating condition alone. To avoid linking inconsistency, these should match in libraries modeling pg-pins.
sram_1rw1r_32_256_8_sky130_TT_1p9V_25C.lib
operating_conditions(OC){
process : 1.0 ;
voltage : 1.9 ;
temperature : 25;
}
...
nom_voltage : 1.8;
nom_temperature : 25;
nom_process : 1.0;
...
voltage_map ( VDD, 1.8 );
voltage_map ( GND, 0 );
The text was updated successfully, but these errors were encountered: