WhyCan Forum(哇酷开发者社区)

我测试了下极限fitting利用率是89%，基本上大概是在1890个LUTs，我跑了上百次，只要综合产生的LUT超过189x，基本上fitter就跑不出来。

因此大致情况下稳定跑出来基本控制利用率在89%以下，当然我还是用的几个月前的fitter，如果是近一两个月supra下的fitter，更难跑出来，效率更降低了。因此我建议不要盲目跟随原厂升级tools，如果你以前做的稳定的项目，非必要不要升级

@aquasnake
之前10K,16K的不是号称99%吗，这个2K的怎么差这么多

目前 agm尚且还需要altera环境，来注入外挂脚本利用quartus ii产生网表，这部分无法自动化，其他我都实现了一键批处理

由于calibration内部晶体用的电压和目标板stand alone工作时的电压可能有偏差，因此校准到的晶体输出频率不等于实际工作时候的频率，由此可以推断，必须保证下载线输出3.3V和板子实际工作后的VCC尽可能地保持一致

同时，猜测AGRV2K内部甚至没有LDO对这个int OSC供电，而是直接跟随系统VCC 3.3V

l

前两天也试了他们的AGRV2K，发现他们的编译器有点玄学，不懂怎么回事，有时候改一个引脚分配文件把引脚映射到另外一个IO，其他啥都不变，编译下载后结果不符合预期，有时候引脚没变，单纯修改verilog逻辑，改变某个引脚后编译下载，结果又不符合预期，但是偶尔从新按照他们的新建工程步骤，代码不变新建编译下载竟然又符合预期了，搞得我很迷茫。。。。

仅仅是引脚更改，那么其实不用在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库。除非你用你自己反向出来这些模块并以代码方式嵌入到你自己的项目

如果用开源的综合器产生网表，那么要做的事情很多，需要手动写 *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，驱动力，滞回，延迟微调整等）不敏感

其实调用 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)

注意，仅仅是写了.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剥离干净

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空间多分配４K以充分使用CPLD

原因是脚本限制了cpld bin size,而且脚本默认是产生加密bin，加密bin需要更多的size。如果不改，当cpld使用到超过90%就会bin超标，窗口会显示error，但是仍然生成bin。而这个超标的bin写到片子里面肯定是无法工作的

最近编辑记录 aquasnake (2024-05-18 09:14:07)

关于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这两个信号在内部片上总线结点必须设置为高，如果不定义，悬空或者为０都将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)

是的，纯logic只能使用纯IO引脚，各种功能脚不能用。
不过用这个芯片的目的，也不是只当CPLD的吧。和MCU联合才是正途。

关于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};

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要写更多的初始化代码。

为什么还要低压降啊？

官方建议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里的RAM IP都能用，FIFO也没问题，只是资源别超过4个M9K。
因为这些IP就是RAM block和LUTs的组合，没什么本质区别

PL IDE 开发难度大，，暂时用quartus+supra还可以理解

PS IDE 一大堆Eclipse套壳不选，，用了个paltformIO，，实在难以理解，，我理解上PIO是给DIY爱好者用的，，哪有正经公司用PIO做IDE的？？
建议搞个正经的Eclipse套壳IDE，，或者联系下MounRiver Studio，，合作支持一下也比PIO强。。

AGRV2K是块好肉，只是原厂厨师烹饪出来的口味，有点怪;)

AG10K也不能卖了吗？我看淘宝店在正常销售啊。。

开发环境基于Eclipse或VS Code都没有啥问题，这是当前开源且功能丰富的工具的两大主流选择。问题是PlatformIO主要面向萌新，有点能力的老鸟用这个就很不搭调。

这问题其实跟MounRiver差不多，起初MounRiver为了迎合Keil/IAR开发者的口味，对Eclispe大肆裁减，企图将Ecipse改为Keil，这引起Eclipse开发者的不满。

于是就有非社区版和社区版之分，非社区版裁掉了很多Ecipse特色的实用功能就是个开源版的Keil，而社区版则没有功能裁减只是增加了WCH家的插件。

我个人认为，作为一个面向各种资历的开发者的工具，没必要为了迎合新人而降低工具的天花板，把新人的入门引导做好即可。

最近编辑记录 海石生风 (2024-06-28 10:59:23)

还有一个告诉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项目，跑出来部分管脚是不可使用的

为什么无法定义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.

其实,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)

瞬时启动以及上电配置时间超过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,就知道开发步骤了