Clock domain crossings on Ports

[thheil-dmatrix]

Hi,

I'm confused about how to change clock domains between OutPort and InPort. I see SyncOut/InPort classes, but not sure what the vision for using these are. The documentation points me to scheduleAcrossClocks.

"The above rules are implemented by the scheduleAcrossClocks() method in Event objects."

I can't find a scheduleAcrossClocks method.

The SyncInPort gets two Clock pointers (makes sense). One of them is passed in, and the other is automatically determined based on the PortSet, which is typically the clock of the model that instantiates the SyncInPort (correct expectation?). The one passed in is what drives the handler, while the automatically determined one is what the inputs should arrive on (I think).

Does the clock conversion happen in the output port (sender side) or input port (receiver side)?

Thanks,

Timothy

[thheil-dmatrix]

I think my question may not be very clear. Let me add some context.

A common paradigm in clock domain crossing is to use a queue. The sender writes into the queue in its clock domain, and the receiver reads out of the queue in its clock domain. This is what we are trying to model.

We generally think of the transport to the queue as occurring in the sender's clock domain, with the queue being at the receiver and part of the receiver model. So what we'd like is an InPort at the receiver that runs at the sender's clock. The sender can safely send one packet per cycle, and we won't have any timing problems at the InPort. The InPort handler, running on the sender's clock edges, will pull incoming packets and place them in a queue. Then the ingress handler, running on the receiver's clock, will wake-up and pull items from the queue to drive the rest of the model logic running on the receiver's clock.

I could just use a normal DataIn/OutPort pair for this, but I can't figure out how to create the DataInPort running on the sender's clock. DataInPort pulls its clock from its port set, and there's no way to override it (unlike events that will take an explicit Clock). I can pass in the sender's PortSet, but that creates name collisions between the sender and receiver port names. I can create a custom PortSet under the receiver with the sender's clock, but PortSets have the hard coded name "ports", so that will collide with the existing PortSet. So the only thing I've figured out to do is to create an intermediate TreeNode with a unique name, then the PortSet under that, all so I can pass that in to control the clock on the DataInPort.

It seems like a lot of effort for such a simple thing. I'm wondering if I'm missing something.

Timothy

[klingaard]

Hi Timothy, thank you for the question.

The base types OutPort and InPort provide a common set of methods/API shared with derived types like DataIn/OutPorts, SignalIn/OutPorts, SyncIn/OutPorts, etc. These base classes, In/OutPort, do not understand/know the notion of time, only their derived types.

But indeed SyncPorts are complex beasts, but once mastered, are very powerful. In a nutshell, if you have 2 units with disparate time domains that pass data between, you must use a SyncPort.

Information regarding SyncOutPort:

• The SyncOutPort is a delegate between the sender (time domain 1) and receiver (time domain 2) of data
• The SyncOutPort relies on the bound SyncInPort to do "the math" and perform the alignment for delivery

Information regarding SyncInPort:

• The SyncInPort does the work of determining when sender's data is available to the receiver

Some basic documentation on Ports: https://sparcians.github.io/map/communication.html#comm_ports
Testing for SyncPort and a reference for use: https://github.com/sparcians/map/blob/master/sparta/test/SyncPort/SyncPort_test.cpp

--

Ok, so I see your update and understand your use case. Let me see if I can reiterate it.

First, this is how we use SyncPort's today:

Clock Domain 1, UnitA
                         sync_out_port_->send(dat);
                 ---------------------- | --------------------
                                        | 
Clock Domain 2, UnitB                   |
                                        V
                 sync_in_port_(receive) -> UnitB::receiveData_(const DataT&)

If in UnitB, there's a queue that is filled by requests from UnitA (like a core to a BIU), then the queue is appended to at the frequency of UnitB. When an entry is processed by UnitB, it will send a credit back to UnitA at UnitB's frequency. UnitA may have moved many cycles ahead before that credit is received.

However, your use case is that UnitB has a port to receive data at the frequency of UnitA. From there, I'd assume you'd have an event scheduled in UnitB's clock domain to drain it? If my understanding is correct, you're actually requiring UnitB to understand 2 clock domains, which is possible, but requires a little subunit work. Specifically, the queue should live in a sub-unit of UnitB which can contain it's own PortSet:

  top.unitb.ports.<clock domain 2 ports>
  top.unitb.queue.ports.<clock domain 1 ports>

When the subunit is created, you can set it's clock Domain 1.