Open side-bar Menu
 Aldec Design and Verification

Archive for the ‘DO-254 Compliance’ Category

The 80s music at DAC was my idea. You’re welcome.

Tuesday, June 24th, 2014

If you attended the Monday Night Reception at DAC 2014, you were greeted with a blast of 80s pop music. If you then said to yourself, “I’d like to meet the genius behind that idea” – that would be me. A few weeks before DAC, our marketing manager came to me with the task of being the DJ for the Monday night reception. As soon as I heard “DJ” I envisioned turntables, cool headphones, disco lights and all the fame that follows. My dreams were dashed a few moments later when she explained that I would only have a PA and a laptop.

Undaunted, I resolved to be the best DJ in the history of DAC Monday Night Networking Receptions. The first challenge was finding music everyone would enjoy. I naturally settled on 80s pop as my genre. I had the brilliant idea of picking a few songs from each year and playing it as a progressive 80s timeline during the evening. I changed my mind when I realized that bright idea would require some serious manual research and work.

Did I give up? Of course not. I did what any good engineer would do – I found an easy (and smart) solution that did not require substantial extra effort – a bit like re-using verification ip’s instead of making them from scratch. This level of engineering genius is often mistakenly perceived as laziness, but I like to call it being smart. In fact I recently wrote a blog on the topic of working smart not hard.

For the rest of this article, visit the Aldec Design and Verification Blog.

See the Future with Impact Analysis

Wednesday, April 9th, 2014

Imagine if you could look into the future…

–   See the impact of requirements changes before they occur.

–   Know with certainty which lines of code in an HDL design or testbench file needed to be re-evaluated based on a change request.

–   Understand how a requirement change impacts the project schedule to help plan and allocate resources effectively.

Impact Analysis Defined

Seeing the future is possible with Impact Analysis, a practice within the change control process of product development. Impact Analysis provides information on what design and verification elements, artifacts, hardware components and materials, personnel, assets or activities that may be affected due to a requirement change. Armed with Impact Analysis data, you can then determine which elements to re-evaluate, modify, and even re-create if necessary.


For DO-254 Compliance, Hardware Flies Not Simulations

Thursday, February 20th, 2014

DO-254 defines 3 types of verification methods: Analysis, Test and Review. In order to satisfy the verification objectives defined in DO-254, applicants must formulate a requirements-based verification plan that employs a combination of the three methods.

Analysis vs. Test

A computerized simulation of the hardware item is considered an Analysis. Test is a method that confirms the actual hardware item correctly responds to a series of stimuli. Any inability to verify specific requirements by Test on the device itself must be justified and alternative means of verification must be provided. In DO-254, the hardware test is far more important than the simulation. Certification authorities favor verification by test for official verification credits because of the simple fact that hardware flies, not simulation models.  Requirements describing pin-level behavior of the device must be verified by hardware test.


Still managing FPGA requirements with Word and Excel?

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.


Much has changed in the last 30 years

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.


It’s no accident that Aldec offers the best VHDL-2008 support

Wednesday, December 11th, 2013

Here at the Aldec corporate office, we have a sign that reminds us all of our mission in the field of Technology. It reads, ‘To deliver solutions that provide the highest productivity to value ratio; supporting our existing products while delivering innovation to current and new technologies’. We have similar statements to reaffirm our commitment in the areas of Research, Alliances, and Culture – we call it our “Aldec DNA”.

Because we genuinely want to have a clear understanding of our user’s requirements and methodology preferences, we continually engage in surveys and interviews.  The knowledge we gain better positions us to support our existing products and to deliver that support where it matters the most to our users. If you’ve ever had that frustrating experience where your favorite tool no longer supports your methodology of choice – then you understand why this is so important.

Our Commitment to the VHDL Community

When it comes to VHDL-2008, we have learned from our customers that many are happy using the methodology – and continue to successfully deliver cutting-edge technology with it. So, while we remain committed to delivering innovation to new technologies, our R&D teams also invest a great deal of development time to ensure that Aldec solutions continue to offer a high level of support for popular languages like VHDL.

For the rest of this article, visit the Aldec Design and Verification Blog.

Does DO-254/CTS™ Support FPGAs with Serial High-speed I/Os?

Wednesday, November 20th, 2013

As a DO-254 evangelist, I travel quite a bit attending conferences and meeting customers all over the world. One question I occasionally get from engineers is whether Aldec’s mil/aero verification solution, DO-254/CTS™, supports verification of FPGA designs with high speed interfaces (for example ARINC 818, LVDS, DDR3 or PCIe).

Depending where I’m at I’ll tell them, “Oui!” or “Hai!” or simply “You bet it does”. Occasionally I’ll respond, “화장실이 어디 있어요!” in hopes that someone will kindly direct me to the nearest restroom.

For the rest of this article, visit the Aldec Design and Verification Blog.

Following the Roadmap to Successful Traceability

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.


DO-254: Insights from a DER

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.


Demystifying Traceability

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.


Verific: SystemVerilog & VHDL Parsers
TrueCircuits: UltraPLL

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy