Posts Tagged ‘co-simulation’
Monday, March 26th, 2018
 In this blog, I am going to discuss different phases that UVM follows.
The reason why UVM came up with such phases is because synchronization among all design-testbench was necessary. Using Verilog and VHDL, verification engineers did not have facilities such as clocking block or run phases. Now, it is very important that the time at which test vectors applied from test-bench reaches the Design Under Test(DUT) at the same time. If timing for different signals varies then synchronicity lacks and thus verification can not be achieved as expected. That is the main reason why UVM has different phases.
The whole environment of UVM is structured on phases. They are active right from the beginning of the simulation to the end of the simulation. The topic discussed here will help people who are new to UVM. To start with, most of the phases are call back methods. The methods are either function or task. They are all derived from the UVM_Component class, same as other test-bench components. If you remember the first blog, we went through how to write a class. We understood the OOP concepts such as inheritance and even used them by extending the base class. Now, creating objects of the class is also important in order to use it as and when required. It is known as build_phase. This step takes place first. Next, after we write different classes, it is important to connect them. For example, if I write different classes with different functionality, at the end I provide them all under one top class. In Verilog it was top level module. In system Verilog it was class Environment. Under that main class, you connect all your semi classes which is known as connect_phase. Next, comes the end_of_elaboration_phase. By the time this phase becomes active, everything is connected and simulation next moment on wards is ready to begin.
(more…)
Tags: asic, co-simulation, coverage, debugging, documentation, FPGA, osvvm, Riviera-PRO, uvm, verification
No Comments »
Monday, January 29th, 2018
 In this blog, my major focus is on explaining the concepts such as Sequence, Sequencer, Driver and showing how the communication takes place from sequence to sequencer and from sequencer to driver. In the previous blog, I included a top-level diagram of the UVM structure, showing different base classes. If you need refresh your memory on where the classes Sequence, Sequencer and Drivers stand please click https://www.aldec.com/en/company/blog/149–understanding-the-inner-workings-of-uvm.
So, let’s look at the main concepts and follow the communication mechanism they use for the effective execution of a test.
(more…)
Tags: asic, co-simulation, coverage, debugging, documentation, FPGA, os-vvm, Riviera-PRO, uvm, verification
No Comments »
Wednesday, November 29th, 2017
 Data analysis is often a very time consuming process for a hardware design or verification engineer. We always end up using the waveform viewer which may not be very efficient in giving us a high-level overview of what we’re looking for. Data that is spread across a long simulation cycle is very hard to visualize on the waveform. Whenever I have to analyze a huge chunk of data, I always wonder what would be the best way to do it. It is often cumbersome to go through even a millisecond’s worth of waveform data to analyze the bigger picture. There are of course other tools that can take a VCD file and perform an analysis but that involves buying and learning to use an additional tool.
Sometimes it’s not feasible to invest time and money into new tools. So we always go back to our trusty waveform viewer to make sense of the results. But what if there is a better way of analyzing such data, especially if you are doing some kind of signal processing application and have a lot of data that you would rather view in a format other than the time domain based representation of a waveform? For example, imagine you are trying to visualize the data of an FFT engine. On a waveform, it is next to impossible to visualize this.
In Riviera-PRO we have the Plots feature which can help you. The plot window ties directly to the simulation database, so you don’t have to code anything new or learn a new tool. Just with a few clicks you can add objects to the plot viewer and, based on the settings, it will generate a plot of that object. Sounds very simple but it gives you a bigger picture of what your design object is doing over the course of the entire simulation, rather than just the slice you can see on the waveform between two points of time.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: co-simulation, debugging, DSP, hardware, plots, processing, Riviera-PRO, signal, simulation, verification, waveform
No Comments »
Tuesday, October 17th, 2017
 Creativity and innovation, which lead the society to success, rest on the foundational institutions such as schools and universities. They provide fertile soil to seed, grow and flourish enterprises. To harvest more within an industry, the ecosystem needs to be enriched where the seeds are grown. Considering that the university’s courses are the nutrition to student, they need to be designed in a productive manner as they will provide the next generation of engineers. By providing the necessary platform in addition to the rich and informative tutorials, the quality of the input information for students would be assured. Particularly in the field of Electrical and Computer Engineering, it is important that students get as much hands on experience as possible, and tackle design challenges – such as HW/SW co-design and co-verification – before entering the job market; for their own benefit as well as the industry as a whole.
