分享一点电路设计经验教训总结
时间：12-12
整理：3721RD
点击：
1. vdd stand-by 电流过大问题查找
1) rtl code的设计一般不会有问题,因为工具会将undriven的信号通过error报出来, 所以在工具跑流程时,不能轻易放过warning和error信息;
2)数模接口, hard block接口 以及memory接口处 ,要仔细检查;
3)用三态要甚重; 仿真过程中出现的三态以及undriven(黄色波形)和multi-driven(红色波行)都要仔细检查;
4)hard block以及memory spec要仔细阅读, 不能只看波形, 对时序一知半解就盲目感觉良好.
案例: vdd stand by电流问题查找过程
报出vdd stand by电流过大问题的时候指出三个方向,一是各人仔细检查stand by波形中各自模块中的信号, 对于非绿色的信号都要彻查; 二是数模接口仔细检查;
因为为了减小面积, memory新换的farady工具生成, 因此,我检查了RAM的控制信号后,发现在stand by模式下, OEB信号是有效的, 不知道这是否会导致memory漏电.因为bist电路测试结束后,只要bist_en还有效,双端口memory的两个output enable(OEA/OEB)就都是无效的, 因此,我就想通过在stand by程序中添加memory bist电路测试程序, 但是,结果却发现stand by电流反而变大了. 这样,就说明usbotg很可疑.
Umemory bist(VDD=1.621V)
不进行测试： 2.3mA
程序中操作memory bist 4.6mA
在stand by程序中分别添加了所有memory的bist测试, 最后发现, 只有MHA/USB的memroy bist测试过后, stand by电流会变大, 这就把问题锁定在双端口memory及其使用上.
具体实验现象如下:
仅打开usb out buffer（2k） bist enable：电流增大2mA；
仅打开 usb in buffer （4k） bist enable：电流增大1.7mA；
仅打开 MHA DPRAM（2.5k） bist enable： 电流增大3mA 多一点；
打开usb in、out buffer（2k＋4k）bist enable： 电流增大和略小于3.7mA；
所有memory的bist enable都关闭，standby电流大小4mA；
即打开bist enable，电流增加； 多个memory bist enable打开，电流增加越多，但是比分别打开单个memory bist enable电流增加之和稍小。
检查电路发现双端口memory的数据输出不是电平输出,而是三态的, 也就是说当OEA关闭无效时, QA是高阻的, 而QA又直接驱动memory bist测试电路中断NAND门, 这样,在stand by模式下,就存从vdd到GND的通路, 必然会出现较大漏电.
为了证实这一结论, 又做了一个实验证明. 即在scan mode(即testmode4模式下)模式下, NX管会断开,这样, 就可以断开NAND的直流通路.理论上电流就应该会减小.
在testmode4下测试stand by电流的操作过程如下: 先在正常功能模式下配置DSP， 然后将P_TEST接为1，然后驱动P_RESET产生四个下降沿，使IC进入scan mode，关断晶振，测得电流为200+ uA. 接近正常值.
与此同时送出去做红外照相的结果也同时显示, 在MHA和USB的双端口memory附近又发热点, 存在较大漏电.
2. 1) FPGA很害怕时钟经过组合逻辑门和分频电路: 时钟A经过组合逻辑门产生时钟B，实际ic中很容易保证AB时钟同步,而FPGA中这两个时钟之间有3ns甚至更多的latency都很正常. 另外,对于内部分频电路也是如此, FPGA中源时钟和产生时钟之间几乎不可能是同步的.
2) 当FPGA验证不稳定出错时, 如果用chip scope抓取内部波形还不能解决的话, 最终极的方法就是引尽可能多的debug信号线到pin脚上来, FPGA的pin脚绝对够用,可以随意发挥.
3) 我们要清楚FPGA验证的过程,方案以及FPGA操作过程中link/load等动作所对应的对实际验证板的操作.
案例:
项目中FPGA验证就很不稳定,因为模式众多,并且不同模式时钟会进行不同沿的选择等, 经常是调通了一个模式,另一个模式又不过了, 靠着不对再重新综合一版的随机方案, 过了FPGA验证, 但是很明显实质问题没有得到解决.
在项目中, 彻查了此问题. 我在FPGA验证代码中,添加了16*8根debug信号线,这几乎涵盖了模块中所有重要信号线. 最后针对出错情况,对pin上引出的debug信号线进行分析,最终发现问题在于:
在master_hs模式下，由于sck0t是由模式位选择了sck0_mux的正向或者反相，因此，sck0t相对于sck0_mux有4ns左右的延时，这样就导致由sck0_mux生成的发送移位寄存器使能信号sck_en_fall会错误的被sck0t早一个cycle采样到，于是导致发送的数据提前左移一位。最后的解决办法是：由于sck0_mux只用来触发了sck_en_fall一个寄存器，因此在该寄存器时钟端加两个buffer，保证与sck0t相位关系。
1) rtl code的设计一般不会有问题,因为工具会将undriven的信号通过error报出来, 所以在工具跑流程时,不能轻易放过warning和error信息;
2)数模接口, hard block接口 以及memory接口处 ,要仔细检查;
3)用三态要甚重; 仿真过程中出现的三态以及undriven(黄色波形)和multi-driven(红色波行)都要仔细检查;
4)hard block以及memory spec要仔细阅读, 不能只看波形, 对时序一知半解就盲目感觉良好.
案例: vdd stand by电流问题查找过程
报出vdd stand by电流过大问题的时候指出三个方向,一是各人仔细检查stand by波形中各自模块中的信号, 对于非绿色的信号都要彻查; 二是数模接口仔细检查;
因为为了减小面积, memory新换的farady工具生成, 因此,我检查了RAM的控制信号后,发现在stand by模式下, OEB信号是有效的, 不知道这是否会导致memory漏电.因为bist电路测试结束后,只要bist_en还有效,双端口memory的两个output enable(OEA/OEB)就都是无效的, 因此,我就想通过在stand by程序中添加memory bist电路测试程序, 但是,结果却发现stand by电流反而变大了. 这样,就说明usbotg很可疑.
Umemory bist(VDD=1.621V)
不进行测试： 2.3mA
程序中操作memory bist 4.6mA
在stand by程序中分别添加了所有memory的bist测试, 最后发现, 只有MHA/USB的memroy bist测试过后, stand by电流会变大, 这就把问题锁定在双端口memory及其使用上.
具体实验现象如下:
仅打开usb out buffer（2k） bist enable：电流增大2mA；
仅打开 usb in buffer （4k） bist enable：电流增大1.7mA；
仅打开 MHA DPRAM（2.5k） bist enable： 电流增大3mA 多一点；
打开usb in、out buffer（2k＋4k）bist enable： 电流增大和略小于3.7mA；
所有memory的bist enable都关闭，standby电流大小4mA；
即打开bist enable，电流增加； 多个memory bist enable打开，电流增加越多，但是比分别打开单个memory bist enable电流增加之和稍小。
检查电路发现双端口memory的数据输出不是电平输出,而是三态的, 也就是说当OEA关闭无效时, QA是高阻的, 而QA又直接驱动memory bist测试电路中断NAND门, 这样,在stand by模式下,就存从vdd到GND的通路, 必然会出现较大漏电.
为了证实这一结论, 又做了一个实验证明. 即在scan mode(即testmode4模式下)模式下, NX管会断开,这样, 就可以断开NAND的直流通路.理论上电流就应该会减小.
在testmode4下测试stand by电流的操作过程如下: 先在正常功能模式下配置DSP， 然后将P_TEST接为1，然后驱动P_RESET产生四个下降沿，使IC进入scan mode，关断晶振，测得电流为200+ uA. 接近正常值.
与此同时送出去做红外照相的结果也同时显示, 在MHA和USB的双端口memory附近又发热点, 存在较大漏电.
2. 1) FPGA很害怕时钟经过组合逻辑门和分频电路: 时钟A经过组合逻辑门产生时钟B，实际ic中很容易保证AB时钟同步,而FPGA中这两个时钟之间有3ns甚至更多的latency都很正常. 另外,对于内部分频电路也是如此, FPGA中源时钟和产生时钟之间几乎不可能是同步的.
2) 当FPGA验证不稳定出错时, 如果用chip scope抓取内部波形还不能解决的话, 最终极的方法就是引尽可能多的debug信号线到pin脚上来, FPGA的pin脚绝对够用,可以随意发挥.
3) 我们要清楚FPGA验证的过程,方案以及FPGA操作过程中link/load等动作所对应的对实际验证板的操作.
案例:
项目中FPGA验证就很不稳定,因为模式众多,并且不同模式时钟会进行不同沿的选择等, 经常是调通了一个模式,另一个模式又不过了, 靠着不对再重新综合一版的随机方案, 过了FPGA验证, 但是很明显实质问题没有得到解决.
在项目中, 彻查了此问题. 我在FPGA验证代码中,添加了16*8根debug信号线,这几乎涵盖了模块中所有重要信号线. 最后针对出错情况,对pin上引出的debug信号线进行分析,最终发现问题在于:
在master_hs模式下，由于sck0t是由模式位选择了sck0_mux的正向或者反相，因此，sck0t相对于sck0_mux有4ns左右的延时，这样就导致由sck0_mux生成的发送移位寄存器使能信号sck_en_fall会错误的被sck0t早一个cycle采样到，于是导致发送的数据提前左移一位。最后的解决办法是：由于sck0_mux只用来触发了sck_en_fall一个寄存器，因此在该寄存器时钟端加两个buffer，保证与sck0t相位关系。