Turning Documentation Into (Unit Testing) Action

A hypothetical for design engineers… what if there were an online tool useful for both documenting your RTL and bootstrapping a testbench. Would you use it?

The tool is Wavedrom. It’s an open source tool hosted at wavedrom.com. You may already use it for documentation. I’ve used it in the past for documenting BFM behaviour. It’s accessible, easy to use and the output is clear. Highly recommended.

If you haven’t seen Wavedrom before you should load it up to see what it can do. By default, it comes up with a simple req/ack data transfer to illustrate the basics. The input is JSON which is pretty easy to work with. Output can be exported as PNG or SVG.

If you want to try something from scratch to see what it’d look like, you can paste in this APB write transaction…

{
  "name": "write",
  "signal": [
    {"name": "clk", "wave": "p..|."  , "node": "....b" },
    {"name": "psel", "wave": "01..0"},
    {"name": "penable", "wave": "0.1.0"},
    {"name": "paddr", "wave": "x=..x", "data": ["addr"] },
    {"name": "pwrite", "wave": "x1..x"},
    {"name": "pwdata", "wave": "x=..x", "data": ["data"] },
    {"name": "pready", "wave": "0..10", "input": "True", "node": "...a."}
  ],  
  "input": [
    {"name": "addr", "type": "logic [7:0]"},
    {"name": "data", "type": "logic [31:0]"}
  ],  
  "edge": ["a->b pready==1"]
}

That input creates a waveform output you can paste into your documentation so others on your team know what to expect from your RTL. That waveform looks like this…

Pretty slick. There’s features that let you get a little fancier with the output, but this example captures the essence of it: use JSON to build digital waveform graphics.

When I used Wavedrom for the first time, I thought it was great for documentation but I wondered about it’s potential for creating Verilog output that I could use in SVUnit tests. Wavedrom is relatively simple, so is SVUnit, so it felt like a good match. And I used Wavedrom to document my BFM so why not convert that documentation into action?

Well, it’s taken me a couple years to get around to it. But in true better-late-than-never fashion I’ve finally added a Wavedrom/JSON to Verilog feature to SVUnit. From an interaction described with Wavedrom, you can export the JSON to an SVUnit test directory where it’ll be converted into a Verilog task that you can then import to SVUnit test templates. The task, which uses the SVUnit clk_and_reset_util, looks like this…

task write(input logic [7:0] addr,input logic [31:0] data);
  step();
  nextSamplePoint();
  psel = 'h0;
  penable = 'h0;
  paddr = 'hx;
  pwrite = 'hx;
  pwdata = 'hx;
  step();
  nextSamplePoint();
  psel = 'h1;
  paddr = addr;
  pwrite = 'h1;
  pwdata = data;
  step();
  nextSamplePoint();
  penable = 'h1;
  while (!(pready==1)) begin
    step();
    nextSamplePoint();
  end 
  psel = 'h0;
  penable = 'h0;
  paddr = 'hx;
  pwrite = 'hx;
  pwdata = 'hx;
endtask

In a nutshell, each clock cycle of the wave is captured in the task. To get this functionality, there are a few hooks in the JSON for specifying name, inputs and conditions. To see exactly what the hooks are, here’s the JSON again with the hooks highlighted in red. Strictly speaking, the red is only required for the Verilog output; it’s benign when it comes to rendering the waveform.

{
  "name": "write",
  "signal": [
    {"name": "clk", "wave": "p..|."  , "node": "....b" },
    {"name": "psel", "wave": "01..0"},
    {"name": "penable", "wave": "0.1.0"},
    {"name": "paddr", "wave": "x=..x", "data": ["addr"] },
    {"name": "pwrite", "wave": "x1..x"},
    {"name": "pwdata", "wave": "x=..x", "data": ["data"] },
    {"name": "pready", "wave": "0..10", "input": "True", "node": "...a."}
  ],  
  "input": [
    {"name": "addr", "type": "logic [7:0]"},
    {"name": "data", "type": "logic [31:0]"}
  ],  
  "edge": ["a->b pready==1"]
}

For some colour commentary… pun intended…

  • Our Verilog task needs a name, handled by the “name”: “write” property.
  • The interface is specified from the APB master point of view. The pready is an input to the master that we can’t drive which is why it has the additional “input”: “True” property.
  • We want to specify an address and data for the write when we call the task. That’s made possible by the “input”: […].
  • With the possible wait states, the write isn’t done until the slave returns a pready. That condition is specified in the “a->b” edge as pready==1.

Call it beta functionality for now, details subject to change, because I’m still working through the usage model. But there should be more than enough here to be useful so I’d call it ready for people that want to get started. I’ve pushed it to the v3.31 release of SVUnit, available now. This AMBA APB example is something I used to test the feature that you can see for yourself in svunit-code/examples/modules/wavedrom. There’s a file called write.json that’s used to create write.svh. That’s a Verilog file that’s then included in dut_unit_test.sv. If you look at svunit-code/examples/modules/wavedrom/README, you’ll see runSVUnit is invoked with a new switch for this feature (-w|–wavedrom). The switch means JSON files are automatically found and translated to Verilog svh files. (If the interest is there, I’ll update the SVUnit user guide with more detailed instructions.)

As for the target audience and application, I expect this to be most useful for design engineers smoke testing RTL who are looking for an easy way to drive pins. Maybe they look at waves, maybe they go all the way to self-checking unit tests, maybe a combination, whatever, I’m just hoping it makes it easier for them to document and test RTL. Don’t get me wrong though, I think it’ll also be useful for verification engineers documenting interfaces to BFMs that’ll be unit tested. I plan on using it myself.

(Hint: If you’re a verification engineer looking to help your design team get started with unit testing, I’m hoping this is a chance for a breakthrough).

Seeing as how this is a new addition to SVUnit, I’d appreciate another 30 seconds of your time for a little feedback that’ll steer me in the right direction…

Thanks!

-neil

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.