SyncPort.hpp File Reference

File that defines synchronized input/output ports. More...

#include "sparta/simulation/TreeNode.hpp"
#include "sparta/utils/DataContainer.hpp"
#include "sparta/collection/DelayedCollectable.hpp"
#include "sparta/ports/Port.hpp"
#include "sparta/events/Precedence.hpp"
#include "sparta/events/EventSet.hpp"

Go to the source code of this file.

Classes
class	sparta::SyncOutPort< DataT >
	Class that defines a synchronized SyncOutPort for data writes on different clocks. More...
class	sparta::SyncInPort< DataT >
	Class that defines an synchronized input port on modules on two different clocks. More...

Namespaces
namespace	sparta
	Macros for handling exponential backoff.

Detailed Description

File that defines synchronized input/output ports.

Explanation of ready/valid mechanism:

1. Receiver can drive not-ready on cycle M to indicate it cannot accept data on cycle M+1.
2. When receiver then drives ready on cycle N, it indicates it can accept new data on cycle N+1.
3. If receiver asserts not-ready on cycle M and data is sent on cycle M, then SyncPort will recirculate the data sent on cycle M, delivering it on cycle N+1.
4. If receiver asserts not-ready on cycle M and data is sent on cycle M' where M < M' < N+1, then SyncPort will recirculate the data sent on cycle M', delivering it on cycle N+1. In effect, this is allowing a sender to drive valid on an arbitrary not-ready cycle, and the data is delivered when ready is finally asserted.

Implementation of ready/valid mechanism:

o SyncInPort keeps track of: current value of ready previous value of ready last tick ready value changed number of sent requests not yet delivered

o When trying to send new data, SyncOutPort will then call SyncInPort::couldAccept_() to determine if data could be delivered in the current cycle.

o Data can be scheduled for sending: SyncInPort is currently ready OR SyncInPort is not ready, but became not ready this cycle OR SyncInPort is not ready, but isn't trying to deliver recirculated data

o Data cannot be scheduled for sending if: (SyncInPort is trying to deliver recirculated data) AND (SyncInPort is not ready AND SyncInPort became not ready on a previous cycle) OR (SyncInPort is ready AND SyncInPort became ready on the current cycle)

Potential race:

num_in_flight_ decremented first, then its value is used to allow sending vs.
num_in_flight_ value used to allow sending, then value is decremented

This only matters if num_in_flight_ is greater than 0 AND couldAccept_() returns false. If couldAccept_() returns false, then by definition, the receiver cannot receive data this cycle (i.e. is asserting not ready). If couldAccept_() returns false, then getLatchedReady_() has also returned false, which means there can be no data delivered this cycle. Therefore, I don't think this race is an issue.

Zero cycle connections:

For zero-cycle connections, we don't allow one in-flight request in sync-port since we're trying to deliver the data on the same cycle it was sent.

Definition in file SyncPort.hpp.