Posts Tagged ‘design’
Monday, March 26th, 2018
As an Applications Engineer I visit lots of potential customers, or talk to them at trade shows, who are doing FPGA designs but don’t own a commercial simulator. I ask them why that is. Most of the time it is budgetary restrictions. They don’t have funds to buy additional tools. I understand their situation and point out to them that at Aldec we have a very cost-effective simulator. But that is not what I want to talk about in this blog. I want to talk about engineers who say: “I am happy with the simulator my FPGA vendor provided me”, or “My simulations only take 15-20 minutes to run, I don’t think I need a faster simulator”, or “We don’t run simulations”.
That last response haunts me the most. For instance, at a recent site visit I was told: “We just load the design on our FPGA and test it out”. I asked how long does a full test iteration (i.e. program FPGA -> test -> debug -> re-code -> re-program) takes. They said about an hour or two, depending on the bug. I then asked how much of that time spent just running synthesis and programming the board? They said about 30 minutes.
Next, I proceeded to explain the benefits of running simulations in such scenario.
Granted, the test on the board will run much faster than a simulation, but you are very much limited by the peripherals that are hooked up to the board. For example, how quickly can you run a new test after one has just completed? Also, there is the matter of synthesizing and implementing the design every time you want to run a new test after a code change.
Imagine how much quicker you can run simulations because you don’t have to go through the above steps. If one tests fails, you could be running another in the background while you debug the one that failed. And let’s not forget the debug capabilities that simulations provide. These include the ability to access internal registers in the design, compare waveforms, and much more.
For the rest of this article, visit the Aldec Design and Verification Blog.
Monday, April 10th, 2017
Most everyone would agree how important FPGA prototyping is to test and validate an IP, sub-system, or a complete SoC design. Before the design is taped-out it can be validated at speeds near real operating conditions with physical peripherals and devices connected to it instead of simulation models. At the same time, these designs are not purely hardware, but these days incorporate a significant amount of the software stack and so co-verification of hardware and software is put at high importance among other requirements in the verification plan.
However, preparing a robust FPGA prototype is not a trivial task. It requires strong hardware skills and spending a lot of time in the lab to configure and interconnect all required peripheral devices with an FPGA base board. Even more difficult is to create a comprehensive test scenario which contains procedures to configure various peripherals. Programming hundreds of registers in proper sequence and then reacting on events, interrupts, and checking status registers is a complex process. The task which is straightforward during simulation, where full control over design is assured, becomes extremely hard to implement in an FPGA prototype. Facing this challenge, verification engineers often connect a microprocessor or microcontroller daughter card to the main FPGA board. The IP or SoC subsystem you are designing will be connected with some kind of CPU anyhow, so this way seems natural. Having a CPU connected to the design implemented in an FPGA facilitates creating programmatically reconfigurable test scenarios and enables test automation. Moreover, the work of software developers can be now reused as the software stack with device drivers can become a part of the initialization procedure in the hardware test.. The software can become a part of the initialization procedure in the hardware test. If that makes sense to you, then why not use an FPGA board that has all you need – both FPGA and the CPU?
Tuesday, October 27th, 2015
Just in time for Halloween, Aldec has released a popular past webinar Don’t be Afraid of UVM for Hardware Designers on YouTube.
Designers are usually very busy doing their work and have little time left for experimentation with new methodologies. Unfortunately for them, official documentation of UVM (Universal Verification Methodology) was written by Verification Engineers for Verification Engineers, concentrating on high-level features and completely neglecting lower-level details such as connecting UVM testbench to your design.
Our webinar starts with solid review of SystemVerilog interfaces with special attention paid to Virtual Interfaces. Then it proceeds to Sequences and other Data Items, processed by Sequencers and fed to the design under test via Drivers. The role of Monitors and Scoreboards in analysis of results is explained. The presentation concludes with environment configuration and running test from the top-level module.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tuesday, September 8th, 2015
Wednesday, July 16th, 2014
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?
Tuesday, June 24th, 2014
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.
Thursday, May 15th, 2014
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. (more…)
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.