基于IP核的PSTN短消息终端SoC软硬件协同设计

摘要 介绍在基于微控制器IP核的PSTN短消息终端SoC设计当中，如何合理划分硬件和软件的功能；从对微控制器IP核的配置与扩展、片上外设在SFR总线上的映射、存储空间的划分与映射等三个方面，详细讲述SoC的软硬件协同设计。

关键词 软硬件协同设计 IP核 SoC DW8051_core

1  概述

　　PSTN短消息终端SoC是为固定电话网短消息业务而设计的一种数字终端处理芯片。片上集成了微控制器、RAM、FSK/DTMF调制解调器、LCD接口、键盘扫描、数据存储器扩展页面寻址接口以及线路状态控制接口；可以完成FSK和DTMF格式的短消息上传、下传，CID（Calling Identity Delivery，主叫识别信息传送）号码的接收，振铃信号检测，话机状态控制等功能[1]，提供了PSTN短消息终端的单芯片解决方案。其中，使用了DW8051_core IP核作为SoC的微控制器核心。

　　SoC（System on chip，片上系统）不仅指它的硬件平台，还包括运行在其上的软件成分。如果系统采用全硬件设计的方案，优点是速度快、效率高，但是研制周期长，从而成本也高；用软件实现则更为灵活，研制周期短。缺点是速度慢，效率比较低。因此，SoC设计必须在硬件与软件功能划分上有一个合理的权衡，并进行协同设计[2]。

2  SoC系统任务的软硬件功能划分

　　系统任务按功能可以分为通信、人机交互、Flash存储器管理和外设管理四部分。通信的物理层功能即DTMF/FSK信号的调制解调，涉及插值、加权、相关等DSP运算。考虑到通信的实时性要求和所使用8位微控制器的数据处理能力，这些运算由专门设计的Modem硬件逻辑实现；而在数据链路层，比如建立和释放与服务器的连接、超时控制、接收FSK数据帧、拆包、差错控制、提取返回消息层的信息和相应标志位的建立等，都交给微处理器由软件实现。人机交互中的键盘扫描要不断判断是否有按键动作发生，用软件实现效率低，这里也用专门的硬件逻辑实现。其他人机交互功能，如菜单操作、短信编辑等，则都由软件实现。Flash存储器管理和外设管理在硬件提供了接口寄存器的情况下，由软件实现。

　　把实时性强、运算量大和重复性强的功能交给硬件去实现，然后在满足系统性能要求的情况下，把尽可能多的任务留给片上的微控制器用软件实现。这样降低了SoC的硬件复杂度以及制造成本，同时系统也可以获得最大的灵活性。

3  SoC的软硬件协同设计

3.1  对微控制器核的配置和扩展

　　DW8051_core是Synopsys公司提供的一个与8051指令兼容的8位微控制器IP核。它采用4个时钟周期为1个指令周期的模式，在时钟周期相同的情况下，处理能力是标准8051的3倍。DW8051_core访问程序存储器和数据存储器的MEM地址总线是16位总线，避免了传统8051结构中数据总线和地址总线低位的时分复用问题。

　　由于DW8051_core是一个IP软核（soft core），所以可以对它进行配置和扩展。在综合（synthesis）的时候，通过对参数文件的设置，可以选择配置内部RAM是128字节还是256字节；可以选择是否使用定时/计数器2，使用1个串口还是2个串口等。用户还可以按照DW8051_core手册的要求使用硬件描述语言编写硬件逻辑，扩展SFR总线和中断系统（最多可以扩展到13级中断）[3]。

　　在SoC设计中，只使用到了微控制器核的1个硬件定时器（Timer0），1个外部中断（Interrupt0），1个串行口（UART），并没有使用DW8051_core的全部功能。那些冗余的功能只会增加系统的硬件负担，所以按照最精简的原则配置DW8051_core：使用内部128字节RAM，不使用定时/计数器2，不使用内部ROM，只使用1个串口，不扩展中断。在DW8051_parameter.vhd文件中，作如下的参数设定[3]可以完成上述配置：

　　package DW8051_parameter is
constant ram_256 : integer := 0;
constant timer2 : integer := 0;
constant rom_addr_size : integer := 0;
constant serial : integer := 0;
constant extd_intr : integer := 0;
end DW8051_parameter;

　　SoC中的FSK/DTMF调制解调器、LCD接口、键盘扫描、数据存储器扩展页面寻址接口以及线路状态控制接口等，都作为片内外设连接在DW8051_core所特有的SFR内部总线上。8 KB的片上RAM和片外512 KB的Flash存储器AM29LV040都连接在DW8051_core的MEM总线上，如图1所示。

图1  经过扩展的DW8051_core SFR总线以及SoC系统结构

3.2  外设在SFR总线上的地址映射

　　DW8051_core通过SFR地址总线sfr_addr[0:7]，SFR读信号sfr_rd，SFR写信号sfr_wr，SFR数据输出总线sfr_data_out[0:7]，数据输入总线sfr_data_in[0:7]来访问映射到SFR总线上的片上外设。每一个外设都通过SFR地址映射成SFR总线上的一个寄存器，如图2所示。

　　对这些扩展SFR寄存器的访问和对普通寄存器的访问在形式上并没有区别。当应用程序使用Keil的C51编译器时，修改reg51.h文件可以让编译器确认用户所扩展的SFR寄存器。对扩展SFR外设地址的分配可以根据设计需要而不同，但是只能使用DW8051_core没有保留和占用的地址，否则会发生冲突。在reg51.h文件中添加以下语句让编译器确认扩展的寄存器：

