4 ms·
>One could concievably test all possible combinations of that logic for errors, but it becomes 2^N combinations where N is the number of inputs and the number o
by legalcorrection 4y ago
>One could concievably test all possible combinations of that logic for errors, but it becomes 2^N combinations where N is the number of inputs and the number of state elements. Since this cannot be tested because the space is huge (excluding hierarchical designs and emulation), you generate targeted test patterns (and many many mutexes) to pare down the space, and perhaps randomize some of the targeted tests to verify you don't execute out of bounds.
This is all true of software too. Certainly, it’s easier to test software, but I don’t think it’s because software state is combinatorially simpler than hardware state.
- sbf501 4y agoActually it is the opposite: it is harder to test software. Software fuzzing is more difficult as function parameters can be (literally) infinitely more complicated to define (e.g., variable length strings), whereas logic test vectors are 1's and 0's (a lot of them, but a finite number). I've yet to see a fuzzing library that could handle all possible combinations of State, even with judicious mutex support.