CPU接口-localbus调试

说在前面1：

作为CPU接口的一种，localbus相比于PCI、PCIe开发简单很多，只需要完成CPU内存地址与硬件寄存器/RAM地址的映射以及读/写信号，片选信号的时序，此次localbus的开发是硬件侧建立一个localbus工程辅助调试localbus驱动。

说在前面2：

硬件平台：AX7103；CPU平台：CT-p2020；驱动操作平台：vxworks

说在前面3：

硬件侧没有开发板与p2020 localbus的50pins直接相对接，而驱动侧需要开发、测试localbus驱动，因此需要创造调试环境，利用AX7103开发板的68个引脚，将localbus总线相关的关键引脚（37pins=16pins_addr+16pins_data+3pins_csn+1pin_oen+1pin_wen）以及中断信号定义到EX_IO1和EX_IO2上，再根据p2020原理图与接插件J5、J4相匹配，调试环境如下图1所示（略丑，只做原型功能验证）。图示J5为p2020接插件（localbus总线相关信号）；J4为p2020接插件（硬线中断、GND信号）；EX_IO1为localbus总线地址、片选和读写使能管脚；EX_IO2为数据、中断管脚。注意：两块开发板的电平标准要一致，否则不能通过杜邦线直连；另外建议两块开发板杜邦线共地相连。

图1 硬件板和CPU板实际调试环境

理论简介：

关于localbus的简介网上有参考价值的就是这个链接：https://wenku.baidu.com/view/aeca83593b3567ec102d8a80.html?from=search 因为局部总线简单，也没有什么可介绍的，理论部分就见链接，我这里就附上关键信号的读写时序图，如下图2，图3所示。同样的localbus接口在不同的CPU处理器地址和数据位宽不一致，信号也会有一些不一致，具体来说：BM3803中地址数据线未复用，数据位宽32bit（双字操作）；p2020中数据线LAD复用（通过LALE信号锁存高11bit的地址，如果只用16bit的地址时可以不接LALE），数据位宽16bit（双字节操作）。

信号	位宽	方向	说明
CE#	1	input	片选信号
OE#	1	input	读使能，低有效
WE#	1	input	写使能，低有效
Addr	27	input	寻址寄存器地址
Data	16	inout	CPU写入或读出FPGA的数据

图2 localbus读时序

图3 localbus写时序

调试历程：

调试伊始，通过p2020的原理图可以看出CS0和CS1分别给了内部的nand_flash以及nor_flash使用，另外输出3位的片选信号（CS2,CS3和CS4），说明最多可以挂8片局部总线外设，，这些外设（含*_flash）共用数据线、地址线以及读写使能。第一步就得先知道驱动使用了哪个片选信号，驱动也是摸索，驱动代码写着只使用了CS4，屏蔽了原来例程中的CS2，通过硬件侧抓cpu_csn[2:0]发现，cpu_csn[0]也会存在低片选状态，后经驱动修改，先保留使用CS2，这样驱动每次读写操作时都能触发“cpu_csn[2:0]==3'b110”。CPU板将对地址区间0xf1000_0000~0xf1000_ffff（128KB）进行读写操作时会拉低CS2，映射到硬件侧就是对寄存器/RAM的读写了。

测试写功能，在CPU启动后，驱动会給内存地址0xf100_0118处写16'h5555，如下图4所示，先给出写地址，然后拉低片选信号，几乎同时拉低了写使能信号，这样数据就从CPU写入到FPGA了。

图4 板级写时序

