Building a system on chip (SoC) from IP blocks requires system-level integration and bring-up, and that requires firmware working on the target. In a fast-paced development cycle, it is crucial to provide customers with IP blocks and tested firmware. In particular, at the bring-up stage, there may be very few debug capabilities at hand and, therefore, a firmware package that is pre-tested on multiple platforms and systems will speed up the integration effort. The driver package provides the following benefits: Abstracts implementation details through well-defined and use case-driven application programming interface (API) Enables early (pre-silicon) development of a board support package (BSP) / software development toolkit (SDK) Provides early reference to silicon validation. Cadence soft-IP cores now come with firmware that has been tested in simulation, on our emulation platform and on FPGA boards. What is the use model of the firmware package? The firmware package typically consists of: Core driver – this is a platform- and OS-agnostic library that abstracts the hardware interface (registers, DMA descriptors, interrupts) into a software interface (functions, data structures, and call-backs). It can be used as a building block for OS or bare metal drivers and applications. Linux reference wrapper – this is a wrapper that uses the core driver library and is registered with a certain Linux kernel framework to allow for our device to be handled by the Linux kernel framework. It can be used as a system testing and bring-up tool and can be further optimized to become a part of a shippable system. Reference code – this is an example application that shows how to use the core driver library API in a typical programming flow for that IP. It can be used for system bring-up and can be further developed in to a shippable bare metal application. What is the architecture of the Cadence firmware? The firmware package comes with abstraction layers on both ends: API on top for the customer application and a hardware abstraction layer (HAL) for all hardware and system calls. Interrupt handling and memory allocation are external to the core driver. Examples of the HAL implementation for ARM bare metal and Linux are provided with the package. Examples of API usage are provided in the reference code. What documentation is provided? There is a Quick Start Guide explaining how to quickly get up and running with the firmware package. The core driver API comes with Doxygen comments. These feed into a User Reference Guide document providing a full API reference and explanation of use with code snippets and pointers to the reference code elements. The HAL is documented in the Porting Guide, containing both the API reference and usage models. The core driver is tested using use case driver test cases and automatic API tests. The results of these, along with a static checker report and the test system architecture, are presented in a Test Report. What platforms will it run on? Both Little and Big Endian are supported – through the HAL implementation. We run our firmware on Cadence Tensilica Xtensa DE_233L (fast model and RTL in FPGA), on ARM Cortex-A9 (fast model), and on Microblaze (RTL in FPGA). What is the bring-up effort for the customer? A quick answer to this would be “less than 100 lines of code” in bare metal. Within a standard system, the customer is required to create the following: A main() function calling the reference code – this would be 20-40 lines of code Specify base addresses to access IP – less than 10 lines of code Optional: Implement the HAL functions (if different from provided) – this is typically 20-50 effective lines of code Optional: Provide any additional reset functionality (not handled by IP registers) For our Linux reference driver, only the Device Tree (DTS) file needs to be updated. Cyprian Wronka![]()
![]()
↧