[J-core] nvc and j-core project RTL

[Rob Landley]

Following up on http://lists.j-core.org/pipermail/j-core/2016-May/000164.html
here's the email thread we've had so far with the nvc maintainer and
our attempts to build the stripped down jcore tarball attached to
that message with his tools:

Rob

> On 02/05/16 06:26, D. Jeff Dionne wrote:
> Nick,
>
> Thanks for making available your excellent nvc. We are trying to use it to
> lower the barrier for people wanting to try out the J-Core project
> http://j-core.org We ran into some difficulty when trying to run our CPU
> test bench in nvc, and I wonder if anything immediately obvious jumps out at
> you as to the cause.
>
> J-Core uses a lot of higher level VHDL, and as such is a good stress test of
> any tool you throw it at. So far, everything including and especially the
> proprietary synthesis tools for standard cell require simplifications to e.g.
> the configuration selection mechanics. This was also necessary for nvc. The
> attached tarball is a modified version of just the RTL, manually configured
> for a 'pure' VHDL testbench that will analyse and elaborate on GHDL and nvc.
> The run output from both tools is shown below.
>
> Yesterday's nvc from github also fails with this RTL, but it does so
> differently. Note also that the elaboration time is quite long.
>
> The shell scripts included in the attached tarball for nvc and ghdl show how
> to analyse and elaborate the sources, but nothing special is necessary.
> Taking diffs from our original j-core releases against the public RTL on
> j-core.org <http://j-core.org> is also interesting, and shows which language
> features we've used that cause nvc problems.
>
> Thanks again for making nvc available!
> J.
>
> jeff:nvc jeff$ git log | head -3
> commit c84b2983b693c5646d24788b27d26780c0d2a93f
> Author: Nick Gasson <nick at nickg.me.uk <mailto:nick at nickg.me.uk>>
> Date: Sun May 1 17:04:03 2016 +0100
> jeff:nvc jeff$
>
> jeff:src jeff$
> jeff:src jeff$ ./nvc.sh
> ** Note: initialising [4ms +3192kB]
> ** Note: loading top-level unit [0ms +68kB]
> ** Note: elaborating design [140ms +21944kB]
> ** Note: optimising design [13ms +152kB]
> ** Note: grouping nets [229407ms +8480kB]
> ** Note: saving library [23ms +12kB]
> ** Note: generating intermediate code [50ms +9348kB]
> ** Note: generating LLVM [152ms +12804kB]
> /opt/LLVM/bin/llc -relocation-model=pic
> /Users/jeff/work/open-source-release/components/cpu/src/work/_WORK.CPU_PURE_TB.final.bc
> -filetype=obj
> /usr/bin/gcc -bundle -flat_namespace -undefined dynamic_lookup -o
> /Users/jeff/work/open-source-release/components/cpu/src/work/_WORK.CPU_PURE_TB.final.so
> /Users/jeff/work/open-source-release/components/cpu/src/work/_WORK.CPU_PURE_TB.final.o
> ** Note: linking [420ms +5132kB]
> jeff:src jeff$
> jeff:src jeff$
> jeff:src jeff$
> jeff:src jeff$
> jeff:src jeff$ nvc -r cpu_pure_tb
> Assertion failed: (remain >= g->length), function _set_initial, file
> src/rt/rtkern.c, line 558.
>
> *** Caught signal 6 (SIGABRT) ***
>
> -------- STACK TRACE --------
> 1 libsystem_kernel.dylib 0x00007fff8ed96002 __pthread_kill + 10
> 2 nvc 0x000000010647e902 vhpi_cb_reason_str.buf + 32498
> 3 nvc 0x0000000106256716 abort + 22
> 4 nvc 0x00000001062566f1 __assert_rtn + 81
> 5 nvc 0x000000010575863a _set_initial + 1354
> 6 _WORK.CPU_PURE_TB.final.so 0x0000000106e2facb WORK.CPU_PURE_TB.elab_reset + 9947
> 7 nvc 0x000000010575d528 rt_call_module_reset + 104
> 8 nvc 0x000000010575b544 rt_restart + 724
> 9 nvc 0x00000001056e065e process_command + 4814
> 10 nvc 0x00000001056df150 main + 1104
> 11 libdyld.dylib 0x00007fff8b42e5ad start + 1
> 12 ??? 0x0000000000000003 0x0 + 3
> -----------------------------
> jeff:src jeff$
> jeff:src jeff$
> jeff:src jeff$ time ./ghdl.sh
> real0m4.155s
> user0m3.447s
> sys0m0.170s
> jeff:src jeff$
> jeff:src jeff$
> jeff:src jeff$ ./cpu_pure_tb
> ../../src/ieee/numeric_std-body.v93:2098:7:@0ms:(assertion warning):
> NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
> ../../src/ieee/numeric_std-body.v93:2098:7:@0ms:(assertion warning):
> NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
> ../../src/ieee/numeric_std-body.v93:2098:7:@0ms:(assertion warning):
> NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
> ../../src/ieee/numeric_std-body.v93:2098:7:@0ms:(assertion warning):
> NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
> LED: Write at 108000000 fs
> LED: Write at 180000000 fs
> LED: Write at 236000000 fs
> LED: Write at 3996000000 fs
> LED: Write at 8460000000 fs
> LED: Write at 11220000000 fs
> LED: Write at 16316000000 fs
> LED: Write at 18820000000 fs
> LED: Write at 20340000000 fs
> LED: Write at 28500000000 fs
> LED: Write at 30572000000 fs
> LED: Write at 32644000000 fs
> LED: Write at 34812000000 fs
> LED: Write at 36972000000 fs
> LED: Write at 39132000000 fs
> LED: Write at 48684000000 fs
> LED: Write at 50612000000 fs
> LED: Write at 58540000000 fs
> LED: Write at 66700000000 fs
> CPU tests passed
> DDR Init
> GDB Stub for HS-2J0 SH2 ROM
> revision: open
> build: Sat Apr 30 17:59:34 JST 2016
> $T0500:00000000;
> 01:abcd0100;
> 02:00000000;
> 03:00000007;
> 04:0000000a;
> 05:10000000;
> 06:00000003;
> 07:000041c8;
> 08:00000008;
> 09:00000009;
> 0a:0000000a;
> 0b:0000000b;
> 0c:0000000c;
> 0d:0000000d;
> 0e:00000000;
> 0f:00007ffc;
> 10:000001a4;
> 11:000001a4;
> 12:00000000;
> 13:00000000;
> 14:ffff8000;
> 15:00000000;
> 16:00000001;
> ^C
> jeff:src jeff$=

