138 lines
5.8 KiB
Markdown
138 lines
5.8 KiB
Markdown
---
|
||
tags:
|
||
- 计算机系统结构
|
||
- 重点复习
|
||
- 总线
|
||
- 仲裁
|
||
- 分离事务总线
|
||
create time: 2026-06-16 21:21
|
||
---
|
||
|
||
# 小题 9 — 总线仲裁与分离事务总线
|
||
|
||
## 概述
|
||
|
||
本题考查**总线主设备**的概念、**总线仲裁机制**的分类与原理，以及**分离事务总线**的工作原理和别称。总线是计算机系统中各部件通信的公共通道，其仲裁和事务管理直接影响系统性能。
|
||
|
||
> [!tip] 考试重点
|
||
> 分离事务总线的别称（流水总线、分离协议总线）和非别称（交叉互连总线、独占总线）是 A 卷原题。总线仲裁的三种集中式策略也需要掌握。
|
||
|
||
## 正文
|
||
|
||
### 一、总线主设备与从设备
|
||
|
||
| 类型 | 含义 | 特点 | 示例 |
|
||
|:----:|------|------|------|
|
||
| **主设备**（Master） | 能**主动发起**总线事务的设备 | 拥有总线控制权，可以发起读写操作 | CPU、DMA 控制器 |
|
||
| **从设备**（Slave） | 只能**被动响应**总线事务的设备 | 不发起事务，只响应主设备的请求 | 内存、I/O 接口 |
|
||
|
||
> [!question] 主设备和从设备的区别？
|
||
> **主设备是"主动方"**——它决定何时使用总线、传输什么数据、传向哪里。**从设备是"被动方"**——它只在被主设备寻址时才响应。例如 CPU（主设备）向内存（从设备）发起读操作：CPU 发出地址和控制信号，内存被动地将数据放到总线上。
|
||
|
||
### 二、总线仲裁机制
|
||
|
||
多个主设备可能**同时请求**使用总线，**仲裁器**（Arbiter）决定哪个设备获得总线使用权。
|
||
|
||
```mermaid
|
||
graph TD
|
||
REQ["Multiple Bus Masters"] --> ARB["Bus Arbiter"]
|
||
ARB --> G1["Grant to Master 1"]
|
||
ARB --> G2["Grant to Master 2"]
|
||
ARB --> G3["Grant to Master 3"]
|
||
```
|
||
|
||
#### 2.1 集中式仲裁
|
||
|
||
由一个**中央仲裁器**统一管理所有总线请求。
|
||
|
||
| 策略 | 原理 | 优先级 | 优点 | 缺点 |
|
||
|------|------|:------:|------|------|
|
||
| **菊花链** | Grant 信号沿设备链逐级传递 | 离仲裁器近的高 | 简单、线数少 | 不公平，低优先级可能饿死 |
|
||
| **轮询** | 仲裁器按固定顺序轮询各设备 | 动态轮换 | 公平 | 效率不高 |
|
||
| **独立请求** | 每个设备有独立的请求/Grant 线 | 可编程设置 | 灵活、快 | 线数随设备数线性增长 |
|
||
|
||
> [!note] 三种集中式仲裁的对比
|
||
>
|
||
> | 维度 | 菊花链 | 轮询 | 独立请求 |
|
||
> |:----:|:------:|:----:|:--------:|
|
||
> | 请求线数 | 1 | 1 | $n$ |
|
||
> | Grant 线数 | 1（串行传递） | $\log_2 n$ | $n$ |
|
||
> | 公平性 | 差 | 好 | 可配置 |
|
||
> | 速度 | 慢（链式传递） | 中 | 快 |
|
||
> | 可扩展性 | 好 | 中 | 差（线数多） |
|
||
|
||
#### 2.2 分布式仲裁
|
||
|
||
没有中央仲裁器，各设备**自行协商**总线使用权。
|
||
|
||
| 策略 | 原理 |
|
||
|------|------|
|
||
| 自举分布式 | 每个设备监控比自己优先级高的设备的请求线 |
|
||
| 冲突检测 | 设备发送数据后检测是否发生冲突，冲突则重试 |
|
||
|
||
> [!question] 什么时候用分布式仲裁？
|
||
> 当系统规模很大（数十到数百个设备）时，集中式仲裁器成为瓶颈。分布式仲裁没有中央瓶颈，适合大规模系统（如以太网的 CSMA/CD 就是一种分布式冲突检测仲裁）。
|
||
|
||
### 三、分离事务总线
|
||
|
||
#### 3.1 核心思想
|
||
|
||
传统总线中，一个事务从**发起请求**到**数据返回**，总线被**全程独占**。即使中间有较长的等待时间（如内存准备数据），其他设备也不能使用总线。
|
||
|
||
**分离事务总线**将一个总线事务**拆分**为两个独立的子事务：
|
||
1. **请求阶段**：主设备发出地址和命令
|
||
2. **响应阶段**：从设备准备好数据后，独立地将数据返回
|
||
|
||
两个阶段之间，**总线被释放**，可以为其他设备服务。
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant M1 as "Master 1"
|
||
participant BUS as "Bus"
|
||
participant MEM as "Memory"
|
||
participant M2 as "Master 2"
|
||
|
||
M1->>BUS: "Phase 1: Request (addr + cmd)"
|
||
BUS->>MEM: "Forward to memory"
|
||
Note over BUS: "Bus released, available"
|
||
M2->>BUS: "Another request uses bus"
|
||
BUS->>M2: "Service Master 2"
|
||
MEM->>BUS: "Phase 2: Response (data ready)"
|
||
BUS->>M1: "Data delivered to Master 1"
|
||
```
|
||
|
||
#### 3.2 别称与非别称
|
||
|
||
> [!abstract]- 答案
|
||
>
|
||
> | 名称 | 是否是分离事务总线的别称 |
|
||
> |:----:|:------------------------:|
|
||
> | **流水总线** | 是 |
|
||
> | **分离协议总线** | 是 |
|
||
> | 交叉互连总线 | **不是**（是另一种总线拓扑） |
|
||
> | 独占总线 | **不是**（独占总线恰恰是分离事务总线的反面） |
|
||
|
||
> [!note] 为什么"交叉互连总线"和"独占总线"不是别称？
|
||
>
|
||
> **交叉互连总线**（Crossbar Bus）是一种总线**拓扑结构**，允许多对设备之间同时建立独立的连接通道。它与分离事务总线解决的是不同层面的问题——拓扑结构 vs 事务管理。
|
||
>
|
||
> **独占总线**描述的是一个事务**独占总线直到完成**的行为模式，这恰恰是分离事务总线要**解决**的问题。传统总线就是"独占"模式。
|
||
|
||
#### 3.3 分离事务总线的优势
|
||
|
||
| 优势 | 说明 |
|
||
|------|------|
|
||
| 提高总线利用率 | 等待期间总线不空闲，可服务其他请求 |
|
||
| 减少总线竞争 | 多个事务可以交错进行 |
|
||
| 提升 I/O 吞吐率 | 多个设备可以同时处于"等待响应"状态 |
|
||
| 适合慢速设备 | 内存访问延迟被隐藏在释放总线期间 |
|
||
|
||
> [!question] 分离事务总线有什么代价？
|
||
> 1. **硬件复杂度增加**：每个设备需要额外的缓冲寄存器来保存请求信息和返回数据
|
||
> 2. **控制逻辑复杂**：需要跟踪每个未完成事务的状态
|
||
> 3. **响应顺序不确定**：先发出的请求可能后返回，需要排序机制
|
||
|
||
## 关联笔记
|
||
- [[计算机系统结构/复习文档/总线与IO系统]]
|
||
- [[小题8-IO系统性能评价参数]]
|