Feature to share implementation

[taichi-ishitani]

For pzbcm, I use text macros to share implementation.
For example:

• https://github.com/pezy-computing/pzbcm/blob/985e7147ab42682e62f32604433090b3be5f8482/pzcorebus_common/pzcorebus_if_internal_macros.svh#L10
• https://github.com/pezy-computing/pzbcm/blob/985e7147ab42682e62f32604433090b3be5f8482/pzcorebus_common/pzcorebus_request_if.sv#L18
• https://github.com/pezy-computing/pzbcm/blob/985e7147ab42682e62f32604433090b3be5f8482/pzcorebus_common/pzcorebus_if.sv#L18

I need a new feature to share implementation between design elements to re-write these interfaces in Veryl.
Followings are idenas for this.

• Unnamed code block.

This is similar to #793 but no instance name is needed.
Code block will be expanded into the scope where it is instantiated.

• Interface inheritance

For the above example, pzcorebus_if behaves pzcorebus_request_if and also pzcorebus_response_if.
Therefore, I think inheritance is one of suitable ways to model the above case.
Implementations of parent interfaces are expanded into the child interface.

[dalance]

#908 seems to be related too.

[dalance]

I think interface inheritance / composition is better than code block approach in this case because code block provide only a feature like text macro and not special support for interface.

There are some syntax ideas:

interface Req {
    var cmd: logic;
    var cmd_accept: logic;
}

interface Resp {
    var data: logic;
    var data_accept: logic
}

interface Bundle inherit Req, Resp {
}
// This is the same as 
// interface Bundle {
//     var cmd: logic;
//     var cmd_accept: logic;
//     var data: logic;
//     var data_accept: logic
// }

// Another inherit syntax
interface Bundle {
    inherit Req;
    inherit Resp;
}

// Composition style
interface Bundle {
    inst req: Req;
    inst resp: Resp;
}

Regardless syntax style, actual member definitions becomes to be difficult to understand in case of having deep inherit depth.
The instance name in composition style seems to be meaningless, so inherit may be better.

[dalance]

Sorry, I've mistakely closed.

[taichi-ishitani]

We need to consider how propagate child's generic arguments and parameters to parent interfaces.
From point of this view, I prefer this syntax.

interface Bundle #(
  param ADDRESS_WIDTH: u32 = 8,
  param DATA_WIDTH:    u32 = 8,
) {
  inst Req  #(ADDRESS_WIDTH, DATA_WIDTH);
  inst Resp #(DATA_WIDTH);
}

[dalance]

Surely, it seems to be necessary.
But I think the inst keyword is not proper, because the new syntax is bit differ than the existing inst declaration.
(and it is not instantiation strictly)
inherit or another appropriate keyword is necessary.

interface Bundle #(
  param ADDRESS_WIDTH: u32 = 8,
  param DATA_WIDTH:    u32 = 8,
) {
  inherit Req  #(ADDRESS_WIDTH, DATA_WIDTH);
  inherit Resp #(DATA_WIDTH);
}

[taichi-ishitani]

inst keyword is not proper

Sorry, this is my miss type.

[dalance]

Multiple inheritance and diamond problem should be considerd.

interface Base #(
    param WIDTH: u32 = 0,
) {
    var x: logic<WIDTH>,
}

interface Req #(
    param WIDTH: u32 = 0,
) {
    inherit Base #(WIDTH);

    var cmd: logic<WIDTH>;
    var cmd_accept: logic;
}

interface Resp #(
    param WIDTH: u32 = 0,
) {
    inherit Base #(WIDTH);

    var data: logic<WIDTH>;
    var data_accept: logic
}

interface Bundle #(
  param ADDRESS_WIDTH: u32 = 8,
  param DATA_WIDTH:    u32 = 8,
) {

  // Base::x is inherited from both Req and Resp with the differenct parameter override

  inherit Req  #(ADDRESS_WIDTH);
  inherit Resp #(DATA_WIDTH);
}

[taichi-ishitani]

When generating SV code, parent interfaces will be expanded into child interface.
Therefore, parent interfaces cannot have members which have the same name and so Veryl compiler should report an error for the above example.

[dalance]

Generally, there are several ways to resolve diamond problem.

• Single inheritance only
• Forbid nested inheritance
• Check conflict at compile
• Separated namespace for each inheritance path

Even if we adopt checking scheme, there are some choices about what type conflict is allowed or not.
For example, non-parameterized common parent can be allowed safely, but forbidding all naming conflict is more simple.