linux 011 注释8:函remove_from_queues (), insert_into_queues() 及新设计团队艺术书第二版第三章 3-24------3-36

(60)接着注释函数 remove_from_queues (), insert_into_queues() ,管理内存缓冲块,实现了 LRU 算法,双向环链表的头部是空闲块,尾部是分配出去的忙碌块:

在这里插入图片描述

(61)接着涉及读取硬盘,先来看看系统是如何初始化块设备的,3-25 块设备初始化blk_dev_init,hd_init:

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/1f93aa2be18743099f4136ca8bd02338.jpeg

(62)接着介绍申请缓冲块的大函数 get_blk()以及 wait_on_buffer() :

在这里插入图片描述

(63)进程的为等待资源的 睡眠与唤醒,是比较神奇的事情,进程在读硬盘申请内存缓冲块时出现了 sleep_on ()函数的调用,配对的又有进程的唤醒函数 wake_up() 。给临界区资源加锁解锁时候,就用到了这两个函数:

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/a969c5e05fcc4389800c5f9456c732

(64)至此,系统已多次申请了公共资源,或者叫临界资源,当申请不到时,或资源不可用时进行等待,那么系统中有哪些临界资源呢:

在这里插入图片描述

(65) 接着介绍函数 ll_rw_block(),add_request() 为最终的读写块设备做准备。对请求的排序要求是读比写优先,并减少硬盘寻道时间:

![![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/60c7ecdc78044cc395dfa4061b646603.jpeg](https://i-blog.csdnimg.cn/direct/f5f21247bc9a4637b6347d2151d89909.jpeg

(66)对块设备的读写请求,并非是直接的,而是经 全局 request[] 数组的限制数量后,再交给块设备去执行的。系统的设计还可以让块设备保存多个针对自己的读写请求,并依次执行。这是其中的一个函数 make_request():

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/9301deacd5ac4517965ed00eb2ee783d.jpeg

(67)接着介绍真正读取硬盘数据的更底层的函数:

![3-32   函end_request,INIT_REQUEST,do_hd_request下](https://i-blog.csdnimg.cn/direct/afd742a3e1f342e59cb086023daf438d.jpeg

![![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/d0d161e7fa2640709aa3f0bcfd0269cb.jpeg](https://i-blog.csdnimg.cn/direct/f03ae20c8d3c4bbd8c1c1564174b08a7.jpeg

(68) do_hd_request 会调用更基层的函数 hd_out(), controller_ready(),然后会进入真正的读盘操作:

3-33   函hd_out,controller_ready

(69)在阅读硬盘中断函数前,先理清几个全局变量的定义 do_hd , do_floppy 。以及进程的五种状态的具体含义:

在这里插入图片描述

(70)接着学习一条新汇编的 intel 指令 , insw , input string word:

在这里插入图片描述

(71) 接着介绍硬盘中断函数 :

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/4ce69ce4182d4443a1ae09e636d7dca5.jpeg

(72)硬盘中断函数里又调用了这几个关于硬盘读写的函数:

![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/a0c7b2679d484774a127f100cf4d2a86.jpeg

(73)
谢谢

### 思AXI VIP错误解决方案 在使用Synopsys AXI VIP时,遇到`remove_frome_master_active`和`in active xact queue`错误,通常是因为VIP内部事务管理机制出现问题。以下是可能的原因及解决方法: #### 1. 错误原因分析 - **事务队列冲突**:VIP维护了两个事务队列——`active_xact_queue`和`master_active_queue`。如果事务未正确完成或被提前移除,可能导致队列不一致,从而引发错误[^2]。 - **驱动器与监视器同步问题**:VIP的驱动器和监视器之间可能存在同步问题,导致事务状态不匹配。例如,驱动器认为事务已完成,但监视器仍将其视为活动状态[^3]。 - **配置参数错误**:某些配置参数(如延迟、响应类型)设置不当可能导致事务无法按预期完成[^4]。 #### 2. 解决方案 以下是一些可能的解决方法: ##### (1) 检查事务队列管理 确保事务在VIP中的生命周期管理正确。可以通过以下方式排查: - 在驱动器中添加调试信息,确认事务是否正确进入和退出队列。 - 使用`uvm_info`打印日志,检查事务的状态变化是否符合预期[^5]。 ```systemverilog // 示例代码:检查事务队列状态 task check_transaction_queues(); uvm_info("DEBUG", "Checking active_xact_queue...", UVM_LOW); foreach (svt_axi_master_agent_config::active_xact_queue[i]) begin $display("Queue index: %0d, Transaction ID: %0d", i, svt_axi_master_agent_config::active_xact_queue[i].get_transaction_id()); end endtask ``` ##### (2) 调整配置参数 检查并调整VIP配置文件中的参数,确保其与DUT的行为一致。重点关注以下参数: - `RESPONSE_DELAY`:响应延迟时间。 - `MAX_OUTSTANDING_XACTIONS`:最大未完成事务数[^6]。 ```systemverilog // 示例代码:调整配置参数 class my_svt_axi_vip_config extends svt_axi_vip_config; function new(string name = "my_svt_axi_vip_config"); super.new(name); this.RESPONSE_DELAY = 10; // 设置响应延迟 this.MAX_OUTSTANDING_XACTIONS = 8; // 设置最大未完成事务数 endfunction endclass ``` ##### (3) 验证环境调试 在验证环境中启用更详细的日志输出,定位问题根源。可以通过设置`UVM_VERBOSITY`为`UVM_HIGH`或更高级别来获取更多信息[^7]。 ```systemverilog // 示例代码:启用详细日志 initial begin uvm_top.set_report_verbosity_level_hier(UVM_HIGH); end ``` ##### (4) 检查DUT行为 确保DUT的行为与VIP的期望一致。例如,检查DUT是否正确处理AXI协议中的信号(如`READY`和`VALID`),以及是否按时响应事务[^8]。 #### 3. 总结 通过检查事务队列管理、调整配置参数、启用详细日志以及验证DUT行为,可以有效解决`remove_frome_master_active`和`in active xact queue`错误。如果问题仍然存在,建议参考VIP用户手册或联系思技术支持团队以获取进一步帮助。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

zhangzhangkeji

谢谢支持

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值