QA in verification

 

Q6: Which of the parts in the testbench should add data to the scoreboard?
A6: That’s a million dollar question…there are two main approaches and the decision between the two should be done according to the project you have at hand. The first approach, which is faster and simpler is to take scoreboard data straight from the generator. Its major drawback is that the scoreboard won’t function if you have to move from the block level to the system level. The second one is to take scoreboard data from the physical interface (sub question: what is lost if you get the data from the physical interface in the form of bits and bytes, instead of taking it from the generator? Hint: all the logical fields), and then reconstruct it. This will allow the scoreboard to work at system level as well.
Therefore the correct answer would be: it depends. If our DUT has a chance of becoming an internal block then go for the second option. If, on the other hand, it is not and data reconstruction is not trivial, go for the first one. You can read more about this subject here.

Q10: What is the difference between the constraints that are added through the test file, and those constraints that are placed in the environment files themselves?
A10: The constraints that are an integral part of the environment are those found in the specification document. They limit the generated data to the DUT’s “specified behavior”, i.e. to correct or erroneous data that the DUT should know how to handle according to the specification. The constraints in the test file, on the other hand, are intended to direct the test further (towards a specific potential bug in the design, or a coverage hole, for example) and are often not related at all to the specification.
It is important to remember that constraints placed inside the actual environment file should not limit the data any further then the specification does. Test constraints are meant to do just that.

Q11: Please explain the difference between declarative code (also known as static code), and sequential code, and give an example of each. What is the major advantage of controlling generation via declarative code? Which of the two is harder to debug?
A11: Simply put, sequential code is a piece of code that you can run step by step in a debugger. For example, a function is a block of sequential code. On the other hand, a lot of the code you write is declarative and can not be stepped through…common examples are function and variable declarations, or generation constraints in HVLs.
The major advantage of controlling generation via declarative code is that it makes the generation extendable. You can add further constraints (or cancel existing ones in SystemVerilog and with some effort in E as well), without modifications to the original code. For example, an external test file can be used to change the generated data. This advantage is the one that made all HVLs opt for this mode of writing.
The major disadvantage is that the code is that declarative code is a lot harder to debug, but that’s a small price to pay compared with the first advantage.