[libre-riscv-dev] [Bug 72] verilog to nmigen converter (full or partial) needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=72

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
been up investigating this overnight (sigh.. :) )

if the system verilog syntax wasn't monstrously large, writing
a parser from scratch would be a reasonable proposition.

if yosys was up to the task, i agree it would be a good idea to use it.

i considered ilang as an intermediary, however yosys has a habit
of destroying if-elif-elif constructs and replacing them with
casez statements, splitting out individual variables into their
own parallelised state machine, and much other weirdness that would
make it virtually impossible to recognise the output.


not only that: this is a file from e.g. the axi_rab rtl:

yosys> read_verilog fsm_expand.sv 
1. Executing Verilog-2005 frontend.
Parsing Verilog input from `fsm_expand.sv' to AST representation.
Lexer warning: The SystemVerilog keyword `logic' (at fsm_expand.sv:21) is not
recognized unless read_verilog is called with -sv!
fsm_expand.sv:21: ERROR: syntax error, unexpected TOK_ID, expecting ',' or '='
or ')'

it's using *Cadence* system verilog syntax, that even iverilog has
some capabilities missing, due to Cadence violating the verilog standard
and iverilog conforming to it.

yosys doesn't stand a chance: it is missing far too much of system verilog.


i've used it a couple of times: dabeaz wrote an example that was capable
of actually understanding yacc-formatted files, searching for their BNF
strings, and outputting an actual python-ply program that python-ply could
understand.

it's a two-step process that is in no way fully automated, however i have
an 8 *THOUSAND* line LALR parser - that i didn't write - that's
come *directly* out of icarus verilog source code (parse.y pushed through
yply.py).

generated in under a second, needed review, found some bugs in parse.y,
fixed, moved on.


currently i am munging the icarus verilog lex file into python (that
was this morning's successful task)

so that's phase (1)


the phase after that, i have had a lot of success in the past using
lib2to3's AST code, as it was designed to include whitespace (where
the standard python AST library does not), and has some additional
nice features including pattern-matching node-visitors that are
extremely comprehensive and also extremely well-documented.

what's particularly important about lib2to3's AST code is that it
has a dead-accurate pretty-printer.  after all, it *was* written to
do python2-to-python3 and vice-versa code-conversion.


phase 2 is to replace all of the print statements in the auto-generated
code with python lib2to3 AST statements.


phase 3 - which can be done as-and-when - will be to create some
node-visitors that *MODIFY* the python AST, searching for the kinds
of patterns that are expected in verilog, however are silly to keep
in nmigen.

one example is the practice by the eth-zurich team of following a
convention varname_n, varname_q then assigning the varname_n to
the initial input, over-riding it later, and then in a sync block
assigning varname_q <= varname_n - something like that, at least.

lib2to3's pattern-matching node-visitor/walker is a good match for
removing (reworking) the AST to be much more along the lines of
nmigen conventions.



the alternative is to write a simple line-by-line code-converter doing
basic pattern-matching.  i've done that before when converting massive
amounts of java to python.  two weeks to convert 20,000 lines of code,
i was very very bored by the end :)


i'm going to give this maybe... 2-3 days, max, to see if it's a
viable approach (python-ply plus lib2to3's AST+pretty-printer).

if it's not making very *very* rapid progress, i'll re-evaluate
the "string-matcher" version as a way to remove *most* of the
drudge work.  from experience though, i know that such line-by-line
string-matchers are "WORN" - write once, read never :)

irony is, normally this would be considered a major, major software
project in its own right.  it's a good candidate for a NLnet milestone,
which is why i'd like to take it a bit more seriously than just
a "string-matcher"

-- 
You are receiving this mail because:
You are on the CC list for the bug.