What's the alternative to building the acceleration right into the processor? With standard RISC processors, the answer is to build your own RTL blocks for the acceleration. And we all know what that means - months of lengthy complex verification cycles. In most RTL blocks, the FSM (finite state machine) contains nothing but control details. And most of the design and verification risk is in the FSM, dur to its complexity.

A late design change made to an RTL acceleration block is much more likely to affect the FSM than the datapath because the FSM contains most of the design complexity. Configurable processors reproduce the RTL block’s ability to have wide datapaths—which can be guaranteed correct-by-construction by the processor vendor—while reducing the risks associated with FSM design because processor-based FSMs are firmware programmable.

Adding functions to a Tensilica processor core never compromises the underlying base Xtensa instruction set, thereby ensuring availability of a robust ecosystem of third party application software and development tools. Configurable Xtensa processor cores are always compatible with major operating systems, debug probes and ICE solutions; and always come with a complete, automatically generated software-development tool chain including an advanced integrated development environment based on the ECLIPSE framework; a world-class optimizing, vectorizing compiler; a cycle-accurate, SystemC-compatible simulation model and instruction set simulator; the full industry-standard GNU tool chain; and EDA synthesis scripts.

Configured processors can be used as an alternative to hand-coded RTL blocks by adding the same datapath configurations as implemented in RTL accelerator blocks. These datapath configurations include deep pipelines, parallel execution units, task-specific state registers, and wide data buses to local and global memories. This broad configurability allows configured processors to sustain the same high computation throughput and support the same data interfaces as RTL hardware accelerators.

However, control of configurable-processor datapaths is very different from the RTL counterparts. Cycle-by-cycle control of a processor’s datapaths is not frozen in a hardware FSM’s state transitions. Instead, the processor-based FSM is implemented in firmware, which greatly reduces the amount of effort needed to fix an algorithm bug or to add new features. In a firmware-controlled FSM, control-flow decisions occur in branches; load and store operations implement memory accesses; and computations become explicit sequences of general-purpose and application-specific instructions.

There are many important benefits to be realized by migrating from hand-coded RTL accelerators to microprocessor cores enhanced with task-specific datapaths controlled by firmware-based FSMs:

1. Added flexibility: Simply changing the FSM firmware changes a block’s function.
2. Software-based development: The ASIC design team can use fast, low-cost software tools to implement most chip features and add more value to the silicon.
3. Faster, more complete system modeling: For a 10-megagate design, even the fastest RTL logic simulator may not exceed a few system-simulation cycles per second. By contrast, firmware simulations for configured processors run at hundreds of thousands or even millions of cycles per second on instruction-set simulators.
4. Unification of control and data: No modern system consists solely of hardwired logic. There’s always a processor running software. Moving functions that may have been previously implemented with hand-coded RTL functions into a processor removes the purely artificial separation between control and data processing and simplifies the system’s design.
5. Time-to-market: As discussed in the above points, using configured processors simplifies ASIC design, accelerates system modeling, and speeds hardware finalization. These benefits get the product to market faster. After product introduction, firmware-based FSMs easily accommodate changes to standards because implementation details aren’t “set in stone.”
6. Designer productivity: The engineering manpower needed to develop and verify custom RTL acceleration hardware is greatly reduced. A processor-centric ASIC design approach permits graceful project-schedule recovery when (never if) a bug is discovered.