Project

General

Profile

[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Issue #602

SystemVerilog bind support

Added by Ed Lander over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Unsupported
% Done:

0%


Description

Hi Wilson,

As previously discussed, here is the ticket for an enhancement request for Verilator to support the SystemVerilog 'bind' construct. The bind construct allows us to instantiate verification objects into the design without actually modifying the DUT code itself, and even over-ride parameters and variables. Supporting bind will allow us to use our existing harness, facilitating Verilator C++ model qualification.

Please see attached code for example of a bind; incisive makefile also attached.

The bind command itself is:
  bind i_targetmod mycheck #(
    .param2(param2),
    .param3(top.param3)
  ) i_mycheck(.p2(p2), .p3(top.p3), .*);

This is saying bind mycheck to instance i_targetmod of module targetmod. Therefore i_mycheck will be instantiated inside i_targetmod. Furthermore param2 and param3 will take vales from targetmod and top respectively, and i_mycheck ports p2 and p3 will get values from targetmod and top respectively (p1 bound implicitly to targetmod value).

Best regards, Ed

bind_example.sv - SystemVerilog bind example (1.63 KB) Ed Lander, 01/14/2013 04:59 PM

bind_example-incisive.mk - Incisive makefile (1.11 KB) Ed Lander, 01/14/2013 04:59 PM

bind_example_2.sv (2 KB) Ed Lander, 02/15/2013 01:33 PM

History

#1 Updated by Wilson Snyder over 6 years ago

I looked at the spec after you mentioned this and there are several forms. The module name format and direct path forms are straightforward. Your example only uses a single non-dotted path. Is the module form needed? Is the dotted hierarchical path form needed? At present Verilator computes what modules are under each other before knowing their dotted paths, so it's much easier not to support dots if that'll satisfy you for the moment. Not insolvable by any means, but just another assumption from Verilog that needs to be relaxed.

I'm in the middle of changes for bug600, this will be next.

#2 Updated by Wilson Snyder over 6 years ago

  • Status changed from New to Assigned

Partial fix in git towards 3.845. Note also bug600's fixes which are in git before this may have made the git version more unstable than usual until the next release.

I committed supporting bind to a target module name, which is different from the example you provided but is perhaps sufficient if you can make minor source changes. If not, let me know if not having dotted references is ok; specifically the instance name specified would need to be that of a cell not under a "generate" block in the same module as the bind statement. Finally let me know if you need the specific instance form (bind a : ...), though that seems to be not well supported in other simulators.

#3 Updated by Ed Lander over 6 years ago

Hi Wilson,

Thanks for the quick action. The bind to target module is actually the typical form that we use, so that's fine (I was experimenting a little bit with the example by binding only to one instance). With regards to supporting dotted hierarchical paths (ie. full hierarchical references), this is something we would like supported ultimately, but we can live without it for now. Is it worth submitting a separate enhancement request for that functionality (with lower priority), so we can close this ticket as partial bind support => 3.845?

Cheers, Ed

P.S. With regards to the complexity of implementing full hierarchical path binding support, it's probably worth mentioning the restrictions in the SV language itself; from IEEE spec: 'It shall be an error for a bind statement to bind a bind_instantiation underneath the scope of another bind_instantiation.' Or (in Doulos speak): 'You may not bind underneath another bound instantiation'

#4 Updated by Wilson Snyder over 6 years ago

  • Status changed from Assigned to Resolved

Module based is sufficient for now, so resolving.

#5 Updated by Wilson Snyder over 6 years ago

  • Status changed from Resolved to Closed

In 3.845.

#6 Updated by Ed Lander over 6 years ago

Hi Wilson,

We have been trialling this fix with 3.845 release, but are still seeing issues: %Error: <path>/<file>:<line>: syntax error, unexpected bind

verilator -V: Verilator 3.845 2013-02-04 rev verilator_3_844-58-gbcadb0b

This is the syntax that is upsetting it:
  bind bind_target binding_module #(
    .param1(param1),
    .param2(param2)
  ) binding_module_instance();

Any ideas? Would you need to see the actual code?

Cheers, Ed

#7 Updated by Wilson Snyder over 6 years ago

Please file a new bug with a test_regress style testcase and/or modify test_regress/t/t_bind.v to show the problem.

#8 Updated by Ed Lander over 6 years ago

Hi Wilson,

We've been debugging this and it doesn't seem to be lack of support for our bind statements, rather the order in which the modules are declared vs them being bound. Consider us unblocked :)

Cheers, Ed

#9 Updated by Wilson Snyder over 6 years ago

I don't see an obvious difference between handing of bind and cells, so order shouldn't matter and trying before & after in my test works. When you figure it out please post a bug as it's likely very simple to fix.

#10 Updated by Ed Lander over 6 years ago

Clarification: as you say, it's not the order, it was moving the bind statements from outside the module to inside. Shall I still submit a ticket or is this expected behaviour?

Cheers, Ed

#11 Updated by Wilson Snyder over 6 years ago

Ah, simple one liner. Fixed in git towards 3.846.

#12 Updated by Ed Lander over 6 years ago

Cool, thanks!

#13 Updated by Ed Lander over 6 years ago

Hi Wilson,

We've been seeing the following types of messages when trying to build our full design (inc. binds):

%Error: <file>:<line>: Expecting expression to be constant, but can't convert a VARXREF '<parameter>' to constant.

%Error: <file>:<line>: Can't convert defparam value to constant: Param <parameter> of <bound_instance>

We've driven your t_bind2.v test-case through the flow, and noticed that the parameters don't include hierarchical references:
   bind targetmod mycheck
     #(
       .param2(param2),
       .param3(param3)
       )
   i_mycheck (.p2(p2), .p3(p3), .*);

Our original example was like this, eg:

  bind i_targetmod mycheck #(
    .param2(param2),
    .param3(top.param3)
  ) i_mycheck(.p2(p2), .p3(top.p3), .*);

Once correcting the bind to module (not instance), we see the same Errors:

%Error: bind_example.sv:32: Expecting expression to be constant, but can't convert a VARXREF 'param3' to constant.

%Error: bind_example.sv:32: Can't convert defparam value to constant: Param param3 of i_mycheck

Simplifying the bind to this is OK:
  bind targetmod mycheck #(
    .param2(param2)
  ) i_mycheck(.p2(p2), .p3(top.p3), .*);

So the hierarchical references for the port binding is fine, but it seems like the hierarchical references for the parameters is not. Is this in line with your intention?

Cheers, Ed

#14 Updated by Wilson Snyder over 6 years ago

Please file a new bug on this rather than attaching to a closed bug (so I don't loose it), and attach a complete test case and I'll take a look, thanks.

Also available in: Atom