+ Post New Thread
Results 1 to 7 of 7
  1. #1
    Member level 3
    Points: 3,124, Level: 13

    Join Date
    Apr 2002
    Posts
    64
    Helped
    0 / 0
    Points
    3,124
    Level
    13

    LDV50 simulation results mismatch btwen debug and fastrun ?

    I encounter a serious problem that when i run Ncverilog with my code at normal(nondebug) mode everything is ok, but when i use linedebug mode(want to dump some wave), my code just fails.
    How it can be?? is it cadence bug? and my code works well when using Modelsim5.7


    My college also counter such problem, his code runs well in modelsim (have try 5.5 ~5.7 veriosn), but it fails in cadnece ncverilog normal mode at certain point. ( I try Ncverilog 2.2, 3.0, 3.1, 4.0 and LDV5.0 , they all fails at the same point)

    Who has the sign off Quality?? modelsim or Cadence??
    I should believe whom??



    My code is


    ..................

    always @( sel_DMA_or_fastme_currram or src_datai or
    me_mc_curr_datai or me_mc_curr_datai_low or me_mc_curr_datai_high
    or src_write_addr or src_write_addr or mc_write_fastme_idx or
    me_mc_write_en)

    begin

    if(sel_DMA_or_fastme_currram == 1) // select input from DMA
    begin
    mbbuf_datai = src_datai;
    mbuf_src_write_addr = src_write_addr;
    mbuf_write_en = src_write_en; <=== This line *
    end
    else // select input from FastME CurrRAM
    begin
    if(mc_write_fastme_idx[0] == 1'b1)
    begin
    mbbuf_datai = me_mc_curr_datai_low;
    end
    else
    begin
    mbbuf_datai = me_mc_curr_datai_high;
    end

    mbuf_src_write_addr = mc_write_fastme_idx;
    mbuf_write_en = me_mc_write_en; <=====This line *
    end
    end


    mb_buffer src_mb(clk, mubbuf_src_sel_bank_w, src_read_addr, src_datao, mbuf_src_write_addr, mbuf_write_en, mbbuf_datai);
    ^^^^^^^^^^ mbuf_write_en

    ................................................



    The Above code fails, becuase i see the wave dump and
    "mbuf_write_en" is delayed one cycle than
    "me_mc_write_en/src_write_en" signals --------->cause my code fails

    If i take src_write_en/mbuf_write_en/ me_mc_write_en outside
    and write another always combination logic, then it SUCCESS


    always @(me_mc_write_en or sel_DMA_or_fastme_currram or src_write_en )
    begin
    if(sel_DMA_or_fastme_currram == 1) // select input from DMA
    mbuf_write_en = src_write_en;
    else
    mbuf_write_en = me_mc_write_en;

    end


    -----------------
    Why the signal "mbuf_write_en" is delayed one clk, when using first write style??


    aramis

    •   AltAdvertisment

        
       

  2. #2
    Full Member level 5
    Points: 4,742, Level: 16

    Join Date
    Apr 2002
    Location
    MOON
    Posts
    280
    Helped
    19 / 19
    Points
    4,742
    Level
    16
    **** ----- ****



    •   AltAdvertisment

        
       

  3. #3
    Member level 3
    Points: 3,124, Level: 13

    Join Date
    Apr 2002
    Posts
    64
    Helped
    0 / 0
    Points
    3,124
    Level
    13

    Re: Race Condition....

    Quote Originally Posted by joe2moon
    A race condition :o

    According to your post can not tell where will induce this
    1 cycle's latency, but it seems to be a race condition.
    But if it is a race condition, why Ncverilog runs in normal mode, it can't find it??



    •   AltAdvertisment

        
       

  4. #4
    Member level 3
    Points: 3,124, Level: 13

    Join Date
    Apr 2002
    Posts
    64
    Helped
    0 / 0
    Points
    3,124
    Level
    13
    besides, if it is really a race condition, the tool can't check it!!
    it will be a serious problem that function not work --- chip fails!!

    can lint tools can check and find about it?? It seems not



  5. #5
    Member level 3
    Points: 2,151, Level: 10

    Join Date
    May 2002
    Posts
    59
    Helped
    4 / 4
    Points
    2,151
    Level
    10

    Bad coding sytle

    Hi, you read the "me_mc_write_en" in your always block, but does not list it in the sensitive list, this creates a latch, that's why me_mc_write_en" is delayed under certain condition. When you take it out, this signal is in the sensitive list, so everything is OK. Any lint tools can check this typical error. BTW, when NC & Modelsim do not show the same result(happens all the time), I always trust NC.



    •   AltAdvertisment

        
       

  6. #6
    Member level 3
    Points: 2,151, Level: 10

    Join Date
    May 2002
    Posts
    59
    Helped
    4 / 4
    Points
    2,151
    Level
    10

    should be "src_write_en"

    Sorry, I made a mistake, it should be "src_write_en" which is not listed in the sensitive list.



  7. #7
    Member level 3
    Points: 3,124, Level: 13

    Join Date
    Apr 2002
    Posts
    64
    Helped
    0 / 0
    Points
    3,124
    Level
    13

    Re: should be "src_write_en"

    Quote Originally Posted by farmerwang
    Sorry, I made a mistake, it should be "src_write_en" which is not listed in the sensitive list.
    Obviously, you are right. I thought i have checked the sensitive list, i miss it!! after i add the "src_write_en" in the sentive list, it works well both in normal mode and debug mode!!

    But it doesn't explain, that when i miss the "src_write_en" in the list, the ncverilog runs ok in normal mode.

    (ps. the Modelsim runs well, even i miss the "src_write_en" )
    I think it's a very trival bug that in the simulator!!
    btw, "farmerwang" you are so excellent!!



    aramis



--[[ ]]--