SystemVerilog Directed Test Bench

I am not certain this is a bug and could quite probably be a user error as I am not all that familiar with tclsh. I am trying to learn how to use your tool by using one of your example designs which you provide

In Windows 10 I associated the .tcl extension with the tclsh application (I installed tcl/tk from ActiveState as your doc recommended). I double-click on tb_gen.tcl in windows explorer and the tclsh ui pops up.

In the form I select the directory examples/standard/sv as the Working Directory. I set the Output directory to some other location.

In the list of sv files which the tool found under the working directory, I select dut.sv. Then I set the mode to gen_mod and click the Generate button. The progress bar gets to 42% and never gets any further.

While still stuck at 42% I check in the output directory and see the following files have been generated:

dut_if.sv tb_mod.sv tb_top.sv

However, the tb_mod.sv has nothing but comments in it, i.e. no actual code.

Can you please help?

I gave up trying to get the ui (wish) version of your tool to work, so switched to trying out your command line version of the tool ('tb_gen_cmd'). I discovered a couple of bugs which I fixed and it now completes, indicating success ("tb_gen_cmd Generation Done."), and in the generated file tb_mod.sv I now see that it includes some actual code, for example the default and the user instructions. I don't know yet if it has produced usable code, but so far things are looking a lot better.

I can send you my modified version of the 'tb_gen_cmd' if you can let me know the best way to get it to you

Kevin, This is the first I have heard of any issues. Not sure if others are having the same problem. I will play around with the gui and see if there is something obviously wrong.

Other wise, you seem to be making some progress. I would like to see any changes you needed to make to get results. I currently do not have access to a simulator ...

Hi Ken, thanks for your help. I will try to describe my changes here since I don't know how to upload files to this site:

1. tb_gen.tcl: Due to Activestate ActiveTcl coming with a different version of iwidgets, CHANGED: "package require Iwidgets 4.0" TO: "package require iwidgets 4.1"

2. tb_gen_cmd: Changed the line referring to the template FROM: "append template "/tb_prg_template.sv"" TO: "append template "/tb_mod_template.sv""

3. tb_gen_cmd: Syntax error, CHANGED: "if {gen_mod == 0} {" TO: "if {$gen_mod == 0} {"

And this is how I run it from a DOS CMD line:

cd D:\Users\kminn\SV_TB_GEN\tb_gen_experiments\tb_gen set TBGEN=D:\Users\kminn\SV_TB_GEN\tb_gen_experiments\tb_gen tclsh tb_gen_cmd dut.sv -mod

Note, running from DOS CMD is ok for me at the moment, I don't really need the ui method to work, so long as the CMD version runs properly.

If you need more info, please let me know, Kevin

Ken, with my 'fixes' I have begun checking the generated code and tried to run an actual simulation (which failed). I see some errors in the dut_if.sv generated file. Note, for the sources I am using your example design under examples/standard, where the dut file is dut.sv.

In the generated dut_in.sv I see issues such as follows. Look at the last four lines of the interface and modport structures..

interface dut_if();

logic rst_n; logic clk; logic 31:0 out1; logic 31:0 out2; logic 31:0 addr; logic 31:0 data_in; logic sel; logic 31:0 data_out; logic ack; logic 32'h00000000; logic 0; logic data_in; logic data_in;

