考研笔记

总线事务

一次总线事务 = 从主设备提出使用总线，到数据传完并让出总线的全过程。

它有五个阶段，而这五个阶段恰好就是本章的目录：

flowchart LR
    R["① 请求<br/>主设备提出申请"] --> A["② 仲裁<br/>裁定这次归谁"]
    A --> AD["③ 寻址<br/>给出地址与命令"]
    AD --> T["④ 传输<br/>一个或多个数据拍"]
    T --> F["⑤ 释放<br/>撤销信号，让出总线"]
    classDef arb fill:#e8f0fe,stroke:#4285f4,stroke-width:2px
    classDef data fill:#fff8e1,stroke:#f9ab00,stroke-width:2px
    class R,A arb
    class AD,T,F data
  • ① ② 回答「谁能用」——6.1.1 的主/从设备、本节的仲裁
  • ③ ④ 回答「传什么、传多少」——6.1.5 的带宽在这里兑现
  • ④ ⑤ 之间每一步的交接时机，就是 6.2.2 总线定时要管的事

注意①②与③④⑤的分工：仲裁只决定”谁使用总线”，它自己不搬任何数据。这与 5.1.2 那条「控制部件不生产数据」是同一条判据在总线上的版本。

机制

五个时间概念

这五个词长得像，考试专挑它们出辨析题：

概念含义谁包含谁
时钟周期总线（或 CPU）的一个基本节拍最小
总线周期（总线传输周期）完成一次基本传送所占的时间含 1 个或多个时钟周期
总线事务从请求到释放的一整套活动含 1 个或多个总线周期
机器周期CPU 完成取指、间址、执行等一个基本工作阶段见 5.2.1
指令周期取出并执行完一条指令的全过程含若干机器周期

关键是认清两条独立的链：

  • 总线这一侧：时钟周期 ⊂ 总线周期 ⊂ 总线事务
  • CPU 这一侧：时钟周期 ⊂ 机器周期 ⊂ 指令周期

两条链在”访存”这一点上交汇——CPU 的一个取指机器周期，内部就包含一次完整的总线事务。但两条链的倍数关系都不固定，这与 5.2.1 强调的”三个时间层次倍数不固定”是同一个提醒。

仲裁：本章只需补一种

三种判优方式的实体内容已经在 5.5.3 学过——中断判优与总线仲裁是同构的，链式查询和独立请求连名字都一样。这里只补齐第三种。

集中式仲裁

由一个中央仲裁器（总线控制器）统一裁决。

方式怎么裁线数优先级主要缺点
链式查询（菊花链）允许信号 BG 沿设备串行传播，谁要用谁截留最少（1 根链）由物理位置决定离仲裁器远的设备可能饿死；链上一环坏，后面全瞎
计数器定时查询仲裁器用计数器广播设备号，编号匹配且有请求的设备应答中（设备号线 根）可变（改计数起点）查询要花时间，平均延迟大
独立请求每个设备有独立的 BR/BG 线，仲裁器用优先权编码器直接选最多（ 根）灵活，可编程线多、仲裁逻辑复杂

计数器定时查询是前两者的折中：不像链式查询那样把优先级焊死在物理位置上（每次从 0 开始计数就是固定优先级，从上次结束处开始计数就是循环优先级，公平），也不像独立请求那样每个设备拉两根线。代价是查询过程本身要花时间。

三者的取舍是同一条轴：线数 ↔ 灵活性 ↔ 响应速度。链式查询在最省线那一端，独立请求在最快最灵活那一端，计数器定时查询在中间。

分布式仲裁

没有中央仲裁器。 各设备把自己的优先级号送上一组公共的仲裁线，同时比较，优先级低的自动撤出。可扩展性好，但每个设备都要带一套比较逻辑。

关联对照：仲裁三方式与中断判优三方式

总线仲裁中断判优（5.5.3）
链式查询（菊花链）链式查询（同名同构）
独立请求独立请求（同名同构）
计数器定时查询软件查询（都靠”逐个问”，都慢）

两套只需记一套。 判据完全一致：靠物理位置的最省线但不灵活，靠编码器的最快但最费线，靠轮询的居中但慢。

读事务与写事务

