1    

 

Expediting Verification of critical SoC

components using Formal methods

Nuni  Srikanth                          Maddipatla  Shankar  Naidu,  Lakshman  Easwaran                                              Application  Engineer                        Lead  Verification  Engineer        Mentor  Graphics                        Ericsson          nuni_srikanth@mentor.com                      maddipatla.shankar.naidu@ericsson.com                              lakshman.easwaran@ericsson.com    Abstract  -­‐  A  lot  of  time  and  effort  is  invested  by  designers  in  creating  a  robust  SoC.  With  more  and  

more   features   getting   incorporated   in   today's   SoCs,   designing   complex   FSMs   has   become  

inevitable.  Finding  corner  cases  in  the  State  machines  early   in  the  design  cycle  is  key  for  a   lesser  

time  to  market.  Also,  since  the  number  of  IPs  integrated  in  the  SoC  is  increasing  exponentially  due  

to  complex  features,  it  becomes  challenging  to  optimize  the  number  of  pin  outs  due  to  shrinking  

die  size.  Formal  techniques  aid  designers  in  comprehensively  verifying  FSMs  &  IO  Muxing  early  on.  

The   formal   engine   generates   various   stimulus   based   on   intelligently   coded   assumptions   &  

assertions   and   tries   to   prove   the   assertions   wrong.   Manually   coding   assertions   is   not   a   viable  

option  since  the  number  of  assertions  would  increase  based  on  the  number  of  state  transitions.  

In   this   paper,   a   user   friendly   flow   (which   was   developed   in-­‐house)   "Formal   Assertion   Builder"  

(referred   as   FAB)   is   presented.   Based   on   a   comprehensive   set   of   state   machine   &   IO   Muxing  

information  provided  by  the  user  (from  the  design  specification),  the  FAB  automatically  generates  

Assertions  &  Assumptions,  binds  them  to  the  Design  file,  generates  Scripts  to  validate  them  using  

the   formal  engine.  Once  the  assertions  are  evaluated  on  the  design,  a  Comprehensive  Report  of  

the  analysis  is  formulated.  

Keywords  –  IOMUX  structure,  FSM  verification,  FAB,  formal  

       

2    

 

Introduction    

Today,  as  the  die  size  continues  to  shrink  and  the  technology  advances,   it  has  become  an  absolute  necessity   for  expedition  of  verification  closure  of   some  critical  SoC  components.  The   timelines  are  pretty   tight,   especially   when   we   verify   a   product   derivative.   FSMs   become   more   complex   and  undergo   multiple   changes.   Also,   the   IO   pins   might   change   to   accommodate   new   IPs   and   the   IO  Muxing   structure   changes   drastically   in   a   derivative   product.   Comprehensive   verification   of   FSMs  and   IO   Muxing   structure   becomes   a   challenge,   and   completing   it   on   time,   a   compulsion.   In   this  paper,  we  present  a  flow  v.i.z  Formal  Assertion  Builder  (FAB),   internally  developed  to  facilitate  the  validation  of  critical  and  corner  cases  of  FSM,  and  IOMUX  areas.  We  have  integrated  &  verified  this  flow   in   a   couple   of   our   projects   and   seen   extremely   good   results.   At   the   end   of   each   of   these  sections,  results,  current  limitations,  and  the  future  scope  are  also  presented.  

FSM  Verification    

Below  is  an  example  of  4  states  FSM,  where  in  there  are  16  possible  transitions,  and  out  of  which  3  are  illegal  states.  Verification  of  such  simple  FSM’s  can  be  done  easily.    

 

 

 

 

 

However,  let  us  consider  an  FSM  of  the  complexity  below.    

       

3    

 

 

 

To  verify  all  the  state  transitions  (legal  and  illegal),  it  is  tedious  to  use  the  traditional  approach  of  building  a  test-­‐bench.  We  need  an  out  of  the  box  approach  where  even  corner  case  scenarios  can  be  verified  with  ease.  We  present  the  formal  approach  which  uses  robust  assertions  to  verify  the  FSM.  Manual  coding  of  assertions  for  large  state  machines  is  practically  impossible  considering  the  enormous  number  of  state  transitions.  It  can  also  lead  to  human  error  while  coding  the  assertions.  

 

In  this  paper,  we  present  a  flow  where  we  have  automated  the  generation  of  assertions  with  a  few  inputs  from  the  user.  These  automatically  generated  assertions  are  in-­‐turn  evaluated  by  a  Formal  Engine.  We  get  a  comprehensive  coverage  result  which  helps  in  understanding  the  robustness  of  the  design.  Let  us  have  a  look  at  the  flow  called  Formal  Assertion  Builder  (FAB)  for  FSM  verification.  

 

 

 

 

 

 

 

