[J-core] json instructions set

[D. Jeff Dionne]

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.

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.

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.

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

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

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)

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.

> 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)…

J.

> 
> Best,
> -- 
> Cedric BAIL