1 Reply Latest reply on Mar 27, 2017 12:50 AM by gsns

    Issues with FM22LD16 Verilog model


      Using the FM22LD16.v Verilog model and have found several issues with it.
      Memory configuration is multiple parts hooked in parallel (i.e. sharing lower
      address bits and all data bits) with CE's tied to upper address bit decodes.
      OE and WE are also shared between parts.


      1) The period check at line 86:


          $period(negedge addr_change,`Trc,notifier);      // Addr cycle time check


         causes issues when a memory is being accessed via page mode.  The memory
         with its CE active is fine (addr_change is qualified with page mode), but
         other memories that have CE inactive are flagging period errors even though
         they are not actually enabled.  My current fix is: 


          $period(negedge addr_change &&& Enabled,`Trc,notifier);      // Addr cycle time check


          Not sure if this is the correct way to rectify this?


      2) Clearing of state variable ce_start_reg at lines 182 and 193 (ub_ and lb_
         cases respectively):


         ce_start_reg  <= 1'b0;


        Writes happen using CE held active with WE toggling (i.e. WE controlled
        writes).  First write happens fine, but then ce_start_reg is cleared and
        following write does not happen.  If writes are done such that page_mode is
        active it works, but I don't see anything in the data sheet indicating that
        this is a requirement for WE controlled writes.  Deleting these two lines 
        (182 and 193) resolves this issue, unsure how it may effect other use cases?


      3) The bufif1 statements that drive the output data (lines 408-423):
          bufif1 b15 (dq[15],data[15],OE_UB);
                    . . . 
          bufif1 b00 (dq[00],data[00],OE_LB);


         As stated above, OE is shared, so during a read parallel connected memories
         will both have OE active, but the read should not occurr until one of the
         parts has CE active.  This functionality is taken care of by line 139:


         wire [15:0] data  = (READ? ((page_mode == 1'b1)) ? Mem[addr] : data_reg : 16'bz);


         Which will have data for the inactive part set correctly to tri-state (Z).
         The Verilog bufif1 statement, however, will not pass Z from input to output
         even when enabled; the truth table indicates Z becomes X.  Thus, it ends up
         with the selected part (CE active) driving the correct read data but the
         unselected part (CE inactive) driving X's.  This contention leads to X's.
         My current fix is to use select statements that will pass Z from input to


          assign dq[15] = OE_UB ? data[15] : 1'bz;
          assign dq[14] = OE_UB ? data[14] : 1'bz;
          assign dq[13] = OE_UB ? data[13] : 1'bz;
          assign dq[12] = OE_UB ? data[12] : 1'bz;
          assign dq[11] = OE_UB ? data[11] : 1'bz;
          assign dq[10] = OE_UB ? data[10] : 1'bz;
          assign dq[09] = OE_UB ? data[09] : 1'bz;
          assign dq[08] = OE_UB ? data[08] : 1'bz;
          assign dq[07] = OE_LB ? data[07] : 1'bz;
          assign dq[06] = OE_LB ? data[06] : 1'bz;
          assign dq[05] = OE_LB ? data[05] : 1'bz;
          assign dq[04] = OE_LB ? data[04] : 1'bz;
          assign dq[03] = OE_LB ? data[03] : 1'bz;
          assign dq[02] = OE_LB ? data[02] : 1'bz;
          assign dq[01] = OE_LB ? data[01] : 1'bz;
          assign dq[00] = OE_LB ? data[00] : 1'bz;


      Scott Nixon


      FirstPass Engineering