The executable architecture model is then also simulated. Simulation issupported at all levels, ranging from RTL or gate-level to cycle-accurate co-simulation of the entire hardware/software system using tools such as MentorSeamless CVE 77, or Axys MaxSim 8. Recently VaST, who started in theSoC and consumer electronics market, extended its CoMET 129 design andsimulation environment to also cope with the specific problems of automotivesystem design. Simulation has some obvious advantages. Using the same sim-ulation environment, the same verification patterns, and benchmarks alreadyavailable from functional verification, designers have elegant means to test anarchitecture design against a functional specification.The co-simulation times are extensive because performance simulation re-quires detailed timed models that are usually more complex than the un-timed–or simplified– models used in function verification. This is a major bottleneckduring design, and becomes particularly painful in iterative design space explo-ration, reducing optimization possibilities, and consequently, system quality.Abstract simulation using, for instance, Cadence VCC 19, is faster and pro-vides temporary relief but comes at the cost of introducing yet another model.Test is the fastest but can only be applied very late in the design process; andmore important than the speed, there is a serious, conceptual limitation to test-and simulation-based performance verification that becomes critical as com-plexity increases.While function verification can also check for correct functional component(integration) interactions, the complex component performance dependenciesthat integration, and especially resource sharing introduces, are only partiallyvisible in the system function, if at all. As a consequence, function verificationpatterns will most likely miss some of the critical performance corner casesillustrated in the preceding section. Identifying all performance corner casesis extremely difficult, and it is even more difficult to find patterns that reach allof them.So, where do we get the patterns from? On the one hand, re-using the pat-terns from function verification is not sufficient because they do not reflectarchitecture dependencies that scheduling introduces. On the other hand, com-ponent verification patterns –if available– are not sufficient, either, becausethey do not cover the complex component interactions that result from systemintegration.