Yu Hu, RTL Synthesis ChangLog, 08-27-07 to 08-31-07

* Update VerilogSynthesis::synthesisIf by deferring the handling of implicit
  latches. More specifically, The whole procedure of latch inference is as
  follows. Consider the following Verilog code: >

     if sel1
          Q = D1
     else if sel2
              Q = D2
<
  The inferred results should be like following:
  (the uncompleted If-else in the lowest scope will be an AND2
  gate which is fed by sel2 and D2 in this example). >

      sel2--+-->+----+
            |   |AND2|--->+----+      +-----+
      D2------->+----+    |MUX2|----->|LATCH|--->Q
            |             |    |      +-----+
      D1----------------->+----+         ^
            |                |           |
            |                |           o
      sel1-------->----------+-------o>+----+
            |                          |AND2|
            +------------------------o>+----+
<

  To setup the latched variables according to lower scope IF statements,
  the complement of the latch enable in the previous scopes should be read
  out and AND/OR with the current select bit (or its complement)
  in the current IF scope and write back as the new latch enable's complement.

* Update Mapper and VerilogWriter and solved the |TODO| in 08/27/2007. I made
  the generated latche enable net after implementNode() equivalent to the old
  enable net associated with the enable BBNode.

* |TEST_XST| "latches_2.v" and "latches_3.v" are synthesized and verified.

* |TEST_XST| "multiplexers_4.v" are synthesized and verified.

* "multiplexers_5.v" cannot be synthesized. There are some problems for
  latch handling in VerilogSynthesis::synthesizeCaseEasy and
  VerilogSynthesis::synthesizeCase. I've updated
  VerilogSYnthesis::synthesizedCaseEasy for this reason.

  In case there is a latch, the latch's enable is feed by a mux
  whose input data and selection bits are from a pre-calculated
  table and the condition of the CASE statement, respectively.
  The latch's data signal is feed by the mux inferred by the CASE
  statement. And the output of the latch is going to the input of
  the data mux. The illustration is as follows.

  Considering the following Verilog code >

         module v_multiplexers_5 (a, b, c, d, s, o);

             input a,b,c,d;
             input [1:0] s;
             output o;

             reg o;

             always @(a or b or c or d or s)
             begin
                 case (s)
                     2'b00 : begin o = a; end
                     2'b01 : begin o = b; end
                     2'b10 : begin o = c; end
                 endcase
             end
         endmodule
<
         The synthesized result will be: >

          +----------------<--------------+
          |        _____                  |
          |   a--->|   |   +-------+      |
          |   b--->|MUX|-->| LATCH |-->---+-->o
          |   c--->|   |   +-------+
          +------->|   |        | (enable)
                   -----  _____ ^
                     |   0|   | |
                     |   1|MUX|-+
                     |   1|   |
                     |   1|   |
                     |    -----
           s--->-----+------^
<

* |TEST_XST| "multiplexers_5.v" is synthesized and verified.

* |TODO| VerilogSynthesis::synthesizeCase still have problem to handle latch.
  For the above Verilog code, no latches will be infer since the current
  implement only test the variable assignment completion among different case
  condition and default statement. In the above code, no default is present,
  so the current implement will consider it as a completed assignment.... The
  solution is to caluate the default condition no matter it's present or not
  and generate latches if default is not present and the default condition is
  not empty (or constantly false).