Jive SBS Syndication Feed

Fast interrupt processing keys numerous applications

renesas@renesas.hosted.jivesoftware.com — Mon, 26 Jul 2010 22:35:43 GMT

Any number of microcontroller (MCU) applications require fast response to internal and external interrupts. For example, real-time control applications such as motor control require immediate response to internal MCU peripherals such as timers and external events such as user controls. The Renesas RX MCU architecture offers interrupt response that meets the most demanding of applications and includes an architectural feature called a fast interrupt function that can further accelerate response to a specified internal or external interrupt source.

The interrupt subject is a complex one that I will address over a series of blog posts in the coming weeks. I'd like to lay groundwork for future posts today.

First of all, it's important to recognize that a number of factors impact interrupt response time. There is the inherent time the MCU architecture takes to recognize an interrupt and transfer control to the interrupt handler or interrupt service routine (ISR).

Memory access speed also comes into play. One of my first posts here addressed Flash memory access speeds. Because the RX family integrates zero-wait-state Flash memory at clock speeds up to 100 MHz, embedded design teams can accurately determine worst-case interrupt response time. For MCUs that incur wait states on memory accesses, a best-case interrupt response time isn't necessarily a realistic interrupt response time. When the CPU clock frequency exceeds the speed at which zero-wait-state operation is possible, the actual interrupt response time can escalate by a factor of 2, 3 or more.

There are also architectural issues that impact how well the code in the ISR performs – or more succinctly how quickly the routine addresses the reason for the interrupt. The depth of the pipeline impacts the amount of time it takes to do meaningful work in the ISR. The first instruction in an ISR takes multiple cycles to execute – but the pipeline fills during that delay allowing subsequent instructions to execute normally.

In general, the RX architecture responds to an interrupt in 7 clock cycles. The first instruction in the ISR is issued on the 7^th cycle after the interrupt is detected. The fast interrupt response function can speed the response so that the first instruction is issued on the 5^th cycle. Moreover, the architecture offers the option of dedicating some registers to the fast interrupt function and that can save cycles in the ISR.

The RX interrupt performance is significantly better than competitive MCUs. For instance, the ARM Cotex-M3 typically responds in 12 cycles although the response is significantly slower when the CPU clock speed exceeds the Flash access speed. The ARM7 and MIPS M4K architectures are slower still in interrupt response time.

In future posts, I will provide a detailed look at how to measure interrupt response and on how the fast interrupt function works.

Code-density optimizations deliver real memory savings

renesas@renesas.hosted.jivesoftware.com — Fri, 23 Jul 2010 14:28:28 GMT

I've done a series of posts on steps that the Renesas RX microcontroller (MCU) design team took to maximize code density, thereby minimizing system memory requirements, Today, let's look at some benchmarks based on actual applications that demonstrate the code-density advantage.

For a quick review, I covered the concept of op-code optimization a couple of months back. I followed that up with posts that focused specifically on the BSR, ADD, BEQ, CMP, and MOV instructions. Those instructions were found to be the most frequently used instructions in an analysis that the RX design team conducted on actual application code. So those instructions were targeted for optimization in terms of minimum instruction length.

The RX team compared a number of MCUs against the RX for code density and the RX won in every instance. Let's focus on comparisons with an ARM Cortex-M3 MCU since that architecture is proving popular and is the ARM flavor that the company has optimized for code density.

For the purpose of comparison, the engineers used the RX code side as the reference case with a relative measure of 1. The results from the ARM MCU test can then be easily compared.

First the team ran a motor-control application developed for an air conditioner. The ARM code was 30% larger with a relative measure of 1.4.The team then benchmarked a data-communication application that was developed for a printer. The ARM code was 23% larger than the RX code.

Next up, the team examined a data-conversion application written for a fax machine. The ARM measured just under 1.4 for a 25% greater code footprint. A real-time-control application for an automotive breaking system resulted in 33% larger code for the ARM MCU.

The greatest advantage delivered by the RX came in a motor-control application for an automobile. The ARM measure was just above 1.6 for a 38% larger code footprint. The final system-control application from a car audio system showed ARM to have 33% larger code.

The real message here is not just that the RX delivers better code density but that it does so as an uncompromised 32-bit CISC processor that takes full advantage performance wise of that 32-bit architecture. And as I covered in a performance benchmark post, the RX also wins convincingly over the Cortex-M3 from the performance perspective.

Renesas offers RX-Stick MCU evaluation platform

renesas@renesas.hosted.jivesoftware.com — Wed, 21 Jul 2010 21:42:28 GMT

