autonomous monitors

[alb]

Hi everyone,

I've started to appreciate the benefits of TLM and the usage of bus
functional models but I'm facing a small 'design' issue related to the
implementation of an autonomous monitor.

I have a full-duplex interface where both ends can initiate a packet
transfer almost independently from each other. The 'master' may send a
command which may or may not result in a reply from the 'slave', but
there are a number of packets which are spontaneously sent from the
'slave' without the need to be prompted [1].

IMO this sort of interaction calls for the implementation of a 'monitor'
which sense the output of the DUT and performs all sorts of protocol
checks. This can be instantiated as part of the BFM but now what to do
with the data?

Dump the data in a file for later usage is kind of cumbersome especially
if some packets are replies to the commands sent by the testbench.
Better approach would be to put packets in a fifo to allow the testbench
to retrieve them when needed, but how to 'match' commands and replies in
order to verify correctness?

Any idea/suggestion/hint is appreciated.

Al

[1] strictly speaking the protocol cannot be qualified as a master/slave
one but in /most/ of the cases it is.

p.s.: I know most of this stuff is part of a course offered by
SynthWorks but unfortunately I do not have currently the resources to
afford it... :-(

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Andy]

You need what is called a scoreboard.

If you are using directed tests (where the expected results are known when you generate the stimulus) then the "master" transaction generator can also generate "transactions" for expected results from the slave, and send those to the scoreboard. The monitor can also generate transactions based on what it saw on the bus coming from the slave. The scoreboard compares these expected vs actual transactions. Scoreboards can be written to handle in-order or out-of-order transactions. The scoreboard can report any expected or actual transactions that were not matched up with their counterpart.

Random stimulus usually requires a reference (behavioral) model of the DUT (or reasonable portion thereof) that can generate the expected slave transactions from the master's generated transactions.

I'm assuming requirements exist for the slave to generate the non-requested packets. Therefore, an additional transaction generator might push expected transactions (per the requirements) into the scoreboard to match up with the actual non-requested slave responses.

You can also set up different scoreboards for different types of transactions (e.g. requested vs non-requested slave responses), and handle them separately using a router that inspects transactions and sends them to the appropriate scoreboard.

Lacking resources for Synthworks' TB course, Janick Bergeron's "Writing Testbenches: Functional Verification of HDL Models" is an excellent reference. I have the first edition (light blue cover), which is strictly VHDL/Verilog, whereas the 2nd edition (red cover) also addresses 'e' and Open Vera techniques. I do not know if the 2nd edition covers as much in VHDL/Verilog as the 1st edition.

Hope this helps,

Andy

 

[alb]

On 09/09/2013 16:28, Andy wrote:

If you are using directed tests (where the expected results are known
when you generate the stimulus) then the "master" transaction
generator can also generate "transactions" for expected results from
the slave, and send those to the scoreboard. The monitor can also
generate transactions based on what it saw on the bus coming from the
slave. The scoreboard compares these expected vs actual transactions.
Scoreboards can be written to handle in-order or out-of-order
transactions. The scoreboard can report any expected or actual
transactions that were not matched up with their counterpart.

Since the actual transactions might include spontaneous transactions
from the DUT, I probably would need to handle 'out of order'
transactions and the lookup function may not be so trivial.

What about timing though? I presume at this point the 'master' cannot
wait for the reply and should simply work as a sequencer. But what if my
test depends on values that I read back from the DUT?

True I can intentionally avoid these situations on purpose if they are
not needed to achieve functional coverage.

Random stimulus usually requires a reference (behavioral) model of
the DUT (or reasonable portion thereof) that can generate the
expected slave transactions from the master's generated transactions.

A random stimulus would be preferable especially when simulating the
whole system together since apparently the real hardware is showing lots
of problems when integrated.

Unfortunately a behavioral model does not exist and even if the
investment is certainly worth it I believe the 'management' won't
understand the reason for it... (sigh!)

I'm assuming requirements exist for the slave to generate the
non-requested packets. Therefore, an additional transaction generator
might push expected transactions (per the requirements) into the
scoreboard to match up with the actual non-requested slave
responses.

This is true indeed for some cases, in some others though the
requirement will simply state 'send packet of type blabla every 2
seconds', which can be translated in amount of clock cycles in principle
and then looked for at the right time window... but it seems a bit
cumbersome.

You can also set up different scoreboards for different types of
transactions (e.g. requested vs non-requested slave responses), and
handle them separately using a router that inspects transactions and
sends them to the appropriate scoreboard.

That's interesting indeed, the router should be able to distinguish the
transactions based on some identifier (maybe a field in the packet
format...) and route them appropriately.

Lacking resources for Synthworks' TB course, Janick Bergeron's
"Writing Testbenches: Functional Verification of HDL Models" is an
excellent reference. I have the first edition (light blue cover),
which is strictly VHDL/Verilog, whereas the 2nd edition (red cover)
also addresses 'e' and Open Vera techniques. I do not know if the 2nd
edition covers as much in VHDL/Verilog as the 1st edition.

I read the 2nd edition and found it extremely inspiring, even though is
a bit crowded of 'e' and 'OpenVera' which are not of my interest for the
time being (and the foreseeable future). A small section on
'scoreboarding' is presented but not many details are given and it lacks
of examples.