Modeling Contention Interference in Crossbar-based Systems via Sequence-Aware Pairing (SeAP)

ASCOM: Affordable Sequence-aware COntention Modeling in Crossbar-based MPSoCs

“…As a result of the algorithm, M holds both the worst-case contention delay (M [LEN (x)+1, LEN (y)+1]) and the necessary information to reconstruct an example (witness) of the subsequence of requests (pairing) that determined such maximum delay. SeAP can be generalized to an arbitrary number of sequences and lengths [3]. However, such generalization cannot escape SeAP scalability concerns, inherited from the HCS problem [4], [7]: its complexity remains in the worst-case exponential on the number and size of the considered sequences of requests [3], [4].…”

“…SeAP can be generalized to an arbitrary number of sequences and lengths [3]. However, such generalization cannot escape SeAP scalability concerns, inherited from the HCS problem [4], [7]: its complexity remains in the worst-case exponential on the number and size of the considered sequences of requests [3], [4]. ASCOM enables a scalable, sequence-aware contention modeling in crossbar-based systems by leveraging two main practical approaches that build on SeAP peculiarities to work around its computational complexity limits.…”

“…We also considered different sequence shapes and distributions with different patterns of request to each device (i.e., grouping a stream of requests to the same device). We explored scenarios where requests are triggered in a variable size cluster (uniformly) in the ranges: [2-2] (fixed range), [2][3][4], [2][3][4][5][6] and [2][3][4][5][6][7][8][9][10][11][12]. Additionally, in consideration of the fact that smaller clusters are more frequent, we also explored sequences in the cluster ranges 2-6 and 2-12 but with a non-uniform distribution, biased towards smaller clusters ([2-6B] and [2-12B]).…”

“…The specific order in which requests are sent to the devices allows to rule out infeasible contention scenarios. The Sequence-Aware Pairing (SeAP) [3] approach builds on precedence relation between accesses, which is a weaker concept than timestamps, to rule out from contention modeling those scenarios where requests from multiple cores to the same HSR cannot happen in parallel, despite happening in the same time window.…”

“…However, SeAP inherits the computational complexity of the pattern-matching approaches it builds on, which is in the worst-case exponential on the number and size of the considered sequences of requests [3], [4], [6]. Owing to the inherent complexity, the use of SeAP on realistic multicore scenarios (i.e., with more than 2 cores) can be challenging already with sequences above 10.000 elements, while sequences from real applications are expected to be in the order of 50.000 to 100.000 thousands elements for 10ms applications.…”