1 / 37

More on PSL

More on PSL. some examples , s ome pitfalls. FSM. start. continue. continue. idle. p1. p2. p3. cancel. cancel. done. Low level assertions. a ssert always (( state = idle and start) -> next ( state = p1)); a ssert always (( state = idle and not start) ->

helene
Download Presentation

More on PSL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related