Aldec Design and Verification
Sunil is Corporate Applications Engineer at Aldec. Sunil provides support for customers exploring simulation tools as an Aldec Applications Engineer. His practical engineering experience includes areas in, Digital Designing, Functional Verification and Wireless Communications. He has worked in wide … More »
August 19th, 2014 by Sunil Sahoo
During a recent trip to Austin, Texas, I spent some time with Aldec Partner, Victor Lyuboslavsky of Victor EDA and creator of the EDA Playground. Victor EDA is one of those organizations that Aldec aligns easily with because we share a strong commitment to accelerate learning within the engineering community by providing the right tools, training and resources.
As a result of this partnership, we are pleased to announce that Aldec Riviera-PRO EDU™ Advanced Verification Platform is now available on EDA Playground.
Here’s an excerpt from Victor’s recent guest blog post on the Aldec Design and Verification Blog, that illustrates how engineers can benefit from leveraging this tool to practice UVM & SystemVerilog simulation:
You may have found yourself among those eyeing the job market and wondering, “How hard is it to switch fields and become a verification engineer?”
July 30th, 2014 by Krzysztof Szczur, Hardware Verification Products Manager
I am a Hardware Technical Support Manager. Ask Me Anything!
Earlier this summer, I joined a team traveling from Aldec’s R&D offices in Kraków, Poland to attend the annual Design Automation Conference (DAC) in San Francisco. As Technical Support Manager for Aldec’s Hardware Products Division, my goals for this event were two-fold. First, as we’ve made huge enhancements to our HES-7™ FPGA prototyping solution in the past year, I wanted to be there in person to share more about them in demos and presentations at the Aldec booth.
Secondly, and really my favorite part of DAC, I wanted to hear from engineers in the field looking for solutions to their real-world problems. Sometimes I have immediate answers for their questions, like the engineer who was not happy with their current solution’s implementation time or the fellow that needed support for in-house development boards. Occasionally though, I don’t have an immediate answer and instead they’ve given me valuable ideas that I get to take back home to my team so we can set to work developing solutions.
July 16th, 2014 by Louie De Luna
If they’re being honest, anyone who has verified an FPGA under strict DO-254 guidance will tell you that it is stressful. Show me an engineer on their first DO-254 project – and I’ll show you someone pulling out their hair and downing what is probably their 5th cup of coffee while these important questions weigh heavy on their minds:
Have we reviewed all FPGA requirements and validated derived FPGA requirements? Do we have a good record of the review activities?
Do I have a test for each functional FPGA requirement? What’s the status of the tests? How do I track the progress and document the results?
June 24th, 2014 by Louie De Luna
Aldec has been working closely with Elbit Systems in Israel on an important DO-254 project for some time now. Using Aldec’s specialized solution DO-254/CTS™ as their primary FPGA physical testing platform, Elbit recently passed a critical EASA verification audit for DO-254/ED-80 DAL A FPGAs.
As a DO-254 evangelist, I have long recognized the value and benefits of Aldec’s solution to the avionics industry, so it was particularly rewarding to hear these words from Moshe Porian, Logic Design Verification Group Leader at Elbit Systems Aerospace Division, “Aldec helped us solve several of our verification challenges. This is the first time in Elbit’s history that we have been able to bring more than 5 FPGA devices to the audit.”
DO-254/CTS solved Elbit’s major challenges, enabling them to test in hardware 100% of FPGA pin-level requirements. As opposed to developing software test vectors, Elbit used their simulation testbench as test vectors for FPGA at-speed testing which cut their development costs. For the rest of this article, visit the Aldec Design and Verification Blog.
May 15th, 2014 by Satyam Jani
Alex Grove, FirstEDA Applications Specialist, was kind enough to author a guest blog for Aldec. Here’s an excerpt:
Here in Europe, I recently had the opportunity to work with Jim Lewis, OS-VVM Chief Architect and IEEE 1076 Working Group Chair, on the first Advanced VHDL Testbenches & Verification training course. This training, held in Bracknell, UK, was attended by engineers from several major European system companies who design and verify programmable devices (FPGAs). VHDL is by far the dominate language used by Europe’s system companies for the design and verification of FPGAs, however it is unclear to many how to enhance their verification with VHDL. What I have found is that experienced FPGA design engineers (including myself) are not utilising the VHDL language for verification.
Jim Lewis introduces VHDL’s verification capabilities, including new VHDL 2008 features and the Open Source VHDL Verification Methodology (OSVVM). OSVVM provides a methodology for testbench development and verification packages that provide functional coverage and random value generation. Read the rest of OS-VVM CoveragePkg, A Detailed Example
April 9th, 2014 by Louie De Luna
– 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.
March 13th, 2014 by Sunil Sahoo
In James Bond movies, Agent 007 has some awesome gadgets but never listens to Q’s instruction on how to use them properly. I’ve often wondered what it would be like if Bond actually did learn about the various features of his tools and how to use them most efficiently.
Sure, that would probably eliminate all of the plot twists that make for a great movie, but when it comes to real life – I don’t care for plot twists. What about you? If you were a secret agent given these tools to keep you out of trouble or even save your life – would you take the time to learn about all of the features?
February 20th, 2014 by Louie De Luna
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.
January 21st, 2014 by Louie De Luna
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.