Chapter

Section

BOOG and LOON have some bugs which require workarounds which one must remember to use.

  1. The delay reported by BOOG is wrong
  2. LOON can write netlists corrupted by instance names with a double underscore
  3. LOON does not work properly with hierarchical netlists
  4. LOON can write netlists corrupted with wrong declarations of internal vectored nets
  5. LOON can crash
  6. LOON can hang or lock up

  1. The delay reported by BOOG is wrong. If you want to know what the delay is, you have to do a LOON synthesis with opt level 0. This LOON delay can be slightly different since some optimisation to the netlist can take place, but the difference is small.

    1 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_0_min_x4
    2 $ boog -l loon_0000_300_4 multi8_boom multi8_4
    Quick estimated critical path ...18134 ps from 'y 1' to 'r 15'
    3 $ loon -l loon_0000_300_0 multi8_4 multi8_4_0
    Critical path ...20955 ps from 'x 0' to 'r 15'
    The correct delay is 20955.
  2. Sometimes, when using LOON with opt level 2 or 4 and buffers are inserted, then the output netlist can contain added buffer instances containing a double underscore ('__') which are illegal.

    1 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_0_min_x4
    2 $ boog -l loon_0000_300_4 multi8_boom multi8_4
    3 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_45
    4 $ loon -l loon_1500_300_2 multi8_4 multi8_4_2
    5 $ grep -n '__' multi8_4_2.vst
    12960:dddk_bbf_rrlcaary__2_2 : drvp_y
    6 $ loon -l loon_1500_300_1 multi8_4_2 multi8_4_21 >/dev/null
    `multi8_4_2` Error line 12960 : syntax error
    `multi8_4_2` Error 18 line 12966 :illegal concurrent statement
    The double underscore in the instance name on line 12960 gives an error when the netlist is read into LOON.

    The workaround is to (i) write the netlist to an AL formatted file; and (ii) then convert the AL file to a VST format. The file formats that Alliance uses to read and write netlists are defined by the environment variables MBK_IN_LO and MBK_OUT_LO. I set these in my .bashrc file to a vst format.

    1 $ cd ~
    2 $ grep 'MBK_.*_LO' .bashrc   
    export MBK_IN_LO=vst
    export MBK_OUT_LO=vst

    MBK_OUT_LO is set to AL for the LOON synthesis, and program x2y is used to convert back to VST

    1 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_0_min_x4
    2 $ boog -l loon_0000_300_4 multi8_boom multi8_4
    3 $ MBK_OUT_LO=al
    4 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_45
    5 $ loon -l loon_1500_300_2 multi8_4 multi8_4_2
    6 $ MBK_OUT_LO=vst
    7 $ x2y al vst multi8_4_2 multi8_4_2
    8 $ grep -n '__' multi8_4_2.vst
    9 $ loon -l loon_1500_300_1 multi8_4_2 multi8_4_21 >/dev/null 
    The grep at event 8 finds no double underscores and the LOON at event 9 gives no errors. Thanks to Ludovuc Jacomme for this tip.

    The scripts buf_loon and loop_buf_loon handle this for the user.

  3. When the input file to LOON is a hierarchical netlist one can see a warning message about signals not found in the hash table.

    1 $ loon -l loon_1500_300_1 multi8_4_2 multi8_4_21 >/dev/null 
    getsignal: 'mbk_out_r 15' not found in hash table
    Sometimes the critical path is given to a non-existant node, and the critical path information in the XSC file is incomplete.

    The workaround is to explicitly flatten any netlist that might be hierarchical before using LOON. These include any netlist containing a macro.

    1 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_0_min_x4
    2 $ boog -l loon_0000_300_4 multi8_boom multi8_boog
    3 $ flatlo -r multi8_boog multi8_4
    4 $ MBK_OUT_LO=al
    5 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_45
    6 $ loon -l loon_1500_300_2 multi8_4 multi8_loon
    7 $ MBK_OUT_LO=vst
    8 $ x2y al vst multi8_loon multi8_loon
    9 $ flatlo -r multi8_loon multi8_4_2
    10 $ loon -l loon_1500_300_1 multi8_4_2 multi8_4_21 >/dev/null

    flatlo at event 9 flattens the netlist. LOON at event 10 gives no more warnings about hash tables.

  4. The netlist writer from LOON can get confused about internal vectored nets. A particular problem is vectors with missing bits, where say bits 3,5,6 and 7 are defined, but not the other bits. The workaround is to replace the internal vectored nets with bits, and writing to the AL format followed by using x2y will do this.

    Since x2y is already used after LOON, this problem has already been solved.

    1 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_0_min_x4
    2 $ boog -l loon_0000_300_4 multi8_boom multi8_boog
    3 $ flatlo -r multi8_boog multi8_4
    4 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_45
    5 $ loon -l loon_1500_300_2 multi8_4 multi8_loon
    6 $ grep 'mbk_buf_mbk_buf_rtlcarry_6' multi8_loon.vst | grep -v '6_2'
    signal mbk_buf_mbk_buf_rtlcarry_6   : bit_vector( 8 downto 4);
          i1  => mbk_buf_mbk_buf_rtlcarry_6(4),
          i1  => mbk_buf_mbk_buf_rtlcarry_6(4),
          i1  => mbk_buf_mbk_buf_rtlcarry_6(8),
          i1  => mbk_buf_mbk_buf_rtlcarry_6(8),
          i0  => mbk_buf_mbk_buf_rtlcarry_6(4),
    mbk_buf_mbk_buf_rtlcarry_6_8 : p1_y
          t   => mbk_buf_mbk_buf_rtlcarry_6(8),
    mbk_buf_mbk_buf_rtlcarry_6_4 : p1_y
          t   => mbk_buf_mbk_buf_rtlcarry_6(4),
    7 $ MBK_OUT_LO=al
    8 $ loon -l loon_1500_300_2 multi8_4 multi8_loon
    9 $ MBK_OUT_LO=vst
    10 $ x2y al vst multi8_loon multi8_loon
    11 $ grep 'mbk_buf_mbk_buf_rtlcarry_6' multi8_loon.vst | grep -v '6_2'
      SIGNAL mbk_buf_mbk_buf_rtlcarry_6_8 : BIT;
      SIGNAL mbk_buf_mbk_buf_rtlcarry_6_4 : BIT;
      mbk_buf_mbk_buf_rtlcarry_6_4 : p1_y
        t => mbk_buf_mbk_buf_rtlcarry_6_4,
      mbk_buf_mbk_buf_rtlcarry_6_8 : p1_y
        t => mbk_buf_mbk_buf_rtlcarry_6_8,
        i0 => mbk_buf_mbk_buf_rtlcarry_6_4);
        i1 => mbk_buf_mbk_buf_rtlcarry_6_8,
        i1 => mbk_buf_mbk_buf_rtlcarry_6_8,
        i1 => mbk_buf_mbk_buf_rtlcarry_6_4,
        i1 => mbk_buf_mbk_buf_rtlcarry_6_4,

    LOON at event 5 has written a netlist with a vector from bit 4 to bit 8, of which bits 5-7 are not used. By writing to an al file at event 8 and converting to vst at event 10, the vector has been converted to individual bits, and bits 5-7 have gone.

  5. LOON can crash when it is inserting buffers.

    1 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_0_min_x4
    2 $ boog -l loon_0000_300_4 multi8_boom multi8_boog
    3 $ flatlo -r multi8_boog multi8_4
    4 $ MBK_OUT_LO=al
    5 $ MBK_TARGET_LIB=$ALLIANCE_MOS/vbe/sclib100_45
    6 $ loon -l loon_1500_300_4 multi8_4 multi8_loon
    Inserting buffers on critical path for file 'multi8_loon.al'
    ...insert_buffer: compute error 
    5.000000e-01!=5.000000e-01 fF   
    24216.684000!=24216.684000 ps    
    13619.424000!=13619.424000 ps
    7 $ echo $?
    100
    8 $ MBK_OUT_LO=vst

    Event 7 shows that the exit status is 100 after the crash instead of the normal value of 0. There is no workaround other than to ensure that the exit status is checked in any script using LOON when it could insert buffers (opt level 2 or 4).

  6. LOON can hang or lock up when it is inserting buffers. LOON remains endlessly looping and using 100% of the CPU and a <CTRL>C is needed to it. This lock up seriously complicates scripts which use LOON. LOON has to be launched as a background process, with the foreground process doing a time out which will kill LOON if it is reached.

     1 time_limit=30
     2 local_sleep()
     3 {
     4 exit_status=2
     5 time=$time_limit
     6 while [ "$time" -gt 0 ]
     7 do
     8   if [ -f "$1" ]
     9   then
    10     exit_status=0
    11     time=0
    12   else
    13     if ! ps h $! >/dev/null
    14     then
    15 #     LOON has crashed and PID has disappeared
    16       exit_status=1
    17       time=0
    18     else
    19       sleep 1
    20       let time="$time"-1
    21     fi
    22   fi
    23 done
    24 }
    25 loon -l lax $in_file $out_file 2>/dev/null >$$_loonout &
    26 local_sleep ${out_file}.xsc
    27 if [ "$exit_status" -ne 0 ]; then
    28 # error handling routine

    LOON at event 25 is run as a background job by using the ampersand at the end of the line. Function local_sleep at event 26 monitors the creation of file ${out_file}.xsc which should be written by loon. If it is written (event 8) then the exit status is 0.

    If the LOON pid has disappeared (event 13), then loon has crashed and the exit status is 1. Otherwise there is a 30 second timeout after which the exit status is the initial value of 2.

    The if statement at event 27 handles an error routine if loon has crashed or locked up.

In the synthesis flow described here, the LOON bugs are handled by enclosing LOON inside the scripts buf_loon or loop_buf_loon so that they can be used as though the crashes, hangs and corrupted netlists didn't happen. Additionally they handle fanin reduction and script loop_buf_loon will also loop LOON until the fastest netlist has been found.