Xilinx

 Multi-­‐Cycle  Path  Tutorial  

by  Ekawat  “Ice”  Homsirikamol  

ver  1.0  

May  3,  2010  

  By  default,  the  synthesis  and  implementation  tools  treat  all  paths  as  single  cycle  paths,  i.e.,  any  
combinational   path   between   two   registers   in   the   implemented   circuit   is   assumed   to   have   a   propagation  
delay  shorter  than  one  clock  cycle.  Hence,  if  you  have  a  combinational  path  between  two  registers   that  
takes   more   than   one   clock   cycle   to   propagate   through,   a   constraint   file   is   required.   Without   the  
constraint   file   the   tool   will   not   know   where   the   multi-­‐cycle   path   is   located.   For   Xilinx,   we   can   either  
specify  these  paths  for  synthesis  (using  UCF  file)  or  for  implementation  (using  XCF  file).  All  constraints  
applied  during  synthesis  will  propagate  to  implementation.  The  full  details  on  how  to  create  a  constraint  
file   can   be   found   in   the   Constraints   Guide,   http://www.xilinx.com/support/documentation/dt_ise11-­‐
1.htm.  

  In  this  tutorial,  we  will  show  how  to  create  a  constraint  file  for  a  multi-­‐cycle  path  using  Xilinx  ISE  
v.11.1.  We  assume  the  use  of  Spartan  3  FPGA  (xc3s50pq208-­‐5).  An  example  used  in  this  tutorial  is  the  
radix-­‐2   sequential   multiplier  
based   on   the   shift/add  
algorithm,   right-­‐shift   version  
with   carry   save   adder   (CSA).  
Source   codes   for   this   example  
are  provided  with  this  tutorial.  
The   circuit   contains   two  
critical   paths:   single-­‐cycle  
path,   passing   through   the  
carry   save   adder   and   omitting  
the   carry   propagate   adder,  
and   a   multi-­‐cycle   path   passing  
through   both   the   carry   save  
adder  and  the  carry  propagate  
adder.   Compared   to   the  
version   based   on   the   carry  
propagate   adder   only,   the  
execution   time   is   reduced  
considerably,  especially  for  the  
large   values   of   the   operand  
size   k.   In   this   example,   we  
assume  k=64.                              Figure  1:  Datapath  
Basic  Implementation  
Before  we  proceed  any  further,  let  us  make  sure  that  the  critical  path  is  always  included  in  the  Post-­‐PAR  
static   timing   report.   To   make   it   happen,   select   the   "Process   Properties"  of   "Implement   Design   -­‐>   Place   &  
Route  -­‐>  Generate  Post-­‐Place  &  Route  Static  Timing"  located  inside  the  Processes  window,  under  Design  
tab.  Then,  specify  the  following  settings.  

Figure  2:  Post-­‐PAR  Static  Timing  Report  Settings  

Once   done,   you   can   implement   the   design   and   view   the   results.   Below   is   a   portion   of   the   generated  
Post-­‐PAR  Static  Timing  Report  :  

Figure  3:  Post-­‐PAR  Static  Timing  Report  

Similarly,  the  PAR  report  will  show  the  following  result  as  your  clock  speed  :  

Figure  4:  PAR  Report  without  UCF  file  

As  expected,  the  critical  path  in  Post-­‐PAR  Static  Timing  Report  goes  through  the  CPA  unit.  However,  this  
is   not   the   actual   critical   path   for   this   circuit.   Hence,   the   tool   needs   to   be   informed   that   the   path   that  
goes  through  the  CPA  is  allowed  to  take  multiple  clock  cycles.  The  exact  number  of  clock  cycles  depends  
on   the   operand   size,   FPGA   device   used   for   implementation,   and   other   factors.   This   number   can   be  
determined,  for  example,  by  first  implementing  the  circuit  with  a  multi-­‐cycle  path,  then  without  multi-­‐
cycle   path,   and   then   computing   the   ratio   of   the   obtained   clock   periods,   and   rounding   it   up   to   the  
nearest  integer.  

Constraint  File  Creation  

