[J-core] json instructions set

Cedric BAIL cedric.bail at free.fr
Wed Jul 12 15:06:20 EDT 2017


On Mon, Jul 10, 2017 at 11:10 PM, D. Jeff Dionne
<jeff at se-instruments.co.jp> wrote:
> On Jul 11, 2017, at 2:51, Cedric BAIL <cedric.bail at free.fr> wrote:
>> 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).
>
> Great, that would be really good.  One issue, however.  The current code is using a Java package called vmagic for VHDL handling.

Oh, I hadn't see that. Dang !

> This means that the tool actually reads and parses(!) the VHDL for the packages that the decoder interfaces with.  It does this to gain a knowledge of the ports and types necessary.  It isn’t (so much) a text manipulation, it actually ‘understands' the code it’s making and the interfaces that code connects to.

Does it just need to understand the package interface or does it need
to understand more than that ? Where is that code located in the
latest tarball ?

> The same thing is done for the ‘SoC Generator’ tool, it understands the types the IP blocks from the actual RTL code.  It uses this to generate the top level RTL, but not from a text template, but by knowing that, e.g. the UART has an Rx pin, and the top-level has an Rx pin, and therefore it has to make a signal to connect those.  Same with CPU busses, bus muxes, etc.

It does sounds cool and scary at the same time :-)

> For the decoder, there might be an argument that this type of functionality is perhaps overkill.  For the SoC gen, it’s a critical function.

I see. My main concern with tool that parse VHDL... is that this is a
hard task. It is quite difficult to find a parser that produce a full
AST here. The best I can find in JS is something that extract the
interface (thus my question above). And I am not a fan of getting into
writing a VHDL parser :-D

>> 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).
>
> Yes, or for instance multiple parallel pipelines.  Then, the whole ‘understands the RTL’ thing starts to look a lot less overkill...

Oh ! So for better long term support, we really need to have a tool
that does understand VHDL.

>> 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.
>
> Yes, I think that’s correct.  The SoC gen, for instance, uses a fairly declarative language to describe the SoC you are after.
>
> For example, here is how a UART is described to soc gen in the library of common SoC modules:
>
>  {:entity "uartlitedb"
>   :dt-name "serial"
>   :dt-props {:compatible ["jcore,uartlite" "xlnx,xps-uartlite-1.00.a"]
>              :device_type "serial"}
>   :left-addr-bit 3
>   :regs [{:name "rx"
>           :width 1
>           :addr 3}
>          {:name "tx"
>           :width 1
>           :addr 7}
>          {:name "status"
>           :width 1
>           :addr 11}
>          {:name "ctrl"
>           :width 1
>           :addr 15}]
>   :generics {"fclk" CFG_CLK_CPU_FREQ_HZ}}
>
> And here is the ‘instantiation’ in the SoC design.edn file for Turtle:
>
>   {:class "uartlite"
>    :name "uart0"
>    :base-addr 0xabcd0100
>    :irq 1
>    :generics {"intcfg" 1
>               "bps" 38400e0}
>    :dt-props {:current-speed (38400)
>               :port-number (0)}
>    :dt-stdout true}
>
> The result of soc gen is the RTL for the top level (pad ring), the RTL that connects all the modules together, the Linux Device Tree specification input file, header files, and possibly a few other things:

Is the Linux Device Tree file also generated by that same tool ?

> devices.vhd:
>
> entity devices is
>     port (
>>         uart0_rx : in std_logic;
>         uart0_tx : out std_logic
>     );
>>     type device_t is (NONE, DEV_AIC0, DEV_AIC1, DEV_CACHE_CTRL, DEV_EMAC, DEV_FLASH, DEV_GPIO, DEV_UART0);
>>     function decode_address (addr : std_logic_vector(31 downto 0)) return device_t is
>     begin
>         -- Assumes addr(31 downto 28) = x"a".
>         -- Address decoding closer to CPU checks those bits.
>         if addr(27 downto 18) = "1011110011" then
>>                         else
>                             -- ABCD0100-ABCD010F
>                             return DEV_UART0;
>                         end if;
> ...
>     uart0 : entity work.uartlitedb(arch)
>         generic map (
>             bps => 38400.0,
>             fclk => CFG_CLK_CPU_FREQ_HZ,
>             intcfg => 1
>         )
>         port map (
>             clk => clk_sys,
>             db_i => devs_bus_o(DEV_UART0),
>             db_o => devs_bus_i(DEV_UART0),
>             int => irqs0(1),
>             rst => reset,
>             rx => uart0_rx,
>             tx => uart0_tx
>         );
>
> pad_ring.vhd
>
> entity pad_ring is
>     port (
> ...
>         pin_atmel_rxd : out std_logic;
>         pin_atmel_txd : in std_logic;
>>     attribute loc of pin_atmel_rxd  : signal is "H17";
>     attribute loc of pin_atmel_txd  : signal is "H18”;
>>     signal uart0_rx : std_logic;
>     signal uart0_tx : std_logic;
>>     obuf_atmel_rxd : OBUF
>         generic map (
>             DRIVE => 8,
>             IOSTANDARD => "LVCMOS33",
>             SLEW => "fast"
>         )
>         port map (
>             I => uart0_tx,
>             O => pin_atmel_rxd
>         );
>     ibuf_atmel_txd : IBUF
>         generic map (
>             IOSTANDARD => "LVCMOS33"
>         )
>         port map (
>             I => pin_atmel_txd,
>             O => uart0_rx
>         );
>>
> It is actually selecting the type of IO cell, drive strength, pad location etc from the pinout file, and doing the instantiation for you.  FPGA tools will infer IO cells (automatically provide general purpose IO cells) but it can’t know the type you want, and ASIC tool flows require all this to be done manually… therefore, this tool.
>
> Documentation should also be generated (datebook type stuff)

I am not familiar with datebook, care to have a pointer ?

> So, this project took on a life of it’s own, and consumed Geoff Salmon.  There is a third such tool that generates the RTL for the S-Core Fixed Point DSP (did we mention we have a DSP we will be announcing soon?) decoder.

Looking forward to it !

>> 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.
>
> I think so.  While I hate process for process sake, I think we should try and make a specification of what said tool(s) should do.  If we are limiting ourselves to a more approachable CPU generator, then perhaps it doesn’t need to start with all the complexity.  If we are looking at working on a maintainable tool set for auto generating things like SoCs, including the top level, IP block stitching, docs, etc. then I think you are more than correct, we need to start with something that gives us VHDL writer functionality.  And likely AST from parsed RTL also (as VMagic does)…

I am afraid of this road, but it really seems like a pipeline that
understand VHDL, read a configuration and then generate/alter VHDL, is
what we are talking about here. This is a complex tool and I am
wondering how maintainable it can get. I have chosen Javascript/JSON
so far because it mached the output system (webbrowser), but if we are
looking at something more long term stable I am not sure it is the
right road.

What is your opinion on other solution like Migen, MyHDL ? In general,
I feel like Python would be a more suitable environnement than Java
and Javascript from the community and long term point of view. Maybe
we should start another thread on the sole topic on how to improve the
maintenability of the generator.
-- 
Cedric BAIL


More information about the J-core mailing list