A Functional Programming Framework for Latency Insensitive Protocol Validation

  • Authors:
  • Syed Suhaib;Deepak Mathaikutty;Sandeep Shukla;David Berner;Jean-Pierre Talpin

  • Affiliations:
  • Virginia Polytechnic Institute and State University, Blacksburg, VA-24060, USA;Virginia Polytechnic Institute and State University, Blacksburg, VA-24060, USA;Virginia Polytechnic Institute and State University, Blacksburg, VA-24060, USA;INRIA-IRISA, Campus Universitaire de Beaulieu, 35042 Rennes, France;INRIA-IRISA, Campus Universitaire de Beaulieu, 35042 Rennes, France

  • Venue:
  • Electronic Notes in Theoretical Computer Science (ENTCS)
  • Year:
  • 2006

Quantified Score

Hi-index 0.00

Visualization

Abstract

Latency insensitive protocols (LIPs) have been proposed as a viable means to connect synchronous IP blocks via long interconnects in a system-on-chip. The reason why one needs to implement LIPs on long interconnects stems from the fact that with increasing clock frequencies, the signal delay on some interconnects exceeds the clock period. Correctness of a system composed of synchronous blocks communicating via LIPs is established by showing latency equivalence between a completely synchronous composition of the blocks, and the LIP based composition. A design flow based on a synchronous composition specification, and stepwise refinement to LIP composition can be easily conceived, and a proof obligation to show latency equivalence between the synchronous specification and the refinement needs to be discharged. In this work, we propose a functional programming based framework for modeling and simulating LIP, and implement the semantics of various refinement steps in the programming model, so we can validate the LIP model against the original system within this functional programming framework. Such validation becomes easier due to the inherent denotational model of functional languages. We specifically use Standard ML to model the original system implementation as well as its latency insensitive version and compare the two by creating a model that contains both, giving them the same inputs and checking their outputs to be latency equivalent.