Courtesy:  Google  

       

4    

 

FAB  Flow  for  FSM  Verification    

 

 

In  order  to  generate  robust  assertions,  the  Formal  Assertion  Builder  needs  certain  basic  information.  The  clock  information  provided  is  used  by  the  FAB  to  clock  all  assertions.  The  FAB  also  generates  an  assertion  to  verify  the  default  state  of  the  FSM  when  it  is  in  Reset.  Hence  the  reset  information  is  required.  The  clock  and  reset  name  should  be  the  same  as  used  in  the  FSM  RTL.  We  also  provide  with  the  current  state,  next  state,  and  top  level  module  names  in  the  configuration  file  which  should  match  the  corresponding  names  in  the  FSM  RTL.  There  is  also  a  provision  to  generate  the  random  assertions  or  directed  assertions.  Directed  assertions  are  used  to  test  if  a  valid  transition  from  one  state  S1  to  another  state  S2  occurs  provided  the  condition  triggers.  While  random  assertions  test  how  many  possible  paths  the  tool  can  take  to  transition  between  two  specified  states.  Both  of  these  types  of  assertions  have  improved  our  confidence  in  finding  the  corner  case  bugs  on  the  FSM  RTL.  

A  snippet  of  the  configuration  file  is  below:  

 

       

5    

 

 

This  configuration  file  is  given  as  an  input  to  the  FAB  along  with  the  FSM  RTL.  The  FAB  generates  an  excel  sheet  with  all  possible  state  transitions.  The  conditions  and  the  outputs  to  be  verified  are  to  be  filled  by  the  Verification  engineer  by  referring  the  Specification.  The  names  in  the  conditions  are  to  be  filled  as  per  the  FSM  RTL.  Snippet  of  the  generated  sheet  is  shown  below:  

 

       

6    

 

 

 

“X”  in  the  condition  column  means  an  illegal  state  as  per  specification.  “NA”  means  a  state  would  move  from  present  state  to  next  state  without  any  condition.  FAB  reads  this  filled  excel  sheet  again  and  generates  the  corresponding  assertions.  It  also  generates  a  bind  file  that  binds  these  assertions  to  the  FSM  RTL  and  corresponding  tool  related  run  files  that  will  aid  the  formal  tool  to  prove  or  disprove  the  assertions.    

An  ENABLE  column  has  been  provided  to  granularly  enable  or  disable  a  specific  assertion.  This  information  is  automatically  used  as  a  condition  in  the  disable  iff  while  dumping  the  SVA  assertions.  The  assertions  generated  would  be  of  the  below  format.  All  the  assertions  would  be  in  a  single  top  level  module.  

       

7    

 

   

 

Results:    

Once  run  with  the  formal,  a  comprehensive  results  categorizing  the  proofs,  failures  are  listed  down  as  shown  both  in  the  Graphical  user  interface  as  well  as  the  text  files:  

A  proof  against  an  assertion  indicates  that  there  is  no  legal  stimulus  that  can  actually  break  the  assertion  taking  in  to  consideration  of  RTL,  environment  constraints,  and  assumptions.  Similarly,  a  failure  against  an  assertion  indicates  that  there  is  a  scenario  that  can  actually  break  the  assertion,  and  counter  example  simulating  the  scenario  is  also  given  by  the  formal  tool  

Vacuous  proofs  are  those  scenarios  where  the  antecedent  conditions  triggering  the  assertion  evaluations  are  not  true.  

 

       

8    

 

 

 

 

 

       

9    

 

 

 

Debugging  the  failures  would  be  also  as  similar  as  that  of  the  simulation  environments.  You  can  use  either  schematic,  or  source  code,  or  wave  form  to  trace  back  the  differences  as  shown  below:  

 

       

10    

 

Summary      

Bugs  Found    

In  our  project,  we  have  found  bugs  like  outputs  driven  after  extra  clock  cycles  during  state  transitions  and  FSM  illegal  transitions  

Limitations    

The  flow  has  been  tested  currently  for  the  Mealy  State  Machines  with  Verilog  FSM’s  only.    Any  SV  assumptions  should  be  manually  handwritten  in  the  generated  assertion  files.  User  intervention  is  required  for  updating  the  configuration  file    

Future  scope    

We  would  like  to  test  FAB  flow  working  with  VHDL  FSM’s,  and  also  automatically  populate  the  configuration  file  and  update  the  transition  excel  sheet  without  manual  intervention.  

     

 

 

 

 

 

 

 

 

 

 

       

11    

 

IO  MUX  Verification    

