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

Documentation does not specify where `systemc_imp_header may be used #965

Closed
veripoolbot opened this issue Sep 11, 2015 · 3 comments
Closed
Assignees
Labels
area: documentation Issue involves documentation resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Arthur Kahlich
Original Redmine Issue: 965 from https://www.veripool.org
Original Date: 2015-09-11
Original Assignee: Wilson Snyder (@wsnyder)


This comes from trying to cause a statement of the form:

@@#include "headerfilename.h"

to be included in the verilator cpp_output.cpp file. The include file defines an extern "C" function that is called in one of the lower level module files using the verilator $c(" blah "); mechanism.

I cannot deduce from the documentation what is wrong with the following lines, whether placed within or outside of a module definition in a lower level Verilog module file:

@@systemc_imp_header @@#include "headerfilename.h" @@Verilog

where the resulting verilator error message is:

@@%Error: some_module_name.v:27: syntax error, unexpected `systemc_interface BLOCK
@@error: Exiting due to 1 error(s)

As far as I can tell, I followed the statements from the manual below:

`systemc_imp_header

Take remaining text up to the next verilog or systemc_... mode switch and place it verbatim into the header of all files for this C++ class implementation. Despite the name of this macro, this also works in pure C++ code.

That says nothing about code locations where this would be unexpected - so where is it expected and where is it not?

This is a request for the documentation to be clarified.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Arthur Kahlich
Original Date: 2015-09-11T21:18:43Z


With correct formatting:

This comes from trying to cause a statement of the form:

to be included in the verilator main_cpp_output.cpp file. The include file defines an extern "C" function that is called in one of the lower level module files using the verilator $c(" blah "); mechanism.

I cannot deduce from the documentation what is wrong with the following lines, whether placed within or outside of a module definition in a lower level Verilog module file:

#include "headerfilename.h"
`Verilog
```

where the resulting verilator error message is:

```%Error: some_module_name.v:27: syntax error, unexpected `systemc_interface BLOCK
Error: Exiting due to 1 error(s)
```

As far as I can tell, I followed the statements from the manual below:

> *`systemc_imp_header*<br>
> Take remaining text up to the next `verilog or `systemc_... mode switch and place it verbatim into the header of all files for this C++ class implementation. Despite the name of this macro, this also works in pure C++ code.

That says nothing about code locations where this would be unexpected - so where is it expected and where is it not?

This is a request for the documentation to be clarified.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2015-09-12T00:19:42Z


They must be a module_item, that is directly within a module/endmodule at the same level as a typical input statement.

Fixed in git towards 3.877.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Arthur Kahlich
Original Date: 2015-09-12T00:52:26Z


Thanks - I was able to discard my sed script hack to work around not knowing how to use these.

@veripoolbot veripoolbot added area: documentation Issue involves documentation resolution: fixed Closed; fixed labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: documentation Issue involves documentation resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants