记录 RFNoC 的整个开发过程
回到目录
1 前言
这篇文章以开发RFNoC-QPSK中的32bits-2bits转换模块为例演示RFNoC的完整开发流程, 并且起名"Outline", 希望通过这一篇文章能够快速回忆起流程. 因此这篇文章并不属于任何章节而是独立于书籍的根目录的存在.
注: 目前采用X310平台进行该流程
2 创建RFNoC Custom Module
这部分的详情见RFNoC工具链简介。
2.1 创建module
首先RFNoC module 是一个功能的工具集(类比gr-mod)。整个module包括多个blocks,共同组成某些功能的模块集合,我们首先就应该创建module。
➜ rfnocmodtool newmod --srcdir <UHD-Install-Prefix>/share/gr-ettus/rfnoc_modtool/rfnoc-newmod
Name of the new module: qpsk
Creating out-of-tree module in ./rfnoc-qpsk... Done.
Use 'rfnocmodtool add' to add a new block to this currently empty module.
其中<UHD-Install-Prefix>
是UHD的安装路径。
2.2 添加block
创建module之后,我们向其中添加第一个功能模块——32bits-2bits转换。起名为conv32Bto2B
,剩下的配置保持默认即可。
➜ cd rfnoc-qpsk
➜ rfnocmodtool add
RFNoC module name identified: qpsk
Enter name of block/code (without module name prefix): conv32Bto2B
Block/code identifier: conv32Bto2B
Enter valid argument list, including default arguments:
Add Python QA code? [y/N]
Add C++ QA code? [y/N]
Block NoC ID (Hexadecimal):
Random NoC ID generated: D6AA69D4
Skip Block Controllers Generation? [UHD block ctrl files] [y/N]
Skip Block interface files Generation? [GRC block ctrl files] [y/N]
3 功能实现
本节内容是要完成新创建RFNoC的功能部分,主要的流程就是FPGA编程+仿真确认功能的正确性,在RFNoC 4.0中提供了完整的仿真库,开发起来十分方便。
3.0 (更改NoC shell)
参考RFNoC CHDR 总线简介,我们知道CHDR包括context和payload两部分,如果是传统一进一出的数据处理模式,则不需要改变context的内容,但是在32位数据转2位数据的模式下,总线上的数据会变多。因此需要改变context的内容来告知CHDR数据变多(否则,CHDR只会读出与你输入数量相等的数据)。
而在CHDR数据转换为更加容易处理的axis的数据,RFNoC提供了两个(也许更多)的模块:chdr_to_axis_data
和chdr_to_axis_pyld_ctxt
。chdr_to_axis_pyld_ctxt
直接将数据拆分为payload和context两部分,如果你想单独处理context的内容就需要进行手动的切片工作,对于不改变context内容的block,只需要将context的内容做透明转发即可。chdr_to_axis_data
会继续把context上的内容继续拆分为timestamp
, has_time
, length
, eov
, eob
以及payload部分data
。
因为我们需要更改context的内容以告知总线数据被本模块倍增了,因此需要将默认的noc_shell生成的chdr_to_axis_pyld_ctxt
更改为chdr_to_axis_data
。
更改只需要参考rfnoc_block_duc
的noc_shell_duc
即可,只是用chdr_to_axis_data
替换了chdr_to_axis_pyld_ctxt
。
3.1 添加数据处理模块
为了保证程序的结构清晰,强烈建议不要在生成的文件中直接添加数据处理的代码,而是将数据处理单独封装成一个module,之后再在rfnoc_block_xxxx.v
中实例化。
在本例中,我创建了QPSK_data_converter.v
来实现数据的拆分转换。则要注意:在rfnocmodtool生成的文件之外创建的源文件,需要手动添加到编译目录中,打开rfnoc-<module name>/rfnoc/fpga/rfnoc_block_<block name>/Makefil.srcs
,在RFNOC_OOT_SRCS
中添加自定义文件!!
# Makefile.srcs
# RFNoC Block Sources
# Here, list all the files that are necessary to synthesize this block. Don't
# include testbenches!
# Make sure that the source files are nicely detectable by a regex. Best to put
# one on each line.
# The first argument to addprefix is the current path to this Makefile, so the
# path list is always absolute, regardless of from where we're including or
# calling this file. RFNOC_OOT_SRCS needs to be a simply expanded variable
# (not a recursively expanded variable), and we take care of that in the build
# infrastructure.
RFNOC_OOT_SRCS += $(addprefix $(dir $(abspath $(lastword $(MAKEFILE_LIST)))), rfnoc_block_conv32Bto2B.v noc_shell_conv32Bto2B.v QPSK_data_converter.v)
3.2 仿真模块功能
创建好数据处理模块之后,最好对其进行仿真分析,因为X310编译一次太久,提前完成数据分析有助于提前发现问题。
仿真的控制在rfnoc_block_<block name>_tb.sv
文件中定义。启动仿真通过make rfnoc_block_<block name>_tb
进行启动。
# cmake生成makefile
cmake -DUHD_FPGA_DIR=<uhd-repo>/fpga -DCMAKE_INSTALL_PREFIX=/opt/gr38uhd4105 ..
# 启动仿真
make rfnoc_block_conv32Bto2B_tb
如果想使用Qustasim进行更下细致的仿真,可以参考RFNoC block 仿真方法
3.3 创建FPGA镜像
makefile同样提供了编译FPGA镜像的快捷指令
make <block name>_x319_rfnoc_image_core
注意:这里有一个小bug,是yml文件定义的版本号为float,而处理脚本会将其当做string进行处理,因此需要手动将yml
文件中的rfnoc_version
的字段改为字符串,报错信息如下:
File "/opt/gr38uhd4105/lib/python3.8/site-packages/uhd/imgbuilder/templates/rfnoc_image_core.vh.mako", line 3, in render_body
protover = config.rfnoc_version.split('.')
AttributeError: 'ScalarFloat' object has no attribute 'split'
修改的文件包括
rfnoc/blocks/xxx.yml
rfnoc/icores/xxxx_x310_image_core.yml
4 安装RFNoC custom module
为了能正确的在gnuradio中调用自定义的module,需要运行编译安装。
cd <rfnoc module dir>/build
make install
5 在GNU Radio中测试模块功能
可以使用自动生成的grc进行测试
在这里对其稍微做出一点改动,框图如下。
在运行gr之前,需要将编译好的fpga镜像写入到x310中。
➜ uhd_image_loader --args="type=x300,addr=192.168.40.2" --fpga-path=<UHD-repo>/fpga/usrp3/top/x300/build-X310_HG/x300.bit
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_4.1.0.HEAD-0-g6bd0be9c
Unit: USRP X310 (31E24FC, 192.168.40.2)
FPGA Image: /home/lilacsat/Playground/rfnoc/src/uhd/fpga/usrp3/top/x300/build-X310_HG/x300.bit
-- Initializing FPGA loading...successful.
-- Loading FPGA image: 100% (121/121 sectors)
-- Finalizing image load...successful.
Power-cycle the USRP X310 to use the new image.
运行gr之前最好再用uhd_usrp_probe
来确定镜像已经被正确加载。
➜ uhd_usrp_probe --args "addr=192.168.40.2"
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_4.1.0.HEAD-0-g6bd0be9c
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[WARNING] [X300] For the 192.168.40.2 connection, UHD recommends a send frame size of at least 8000 for best
performance, but your configuration will only allow 1472.This may negatively impact your maximum achievable sample rate.
Check the MTU on the interface and/or the send_frame_size argument.
[WARNING] [X300] For the 192.168.40.2 connection, UHD recommends a receive frame size of at least 8000 for best
performance, but your configuration will only allow 1472.This may negatively impact your maximum achievable sample rate.
Check the MTU on the interface and/or the recv_frame_size argument.
[INFO] [GPS] No GPSDO found
[INFO] [X300] Radio 1x clock: 200 MHz
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 24862979 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=24862979
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 24862979 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=24862979
[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 816000 and may result in dropped packets on some NICs
[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs
[WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0xd6aa69d4, 0xffff
_____________________________________________________
/
| Device: X-Series Device
| _____________________________________________________
| /
| | Mboard: X310
| | revision: 11
| | revision_compat: 7
| | product: 30818
| | mac-addr0: 00:80:2f:30:ed:c5
| | mac-addr1: 00:80:2f:30:ed:c6
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.2
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: 31E24FC
| | FW Version: 6.0
| | FPGA Version: 38.0
| | FPGA git hash: 6bd0be9
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| _____________________________________________________
| /
| | RFNoC blocks on this device:
| |
| | * 0/Block#0
| | * 0/DDC#0
| | * 0/DDC#1
| | * 0/DUC#0
| | * 0/DUC#1
| | * 0/Radio#0
| | * 0/Radio#1
| _____________________________________________________
| /
| | Static connections on this device:
| |
| | * 0/SEP#0:0==>0/DUC#0:0
| | * 0/DUC#0:0==>0/Radio#0:0
| | * 0/Radio#0:0==>0/DDC#0:0
| | * 0/DDC#0:0==>0/SEP#0:0
| | * 0/Radio#0:1==>0/DDC#0:1
| | * 0/DDC#0:1==>0/SEP#1:0
| | * 0/SEP#2:0==>0/DUC#1:0
| | * 0/DUC#1:0==>0/Radio#1:0
| | * 0/Radio#1:0==>0/DDC#1:0
| | * 0/DDC#1:0==>0/SEP#2:0
| | * 0/Radio#1:1==>0/DDC#1:1
| | * 0/DDC#1:1==>0/SEP#3:0
| | * 0/SEP#4:0==>0/Block#0:0
| | * 0/Block#0:0==>0/SEP#4:0
| _____________________________________________________
| /
| | TX Dboard: 0/Radio#0
| | ID: UBX-160 v2 (0x007d)
| | Serial: 31DE8D1
| | _____________________________________________________
| | /
| | | TX Frontend: 0
| | | Name: UBX TX
| | | Antennas: TX/RX, CAL
| | | Sensors: lo_locked
| | | Freq range: 10.000 to 6000.000 MHz
| | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | Connection Type: QI
| | | Uses LO offset: No
| _____________________________________________________
| /
| | RX Dboard: 0/Radio#0
| | ID: UBX-160 v2 (0x007e)
| | Serial: 31DE8D1
| | _____________________________________________________
| | /
| | | RX Frontend: 0
| | | Name: UBX RX
| | | Antennas: TX/RX, RX2, CAL
| | | Sensors: lo_locked
| | | Freq range: 10.000 to 6000.000 MHz
| | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| _____________________________________________________
| /
| | TX Dboard: 0/Radio#1
| | ID: Unknown (0x0094)
| | Serial: 3188C83
| | _____________________________________________________
| | /
| | | TX Frontend: 0
| | | Name: Unknown (0x0094) - 0
| | | Antennas:
| | | Sensors:
| | | Freq range: 0.000 to 0.000 MHz
| | | Gain Elements: None
| | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| _____________________________________________________
| /
| | RX Dboard: 0/Radio#1
| | ID: TwinRX Rev C (0x0095)
| | Serial: 3190DF9
| | _____________________________________________________
| | /
| | | RX Frontend: 0
| | | Name: TwinRX RX0
| | | Antennas: RX1, RX2
| | | Sensors: lo_locked
| | | Freq range: 10.000 to 6000.000 MHz
| | | Gain range all: 0.0 to 93.0 step 1.0 dB
| | | Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz
| | | Connection Type: II
| | | Uses LO offset: No
| | _____________________________________________________
| | /
| | | RX Frontend: 1
| | | Name: TwinRX RX1
| | | Antennas: RX1, RX2
| | | Sensors: lo_locked
| | | Freq range: 10.000 to 6000.000 MHz
| | | Gain range all: 0.0 to 93.0 step 1.0 dB
| | | Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz
| | | Connection Type: QQ
| | | Uses LO offset: No
测试结果
因为没有做幅值映射,只是将数据拆解开,放到最低两位,所以数据有4种情况。图中可见四种幅值的数据点。
回到目录
原文地址:https://www.cnblogs.com/ArtisticZhao/p/16088836.html
下一篇: 什么是六西格玛绿带计划?
推荐阅读
-
记录 RFNoC 的整个开发过程
-
196:受试者参与临床试验的整个过程
-
下载和安装嵌入式微控制器开发软件 CodeWarrior 的过程。
-
嵌入式 Linux 项目开发 (I) - BOA 移植 - IV.BOA 移植过程中的错误解决方案
-
什么是数据库事物?为什么需要数据库事物,事物有哪些特征?事物的隔离级别是什么?-1.什么是数据库事务? 1.事务是作为一个逻辑单元执行的一系列操作。一个逻辑工作单元必须具备四个属性,即ACID(原子性、一致性、隔离性和持久性)属性,只有这样才能成为事务: 原子性 2.事务必须是一个原子工作单元;它的数据修改要么全部执行,要么全部不执行。 一致性 3.事务完成时,所有数据必须保持一致。在相关数据库中,所有规则都必须适用于事务的修改,以保持所有数据的完整性。事务结束时,所有内部数据结构(如 B 树索引或双向链接表)必须正确无误。 隔离 4.并发事务的修改必须与其他并发事务的修改隔离。一个事务会在另一个并发事务修改之前或之后查看某一状态下的数据,而不会查看中间状态下的数据。这就是所谓的可序列化,因为它允许重新加载起始数据和重放一系列事务,从而使数据最终处于与原始事务执行时相同的状态。 持久性 5.事务完成后,它对系统的影响是永久性的。即使在系统发生故障的情况下,修改也会保留。 2. 为什么需要数据库事物,事物有哪些特征? 事物对数据库的作用是对数据进行一系列操作,要么全部成功,要么全部失败,防止出现中间状态,确保数据库中的数据始终处于正确、和谐的状态。 特征:原子性、一致性、隔离性、持久性,以及其他特征 原子性(Atomicity):所有操作在事务开始后,要么全部做完,要么全部不做,不可能停滞在中间环节。事务执行过程中出现错误时,会回滚到事务开始前的状态,所有操作就像没有发生一样。也就是说,事务是一个不可分割的整体,就像化学中的原子一样,是物质的基本单位。 一致性(Consistency):在事务开始之前和结束之后,数据库的完整性约束都没有被破坏。例如,如果 A 转钱给 B,A 不可能扣除这笔钱,但 B 却没有收到这笔钱。 隔离:在同一时间内,只允许一个事务请求相同的数据,不同事务之间没有干扰。例如,甲正在从一张银行卡上取款,在甲取款过程结束之前,乙不能向这张卡转账。 持久性(耐用性):事务完成后,事务对数据库的所有更新都将保存到数据库中,无法回滚 3.事务的隔离级别有哪些? 数据库事务有四种隔离级别,从低到高分别是未提交读取(Read uncommitted)、已提交读取(Read committed)、可重复读取(Repeatable read)、可序列化(Serializable)。此外,事务的并发操作中可能会出现脏读、不可重复读、幽灵读等情况。事务并发问题 脏读:事务 A 读取事务 B 更新的数据,然后事务 B 回滚操作,那么事务 A 读取的数据就是脏数据。 不可重复读取:事务 A 多次读取同一数据,事务 B 在事务 A 多次读取期间更新并提交数据,导致事务 A 多次读取同一数据时结果不一致。 幻影读取:系统管理员 A 将数据库中所有学生的具体分数改为 ABCDE 等级,但系统管理员 B 在此时插入了具体分数的记录,当系统管理员 A 更改结束后发现仍有一条记录未被更改,仿佛发生了幻觉,这称为幻影读取。 小结:不可重复读和幻读容易混淆,不可重复读侧重于修改,幻读侧重于增删。解决不可重复读问题只需锁定满足条件的行,解决幻读问题则需要锁定表 MySQL 事务隔离级别
-
从开发、部署到网站备案全过程的私人工作经验
-
简述 php 开发网站的整个工作流程
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
在阅读《丰乳肥臀》的过程中,我想记录下那些触动我的趣事和伤心事
-
什么是可用性测试?有效性(Effectiveness)-- 用户完成特定任务和实现特定目标的正确性和完整性程度;效率(Efficiency)-- 用户完成任务的正确性和完整性程度与所用资源(如时间)之比;满意度(Satisfaction)-- 用户在使用产品时的主观满意度和接受程度。 2.如何获得可用性? 可以参考以下原则:Gould、Boies 和 Lewis(1991 年)为以用户为中心的设计定义了 4 个重要原则: 早期以用户为中心:设计者应在设计过程的早期就努力了解用户的需求。 综合设计:设计的所有方面都应同步发展,而不是按顺序进行。使产品的内部设计始终与用户界面的需求保持一致。 早期和持续测试:当今唯一可行的软件测试方法是经验主义方法,即如果实际用户认为设计可行,该设计就是可行的。通过在整个开发过程中引入可用性测试,用户就有机会在产品推出之前对设计提出反馈意见。 迭代设计:大问题往往掩盖了小问题的存在。设计人员和开发人员应在整个测试过程中对设计进行迭代。 3...什么是可用性测试? 可用性测试是根据可用性标准对图形用户界面进行的系统评估。 可用性测试是衡量用户与系统(网站、软件应用程序、移动技术或任何用户操作设备)交互时的体验质量。4.如何进行可用性测试? l 实验室实验