Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SystemVerilog bind support #602

Closed
veripoolbot opened this issue Jan 14, 2013 · 14 comments
Closed

SystemVerilog bind support #602

veripoolbot opened this issue Jan 14, 2013 · 14 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Jan 14, 2013


Author Name: Ed Lander
Original Redmine Issue: 602 from https://www.veripool.org
Original Date: 2013-01-14
Original Assignee: Wilson Snyder (@wsnyder)


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

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 14, 2013


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 15, 2013


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 15, 2013


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'

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 16, 2013


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


Module based is sufficient for now, so resolving.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 5, 2013


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


In 3.845.

@veripoolbot veripoolbot closed this Feb 5, 2013
@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 12, 2013


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

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 13, 2013


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 13, 2013


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

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 13, 2013


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 14, 2013


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

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 14, 2013


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.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 14, 2013


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


Cool, thanks!

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 15, 2013


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

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 15, 2013


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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.