Scoreboard Push Index Not In Range Error

[MT]

I made a temporary scenario to provide stimulus to a VC, but I’m getting this error at runtime:

 
# %%    82 ns    Alert  FAILURE   in OSVVM,                    Scoreboard Push Index: -2147483648 is not in the range (1 to 1)

I’m using osvvm 2024.09. The message seems to originate from the LocalOutOfRange() function in ScoreboardGenericPkg, indicating that the index is outside of the MinIndex and MaxIndex range. I just can’t seem to figure out where the bug is in my code. Any help would be appreciated.

architecture temp of test_ctrl is
   signal TestDone    : integer_barrier := 1 ;
   
begin
   
   ctrl_proc : process is
   begin
      -- Initialization of test
      SetTestName("temp") ;
      SetLogEnable(PASSED, TRUE) ;  -- Enable PASSED logs
      SetLogEnable(INFO, TRUE) ;    -- Enable INFO logs
      
      TranscriptOpen("temp.txt") ;
      SetTranscriptMirror(TRUE) ; 
      SetAlertLogOptions(WriteTimeLast => FALSE) ;
      SetAlertLogOptions(TimeJustifyAmount => 8) ;
       
      -- Wait for Design Reset
      wait until RST_N = '0' ;
      WaitForClock(CLK_100, 2) ;
      ClearAlerts ;
      
      -- Wait for test to finish
      WaitForBarrier(TestDone, 35 ms) ;
      AlertIf(now >= 35 ms, "Test finished due to timeout") ;
      AlertIf(GetAffirmCount < 1, "Test is not Self-Checking");
      
      TranscriptClose ;
      
      print("") ;
      EndOfTestReports ;
      print("") ;
      std.env.stop(GetAlertCount) ;
      wait ;
      
   end process ctrl_proc ;
  

   send_proc : process
      variable file_data_v : slv_vector(0 to 1)(63 downto 0) ;
      
   begin
      Log("Waiting to be out of reset...", INFO) ;      
      wait until RST_N = '1' ;
                                      
      SetModelOptions(
         TransactionRec => RX_IF ,
         Option         => 1     , 
         OptVal         => 2         
      ) ;

      Log("Building slv_vector...", INFO) ;
      file_data_v(0)(15 downto  0) := std_logic_vector(to_signed( 1,16)) ;
      file_data_v(0)(31 downto 16) := std_logic_vector(to_signed(-2,16)) ;
      file_data_v(0)(47 downto 32) := std_logic_vector(to_signed( 3,16)) ;
      file_data_v(0)(63 downto 48) := std_logic_vector(to_signed(-6,16)) ;
      file_data_v(1)(15 downto  0) := std_logic_vector(to_signed( 4,16)) ;
      file_data_v(1)(31 downto 16) := std_logic_vector(to_signed(-4,16)) ;
      file_data_v(1)(47 downto 32) := std_logic_vector(to_signed( 5,16)) ;
      file_data_v(1)(63 downto 48) := std_logic_vector(to_signed(-5,16)) ;

      Log("Sending burst to vc...", INFO) ;
      SendBurstVector(
         TransactionRec => RX_IF       , -- Test Control Interface
         VectorOfWords  => file_data_v , -- file data
         StatusMsgOn    => true          -- true -> Print Log message
      ) ;
      
      AffirmIf( TRUE, "Dummy AffirmIf() to avoid error.") ;

      Log("Waiting for barrier: TestDone...", INFO) ;
      WaitForBarrier(TestDone) ;
      wait ;
     
   end process send_proc ;

end architecture temp ;

[Jim Lewis]

Hi Minteng,
When an ID has a value of -2**31 (-2147483648), it has not been initialized yet.
OSVVM VC, such as AxiStream, initialize the TransRec.BurstFifo signal at time 0 ns delta cycle 1, so it is not valid until time 0 ns delta cycle 2.

Are you working with an OSVVM VC or one of your own? If it is an OSVVM VC, time is either 0 ns or the VC does not support bursting and has not initialized the TransRec.BurstFifo as a result – (I just looked at the OSVVM UART which does not support bursting yet, but it seems to initialize BurstFifo anyway – a burst transaction can send many single word transfers on an interface).

If it is one of your own VC and it supports Burst operations, then TransRec.BurstFifo needs to be initialized at time 0 – preferably as soon as possible. See the OSVVM AxiStream transmitter for an example.

If time is actually 0 ns, then your statement,
wait until RST_N = '1' ;
seems like it is intended to find the end of reset – which should be well after time 0 ns.
My guess is that it is finding an X to 1 transition at time 0 ns.

The following should work. The now > 0 ns excludes the case where RST_N is initialized to 0, and is changed to a 1 at time 0 (which would not allow reset to happen).

wait until rising_edge(RST_N) and now > 0 ns ;  -- find reset changing from active to inactive

Best Regards,
Jim

[MT]

Hi Jim,

Thank you for the quick response. I’m working with a custom VC. You’re right, the problem was that BurstFifo wasn’t initialized in the VC. I added the following at the beginning of the VC’s transaction handler process, and it worked.

RX_IF.BurstFifo <= NewID("RxBurstFifo", ModelID, Search => PRIVATE_NAME) ;

I appreciate the tip on handling the reset detection. I’m sure it’ll come in handy.

[Author]

Posts