In reply to ben@SystemVerilog.us:
Ben,
I am going through your papers. First, my methodology question…
-
From what is dissolving into my understanding, it appears that assertions are good at targeting lower-level/temporal level requirements. Generally, our “requirements” are higher level. Example “The DUT shall support transmission of IGMP Query”. In my testbench, I use a packet monitor connected to a coverage collector, and simply sample the queries that come out. I’m not sure how I would parse, and detect these packets using assertions (probably because I’ve not tried!) These requirements don’t appear to easily map to assertions. Agree/Disagree/thoughts?
-
I could see a list of derived requirements, I.e. requirements generated because of the designers chosen implementation of the higher level requirements being perfect for assertions. Basically all the nuts and bolts of the design, and the interface protocols. Agree/Disagree/thoughts?
We don’t write down any implementation specific requirements. Should we, and then generate assertions to target those? Alternatively, should we NOT write them down, and let the assertions BE the documentation?
In addition, can/should the assertions also target higher level requirements (which are of more importance in the grand scheme of things)? E.g. I just to know queries were produced, but I do not care how the designer does it)