------------------------------------------------------------

> On May 5, 2016, at 6:13 AM, Nick Gasson <nick at nickg.me.uk
> <mailto:nick at nickg.me.uk>> wrote:
>
> Hi Jeff,
>
> This is a really useful test case. I haven't tried running nvc on such a
> large design before, or one that uses record signals so heavily. I've
> managed to improve the elaboration performance, and fix the assertion
> failure you were seeing. Currently it fails at runtime with a spurious
> out-of-bounds error that I haven't managed to debug yet. Hopefully I
> will get some time to work on it at the weekend.
>
> Thanks!
> Nick

--------------------------------------------------------------------

> On 08/05/16 07:37, D. Jeff Dionne wrote:
> Hi Nick,
>
> I tried your latest git checkin, and it corrects the 'range' bug, and then seems
> to hang. I realised that at this point, it might not be clear how to find which
> signals are misbehaving. Not sure if this is helpful, but a little background
> into the design might help in tracking down that misbehaviour.
>
> Here are relevant GHDL traces from where I would start looking:
>
> [PastedGraphic-10.tiff]
>
> The top 2 are obvious. The processor has to be in a 'slot', which is
> essentially a global enable, to issue instructions (and write back, etc). It is
> a combinatorial signal of e.g. memory bus state, etc and at this early stage
> should just always be asserted. The reset microcode (lines counted by addr,
> reset is code 0300) will if_issue (instruction fetch issue), leading to a fetch
> cycle (at 35ns). PC and if_dr (instruction fetch data register) show the first
> instruction fetch cycle (at 45 and 55ns, respectively).
>
> The same traces from NVC:
>
> [PastedGraphic-12.tiff]
>
> We can't see addr[] or code[] record members in the FST file, so I made signals
> to let us see them, because it wasn't clear what was happening otherwise (diff
> below). It shows that the microcode sequencer is running initially, stepping
> through the 'system plane' 0300 reset microcode, but then slot is de-asserted
> and once it drops, everything stops.
>
> Finding what de-asserts slot seems to be the next step to tracking down what
> signal is incorrect.
>
> Progress...
>
> Cheers, J.
>
> jeff:src jeff$ hg diff
> diff -r 9c1473129d98 decode_core.vhd
> --- a/decode_core.vhdSun May 01 18:32:55 2016 +0900
> +++ b/decode_core.vhdSun May 08 15:29:02 2016 +0900
> @@ -52,6 +52,9 @@
> signal maskint : std_logic;
> signal delay_slot : std_logic;
>
> + signal addr_p : std_logic_vector(7 downto 0);
> + signal code_p : std_logic_vector(15 downto 0);
> +
> signal this_c : decode_core_reg_t;
> signal this_r : decode_core_reg_t := reset_vector;
>
> @@ -104,6 +107,9 @@
> end;
> begin
>
> + addr_p <= op.addr;
> + code_p <= op.code;
> +
> decode_core :
> process(this_r,slot,next_id_stall_a,ilevel_cap,dispatch,maskint_next,delay_jump,event_i,next_op)
> variable this : decode_core_reg_t;
> begin
> jeff:src jeff$
>
> Cheers,
> J.

