[J-core] Making NVC work for us

D. Jeff Dionne Jeff at SE-Instruments.co.jp
Mon Mar 13 04:05:48 EDT 2017


As we discussed, NVC from https://github.com/nickg/nvc has for a while been able to build a simulator executable from a pre-processed and slightly modified version of our RTL code (see below*)

We have 2 use cases for NVC:  1, replace GHDL with a lighter and more approachable code base, and 2, use it as a VHDL front end for other things (at first yosys).

As a GDHL replacement, the main problem is not the simulator itself, it is the writing out of waveform files. Nick glued an FST file format writer library, from the gtkwave project, into NVC:  https://github.com/nickg/nvc/blob/master/src/rt/fst.c and https://github.com/nickg/nvc/tree/master/thirdparty It seems that FST doesn't know how to serialize complex data types used in VHDL (as opposed to simple booleans and integers, used in Verilog) and so the FST glue just prints an error when it tries to write waveforms from our RTL.  You had mentioned that asking Tony Bybell (FST maintainer) what to do was a good idea... can you do that?

As for using it as a front end, that is an interesting project.  I found a command line switch that dumps out the internal AST, either after parsing or after 'elaboration' (e.g. constant folding).  This output isn't in a format that is useful to us, but it does prove that the internal structures are likely there to allow this use case.  The best thing I think is to emit some sort of intermediate format, and have that consumed by other tools.

All of this is 'nice to have'.  It would be great if we could figure out how to get it done without assigning engineer time.  What about a GSoC or the like?

*There may still be problems with the idiosyncratic 'configuration' (VHDL language keyword) based selection of different implementations (e.g. FPGA family, ASIC, simulator... but also things like CPU build options).  Other tools seem to have similar problems (ASIC tools, for instance) and a good solution to that language conformance issue likely means fixing NVC, but then also having our preprocessor take over the work done now with 'configurations'

More information about the J-core mailing list