Let   us   now   try   to   create   a   constraint   file   to   specify   the   multi-­‐cycle   path.   First,   go   to     "Constraints   Editor"  
under  "Tools"  tab.  Inside  Constraints  Editor,  create  a  timing  constraint  for  "Clock  Domains"  by  going  to  
"Timing  Constraints  -­‐>  Clock  Domains"  located  inside  "Constraint  Type"  window.  Then,  specify  the  clock  
period  as  shown  below:  

Figure  5:  Clock  Period  

The  tool  will  try  to  optimize  the  clk  net  based  on  the  given  time  period.  Then,  we  will  need  to  specify  the  
exception  path.  This  can  be  done  by  navigating  to  "Timing  Constraints  -­‐>  Exceptions  -­‐>  Paths".  Inside  the  
Path  Exceptions  pop  up,  we  will  give  TIMESPEC  name  as  TS_multipath.  From  group  remains  default  as  All  
Flip   Flops.   This   field   tells   the   tool   where   the   beginning   of   the   path   is   located.   Then,   expand   the   Through  
points  by  selecting  the  plus  sign  and  creating  a  new  through  point  constraint.  This  step  will  tell  the  tools  
which   path   needs   to   be   considered   as   a   multi-­‐cycle   path.   If   Through   Point   is   omitted,   the   tool   will  
assume   that   all   paths   starting   from   the   source   and   ending   with   the   destination   are   all   exceptions.  
Referring   to   the   source   code,   the   addout   net   is   the   multi-­‐cycle   path   signal.   We   can   select   this   net   by  
specifying  the  Through  Points  as  shown  below  :  

Figure  6:  Through  Points  

Then,  under  To  group,  the  destination  must  be  selected.  In  our  case,  the  destination  is  pp  register.  We  
can  create  the  destination  group  by  selecting  the  Create  button  and  filling  the  pop  up  as  shown  below:  

Figure  7:  To  groups  

Again,  a  Filter  is  used  to  create  the  group.  You  can  also  try  creating  the  group  without  using  the  Filter,  
but  the  resulting  UCF  file  will  look  much  messier  and  the  design  will  not  be  flexible  as  the  nets  are  fixed.  
Hence,  if  a  design  size  is  changed,  this  UCF  file  may  not  be  functioning  correctly.  

When  done,  select  Constraint  Type  as  ”Relative  to  other  path  TIMESPEC"    with  Reference  TIMESPEC  as  
TS_clk,  with  a  multiply  factor  of  2.  The  final  Path  Exceptions  should  look  like  those  shown  in  the  below  
figure:  

Figure  8:  Final  Path  Exceptions  

Press  OK,  then  navigate  to  Timing  Constraints  under  Constraint  Type  window.  You  will  see  the  code  
generated  inside  your  UCF  file  as  shown  below  :  

Figure  9:  Final  UCF  file  

The  lines  number  1  -­‐  3  specify  the  group  names  and  their  associated  nets  and  instances.  Line  number  4  
is  telling  the  tool  to  optimize  for  the  clock  period  equal  to  6.5  ns  with  the  50%  duty  cycle.  Line  number  5  
tells  that  any  path  starting  from  any  flip  flop  that  goes  through  "addout"  signal  and  ending  with  the  "pp"  
group  can  have  the  critical  path  equal  to  two  times  the  clock  period.  Save  the  constraint  file  by  using  
"ctrl+s"  key  on  your  keyboard.  The  constraint  file  is  now  ready  for  implementation.    

Design  Optimization  
Implement  the  design  with  the  UCF  file.  Once  done,  you  should  see  that  the  PAR  result  file  contains  the  
following  summary:  

Figure  10:  PAR  result  with  UCF  (TS_clk  =  6.5  ns)  

As  opposed  to  implementation  without  UCF  file  (Figure  4),  we  can  now  see  two  separate  results  for  each  
of  our  constraints.  Clock  path  without  CPA  and  with  CPA  are  5.583  ns  and  12.403  ns,  respectively.  In  this  
case,   the   tool   tries   to   optimize   the   design   for   the   basic   clock   period   6.5   ns,   and   optimize   the   path  
through  CPA  to  the  delay  smaller  than  twice  the  clock  period.  Note  that  we  do  not  need  to  set  our  clock  
period   to   5.583   ns   when   we   actually   implement   the   design   on   FPGA.   In   fact,   if   we   use   the   design   on  
FPGA   with   the   above   clock   period,   the   design   will   probably   fail   to   operate   correctly   as   the   minimum  
delay  of  the  multi-­‐cycle  path  is  12.403  ns;  which  is  bigger  than  twice  the  clock  period.  The  results  shown  
above   are   the   minimum   possible   values   for   each   path   separately.   We   will   need   to   select   an   appropriate  
value  for  our  clock  when  the  above  constraints  are  taken  into  consideration.  The  best  course  is  to  use  
the  clock  period  as  specified  inside  the  UCF  file  or  to  modify  the  constraint  file  so  the  tools  can  optimize  
the  path  accordingly.  

