Requirements Spec: Multi active input pin handling

in avm flow
Author(s): Renjith

Date: 29 Nov 2021

Introduction
Google is using avm as electrical models. These contain multiple active pins which need to be
effectively handled by tool. Currently we are completely ignoring these, and macros won’t
switch.

Detailed Background
This is how the avm state looks like
state_boolean avm_read_write
"!PDE&WCK&RCK&!KCS&!DFTRAM&!REN&!WEN&!MCSRD[1]&!MCSRD[0]&!MCSWR[1]&!MCSW
R[0]" "RCK&WCK" "NA"

Here the active pin is specified as "RCK&WCK"

Tool identified this combination as a separate pin & stored in dv.cell_mode_usage_attributes()

though such a pin is not present for this cell.
80963: {'_high_energy_mode_': ('avm_read_write',
'!PDE * WCK * RCK * !KCS * !DFTRAM * !REN
* !WEN * !MCSRD[1] * !MCSRD[0] * !MCSWR[1] * !MCSWR[0]'),
'_low_energy_mode_': ('avm_read_write',
'!PDE * WCK * RCK * !KCS * !DFTRAM * !REN
* !WEN * !MCSRD[1] * !MCSRD[0] * !MCSWR[1] * !MCSWR[0]'),
'_median_energy_mode_': ('avm_read_write',
'!PDE * WCK * RCK * !KCS * !DFTRAM *
!REN * !WEN * !MCSRD[1] * !MCSRD[0] * !MCSWR[1] * !MCSWR[0]')},

>>> dv.convert_to_name(Pin(80963))
Pin('RCK&WCK')

We are looking for some working solution in the default flow itself. Tool need to do some basic state
assignment and then plan for some better handling.
e.g in this npv working scenario we are telling the tool to completely ignore all active pin & proceed
with user assigned period. Similar to that when tool finds 2 active pins we can consider the pin with
fastest freq as the trigger point and proceed with that.
Testing
We have the avm available in this area -->
/lus01/ae/rnr/sftp_google/npv_mem_not_switching/
Business Impact
Describe why this should be a priority relative to other products/features. Avm is a supported
flow but when it captured multi active pin details tool cannot handle it. We end up ignoring these
macros which is bad. Only possible alternative is to hack each and every avm files and keep
only 1 active pin which is a very tedious process. Also hacking the input collaterals is not a
recommended approach too.
Commented [EB1]: @Renjith: can you elaborate more
here.
Do you prefer to have the faster among the active pins
considered and the mode to be applied if that faster active
pin switches ?
When both pins have equal frequency, randomly pick one.
Commented [RR2R1]: Yes @Eldo N Baby . End goal is
that tool needs to find out a valid pin to find the freq/period
to apply the user provided state. Something like an override
(using state + period option in npv). So findings the pin with
fastest frequency & use it as the period would be the
easiest/best approach.
Commented [ENB3R1]: Thanks.
How about VCD handling. Should we apply the mode when
both pins switch together or when anyone switches.