----------------------------------------------------------------------

On 05/09/2016 04:44 PM, Nick Gasson wrote:
> Hi Jeff,
> 
> Thanks very much for investigating this. I was thinking I'd have to
> implement dumping record signals first (which I'll have to do soon
> anyway...).
> 
> Thanks,
> Nick
> 
> 

---------------------------------------------------------------------

> On 07/05/16 00:41, Rob Landley wrote:
> Can I forward this reply to the j-core at j-core.org mailing list? We've
> got people asking about ICE40 over at
> https://plus.google.com/+ChristopherFriedt/posts/Tr4NbfdXMJ3 and I
> wanted to give them a status update.
>
> Thanks,
>
> Rob

---------------------------------------------------------------------

On 05/09/2016 04:45 PM, Nick Gasson wrote:
> I don't mind, but I'm not sure what the connection is with ICE40? This
> is just a simulation tool.
>
> Thanks,
> Nick

--------------------------------------------------------------------


On 05/09/2016 11:33 PM, D. Jeff Dionne wrote:
> We're not sure yet if there are limitations in the NVC tree that cause
> a problem. What we really want is to have the same front end for both
> sim and synth.
>
> We have been hacking on the Verific (proprietary, we have an eval
> binary only of the library) front end for yosys, and I'm pretty sure
> we now understand what it needs to take in as an AST, and how it uses
> that tree. If we can define a sort of common AST file interchange
> format between your tool and Clifford's, that would be hugely exciting.
>
> Verific is sort of loosely bolted onto yosys with a glue layer of only
> maybe 1k lines of C++. If it was C it would only be maybe 300 lines,
> but I digress ;) Verific makes available a tree, post elaboration,
> which is walked by this code and instantiates elements node by node
> into a yosys internal tree, and/but when something that doesn't have
> a translation method shows up in the Verific tree, yosys asks for
> Verific to flatten it to simple wires and gates level (which closes
> off certain optimisation possibilities, of course). This is the part
> I think that is missing because, as you say, nvc is only a sim tool.
> I have been hacking the Verific translation layer, complete enough now
> so that there are very few of those cases left...
>
> Cheers,
> J

-------------------------------------------------------------------------

On 05/09/2016 11:44 PM, D. Jeff Dionne wrote:
> And just to be clear, the thinking would be Verific goes away, and nvc
> writes a tree that a new front end glue layer for yosys reads. The
> above I think shows that nvc would not need to flatten to gates (which
> would be counterproductive anyway) since Verific rarely needs to.
>
> A new or augmented lower.c pass would do the heavy lifting, if I
> understand your source correctly.
>
> J

------------------------------------------------------------------------

