AxiLite4SlaveFactory generates combinatorial paths from inputs to ready outputs about spinalhdl HOT 5 CLOSED

Should be good with d04f565, let's me know if there is any issue left ^^

from spinalhdl.

This removed the combinatorial path to the ar.ready.
However, the combinatorial paths in the write logic are still present (see picture below)

I traced the reason of those to the StreamJoin apply function here:

  /** Join streams, but ignore the payload of the input streams. */
  def apply(sources: Seq[Stream[_]]): Event = {
    val event = Event
    val eventFire = event.fire
    event.valid := sources.map(_.valid).reduce(_ && _)
    sources.foreach(_.ready := eventFire)
    event
  }

This is called on the w and aw streams before creating the register stage with halfPipe, so the ready signal is still combinatoric.

Moving the halfPipe before the StreamJoin removes the remaining combinatoric path.

from spinalhdl.

Moving the halfPipe before the StreamJoin removes the remaining combinatoric path.

Yes right

The issue i have with that is that it would cost around 64 registers, i'm not realy into spending area just for following the spec (with no purpose)

Does this path create practical issues on your side ?
An option could be added to have the fix as you say.

from spinalhdl.

I don't have a practical issue with it right now, as the design I'm working on still early on and only runs in simulation, where I noticed the core not following spec.

As far as I understand, the reason for the no combinatorial paths rule in the spec is, because it may introduce long combinatorial paths is the design, that reduce max clock speed.

You're right that registering data and address with a halfPipe on w and aw uses unnecessary area, especially as the spec guarantees that data and address are stable as long as valid is high.

To follow spec, it would be enough to register the valid signals of both paths, a validPipe should be enough and only cost 2 registers.

I'm also OK with leaving it how it is right now, and testing it again once my design is more complete and see if it causes a practical issue.

from spinalhdl.

To follow spec, it would be enough to register the valid signals of both paths, a validPipe should be enough and only cost 2 registers.

I forgot that one existed XD. Yes it would work, as long as the BusSlaveFactory haltIt primitive isn't used by the user (as that one may depend on the address.

I'm also OK with leaving it how it is right now, and testing it again once my design is more complete and see if it causes a practical issue.

In general, i tend to integegrate pipelining stages at a more "macro level", meaning between the main memory bus and the shared peripheral bus, which then goes to individual peripherals, that can save a lot of area, especialy if you have many little bus slave factory (ex gpio)

from spinalhdl.