　　sfr SEND_MODEM_DATA = 0xf1;/* 扩展，发送Modem数据，只写 */
sfr READ_FSK_DECODE = 0xf1;/* 扩展，读FSK解调数据，只读 */
sfr READ_DTMF_DECODE = 0xf2;/* 扩展，读DTMF解调数据，只读 */
sfr MODEM_STATUS = 0xf3;/* 扩展，Modem状态，只读 */
sfr MODEM_CTRL = 0xf2;/* 扩展，Modem控制，只写 */
sfr KEYPAD_VALUE = 0xf4;/* 扩展，读键盘值，只读 */
sfr FLASH_PAGE = 0xf5; /* 扩展，页面寻址，只写 */
sfr LCD_DATA = 0xf6; /* 扩展，LCD数据，读写 */
sfr LCD_CTRL = 0xf7; /* 扩展，LCD控制，只写 */
sfr CIRCUIT_STATUS = 0xff; /* 扩展，线路状态，只读 */
sfr CIRCUIT_CTRL = 0xff; /* 扩展，线路控制，只写 */

　　为了节约SFR总线地址资源，一些扩展的SFR寄存器在硬件上设计为只能写、不可读，另外一些被设计为只能读、不可写。这样，二者可以复用同一个SFR总线地址，比如MODEM_CTRL和READ_DTMF_DECODE寄存器；但是这样在需要先将那些“只写”寄存器的内容读出，运算后再进行写回操作的时候就很不方便。这里采用了镜像变量的方法，为每一个“只写”寄存器建立一个全局变量，每次写寄存器操作后，都对这个全局变量进行同样的写操作，时刻保持变量值和寄存器的内容一致，在需要读出的时候就使用此全局变量。MODEM_CTRL寄存器的bit0控制Modem是DTMF还是FSK模式。下面以对这一位的操作为例说明。

　　建立它的镜像全局变量：

　　unsigned char xdata modem_ctrl_mirror;

　　定义控制位：

　　#define MODEM_B0_MODE0x01// 1-DTMF, 0-FSK

图2  片上外设在SFR总线上的物理连接

　　设置Modem为FSK模式：

void Modem_SetMode_FSK() {
MODEM_CTRL = modem_ctrl_mirror & (~MODEM_B0_MODE);
modem_ctrl_mirror = modem_ctrl_mirror & (~MODEM_B0_MODE);
}

　　在初始化程序中对这些“只写”寄存器及其镜像全局变量进行赋值。

void DevicesInit() {
MODEM_CTRL = MODEM_CTRL_INI;
modem_ctrl_mirror = MODEM_CTRL_INI;
}

3.3  存储空间的划分和映射

　　在物理上，把8KB的片内RAM分为两部分，0000H～1BFFH（共7 KB）映射到数据空间，1C00H～1FFFH（共1 KB）映射到程序空间，并覆盖Flash中程序空间的1C00H～1FFFH区域；把512 KB的Flash存储器也分成两部分，00000H～0FFFFH（共64 KB）映射到程序空间，剩下的10000H～7FFFFH（共448 KB）都映射到数据空间。

　　对微控制器核来说，可以寻址64 KB的程序空间和64 KB的数据存储空间。对整个SoC而言，因为Flash中的程序空间有1 KB被RAM程序空间覆盖掉，所以逻辑上它的程序空间依然是64 KB，但数据空间变为7 KB＋448 KB，共455 KB。微控制器核通过扩展的SFR寄存器FLASH_PAGE按32 KB×16页的页面方式访问Flash存储器，其中包括程序空间和数据空间，如图3所示。

图3  程序空间和数据空间的划分和映射

　　在对Flash存储器件进行写操作后的某一段时间内（从几十μs～几百μs），对它进行读操作是不能读出一个确切值的，这是Flash存储器件的一个特性。本设计中程序和数据存放在同一个AM29LV040 Flash存储器中。在对Flash存储器进行写操作时，要不断地从其中读出进行写操作的程序指令，然后对它本身进行写操作。微控制器核在20 MHz的时钟频率下，指令周期大约是200 ns，即每隔200 ns左右，SoC就要从Flash存储器中读取一条指令。这显然和上述的Flash存储器特性发生了冲突。

　　通过对编译环境的设定，可以把进行写Flash操作的函数unsigned char WriteData_FLASH (unsigned char * dest, unsigned char *scr, unsigned int len) 和Flash扇区擦除函数unsigned char EraseSector_FLASH (unsigned char sector_index)定位到程序空间的1C00H～1FFFH，并备份到数据空间的0EC00H～0EFFFH。在应用程序的设备初始化函数void DevicesInit()中，调用加载函数void LoadFLASHOpToRAM()，把对Flash进行写或者擦除操作的这1KB的程序代码从Flash加载到RAM的程序空间。以后凡是涉及到对Flash的写或者擦除操作，都由硬件逻辑切换总线到RAM去执行这一段程序代码。这样，以不大的RAM开销，解决了不能同时对Flash进行读和写操作的矛盾。函数void LoadFLASHOpToRAM()的代码如下：

#define PROG_RAM_DATA0xEC00
#define PROG_RAM_DATA_PAGE9
static unsigned char xdata RAM_prog[1024] _at_ 0x1C00;
void LoadFLASHOpToRAM(){
unsigned char xdata * p;
FLASH_PAGE = PROG_RAM_DATA_PAGE;
p = (unsigned char xdata *)PROG_RAM_DATA;
memcpy(RAM_prog,p,1024);
}

4  总结

　　本文详细讲述了在基于微控制器IP核PSTN短消息终端SoC设计中软硬件协同设计的方法。在合理划分硬件和软件任务的基础上，使设计更好地达到了系统性能的要求。现在SoC已经在Xilinx VirtexII 2v1000 FPGA验证平台上顺利运行，并成功进行了和服务器的互联互通测试。