SystemVerilog Interface Support

[jijingg]

Hi @Dolu1990 , we would like to add an interface to SpinalHDL. Could you please take a look at how difficult it will be.

interface  AP_APB4_32_IF ();
    logic [31:0] paddr    ;
    logic [31:0] pwdata   ;
    logic [31:0] prdata   ;
    logic        pwrite   ;
    logic        pready   ;
    logic        psel     ;
    logic        penable  ;
    logic        pslverr  ;
    logic [2:0]  pprot    ;
    logic [3:0]  pstrb    ;

    modport mst (
        input         prdata    ,
        input         pslverr   ,
        input         pready    ,
        output        paddr     ,
        output        pwdata    ,
        output        pwrite    ,
        output        psel      ,
        output        penable   ,
        output        pprot     ,
        output        pstrb
    );

    modport slv (
        output        prdata    ,
        output        pslverr   ,
        output        pready    ,
        input         paddr     ,
        input         pwdata    ,
        input         pwrite    ,
        input         psel      ,
        input         penable   ,
        input         pprot     ,
        input         pstrb
    );
endinterface

module Top(
input   clk  ,
....
AP_APB4_32_IF.slv   apb_slv,
AP_APB4_32_IF.mst apb_mst
);
...
endmodule 

Here is a conceptual code, Possibly not accurate， not the final version, where the Spinal SystemVerilog backend captures SVIF and modeport to generate an Interface.

trait SVIF{
}

class modeport(message: String = "") extends scala.annotation.StaticAnnotation

case class MY_APB_IF(aw: Int = 32, dw: Int = 32) extends Bundle with SVIF with IMasterSlave{
  val  paddr    = Bits(32 bit)
  val  pwdata   = Bits(32 bit)
  val  prdata   = Bits(32 bit)
  val  pwrite   = Bool()
  val  pready   = Bool()
  val  psel     = Bool()
  val  penable  = Bool()
  val  pslverr  = Bool()
  val  pprot    = Bits(3 bit)
  val  pstrb    = Bits(4 bit)

  override def asMaster(): Unit = mst
  @modeport()
  def mst = {
    out(paddr, pwdata, pwrite, psel, penable, pprot, pstrb)
    in(pready, prdata, pslverr)
  }

  @modeport()
  def slv = this.mst.asInstanceOf[Data].flip()

  def <<(that: MY_APB_IF) = {
  ???
  }

  def ><(that: Apb4) = {
    this.paddr  <> that.PADDR
    this.psel   <> that.PSEL
    ???
    that.PRDATA <> this.prdata
  }
}

We also need to consider the inheritance and extensibility of the existing interface.

[Dolu1990]

Hi jijingg,

I think having enough support for your example would be faisable, it would mostly be about backend stuff.
But the main practical issue, would be to propagate parameters from SpinalHDL to the System verilog interface. That would be the main thing to think about (i think)

You are thinking about this feature mostly for blackboxes / toplevel io ?

[jijingg]

You are thinking about this feature mostly for blackboxes / toplevel io ?

Yes, For mixed development, the interfaces of toplevel and blackbox are our current bottlenecks, requiring manual handling. If Spinal directly supports this, things would improve significantly.
In addition, printing the internally generated Verilog code with interfaces (depending on user preference) would be beneficial for code volume and review.

[Dolu1990]

hmm, maybe then the solution would be more about kinda creating a automated layer in between the current SpinalHDL blackbox support and a systemverilogification of it.

Meaning :

class MyBlackBox extends BlackBox{
   val bus = master(Apb3(xyz))
   jijnggSvBinder(bus)
}

Meaning, that the jijnggSvBinder would document to the BlackBox how to bind that bus interface during the verilog generation.
The overall meaning of that aproache would be that SpinalHDL itself would stay blind about what is a systemverilog interface, but during the phase which generate the verilog, there would be a very small logic to bind stuff together in the way the jijnggSvBinder specified ?

That jijnggSvBinder would have the knowledge of how the APB system verilog interface is defined in your libraries.
In other words, SpinalHDL itself would not generate the interface AP_APB4_32_IF definition, it would use your one. assuming it come from your system verilog libraries.

[Dolu1990]

@jijingg

[jijingg]

Sorry for being late.

I carefully thought about it and realized that we still don't need to do any special processing on BlackBox's interface. If it's two different interfaces, let the user implement their own mapping and connection relationships. @Dolu1990

class MyBlackBox extends BlackBox{
  val x   = in Bits(32 bit)
  val y   = out Bits(32 bit)
  val cfg = master(MY_APB_IF(32, 32))
}

class Top extends Component{
  val a = in Bits(32 bit)
  val b = out Bits(32 bit)
  val spinal_apb = slave(Apb4(Apb4Config(32, 32)))

  val ut = new MyBlackBox

  ut.x    := a
  b       := ut.y
  ut.cfg  >< spinal_apb                          //way1: ut.cfg implement a method connect with spinalhdl's Apb4
//  twoDiffrenceAPBconnect(ut.cfg,  spinal_apb)  //way2: implement a function connect two different APB
}

get