modport dut_conn( input rst_n, input clk, output out1, output out2, input addr, input data_in, input sel, output data_out, output ack, initial 32'h00000000, endalways 0, end data_in, end data_in );

Would you have time to run your standard example design on your side and see if you can reproduce this issue?

Thanks,

Kevin

Some more detail on the issue:

If I comment out the whole of the initial block and the always block in the dut.sv, the generated dut_if.sv comes out ok. It is as if your TCL script is not parsing the input source correctly. Note, in case it was a dos vs unix thing, I tried using dos2unix and unix2dos on the dut.sv but it didn't make any difference. I also tried removing the leading whitespace on every line but also didn't have any effect.

Kevin, I will definitely look into this. It looks like you have provided enough info for me to trace this down.

Until then, I hope you are not hung up on the generator. It is really only a nice to have, attempt to save the tester some code writing time. The generator is a VERY simplistic parser and it is not fully compliant with SystemVerilog syntax. There may be some statements of its limits in the doc. (I have not looked at this project in several years now)

This project was my attempt to learn some SystemVerilog. It is a reconstruction of the VHDL testbench system, also published here on Opencores by me. I have NEVER used this to actually test something real.

I did not expect anyone to actually use this project for real work. After all, this system completely dummies down SV to a scripting system ... kind of.

Also, if you know any tcl/tk, feel free to hack at it to make it do what you need.

Ken

Hi Ken, "this system completely dummies down SV to a scripting system" ..

to me, this is the power of your application. We needed a way to quickly code up new testcases, swap to a new testcase and not have to compile the whole design each time. Your approach with the stm file makes it almost as easy as writing plain English. We have been using your vhdl testbench system and it has been working great, but for various reasons, going forward we need a SystemVerilog solution.

Do you think it should be relatively simple for me to manually fix the errors in the output files? (tb_if.sv, tb_mod.sv, tb_dut.sv). If yes, then so long as the stm parsing/cmd generation code is working properly then I should be able to manage with what I've got for now.

"The generator is a VERY simplistic parser" .. my dut is going to be quite simple, and I will need the testbench to interface to a couple of AXI4 interfaces, so hopefully there wont be any complex syntax to trip up your parser.

I can imagine its going to be hard for you to debug your own tcl, let alone me having a go at it. Years ago I worked for a large EDA company and wrote tcl all the time, but I am very rusty now.

Ultimately I need to decide if my SystemVerilog Testbench Framework is going to use your application, or whether I have to opt for some other, completely different approach. I am restricted at the moment to using Xilinx Vivado simulator, and it appears UVM isn't really supported, also it is a directed stimulus, not random that I need, and I wont be needing code coverage, so yours is a really good fit and tantalizingly close to working,

Kevin

Kevin, It is kind of refreshing to hear some of the things you said. It is exactly why I though publishing it would be of some benefit to someone. I am glad the VHDL version has been working for you.

All that said, I managed to look over what I have on my current system. I have both 8.5 and 8.6 tcl installed, and 8.6 is my default, meaning no more Iwidgets. The tb_gen.tcl gui functions for me in that it does output what looks like correct and complete code. (I ran it from a 8.5 shell by sourcing tb_gen.tcl) What it does NOT do is progress the feedback bar to 100%. With a couple little tweaks, that was easy to fix.

Now I program all my gui applications with only the tk items. I will update the gui from the current version on OpenCores. This will take me a few days …

I have to check out a copy of the current repo and make sure all my changes are done there and submitted. The one real problem I have is no way to compile :(

Ken

Hi Ken, that's great news. I will happily use your fixed gui version or tb_gen_cmd. I am not sure of the best way to get it to me, I wonder if my opencores address would suffice for this sort of thing:

bbear1@openco... (@opencores.org)

Kevin

Please find a new version of tb_gen.tcl. I found a bug in the 1.0 version, now Beta 1.1.

As you described, the output of the mod file was being truncated. My local version did not have this issue.

Let me know how it goes. Ken

Hi Ken, I tried your latest tb_gen.tcl and can confirm that it completes and the bar shows 100%, however it still has the same issue in terms of generating bad SV code. Note, I had to make one change to your tb_gen.tcl and that was to point to the iwidgets version which came with activetcl..

package requires

##KM, ORIG: package require Iwidgets 4.0 package require iwidgets 4.1

Here is an extract from the generated tb_mod.sv..

////////////////////////////////////////////// // DUT signals logic data_in; logic data_in; logic 0; logic 32'h00000000;

(the last two lines result in simulator compile/elab errors)

I am not sure if you are using the same DUT, so here is what I am using:

module dut_module ( rst_n, // reset not clk, // input clock out1, // output buss one out2, // output buss two addr, // address data_in, // write data data_out, // read data sel, // select ack // acknowlage out. );

input rst_n; input clk; output 31:0 out1; output 31:0 out2; input 31:0 addr; input 31:0 data_in; input sel; output 31:0 data_out; output ack;

logic rst_n; logic clk; logic sel; logic ack; logic 31:0 out1; logic 31:0 out2; logic 31:0 addr; logic 31:0 data_in; logic 31:0 data_out;

initial begin
  out1 =  32'h00000000;
  out2 =  32'h00000000;
  ack  =  1'b0;
  data_out = 32'hzzzzzzzz;
end

always @(posedge clk) begin
  if(rst_n  == 0) begin
    out1  = 0;
    out2  = 0;
    data_out = 32'hzzzzzzzz;
    ack   = 0;
  end else if (sel == 1) begin
    if(addr == 0) begin
      out1 = data_in;
    end else begin
      out2 = data_in;
    end
    #1;
    ack  = 1;
    #1;
    ack  = 0;
  end else begin
    ack  = 0;
  end
end

endmodule // dut_module

I also had to modify the template slightly to uncomment the Read, Write and Verify instructions, I don't see that could be causing the issue though.

Interestingly, if I use your test_dut.sv for the DUT and generate the testbench for that I dont see any issue!

I understand that your parser is not bullet proof but the above code for my dut is very basic. I guess there must be something about it though that is tripping up your parser.

When you get time would you be able to run the above dut code on your side and see if you get the same issues?

Kevin

Kevin, I did try to send you an email using the opencores addi, but it bounced ...

I will review fully what the OC repo contains and compare against my local work. If there is more differences, then I failed to keep OC updated with the latest. (which is bad) If you could send me enough of your module definition to generate from, I will use it for my testing.

Send to sckoarn at storm dot ca

It will be several hours till the end of my work day. I will have a look when I get home. EST time zone.

Ken

Hi Ken, I see now that the difference in the dut between yours and mine (which I am pretty sure I got from your repo originally) is that yours only has the ports, whereas 'mine' includes an initial begin and always block. In a real world I would only have synthesizable code in the dut, so perhaps what I took as being your dut file, was not meant for that purpose at all? If I comment out the initial begin and always blocks from my dut file then I get good code, Kevin

Ken, I remember where I got the dut.sv originally, it came from your examples directory (examples/standard/sv/dut.sv) I will send you my files to the address you gave me, Kevin

All this time later, Kevin has been able to use the system to do his work. The tb_gen GUI has had an upgrade both for tcl/tk language usage (now should work by default on standard tcl/tk installs) and a bit of work on the parser. The parser has been put in a separate file and a source button added to the GUI for rapid development. Due to the vast SV definitions that can be stated in a top DUT module, I will not be trying to add more features to it.

Feel free to enhance for yourself.

No fixes were needed in the base SV package code ...