On 05/10/2016 01:39 AM, Nick Gasson wrote:
> Ah, I see. That's really interesting! Yes, I think for synthesis it
> would be the same up to and including the elaboration phase in elab.c.
> That produces a single flattened AST object that you could then walk and
> write out the yosys input (BLIF?).
>
> Thanks,
> Nick

----------------------------------------------------------------------

On 05/12/2016 04:23 PM, Nick Gasson wrote:
> Try with the latest git master? It outputs the same prints as GHDL, but
> generates some "address has an X for data sram" warnings at the start of
> the simulation.
>
> There's also some performance bottlenecks I think could be improved.
>
> Thanks,
> Nick

--------------------------------------------------------------------

On 05/13/2016 02:00 AM, D. Jeff Dionne wrote:
> Tried the latest from git and wow, that's some progress, fantastic!
>
> I've not had a chance to see what the cause of the X are yet, but a
> quick glance says bus monitor is complaining about something. That
> explains why the timing is also off:
>
> GHDL:
> ...
> LED: Write at 50612000000 fs
> LED: Write at 58540000000 fs
> LED: Write at 66700000000 fs
> CPU tests passed
>
> nvc:
> ...
> ** Warning: 1948ns+6: Report Warning: address has an X for data sram
> Process :cpu_pure_tb:mon_mem_bus:monitorx
> File bus_monitor.vhd, Line 143
> ...
> LED: Write at 48988000000 FS
> LED: Write at 56916000000 FS
> LED: Write at 65076000000 FS
> CPU tests passed
>
> There must be bus cycles that are taking a different (fewer) number
> of clocks to complete. Geoff may be able to give more insight, but
> I would suspect these are related, and the bus monitor is catching
> these 'bad' cycles on nvc and providing the bus ack early. Why it
> doesn't cause execution to go off the rails is another question...
>
> This is great, thanks for the work. Before the next release, we will
> make sure we add nvc alongside ghdl for simulation in the Makefile
> infrastructure...
>
> Cheers,
> J.

---------------------------------------------------------------------

On 05/13/2016 02:54 AM, D. Jeff Dionne wrote:
> FYI, with nvc starting to work, and the whole simulator thing being
> just a handful of clean, easy to understand, straight C... This
> is a big deal.
>
> Building it requires an install of LLVM (which you can do once) but
> aside from that it builds the nvc tool binary from its dozen or so C
> sources in far less than a minute.
>
> Cheers,
> J.

--------------------------------------------------------------------

On 05/14/2016 02:42 AM, Rich Felker wrote:
> I wonder if it would be plausible to hook it up to libfirm instead of
> llvm for the backend. Then the whole thing would be clean, easy to
> understand, straight C all the way down.
>
> Rich

-------------------------------------------------------------------

On 05/14/2016 02:57 AM, D. Jeff Dionne wrote:
> This is the code generator
> 
> https://github.com/nickg/nvc/blob/master/src/cgen.c
> 
> might even be the only part that touches LLVM directly, except for
> linker support
> 
> https://github.com/nickg/nvc/blob/master/src/link.c
> 
> But I’m not sure that LLVM is really too much of a problem, it
> only takes 10min to compile (for me). That might be because Mac
> is clang by default, though one would think Linux would be a first
> class platform for it.
> 
> My real interest in this is 2fold: 1, GHDL is a pain to build
> because it needs GNAT and 2, it seems very likely the
> post-elaboration Syntax Tree, from (something derived from)
> https://github.com/nickg/nvc/blob/master/src/lower.c could be
> written out in a form that yosys can handle.  If that is the case,
> it would give us at least synthesis for arbitrary asic processes,
> and with the rest of qflow maybe even a full backend flow for mixed
> signal chips.
> 
> Immediately, ICE40 FPGAs become a target we can handle with our own
> tools, and it looks like we can even buy Known Good Die (unpackaged)
> for them.  KGD of those would open the door to selling small digital
> only chips.
> 
> J.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-10.tiff
Type: image/tiff
Size: 165422 bytes
Desc: not available
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160520/5dde3a1d/attachment-0002.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-12.tiff
Type: image/tiff
Size: 233864 bytes
Desc: not available
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160520/5dde3a1d/attachment-0003.tiff>