[J-core] Fwd: Re: nvc and j-core project RTL

[Rob Landley]

The bug causing timing differences between nvm and ghdl has been tracked
down and fixed. Jeff described it here:

  http://lists.j-core.org/pipermail/j-core/2016-June/000186.html

And below is the email thread about fixing it.

Anybody wanna try feeding the full j2 SOC (not just the stripped down j1
without peripherals) into nvc and see what breaks? :)

And/or adjust the build system to use nvc instead of ghdl for the
simulation it already does...

The other big thing is trying to glue yosys onto the back end of nvc, as
Jeff talked about a bit at the above link.

Rob

-------- Forwarded Message --------
Subject: Re: nvc and j-core project RTL
Date: Fri, 10 Jun 2016 06:25:15 +0900
From: D. Jeff Dionne <Jeff at SE-Instruments.com>
To: Nick Gasson <nick at nickg.me.uk>
CC: D. Jeff Dionne <Jeff at SE-Instruments.com>, Rich Felker
<rfelker at se-instruments.com>, Rob Landley <rob at landley.net>, Geoff
Salmon <gsalmon at se-instruments.com>

On Jun 10, 2016, at 6:11 AM, Nick Gasson <nick at nickg.me.uk> wrote:
> 
> OK, I've managed to fix this one!


Confirmed, identical output!  Fantastic :)

Cheers,
J.

> The problem was with the sensitivity
> list generation for the data_buses procedure in the top level. With the
> latest git master, I get the same output as GHDL with the same
> timestamps.
> 
> I think there's some more work I can do to improve simulation
> performance. Hopefully I can work on this a bit at the weekend.
> 
> Thanks,
> Nick
> 
> On Fri, 13 May 2016 16:00:31 +0900
> "D. Jeff Dionne" <Jeff at SE-Instruments.co.jp> wrote:
> 
>> On May 13, 2016, at 6:23 AM, Nick Gasson <nick at nickg.me.uk> 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.  
>> 
>> 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.
>> 
>>> 
>>> There's also some performance bottlenecks I think could be improved.
>>> 
>>> Thanks,
>>> Nick
>>> 
>>> 
>>> On 10/05/16 05:44, D. Jeff Dionne wrote:  
>>>> On May 10, 2016, at 13:33, "D. Jeff Dionne"
>>>> <Jeff at SE-Instruments.com> wrote:  
>>>>> 
>>>>> I have been hacking the Verific translation layer, complete
>>>>> enough now so that there are very few of those cases left...  
>>>> 
>>>> 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
>>>> 
>>>>> 
>>>>> Cheers,
>>>>> J
>>>>> 
>>>>>> Thanks,
>>>>>> Nick
>>>>>> 
>>>>>> 
>>>>>>>> On 07/05/16 00:41, Rob Landley wrote:
>>>>>>>> On 05/04/2016 04:13 PM, Nick Gasson 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  
>>>>>>> 
>>>>>>> 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  
>>>>>> 
>>> 
>> 
>