-
Notifications
You must be signed in to change notification settings - Fork 56
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
illegal statements with interfaces which do not either raise an error, or generate valid verilog #206
Comments
Another example. Add a task to an interface that uses that same interface in the ports, like e.g.:
This compiles with sv2v to:
However, this is not legal verilog becuase of the ReadPort usage in the copyFrom task. Therefore the sv2v step should fail I feel. |
(basically, if something is declared as an interface, and then still appears in the output verilog, then that should likely automatically trigger an sv2v error perhaps?) |
(I feel like the goal should be that all compile errors are captured by sv2v, so that the verilog compilation always succeeds, see #194 ) |
I've added checks to handle the example you gave in #206 (comment), which now results in: I haven't yet handled the example you provided in #206 (comment). |
Consider the following:
This runs without any error, outputing:
I suppose ReadPort could be imagined to be a verilog typedef, but I think that if such a typdef hasn't been defined, then this code should be illegal, and should raise an error, when compiled with sv2v?
This generates:
As far as I know, assigning one interface instance to another is illegal? In any case, the generated verilog is certainly illegal. I feel that the system verilog above should raise an error, from sv2v, when compiled with sv2v.
The text was updated successfully, but these errors were encountered: