Part of the  

Chip Design Magazine


About  |  Contact

Posts Tagged ‘AMBA’

IoT Cookbook: Analog and Digital Fusion Bus Recipe

Tuesday, December 2nd, 2014

Experts from ARM, Mathworks, Cadence, Synopsys, Analog Devices, Atrenta, Hillcrest Labs and STMicroelectronics cook up ways to integrate analog with IoT buses.

By John Blyler, Editorial Director

Many embedded engineers approach the development of Internet-of-Things (IoT) devices like a cookbook. By following previous embedded recipes, they hope to create new and deliciously innovative applications. While the recipes may be similar, today’s IoT uses strong concentration of analog, sensors and wireless ingredients. How will these parts combine with the available high-end bus structures like ARM’s AMBA? To find out, “IoT Embedded Systems” talked with the head technical cooks including Paul Williamson, Senior Marketing Manager, ARM; Rob O’Reilly, Senior Member Technical Staff at Analog Devices; Mladen Nizic , Engineering Director, Mixed Signal Solution, Cadence; Ron Lowman, Strategic Marketing Manager for IoT, Synopsys; Corey Mathis, Industry Marketing Manager -  Communications, Electronics and Semiconductors, MathWorks; Daniel Chaitow, Marketing Manager, Hillcrest Labs; Bernard Murphy, CTO, Atrenta; and Sean Newton, Field Applications Engineering Manager, STMicroelectronics. What follows is a portion of their responses. — JB

Key points:

  • System-level design is needed so that the bus interface can control the analog peripheral through a variety of modes and power-efficient scenarios.
  • One industry challenge is to sort the various sensor data streams in sequence, in types, and include the ability to do sample or rate conversion.
  • To ensure the correct sampling of analog sensor signals and the proper timing of all control and data signals, cycle accurate simulations must be performed.
  • Control system and sensor subsystems are needed to help reduce digital bus cycles by tightly integrating the necessary components.
  • Hardware design and software design have inherently different workflows, and as a result, use different design tools and methodologies.
  • For low-power IoT sensors, the analog-digital converter (ADC) power supply must be designed to minimize noise. Attention must also be paid to the routing of analog signals between the sensors and the ADC.
  • Beyond basic sensor interfacing, designer should consider digitally assisted analog (DAA) – or digital logic embedded in analog circuitry that functions as a digital signal processor.

Blyler: What challenges do designers face when integrating analog sensor and wireless IP with digital buses like ARM’s AMBA and others?

Williamson (ARM): Designers need to consider system-level performance when designing the interface between the processor core and the analog peripherals. For example a sensor peripheral might be running continuously, providing data to the CPU only when event thresholds are reached. Alternatively the analog sensor may be passing bursts of sampled data to the CPU for processing.  These different scenarios may require that the designer develop a digital interface that offers simple register control, or more advanced memory access. The design of the interface needs to enable control of the peripheral through a broad range of modes and in a manner that optimizes power efficiency at a system and application level.

O’Reilly (Analog Devices): One challenge is ultra-low power designs to enable management of the overall system power consumption. In IoT systems, typically there is one main SoC connected with multiple sensors running at different Output Data Rates (ODR) using asynchronous clocking. The application processor SoC collects the data from multiple sensors and completes the processing. To keep power consumption low, the SoC generally isn’t active all of the time. The SoC will collect data at certain intervals. To support the needs of sensor fusion it’s necessary that the sensor data includes time information. This highlights the second challenge, the ability to align a variety of different data types in a time sequence required for fusion processing. This raises the question “How can an entire industry adequately sort the various sensor data streams in sequence, in types, and include the ability to do sample or rate conversion.?”

Nizic (Cadence): Typically a sensor will generate a small (low voltage/current) analog signal which needs to be properly conditioned and amplified before converting it to digital signal sent over a bus to memory register for further processing by a DSP or a controller. Sometimes, to save area, multiple sensor signals are multiplexed (sampled) to reduce the number of A2D converters.

From the design methodology aspect, the biggest design challenge is verification. To ensure analog sensor signals are sampled correctly and all control and data signals are timed properly, cycle-accurate simulations must be performed. Since these systems now contain analog, in addition to digital and bus protocol verification, a mixed-signal simulation must cover both hardware and software. To effectively apply mixed-signal simulation, designers must model and abstract behavior of sensors, analog multiplexers, A2D converters and other analog components. On the physical implementation side, busses will require increased routing resources, which in turn mean more careful floor-planning and routing of bus and analog signals to keep chip area at minimum and avoid signal interference.