In this blog, you will become familiar with the TySOM Education kit (TySOM EDU) package designed for the university courses related to hardware design and embedded system design researches.
The TySOM EDU contains a TySOM embedded development board, Riviera-PRO advanced hardware simulator and informative tutorials and reference designs. Although it is possible to choose any development board from the TySOM embedded development board family, the TySOM-1A-7Z010 would be the most cost-effective solution for most university projects.
TySOM-1A-7Z010 (ZynqTM) is a ready-to-use and feature-rich embedded development board which provides the required peripherals to tackle both basic and advanced Zynq-based projects. The XC7Z010 is based on the Xilinx® All Programmable System-on-Chip (SoC) architecture, which integrates a dual-core ARM Cortex-A9 processor with Xilinx 7-series Field Programmable Gate Array (FPGA) logic. Coupling the device to a rich set of peripherals for connectivity, communication and multimedia, makes this board ideal for university projects requiring HW/SW co-design. For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: co-simulation, design, digital, embedded, FPGA, HDL, prototyping, Riviera-PRO, simulation, SoC, university, Xilinx
No Comments »
Friday, August 11th, 2017
 FPGA Design Verification Challenge
The FPGA design and verification “ecosystem” changes rapidly to keep pace with the fast growing size of FPGA devices. The largest Xilinx Virtex UltraSCALE chips provide 4.4 Million logic cells or using another metric 50 million equivalent gate count.
To enable efficient design process for Virtex-7 and newer UltraSCALE FPGAs, Xilinx provides software called Vivado Design Suite. Besides supporting a classical HDL design flow, it also provides system level design tools like IP Integrator, System Generator or even High Level Synthesis, that are very convenient for designing large and complex designs.
Verification has always taken a significant share of the project schedule with HDL simulation being the main stage of that process. With such big designs however, even the fastest simulators would spend hours in simulation tasks.
Simulation Acceleration with HES-DVM™
Aldec’s HES-DVM bridges this gap enabling accelerated simulation with the design running in the FPGA and the testbench in the simulator.
Aldec has been providing HES™ – Hardware Emulation Solutions since 2001. During that time the HES evolved to address the most sophisticated design requirements and fulfill customers’ requirements. Thus, simulation acceleration is only one example of how HES can be used with other applications being hybrid co-emulation, in circuit emulation, and physical prototyping.
With simulation acceleration the user can move any synthesizable module from simulator to the FPGA thus offload some processing from the HDL simulator. Typically, an entire design is implemented in HES board and the simulator only executes the testbench.
Figure 1: Signal-level simulation acceleration
The HES boards are seamlessly integrated with the simulator with PCI Express x8 physical connection to the host workstation. The HES-DVM provides co-simulation interfaces for Aldec’s Riviera-PRO and Active-HDL simulators but also for other 3rd party simulators. It can be used both in Linux and Windows operating systems with all required PCIe drivers and interfaces working out of the box.
The DVM tool automates the process of design compilation and implementation for HES boards. It generates all necessary scripts and configuration files to run simulation acceleration in a given HES board but also brings many useful debugging features. Despite running your design in FPGA hardware you can keep simulation level visibility with an RTL View of all internal probes.
Figure 2: Design setup flow for acceleration using DVM™
Acceleration Benchmark
MIG controller for DDR3, AXI interconnect, two AXI traffic generators and one AXI protocol checker as shown in the following diagram.How much acceleration can I achieve? This is always the first customer’s question and frankly there is no straight answer because the result depends on the complexity of both the design and the testbench. Usually a good estimation can be obtained from running simulation profiling and then applying Amdahl’s rule. However, the best way to verify acceleration potential is just to experiment with a typical design, so we have created a simple design of a memory sub-system using Xilinx Vivado Design environment. It contains MIG controller for DDR3, AXI interconnect, two AXI traffic generators and one AXI protocol checker as shown in the following diagram.
Figure 3: Diagram created for memory subsystem benchmarking
Benchmark Results
Workstation and software used for benchmarking:
Workstation:
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
RAM: 32 GB
HES Board: HES7XV4000BP_REV2, contains 2x Virtex7 2000 FPGA
Software:
OS: Linux CentOS 6, x86_64
Simulator: Riviera-PRO 2017.02
Design env: Vivado 2016.4
Acceleration env: HES-DVM 2017.02
If you are interested in further details about this project, benchmark, and tools which can significantly accelerate your simulation you can view the following application note: https://www.aldec.com/en/support/resources/documentation/articles/1915
Tags: acceleration, co-simulation, FPGA, HES-DVM, simulation, SoC and ASIC Prototyping, verification, Xilinx
No Comments »
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?
(more…)
Tags: Active-HDL, ARM, asic, co-simulation, design, FPGA, fpga prototyping solution, hardware, prototyping, SoC, SoC and ASIC Prototyping, soc design, Xilinx
No Comments »
Monday, November 25th, 2013
 COMRATE™, the co-simulation solution developed by Aldec and Agilent is a lot like “couples-therapy” that can help get your digital blocks talking to the rest of your model-based design.
