pbreuer
commented
2 years ago And the answer is ... I have had a look at the code of iverilog, and I see no evidence it parses system verilog of any kind. The parser is not mutable, so supplying the flags saying this or that standard can do nothing. They can and do enlarge the lexical keyword set, and maybe let some newer literal constant forms get recognized (accepted/rejected I can't tell). That's it.
I've written a patch to let it prse replicated array entries and it seems to work. But it'll accept that grammar under any flag now. I should do something about that. Anyway, that cut down the syntax errors to a manageable number. Translation should still work if I did it right (I made the syntax tree grow a deep-replicated set of branches/twigs). But I forgot about '{default: foo} and will have to deal with that too. But nothing to do with Clash there. You are very much in the clear.
My fault for not figuring out the state of things earlier.
I have a separate issue in that verilog code generated by Clash is being parsed and compiled by iverilog, but is not simulating right. Verilator completely blows up on even medium sized (40KB) verilog source files from Clash (perhaps a synthesizability question?)
What do people use to simulate verilog and/or system verilog that is open source?
Regards
PTB
leonschoorl
I've been trying iverilog ("icarus verilog") on the system verilog code output from clash (approx 1.6.3) but it won't compile, well, parse, because .... iverilog doesn't seem to accept the repeat notation for arrary literal elements, though it says it implements IEEE1800-2005 (and I am forcing that with -g2005-sv).
Is there a switch to make clash produce array literals without using the element repeat syntax, i.e. literally repeat the element literals?
You have the right of it re the standard:
The iverilog parser errors hundreds of times on the generated files so it's hard to pick a good example, but this is just a random one:
I broke up a long line to get the error line reported. If I replace 4{ foo } by `{ foo,foo,foo,foo } then all is well.
Instead of 90'b0xxx... clash actually generated a concatenation {1'b0, 89'bxxxx...} but that makes no difference to the error.
Can somebody confirm that the system verilog is OK, clash is right, iverilog is wrong? I don't read verilog well enough to figure. There's a concatenation outside of the inner function evaluation that might be throwing me.
Does a clash switch to emit system verilog array repeats "longhand" exist?
(I have tried both stable 11.0 and development 12.0 iverilog).
Any info welcome.
Regards
PTB