1 / 23

Design and Verification in the ForSyDe Methodology

Design and Verification in the ForSyDe Methodology. Tarvo Raudvere Royal Institute of Technology tarvo@imit.kht.se. Motivation for ForSyDe. Trends Increasing capacity of integrated circuits allows to integrate more and more functions on a single chip

mason-valencia
Download Presentation

Design and Verification in the ForSyDe Methodology

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. Design and Verification in the ForSyDe Methodology Tarvo Raudvere Royal Institute of Technology tarvo@imit.kht.se

  2. Motivation for ForSyDe • Trends • Increasing capacity of integratedcircuits allows to integrate more and more functions on a single chip • SoC-architectures may include a variety of components: microprocessors, DSP cores, memories, custom hardware and analog parts • Conclusion • Simulation is not enough • System-level design methodologies have to incorporate formal methods

  3. Outline • Motivation • Design Flow • Design Refinement • Gradual Design Verification • Verification Example • Conclusion

  4. ForSyDe (Formal System Design) • Objective • Addresses the design of reactive system-on-chip applications with control and data flow parts • Foundations • Start with a purely functional and deterministic system specification • Uses a synchronous model of computation • Uses a functional modeling language with formal semantics • Allows for formally defined design transformation • Allows to interpret the system model into a hardware and software interpretation

  5. Specification Model DesignConstraints Functional Domain Design Refinement Verification Transf. Library Implement. Model Implementation Mapping Implementation Domain HW Description Interface Description SW Description The ForSyDe Design Flow

  6. Specification Model • Is based on a synchronous model of computation • Is purely functional and deterministic • Uses process constructors • Uses possibly infinite/ideal data types • Implies a concurrent process model • Can be refined during design transformations

  7. A system is specified as a function of the system inputs A function can be composed of the other functions A function has no side effects There is no global state System inputs are signals A functional system specification is deterministic Concurrency is implicit Functional Specification system i1 f s1 i2 o1 h s2 i3 g o1=system (i1,i2,i3) where s1 = f (i1,i2) s2 = g (i3) o1 = h (s1,s2)

  8. Synchronous Assumption • The system computes infinitely quickly • Each reaction divides time into a sequence of discrete instants • A system reaction to an input appears at the same time as the input • The synchronous assumption leads to a clean separation between communication and computation Values Process v3 v2 v1 v’3 v’1 v’1 t3 t2 t1 t3 t2 t1 Tags Event

  9. Process Constructor • is a higher-order function • is used for synchronization • has a hardware and software interpretation • allows for design transformations • is used to create processes

  10. Tag Process 3 2 1 0 1 8 2 Value Event AbsentValue Process Constructor mapSY Timing Signal 3 2 1 0 2 9 3 Computation

  11. System as a process network system (s1,s2,s3) = s7 where s4 = B1 (s1,s2,s6) s6 = B2 (s3,s5) (s7,s5) = B3 (s4) B3 (i1) = (o1,o2) where (o1,o2) = P6 (i1) P6=mealySY(f,g,m0) f::Int->Int->Int f a b = (a+b) mod 4 system s1 B1 P1 s4 P3 s2 s7 P2 P6 s6 B3 s3 P4 P5 s5 B2

  12. Process Network Sub-Domain(Rate: n) Implementation Model Domain Interface • may contain synchronous sub-domains • is described in terms of limited resources • can be mapped to hard- and software (VHDL,C) Process Network n Process Network m n m Main Domain(Rate: m) Main Domain(Rate: m)

  13. Semantic PreservingTransformation Do not change the meaning of the model Used mainly for process merging and splitting M1 Mn ImplementationModel T1 T2 Tn The specification model (M0) is stepwise refined by the use of well defined design transformation (Ti) into an implementation model (Mn) Refinement of the Specification Model Specification Model M0 • Design DecisionTransformation • Change the meaning of the model • Introduce a design decision • Examples are refinement of data types, constraining buffer sizes

  14. Verification in ForSyDe • Global properties are verified by simulation • Local properties of design blocks can be checked through model checking • Design transformation contains information about the changes in the model, that can be used for defining relevant verification properties

  15. Specification model Trans- formation library Input stimuli gen. Property library Design Constraints B1 B2 B3 T B1 B’2 B3 Input stimuli Block B’2 Property checker Implementation model Verification Gradual design verification

  16. Assumptions for gradual verification • The specification model is correct • Only the local correctness of the system is verified through model checking • The designer is aware of the constraints for every design block • Design blocks are small enough, that existing verification tools manage the tasks in reasonable time

  17. Verification Details • For every design transformation there is a set of predefined properties • There are templates to assist the user to model the design environment for design blocks • Abstraction has to be done by the user • The Cadence version of SMV (Symbolic Model Verifier) is used for verification • Translation from ForSyDe into SMV is straight forward

  18. Refinement of the Equalizer System Model Button Control Dist. Control HoldLevel LevelControl Distort.Control CheckLow Freq Buttons PowerSpectrum FIR1 Amplifier Audio Filter FFT AudioIn FIR2 Amplifier Sum GroupSamples FIR5 Amplifier Audio Analyzer AudioOut

  19. V Button Control Audio Filter Transformation: ChannelToHandshake V Receive V Send Button Control Finite FIFO Audio Filter Refinement into a Handshake Protocol • The handshake protocol introduces a delay between Send and Receive • The FIFO buffer stores the input data if the channel is busy with the previous arrival • The FIFO size must correspond to the load on the channel

  20. Verified properties Reliability: The only data loss is caused by overflow. (1 sec.) Latency: It takes a fixed number of clock cycles to transport data through the channel. (0.2 sec.) Bandwidth: An input stream with a certain data rate causes no FIFO overflow. (0.2 sec.) Order: Present values on the channel output preserves the same order they have on the input. (400 sec.)

  21. Requirements • For every new design transformation a set of properties has to be defined, which are obligatory to verify • In order to avoid state space explosion, abstraction has to be applied. • The proper abstraction technique should be selected according to: • specific design transformation • the properties that we verify

  22. Conclusion • The ForSyDe methodology supports formal system design • Design flow starts at a high abstraction level • Design is refined through the well-defined design transformations • Implementation can be mapped to soft- and hardware • Verification is applied during the design refinement

  23. Thanks for your attention!

More Related