从今天开始记录自己的学习和工作总结，给自己开一个好头，今天晚上强迫着自己将8051那个项目又重新过了一遍，把后端大体的flow大致跑了一下，太久没有实践和反思了，从年前十二月份到现在三个月的时间过得浑浑噩噩的，前天痛下决心删游戏，戒烟戒酒，开始泡论坛学东西，坚持锻炼身体，今天在跑flow的时候本来没想着从头开始再做一遍的，本想借着去年十二月份的进度直接从routing开始走，无奈发现行不通，第一个就是群大在做的时候他读入的数据有些虽然修改了但是查看timing报告的时候经常出错，还有一个就是CTS这一块总有问题，于是乎又想着从时钟树综合那一块做起，这时却又发现人家在这两块分别采用了不同的floorplan，这才想起来前面做floorplan的时候打PG的时候由于电源线方向与SRAM内部pin脚的方向不一致会导致的那个问题，看来有问题还是不能推脱到以后解决，当天就得开始想办法，于是乎痛下决心从netlist开始做，才做到placement这一步抽取rc信息的时候就报错，提示scan_en这个port找不到其位置，抽取信息失败，首先查看input_data文件夹下的.v文件，发现综合出来的网表中是含有scan_en这个port的，为了彻底排除这方面的原因我又重新在dc里面综合了一下，结果还是报错，接着再仔细看icc中的log文件，发现做完floorplan和placement之后这个错误都没有出现，查看相应的timing信息都是可以的，说明icc在导入网表的时候并未提示这个错误，一直到时钟树综合的第一步抽取rc信息的时候才有这个问题，抽之前我source了两个脚本文件，第一个是库文件和sdc文件的脚本，source之后没有任何问题，而第二个是关于postCTS的相关设置，source这个文件就报错，错误应该出现在sdc约束文件这一块，打开该文件，发现在最后一行通过set analysis case的语句中func mode和scan mode居然都设置为0，目测应该是这一行导致scan_en这个端口在icc中产生了识别的错误，当时也没有深究，本着赶紧跑一下flow的心态，想了个简便方法就是直接删掉这两句话，读入一个不带scan_en端口的网表文件，果然抽取rc信息的时候这个错误消失了，不过在mmmc这里又出了问题，前面只设置一个scenario的时候CTS没有任何问题，可是添加多个scenario再跑的时候确只能够识别其中的两个，第五个scenario的sdcfile居然提示变量设置错误，先忽略这两个警告，一直跑到routing都是可以的，但是在查看clock tree时却提示时钟树并未综合，看来还是mmmc的设置有问题，明天有两个任务，第一就是在这个基础想解决mmmc中CTS的报错问题，第二个就是读入带有scan mode的网表文件重新跑flow，时间充裕的话可以做一下单scenario和多个scenario的对比。