把supra分解后获取bin单独调用
然后用脚本搭建了windows下的命令行环境,包括fitter和downloader,一键产生bit file(bin)和一键下载。fitting成功,download过程出现校准片内硅振荡器出现错误,何解?
最近编辑记录 aquasnake (2024-03-25 18:07:17)
离线
我测试了下极限fitting利用率是89%,基本上大概是在1890个LUTs,我跑了上百次,只要综合产生的LUT超过189x,基本上fitter就跑不出来。
因此大致情况下稳定跑出来基本控制利用率在89%以下,当然我还是用的几个月前的fitter,如果是近一两个月supra下的fitter,更难跑出来,效率更降低了。因此我建议不要盲目跟随原厂升级tools,如果你以前做的稳定的项目,非必要不要升级
离线
似乎已经下载成功
openocd能获取到device id,基本可以认为已经可以通过swd访问到芯片
离线
目前我只能用到89%,一旦资源用到超过1890 LUTs,fitter就跑不出来。不清楚是不是工具限制了产生bin的size大小还是其他什么。mcu的firmware分配到内部flash是从低到高,cpld的bit bin是高空间活动分配(起始地址0x800fffff - cpld bin size),中间必然有一个分界,可能是内部flash不够多,只能限制了size,因此也限制了cpld的充分使用,不知道某些具有更多内部flash容量的rv2k是不是这种情况
最近编辑记录 aquasnake (2024-03-26 09:33:24)
离线
目前 agm尚且还需要altera环境,来注入外挂脚本利用quartus ii产生网表,这部分无法自动化,其他我都实现了一键批处理
离线
int OSC calibration失败的原因已经解决,对Jlink-OB下载线的vcc 3.3v供电很敏感. 偏差0.5V都不行。
我因为通常习惯在jtag调试器对target板供电为了防止反向灌流加个二极管,由此导致了vcc的压降,造成校准失败。
虽然我已经让校准通过,但是我对校准精度不报大的期望,当然,这个内部晶体时钟我只用来对信号延迟计数用,并不涉及其他,请不要学我,我任何时候都是把器件用到很抠门的地步,能省一颗料则省。
最后还是希望agm在这里对内部晶体供电做一个补偿,是否考虑内部供电统一安排到2.5v vcc(vddio除外),以便当用户在使用欠压下载线的时候能够保证内部晶体的稳定
最近编辑记录 aquasnake (2024-03-27 10:48:20)
离线
由于calibration内部晶体用的电压和目标板stand alone工作时的电压可能有偏差,因此校准到的晶体输出频率不等于实际工作时候的频率,由此可以推断,必须保证下载线输出3.3V和板子实际工作后的VCC尽可能地保持一致
同时,猜测AGRV2K内部甚至没有LDO对这个int OSC供电,而是直接跟随系统VCC 3.3V
l
离线
fitter效率突破不了90%上限的问题,可能是无法解决的,我试图编辑.qsf文件的约束参数也没有什么优化,基本上原厂提供的配置就已经到达极限了。 也并非的工具的问题,我发现agm用的约束参数就是quartus ii兼容的(这里面很奥妙),cyclone 4架构或许就是需要剩余一部分面积才能布局布线走出来,而阉割到2K或许无法保证剩下的10%的面积连成一片,零散的10%的面积或许就是无法利用起来的,甚至无法插入一个锁存/触发模块
基于LUT结构的FPGA,Verilog代码需要写的尽量对称,所谓对称,就是if或者case语句内尽量具有相同的表达式结构,越对称,便于合并相同逻辑,综合的效率越高。同时尽量把case的所有分支都填充满,条件越详细,反而综合后分配的LUT越少。
虽然fitter的优化约束无法扣出资源,但是在综合这个步骤,通过改写代码,统一表达式结构,同样扣掉了几十个LUT出来,以前我做IC设计bring up时候的痛苦回忆又回来了,要跑通一个优化的配置,可能需要跑上百次verification. 通常效率最高的时候是在半夜,这个时候没有人和你争服务器job现程。而在白天,比如在一间科技公司,几百号人争夺代码服务器上的cpu资源,通常很难跑的快
最近编辑记录 aquasnake (2024-03-29 23:24:11)
离线
agm的toolchain其实是属于外挂,对quartus ii做了一定程度的注入,migration以后产生的quartus ii的工程文件,然后就是利用quartus ii综合,此时需要运行agm的外挂脚本(af_quartus.tcl),脚本中把综合的约束条件自动注入综合器(它会覆盖原始quartus ii中的综合setting优化设置),产生网表
然后执行agm的fitter(af.exe)去布局布线,此时注入fitter的约束条件,同时根据.ve的pin脚分配产生bin。
在利用quartus ii做综合的的时候,一旦运行了agm的脚本,如果再次去修改ide的全局综合优化设置,就会改变外挂之前设置好的参数,所以,一旦运行脚本(af_quartus.tcl)后,就不建议去做其他setting修改,这会导致产生一些非预期的问题,唯一能做的就是点箭头start compilation
如果你在次过程中,不慎修改了setting,那么最好还是再次运行一下外挂脚本(af_quartus.tcl)
由于是外挂,因此步骤上是必须严格按照顺序的,点错了,或者中间修改了ide设置,都有可能破坏注入参数
离线
仅仅是引脚更改,那么其实不用在quartus ii里面做编译,只需要修改.ve文件,然后再次执行af.exe就可以了。
我直接是把fitting, downloading写成了脚本一键运行, 因为fitting有时候跑一次跑不出来,会error,要多跑一次才会顺利通过,因此一键运行加速了我开发的时间,这样我完全抛弃了supra前端
最近编辑记录 aquasnake (2024-04-01 10:58:11)
离线
@jiaowoxiaolu
因为控制字写在 ur_project.qsf文件中,这个文件其实也是一个脚本,会被af.exe调用
然而约束控制字都是altera的东西,你甚至可以在altera的工程目录下找到类似的.qsf文件,然后把需要约束的管脚配置字,摘抄过来
为什么agm不公开这些?因为这些东西是altera/intel的,quartus ii中用户不必关心.qsf文件,直接在assignment editor中有配置,配置完毕后会自动更新.qsf。而在agm中,是直接编辑这个.qsf文件。
我一开始也尝试去向供应商询问这些东西,但是基于某些原因,没有获得我需要的解答,因此都是自己慢慢啃生肉。当然,在此过程中已经了解为什么会不解答这些技术问题。因为这涉及到agm对altera的软硬件做了什么的问题,这些问题是不方便原厂自己公开释放的
最近编辑记录 aquasnake (2024-04-03 19:28:43)
离线
用开源的综合器裸奔,就不能用quartus ii里面MegaWizard IP的东西了,这些都是绑定到IDE的闭源IP库。除非你用你自己反向出来这些模块并以代码方式嵌入到你自己的项目
离线
片上振荡器是精度5%??
而且RC振荡器在上电起振有一段时间的预热时间才能稳定。 如果这个预热稳定时间,大于系统RESET时间,而且又用这个片上振荡器作为信号整形、延迟或者分频等精确用途的话,比较难以搞定。
但是系统reset时间又不能做太长,这是cpld,不是单片机,需要瞬时启动特性。我在尝试如何把这个5%精度又需要上电时间的黑科技玩起来用来代替真正的外部时钟源
最近编辑记录 aquasnake (2024-05-11 11:32:56)
离线
如果用开源的综合器产生网表,那么要做的事情很多,需要手动写 *asf
先借用quartus ii跑一遍,跑之前先assignment editor配置好虚拟的管脚约束,然后点af_quartus.tcl运行产生网表,以及altera的*.qsf文件。然后跑一次fitter,会自动将altera的*.qsf迁徙到AGM的 .\alta_db\alta.aqf, .\alta_db\alta.asf
但是,这两个约束并不是最终的,最后,将ur_project.asf里面的设置再次覆盖,所有的参数都是altera quartus ii里面的,因为他这个fitter是衔接quartus ii的。
假设用第三方开源的综合器产生网表,但是这些文件并不会导出,也不会是quartus ii的参数,因此会出现丢失pin脚约束和其他全局约束的情况。fitter还是会调用 .\alta_db\alta.aqf, .\alta_db\alta.asf 去约束,而这几个都是quartus ii环境下的,它与quartus ii强耦合
最乐观的情况是你上次成功编译后管脚约束是正确的,你又会手动编辑ur_project.asf。而且你的项目对于pin脚约束(上拉,OD,驱动力,滞回,延迟微调整等)不敏感
离线
切记一定要用商用IDE,不要用开源的东西。开源的东西不成熟,要把开源的搭建成可以商用的程度,差不多就是搭建环境,这需要一个TEAM的人力,少说也要3个人一个月的高强度工作。
或者是,一个人单独磨半年1年,搞出一套环境,当然搞出了这套环境你也只能自己用。自己一个人做点别人搞不了,不屑于搞的东西,而且原厂又不知道。
离线
其实调用 quartus综合也可以一键批处理化
新建一个文本文档改后缀为bat文件,里面是
path = path;C:\altera\13.1\quartus\bin64
quartus_sh -t af_quartus.tcl
pause
这样就可以了。前提是先安装quartus II 13.0或者13.1
然后观察.\simulation\modelsim目录下是否产生了最新修改时间的.vo文件,有则是综合通过。
但是综合用批处理比较不直观,不能看到到底占用了大致多少的芯片资源(LUT),不适合在开发中使用,用来出版本合适。如果是前期代码编译开发,还是开quartus IDE界面比较好。
但是在fitting的过程中,会有资源占用比例显示出来,其实显示资源占用比放在综合脚本里面显示比较人性化
写脚本的方便之处是缩短了编译时间,也不用手动去选.tcl脚本,防止点错脚本。这样一键傻瓜操作,加速了对工具使用的适应磨合时间(大多数开发者,开发一个新项目开始,几乎要占用3-7天搭建环境,适应环境,并琢磨出一套开发流程,直接命令行的调用环境效率提升很明显)
最近编辑记录 aquasnake (2024-05-13 14:31:36)
离线
我看了几个例程,就是学生作品,把实际的物理管脚直接写到了verilog模块里面的输入输出IO上了。
这种写法,不具有模块化,耦合很强,移植需要改写很多文件。
当把IO替换成自定义信号后,fitter就丢失了管脚分配。但是fitter不会强制出错,会给你默认按管脚顺序分配,只给出warning,会顺利产生bin,当你用这个bin烧写到片子里面,管脚定义是不对的,上去很容易烧片子。(废话,假设输入被定义到输出,不就io大电流了) 这很危险。
我彻底改写了框架,要么自己写一个AGRV2KLxxx.pinmap映射表让脚本产生正确的管脚分配,要么直接粗暴地在.asf文件中定义管脚。因为.pinmap文件也只是管脚映射,没有其他上下拉,驱动力等的设置,最终也是要看.asf文件。
至于.ve,实际没有多大用处,可能对于MCU的代码有意义,类似一个define,但是管脚分配在AGM内部,尽然涉及到了3个地方(.ve,.pinmap,.asf),拉扯到最后甚至绝大多数用户都不知道怎么定义管脚!
最近编辑记录 aquasnake (2024-05-14 15:21:34)
离线
注意,仅仅是写了.ve文件中的管脚映射,也是不会导入到fitter控制中去的。
在"af_prepare.tc"中:
### Run Compile ###
set PIN_MAP "__device_pinmap__"
set VE_FILE "__ve_file__"
if { [file exists $VE_FILE] && [file exist $PIN_MAP] } {
以上必须满足同时有.ve文件和.pinmap文件才能产生正确的.pre.asf
遗憾的是,SDK里面并没有给你包含AGRV2KLxxx.pinmap文件,这个脚本非常罗嗦,绕了一大圈最终有.asf控制,什么pre.asf都是中间临时脚本,最后统一被.asf覆盖。
而且完全可以删除xxxx.pinmap这些文件,也就是说,不管quartus ii里面的逻辑管脚映射如何,都没有意义,最后物理分配看.asf文件。甚至删除了pinmap文件还更有好处,我不需要先在quartus里面对着一个模型bga封装去虚拟分配管脚了,哪怕它是空的,也完全没有关系,彻底把管教配置和quartus剥离干净
离线
RV2K的sdk实际上对于端口配置做的一点比较复杂的自动化代码。
先是用python脚本,把项目的verilog代码做了一次再封装,产生一个更高级别的顶层接口,然后把管脚定义在这个顶层接口了(我非常反对这种做法,理由下面会分析)。
接口封装了CPLD和MCU衔接的AHB总线以及DMA和他们之间的握手信号。到此为止是很好的,但是把PIN脚映射再次封装成一个更高级别顶层。这虽然解决了PIN脚配置问题,但是造成了另一个问题:
比如我换了项目的PIN脚定义,我不能简单地修改.ve,因为fitter不看.ve。你必须要重新跑一遍gen_vlog脚本产生顶层接口,然后再次重新编译项目,包括综合和布局布线全部都重来一遍!
我在想把PIN脚映射从gen_vlog剥离,直接自动化代码产生在.asf文件中,这样更改pin脚定义就不需要重编了,只让fitter看.asf就好了
很多用户在需要改pin脚的时候,都会误以为只需要改.ve文件就好了,最多重新跑一下全编。但是不行!你必须重新做初始化产生自动化代码,必须要跑gen_vlog。而gen_vlog这个环境配置,需要你重新建立一个工程,quartus工程.qpf重新产生后某些配置你必须重新再次设置(类似项目代码需要重新添加,设定verilog版本标准,再次配置仿真工具等)。尤其在类似PIO这种集成环境里面,会搞的更繁琐。我的做法是直接把gen_vlog调用写成批处理一键运行重新NEW一把。
当然,最彻底的改进是不要把pin脚映射做成顶层接口,而是让脚本自动产生.asf文件
最近编辑记录 aquasnake (2024-05-16 08:51:56)
离线
fitter效率90%的问题再次跟踪
修改两个地方
1, gen_batch脚本中找到以下这行:
logic_compress = (logic_size < (0xa000-LOGIC_ALGO_SIZE))
修改为
logic_compress = (logic_size < (0xb000-LOGIC_ALGO_SIZE))
2, af_run.tcl文件中找到以下这行:
--logic-address 0x80007000\
修改为
--logic-address 0x80006000\
以上给CPLD bin空间多分配4K以充分使用CPLD
原因是脚本限制了cpld bin size,而且脚本默认是产生加密bin,加密bin需要更多的size。如果不改,当cpld使用到超过90%就会bin超标,窗口会显示error,但是仍然生成bin。而这个超标的bin写到片子里面肯定是无法工作的
最近编辑记录 aquasnake (2024-05-18 09:14:07)
离线
AGM RV2K? 紫光PGC2K?高云Tang Nano 4K? 同台竞技
这三个都是6K LUT以下基于片上flash配置的瞬时启动CPLD的同一性能档次。
从易用性,开发友好度来说,PGC2K ~= Tang Nano 4K > RV2K
从市场采购渠道来说 RV2K >> PGC2K ~= Tang Nano
从toolchain的定制性,做差异化挖掘技术深度来说 AGM的工具简直就是Hacker最喜欢的,它等于50%皮角了quartus,而且是以命令行方式,可以集成进不同项目脚本
另外两家用的是Lattice类似的IDE,从管脚分配模块界面上可以很容易感受到Lattice的风格,完善度做的比较好,前期开发比AGM友好。
紫光预测市场化应该要比高云做的出色,高云很难真正把基于lattice的方案替换掉
离线
关于RV2K能否只用CPLD的讨论
最早我问代理,给于的回复是完全可以拿它当一个纯CPLD来用。不过我总觉得似乎必须要带上片上总线AHB,即使不连接MCU不做任何事情。
在自己的项目模块中加入一坨:
`ifdef AGM_RV2K
input sys_clock,
input bus_clock,
input resetn,
input stop,
input [1:0] mem_ahb_htrans,
input mem_ahb_hready,
input mem_ahb_hwrite,
input [31:0] mem_ahb_haddr,
input [2:0] mem_ahb_hsize,
input [2:0] mem_ahb_hburst,
input [31:0] mem_ahb_hwdata,
output mem_ahb_hreadyout,
output mem_ahb_hresp,
output [31:0] mem_ahb_hrdata,
output slave_ahb_hsel,
output tri1 slave_ahb_hready,
input slave_ahb_hreadyout,
output [1:0] slave_ahb_htrans,
output [2:0] slave_ahb_hsize,
output [2:0] slave_ahb_hburst,
output slave_ahb_hwrite,
output [31:0] slave_ahb_haddr,
output [31:0] slave_ahb_hwdata,
input slave_ahb_hresp,
input [31:0] slave_ahb_hrdata,
output [3:0] ext_dma_DMACBREQ,
output [3:0] ext_dma_DMACLBREQ,
output [3:0] ext_dma_DMACSREQ,
output [3:0] ext_dma_DMACLSREQ,
input [3:0] ext_dma_DMACCLR,
input [3:0] ext_dma_DMACTC,
output [3:0] local_int,
`ifdef INT_OSC_SUPPORT
input int_clk,
`endif
`endif
然后还必须定义AHB总线待机
`ifdef AGM_RV2K
assign mem_ahb_hreadyout = 1'b1;
assign slave_ahb_hready = 1'b1;
`endif
AHB这两个信号在内部片上总线结点必须设置为高,如果不定义,悬空或者为0都将FIT不过。why? 为什么不设计的时候内部直接weak pull-up??
不知道有谁完全不带AHB就正常当cpld使用并调通的?
最近编辑记录 aquasnake (2024-05-18 13:51:36)
离线
HSI 不准的问题. 5%都是乐观的,实际使用高低温极限测试估计有15%温漂.
不过我可以忍受20%的偏差. VE里面定义主频乘以一个偏差系数补偿一下:
SYSCLK 120 # x 1.2, ie 100->120, 200->240
PLL_CLKIN PIN_OSC
注意,如果使用内部rc振荡器,不要把32vf407的SYSCLK定义到超过240(实际跑在200m), 由于偏差一致性不好,频率不要跑高, 建议定义个低于200的数值.(省成本,就必须牺牲性能,不要跑极限了)
而且代码里面开机初始化时最好做一段时间延时等待warm up
最近编辑记录 aquasnake (2024-05-22 13:13:20)
离线
纯可编程逻辑部分开发,如果使用到内部晶体,必须要挂载PLL库,这个pll库是需要自动化脚本产生的,而产生这个脚本,依赖于ve和SDK里面的脚本,SUPRA缺失这几个脚本.然后还要移植到SUPRA环境下的命令行调用.
单纯migrate后只能产生一个空的顶层接口. 只有用自动化脚本产生,才能把alta_sim.v这个底层接口挂载进项目中,并自动生成包含AHB总线的顶层接口.
除非用外部有源晶振或者项目不需要SYSCLK时钟,那么才能剥离alta_sim.v(??没有尝试过,理论可行),否则都是按MCU+CPLD的开发流程走.
最近编辑记录 aquasnake (2024-05-22 13:25:04)
离线
关于cpld端获取不到sys_clk的问题
在自动生成的顶层verilog代码中,定义了以下接口:
alta_gclksw gclksw_inst (
.resetn(sys_resetn),
.ena (1'b1),
.clkin0(PIN_HSI_in),
.clkin1(PIN_HSE_in),
.clkin2(PLL_CLKOUT[0]),
.clkin3(),
.select(sys_ctrl_clkSource),
.clkout(sys_clk));
这个接口的功能是系统时钟选择. 主要看输入项参数sys_ctrl_clkSource决定
在alta_sim.v中:
assign sys_ctrl_clkSource = {2{sys_ctrl_pllReady}};
意思是无论如何,只会选择2'b00或2'b11,即clkin0或clkin3. 以PLL锁定输出信号决定.
实际上正常工作应该选择到clkin2(PLL_CLKOUT[0]),由此cpld获取不到正常的sys_clk
应该改写为以下:
assign sys_ctrl_clkSource = {sys_ctrl_pllReady, 1'b0};
离线
看起来fitter无法使用altclkctrl这个ip库,只能单时钟。这样就需要自己写多时钟切换代码。
逻辑很简单,在pll没有lock之前,使用HSI时钟,等PLL LOCK后,使用变频后的时钟。
自己写比较麻烦,简单的multi-plexer会有switchover glitch,一般用需要等pll lock后再加几个clock然后才能保证避免这个glitch。目前我的系统作为从设备需要检测master一个时钟输出6个clock后就要响应。
或者永远不要等PLL LOCK信号,哪怕PLL变频后一开始一段不稳定,也接受,也不切换,直接使用PLL输出,这样CPLD可以加快PLL上电瞬时性
离线
POR与GSR设计
POR上电即是设置的默认值,判断芯片第一次上电,可以通过读altpll这个硬IP的.locked输出信号获取状态。但是cpld无法得知硬件脚nRST的此刻状态,很可能PLL输出已经locked置位,但是MCU的nRST还没有为1(尤其是nRST脚并联一个电容的情况下)。因此,需要MCU里面boot代码开始对某个地址寄存器写状态位给CPLD。CPLD读这个寄存器(RAM)获取。
GSR仅是针对CPLD的,低有效,一旦为低,CPLD寄存器全部恢复为初始态。
AGRV2K似乎并没有GSR控制脚。因此可能需要设计一个input脚然后另写reset process block。这将降低实际CPLD的使用效率(额外占用LUTs)。
AGRV2K并不如MAX II/V以及MACH XO2好用。尤其要判断第一次上电以及已经上电后再次reset的不同状态的应用情况下,AGRV2K要写更多的初始化代码。
离线
换一个超低压降ldo,或许对校准精度有惊喜。
现在我不用改电路了。:)
离线
aquasnake 说:换一个超低压降ldo,或许对校准精度有惊喜。
现在我不用改电路了。:)
为什么还要低压降啊?
官方建议3.3V后面接一个功率磁珠。我的供电是5V,然后我校准供电在ldo之前,但是jlink输出电压3.3V.这样经过一个ldo的压降就满足不了校准的需求,神奇的是除了校准,下载其他都是无问题的。
如果改板,把校准输入电压接到LDO后端,就可以了。但是这个时候,必须要保证板子不能供电。但是校准电压vcc不一定是实际工作时候的vcc.也就是说,校准相对不准。
如果改JLINK,输出5V,就不需要改板了。直接接到LDO前端,这个对校准还有好处,就是校准电压vcc就是实际工作时候的vcc。
不改JLINK,不改板,只替换ldo用超低压降的(vdrop min 0.2V),就能直接兼顾3.3V输入和5V输入。在 3.3V JLINK供电连接下,虽然处于LDO吃不饱状态,但是只要过OSC校准和下载即可。实际工作是输入5V
这就是超低压降LDO的实际作用。
离线
Quartus的ip库能用么 比如生成个fifo啥的 supra的ip太少了
有两个ip可以直接兼容
altpll clkctrl
例化调用或者直接调用原语都可以
其他的估计不行,fifo要用agm的bram去做
这玩意2K LUT,其实你不能当他个fpga用,用起来比较晦涩
不要把它用去做通信数字编解码用,还是做做低级的吧。
离线
接下来说说agrv2k最大的开发环境上的坑
1。PL部分没有自己的IDE,交叉使用supra和quartus,会丢失大量的初级用户,尤其是高等院校学生以及创业公司选用的考虑。虽然个别钉子户老顽固和开源社区是很喜欢这种基于命令行的toolchain的。此处评估拒绝了市场1/3的新进客户。
2。PS开发选用的platformIO,不得不说,这绝对是对于客户而言最失望的开发环境。而且对操作系统耦合极其强,要求win10之后。此处评估拒绝市场1/2的客户。甚至platformIO插件的安装文件夹还随时在被监视,一旦发现被修改,远程即强制你更新(重新安装,而且一更新安装即是1小时!除了360,我从未见过如此厚颜无耻之徒! 这也就是为什么PIO要求有最高Admin管理员账户权限的原因!很符合流氓特征)。虽然vscode+platformio界面看似很fashion,但是我却完全鄙视,又臭又长的东西。哪怕是cmake都要比之好10倍,更不用说keil以及其他针对嵌入式mcu的IDE了。
3。python选用版本过高,越高的python版本,意味着对windows的版本选择面越窄。虽然github上有针对win7(及以前)OS的皮角兼容DLL(呵呵,这个皮脚库其实某为内部也在用),但是对于新进客户,这将强制他们电脑系统升级到WIN10以后,在一些中大型企业中,这是绝对不能接受的!结合2,此处评估再次拒绝市场1/4的客户(尤其是大客户)
最终客户接受率估计:2/3 * 1/2 * 3/4 = 1/4
这也就是为什么我一开始就下决心要抽取SUPRA,弃用PlatformIO,自己造轮子搭建Toolchain的初衷。supra很符合开源精神,bin文件夹内的exe都可以命令行调用。PlatformIO虽然源自于开源社区,但是走在背离开源的路上(无责任猜测可能M$有背后塞金资助了,而且强推的很厉害,甚至连一些培训机构也在推广).y有时候,我仅仅需要一个轻量级别的,跨操作系统(以及跨版本的),可裁减自由定制的,拥有充分脚本扩展性和编译控制的非集成开发环境。
最近编辑记录 aquasnake (2024-06-23 22:40:43)
离线
AGRV2K是块好肉,只是原厂厨师烹饪出来的口味,有点怪;)
离线
RV2K到底能不能支持open-drain输出配置?
在Supra\etc\__design__.qsf中
修改这一行set_global_assignment -name AUTO_OPEN_DRAIN_PINS OFF,将OFF改为ON
在Supra\etc\af_quartus.qsf中
增加这一行set_global_assignment -name AUTO_OPEN_DRAIN_PINS ON
重新生成项目文件,重新跑综合和布局布线
成功生成top.bin后,打开.\alta_db\alta.asf
可以看到部分OUTPUT PIN已经被设置成OD门了
前提是,因为他是自动根据综合器网表来生成的,所以Verilog代码里面,要将OD输出的PIN的高电平,写做"Z",这样配合上拉,即可以认为是1,但是功耗会比直接输出1小的多(如果前后级电平之间有压差的话),而且系统抗ESD性能也会略好些。
OD输出配合内部弱上拉,将可以有效降低系统的静态功耗,以及减少总线冲突。一般用于总线上存在两个或以上的驱动源,以及总线前后级(源端到目的端)IO电平有压差的情况下。
最近编辑记录 aquasnake (2024-06-30 15:45:32)
离线
还有一个告诉fitter配置成OD输出口的约束
在.ve里面,logic配置output(或inout)口后面加限定!PIN_xx_out_data
这个方法我还没有检验,这个是直接把io的输出口的上mos管直接干掉,不管你verilog怎么写,哪怕你写了输出1,这么干了以后,输出1等于Z,同样,如果驱动脚外面没有上拉电阻的话,内部最好配置弱上拉,因为Z的作用,其实是降功耗,而不是意图让后级或总线电平悬空。
公开release版本的supra或者AgRV_pio SDK,在默认全局约束(__design__.qsf)里面还有一些需要客户根据自己项目修改的,按照官方release出来的设置,产生的自动化quartus项目,跑出来部分管脚是不可使用的
离线
RV2K到底能不能支持weak pull-up端口IO配置?
在logic_design.asf(默认top.asf文件)中把需要的pin脚设置上拉
set_instance_assignment -name WEAK_PULL_UP_RESISTOR ON -to PIN_xx
然后重新全部跑一遍logic的综合和fitter
下载后实际开机运行结果并没有上拉
在.\Supra\etc\af_quartus.qsf中开放全局上拉设置
set_global_assignment -name WEAK_PULL_UP_RESISTOR ON
然后重新全部跑一遍logic的综合和fitter
下载后实际开机运行结果还是并没有上拉
代码都是原来跑在altera max II系列上的同样代码
由此,我怀疑,RV2K的fitter是否真正能配置weak pull-up?
最近编辑记录 aquasnake (2024-07-04 16:42:05)
离线
为什么无法定义pin脚输出z的猜测
我试验了在我项目module里对一个output变量直接赋值z,传递到顶层相应pin脚是可以的。
但是如果写的复杂点,对这个output写一个判断的逻辑,例如a = b ? 1'b0 : 1'bz;
然后top里面对这个module调用,参数传递过去后逻辑就改变了。
原则上综合器并不会接受这种写法,固定的z能传递只是因为是固定值z,综合器把一个wire型变量赋值固的z,优化为unused,因此传递到顶层,真正的物理pin脚就理解为不使用,不使用的io默认状态就是z。
但是如果是有相应逻辑而非固定z,那么在其他module中的端口wire型变量赋值组合逻辑表达式中出现z就会被传递错误的值,通常综合器碰到含有z的逻辑表达式直接理解为false,那么这个wire型端口传到顶层就是0。
因此,rv2k sdk中将用户module之外再套一个top层的自动代码,我真的有点反感,因为你要定义含有z的组合逻辑到一个io,你必须写到顶层,只有顶层才是真正对物理pin脚做定义。那么这个自动产生的top module,到头来还是要手动去改,于是自动生成的top顶层意义在哪里?
因此还是回到前面的贴子中所提出的观点,我还是需要对项目文件结构做一个重写,顶层自动分配pin脚这种方法,是有问题的,应该做根据用户顶层而产生 .asf的自动python脚本,而不是去将用户module之外产生一个top.
离线
OD和上拉配置应该这样设置:
# define open-drain output pins
set_instance_assignment -name ENABLE_OPEN_DRAIN -to PIN_XX~output true
# define pull-up pins
set_instance_assignment -name WEAK_PULL_UP_RESISTOR ON -to PIN_XX
现在我已经抛弃了SDK那种在用户项目之外再套个顶层的代码架构,退回到ag1280那种传统.保持用户顶层的可编辑性,这样管脚配置输出z不会因为模块间接口传递的问题都丢失
基本上已经调通,但是距离量产还有距离,还有不少坑.
无法完全替代MAX II或Lattice MACH XO2
主要以下几点要求比较苛刻:
1. 内部 RC-OSC对电压要求苛刻
2. 芯片上电配置时间比友商的同类规模cpld长
内部PLL的LOCK稳定更加长了上电配置时间.
所以,保持最高可移植度的使用方法是,不要去用他这个RC-OSC, 最好不要去用PLL.
当然,用来代替小规模fpga使用是没有问题的,因为本身FPGA配置时间就相对长. 但是如果是之前作为cpld使用,而cpld是master设备的话,这个上电配置时间必须有要求,它只能满足于小于外围被测量设备的上电时间.
离线
其实,rv2k是cyclone 4(兼容)啊, 如果是基于ag1280/max V epm1270基础上升级过来的就很适合了
但是之前ag1280 q48做的有点问题,管脚改的缩的太少了. 能有一个兼容epm240/570 qfp100,并且资源到2K~4K的CPLD就好了
总是觉得AGM似乎是在FOUNDRY厂那边做改封装和缩减,核心还是ALTERA的,所以兼容MAX II的最高到570了,AG1280是奇葩,完全可以设计成QFP100的,但是没有,因此市面上基本没有人用这个片子,后来也就不了了之,才有用基于CYCLONE4的RV2K去顶这个空档
最近编辑记录 aquasnake (2024-07-11 13:20:20)
离线
关于非易失性配置的fpga/cpld的瞬时启动性能的讨论
我对这个指标特别关注,因为在一些用途中,必须要求fpga/cpld具有瞬时启动特性.
那么我来分析下怎么设计能尽量缩短master boot模式下fpga/cpld的上电配置时间.
一些原本基于fpga架构,然后使用spi flash设计的架构,它在boot的时候,要将spi flash先倒到内部sram中去配置,这种上电配置时间较长,因为spi flash无法片上执行.
一些基于并口nor flash的架构,上电配置时间几乎不存在,因为一上电就直接可以nor flash片上执行.
我怀疑rv2k就是内部的spi flash boot模式,因此需要上电配置时间.
上电配置时间的存在会带来什么问题?
在配置期间,fpga的gpio保持高阻态,开机后是无法立即驱动外围设备的.
但是原则上,fpga设计公司应该有一种方法,可以通过初始配置上下拉电阻,来让fpga配置期间内保持gpio的电平状态.而这种对pin脚上下拉电阻的配置,则必须写到内部nor falsh中(具有立即片上执行性能),也就是说,对于pin脚的配置,不能写到spi flash中,而应该写到boot loader代码部分的nor falsh中.
AMD总裁提出的5% rules哲学也包括了此类,也就是说,看起来两个差不多的东西,好的设计体现在95%以上的部分.而好的应用,在于你是否用到了95%以上
最近编辑记录 aquasnake (2024-07-13 12:45:54)
离线
瞬时启动以及上电配置时间超过500us, 无法胜任某些应用
这个芯片说是cpld,其实核心是fpga,而且瞬时启动没有做好,上电时间超altera, lattice等友商
上电延迟我用图表来表示不同方案的差异
传统altera, lattice的实现流程
power up VCC----LDO(fixed delay 200us)----POR(insertion delay 150-250us)----configulation and initialization time(
unknown, ???us)--->init done, GPIOs restore to user's setting
AGRV2K实现将ARM和CPLD的 POR都统一, 然后合并到外部的RESET脚,这个脚有上拉电阻到vcc,监视VCC实现启动延迟
但是问题来了,如果要将CPLD和ARM的POR都接到一起,那么只能按照最长上电需求的器件去做,显然CPLD这里不是卡时间部分,ARM才是那个需要更久上电时间的.而且内部还带了PLL, PLL输出LOCK后才能让ARM脱离RESET,因此估计PLL的LOCK信号内部也是通过与门连接进去了.
如果单独使用CPLD和ARM,CPLD会在ARM RESET之前完成它自己的POR和配置,即CPLD比ARM更早READY,按说应该采用这样的多芯片上电流程思想.
但是在AGRV2K,以上无法实现,CPLD的上电时间被ARM拖累,上电时间将突破500us,这限制了很多有瞬时上电要求的应用.
最近编辑记录 aquasnake (2024-08-21 13:58:49)
离线
我是windows环境,批处理调用命令行方式脚本
好用不好用因人而异.看注重那些方面,我因为对于综合速度,出错信息检查,工具链嵌入整合到项目平台有较多的考虑,所以觉得这种方式对我很合适.
传统的开supra然后再找到具体的功能目录点开的方式我觉得我实在太累,有时候做不同平台的项目,一个功能过了半年一年不维护再要去看很多东西就望了,操作流程需要写一个doc文件,但是如果脚本控制,我不用记,直接点脚本运行了,实在想看细节就看脚本,脚本按顺序调用exe,就知道开发步骤了
离线
@aquasnake
之前10K,16K的不是号称99%吗,这个2K的怎么差这么多
我怀疑agrv2k就是一个16K LUTs的cyclone IV clone.
内建一个RISC V的软核.极限跑200多M频率吧.只是猜测.
如果真的是软核,那就还有继续反向的动力,要是能更进一步皮角掉Supra的fitter工具,甚至能释放出完整的LUT出来
可玩性比安路更高,适合极客有具有完全脱离原厂支持以及有深度自我想法的开发者用. 如果商业应用,开发时间会比其他家的长点,主要工具链和SDK上不如别家做的完善.但是这些东西做太完善了就玩不出花了,如果你要以最小的系统成本,做尽可能大的活, rv2k可能有惊喜
同时,我希望能精简risc v部分,释放出部分LUT出来给PL用,能做到4K用户LUT,那就太好了
最近编辑记录 aquasnake (2024-10-27 19:50:32)
离线