Explicit hierarchical reference not resolving in Verilog::Net (CELL outside of module definition) #537
Comments
|
Original Redmine Comment Oh, no Verilog-Perl doesn't actually do anything with the bind. At the moment I unfortunately don't have the time to fix it, but if you'd like to it should be straight forward-ish and I'll take the patch: Add a new bind callback routine in callbackgen. Then have File.pm get that callback and register it in the per-Module.pm structure. In the Module.pm link routine, iterate over the registered binds, find the appropriate scope, and add the appropriate Cell substructures. |
|
Original Redmine Comment What do you mean by 'register it in the per-Module.pm'? I've done the first few steps but have no figured out how to register the callback. I have noticed that there are callbacks in the Bison grammar file (VParseBison.y), is this what you meant? |
|
Original Redmine Comment Sorry was too brief. After you add the new callback name to callbackgen, have VParseBison.y call it similar to the other callbacks but in the action of the rule where yBIND is. Add a "empty" callback to SigParser.pm, this is just a guide so people can see what the callbacks are. Compiling with "make" should work. "make test" should fail on test 35 at least, you can run just that test with "t/35_sigparser.t". That test should fail because it will miscompare with t/35_sigparser.out as you added the new callback, you'll see the test output listing the new callback with the appropriate parameters you passed. Make sure all the information you will need is listed. Then in File.pm (which inherits SigParser) make a callback to receive the new bind callback. This call into a new Module.pm structure method that adds the bind. Now a module knows what's bound, and the last step as said before is to have link use that to link the module - see how Module's _link deals with cells now it should be similar for bound cells. |
|
Original Redmine Comment Closing due to age - if you implemented something for this patches are always accepted. |
Author Name: Brian Mokrzycki
Original Redmine Issue: 537 from https://www.veripool.org
Original Date: 2012-07-26
This is a continuation of a previous issue described in the user forum, found at:
http://www.veripool.org/boards/18/topics/show/887-Verilog-Perl-bind-operator
After the resolution of the previous issue a new issue became apparent where the explicitly named path of the target module to be bound to is not resolving correctly, even though it's both valid systemverilog and a valid path to the target module. I've created a set of source files to highlight the issue.
After downloading the source
This bug was observed on Git hash 6f7ed3a
The text was updated successfully, but these errors were encountered: