You are incorrect about the Cygnal Parts not having a bus. There a number of the parts that have something called the EMIF (External Memory InterFace). This interface directly supports the XRAM functionality (i.e. PDATA and XDATA / movx) type memory spaces. It does not support external program code (i.e. CODE / movc) space.

For example, on my current project I have a C8051F126 part with external 32Kx8 SRAM chip. The Cygnal EMIF on this part can be configured on a series pins of P0 -> P3 or on a series of pins of P4 -> P7. The four additional ports are available when you select the TQFP-100 package. The EMIF has the additional features it can be configured for 8 bit address. or 16 bit address in both multiplex or non-multiplex mode. On my design I used the non-muxed mode and so ports P5, P6, and P7 support linear address and data bus directly to the SRAM with no additional logic. A few of the upper bits of P4 support the RD/ and WR/ control lines.

The non multiplexed mode also supports a faster cycle time so that throughput to/from the SRAM can be better if you wanted to pay more money for the fastest possible SRAM.

Note that the EMIF also supports the PDATA type accesses to external RAM (via the MOVX @R0,A type instruction using a new special function register that is specifically used to hold the page address. This permits the use of a page pointer into a one block of XDATA whilest the DPTR can reference another area altogether. (On normal 8052's this mode of operation when the PDATA and XDATA accesses are mixed together it was necessary to keep updating the P2 port all the time before each MOVX @R0,A type instruction). On the Cygnal part this permits the program code to very efficiently support memory copies from one place to another, a job that other processor designers have addressed by having dual DPTRs.

Michael Karas