We'll get right to the subject at hand today since time may be of the essence. If you want a chance to evaluate the Renesas RX microcontroller (MCU) architecture, Renesas has a USB-based development platform called the RX-Stick – that at least for the moment is free. Register for or log in to the MyRenesas site and you can request an evaluation kit that will be supplied free while supplies last.

The RX-Stick is based on a 100-MHz RX610 MCU with 2 Mbytes of Flash memory. The small development board is powered by a USB cable and USB also serves to connect a PC development host with the on-board debugger and Flash programmer.

The evaluation board includes a 10x14-LED-matrix display, a small speaker, and a joystick interface and potentiometer inputs.

The kit comes with a High-performance Embedded Workshop (HEW) IDE and compiler CD. You have unlimited access to the HEW feature set for 60 days. Thereafter a compile size limit of 128 kbytes will apply.

The evaluation kit provides a number of demonstration projects that you can use to exercise the DSP and FPU capabilities of the IC, and even run you own Dhrystone benchmarks.

Renesas will support sharing of RX-Stick experiences on the Renesas Rulz community web site that also hosts this blog. You can share your projects and read about the experiences of fellow RX users.

Engineers that register to receive an RX-Stick kit will also be automatically eligible to receive a free kit based on the RX62N MCU later this year. The RX62N kit will include features such as Ethernet, USB, and CAN support.

Subroutine branch instructions contribute to code density advantage

renesas@renesas.hosted.jivesoftware.com — Thu, 15 Jul 2010 22:14:19 GMT

I've focused on the topic of optimized instruction encoding repeatedly recently because it's a big story in terms of the code-density advantage that the Renesas RX microcontroller (MCU) architecture offers over competing MCUs. I'll be sharing some details of that advantage in a future post just as I did in the performance benchmarking area recently. Today, I'll focus on the details of instruction encoding and specifically the instructions that are used to call subroutines.

The analysis that the RX team did when working on instruction encoding revealed that subroutine branch instructions account for 8% of all of the instructions that comprise actual application code. That made the instruction a target for optimization.

Most processors and MCUs including the RX have two types of subroutine branch instructions. The JSR (Jump Subroutine) instruction is used to transfer execution to a subroutine located at the address that's specified by the register specified by the instruction. Conversely, the BSR (Branch Subroutine) instruction uses relative addressing to determine the address where the subroutine is located.

Ironically, the use-case advantages of each are almost opposite of their origin. Let's temporarily go back to the day of 8-bit processors before compilers and high-level languages were commonplace. The JSR instruction was simple to use because programmers working in assembly language knew the exact address at which their code would be loaded and therefore a directly-addressed JSR instruction was foolproof.

But many subroutine calls were to addresses relatively close to the current program counter. Microprocessor architects conceived the BSR call with relative addressing to boost code density. The BSR was more efficient than JSR when the relative displacement between source and destination was small. Many implementations of the JSR instruction supported immediate values and therefore could take more bits to encode.

Fast forward to the day of the compiler and the situation is opposite. The RX JSR instruction can always be encoded in 2 bytes – it doesn't support immediate values. In fact immediate values are pretty useless in the compiler world where the programmer generally don't control the address at which the code will load.

Compilers use the BSR instruction that these days requires more bytes to encode given the huge memory arrays that are present even in relatively-simple systems. The displacement value is determined during the compilation process. The RX design team optimized the BSR instruction so that compilers or assembly language programmers could use the smallest instruction length possible -- dictated by the relative-addressing displacement between the program counter and the target address of the subroutine.

The RX BSR instruction comes in three forms, and the smallest of the three can be encoded in two bytes. Moreover, the smallest form can support the largest – 32-bit -- range of address destinations. The RX architecture accomplishes that feat by storing the displacement value in a register.

In a three-byte version, the instruction can cover a 16-bit displacement range covering jumps from -32768 to 32767 relative to the value of the program counter. The first byte stores the op code and the next two bytes store the displacement.

That three byte version will suffice in the vast majority of cases and offers a one-byte savings over the more typical four-byte version found in most 32-bit MCUs. The RX does support a four-byte version that covers a 24-bit displacement range.

These instruction optimizations may seem inconsequential at first glance. But one byte here and two bytes there adds up. Moreover, the RX CISC architecture is able to maximize code density without playing the tricks that RISC vendors such as ARM have resorted to – specifically using a 16-bit instruction set with a 32-bit processor. The RX can take full advantage of the 32-bit architecture at all times while offering best-in-class code density.

