[J-core] Making NVC work for us

[Rob Landley]

On 03/13/2017 03:05 AM, D. Jeff Dionne wrote:
> Rob,
> 
> 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,

"Not written in ada" goes a long way there.

> and 2, use it as a VHDL front end for other things (at first yosys).

I remember you licensed a proprietary front end to test yosys against,
and had code generation working with that. Did you ever build the "j1"
tarball with that and see if it did anything interesting on ice40?

However, we're not sure about name "j1" for a couple reasons:

1) There's an existing "j1cpu" project (ala
https://twitter.com/mostlymoss/status/840151645606440962).

2) Removing the hardware multiplier doesn't actually change the
instruction set (not if we microcode the shift-and-add version, which I
don't think we did yet but isn't a big deal).

> 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.

That's a bit limiting, yes.

> You had mentioned that asking Tony Bybell (FST maintainer) what
> to do was a good idea... can you do that?

I'll see what I can do. :)

> 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.

It would be nice if there was a standard for abstract syntax trees. Does
yosys document its expected input format?

> 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?

I can shake that tree too...

> *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,

Upgrading NVC. It seems more like we're hitting stuff that's
missing than broken per se. (I expect we're the most complicated
project anybody's fed to that tool yet.)

> but then also having our preprocessor take over the work
> done now with 'configurations'

At some point I expect we'll have to break down and do something
like menuconfig, but we have a pending infrastructure rewrite
I should try to describe for the list before then. :)

Rob