feature: add new optional reset signal to StreamWidthAdapter and StreamFragmentWidthAdapter

[jonnykl]

Context, Motivation & Description

I've added a new optional reset signal to the StreamWidthAdapter (and also StreamFragmentWidthAdapter). This signal resets the internal counters to 0. Output valid/ready signals are combinatorially set to False when the reset input is asserted. Therefore the reset signal effectivly discards the buffered input. It is allowed to pass null for the reset signal. In that case the adapters behave exactly as before.

Impact on code generation

• additional reset signal for the counter
• additional signal in the output valid/ready signals

Checklist

• Unit tests were added
• API changes are or will be documented:
  • using Scaladoc comments: /** */?
  • on RTD?
  • thanks to a new tracking issue on RTD?

[Readon]

Have you investigated the reset area described here? I think this can help with the reset related logic.

[jonnykl]

The reset area isn't useful for this purpose. The reset area would also add the reset signal to the internal buffer register which is not needed and therefore makes the design unnecessarily more complex. More important, the reset area does not affect the combinatorial valid and ready signals.

[kleinai]

I see how the reset area wouldn't be necessary here. Also looks like your apply method changes failed to compile.

[Readon]

The reset area isn't useful for this purpose. The reset area would also add the reset signal to the internal buffer register which is not needed and therefore makes the design unnecessarily more complex. More important, the reset area does not affect the combinatorial valid and ready signals.

I think the combination logic you want to apply to those Streams is more like a call to haltWhen() or a reduced version.
On the other hand, I think the reset itself is a definition in Sequential logic, not a combinational one.

The design principle of the components in the library is to adopt the combinational logic in some methods or areas. While user using them, they can easily composite them through facilities with or without registers to control the timing.
So I personally prefer to use a method standalone like "haltWhen" to do combinational work.

As a reference, there are no components (to my knowledge) mixed reset logic into the functional logic.

[jonnykl]

Also looks like your apply method changes failed to compile.

Yes, I already fixed that.

I think the combination logic you want to apply to those Streams is more like a call to haltWhen() or a reduced version.
On the other hand, I think the reset itself is a definition in Sequential logic, not a combinational one.

As of my unterstanding, haltWhen() implies that the stream is just interrupted without loosing data. This is not the case for my proposed feature and that's why I think it is useful.

The design principle of the components in the library is to adopt the combinational logic in some methods or areas. While user using them, they can easily composite them through facilities with or without registers to control the timing. So I personally prefer to use a method standalone like "haltWhen" to do combinational work.

As a reference, there are no components (to my knowledge) mixed reset logic into the functional logic.

How do you think such a "reset" signal could be implemented in a better way? Putting the adapter into a reset area and adding haltWhen(reset) to the input and output streams should achieve the same effect (altough this has the downside that the reset area also affects the internal buffer register which is not needed (as already mentioned)). Do you think the user should do that if such a behavior is required?

[Dolu1990]

instead of "reset", maybe it should be more like "flush" ?