Developers conference sessions will cover RX MCUs, tools, and applications

renesas@renesas.hosted.jivesoftware.com — Tue, 13 Jul 2010 22:23:49 GMT

Registration just opened for the Renesas Electronics Developers Conference 2010 that's scheduled for October 11-14 in Orange County, CA near Anaheim. The conference will feature material that's applicable across all Renesas product families. Design teams that are considering or working with the relatively new RX microcontroller (MCU) architecture will find a lot of help at the conference. A number of lab sessions and presentations will focus specifically on the RX MCU architecture, development tools, and application-specific development.

The conference will include more than 100 hours of hands-on labs and lectures. Moreover, a roster of more than 40 Renesas Alliance Partners will participate. And there will be an exhibit hall. Let's peruse the RX-centric sessions and some others that might interest readers of the Doctor Micro blog.

Given the broad spectrum of MCUs offered by Renesas, most all attendees will find the session on the company's microprocessor and MCU roadmap extremely interesting. Ritesh Tyagi, Director MCU & Segment Marketing, will present the 9:45 AM session on Tuesday that will cover 8-, 16-, and 32-bit architectures and will detail how the architectures align with application segments in the market.

Later on Tuesday at 1:30 PM, Product Marketing Manager Mark Rootz of Renesas will discuss the methodology of choosing an MCU architecture. Rootz will cover a number of architectures but will focus on the RX family and detail the advantages of the DSP and FPU capabilities that we've previously covered in this blog.

On Wednesday at 9:45 AM, the schedule features a session on migrating to the RX family. The RX architecture is derived from the M16C and H8SX families. And as I've covered previously, the architecture and development tools simply the migration process.

On Wednesday at 4:00 PM, attendees may find the lab session on USB that's focused on the RX62N helpful. The session will examine host, device, and OTG (On The Go) implementations.

The Thursday schedule includes an RX-centric session on maximizing performance in power-limited environments that's slated for 8:30 AM. The session will address clock, device, and compiler settings that allow the design team to minimize power even in performance-intensive applications. As I covered on the blog, the RX includes multiple power-supply domains and low-power states that enable such designs.

In the application-specific area, motor control sessions stand out with two RX-centric sessions on Wednesday. First at 11:00 AM there is a lab session focused on using the timers, PWM controllers, and ADCs on the RX62T. Attendees will experience a hands-on-coding example.

Later at 4:00 PM, there is a session on motor control focused on the RX62T family of MCUs and motor-control algorithms. The lecture session will highlight the analog capabilities that are integrated in the RX62T. Attendees will also learn about implementing different motor-control algorithms using the Renesas HEW (High-performance Embedded Workshop) and the RX motor control development kit. There are additional motor-control sessions that are not centric to the RX including an introductory session Tuesday at 1:30 PM.

Attendees will find a number of sessions focused on development tools including general sessions on the HEW. One RX session from a Renesas Alliance Partner looks especially interesting. IAR will present an RX-centric session that focused on the company's compiler and Embedded Workbench IDE (Integrated Development Environment). Attendees will get an insider look at code optimization strategies and also learn about debugging and other special functions of the IDE. It will be interesting to hear a third-party go into the details of the RX architecture.

ADD instruction offers 3-operand flexibility

renesas@renesas.hosted.jivesoftware.com — Fri, 09 Jul 2010 00:50:08 GMT

I'm going to continue with a few more posts that focus on Renesas RX microcontroller (MCU) instructions that really demonstrate the advantages of the CISC architecture. Today let's examine the ADD instruction. The instruction implementation in the RX offers great flexibility in that it supports a variety of addressing modes and even a three-operand format. Moreover there is a code density story as well.

As we've discussed before, the RX design team chose specific instructions for optimization based on the analysis of actual application code. ADD is the 5^th most regularly occurring instruction – making up 6% of the instructions in a typical program and was therefore targeted for special treatment.

Of all of the instructions that I've discussed, ADD perhaps best illustrates the flexibility of CISC architectures in general and the RX architecture specifically. Let's examine the three-operand format that illustrates the flexibility.

Consider the instructions:

ADD R1, R2, R3

and

ADD R1, R2.

The three-operand format adds the values in R1 and R2 and stores the result in R3. The two-operand version adds the values in R1 and R2, and stores the result in R2 – overwriting one of the operands. Both instructions have value to both compilers and programmers working in assembly language. With typical processors that only support the two-operand format, there are times when an extra move instruction is required before or after the add because the program needs to preserve the data in the destination register before the ADD takes place as well as preserving the summed result.

