UVM 源码 uvm_sequencer_base grant_queued_locks

eaglezhang01

许晴125 发表于 2021-12-10 16:31
大佬

上次看到你说加微信，其实比较建议问题就在这上面问，这样其他人也可以看到可以相互学习讨论，这样回答问题更有意义，加一个好友也没坏处，微信号：lxdd52

许晴125

eaglezhang01 发表于 2021-12-13 15:46
上次看到你说加微信，其实比较建议问题就在这上面问，这样其他人也可以看到可以相互学习讨论，这样回答问 ...

已添加，希望大佬以后多多指点

许晴125

eaglezhang01 发表于 2021-12-13 15:42
is_blocked是检查sqr有没有已经被其他seq独占

大佬，最近有时间又看了看这块的代码，有两个小问题：1、lock函数调用的时候，lock_list[]队列只有在grant_queued_locks中赋值，当首次调用grant_queued_locks的时候，lock_list肯定是空的，经过grant_queued_locks调用以后，lock_list[]才有值，后续再调用grant_queued_locks的时候，is_block就会检测到对应的值lock_list，这个时候就会对arb_sequence_q重新排序，达到lock的请求。
在整个l调用flow里面有固定的两次调用:lock--->m_lock_req--->grant_queued_locks,m_choose_next_request--->grant_queued_locks
当然这里1.1d和1.2版本处理有不同，我是在1.2的版本看的。
不知道这里理解的对不对？
2、为什么在lock_list进行赋值的时候，还要每次赋值一次就m_set_arbitration_completed()????

eaglezhang01

许晴125 发表于 2022-2-22 10:10
大佬，最近有时间又看了看这块的代码，有两个小问题：1、lock函数调用的时候，lock_list[]队列只有在gran ...

先回答第2个问题，你看走这个分支是not blocked的，意思就是此刻没有任何requester占着资源，不会被阻塞，所以sqr能立马响应这个request，调你标记这行这个函数你看它是不是把一个关联数组置为1了，再追一下这个数组是在什么地方使用的你就明白了，其实这里相当于返回grant信号通知requester说我同意你了，否则requester就一直等着，sqr的作用就是一个arbiter，你带着arbiter的特性去看会能较快理解这个部分，
第1个问题我可能得看看了再回答你，又好久没看了，我最近在整理文档了，目前整理了tlm，config_db，factory，信息打印机制，正在整理phase，然后应该就是sequence

许晴125

eaglezhang01 发表于 2022-2-22 20:34
先回答第2个问题，你看走这个分支是not blocked的，意思就是此刻没有任何requester占着资源，不会被阻塞 ...

首先对第二个问题，在lock的时候，会调用grant_queued_locks(),这里面会m_set_arbitration_completed()，但是顺序执行到m_wait_for_arbitration_completed()的时候是等不到这个m_set_arbitration_completed()。


所以我理解这会在driver发起get_next_item的时候，才会在wait_for_grant以及lock处才会等到仲裁结束。

按照我的理解，只有在仲裁结束，从arb_sequence_q[]里面选出来适合发送的seq，触发m_set_arbitration_completed，才会m_wait_for_arbitration_completed()。所以我理解lock哪个地方m_set_arbitration_completed()是没有意义的。

不知道我理解的对不对？

首先对第一个问题，一句话概括我对lock的理解：grant_queued_locks：对lock_list进行赋值，并将arb_sequence_q[]的seq按照is_block(){也就是lock_list}进行重排序，将lock住的放在arb_sequence_q[]最前面。m_choose_next_item()就是从arb_sequence_q[]中选取seq.

我理解整体的思路应该是这样的，还请大家多多指教。

eaglezhang01

第二个问题，在你之前标红色的那个地方不就是在对grant赋值吗，这样就等到了啊，并不需要driver什么事，这个arbiter相当于会有两个req，一个是driver来的，一个是lock来的

许晴125

eaglezhang01 发表于 2022-2-23 10:29
第二个问题，在你之前标红色的那个地方不就是在对grant赋值吗，这样就等到了啊，并不需要driver什么事，这 ...

这么说吧，无论是否有lock操作，driver拿到的item都是从arb_sequence_q[]中获取的？

eaglezhang01

许晴125 发表于 2022-2-23 15:23
这么说吧，无论是否有lock操作，driver拿到的item都是从arb_sequence_q[]中获取的？ ...

不是哦，arb_sequence_q存放的是所有的req，item是transaction，类型都不一样，这里其实是先仲裁，仲裁成功了，seq会把transaction放入一个fifo中，然后driver那边就从这个fifo去取，fifo名字：m_req_fifo可以trace下

许晴125

eaglezhang01 发表于 2022-2-23 18:22
不是哦，arb_sequence_q存放的是所有的req，item是transaction，类型都不一样，这里其实是先仲裁，仲裁成 ...

是的，我的意思是说仲裁都是从arb_sequence_q[]这个队列里面来的吧？lock_list只会在is_block的时候发挥作用，用于调整通过grant_queued_locks来arb_sequence_q[]的seq的顺序？

许晴125

eaglezhang01 发表于 2022-2-23 18:22
不是哦，arb_sequence_q存放的是所有的req，item是transaction，类型都不一样，这里其实是先仲裁，仲裁成 ...

哦，好像突然明白了我知道我的问题出在哪里了。

实际上start_item是item的属性，并且会有一个对应的seq，将这个seq放入arb_sequence_q[]中去，跟其他的seq做仲裁，start_item会一直等到仲裁（drive的get_next_item）到自己的seq，然后结束start_item。并将arb_sequence_q[]中对应的seq删除。

然后finish_item，调用send_request，将item发送出去。然后等待drive的item_done。

item1/item2/item3都可以对应同一个seq，但是每次start_item/finish_item都是针对的一个item而言！！！item只不过是放在了seq的载体上，用于给sqr做仲裁。

我之前理解start_item/finish_item一直是觉得seq的概念是一连串的item，但其实每次start_item/finish_item其实就是一个item对应着的seq。

语言比较乱，不知道我表述清楚了吗？但我感觉之前对arb_sequence_q[]的理解不对。

补充一张图，说明一下：通常在body()里面进行start_item/finish_item，如果是seq发送多个item的话，my_seq_id的值应该是一样的。arb_sequence_q[]也会push_back多次。
所以每次拿去仲裁的seq，仲裁结束后，都只会发送一个item。