New processor language variant needed for SIlicon Labs CIP-51 (C8051Fxxx) family

[gtackett]

Is your feature request related to a problem? Please describe.
In order to add support to Ghidra for the Silicon Labs CIP-51 (originally created by Cygnal Integrated Products, which was later acquired by Silicon Labs), 8051.ldefs needs a new variant of the 8051 processor.

The need for a new variant is driven by features of the CIP-51 and supporting compilers that can't be adequately handled with any of the existing variants. The solution description below discusses some of these.

Describe the solution you'd like

CIP-51 implements the full 8051 instruction set and on-chip peripherals as the original 8051. Devices based on the CIP-51 core offer additional special purpose on-chip peripherals which vary from model to model.

The CIP-51 memory model is also based on the original 8051, but with extensions to allow for additional memory and for the various on-chip peripheral devices specific to the CIP-51 family.

Initially I think we should focus on the C8051F120, a member of what may be the earliest CIP-51 variant family. Its feature set appears to be fairly representative of the CIP-51 family in general.

There are at least two compilers/toolchains that specifically support CIP-51 extensions to the 8051:

• ARM Keil's C51/CX51
• IAR Embedded Workbench

Describe alternatives you've considered
Extensions to the 8051 as implemented in existing variants--mx51, 80251, 80390, and mx51--can't be used to accurately and adequately describe the extensions present in CIP-51.

Additional context
I may be able to handle some of the additions or changes to the existing 8051.pspec/.cspec/.ldefs but can definitely use help from anyone who already knows the CIP-51 architecture or is willing to read up on it.

To fully achieve support for CIP-51, changes to the .sinc file may also be required.

Pointers to the applicable Silicon Labs and Keil documentation should soon follow in one or more replies to this comment.

[gtackett]

C8051F120 Extended Special Function Register (SFR) space

The 8051 has a set of Special Function Registers in a portion of RAM that's distinct from ordinary data memory and program memory.

CIP-51 expands the number of SFRs via SFR paging. The C8051F120 SFR pages are numbered 0, 1, 2, 3, and F. All 8051 SFRs are inherited by CIP-51 and reside on SFR page 0. SFRs for some C8051F120 device-specific peripherals also reside on Page 0.

Those SFRs that are most critical to MCU operation are each available on every SFR page, A few examples are the Accumulator (A), B, DPTR (the Data Pointer), one interrupt enable and one interrupt priority register (IE and IP respectively), the Program Stack Pointer (SP), and the SFR page stack registers (SFRPAGE, SFRNEXT, and SFRLAST).

The value in SFRPAGE determines which page of SFRs is accessed during execution of direct-access MOVs to/from SFR space.

How to implement SFR paging in a .pspec file

Ideas, anyone?

C8051F120 Extended Program Memory

CIP-51 introduces a new SFR PSBANK to control access to its expanded program memory.

Program memory address space.

The C8051F120 extends program memory address space to 128Kb, up from the 8051's 64 Kb, This is implemented in on-chip flash memory as four 32Kb code banks. Code bank 0 (aka the common code bank) is always mapped to the lowest 32Kb (0x0000-0x7FFF) of the 8051 address space. Any of the four code banks can selectively be mapped into the upper 32Kb of the 8051 address space. (Mapping Bank 0 to the upper half would make little sense as it's always mapped to the lower half, but going so is allowed.)

Mapping the upper code banks

See below.

[gtackett]

C8051F120/1/2/3/4/5/6/7, C8051F130/1/2/3 data sheet

[gtackett]

I'm going be revising 8051.ldefs to start adding support for the CIP-51 architecture and Keil Cx51 compilers, along with the following two new files:

• cip-51.pspec, initially just revising the symbol names from 8051.pspec
• cx51.cspec, based on 8051.cspec, renamed to reflect the Keil compiler name, and implementing its register-based default calling convention.

(This work will be done in my own fork of the master repository but isn't there yet.)

I will have a few questions about what's necessary in each of these files to capture the unique aspects of CIP-51 and Cx51.

A couple of the specific subjects I've begun working on, with no. 1 being the one I'm focused on finishing first.

1. How to extend the 8051's 64 KB program memory to accommodate C8051F12x extended program memory address range, which:

• Is user-writable FLASH from 0x00000 to 0x200FF;
• Has a reserved "hole" at 1FC00-1FFFF (initially it's not very important that it be reserved);
• Has a no-execute scratchpad at 20000-200FF for constant data.

2. How to handle multiple pages of SFRs, in which

• Some registers are visible on all SFR pages, but most are only visible on one;
• Most SFRs are read-volatile/write-volatile, but a handful (stack pointer, accumulator, etc.) aren't.

Perhaps @GhidorahRex , @emteere or others more knowledgeable than me in Ghidra development, can connect with me so that I can more fully describe where I need some help?

(Ryan has been working with me on a loader that needs the additional memory space in order to load larger binaries.)

[gtackett]

In a branch in my fork of Ghidra I've just now made changes to:

1. Add a processor variant called "CIP-51"
2. Add an address space specific to CIP-51 called IFLASH with 24 bit addressing.
3. For CIP-51, make the SFR address space accommodate 16 bit addresses.

This more than suffices to provide some storage into which a loader can place memory content from a binary file into flash memory. @ryanmkurtz has already given some help on this front. Before I take on that, I still have some cracking to do on Keil's extended OMF-51 as produced by their Cx51 compiler[s] and BL51/LX51 linkers.

[gtackett]

Mapping the upper code banks

CIP-51 MCUs use the PSBANK SFR (in the C8051F12x/13x it's at 0xB1 on all SFR pages) to control from which bank instructions and constants are fetched.

The two COBANK bits (5 and 4) select which of the four banks is used to fetch constant operands for MOVC and flash MOVX instructions.

The two IFBANK bits (1 and 0) select one of the four banks is used for fetching instruction opcodes

[gtackett]

Submitted PR #7320 for first round of work on CIP-51 support.