The RX ADD instruction offers additional flexibility in that the first of the three operands can be an immediate value. Of course RISC architectures would always have to load such an immediate value prior to executing the ADD.

The three-operand ADD is encoded in three bytes when each of the operands is a register. With an 8-bit immediate value, the instruction still only requires 3 bytes. Larger immediate values can stretch the instruction length to 4, 5, or 6 bytes.

Let's also have a quick discussion about the two-operand ADD instruction before we conclude. Like many CISC processors, the RX can encode a two-operand ADD instruction in two bytes when both operands are registers. But the RX team devised 2-byte instructions both for ADDs involving an immediate value or data from a memory location.

A two-operand ADD instruction in which the first operand is a 4-bit immediate value, and the second operand is a register requires only two bytes. That is half the size of typical immediate-value ADD instructions. Larger immediate values stretch the instruction length to 3, 4, 5, or 6 bytes.

A two-operand ADD instruction in which the first operand is data in a memory location that's pointed to by a register also requires only two bytes. More complex versions can use a register storing a memory location, and an offset from that location. Such relative-addressing modes can result in 3-, 4-, or 5-byte instructions.

The combination of flexibility and compact instructions is a powerful one. For systems, the result is smaller code, less memory and therefore lower cost, and better performance.

Benchmarks demonstrate the RX performance advantage

renesas@renesas.hosted.jivesoftware.com — Fri, 02 Jul 2010 17:29:21 GMT

An early post on the Dr Micro blog focused on zero-wait-state Flash memory as a huge advantage for the Renesas RX microcontroller (MCU) family. Renesas has been able to manufacture Flash memory that supports 10-nsec read operations, thereby enabling zero-wait-state operation at clock frequencies up to 100 MHz. Today, let's have a look at what that means in terms of actually application performance.

The RX team has focused a lot of its development work on real-world applications as we've covered in multiple posts on instruction optimization. The company has also used real-world applications to compare the performance of the RX relative to other popular MCUs.

Engineers ran benchmark tests using three actual customer applications from the motor-control and automotive market segments. The benchmarks provide good points of comparison of both the relative performance of different MCU microarchitectures and the realized performance based on factors such as memory access speed.

First the benchmarks compared an RX CPU and an MCU based on the ARM Cortex-M3 with both MCUs clocked at 24 MHz. The chosen clock rate was one at which both MCUs operate with no wait states executing from on-chip Flash memory. The RX handled all three benchmarks better than the ARM MCU. On average, the RX offered around 10% better performance.

The engineers then repeated the tests with 48-MHz clock rates. As is the case with most MCUs, the ARM MCU incurred one wait state reading instructions from Flash memory. In the second round of tests, the RX operating with no wait states provided more than 50% better performance on average across the three benchmarks.

Finally, the tests were run at maximum clock speeds. The ARM MCU was clocked at 72 MHz resulting in two wait states on Flash reads. The RX was clocked at 100 MHz – still operating with zero wait states. In two of the three tests the RX proved well more than two times faster than the ARM chip. In the third benchmark, the performance advantage was still in the range of 75%.

The tests illustrate that the RX CISC microarchitecture offers a baseline performance advantage over one of the most popular RISC MCUs. The advantage is considerably greater when you take into account Flash performance and maximum clock speed. The fact that Renesas owns its own fabs and can leverage its process technology to ramp clock speed and Flash-read speeds is a key differentiator relative to licensed cores such as those from ARM.

Repeat MAC instruction extends math advantage of the RX

renesas@renesas.hosted.jivesoftware.com — Thu, 01 Jul 2010 01:05:10 GMT

I've recently spent quite a lot of time writing about the Renesas RX microcontroller (MCU) instructions in terms of code density and flexibility. Today let's take a look at an instruction that does afford a code density advantage but that also illustrates the powerful math capability built into the RX. The Repeat Multiply and Accumulate (RMPA) instruction offers the incredible ability to perform a series of multiply and accumulate (MAC) instructions on tables of operands stored in memory.

The capabilities of the RMPA instruction are unusual in the context of 32-bit MCUs for a number of reasons. For starters, many 32-bit MCUs lack MAC capabilities – a function required in most digital-signal-processing (DSP) algorithms. As I covered in a prior post, the RX includes both hardware MAC and floating-point units (FPUs).

Even MCUs with MAC capability don't always have the ability to operate directly on operands from main memory. RISC MCUs, for instance, almost always require operands to be present in registers. And even some CISC MCUs require operands for MAC or FPU instructions to be in specific registers. Finally, the RMPA

