Abstract HAL(Hardware abstract layer) to fit more generic usage.

[Readon]

As discussed in #1376, the same fundamental facility implemented by different vendors or technical would require different generating policy. However, in user's code it's best to remain the core logic unchanged.

So abstract out a vendor related HAL to fit this requirement becomes normal strategy.
For example, in user code they could do

    val mux = PriorityMux(...)

    // elaborating
   target = new Component{...}
   SpinalVerilog(target,  objectMap = (target.mux -> XilinxPriorityMux(...)))

While elaborating, the mux can be replaced by a vendor specific object or class.

I think this could be implemented as a rework of mux, which can clear all original design of mux and adapt newly created XilinxPriorityMux into it.
However, I do not know if it is a good way to do that.

[Dolu1990]

Yes i agree, some target specific parameters would be realy realy much needed to select default implementations

However, I do not know if it is a good way to do that.

I always have been hesitante on the way to do it XD

Currently there is the SpinalConfig device property which kinda of map toward that idea.

case class Device(vendor: String = "?",
                  family: String = "?",
                  name: String = "?",
                  supportBootResetKind : Boolean = true){
  def isVendorDefault = vendor == "?"
}
object Device{
  val ALTERA = Device(vendor = "altera")
  val XILINX = Device(vendor = "xilinx")
  val LATTICE = Device(vendor = "lattice")
  val ACTEL = Device(vendor = "actel")
  val ASIC = Device(vendor = "asic", supportBootResetKind = false)
  val NONE = Device(vendor = "none")
}

Maybe it could be extended toward something which would allow :

trait OhMuxImpl
object OhMuxImpl extends DeviceSetting[OhMuxImpl]
object OhMuxByOr extends OhMuxImpl
object OhMuxByMux extends OhMuxImpl

object CustomImpl extends App{
  val ASIC = Device(vendor = "asic", supportBootResetKind = false) //in the example we define ASIC, but in realy this would be already defined in spinal.core itself.
  ASIC(OhMuxImpl) = OhMuxByOr

  val config = SpinalConfig(device = ASIC)
  config.generateVerilog(new Component{
    //OhMux impl
    Device(OhMuxImpl) match {
      case OhMuxByOr => xxx
      case OhMuxByMux =>  yyy
    }
  })
}

So having some sort of data base in the Spinal.core.Device base class, and being able to ask stuff to it durring generation.

[Dolu1990]

PriorityMux will internaly use "Device(PriorityMux) match" to figure out what default implementation it should use.

object PriorityMux{
  def apply(...) = Device(PriorityMux) match {
    case OhMuxByOr => PriorityMux.or(...)
    case OhMuxByMux =>  PriorityMux.mux(...)
  } 
  def or(..)
  def mux(..)
}

[Dolu1990]

Note that here i use pattern matching to know what it need to do, but it could use landa function/software interface instead.

object OhMuxImpl extends DeviceSetting[OhMuxImpl]
or
trait OhMuxImpl{
  def apply[T <: Data](oh : Bits, inputs : Seq[T]) : T
}
``

[andreasWallner]

I see a big drawback with handling this inside of e.g. PriorityMux: To be able to customize generation for my hardware I then have to modify every library that I'm using - basically maintain a fork of SpinalHDL lib with the custom versions of those components.
I haven't been able to come up with a way that I'm happy with - but it would be far nicer if those implementations could be provided from the "user side"...

[Readon]

I prefer "user side" too. In this case, the implementation and interface could be decoupled.

[Dolu1990]

To be able to customize generation for my hardware I then have to modify every library that I'm using

Right, that is what i meant with "but it could use landa function/software interface"
So :

object OhMuxImpl extends DeviceSetting[OhMuxImpl]
trait OhMuxImpl{
  def apply[T <: Data](oh : Bits, inputs : Seq[T]) : T
}