Want to see how DV Notebook works with your own data? We can demonstrate our products' powerful feature set in the comfort of your lab.
How many jobs are run per week to simulate, synthesize and analyze your FPGA/ASIC?
Select the most applicable answer
A single engineer can process 1000's of program outputs as long as no real work is needed. In contrast, if 100's or 1000's of errors are being generated, entire teams can quickly become overwhelmed. Efficiently organizing result data can allow a team to continue making forward progress and fully utilize simulation and computation resources.
If you do random testing, what percentage of randomized values are held constant after time 0?
Variables that are randomized prior to starting a test tend to be associated with functional coverage. Randomizing functional coverage can make it difficult to reproduce in regressions.
Which of the following risk factors have you seen de-rail a project?
Check all that apply
Much risk analysis in FPGA and ASIC design is focused on verification tools and code analysis. We are interested in some of the more human factors as well as those that come from other parts of the design and implementation team.
Assuming that 10 tests fail with the same error message in a single regression ...
All teams have constraints in head count, license count, CPUs, disk, and time. Customer experience varies in how to trade off machine hours for human or debug hours. When remote teams or vedors are involved, closing every issue can be difficult.
On past projects, which are the biggest hurdles for engineers to filing bug reports?
Bug tracking and source-control databases are some of the most comprehensive sources of project health data available. In hardware and software alike, bug rates are often used as a metric to measure risk and release readiness.
How many of the following people have you worked with?
Our customers have given us feedback that different teams have different dynamics. Many corporate processes like bug tracking, code reviews, spec reviews and the like are more effective in some teams than in others.
When an RTL module has 600 lint warnings ...
An RTL module needs to be lint clean in order to be accepted by many downstream tools. Different teams treat their lint results differently. Some teams check lint results into source control to track progress on model cleanliness.
In your experience, requirements discussions and architectural simulation ...
Many larger teams have separate architecture and implementation groups. In these teams, divergence can occur when the RTL and verification teams are implementing one interpretation of a feature while marketing and architecture groups are working under a different interpretation.
On Monday morning, after letting a synthesis or simulation run all weekend ...
The number of compute jobs that a team can run is bounded by their ability to process and understand errors. When an engineer's email tool or unix disk is the main source of history and classification, it demands more of each engineer.
When a new problem pops up in an RTL module ...
Revision control systems are important in most hardware and software development. Often, there is no comparable tracking of the changes in output results over time. Even when outputs are checked into revision control, they are often in a format that does not lend itself to diff or other change tracking tools.
When planning the schedule for our next project ...
Forecasting project schedules is difficult. On one team, an engineer will be asked to pad his schedule. On another, he will be asked to trim the fat before the project has even begun. Some companies, whose products bear a strong resemblance generation after generation have tackled this problem by maintaining databases of time and effort for each module and feature.
When management asks to drop features and pull in the schedule ...
It can be hard to turn the ship. Correlating features to workload requires high quality information on the status of each feature and the workload of the team.
When analyzing code coverage ...
Each code change degrades our confidence in project metrics such as coverage closure and timing closure. Analyzing these metrics requires tight integration with the revision control system in order to account for stability. This integration also allows teams to appreciate the cost of re-doing downstream work after any source code change.
Submit your answers to enter the Achilles DVCon 09 drawing for a Nespresso D90 espresso machine. The winner will be notified via email on March 27th 2009.
Your email address will be treated as confidential information and will not be released or sold to any third party. Please see our Privacy Policy if you have any questions.
© Copyright 2008 Achilles Test Systems, Inc. Valid XHTML & CSS.
