Open side-bar Menu
 Aldec Design and Verification

Posts Tagged ‘Aldec’

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.

Effective Communication is Key in Relationships… and ESL Design!

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.


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.

Biggest Hits and Trends from ARM TechCon

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.


Integrating SystemVerilog and SCE-MI for Faster Emulation Speed

Wednesday, October 9th, 2013

In the last SCE-MI article, we discussed how SCE-MI macro-based infrastructures can speedup SoC design verification time. In SCE-MI 2.1, Accelera introduced a ‘function-based’ infrastructure which is based on SystemVerilog DPI functionality. The SystemVerilog DPI is an interface which can be used to connect SystemVerilog files with foreign languages (C, C++, SystemC, etc).


Why Randomize?

Tuesday, September 24th, 2013

Jim Lewis, VHDL Training Expert at SynthWorks (and founding member of OSVVM, which Aldec was an early adopter of) was kind enough to author a guest blog for Aldec. Here’s an excerpt:

After presenting a conference paper on how to do OSVVM-style constrained random and intelligent coverage (randomization based on functional coverage holes), I received  a great question, “Why Randomize?”

The easiest way to answer this is with an example.  Let’s look at a FIFO test – test a FIFO, write to it, read from it, write to it and read from it simultaneously, fill it and see that additional writes are held off successfully, and empty it and see that additional reads are held off successfully. 

Most certainly a FIFO can be tested using a directed test (just code, no randomization).  The following simulation waveform shows diffcount (the number of words in the FIFO) for a directed test.   The lowest value is empty.  The highest is full.  Using this, you can visually check off all of the required conditions and see that the FIFO is indeed tested.

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.


SCE-MI for SoC Verification

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.


Verilog-AMS & Multi-Level Simulation

Monday, September 16th, 2013

It occurred to me that it has been a few months since we shared an update on HiPer Simulation A/MS. Following DAC 2013 and Daniel Payne’s posts at SemiWiki (post 1, post 2), we at Aldec and Tanner EDA have received many inquiries from the field, conducted a number of evaluations, and deployed our analog/mixed-signal (AMS) design flow with our first mutual customers. In this article, I’ll share more the mixed-signal simulation methodology and highlight some of Verilog-AMS use cases that we have seen in the field.

Digital & Analog HDLs

The Verilog and VHDL languages were designed to handle discrete signals, where the number of possible signal values is limited (e.g. 1, 0, X, Z). Whereas Verilog-A was designed to handle continuous-time (analog) signals, that can take any value from a continuous range at any point.

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

The WHAT is mandatory but the HOW is entirely optional

Monday, September 9th, 2013

You look confused. Perhaps I owe you an explanation. Anyone familiar with hardware design flow knows that it starts with specification and ends with implementation. The specification in this flow is the “What” – it defines what needs to be designed. The process for implementation is the “How” – it defines how you are going to achieve it.

Let’s break down just one part of the “How” or implementation – the Design Process. For many years hand-coded RTL has been used as the de facto method for implementation and it is still being used as predominant method for designing cutting-edge hardware. But does it follow that it is the most efficient method? I would say probably not, especially given the ever-growing complexity of the hardware.

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

S2C: FPGA Base prototyping- Download white paper

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