Archive for the ‘Requirements Management’ Category
Tuesday, January 21st, 2014
Smart engineers work smart by using tools that are readily available and that they know how to use. Wise engineers work wisely by first evaluating the options, analyzing the results and making a strategic decision not only for the current project but, more importantly, for upcoming projects as well.
Recently, a customer developing avionics systems came to us with their frustrations in managing FPGA requirements. They managed higher level requirements, such as line replaceable unit (LRU) and circuit card assembly (CCA) requirements, in IBM DOORS. The FPGA requirements, test cases and their traceability to HDL design, testbench and simulation results were managed using Word and Excel. Since DOORS lacked the capability to trace to FPGA design and verification elements necessary for DO-254 compliance, the customer felt they had to choose Word and Excel.
Why? Because Word and Excel are readily available and the team members already know how to use them. But as their projects grew in complexity increasing the number of requirements to be managed, they found that Word and Excel have many shortcomings and realized that they are not the right tool when it comes to requirements management and traceability.
For the rest of this article, visit the Aldec Design and Verification Blog.
Friday, January 10th, 2014
When I first launched Aldec in 1984, home computers hadn’t quite taken off and innovations such as the compact disk and those oversized, power draining cellphones were still struggling to obtain mass acceptance.
Fast forward 30 years, even those of us in the electronics industry have whiplash from the speed at which technology is advancing and delivering new products. Buyers are more eager to become early adopters of innovative new technology, and smarter, faster tools are required to keep pace.
As a long-time member of the Electronic Design Automation (EDA) community, Aldec has had a front row seat to the technology race and over the years we have celebrated many successes of our own. Here, our product managers reflect on some of our most memorable highlights from 2013.
Monday, September 23rd, 2013
If DO-254 is both the mission and the map required to achieve compliance, then traceability represents the roads on that map. Consider this.
– Roads connect two or more places on a map; traceability connects two or more elements in a project (such as functions, requirements, concept, design, verification data and test results).
– Road names help identify specific places that are linked to it; traceability names help identify specific project elements that are linked to it.
– In the absence of roads, reaching your destination is practically impossible; in the absence of traceability achieving compliance is also practically impossible.
Wednesday, June 26th, 2013
An Interview with FAA Consultant DER, Randall Fulton
A few weeks ago I had the opportunity to sit down with an avionics industry certification expert, FAA Consultant Designated Engineering Representative (DER), Randall Fulton. We began discussing common mistakes in DO-254 projects, and then branched out to many different areas including future of DO-254, industry engineering best practices, and his advice to organizations new to DO-254.
Louie: In your experience, what are the common mistakes in DO-254 projects?
Randall: Starting certification liaison activities and the SOI-1 planning audit after the design already exists. Many projects also need to read the additional guidance from the FAA in Order 8110.105 to understand the impact and be prepared to show the data to satisfy the Order. Organizations also underestimate the resources required for a project. This includes staffing as well as managing all the data. Another common area is not appreciating the impact of effective requirements writing skills.
Monday, June 17th, 2013
For DO-254 Compliant FPGAs and ASICs
I have been getting a lot of questions from our customers about traceability in the context of DO-254 and airborne FPGAs and ASICs. It seems that there are several new concepts and terminologies associated to traceability that are new to most of us. So I thought I would shed some light in this blog and explain the basic 5 terminologies. Also I have always liked the word “demystify”, but never had the chance to use it – so here is my chance.
Traceability – Traceability is the activity that maps all of the design and verification elements back to requirements to ensure that what is being built and tested is based on the requirements. Traceability is the correlation between system requirements, FPGA requirements, conceptual design, HDL design, post-layout design, verification test cases, testbench and test results.
Downstream Traceability – A top to bottom reporting activity that shows the mapping or correlation between system requirements, FPGA requirements, HDL design, test case, testbench and test results. Running a downstream traceability can expose FPGA requirements that are not implemented by any HDL function or not covered by a test case.
Upstream Traceability – A bottom to top reporting activity that shows the mapping or correlation between test results, testbench, test case, HDL design, FPGA requirements and system requirements. Running an upstream traceability can expose derived FPGA requirements or unused HDL functions. Tools like Spec-TRACER can also use upstream traceability to expose all of the design and verification elements associated to a FAILED simulation result.
Tuesday, June 11th, 2013
Functional Verification Insights from Austin
I just returned back to the office from the 50th Design Automation Conference (DAC) which took place in Austin, TX, on June 2—6. As I began compiling my trip report, I thought that I might share some of my observations, especially for those who couldn’t attend this industry event but still wanted to gain some insight.
One of the reasons I like DAC is that it has always been the main industry event, attracting people from all over the world, and provides participants with the opportunity to meet most of their key customers, ecosystem partners, and competitors in a single location. From an exhibitor’s perspective, DAC is mainly about engaging with attendees on the floor, learning about their current and anticipated challenges, and educating them on how they can innovate and succeed using our product offerings.
Monday, May 20th, 2013
With the explosion of both in size and complexity of today’s FPGAs and ASICs, methodologies to efficiently manage and control requirements from concept to product rollout have never been more crucial to produce high quality and reliability products on time and within budget. Developers of FPGAs and ASICs used for safety-critical applications face even greater challenges because of the strict requirements-based development process they have to follow to achieve industry compliance.
How do we make sure that our final product safely functions as intended? How do we manage and track requirements changes effectively? Do the developers know what requirements changed? How do we establish and maintain traceability? Have we tested all the requirements? These are real and common questions and challenges that arise during FPGA/ASIC development for safety-critical applications.
Thursday, May 16th, 2013
This year’s Design Automation Conference (DAC) will be held in Austin, Texas. If we survive the 70% humidity, our team looks forward to meeting you at Booth #2225 from June 3-5. Aldec HQ is located in Nevada just outside of Las Vegas… so we’re accustomed to more of a dry heat.
We invite you to register at www.aldec.com/dac2013 to attend a technical sessions led by Aldec’s top engineers from all over the world. I can’t stress enough how important it is to pre-register since these sessions do fill up quickly. You’ll also get a free t-shirt when you attend one of our sessions – we’ve designed some pretty cool ones to give away this year.
Aldec has also teamed up with Agilent to deliver a DAC Insight Presentation on Wireless Algorithm Validation Wednesday, June 5, 2013 from 2:00-4:00pm. Learn more.