There are some ambiguities in mandelbrot multicore

[chenbo-again]

my solution:

  val allReady = io.outputs.map(s => s.ready).asBits()
  val low = util.lowbit(allReady)
  val unbusy = allReady.orR
  val num = OHToUInt(low)

it's a one cycle dispatcher, but it fails, when I take a look to test script then:

    fork{
      val startX = -2.0
      val startY = -1.5
      val endX = 0.8
      val endY = 1.5
      val stepX = (endX - startX) / resX
      val stepY = (endY - startY) / resY

      cmd.valid #= false
      cd.waitSampling()

      for (y <- 0 until resY;
           x <- 0 until resX) {
        cd.waitSampling(Random.nextInt(10))
        cmd.valid #= true
        cmd.x.raw #= ((startX + x * stepX) * (1 << 20)).toInt
        cmd.y.raw #= ((startY + y * stepY) * (1 << 20)).toInt
        cd.waitSamplingWhere(cmd.ready.toBoolean)
        cmd.valid #= false
      }
    }

just imagine 2 task back2back transform, a one cycle dispatcher and Arbiter may not distinguish 2 results between (x ,y) and (x+1, y)
result of (x+1, y) may appear first in this situation. (with the simple strategy mentioned in spec.

so I think there will be more information in PixelResult, both iteration and (x, y)

[Dolu1990]

Ahhh yes, to simplify the design, the dispatcher / arbiter were designed to always select ports in a sequancial manner (0 then 1 then 2 then 3 then 0 then 1 ...)

It is kind of described in :
https://github.com/SpinalHDL/SpinalWorkshop/blob/workshop/src/main/scala/workshop/mandelbrot/spec.md#part-2--pixelsolvermulticore

But it may need some rewording ?

[chenbo-again]

Just make part3 required and reorder to 132. Part 3 is interesting too, and it is not so hard.

[Dolu1990]

Ahh so, yes, we could add a orderId in the PixelTask and PixelResult, to let freedoom on the implementation. Why not :D

Would that be good for you ?