与写操作的简单相比，问题都出在了读操作，我们也同样地将AX7103和p2020的读使能线接好（地址、数据和片选信号先接好了），发现此时CPU不能启动了，但是将此信号接到未使用的EX_IO上时CPU可以正常启动，说明读使能信号干扰了CPU的启动，可是，cpu_oen和cpu_wen属性是一样的，input到FPGA内部，不存在输出到CPU导致不能启动，，，查看p2020的datasheet发现p2020上的LGPL2信号有两重定义：1.localbus的读使能cpu_oen；2.配合LBCTL、LALE信号配置e500核pll时钟占空比。怀疑是系统启动后短时间内FPGA侧的cpu_oen电平影响到CPU侧的LGPL2，为此，我们将读使能改为inout信号，在CPU启动后的10s内为高阻态，起着隔离作用，而10s后p2020的bootrom也加载差不多可以bootup了，然而实际测试下来的结果是CPU依旧不能正常启动。

我们把所有的杜邦线完全拔掉，只保留读使能线的连接，发现CPU可以正常启动，此时说明FPGA侧的读使能电平并没有影响到CPU侧的启动，为了具体定位到哪一个信号，我们再次基础上，把线一点一点接上去，最后接完了读使能线、写使能线，片选线以及地址线后，CPU板可以正常bootup而且FPGA能抓到正常的读写（只是看不到读写数据）时序，插上了数据线后发现CPU就不能启动了，至此，总算定位到问题出在哪了，为此，FPGA侧做了一个延迟处理，数据线一直处于20s的高阻态（此时CPU可以进行localbus写操作），等到bootup后，才使能数据的读出，这样处理其实很笨拙，但是确实能解决CPU不能正常启动的问题，可治标不治本/允悲/，毕竟刻意的延迟不靠谱。

//rst_done只有20s后才为1，在此之前cpu_data处于高阻
assign cpu_data  = ((cpu_oen==1'b0)&&(rst_done==1'b1)) ? cpu_rdata : 16'bz;
assign cpu_wdata = cpu_data ;

灵感一现。。。FPGA侧在“assign cpu_data  = (cpu_oen==1'b0) ? cpu_rdata : 16'bz;”只是多加了一条约束条件“(rst_done==1'b1)”就能让CPU启动，说明在CPU启动之初，cpu_oen满足低使能导致cpu_data有输出干扰到CPU侧的数据线，，，博客之初提及p2020内部还有nand_flash和nor_flash，在p2020启动的时候要从这些flash里读写数据，也拉低了cpu_oen，此时localbus读出的是默认值16'h0，而本应该从*_flash里读出一些有用的值被16'h0覆盖。为了验证这种猜想，我将数据信号的代码改为

//CPU只有片选了localbus后FPGA才会将cpu_rdata输出，否则高阻
assign cpu_data  = ((cpu_oen==1'b0)&&(cpu_csn[0]==1'b0)) ? cpu_rdata : 16'bz;
assign cpu_wdata = cpu_data ;

这样修改后CPU正常启动，因为p2020启动之初，会读*_flash，虽然拉低了cpu_oen，但是选通并非CS2，故此时FPGA的cpu_data保持高阻，直到片选成功且读使能低有效才将读数据输出。

调试总结：

耗时半周，终于调试完毕。定位问题比解决问题更耗时，有感。

排除法，一步一步定位问题。不排除还有点运气成分，hahah

/*************** ver 2.0 about interrupt added by LIUWF ***************/

       在调试完基本的数据读写功能后，需要调试硬线中断，FPGA开发板需要上传数据时通过中断告知CPU，由p2020原理图可以知道，除了irq3被占用，另外6个中断（irq0/1/2/4/5/6）可供外设使用，均在J4接插件位置处，，p2020内部中断有64类，外部中断有12类，我们调试中使用到的是外部中断irq1。

       硬线中断这块的调试主要是驱动修改内容，硬件配合抓信号。

       需要注意的是，下图是p2020 datasheet关于中断irq的描述为高时置中断，为低时不产生中断，，然而实际板级测试发现，irq为低时有效，产生硬线中断。

       当驱动收到中断后，需要对硬线中断进行复位，参考PCIe总线中INTa中断操作，我们定义0x110寄存器为中断寄存器，驱动往0x110写1在写0时硬件将硬线中断信号重新拉回高电平复位状态。

/**************************end for ver 2.0*********************************/