Plugin deadlock in circular dependency on Handle

[KireinaHoro]

I'm trying out the plugin framework and encountered some deadlock issue:

import spinal.core._
import spinal.core.fiber.Handle
import spinal.lib._
import spinal.lib.misc.plugin._

class Plugin1 extends FiberPlugin {
  val logic = during setup new Area {
    val int = host[Plugin2].logic.const
  }
}

class Plugin2 extends FiberPlugin {
  val logic: Handle[Area with Object{val const: Bool}] = during setup new Area {
    val const = True
    awaitBuild()
    val o = out(Bool())
    o := host[Plugin1].logic.int
  }
}

class PluginTest extends Component {
  val host = new PluginHost
  host.asHostOf(new Plugin2, new Plugin1)
}

object PluginTest extends App {
  SpinalVerilog(new PluginTest)
}

Elaboration failed with a rather cryptic error message:

[Progress] at 0.137 : Elaborate components

! SpinalHDL async engine is stuck !
Waiting on global_elab_inflightLock defined at ???:
1) global_elab loader
Waiting on global_elab_lock_1000000_lock defined at spinal.lib.misc.plugin.FiberPlugin.awaitBuild(Fiber.scala:31):
1) Plugin2_logic

My understanding is that since Plugin1.logic.int and Plugin2.logic.o are in different phases (setup and build), there should not be a real loop here. An ugly workaround is to have a null-initialized const outside of the logic block:

class Plugin1 extends FiberPlugin {
  val logic = during setup new Area {
    val int = host[Plugin2].const // instead of `logic.const`
  }
}

class Plugin2 extends FiberPlugin {
  var const: Bool = null
  val logic = during setup new Area {
    const = True
    awaitBuild()
    val o = out(Bool())
    o := host[Plugin1].logic.int
  }
}

But with this workaround const loses its name inside the area. Is there a better way to specify this type of dependency?

Also, it would save a lot of headaches if the error message is improved / documentation is updated.

[Dolu1990]

Hi,

the Plugin1.logic and Plugin2.logic content can only be accessed form the outside once they completted.
So, as Plugin2.logic will wait awaitBuild, the Plugin.logic1 content will only be assessible during build phase, issue is that the Plugin1.logic is only setup phase, and until it finish it will force the whole system to stay in setup phase and can't progress because it wait on plugin2.logic (dead lock)

An alternative to your workaround is :

class Plugin2 extends FiberPlugin {
  val const = during setup Bool()
  val logic = during build new Area {
    val o = out(Bool())
    o := host[Plugin1].logic.int
  }
}

or

class Plugin2 extends FiberPlugin {
  val api = during setup new Area{
    val  const = Bool()
  }
  val logic = during build new Area {
    val o = out(Bool())
    o := host[Plugin1].logic.int
  }
}

[KireinaHoro]

Great! Unrelated to the deadlock, I noticed that both approaches are a bit weird with naming: for example if you do

val MyKey = NamedType(Bool())

MyKey would actually get a getName of Plugin2_MyKey instead of just MyKey (as it would be directly inside a Component) and this is a bit annoying for some header file generation I'm doing later. I'm currently wrapping it in a new Area { ... } setName "" to keep the old behaviour, but this feels a bit anti-pattern. What do you think?

[Dolu1990]

Hi,

MyKey would actually get a getName of Plugin2_MyKey instead of just MyKey

That is done on purpose.
The idea is to avoid naming conflicts. as multiple plugin may define different MyKey internaly, while all sharing the same global name space (the component they are into)

So, there is one fondamental thing about the Plugin thing which is very different from Component / Module, is that the idea, is that the Plugin are themself parameters, so they may can come nameless, from the outside. Here is an example :

  class VexiiRiscv extends Component {
    val host = new PluginHost
  }

  SpinalVerilog{
    val toplevel = new VexiiRiscv
    
    //Now let's parametrize the CPU with some plugins
    toplevel.host.asHostOf(List(
      new PluginA(),
      new PluginB(),
      new PluginC(),
      new PluginD()
    ))
    
    toplevel
  }

But i just pushed a change which allow you so use it your way :

  class PluginX extends FiberPlugin {
    val logic = during setup new Area {
      val x = True
    }
  }

  class PluginY extends FiberPlugin {
    val logic = during setup new Area {
      val Y = True
    }
  }

  class VexiiRiscv extends Component {
    val host = new PluginHost
    val plugX = new PluginX()
    host.asHostOf(plugX)
  }

  SpinalVerilog{
    val toplevel = new VexiiRiscv()

    //Now let's parametrize the CPU with some plugins
    toplevel.host.asHostOf(List(
      new PluginY()
    ))

    toplevel
  }

=>

module VexiiRiscv (
);

 wire                plugX_logic_x;
 wire                PluginY_logic_Y;

 assign plugX_logic_x = 1'b1;
 assign PluginY_logic_Y = 1'b1;

endmodule

About the dead lock thing, i'm working on it, got it to report error on dead lock circular chain inside each phase (not working yet when the chain cross phase)

For instance that :

object PlayComposablePlugin2 extends App {

  import spinal.lib.misc.pipeline._

  class PluginA extends FiberPlugin {
    val retainer = Retainer()

    val logic = during setup new Area{
      val b = host[PluginB]
      val bRetainer = retains(b.retainer)
      awaitBuild()
      retainer.await()
    }
  }

  class PluginB extends FiberPlugin {
    val retainer = Retainer()

    val logic = during setup new Area {
      val c = host[PluginC]
      val cRetainer = retains(c.retainer)
      awaitBuild()
      retainer.await()
    }
  }

  class PluginC extends FiberPlugin {
    val retainer = Retainer()

    val logic = during setup new Area {
      val a = host[PluginA]
      val aRetainer = retains(a.retainer)
      awaitBuild()
      retainer.await()
    }
  }


  class VexiiRiscv extends Component {
    val host = new PluginHost
  }

  SpinalVerilog{
    val toplevel = new VexiiRiscv()

    //Now let's parametrize the CPU with some plugins
    toplevel.host.asHostOf(List(
      new PluginA(),
      new PluginB(),
      new PluginC()
    ))

    toplevel
  }
}

Now report

! SpinalHDL async engine is stuck !
Waiting on global_elab_inflightLock defined at ???:
1) global_elab loader
Fiber chain detected with : 
- PluginA_logic waiting on PluginC_logic_aRetainer
- PluginC_logic waiting on PluginB_logic_cRetainer
- PluginB_logic waiting on PluginA_logic_bRetainer

It also report when a plugin thread retains something, but finished without releasing it

We can do a call to talk about all the API :D

[KireinaHoro]

Thanks for the clarification! I'm working with a global profiler and the keys would represent timestamps for phases in the design; this should be global. I think your example shows it nicely, I'll see if I can adapt.

Let's arrange the call about API designs on LinkedIn :)

[Dolu1990]

Yes sure ^^

Pushed changes to improve the error reporting on your case :

! SpinalHDL async engine is stuck !
Fiber chain detected with : 
- Plugin2_logic waiting on spinal_elab_build_start at spinal.lib.misc.plugin.FiberPlugin.awaitBuild(Fiber.scala:29)
- spinal_elab waiting on Plugin1_logic_fiber_completion at spinal.sim.JvmThread.park(SimManager.scala:32)
- Plugin1_logic waiting on Plugin2_logic at spinal.tester.code.Plugin1$$anon$107.<init>(Debug.scala:2467)