Lowman (Synopsys): For an IC designer, the digital bus provides a very easy way to snap together an IC by hanging interface controllers such as I2C, SPI, and UARTs to connect to sensors and wireless controllers.  It’s also an easy method to hang USB and Ethernet, as well as analog interfaces, memories and processing engines.  However, things are a bit more complicated on the system level. For example, the sensor in a control system helps some actuator know what to do and when to do it.  The challenge is that there is a delay in bus cycles from sensing to calculating a response to actually delivering a response that ultimately optimizes the control and efficiency of the system.  Examples include motor control, vision systems and power conversion applications. Ideally, you’d want a sensor and control subsystem that has optimized 9D Sensor Fusion application. This subsystem significantly reduces cycles spent traveling over a digital bus by essentially removing the bus and tightly integrating the necessary components needed to sense and process the algorithms. This technique will be critical to reducing power and increasing performance of IoT control systems and sensor applications in a deeply embedded world.

Mathis (Mathworks): It is no surprise that mathematical and signal processing algorithms of increasing complexity are driving many of the innovations in embedded IoT. This trend is partly enabled by the increasing capability of SoC hardware being deployed for the IoT. These SoCs provide embedded engineers greater flexibility regarding where the algorithms get implemented. The greater flexibility, however, leads to new questions in early stage design exploration. Where should the (analog and mixed) signal processing of that data occur? Should it occur in a hardware implementation, which is natively faster but more costly in on-chip resources? Or in software, where inherent latency issues may exist? One key challenge we see is that hardware design and software design have inherently different workflows, and as a result, use different design tools and methodologies. This means SoC architects need to be fluent in both C and HDL, and the hardware/software co-design environments needed for both. Another key challenge is that this integration further exacerbates the functional, gate- or circuit-level, and final sign-off verification problems that have dogged designers for decades. Interestingly, designers facing either or both of these key challenges could benefit significantly from top-down design and verification methodologies. (See last month’s discussion, “Is Hardware Really That Much Different From Software?”)

Chaitow (Hillcrest Labs): In most sensor-based applications, data is ultimately processed in the digital realm so an analog to digital conversion has to occur somewhere in the system before the processing occurs. MEMS sensors measure tiny variations in capacitance, and amplification of that signal is necessary to allow sufficient swing in the signal to ensure a reasonable resolution. Typically the analog to digital conversion is performed at the sensor to allow for reduction of error in the measurement. Errors are generally present because of the presence of noise in the system, but the design of the sensing element and amplifiers have attributes that contribute to error. For a given sensing system minimizing the noise is therefore paramount. The power supply of the ADC needs to be carefully designed to minimize noise and the routing of analog signals between the sensors and the ADC requires careful layout. If the ADC is part of an MCU, then the power regulation of the ADC and the isolation of the analog front end from the digital side of the system is vital to ensure an effective sampling system.

As always with design there are many tradeoffs. A given analog MEMS supplier may be able to provide a superior measurement system to a MEMS supplier that provides a digital output. By accepting the additional complexity of the mixed-signal system and combining the analog sensor with a capable ADC, an improved measurement system can be built. In addition if the application requires multiple sensors, using a single external multiple channel ADC with analog sensors can yield a less expensive system, which will be increasingly important as the IoT revolution continues.

Murphy (Atrenta): Aside from the software needs, there are design and integration considerations. On the design side, there is nothing very odd. The sensor needs to be presented to an AMBA fabric as a slave of some variety (eg APB or AHB), which means it needs all the digital logic to act as a well-behaved slave (see Figure). It should recognize it is not guaranteed to be serviced on demand and therefore should support internal buffering (streaming buffer if an output device for audio, video or other real-time signal). Sensors can be power-hungry so they should support power down that can be signaled by the bus (as requested by software).

The implementation side is definitely more interesting. All of that logic is generally bundled with the analog circuitry into one AMS block and it is usually difficult to pin down a floor-plan outline on such a block until quite close to final layout. This makes full-chip floor planning more challenging because you are connecting to an AMBA switch fabric, which likes to connect to well-constrained interfaces because the switch matrix itself doesn’t constrain layout well on its own. This may lead to a little more iteration of the floor plan than you otherwise might expect

Beyond basic sensor interfacing, you need to consider digitally assisted analog (DAA). This is when you have digital logic embedded in analog circuitry, functioning as a digital signal processor to perform effectively an analog function but perhaps more flexibly and certainly with more programmability that analog circuitry. Typical applications are for beamforming in radio transmission and for super-accurate ADCs.

