Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis,

Transcription

1 TM November 2012 Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, mobilegt, PowerQUICC, Processor Expert, QorIQ, Qorivva, StarCore, Symphony and VortiQa are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. Airfast, BeeKit, BeeStack, CoreNet, Flexis, Layerscape, MagniV, MXC, Platform in a Package, QorIQ Qonverge, QUICC Engine, Ready Play, SafeAssure, the SafeAssure logo, SMARTMOS, TurboLink, Vybrid and Xtrinsic are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners Freescale Semiconductor, Inc.

2 Timing constraints are inputs to any timing driven closure; as such they are equivalently important to RTL code timing constraints are the specification of timing intent usage of constraints for synthesis and STA : implies no verification An incorrect constraint will turn into a self-fulfilling prophecy very limited verification by gate level simulations possible Requires targeted coding of stimulus that cover related timing aspects usual check of constraints: by reviews? How to identify an incorrectly coded timing constraint?? How to identify the completeness/consistency of a constraint?? How to identify the correct application of a timing constraint to all areas/logic where it applies? TM 2

3 Significanty different methods of verification and tool support: High level simulations using generated or specific high-level models Directed and random RTL or gate level Formal verification approaches (assertions, model checking) Other methods (e.g. AMS simulations, structural analysis, reviews,...) Multiple verification levels performed by different people: IP verification (IP): focusing on correct implementation of the IP SoC integration (SoC): focusing on interfaces and correct connectivity System Test (SoC/Systems): focusing on system functionality Further complications by parameterized IP and the effects of staged verification performed by different teams? How to determine a realistic verification coverage for all methods?? How to combine the sometimes significantly differing viewpoints?? How to identify areas missing appropriate verification? TM 3

4 There are many, different viewpoints of a design of importance: Usually there are multiple device modes that need to be verified Application run modes (high performance, standard, low power, safety recovery) Test modes (ATPG, analog test, logic BIST, application self-test on/off-line) Timing aspects (mode dependent!), power (voltage domains/run modes) Analog aspects of the SoC Reset phase Low voltage... behavior before and when reaching a brownout condition Interaction between digital control logic and analog blocks (e.g. ADC, PLL, OSC, voltage regulators,...) behavioral model for verification? Many of this aspects have a separate methodology for verification; sometimes these are an art on its own (STA, AMS of reset phase) Verification of combined aspects, and especially mode transitions (e.g. safety recovery after a brownout) is basically impossible TM 4

5 TM