Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-01-14T23:34:57Z

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 #�, this will be next.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-01-15T04:24:50Z

Partial fix in git towards 3.845. Note also #�'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.

Original Redmine Comment
Author Name: Ed Lander
Original Date: 2013-01-15T13:52:08Z

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'

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-01-16T00:26:02Z

Module based is sufficient for now, so resolving.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-02-05T03:21:45Z

In 3.845.

Original Redmine Comment
Author Name: Ed Lander
Original Date: 2013-02-12T16:33:41Z

Hi Wilson,

We have been trialling this fix with 3.845 release, but are still seeing issues:
%Error: /:: 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

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-02-13T00:28:46Z

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

Original Redmine Comment
Author Name: Ed Lander
Original Date: 2013-02-13T12:31:13Z

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

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-02-13T12:59:40Z

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.

Original Redmine Comment
Author Name: Ed Lander
Original Date: 2013-02-14T10:09:13Z

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

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-02-14T11:55:53Z

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

Original Redmine Comment
Author Name: Ed Lander
Original Date: 2013-02-14T11:59:52Z

Cool, thanks!

Original Redmine Comment
Author Name: Ed Lander
Original Date: 2013-02-15T13:33:42Z

Hi Wilson,

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

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

%Error: :: Can't convert defparam value to constant: Param 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

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2013-02-15T13:48:51Z

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.