autonomous monitors

Discussion in 'VHDL' started by alb, Sep 7, 2013.

  1. alb

    alb Guest

    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?
    alb, Sep 7, 2013
    #1
    1. Advertising

  2. alb

    Andy Guest

    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 alsogenerate "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-requestedpackets. 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 asthe 1st edition.

    Hope this helps,

    Andy
    Andy, Sep 9, 2013
    #2
    1. Advertising

  3. alb

    alb Guest

    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.
    alb, Sep 9, 2013
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jack
    Replies:
    1
    Views:
    773
    Harald Hein
    Jul 1, 2003
  2. Meh-Lit Kim
    Replies:
    1
    Views:
    777
    Chris Uppal
    Oct 8, 2003
  3. Alex Hunsley
    Replies:
    0
    Views:
    351
    Alex Hunsley
    Jan 23, 2004
  4. Aaron Leung
    Replies:
    0
    Views:
    285
    Aaron Leung
    Dec 8, 2004
  5. Todd Jacobus

    How do I make an autonomous program?

    Todd Jacobus, Aug 23, 2008, in forum: Ruby
    Replies:
    8
    Views:
    119
    Dave Bass
    Aug 24, 2008
Loading...

Share This Page