Figure: The AMBA Bus SOC Platform is a configurable with several peripherals and system functions, e.g., AHB Bus(es), APB Bus(es), arbiters, decoders. Popular peripherals include RAM controllers, Ethernet, PCI, USB, 1394a, UARTs, PWMs, PIOs. (Courtesy of ARM Community -

Newton (STMicroelectronics): Integration of devices such as analog sensors and wireless IP (radios) is widespread today via the use of standard digital bus interfaces such as I2C and SPI. Integration of analog IP with a bus – such as ARM’s AMBA – becomes a matter of connecting the relevant buses to the digital registers contained within the IP. This is exactly what happens when you use I2C or SPI to communicate to standalone sensors or wireless radio, with the low-speed bus interfaces giving external access to the internal registers of the analog IP. The challenges for integration to devices with higher-end busses isn’t so much on the bus interface, as it is in defining and qualifying the resulting SoC. In particular, packaging characteristics, the number of GPIO’s available, the size of package, the type of processing device used (MPU or MCU), internal memory capability such as flash or internal SRAM, and of course the power capabilities of the device in question: does it need very low standby power? Wake capability?  Most of these questions are driven by market requirements and capabilities and must be weighed against the cost and complexity of the integration effort.

The challenges for integration to devices with higher-end busses isn’t so much on the bus interface, as it is in defining packaging characteristics, available GPIOs, type of processing device, memory such as flash or internal SRAM, and power capabilities.

Blyler: Thank you.

This article was sponsored by ARM.

ARM and Cortex are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. mbed is a trademark of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved.

Silvaco – SOC Soln’s Acquisition Reflect Systems Trend in IP

Thursday, August 31st, 2017

With completion of the Silvaco acquisition of SOC Solutions, Electronic System Design sat down with the principals from each company to talk about the future.

By John Blyler, Editor-in-Chief

Quotable Quotes:

… to combine our (processor) subsystems with CAN-FD and FlexRay to service the automotive market.

… our IP Fingerprinting … targeted towards … concerns about (compliance).

… this will eventually lead to the “Arduino” type solutions that will fuel the IoT industry and others.

… We may be on the forefront of the next evolution of deliverables that will be expected with IP.

To grow, traditional EDA tools and IP suppliers must embrace the larger electronic systems market. This is nothing new to Jim Bruister, CEO at SOC Solutions (now part of Silvaco). He has frequently commented on the need to adapt the semiconductor IP industry to ensure it will be successful in the larger IOT system and embedded spaces. (See, “How can the Chip Community Improve the Industry for IOT Designers?)

Embracing the larger system perspective is just one of the reasons why the Silvaco acquisition of SOC Solutions is important. To understand why, JB Systems talked with Warren Savage, General Manager of IP at Silvaco, and Jim Bruister, CEO of SoC Solutions. What follows is a slightly edited version of their responses. – JB

Silvaco and SOC Solutions Acquisition

Warren Savage, General Manager of IP, Dave Dutton, CEO of Silvaco Inc, and Jim Bruister, CEO of SoC Solutions, sign the acquisition agreement. (Courtesy of Silvaco)

Blyler: How will SOC Solutions complement Silvaco in the IP space?

Bruister: One way is with a lot of IP, especially for AMBA infrastructure.  We’ve been providing ARM Cortex-M0/M3/A5 AHB and AXI subsystems for many years – both off-the-shelf and customized subsystems. Many IP engagements now require a system level hardware-software approach from the IP supplier and the IP user alike, which we provide.

Additionally, we (SOC Solutions) bring several popular cores to Silvaco, e.g., QSPI, Serial Flash Controllers, AES encryption/decryption, DMA controllers, I2C, SPI, SPI bridges, LCD controllers and more.

Savage:  Systems level thinking has become a big factor in the IP world. SoC Solution’s infrastructure IP plus their knowledge of how to put together both hardware and software subsystems fits very well into what customers want. A minimal overlap of products between the two companies also helps.

Blyler: What markets will be opened up?

Bruister: The combination of existing products from both companies will open up markets in automotive, industrial, IoT and perhaps medical industries.  For example, we intend to combine our Cortex-M0/M3 (or other CPUs such as ColdFire) subsystem with CAN-FD and FlexRay to service the automotive market with an automotive platform. Similarly, we will provide a sensor platform that contains a M0/M3/Coldfire subsystem with Silvaco’s I3C core to service the smart sensor market.

Savage: I don’t know about “opening up” markets, but there is a natural shift in the IP industry to align specific products and services that help customers in vertical markets. However, I will say that in the previous IPextreme/Silvaco IP world, we didn’t have the expertise to provide serious consulting and custom products like we have with SoC Solutions. Instead of turning away that business, we can offer something now to customers that need it.

Blyler: In past articles, Jim Bruister has said that IOT chip design must be done differently in the future. Will this acquisition help in that effort?

Bruister: I believe so.  Silvaco has historically been an EDA company with many physical design and analysis tools-libraries. That will be combined with our (SOC Solution) IP and product base to provide a “one-stop-shop” whole chip solution. The best example of this is how we support today’s “Smart Designs” in which more and more digital CPU based systems are added to custom analog to produce smart-sensors, smart-rf, and smart-IoT devices.

Savage: Jim is right: A large amount of the Silvaco customer base is BigA – SmallD, which is in contrast to the IPextreme/SoC customer base.  We are seeing the opportunity now with IOT customers to outsource the entire digital portion of the chip, rather than investing in a new digital team, tools, etc.

Blyler: Security has become a critical element in IP reuse. Will the acquisition help protect IP?

Warren: SoC Solutions was already a supporter of our IP Fingerprinting technology which is more targeted towards companies that have weak internal controls and are concerned about the liability associated with being out of compliance. It really doesn’t protect against people that want to steal your IP.

Blyler: What will the future bring?

Bruister: Already we are beginning to see the fruits of the acquisition.  The SoC Solutions’ IP and team brings the critical mass needed to bring Silvaco’s IP strategy to life.  But it’s just the beginning.  Silvaco plans to expand the IP and Services team to bring world-class IP and services to the industry.  My vision is this will eventually lead to the “Arduino” type solutions that will fuel the IoT industry and others.

Savage: Yes, that’s a good point that Jim brings up.  We may be on the forefront of the next evolution of deliverables that will be expected with IP. Such a deliverable package would include compliance setups, test boards, drivers, middle-ware, and more.   We have definitely seen this taking place last year with our I3C product, which keeps pushing the boundaries of traditional deliverables.

Blyler: Thank you.

New ARM IP Tooling Suite Reduces Significantly SoC Integration Time

Thursday, June 4th, 2015

Gabe Moretti, Senior Editor

IP should be easy to integrate into a design and thus require a reasonably short amount of time.  But when sophisticated IP must be integrated into large and complex designs, the task is often complicated.  Requiring above average knowledge in exchange for leading edge results would seem a fair exchange.  But in general customers do not see it that way.

ARM, the leading provider of highly sophisticated system IP, from CPUs to busses and anything digital in between, found that its customers were often challenged by the integration task.  The release of an integrated family of tools is addressing the issue and seems to effectively reduce integration time from months to days.

The new IP tooling suite comprises Socrates DE, CoreSight Creator and CoreLink Creator. Additionally, CoreLink Creator will easily configure and help implement the new CoreLink NIC-450 Network Interconnect, the follow-on to the widely-adopted CoreLink NIC-400.

Socrates DE and CoreSight Creator are available now for immediate licensing. CoreLink Creator and CoreLink NIC-450 will be available for delivery in 2H’15. Find out more by visiting ARM booth #2414 at the upcoming DAC show, June 7-11 at the Moscone Center in San Francisco.

How the SCC Suite Works

The new suite addresses the most complex challenges associated with SoC configurability and assembly while reducing time to market. Examples of efficiency gains include:

  • An 8x improvement in assembly schedule – based on project metrics from an ARM project to build a 64-bit ARM big.LITTLE reference platform
  • Configuration of an ARM Cortex-A72 processor in seconds
  • Effortless management of 100,000+ lines of connection metadata per IP.

“Our partners need to deliver ARM-based SoCs to market as fast and accurately as possible,” said James McNiven, general manager, systems and software group, ARM. “In the process of building our own reference designs, we saw our IP configuration, creation and assembly schedules go from projections of months to days thanks to Socrates DE and the CoreSight and CoreLink Creators. Our lead partners are now using ARM IP tooling in concert with ARM and third-party IP to assemble intelligent subsystems faster than ever.”

Simplifying the SoC development process

Socrates DE delivers ARM’s most advanced IP design environment to date, offering configuration, creation and assembly of ARM and third-party IP. Socrates DE equips architects and designers with a wide range of capabilities:

  • The same design environment used within ARM
  • Built-in ARM design knowledge such as ARM AMBA protocols
  • A platform to standardize any IP into the industry-standard IP-XACT format
  • A built-in IP catalog supporting ARM and third-party IP
  • The ability to differentiate on top of ARM IP while maintaining design integrity.

Accelerating system IP design

CoreSight and CoreLink Creators, which are built on Socrates technology, further enable architects and designers with several configuration efficiencies:

  • The same IP creation environment used within ARM
  • Built-in ARM design rule checks
  • Guided creation of a high-level specification for Coresight or Corelink IP
  • Automated microarchitecture creation
  • Auto-generated right-first-time RTL and IP-XACT
  • Seamless integration with Socrates DE.

On-chip communication leadership

The new CoreLink NIC-450 Network Interconnect offers a tool-driven automation flow that employs algorithms for tasks such as ensuring deadlock-free operation and partitioning across multiple power/voltage domains. The highly configurable, multi-power-domain CoreLink NIC-450 is most easily configured and deployed via the CoreLink Creator tool. The CoreLink Creator tool enables CoreLink NIC-450 to be optimized to suit the requirements of a complex SoC using AMBA protocols, the industry’s de facto standard for on-chip communication.

Network on Chip Solution Is Gaining Market Shares

Thursday, November 14th, 2013

by Gabe Moretti, Contributing Editor

It is important to notice how much network on chip (NoC) architectures have established themselves as the preferred method of connectivity among IP blocks.  What I found lacking are tools and methods that help architects explore the chip topology in order to minimize the use of interconnect structures and to evaluate bus versus network tradeoffs.


Of course there are busses for SoC designs, most of which have been used in designs for years.  The most popular one is the AMBA bus first introduced in 1996.  Up to today there are five versions of the AMBA bus.  The last one introduced this year is the AMBA 5 CHI (Coherent Hub Interface) that offers a new high-speed transport layer and features aimed at reducing congestion.

Accellera offers the OCP bus developed by OCP-IP before it merged with Accellera.  It is an openly licensed protocol that allows the definition of cores ready for system integration that can be reused together with their respective test benches without rework.

The OpenCores open source hardware community offers the Wishbone bus.  I found it very difficult to find much information about Wishbone on the website, with the exception of three references to implementations using this protocol.  Wishbone is not a complete bus definition, since it has no physical definitions.  It is a logic protocol described in terms of signals and their states and clock cycles.

Other bus definitions are proprietary.  Among them designers can find Quick Path from Intel, Hyper Transport from AMD, and IPBus from IDT.

IBM has defined and supports the Core Connect bus that is used in its Power Architecture products and is also used with Xilinx’s MicroBlaze cores.

Finally Altera uses its own Avalon bus for its Nios II products line.

Clearly the use of busses is still quite pervasive.  With the exception of proprietary busses, designers have the ability to choose both physical and protocol characteristics that are best suited for their design.

Network on Chip

There are two major vendors of NoC solutions: Arteris and Sonics.  Arteris is a ten year old company headquartered in Sunnyvale but with engineering center near Paris, France.  its technology is derived from the computer networking solutions that are modified to the requirements of SoC realizations.  Its products deal both with on-chip as well as with die-to-die and multi-chip connectivity.

Sonics was founded in 1996.  In addition to network on chip products it also offers memory subsystems, and tools for performance analysis and development tools for SoC realizations.  It offers six products in the NoC market covering many degrees of sophistication depending on designers’ requirements.  SonicsGN is its most sophisticated product.  It offers a high-performance network for the transportation of packetized data, utilizing routers as the fundamental switching elements.  On the other hand SonicsExpress can be used as a bridge between two clock domains with optional voltage domain isolation.  It supports AXI and OCP protocols and thus can be integrated in those bus environments.

After the panel discussion on IP Blocks Connectivity that covers mostly NoC topics, I spoke with Avi Behar, Product Marketing Director at Cadence.  Cadence had wanted to participate to the discussion but their request had come too late to include them in the panel.  But, information is important, and scheduling matters should not become an obstacle.  So I decided to publish their contribution in this article.

The first question I asked was: on chip connectivity uses area and power and also generates noise.  Have we addressed these issues sufficiently?

Avi:A common tendency among on-chip network designer is to over design. While it’s better to be on the safe side – under–designing will lead to the starvation of bandwidth hungry IPs and failure of latency critical IPs – over–designing has a cost in gate count and as a result in power consumption. In order to make the right design decisions, it is crucial that design engineer run cycle-accurate performance analysis simulations (by performance I primarily mean data bandwidth and transaction latency) with various configurations applied to their network. By changing settings like outstanding transactions, buffer depth, bus width, QoS settings and the switching architecture of the network and running the same, realistic traffic scenarios, designers can get to the configuration that would meet the performance requirements defined by the architects without resorting to over-design. This iterative process is time consuming and error prone, and this is where the just launched Cadence Interconnect Workbench (IWB) steps in. By combining the ability to generate a correct-by-construction test bench tuned for performance benchmarking (the RTL for the network is usually generated by tools provided by the network IP provider) with a powerful performance analysis GUI that allows side-by-side analysis of different RTL configurations, IWB greatly speeds this iterative process while mitigating the risks associated with manual creation of the required test benches.

What type of work do we need to do to be ready to have a common, if not standard, verification method for a network type of connectivity?

Avi: There are two aspects to the verification of networks-on-a-chip: functional verification and ‘performance verification’. Functional verification of these networks needs to be addressed at two levels: first make sure that all the ports connected to the network are compliant with the protocol (say AMBA3 AXI or AMBA4 ACE) that they are implementing, and secondly, verifying that the network correctly channels data between all the master and slave nodes connected to the network. As for performance verification, while the EDA industry has been focusing on serving the SoC architect community with virtual prototyping tools that utilize SoC models for early stage architectural exploration, building cycle accurate models of the on-chip network, capturing all the configuration options mentioned above is impractical. As the RTL for the connectivity network is usually available before the rest of the IP blocks, it is the best vehicle for performing cycle-accurate performance analysis. Cadence’s IWB, which as described in the previous answer, can generate a test bench tuned for running realistic traffic scenarios and capturing performance metrics. IWB can also generate a functional verification testbench which addresses the two aspects I mentioned earlier – protocol compliance at the port level and connectivity across the on-chip network.

What do you think should be the next step?

Avi: Many of our big SoC designing customers have dedicated network-on-a-chip verification teams who are struggling to get not only the functionality right, but ever more importantly, get the best performance while removing unnecessary logic. We expect this trend to intensify, and we at Cadence are looking forward to serving this market with the right methodologies and tools.

The contribution from Cadence reinforced the point of views expressed by the panelists.  It is clear that there are many options available to engineers to enable communication among IP blocks and among chips and dies.  What was not mentioned by anyone was the need to explore the topology of a die in view of developing the best possible interconnect architecture in terms of speed, reliability, and cost.

Hardware-Software Tops Priority List For ASIC Prototypers

Thursday, August 23rd, 2012

By John Blyler
The most important decision facing chip prototyping designers this year (2012) concerned the completeness of the combined hardware and software platform. (See Fig. 1). Cost and boot time followed as the next most importance issues. Close to 200 qualified respondents participated in the annual Chip Design Trends (CDT), “ASIC/ASSP Prototyping with FPGAs” survey.

Fig. 1: Prototyping priorities listed in the 2012 CDT survey.

The concern over a complete hardware-software prototyping solution was in stark contrast to results from previous years, when key concerns revolved around the flexibility and expandability of the system, as well as cost, performance and ease-of-use factors (see chart below).

Another surprising finding in this year’s survey is the importance of system “bring-up-time,” which ranked in the top three concerns for software development-based prototyping systems. The importance of software-related issues was further verified by another survey question that found an overwhelming 65.5% of respondents used a combination of software and hardware execution (i.e. simulation plus FPGA prototyping).

What was the language of choice for these hardware-software co-designers? C/C++ beat out Verilog, VHDL and their derivatives. (see Fig. 2)

Fig. 2: Software languages used in software simulation and hardware (FGPA) based prototyping systems. (Source: 2012 CDT Survey)

Most designers who used a combination of software simulation and hardware FPGA-based prototyping did so to achieve early verification results (42.7%) and to accelerate the (simulation) speed with software processor models (35.4%)

The most common hardware configuration on the FPGA prototyping board consisted of between 4 to 9 clocks with the fastest clock running 50 to 125 MHz.

What interfaces were used to connect the software simulation and FPGA based prototyping/emulation/acceleration platforms? Not surprisingly, ARM-based interfaces were the most popular (56.4%), including ACE, AMBA, AXI, AHB, or APB variations (see Fig. 3). OCP was the choice interface for 17.3% designers. Many software developers just didn’t know what interface was used (36.4%).