Posts Tagged ‘FPGA’
Friday, March 12th, 2021
 While immunization vaccines are rolling out at an impressive pace, and as society slowly reopens, our best defense against the Coronavirus continues to be early detection and rapid response (such as self-isolation).
An early symptom of having the virus is an increased body temperature, which can be easily measured using contactless methods such as thermal sensors or cameras sensitive to IR radiation.
However, general purpose cameras still have a role to play – in augmenting and putting into better context the thermal data.
Imagine two cameras – one IR and one standard – observing the entrance to a place of work or indoor public venue. If the image captured by the standard camera feeds a system with face detection software, then the thermal image can be made more meaningful: yes, that heat source is a human face.
(more…)
Tags: AI, Computer Vision, COVID-19, embedded, FPGA, Gstreamer, IR, Linux, MPSoC, Zynq
No Comments »
Tuesday, August 11th, 2020
 In the early days of digital design, all circuits were designed manually. You would draw K-map, optimize the logic and draw the schematics. If you remember, we all did many logic optimization exercises back in college. It was time consuming and very error prone. This works fine for designs with a few hundred gates, but as the designs get larger and larger this became non-feasible.
Designs that are described at a higher level of abstraction are less prone to human errors. High-level descriptions of designs are done without significant concern regarding design constraints. The conversion from high-level descriptions to gates is done by using synthesis tools. These tools use various algorithms to optimize the design as a whole. This circumvents the problem with different designer styles for the different blocks in the design and sub-optimal design practices. Logic synthesis tools also allows for technology independent designs. Logic synthesis technology was commercialized around 2004, and since then it’s been part of the standard EDA tool chain for ASICs and FPGAs.
(more…)
Tags: acceleration, Active-HDL, design, embedded, Emulation, FPGA, FPGA Simulation, HDL, HES-DVM, Intel, Synthesis, systemverilog, verilog, Xilinx
No Comments »
Monday, May 4th, 2020
 These days verification teams no longer question whether hardware assisted verification should be used in their projects. Rather, they ask at which stage they should start using it.
Contemporary System-on-Chip (SoC) designs are already sufficiently complex to make HDL simulation a bottleneck during verification, without even mentioning hardware-software co-verification or firmware and software testing. Thus, IC design emulation is an increasingly popular technique of verification with hardware-in-the-loop.
Recently, hardware assisted verification became much more affordable thanks to the availability of high capacity FPGAs (like Xilinx Virtex UltraScale US440) and their adoption for emulation by EDA vendors.
A good example of such an emulation platform is Aldec’s HES-DVM. It can accommodate designs over 300 Million ASIC gates on multi-FPGA boards (HES-US-1320), where the capacity scales by interconnecting multiple boards in a backplane.
(more…)
Tags: ARM, asic, embedded, Emulation, FPGA, HES-DVM, simulation, SoC, verification
No Comments »
Wednesday, February 19th, 2020
Have you ever worked on a group project where you had to combine your work with that of a colleague of a different engineering discipline but the absence of an efficient means of doing so affected the project’s overall outcome? Well, for software and hardware engineers developing an SoC, the merging of their respective engineering efforts for verification purposes is a big challenge.
Early access to hardware-software co-verification allows hardware and software teams to work concurrently and set the foundation to a successful SoC project. However, many co-emulation methodologies are based on processor virtual models which are not accurate representations of the design. Fortunately, Aldec has a solution that integrates an ARM-based SoC from Xilinx, specifically a Zynq UltraScale+ MPSoC, with the largest Xilinx UltraScale FPGA. Since the Zynq device includes the hard IP of the ARM processor, our solution provides an accurate representation of the ARM-based SoC design for co-verification.
(more…)
Tags: ARM, asic, embedded, Emulation, FPGA, HES-DVM, SoC, SoC and ASIC Prototyping, Validation, verification, Zynq
No Comments »
Thursday, December 12th, 2019
Understandably, hardware designed for an aircraft, or indeed any safety critical application, must be robust. I also believe that all engineers wish to verify their designs as thoroughly as possible, anyway. However, there are limiting factors; most notably the high complexity of most designs. Since we are unable to discover and verify the design against all abnormal conditions, the main question is: when is robustness verification truly complete?
Random nature of robustness
Test scenarios for robustness verification always contain many input stability issues, such as erroneous values, lack or loss of value, unexpected timing and unpredicted toggling. Certainly there is a significant random factor but it should not lead us to oversimplify this part of verification by applying less or more advanced randomization methods only. The robustness of any design, and especially for projects where human lives are potentially at risk, cannot be achieved by inspecting the results of randomly generated scenarios. It must be part of the original design.
RTCA/DO-254
The “Design Assurance Guidance for Airborne Electronic Hardware” document does not explicitly address robustness testing. However, two supplements – “FAA Order 8110.105A” and the “EASA Certification Memorandum” – clarify that to demonstrate robustness, the applicant should also define the requirements-based testing. In other words, it is expected that abnormal operating conditions be captured and documented as derived requirements.
How many “robustness requirements” do we need?
Having extra requirements for robustness verification does not solve the problem stated above, so the question really is: how many “robustness requirements” will be enough?
(more…)
Tags: FPGA, safety-critical, verification
No Comments »
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 »
Wednesday, February 28th, 2018
When should we use the term “Vision for Everything”, as vision-based applications are entering various industries? It’s been a few years since the emergence of Embedded Vision and we see that it’s being used in a wide range of applications including Security, Medical, Smart homes, Robotics, Transportations, Automotive Driver Assistance Systems (ADAS) and Augmented Reality (AR).
This is the first in a series of blogs explaining what you need to know to start designing Embedded Vision applications which can be used in ADAS, from choosing the right device and tools to demystifying the vision algorithms used in automotive applications and how to implement them into FPGAs.
ADAS consists of two main parts, vision and sensor fusion. Cameras used in a smart car can provide the information such as object detection, classification and tracking. However, they don’t provide the distance between the vehicle and obstacles needed to prevent a collision. To do that, sensors such as LIDAR or RADAR come to play.
In this series of blogs, we will mainly focus on the vision side of the ADAS; but will cover sensor fusion in the future. The main goal of this series of blogs is to give an in-depth knowledge of Aldec’s complete ADAS reference design which includes 360-Degree Surrounding View, Driver Drowsiness Detection and Smart-Rear View.
(more…)
Tags: acceleration, ARM, embedded, FPGA, hardware, verilog, VHDL, Xilinx
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 »
Thursday, January 25th, 2018
 A high-performance router is an absolute must if you want to run a high-traffic network in which different devices need to transfer and receive data as fast as possible. A router with a powerful processor and sufficient local memory reduces data hiccups and minimizes message loading and buffering times. But is that enough?