The RMPA instruction ins a simple 2-byte instruction. The format is:

RMPA.size

The size specifier can be B, W, or L for byte, word (16-bit), or long word (32-bit) respectively. That size argument is not important from the point of view of the MAC operation, but it does inform the processor of the size of a memory increment to take as it fetches sequential operands.

The program must prepare for the RMPA instruction by loading a table of operands in two different memory locations. The program must store the location of one operand in R1 and the location of the second operand in R2. The program must also store the number of operands in the table in R3.

The instruction results in the multiplication of two operands that are then added to the existing accumulated value. The result is store in the trio of registers R6:R5:R4 as an 80-bit datum. The program should set the R6:R5:R4 value to the desired initial value before calling RMPA.

Clearly, RMPA accomplishes an incredible amount of work for a two-byte instruction. Moreover, the instruction takes advantage of the on-chip math capabilities. In a subsequent post, we will examine a specific algorithm example.

Conditional branch instructions require as little as 1 byte

renesas@renesas.hosted.jivesoftware.com — Sun, 27 Jun 2010 18:22:07 GMT

Let's continue an examination of some Renesas RX microcontroller (MCU) instructions that key the code density benefits of the architecture, and that demonstrate the flexibility of a CISC instruction set. I recently covered the Move (MOV) and Compare (CMP) instructions. Today let's focus on Conditional Branch instructions including BEQ (branch if equal) and BNE (branch if not equal). The RX instruction set encodes such instructions in as compact a length as a single byte.

As we covered previously, the design team behind the RX analyzed real application code to discern regularly used instructions, and then sought to minimize the instruction length for those instructions. If you review my prior post on optimized op codes, you will see that conditional branch instructions can comprise 15% of the instructions in a typical program – second in frequency only to the MOV instruction.

As is with the case of most RX CISC instructions, the conditional branch instructions come in many flavors offering incredible flexibility to the programmer. For example, there are conditional branches based on greater than or less than operators, and based on positive, zero, or negative values.

The BEQ and BNE, however, are the most commonly used. And the RX team found a way to encode these instructions in as little as 1 byte. Consider the following instructions:

BEQ label or BEQ 1000h

Both instruction result in a branch to a memory location if the processor's Z flag is set to a "1" value. The instruction length is determined by the difference between the memory location of the BEQ instruction that's stored in the program counter relative to the branch location defined either by a label or by an immediate value.

Many branch instructions are to a new address within the general vicinity of the executing branch instruction. The Renesas assembler will subtract the current instruction address from the target to determine a displacement value that is called the pcdsp (displacement of relative addressing of the program counter) in RX parlance. If the branch distance is forward to a memory location higher than the existing program counter, and if the distance is 10 or less, then the instruction is encoded in one byte.

Of course the RX supports much greater branch operations including both in the forward and reverse directions from a memory address perspective. A two-byte instantiation can control forward or reverse branches in the range of -128 to +127 relative to the program counter. And the three-byte version stretches the range to -32768 to +32767.

The other types of branch instruction such as the aforementioned branch greater than (BGTU) all rely on two-byte encoding. Those instructions have a maximum displacement of -128 to +127.

Again the branch instruction illustrates the flexibility of a CISC architecture. Programmers have the ability to use a single instruction to evaluate a complex condition. On the other hand, the most commonly used BEQ and BNE instructions are always encoded in the minimum possible length. The result is better performance on application code that occupies a smaller memory footprint.

On-chip RX debuggers get personal and ICE is planned

renesas@renesas.hosted.jivesoftware.com — Fri, 25 Jun 2010 18:26:09 GMT

In several recent posts I covered third-party development tools for the Renesas RX microcontroller (MCU) family such as the J-Link emulator from Segger. I received several emails pointing out that Renesas also offers such tools and of course I didn't mean to imply that they didn't. Indeed Renesas is already shipping the E1 and E20 debuggers and plans to support the RX with its E100 in-circuit emulator (ICE).

Perhaps we should step back a bit and talk terminology here. The term emulator is often used to describe different tools -- a software emulator/simulator, a software emulator/debugger that uses-on-chip debugging capabilities, or a hybrid software/hardware tool such as an ICE that places a specialized hardware module on a target pc board in place of the MCU.

Software emulators/simulators can be used in the early stages of a development as a stand-in for hardware so that code development can commence simultaneously with hardware development. The Renesas High-performance Embedded Workshop (HEW) includes such simulation capabilities.

