I am totally in agreement with you then. The current functional coverage is badly architected and does not scale. Companies have too many problems relating use case coverage to functional coverage poinbt. I think use cases are the key and these can be broken down into ways in whgich use cases can be satisfied. Problem is that EDA companies have too much invested in functional coverage to want to change.
no, I am asking how to define function coverage efficiently. Now we can only extract cover points from design spec, and it is for verification only. Above discussion looks like related to expanding functional coverage to system level. I am wondering how to achieve it. And how to organize it and make it as "simple" as code coverage.
who should be the person to define the system level functional coverage matrics? How to prove it is complete. If it is not a complete matrics, it is meaningless to target it and if it is too complex, quite difficuit to get 100%. Functional coverage is not like code coverage with which we have a good reference. (RTL code)
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.