[J-core] json instructions set

Cedric BAIL cedric.bail at free.fr
Mon Jul 10 13:51:18 EDT 2017


Hi,

On Tue, Jun 27, 2017 at 10:11 AM, Cedric BAIL <cedric.bail at free.fr> wrote:
> On Mon, Jun 26, 2017 at 10:28 PM, D. Jeff Dionne
> <Jeff at se-instruments.co.jp> wrote:
>> On Jun 27, 2017, at 9:12, Cedric BAIL <cedric.bail at free.fr> wrote:
>>> So I have been working on making
>>> http://www.shared-ptr.com/sh_insns.html more usable for developping
>>> new instructions as I think we are taking the road of adding more of
>>> them in the future and we need also an easier way to discuss future
>>> propoal I think.
>>
>> Thanks for that, (the) one thing missing from the J-Core IP set is a coherent documentation suite.
>>
>>> I have put my work on https://github.com/Bluebugs/sh-insns . It
>>> require to be installed either locally or on a webserver. It doesn't
>>> require any database or anything, it uses client side Javascript for
>>> everything (which make it a bit heavy on your computer, but it isn't
>>> too bad considering the benefit). This new webpage allow for sorting,
>>> filtering and regexp based search on the entire instructions set (and
>>> you can combine this together). The instructions themself are actually
>>> described in a separate JSON file (thus the title of the email) that
>>> would allow pull request discussion for expanding the J-Core
>>> instructions set.
>>
>> The CPU core decoder RTL is automatically generated from an OpenDoc spreadsheet at the moment.  This may or may not have been a good choice, but it was at least fairly easy to work with.  Javascript might have been better.
>
> I have started looking at it, but was a bit too much of work for me
> for the time I had, that why I switched to do something that I deemed
> a better use of my time. I may have to go back at it later.
>
>> The javascript and the .ods diverge in purpose, with the .ods specifying pipeline control, and this new javascript trying to document.  And and still there remains 2 (or 1 1/2) problems unsolved by either, the autogeneration of a (hopefully, cycle accurate) simulator and databook quality instruction set reference.  I had this vague idea that the documentation web pages would display a pipeline diagram, and show cycle by cycle what happens...
>
>> I have been thinking that what we need is a source format that generates all of these things.  The javascript seems a better place to start from a structure point of view, likely importing the information in the .ods from the RTL distribution.
>
> I would love to see this. I guess that a possible evolution would be
> to have the information of the ods injected inside the JSON and
> generate things from it. I definitively like the idea of having a web
> page display the pipeline diagram with a cycle by cycle animation of
> what the instruction does. It is also pushing for going into the
> direction of using more Javascript related technologie.

So I have been looking and thinking about this a bit more. Converting
the ods to JSON doesn't seem to be difficult and writing a generator
that would use it to replace the current code that generate the vhdl
seems quite doable (maybe a weekend of work). I would be tackling it
once your code is in a git as a way to learn how the decoder work
(Without the source in a git repository, it would be difficult to
provide a patch and track a moving target). Still, implementing the
same thing, but with javascript and json doesn't seems like it will
fit the need of the j-core project.

I may be wrong here, but the micro code can be different from one
version of the core to another (J1 vs J2 today and later when there is
a FPU for example). I am guessing we want something more configurable.
I kind of understand why there are Python and other system that does
generate VHDL. My guess is that what we really want is a way to
generate VHDL, JSON documentation (that can be used by assembler and
compiler scheduler also) from a source that has configuration flags. I
am not a VHDL expert at all, nor do I know all the existing tools, so
maybe there are tools that would fit the needs of the project already
? Ofcourse this is, if I understand the need correctly.

Best,
-- 
Cedric BAIL


More information about the J-core mailing list