Because of the huge amount of data that people now generate – combined with the wealth of communication protocols, such as Wi-Fi, Ethernet, USB, SFP, QSFP – high-performance, hardware re-programmable routers are becoming popular. That hardware re-programmability is being delivered through FPGAs, and utilizing one as the main ‘processor’ on the router makes it easy to add or modify desired modules such as encryption and compression.
(more…)
Tags: acceleration, design, digital, embedded, Emulation, FPGA, hardware, industrial, prototyping, SoC, SoC and ASIC Prototyping, Xilinx
No Comments »
Monday, December 11th, 2017
Modern ASIC and SoC designs have increased in complexity such that multiple FPGAs of the largest capacity are now required to prototype the entire functionality of the design. As design sizes increase, more and more FPGAs are required. The capacity and pin limitations of FPGAs create constraints for how the ASIC/SoC design can be mapped into the FPGAs. Aldec’s HES-DVM’s prototyping mode accounts for the limitations of the target FPGAs and allows the user to map a design to the FPGAs within these constraints.
Partitioning a design to fit into multiple FPGAs can be a lot of work
Designing the partitions with HES-DVM is as easy as selecting specific VHDL/SystemVerilog design modules from the hierarchy and moving them to a desired partition. All information about the design modules and the amount of LUTs, Flip-flops, memory blocks, DSP slices, and I/O consumed are displayed for convenience. These values can also be viewed as a percentage of the target FPGAs’ available resources allowing you to know when an FPGA is full.
Adding a module to a partition
Mapping a partition to an FPGA
Once the partitions are finalized, each partition can be assigned to a specific FPGA. A design successfully fitting into the FPGAs on the target prototyping board is only the beginning. There still remains a big problem with the sheer number of connections between the partitions. Modern designs have thousands of internal signals interconnecting major blocks or sub-systems. It’s likely that there won’t be a sufficient amount of direct connections between FPGAs to support the design’s internal wiring. How can the large amount of internal design signals possibly be accommodated by the relatively smaller amount of I/O available from the FPGAs?
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: asic, FPGA, HES-7, HES-DVM, prototyping, SoC, SoC and ASIC Prototyping
No Comments »
|
While immunization vaccines are rolling out at an impressive pace, and as society slowly reopens, our best defense against the Coronavirus continues to be early detection and rapid response (such as self-isolation).
