IEEE.org     |     IEEE Xplore Digital Library     |     IEEE Standards     |     IEEE Spectrum     |     More Sites

Skip to content
  • Lars Asplund's avatar
    Manage testing of error asserts that can't be fully tested. · 6de05e1b
    Lars Asplund authored
    Functions that are expected to fail with an assert of severity *error* are normally tested in in two steps:
    1. Configure the simulator to stop on error and then apply test input to trigger the assert. The simulator is expected to stop on the assert and this premature simulation exit is logged as an error.
    2. Configure the simulator to stop on failure and then apply test input to trigger the assert. The simulator is expected to run to completion and the assert will go undetected. The test is logged as a passing test.
    
    If the first step fails and the second passes we can conclude that the assert severity level is error. A couple of tests will fail in step 2 because the tested function is not designed to handle a non-stopping assert. Specifically, a few functions
    will run into an integer out of range problem that will force the simulator to stop regardless of its configuration. This commit changes the tests for these functions such that only step 1 is performed. The price for not running step 2
    is that we can't conclude that the assert is of severity error. All we know is that it is of severity error or failure.
    
    The integer out of range condition was not detected by earlier versions of GHDL which caused step 2 to pass as expected.
    6de05e1b