An ICE, with an MCU module allows the emulator software to have real-time access to buses, registers, and control circuits. An ICE supports debugging of both software and hardware. Such products are fairly expensive because of the hardware in the MCU module and the emulator, but the cost is often warranted.

The software emulator/debugger relies on debug capabilities built into the MCU. Segger calls their product an emulator. Renesas refers to its products as On-Chip Debugging Emulators. Such products do have a hardware component that connects to the JTAG (Joint Test Action Group) port on the MCU and provides access to the on-chip debugging capability. The hardware modules also connect to the host development system such as a PC and can offer other features such as the ability to program MCU flash memory.

Currently, Renesas offers two of the on-chip emulators. The E1 is priced at $150 and therefore is sufficiently affordable that every member of embedded design team can have one for their own use. The $995 E20, meanwhile, offers higher-end capabilities and is more likely to be a shared resource.

Both products include a GUI software-based debug package. Both can program on-chip Flash memory, and have UART and JTAG connections. Both also have similar capabilities in supporting 256 software break points, 8 hardware breakpoints based on execution address, and 4 hardware breakpoints based on data access.

The E1 has internal trace capabilities for 256 branches or instruction cycles. The E20 can handle approximately 2 million branches or cycles. The E20 also includes a 4-kbyte real-time RAM monitor that's not available in the E1.

Renesas also plans to support the RX with ICE capabilities with what it calls a Full-spec Emulator. The E100 product is common to a broad base of Renesas MCUs including the M16C, R8C, H8S, and H8SX families. The MCU target module is different with each.

Compare instruction adds to the RX code-density story

renesas@renesas.hosted.jivesoftware.com — Sat, 19 Jun 2010 19:41:44 GMT

I know that I've posted multiple times about the code-density advantage of the Renesas RX microcontroller (MCU) family. I've done so because it directly impacts system cost. Better density equates to less memory. Today, I'll cover another instruction – the compare (CMP) instruction – that plays a big part in code density and illustrates again the power of a CISC instruction set in terms of flexibility.

As I mentioned in the recent post on the move (MOV) instruction, the RX design team analyzed real application code to discern which instructions were used most frequently. The team then focused on the most frequently used instructions and devised innovative ways to minimize instruction length.

The code analysis revealed that the CMP instruction was the third most frequently used instruction. The instruction comprised 11% of the sample code. Moreover, the design team found a way to cut the instruction length in half relative to other CISC MCUs – yielding a 2-byte CMP instruction.

As we covered in the discussion of the MOV instruction, the CMP instruction is variable in length depending on the type of the operands. It's a tremendous advantage of a CISC instruction set to be able to use immediate values and operands stored in memory with instructions such as CMP. RISC MCUs require that both operands be stored in registers.

There are three different ways you can use CMP with a 2-byte instruction length. Register to register compares are always 2 bytes. But the RX also supports both compares using immediate values and operands from memory with 2-byte instructions.

Consider the following instruction:

CMP #7, R2.

The instruction compares an immediate value 7 with the data stored in R2. As long as the immediate value is 4 bits or less in size, the instruction requires only 2 bytes. But the implementation provides the flexibility to use immediate values as wide as 32-bits. The instruction lengths scales from 2 to 6 bytes to support 4, -, 8-, 16-, 24-, and 32-bit immediate values.

The CMP instruction can also be implemented in 2 bytes for memory-to-register compare operations. Consider the following instruction:

CMP [R2], R3.

This instruction comparing the operand pointed to by R2 with the one stored in R3 always requires only 2 bytes. Again, however, the implementation offers flexibility. The instruction can be used with a displacement value from the memory location stored in the register. The instruction length scales to 5 bytes to support 16-bit displacements.

Most all CISC architectures offer the flexibility illustrated here with CMP. That is a huge advantage of CISC relative to RISC MCUs. But the RX team went a step further to develop compact versions of the instruction that embedded design teams can leverage to significantly reduce code size.

Video demonstrations highlight the advantages of an FPU

renesas@renesas.hosted.jivesoftware.com — Fri, 18 Jun 2010 18:52:06 GMT

The integrated floating-point unit (FPU) is one of the key performance-oriented aspects of the Renesas RX microcontroller (MCU) architecture. I covered the FPU and the DSP capabilities of the RX previously. Today I'll offer a brief follow up and a pointer to some demonstrations that illustrate the FPU capabilities and benefits.