读事务写事务
③ 寻址主设备发地址 + 读命令主设备发地址 + 写命令
数据由谁驱动从设备主设备
④ 传输从设备准备好后把数据放上总线，主设备采样主设备把数据放上总线，从设备锁存
数据线是否转向需要（地址由主发、数据由从发）不需要（都由主设备发）
谁在等主设备等从设备准备数据从设备可能要求主设备等

读事务比写事务多一次数据线转向，这在半双工的共享数据总线上要留出空档（6.1.2），可能多占一个周期。“读比写慢”最根本的一条原因就在这里，而不是”读要去存储体里找”——写同样要写进存储体。

单次传送、突发传送、分离事务

单次传送

一次事务只传一个数据单元，每个字都要重新付一遍地址阶段的开销。

突发传送（Burst）

只发送首地址和长度，随后连续传多个数据拍，后续地址由双方按约定递增，不再重发。

地址命令首字准备

这是 6.1.5 那个 47% 利用率问题的直接解法：地址阶段和首字准备是固定开销，数据拍越多，摊到每拍上的开销越小。

若地址命令占 个周期、准备占 个周期、每拍 1 个周期，传 个总线字：

Cache 块填充是突发传送最典型的用途——一个 Cache 块必须整块调入（3.5.2），这正好是一次长突发。块越大，总线利用率越高，这也是”块大小要适中”那个取舍里被经常忽略的一侧。

分离事务（Split Transaction）

主设备发出读请求后立即释放总线，不占着等；从设备准备好数据后，作为一次新的事务把数据送回来。

  • 收益：从设备准备数据的那段时间里，总线可以服务别的事务，利用率显著提高
  • 代价：需要事务标识（把回来的数据对上是谁请求的）、请求队列、以及处理乱序返回的能力

层次辨析：分离事务与非阻塞 Cache 不是一回事

两者都在解决”等待期间别闲着”，但放弃的东西不同：

  • 分离事务：主设备放弃的是总线的占用，让别的设备用
  • 非阻塞 Cache（5.6.5）：CPU 放弃的是阻塞等待，继续执行后面的指令

一个系统可以只有其中之一。“CPU 能不能在等待时干别的”由后者决定，与总线是不是分离事务无关——这一点在 6.2.2 还会正面处理一次。

边界

仲裁不传数据。 它只决定使用权。计算事务时间时，仲裁阶段可能与前一个事务重叠（流水化），是否单独计时按题目规定。

不是每道题都把五阶段分别计时。 很多题目只给”地址 + 数据”两段。按题图数周期，不要凭五阶段的名字硬凑。

突发传送不重发地址，但仍需要地址递增的约定。 从设备必须知道后续拍对应哪些单元——通常是顺序递增，也有回绕（wrap）方式，看协议。

突发长度不等于 Cache 块大小。 若块大于单次突发的上限，要拆成 次事务；能否重叠要看主存是否多体交叉。

分离事务提高的是总线利用率，不是单次访问的延迟。 对发起者来说，分离事务的读延迟只会更长（多了一次事务的建立开销）。这与 5.6.1 “吞吐提高、延迟不减”是同一个形状的结论。

总线周期与机器周期没有固定倍数关系。 它们分属两条链，只在访存那一点交汇。

对照速查

问题判据
事务五阶段请求 → 仲裁 → 寻址 → 传输 → 释放
仲裁做什么只定谁用，不搬数据
链式查询的优先级由什么定物理位置（离仲裁器的远近）
计数器定时查询怎么做到公平每次从上次结束处继续计数（循环优先级）
独立请求的线数（每设备一对 BR/BG）
读比写多了什么数据线转向
突发传送省的是什么重复的地址阶段与首字准备
分离事务放弃的是什么对总线的占用（不是 CPU 的等待）

考点

  • 概念辨析：时钟周期 / 总线周期 / 总线事务 / 机器周期 / 指令周期五选一，问包含关系或”下列哪个最长”。
  • 仲裁方式对比：线数排序（链式 < 计数器 < 独立请求）、灵活性排序（相反）、链式查询的可靠性缺陷（一环坏后面全瞎）是高频答案。
  • 突发时间计算：，并求利用率；常与 Cache 块大小、多体交叉联合出题。
  • 分离事务判断：给一段描述，判断是否为分离事务——判据是”请求与响应之间总线有没有被释放”。
  • 读/写事务差异：数据由谁驱动、是否需要转向。

链接

反向链接