Automatic Interface Generation

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

2. Protocol Synthesis using P.I.G. (Protocol Interface Generator) Presented by: Trevor Meyerowitz Some slides used from the presentation below: Automatic Synthesis of Interfaces between Incompatible Protocols 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

3. Outline • Motivations • Protocol Description • Synthesis algorithm • Conclusions

4. Problem Statement: • 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

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

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. Assumptions • 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. B A A protocol description B protocol description Overview of the synthesis process A protocol is the set of allsequences of values admissible at the ports of a module for one transaction

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

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

12. Handshake Transmitter Serial Receiver Interface Machine 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 start trigger bus bus

13. Handshake Transmitter: 0- 1a 1a 0b 0b Protocol Description: Example 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 )+ } } 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 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: 0- 1a 0b

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. 0- 1a 0b 0- 1a 0- 0b 0- 0- 0- 1a 1a 1a 1a 0b 1a 0- 1a 1a 1a 0b 1a 1a 0- 0b 0b 1a 0b 0b 0b 0- 0b 1a 0b 0b 0b 0b 0- Product computation: Example

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

18. Testbench • 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. Results From To States Recur. Full Recur. PM States Handshake Serial 4 14 5 9 Serial Handshake 3 13 5 9 ATM serial ATM req-ack 1438 2983 1490 3249 ATM req-ack ATM serial 111 3416 1680 3249 ATM serial rev. ATM req-ack 116 235 116 3249

20. Conclusions • 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.