Renesas engineers used a demo board based on the first RX MCU, the RX600, and developed three relatively simple applications that illustrate the advantage that an FPU affords. Two of the demonstration applications are run side by side with one using the FPU and one relying purely on integer operations. The other illustrates real-time FPU performance.

You can access the video on the Renesas web site. To watch, you will need Windows Media Player or some other application capable of handing the Windows Media Video format.

The first demonstration simply displays the path of a bouncing ball. The FPU version requires 22 µsecs of calculation time, whereas the integer version requires 106 µsecs.

The second demonstration relies on an electronic keyboard and a microphone, and the musical scale is analyzed using a fast-Fourier-transform (FFT) algorithm. The FPU enabled FFTs of 12 notes required 2315 µsecs of calculation time. The integer version took an order of magnitude longer at 25795 µsecs.

The final demonstration doesn't compare FPU and integer operations but rather demonstrates the real-time FFT capabilities of the RX. Again a microphone is used to capture a sequence of piano notes and the FFT is performed on each note with a real-time frequency-domain display on the demo board LCD.

The decision to integrate an FPU, and the execution in silicon, will enable the RX family to take on applications beyond the range of most MCUs.

MOV instruction illustrates RX CISC advantages

renesas@renesas.hosted.jivesoftware.com — Wed, 16 Jun 2010 19:36:26 GMT

I've mentioned in several blog posts that the Renesas RX microcontroller (MCU) family leverages the best of RISC and CISC architectures to deliver breakthrough performance and code density. The instruction set is decidedly CISC in nature and is a primary factor in the code density and performance advantage that the RX enjoys over other 32-bit MCUs. So it's time to take a detailed look at some instructions to illustrate the benefits of the architecture and we will start with the move (MOV) instruction.

The MOV instruction is a good place to start because it is the most frequently used instruction in real code. In the recent post that I did on op codes and code density, I included a graphic that broke down the frequency of instruction usage. The RX team analyzed real code to discern the most frequently used instructions and focused on those instructions to optimize instruction length thereby delivering a code-density advantage that requires less memory. MOV instructions comprise 31% of the code in a typical application.

The MOV instruction in a CISC architecture is especially powerful. Unlike in the RISC case where instructions are generally fixed in length, the CISC counterpart is variable in length and far more capable. For example, the RX MOV instruction can handle the following types of data transfer from source to destination:

register to register
register to memory location
memory location to register
memory location to memory location
immediate value to register
immediate value to memory location.

Generally the MOV instructions can operate on byte (8-bit), word (16-bit), and long word (32-bit) data. Indeed the instruction specifies the amount of data being moved – MOV.B specifies a byte-wide move.

Of course what is immediately evident is that the instruction length for a MOV instruction might be exceptionally long. When you move a 32-bit immediate value to a register, for instance, the immediate value itself will occupy four bytes in the decoded instruction. Moreover some of the moves that involve memory locations rely on memory locations stored in a register along with the specification of a displacement value from that memory location. In the worst case, a MOV instruction might include the MOV instruction op code, a 32-bit immediate value, a register designation, and a displacement from that register. That type of instruction can stretch to eight bytes.

Fear not, however, because the flexibility of the RX MOV is a great benefit. And the MCU design team went to great lengths to deliver compact instruction encoding for the most commonly used instantiation of MOV.

In fact, there are a number of short-format MOV instructions that will be used most frequently and those instructions are 2 or 3 bytes in length. Let's consider a typical example. Consider the following instruction:

MOV.L Rs, dsp:5[Rd]

This instruction transfers a 32-byte value from a source register (Rs) to a memory location that is defined by the location stored in a destination register (Rd) added to a 5-bit displacement value. The RX design team managed to encode this instruction in two bytes.

The MOV instruction and the L designation for long word require 5 bits. Both of the register designations are done with 3 bits meaning that the instruction can only use half of the 16 registers in the MCU. But that's a minor limitation for modern compilers or hand-coded assembly language. The 5-bit displacement provides a range of 32 address locations as an offset from the memory location stored in Rd.

In comparison, consider the same instruction with full access to 16 registers and with the range afforded by a 16-bit displacement value. That instruction would double in size to 4 bytes.

There are many more examples of optimized instruction encoding found in the RX architecture. We will cover more in coming posts. I've also promised and will provide more in the way of code density benchmarks for the RX. When you see code density discussed remember the example of the MOV instruction. When clever encoding can reduce a powerful instruction from 4 bytes to 2 bytes, the inherent advantage of a CISC instruction set gets greatly enhanced.

IAR Systems offers RX IDE, compiler and PowerPac

