{"id":20,"date":"2015-08-24T06:31:32","date_gmt":"2015-08-24T06:31:32","guid":{"rendered":"http:\/\/www.verilogpro.com\/?p=20"},"modified":"2022-06-27T00:44:23","modified_gmt":"2022-06-27T07:44:23","slug":"systemverilog-verilog-x-optimism-pessimism","status":"publish","type":"post","link":"https:\/\/www.verilogpro.com\/systemverilog-verilog-x-optimism-pessimism\/","title":{"rendered":"SystemVerilog and Verilog X Optimism – What About X Pessimism?"},"content":{"rendered":"\n

In my previous post about SystemVerilog and Verilog X Optimism – You May Not Be Simulating What You Think<\/a>, I discussed what is Verilog X optimism, and some coding styles that are prone to Verilog X optimism bugs. So how do you avoid potential bugs that Verilog X optimism can introduce?<\/p>\n\n\n\n

One technique that has been discussed in literature is to not use X’s at all, but make the values of flip-flops and memories at the beginning of simulation determine, and randomly assign 0’s and 1’s to them. This would have to be done using a tool as doing so manually would be impractical. The problem with this approach is how would you know whether you have covered the state space that could cause a problem? The number of possible states is of course 2n<\/sup>, which is likely impractical to cover. This technique could be interesting though if, for example, you want to know whether a particular X on an un-reset flop can cause a design problem. You could setup two simulations assigning 0 and 1 to the X, and verify that they both produce the same result.<\/p>\n\n\n\n

Another option is you could swing to the opposite end of the spectrum, and attempt to make constructs X pessimistic. With this principle, you would code RTL in such a way that X’s will propagate through logic, thus guaranteeing all ambiguities will propagate to downstream code. However, being pessimistic, simulations may yield X where there is really no uncertainty in actual silicon behaviour.<\/p>\n\n\n\n

Looking at our X optimistic if…else<\/b> again, first we can try making it more pessimistic by adding a “default” statement to fallback on. Consider this coding style for an if…else<\/b> statement:<\/p>\n\n\n\n

always_comb begin\n  if (sel)\n    y = a;\n  else if (!sel)\n    y = b;\n  else\n    y = 'x;\nend<\/pre>\n\n\n\n
This coding style does swing to the opposite end of the spectrum of X-pessimism. Even if a<\/i> and b<\/i> have the same value, an X on sel<\/i> causes the output y<\/i> to become X.<\/p>\n\n\n\n