To illustrate, let’s take a look at a very basic model-level design and think about it from design-under-test perspective (i.e., what are the challenges associated with verifying this DUT):
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: agilent, Aldec, co-simulation, co-simulation flow, co-simulation solution, comrate, debugging, digital blocks, hdl models, mixed-signal, model-based design, multirate design, Riviera-PRO, system-level environment, system-level simulation, systemvue, verification, verification of multirate systems with multiple digital blocks
No Comments »
Wednesday, November 6th, 2013
 The recent ARM® TechCon Conference in Santa Clara was definitely the front-runner of my favorite conferences that I attended this year. Fun, informative and filled with software engineers, physical designers, design verification teams, and hardware engineers – ARM TechCon was the place to be to learn about the latest innovations from the embedded industry. Aldec was there showcasing our HES-DVM™ and HES-7™ platforms, which enable engineers to utilize emulation and FPGA-based prototyping to verify the latest ARM designs.
(more…)
Tags: Aldec, ARM, arm processors, arm techcon conference, arm-based processors, co-simulation, dual-core arm cortex-A9 processors, Emulation, hes-7 platforms, hes-7 soc db, HES-DVM, hw/sw verification platform, ICE, In-circuit emulation, prototyping, rtl simulation, SoC, SoC and ASIC Prototyping, Xilinx, xilinx zynq soc
No Comments »
Wednesday, September 18th, 2013
 Today’s System-on-Chip verification teams are moving up in the levels of abstraction to increase the degree of coverage in the system design. As designs grow larger, we start to see an increase in test time within our HDL simulations. Engineers can utilize Hardware-Assisted approaches such as simulation acceleration, transaction-level co-emulation, and prototyping to combat the growing simulation times of an RTL simulator. In this article, we’ll dive much deeper into the transaction-level co-emulation methodology.
(more…)
Tags: accelera, Aldec, co-simulation, dpi, Emulation, FPGA, function-based, hardware, hardware emulation platform, hardware-assisted verification method, hardware-assisted verification solution, hdl simulations, high-level testbenches, macro-based, pipes-based, prototyping, rtl simulator, sce-mi, simulation acceleration, SoC, SoC and ASIC Prototyping, soc designs, standard for co-emulation modeling interface, system-on-chip verification, systemverilog direct programming interface, systemverilog lrm, transaction-level co-emulation, transaction-level co-emulation methodology, Validation, verification
No Comments »
|
In this blog, I am going to discuss different phases that UVM follows.