Let  us  try  to  optimize  the  path.  Again,  we  need  to  go  back  and  edit  the  timing  constraint  for  our  clock  
domain  from  the  constraint  editor.  The  value  should  be  set  for  5  ns.  After  re-­‐implementing  the  design,  
you  should  receive  the  following  result:  

Figure  11:  PAR  result  with  UCF  (TS_clk  =  5.0  ns)  

The  results  do  not  meet  the  timing  requirement.  When  constraint  is  not  met,  timing  score  is  not  equal  
to  0.  Let  us  relax  our  requirement  and  implement  the  design  for  5.2  ns.  
  

Figure  12:  PAR  result  with  UCF  (TS_clk  =  5.2  ns)  

All  constraints  are  met  for  the  clock  period  of  5.2  ns.  These  steps  can  be  repeated  until  an  optimal  result  
is  reached.  

Let  us  look  at  the  improvement  of  our  circuit’s  latency  when  a  multi-­‐cycle  path  is  specified.  For  k  =  64,  
the   total   number   of   clock   cycles   required   without   multi-­‐cycle   path   is   128.   When   a   multi-­‐cycle   path   is  
specified,  the  total  number  of  clock  cycles  required  is  127+2=129.  The  total  latencies  with  and  without  
multi-­‐cycle   path   are   5.2*129   =   670.8   ns   and   10.943*128   =   1400.7   ns.   The   performance   of   the   circuit  
with  a  multi-­‐cycle  path  is  higher  by  108%!  

Critical  Path  Verification  

In  the  previous  section,  we  have  learned  how  to  specify  a  multi-­‐cycle  path.  But  how  can  we  verify  that  
the  critical  path  we  received  is  the  one  that  we  expected?  In  a  more  complex  circuit,  there  is  always  the  
possibility  that  we  might  miss  some  through  points.  Looking  at  the  Post-­‐PAR  Static  Timing  Report  from  
ISE,  the  report  does  not  show  any  information  on  the  multi-­‐cycle  path.  In  fact,  it  only  shows  the  same  
critical  path  even  when  UCF  file  is  specified.    

To  obtain  the  critical  path  information,  we  will  need  to  open  the  Timing  Analyzer  program.  This  program  
is  normally  located  in  the  following  location  "Start  Menu  (Windows  button)  -­‐>  Programs  -­‐>  Xilinx  -­‐>  ISE  -­‐>  
Accessories  -­‐>  Timing  Analyzer".  Then,  open  our  design  by  choosing  "File  -­‐>  Open  Design"  and  select  
top_mult.ncd  from  the  ISE  project's  workspace,  top_mult.pcf  should  be  selected  automatically.  Next,  
select  the  UCF  file,  top_mult.ucf,  under  User  constraints  file  and  press  OK.  Select  "Timing  -­‐>  Run  
Analysis"  and  analyze  against  "design  timing  constraint".  Under  Timing  Constraint  tab,  you  will  see  that  
the  two  constraints  are  selected  for  analyzing.  Then  make  sure  that  Report  Options  tab  contain  the  
following  settings  so  that  the  critical  path  is  generated  :  
  

Figure  13:  Report  Options  of  Timing  Analyzer  

Press  OK.  

Figure  14:  Post-­‐PAR  Static  Timing  Report  of  Timing  Analyzer  (TS_clk  constraint)  
Looking  at  the  generated  timing  report,  we  can  see  that  the  critical  path  for  the  TS_clk  period  does  not  
any  longer  go  through  the  CPA  unit.  The  path  that  goes  through  the  CPA  unit  is  TS_multipath,  which  is  
what  we  expected.