More on PSL

1. More on PSL someexamples, somepitfalls

2. FSM start continue continue idle p1 p2 p3 cancel cancel done

3. Lowlevelassertions assertalways ((state = idle and start) -> next (state = p1)); assertalways ((state = idle and not start) -> next (state = idle)); assertalways ((state = p1 and continue) -> next (state = p2)); and so on… one for eachtransition good, butverylocalised

4. Lowlevelassertions assertalways ((state = idle and start) -> next (state = p1)); assertalways ((state = idle and not start) -> next (state = idle)); assertalways ((state = p1 and continue) -> next (state = p2)); and so on… one for eachtransition good, butverylocalised Bit-vector

5. Lowlevelassertions assertalways ((state = idle and start) -> next (state = p1)); assertalways ((state = idle and not start) -> next (state = idle)); assertalways ((state = p1 and continue) -> next (state = p2)); and so on… one for eachtransition good, butverylocalised constant

6. Lowlevelassertions assertalways ((state = idle and start) -> next (state = p1)); assertalways ((state = idle and not start) -> next (state = idle)); assertalways ((state = p1 and continue) -> next (state = p2)); and so on… one for eachtransition good, butverylocalised Implicit self-loop

7. Higherlevelassertion assertalways (not (state = idle) -> eventually! (state = idle) Note: not a safetyproperty! Will alsolikelyneed to link the statemachine to the system that it is controlling and check that the desiredfunctionality is achieved Message: try to raiselevel of abstraction of properties(whilekeepingthemshort and simple)

8. Example: simple bus interfacespec (1) 1. 2 commands, read and write (with corresponding signals) 2. Commandcan be issuedonly after requesting the bus, indicated by a pulsedassertion of signal bus_req, and receiving a grant, indicated by the assertion of signal gntonecycle after the assertion of bus_req 3. If the bus was not requested, it shouldn’t be granted 4. Command is issued the cyclefollowingreceipt of grant 5. Either a read or a writecan be issued, not bothsimultaneously

9. Example: simple bus interfacespec (2) 6. Reads and writes come with an address, on addr[7 downto 0], that should be valid in the followingcycle 7. Addressvalidity is indicated by signal addr_valid 8. If a read is issued, thenonepulse of data on data_in[63 downto 0] is expected the followingcycle 9. If a write is issued, thenonepulse of data on data_out[63 downto 0] is expected the followingcycle 10. Valid read data is indicated by data_in_valid and valid write data by data_out_valid

10. Example: simple bus interfacelowlevel checks 2, 4. assertalways ((read or write) -> ended(bus_req; gnt; true)) Built in function Returnstruewhen the SERE has just ended

11. Example: simple bus interfacelowlevel checks 3. assertalways (not bus_req -> next (not gnt))

12. Example: simple bus interfacelowlevel checks 5. assertnever (read and write)

13. Example: simple bus interfacelowlevel checks part of 6,7. assertalways ((read or write) -> nextaddr_valid) assertalways (not (read or write) -> next (not addr_valid))

14. Example: simple bus interfacelowlevel checks 10. assertalways (read -> nextdata_in_valid) assertalways (not read -> next (not data_in_valid)) assertalways (write -> nextdata_out_valid) assertalways (not write -> next (not data_out_valid))

15. Example: simple bus interfacelowlevel checks Havechecked the protocol but not mentioned the addr, data_in or data_out buses Need to thinkabout overall functionality as well as lowleveldetails

16. Example: simple bus interfacehigh level checks Let’sassumetwo input signals get_data and put_dataindicating that a read or write is needed Assumealsowehave a way to recognise, at the assertion of get_data or put_data, the data that needs to be read or written (from addressget_addr[7 downto 0] to read_buffer[63 downto 0] or from write_buffer[63 downto 0] to addressput_addr[7 downto 0]) Assumealso a suitablememory

17. Example: simple bus interfacehigh level checks assertforall ADR[7 downto 0] in boolean: always ((get_data and get_adr[7 downto 0] = ADR[7 downto 0]) -> eventually! (read_buffer[63 downto 0] = mem[ADR[7 downto 0]])) Notes: havemadesomeassumptionse.g. aboutmemory not changing after read included to show some of the fancier PSL constructs and use of bus structures

18. Main message Writebothlowlevel and high level checks Lowlevel checks will be easier to write– oftentranscribed from spec. High levelspecsconsiderdesiredfunctionality, whichmay be implicit in the spec. Hard to writebut high pay-off For one approach to a methodology for use of PSL, see the ProsydEuprojectweb page (www.prosyd.org) Containsmanyinterestingexamplesboth small and large(including the followingexample)

19. Common PSL errors Mixing up logicalimplication and suffix implication assertalways {req; ack} -> {start;busy[*]; end} Probablydidn’tmean start to coincide with req Source: the PSL book (Eisner and Fisman)

20. Probablymeant assertalways {req; ack} |=> {start; busy[*]; end} then if

21. Confusing and with implication Every high priorityrequest (req and high_pri) should be followedimmediately by an ack and then by a gnt assertalways (req and high_pri) -> next (ack -> nextgnt) or assertalways (req and high_pri) -> next (ack and nextgnt) or assertalways (req and high_pri) |=> {ack; gnt} Which? Why?

22. Confusingconcatentation with implication Are theseequivalent? assertalways {a; b; c} assertalways ( a -> next b -> next[2] c)

23. Confusingconcatentation with suffix implication Are theseequivalent? assertalways {a; b[+]; c} |=> {d} assertalways {a; b[+]; c; d}

24. Exercise Figureout from the standard what {SERE} (FL_property) means

25. Usingnever with implication assertalways (req -> next ack) req is alwaysfollowed by ack Twoconsecutivereqs are not allowed assertnever (req -> nextreq) ?

26. Usingnever with implication assertalways (req -> next ack) req is alwaysfollowed by ack Twoconsecutivereqs are not allowed assertnever (req -> nextreq) ?? or assertalways (req -> next (not req)) or assertnever {req; req} Which? Why? (And similarly for suffix implication)

27. Negatingimplications assertalways ((high_pri and req) -> ack) High priorityreq gives an immediate ack Lowpriorityrequestdoes not give an immediate ack assertalways not ((low_pri and req) -> ack) ?? Ex: Whatshould it be? Check all threeassertions on the followingtraces (And similarly for suffix implication)

28. req high_pri low_pri ack

29. req high_pri low_pri ack

30. Incorrectnesting of implications (1) If a request (assertion of req) is acknowledged (assertion of ack the followingcycle), then it must receive a grant (assertion of gnt) the cyclefollowing ack assertalways ((req -> next ack) -> nextgnt) Faults? Whatshould it be? (Write in both LTL and SERE style) Check on followingtrace

31. req ack gnt

32. Incorrectnesting of implications (2) Ifthere is a granted read request (assertion of reqfollowed by ack followed by gnt), theniftherefollows a complete data transfer {start; data[*], end}, then the wholethingshould be followed by an assertion of signal read_complete. assertalways({req; gnt; ack} |=> {start; data[*]; end}) | => {read_complete} ?? Fault? Whatshould it be? (Write with two suffix implications and with one) In the lattercase, thinkabouthowmoving the position of the suffix implicationchanges the meaning of the property

33. Thinking you are missing a ”first match” operator On the cycle after the first ack following a request, a data transfer shouldbegin assertalways ({req; [*]; ack} |=> {start; data[*]; end}) ?? Wrong: Demands a transfer after everyassertion of ack after the req.

34. Thinking you are missing a ”first match” operator On the cycle after the first ack following a request, a data transfer shouldbegin assertalways ({req; [*]; ack} |=> {start; data[*]; end}) ?? Wrong: Demands a transfer after everyassertion of ack after the req. Answer: useack[->]

35. ”Extraneous” assertions of signals assertalways {ack} |=> {start ; busy[*] ; done} ack start busy done

36. May wish to ruleoutsomebehaviours assertalways (ack -> not (start or busy or done)) assertalways {ack} | => {start and not busy and not done ; {not start and busy and not done}[*]; not start and not busy and done}

37. PSL Seems to be reasonably simple, elegant and concise! Jasper’s Göteborg based team havehelped to define and simplify the formal semantics. See the LRM (or IEEE standard) and also the paper in FMCAD 2004 In largerexamples, oneuses the modellinglayer (in VHDL) to augment specs, ending up with small and readable PSL properties