1. Automatic Interface Generation P.I.G. : Presented by Trevor Meyerowitz Sonics: Presented by Michael Sheets EE249 Discussion November 30, 1999

2. Roberto Passerone University of California at Berkeley James A. Rowson Alta Group of Cadence Design Systems Alberto L. Sangiovanni Vincentelli University of California at Berkeley Automatic Synthesis of Interfaces between Incompatible Protocols Protocol Synthesis using P.I.G. (Protocol Interface Generator) Presented by: Trevor Presented by: Trevor Meyerowitz Some slides used from the presentation below:

3. OutlineOutline Motivations Protocol Description Synthesis algorithm Conclusions

4. Designs are becoming more and more complicated  they are impossible for one individual to understand  design cycle times and market windows are decreasing One technique of coping with this is design reuse  using both internal and external IP’s  each block has its own way of handling data  manual interfacing is costly, unreliable and time consuming Interface synthesis attempts to meet these needs through:  declarative specification of signaling protocol  automatic synthesis of interface machine  automatic generation of testbench Problem Statement:

5. Problem Solution: Glue Logic Given a protocol specification for each IP block glue logic is... IP Block Protocol IP Block Protocol Glue Logic

6. Problem Solution: Criteria Given Protocol Descriptions, The Generated Interface Must:  ensure consistency between different protocols  be independent of implementation (e.g. easily transferable to hardware or software)  not cause unnecessary overhead What We Need  a format for specifying the protocols  a technique for synthesis  a technique for testing

7. P.I.G. (Protocol Interface Generator) Protocols are FSM’s that are described using regular expressions Glue logic is generated by taking the product of the machines and pruning it to minimize latency Outputs product machine in Verilog or C form Automatically generates test bench software Has a number of simplifying assumptions

8. AssumptionsAssumptions Point - to - point communication The two protocols exchange the same token The two parties are synchronous and share the same clock Data in the interface is stored in a register wide enough to contain an entire token, controlled by an FSM Only one transaction handled

9. Overview of the synthesis process A B A protocol descriptionB protocol description A protocol is the set of all sequences of values admissible at the ports of a module for one transaction

10. A Overview of the synthesis process B A protocol descriptionB protocol description A Automaton B Automaton Language Recognizers Product Machine Subset

11. Protocol Description: Overview Name of the protocol Type of the token List of all ports Direction of the ports Regular expression

12. Protocol Description: Example This example transfers 2 bytes of data:  the transmitter uses a handshake protocol  the receiver uses a serial protocol Interface creates the product machine to make the machines work together Handshake Transmitter Serial Receiver Interface Machine trigger bus start bus

13. type byte bit[7:0]; type yow { byte a; byte b; }; protocol handshake of type yow { master bit trigger; master byte bus; term wait( bit t ) { t, - } term get( bit t, byte b ) { t, b } handshake( yow y ) { wait( 0 ) *, get( 1, y.a )+, get( 0, y.b )+ } Protocol Description: Example 1a 0- 1a 0b Handshake Transmitter: type byte bit[7:0]; type yow { byte a; byte b; }; protocol handshake of type yow { master bit trigger; master byte bus; term wait( bit t ) { t, - } term get( bit t, byte b ) { t, b } handshake( yow y ) { wait( 0 ) *, get( 1, y.a )+, get( 0, y.b )+ } type byte bit[7:0]; type yow { byte a; byte b; }; protocol handshake of type yow { master bit trigger; master byte bus; term wait( bit t ) { t, - } term get( bit t, byte b ) { t, b } handshake( yow y ) { wait( 0 ) *, get( 1, y.a )+, get( 0, y.b )+ } type byte bit[7:0]; type yow { byte a; byte b; }; protocol handshake of type yow { master bit trigger; master byte bus; term wait( bit t ) { t, - } term get( bit t, byte b ) { t, b } handshake( yow y ) { wait( 0 ) *, get( 1, y.a )+, get( 0, y.b )+ } type byte bit[7:0]; type yow { byte a; byte b; }; protocol handshake of type yow { master bit trigger; master byte bus; term wait( bit t ) { t, - } term get( bit t, byte b ) { t, b } handshake( yow y ) { wait( 0 ) *, get( 1, y.a )+, get( 0, y.b )+ }

14. Protocol Description: Example 1a 0- 0b type byte bit[7:0]; type yow { byte a; byte b; }; protocol serial of type yow { master bit start; master byte bus; term null( ) { 0, - } term one( byte b ) { 1, b } term two( byte b ) { 0, b } serial( yow y ) { null( ) *, one( y.a ), two( y.b ) } Serial Receiver:

15. Product computation Start from the initial state Explore all possible paths and add states Generate input and output and resolve non determinism Remove illegal transitions Optimize performance (minimize latency)

16. Product computation: Example 1a 0- 1a 0b 0- 1a0b 0- 1a0- 1a 0- 0b 0-1a0-0b 1a 0b1a 0b 1a0b 1a 0b0-

17. Product computation: Example 1a 0- 1a 0b 1a0b 1a 0b 0- 1a 0b 0- Initial States: Nothing has been transmitted or received State 2: The transmitter sends “a” The receiver stays put State 3: The transmitter sends “b” The receiver receives “a” State 4: The transmitter stays put The receiver receives “b” Transaction Finished.

18. TestbenchTestbench Also synthesize “driver” and “monitor” modules Driver module is FSM that:  randomly generates token values  randomly selects from non-deterministic choices in protocol (Kleene closures, for instance) Monitor module is FSM that:  collects token and prints it out when received successfully  randomly selects non-deterministic responses

19. ResultsResults FromToStatesRecur.Full Recur.PM States HandshakeSerial41459 SerialHandshake31359 ATM serialATM req-ack1438298314903249 ATM req-ackATM serial111341616803249 ATM serial rev.ATM req-ack1162351163249

20. ConclusionsConclusions The Good  regular expressions provide a standard format for protocol specification  product machine allows automatic synthesis  can output to C or Verilog The Bad  currently limited by simplifying assumptions  the potential for FSM blow-up with many protocols or complicated protocols The Verdict  a potentially compelling solution with much work left to be done.