renesas@renesas.hosted.jivesoftware.com — Fri, 11 Jun 2010 18:06:16 GMT

Let's again continue our recent trend of looking at development tools for the Renesas RX microcontroller (MCU) family with a look at another third party that moved early to support the RX. IAR Systems announced a year ago that it would support the RX family with both its IAR Embedded Workbench and its IAR PowerPac tools. Collectively the tool sets provide embedded design teams with a complete Integrated Development Environment (IDE), compiler and assembler, a real-time operating system (RTOS), and middleware -- everything needed to build and deploy an application.

The RX advancements in code density, performance, and low power drew the early IAR support. “The RX family is a world-class technical achievement that will attract engineers looking for tomorrow’s microcontrollers. That we have already released support for the RX family is a result of the long-term commitment that we have to support Renesas customers with quality development tools” commented Mats Ullström, Product Director at IAR Systems.

The IAR Embedded Workbench is an IDE that includes a project manager, editor, build tools, and a debugger. The tool suite also includes a C/C++ compiler and assembler that are optimized for the RX hardware. For example, the compiler supports the FPU. AS I discussed in a prior post, the integrated FPU is a key factor in maximizing RX performance. The IAR compiler directly generates FPU instructions from C or C++ source code without using assembly inlining, thereby yielding maximum arithmetic performance.

Embedded designers can leverage the continuous workflow of the IAR Embedded Workbench to create source files and projects, build the applications, and then debug the application on either a simulator or actual hardware.

The IAR PowerPac integrates tightly with the IAR Embedded Workbench and adds RTOS and middleware features. The software includes an RTOS, a file system, TCP/IP network stack, and USB device stack. The integration with the Workbench allows the IDE C-SPY debugger to access RTOS internals such as a task list, timers, queues, semaphores, resources, and mailboxes.

Design teams can register and download an evaluation edition of the IAR tools, The evaluation editions corresponds to the latest production release but is only functional for 30 days. There is also a free KickStart version of the tools that can be used to build code-size-limited applications.

Third party tools emerge for RX family

renesas@renesas.hosted.jivesoftware.com — Thu, 10 Jun 2010 18:43:40 GMT

Continuing on the theme of my recent posts on development tools for the burgeoning Renesas RX microcontroller (MCU) family, I thought I'd take a look at third-party tools. I expect that as the MCU architecture begins to gain traction, you will see broad third-party support. I'll cover the third-party tool situation on a recurring basis as new products are announced and will focus today on Segger Microcontroller as they were among the earliest to commit support to the RX family. The company offers both an operating system and a debugger for the RX family.

Last November, Segger announced availability of the embOS real-time operating system (RTOS) for the RX family. The RTOS relies on a priority-controlled scheduler and yields what Segger calls zero interrupt latency depending on the MCU and compiler used. Embedded design teams can prioritize task at 255 levels.

The embOS includes support for low-power MCU modes on MCUS such as the RX. As I discussed previously in a power-centric post, the RX family can enter power-saving standby modes. For instance, the RX600 dissipates only 3 µA in standby even with the real-time click active.

Segger's RTOS offers full interrupt support. Embedded design teams can make use of nested interrupts. The RTOS also includes a real-time kernel viewer, and precision task profiling so that design teams can ensure code matches real-time application requirements.

More recently, Segger also announced that its J-Link emulator is now compatible with the RX family. “We are very excited about the opportunity to provide the first independent emulator for Renesas RX. We believe that RX is going to be a very successful family of microcontrollers due to the very efficient core, which achieves more Mips/MHz than competing architectures and due to Renesas’ unique Monos Flash technology, allowing zero wait state operation up to 100MHz,” says Dirk Akemann, Marketing Manager at Segger.

The J-Link emulator allows design teams to set an unlimited number of breakpoints in RAM and internal Flash memory. The emulator capability complements the eight hardware-event breakpoints that are designed in to RX MCUs. The emulator supports a comprehensive set of events including breakpoints set based on execution, data access, and trace parameters, as well as combinations of all three.

The emulator requires no power supply. A USB cable supplies power from the host development system. The emulator can monitor all on-chip JTAG signals and can measure target voltage.

Design teams can purchase a J-Link emulator from Segger starting at $299. If a user already owns a J-Link emulator they only need a new $60 adapter cable to use the emulator with the RX family. You can download the required RX-family software for free from the Segger web site.

The J-Link integrates seamless with Renesas's software development tools including the High-performance Embedded Workshop (HEW) Integrated Development Environment.