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的数据

CPU接口-localbus调试_第1张图片 图2 localbus读时序 CPU接口-localbus调试_第2张图片 图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了。

CPU接口-localbus调试_第3张图片 图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为低时有效,产生硬线中断。

CPU接口-localbus调试_第4张图片

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

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

 

你可能感兴趣的:(FPGA)