module Top(
input  [31:0]   a   ,
out    [31:0]   b   ,
out             dfx ,
Apb4.slave      spinal_apb
);

MY_APB_IF       my_cfg_if;

MyBlackBox  dut(
    .x(a                   ),
    .y(b                   ),
    .cfg(my_cfg_if         )
)

assign   my_cfg_if.paddr    =  spinal_apb.PADDR   ;
assign   my_cfg_if.pwdata   =  spinal_apb.PWDATA  ;
assign   my_cfg_if.pwrite   =  spinal_apb.PWRITE  ;
assign   my_cfg_if.psel     =  spinal_apb.PSEL    ;
assign   my_cfg_if.penable  =  spinal_apb.PENABLE ;
assign   my_cfg_if.pprot    =  spinal_apb.PPROT   ;
assign   my_cfg_if.pstrb    =  spinal_apb.PSTRB   ;
assign   spinal_apb.PREADY   = my_cfg_if.pready    ;
assign   spinal_apb.PRDATA   = my_cfg_if.prdatta   ;
assign   spinal_apb.PSLVERR  = my_cfg_if.pslverr   ;

endmodule

[jijingg]

If the interface of the BlackBox does not need any special declaration, then things might be simpler.

class MyBlackBox extends BlackBox{
  val x   = in Bits(32 bit)
  val y   = out Bits(32 bit)
  val cfg = slave(Apb4(Apb4Config(32, 32)))
}

class Top extends Component{
  val a = in Bits(32 bit)
  val b = out Bits(32 bit)
  val spinal_apb = slave(Apb4(Apb4Config(32, 32)))

  val ut = new MyBlackBox

  ut.x    := a
  b       := ut.y
  ut.cfg  << spinal_apb
}

module Top(
input  [31:0]   a   ,
out    [31:0]   b   ,
out             dfx ,
Apb4.slave      spinal_apb
);

MyBlackBox  dut(
    .x(a                   ),
    .y(b                   ),
    .cfg(spinal_apb        )
)

endmodule

[jijingg]

In theory, an Interface is actually another form of Component. It is very similar to a Component in the following ways:

1. It can be instantiated like Component
2. It can also be parameterized. If two Interfaces are different, they should generate two different modules like modules_0/modules_1 to differentiate them, or they can be named like Components by using setDefinitionName. The only complexity lies in its modport - when to expand it during SV generation and when not to. However, in terms of validity checks and inheritance from the original method, the most significant modification point should be the SystemVerilogEmitter.

[jijingg]

Yes ,we creat a trait of Svif(TBD name) used for users to implement there Bundle with Interface(which only valid when generateSystemVerilog)
If you don't use SVIF, or you use SVIF but use generateVerilog, then nothing happens. The printed verilog is the same as the old way.

trait Svif {}

class Apb3(c: Apb3Config) extends Bundle with IMasterSlave with Svif{
  override def asMaster(): Unit = mst
  @modport()
  def mst = {
  }
}

[Readon]

How about add an option to the SpinalSystemVerilog for the standalone interface? Because there are not that many language related concepts coupled in spinal itself.

The problem might be how to determine which Bundle is a class defined and which is only created by 'new Bundle'.

[Dolu1990]

hmmm
I was more thinking about adding some specific binding API to the blackbox class. Some instruction about "How to bind things between the regular SpinalHDL model, toward the SV model".
Once this is set, as a second step, we could think about a more fluant API

First step would be the very low / raw level API. For instance (crappy example)

class MyBB extends BlackBox{
   val apb = Apb3(32,16)
   val apbIi= newBinding(name = "apb", param = "32, 16")
   apbii.bind(apb.PADDR, "PADDR")
   apbii.bind(apb.PWDATA, "PWDATA")
}

So that would be a low level API for custom binding. Suggar layers would be needed on the top, but we kinda realy need to think about the lowlevel first.

[jijingg]

How about add an option to the SpinalSystemVerilog for the standalone interface? Because there are not that many language related concepts coupled in spinal itself.

I agree with your statement， and yes the problem is how to classify bundle which need generated Interface or which not , It is inevitable to use TAG or provide a trait interface to identify

[andreasWallner]

I think there is talk about two different ideas here: using a SV BlackBox that uses an interface vs. generating code that uses interfaces. The second one is due to me, reading your OP again I think you were talking just talking about blackboxes?

The solutions that look fitting to me are different for those two:

• if it's for a bunch of blackboxes, I don't see a reason to bake this deeply into generation. port/direction/etc. will be fixed for one blackbox, after which normal IMasterSlave (or similar) can be used. The interface definition has to exist somewhere in the existing SV code anyways, so why would you go through the effort of describing all possible modports in SpinalHDL?

• If we wanted to generate code that uses interfaces internally then we have a concept already that maps to interfaces: IMasterSlave. In this case, why not do it for all IMasterSlave? (if generating code that uses interfaces internally was not the idea here, please ignore this)

[jijingg]

First step would be the very low / raw level API. For instance (crappy example)

@Dolu1990 Here is a solution #1364 , and the basic interface functions have been resolved, including the interface of BlackBox, Of course, there are still some difficult problem nee your help