Why can't SyncPort support multiple payloads per cycle?

[Troy-Fan]

AFAIK, we can send multiple payloads to DataPort per cycle.
But we can't do that with SyncPort due to the assertion in ports/SyncPort.hpp#L1011-L1016.
I am wondering the reason why SyncPort has this limitation.
Is this because we want to simplify the implementation of SyncPort or do we have other concerns?

[furuame]

@klingaard or @kevin-heuer Do you have ideas about this limitation?

[klingaard]

Oooohhhh boy, what are you guys doing? 😆

The original author(s) of the SyncPort intended it to be used with sparta::Bus which, in real HW, doesn't allow you to drive more than 1 data packet on the same wires per cycle. If this happens in the model, then the model is busted, hence the assert.

I'm not sure what your use case is here, but if you have the same port driving multiple data to be delivered on the same cycle, I would guess you're looking to reduce modeling maintenance by reusing the same code. I suggest 2 ports, each bolted to the same callback in that case.

[furuame]

We’d like to transfer data between two Units with different clock frequencies 😬 Data Port is the originally preferred way, but it can’t be used in that asynchronous scenario. Then we’re trying SyncPort but ran into that assert.

I suggest 2 ports, each bolted to the same callback in that case.

Number of datas transferred in a cycle can be dynamic. Yes there is a maximum, but we're wondering if we can make it either by supporting asynchronous scenario for DataPort or allowing multiple datas for SyncPort.

The original author(s) of the SyncPort intended it to be used with sparta::Bus which, in real HW, doesn't allow you to drive more than 1 data packet on the same wires per cycle. If this happens in the model, then the model is busted, hence the assert.

I see. So can I say that’s a sanity check for the Bus scenario? Functionally it should work if we lift that assert? 😆 If so, would it sound good to you that we add a boolean to enable/disable that assert in SyncPort?

[klingaard]

You can remove the assert and add some testing to see if you get the desired results. And you're more than welcomed to make that assert "optional" for your purposes. But keep in mind that the assert was to help modelers using the SyncPorts ensure that the delays they were providing allowed the skewing properly and didn't "clobber" data being delivered. In other words, it's a good assert. 😉

[furuame]

Oh ... now I correlate what you’re saying and codes what Troy showed to me earlier ... @Troy-Fan Let’s take a look at how to ensure multiple datas work in SyncPort.