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系统性能评价参数]]
|