For  a  given  chip  size,  we  can  only  have  limited  number  of  pads.  Also  as  the  functionality  increases,  number  of  IPs  and  consequently  number  of  pins  also  increases.  Hence  we  have  to  use  configurable  pad  multiplexing  to  connect  several  IP  signals  to  each  pad.  Pad  muxing  is  very  critical  for  a  SOC  as  no  external   communication   can   take  place   if   Pad  muxing   itself   fails.    Verifying  a   complex   IO  MUXING  structure   requires   a   very   good   methodology   as   masking   a   single   bug   in   this   structure   could  potentially  lead  to  a  failed  chip.      

Typically  IO  MUXING  connection  in  a  SoC  environment  looks  as  below:  

 

The   connections   can   originate   from   the   hierarchies   that   are   deep   in   to   the   design   and   then   go  through  a  single  or  multiple  pad  muxing  logic  (based  on  the  complexity)  before  it  gets  interleaved  to  the  external  world.    

For  each  specified  padmux  configuration,  what  formal  tool  does  is  to  verify  the  matching  connection  between  IP  signals  and  chip  IOs.  This  is  illustrated  in  the  above  figure.  The  formal   tool  does  this  whole  work  of  connectivity  check   from  IP  sig   to  chip   IO  with  the  help  of  following  assertions.      always  (<Pad  mux  configuration>)-­‐>(<IP  IO>==<Chip  IO>);      This  assertion  will  check  whether  for  a  given  Pad  mux  configuration,   IP  signal  value   is  equal  to  the  value   coming   out   of   the   pad.   This   connectivity   check   is   exhaustive   in   nature   so   test   condition   is  checked  for  different  set  of  inputs  for  complete  coverage.  

       

12    

 

FAB  Flow  for  IOMUX  verification    

FAB  flow  for  IOMUX  verification  requires  the  following:  

• SoC  RTL      -­‐  The  RTL  on  which  the  IOMUXING  verification  has  to  be  done  • IOMUXING  sheet  –  Muxing  excel  sheet  prepared  as  per  the  specification  by  the  Architecture  

team  • Signal  Mirror  list  –  List  of  signals  that  needs  to    snooped  from  the  RTL  • Configuration  file  -­‐  setup  file  that  captures  the  clock  names,  reset  names,  polarity  of  reset  as  

specified  in  the  RTL.      

 

Taking  all   these   inputs,  FAB   tool  generates  PSL  assertions  binding   the   top   level  vunit   to   the  actual  RTL  model,  and  tool  independent  execution  scripts.  These  scripts  in  turn  can  then  be  used  to  run  the  formal   tool   by   taking   the   assertions   along   with   the   compiled   libraries   of   the   DUT.   Here   we   are  actually  reusing  the  same  RTL  data  base  from  the  simulation  environment.  

         

 

Snippet  of  the  Assertions  generated  looks  like  below:  

       

13    

 

 

During  early  stage  of  IOMUX  verification,  there  are  lot  of  RTL  signals  that  are  not  present  in  the  

design,  due  to  which  Vacuous  Pass  used  to  appear  in  the  output  results.  Challenge  with  Vacuous  

passes  is  that  the  assertions  don’t  get  evaluated  as  the  antecedent  of  the  assertions  is  not  true.  It  

would  be  very  hard  to  debug  such  cases.  In  our  flow,  we  split  all  the  antecedent  conditions  

individually  and  enable  cover  point  on  them  so  that  during  formal  verification  of  the  design,  if  there  

are  any  hierarchical  signal  mapped  are  missing,  then  uncovered  is  seen  against  all  the  corresponding  

signals  so  that  one  can  easily  come  to  know  about  which  corresponding  signal  in  the  RTL  is  not  

present  and  exactly  pin  point  the  same  feedback  to  the  design  team.  

Below  is  the  snippet  of  sample  generated  cover  applied  on  individual  signals:  

       

14    

 

Summary      

780  PSL  properties  were  thoroughly  verified  and  many  bugs  were  caught  in  the  design  prior  to  verification  team  catching  these  bugs.      

 

Bugs  Found    

Found  close  to  20  bugs  during  the  initial  bring  up  of  the  RTL,  and  also  incorrect  muxing  between  the  IP  signals.    

There  were  also  50  to  60  unconnected  or  tied-­‐off  pins.  There  were  essentially  not  implemented  in  the  RTL  but  existing  in  the  IO  MUXING  sheet.  

 

Limitations    

The  flow  has  been  currently  tested  for  PSL  assertions,  and  the  global  clock  frequency  should  be  always  more  than  the  design  clock  frequency  on  which  the  assertions  get  evaluated  

       

15    

 

If  formal  run  on  large  SoC  designs  without  properly  black  boxing,  then  it  takes  many  hours  to  get  converging  results.