ieee1500协议 一

IEEE 1500 为对于嵌入式core和集成电路提供了标准的可测试性方法

概览

IEEE Std 1500™为嵌入式设计块的独立、模块化测试开发和测试应用定义了一个可扩展的架构,并且还支持测试围绕这些内核的外部逻辑。模块化
测试通常是嵌入式非逻辑块(例如存储器)和嵌入式预先设计的不可合并知识产权(IP)内核的要求。此外,IEEE 1500 架构也可以
用于将大型设计块划分为更易于管理大小的较小块并促进测试重用
用于从一个片上系统(SoC)设计到下一个设计重复使用的块

The IEEE 1500 architecture comprises hardware requirements, through the definition of a standardized core wrapper, and uses a test-specific language to communicate information between core providers and core users. This language is the IEEE P1450.6™ 1 core test language (CTL). Although IEEE Std 1500 limited itself to test aspects internal to nonmergeable cores, careful consideration was given to the interoperability of such cores, resulting in plug-and-play (PnP) requirement definitions. SoC-specific issues such as those related to the design of test access mechanisms (TAMs) are excluded from this standard and assumed to be addressed by the SoC designer

IEEE 1500 架构包括硬件要求,通过定义标准化的内核封装,并使用特定于测试的语言在内核提供者和内核用户之间传达信息。这种语言是 IEEE P1450.6™1 内核测试语言(CTL)。虽然 IEEE 标准 1500 仅限于不可合并内核内部的测试方面,但对这种内核的互操作性进行了仔细考虑,从而产生了即插即用(PnP)要求定义。特定于片上系统(SoC)的问题,例如与测试访问机制(TAM)设计相关的问题,被排除在该标准之外,并假定由 SoC 设计者解决。

IEEE Std 1500 specifically focuses on defining test requirements for unidirectional non-tristate digital terminals, as these represent a minimum and mandatory set of requirements upon which the more complex bidirectional terminals are based. It is, therefore, implied that support for bidirectional or tristatable terminals is provided only to the extent that the individual unidirectional terminals, i.e., the bidirectional or tristatable terminal, are available for IEEE 1500 wrapper insertion. In addition, the hardware architecture defined in this standard anticipates a synchronous wrapper design methodology

IEEE Std 1500 特別著重於定義單向非三態數位終端的測試要求,因為這些要求代表了更複雜的雙向終端所基於的一組最低和強制性要求。因此,這意味著僅在各個單向終端(即雙向或三態終端)可用於 IEEE 1500 包裝器插入的範圍內提供對雙向或三態終端的支援。此外,本標準定義的硬體架構預期採用同步包裝器設計方法。

While IEEE Std 1500 does not discuss chip-level design, the architecture defined in this standard does not prevent interfacing with IEEE 1149.1™-based standards. An example of this interface is provided in Annex C for the reader’s benefit

虽然 IEEE Std 1500 并未讨论芯片级设计,但本标准中定义的架构并不妨碍与基于 IEEE 1149.1™ 的标准进行接口。为方便读者,附件 C 提供了此接口的一个示例。

All rules described in this standard apply to the case where the IEEE 1500 wrapper is enabled (the wrapper logic actively participates in the test of the core) except rules specific to the Wrapper Disabled state of the IEEE 1500 wrapper. In Wrapper Disabled state, the IEEE 1500 wrapper is disabled, allowing functional operation of the wrapped core. IEEE P1450.6 constructs were added to this standard, where appropriate, to further guide the reader. It is anticipated that the reader will refer to these CTL constructs documented in
IEEE P1450.6. 

本标准中描述的所有规则都适用于启用 IEEE 1500 包装器的情况(包装器逻辑主动参与核心测试),但 IEEE 1500 包装器的包装器禁用状态特有的规则除外。在包装器禁用状态下,IEEE 1500 包装器被禁用,允许包装核心正常运行。在适当的情况下,IEEE P1450.6 构造被添加到本标准中,以进一步指导读者。预计读者将参考 IEEE P1450.6 中记录的这些 CTL 构造。

Additional discussion that complements the body of this standard are presented in annex clauses:

— Annex A contains the legend for IEEE 1500 wrapper cells.

— Annex B shows examples of IEEE 1500 wrapper cells.

— Annex C presents similarities between IEEE Std 1500 and IEEE Std 1149.1 and discusses an example interface between IEEE Std 1500 and IEEE Std 1149.1.

附录条款中提供了对本标准主体的补充讨论:
— 附录 A 包含 IEEE 1500 包装器单元的图例。
— 附录 B 显示了 IEEE 1500 包装器单元的示例。
— 附录 C 介绍了 IEEE Std 1500 和 IEEE Std 1149.1 之间的相似之处,并讨论了 IEEE Std 1500 和 IEEE Std 1149.1 之间的示例接口。

1.1 Scope

IEEE Std 1500 has developed a standard design-for-testability method for integrated circuits (ICs) containing embedded nonmergeable cores. This method is independent of the underlying functionality of the IC or its individual embedded cores. The method creates the necessary requirements for the test of such ICs, while allowing for ease of interoperability of cores that may have originated from different sources.

1.1 范围
IEEE Std 1500 为包含嵌入式不可合并内核的集成电路(IC)开发了一种标准 design-for-testability 方法。这种方法独立于 IC 或
它的单独嵌入式内核。该方法为此类 IC 的测试创建了必要的要求,同时
允许可能来自不同来源的内核的互操作性。

1.2 Purpose The aim of IEEE Std 1500 is to provide a consistent scalable solution to the test reuse challenges specific to the reuse of nonmergeable cores, while preserving the IP aspects that are often associated with these cores. This objective is achieved through provision of a core-centric methodology that enables successful integration of cores into SoCs.

1.2 目的
IEEE Std 1500 的目的是为特定于
重用不可合并的内核,同时保留通常与这些内核相关的 IP 方面。
这一目标是通过提供核心中心方法论来实现的,该方法论能够成功地将核心集成到 SoC 中

IEEE Std 1500 provides a bridge between core providers and core users and also facilitates the automation of test data transfer and reuse between these two entities via the use of the IEEE P1450.6 CTL. This automation relies on information requirements (the information model) placed on the core provider to ensure that the core can be successfully integrated by the core user. The result is shorter time to market for core providers and core users.

IEEE Std 1500 在核心提供商和核心用户之间架起了一座桥梁,还通过使用 IEEE P1450.6 CTL 促进了这两个实体之间测试数据传输和重用的自动化。这种自动化依赖于对核心提供商的信息要求(信息模型),以确保核心用户可以成功集成核心。结果是核心提供商和核心用户的上市时间更短。

The data transfer and reuse from the core provider to the core user are based on the premise that the core test data are left unchanged, while the test protocol is adapted from the IEEE 1500 hardware interface to the SoC.

从核心提供者到核心用户的数据搬迁和重用是基于核心测试
数据保持不变,而测试协议从 IEEE 1500 硬件接口适配到
SoC

2. Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies.

IEEE Std 1149.1, IEEE Standard Test Access Port and Boundary-Scan Architecture.2 IEEE P1450.6, Draft Standard for Standard Test Interface Language (STIL) for Digital Test Vector Data— Core Test Language (CTL), http://grouper.ieee.org/groups/ctl/.

EMBEDDED CORE-BASED INTEGRATED CIRCUITS

2. 规范性参考
以下参考文件对于本文件的应用是必不可少的。对于注明日期的参考文献,仅适用引用的版本。对于未注明日期的参考文献,参考文件的最新版本
(包括任何修订或更正)适用。

3. Definitions, acronyms, and abbreviations This clause lists some definitions of terms that have been used throughout this standard. In addition, a list of acronyms and abbreviations is also provided. The criteria for differentiating various terms are based on the following rules:

3. 定义、首字母缩略词和缩写
本条款列出了本标准中使用的术语的一些定义。此外,列表
还提供了首字母缩略词和缩写。区分各种术语的标准基于
以下规则:

a) General terminology in the scope of electrical engineering and/or test technology, which do not influence the definition of this standard itself. 1) These terms are used in this standard without further explanation. It is assumed that the readership has sufficient background knowledge to understand these terms. 2) Some of these terms may already be defined in The Authoritative Dictionary of IEEE Standards Terms. Therefore, someone looking for a particular definition could always consult The Authoritative Dictionary to verify the meaning of the term. b) Terms that are specific to this standard 1) These terms are defined in this clause. 2) General definitions are valid throughout this standard. 3) Local definitions are relevant only to a specific clause of this standard. Effort has been made to achieve consistent usage of all terms (e.g., wrapper, TAM).

a) 电气工程和 / 或测试技术范围内的通用术语,这些术语不会影响本标准本身的定义。

3.1 Definitions

3.1.1 access mechanisms: Mechanisms by which signals may be propagated to and from a core, from either embedded circuitry or from the primary inputs and outputs of the system chip. There are two types of access mechanisms: (a) Functional access: The mechanism for moving stimuli to and observing responses from a core or user-defined logic (UDL) during functional operation or normal mode. b) Test access: The mechanism for moving stimuli to and observing responses from a core or UDL during nonfunctional operation or test mode.

3.1.1 访问机制:信号可通过嵌入式电路或系统芯片的主要输入和输出传入和传出内核的机制。访问机制有两种:
(a) 功能访问:在功能操作或正常模式下,将刺激移至内核或用户定义逻辑 (UDL) 并观察其响应的机制。
b) 测试访问:在非功能操作或测试模式下,将刺激移至内核或 UDL 并观察其响应的机制。

3.1.2 auxiliary clock (AUXCK): A functional clock that may be used in conjunction with wrapper clock (WRCK) during core test for capturing, shifting, updating, and optionally transferring test data in a wrapper.

3.1.3 bypass: As applied to core wrappers, an abbreviated sequential path connecting a wrapper serial input (WSI) to a wrapper serial output (WSO).

3.1.4 captureWR: A wrapper terminal used to enable and control a Capture operation in the selected IEEE 1500 wrapper register (WR).

3.1.5 cell functional input (CFI): For input wrapper cells, the cell’s input, which is connected to a wrapper functional input (WFI); for output wrapper cells, the cell’s input, which is connected to a core output. NOTE—See CFI pin in Figure 16.

3.1.2 辅助时钟 (AUXCK):在核心测试期间可与包装器时钟
(WRCK) 一起使用的功能时钟,用于捕获、移位、更新和可选地传输包装器中的测试数据。
3.1.3 旁路:应用于核心包装器时,连接包装器串行输入
(WSI) 和包装器串行输出 (WSO) 的简化顺序路径。
3.1.4 捕获 WR:用于启用和控制所选 IEEE 1500 包装器寄存器 (WR) 中的捕获操作的包装器终端。
3.1.5 单元功能输入 (CFI):对于输入包装器单元,单元的输入连接到包装器
功能输入 (WFI);对于输出包装器单元,单元的输入连接到核心输出。
注意 — 参见图 16 中的 CFI 引脚。

3.1.6 cell functional output (CFO): For input wrapper cells, the cell’s output, which is connected to a core input; for output wrapper cells, the cell’s output, which is connected to a wrapper functional output (WFO). NOTE—See CFO pin in Figure 16.

3.1.7 cell test input (CTI): A wrapper boundary register (WBR) cell’s test data input.

3.1.8 cell test output (CTO): A wrapper boundary register (WBR) cell’s test data output.

3.1.9 control: The process of applying test pattern stimuli.

3.1.10 core: Predesigned circuit block that can be tested as an individual unit.

3.1.6 单元功能输出 (CFO):对于输入包装器单元,单元的输出连接到核心输入;对于输出包装器单元,单元的输出连接到包装器功能输出 (WFO)。注意——参见图 16 中的 CFO 引脚。

3.1.7 单元测试输入 (CTI):包装器边界寄存器 (WBR) 单元的测试数据输入。

3.1.8 单元测试输出 (CTO):包装器边界寄存器 (WBR) 单元的测试数据输出。

3.1.9 控制:应用测试模式刺激的过程。

3.1.10 核心:可作为单独单元进行测试的预先设计的电路块。

3.1.11 core data register (CDR): Optional data register that belongs to a core being wrapped.
3.1.12 core input: An input terminal of an unwrapped core.
3.1.13 core integrator: An entity that incorporates one or more cores into an system on chip (SoC).
3.1.14 core isolation: A test mode feature preventing core-to-core or core-to-UDL (i.e., user-defined logic)
interaction.
3.1.15 core output: An output terminal of an unwrapped core.

3.1.11 核心数据寄存器 (CDR):属于被包装核心的可选数据寄存器。
3.1.12 核心输入:未包装核心的输入端。
3.1.13 核心集成器:将一个或多个核心整合到片上系统 (SoC) 中的实体。
3.1.14 核心隔离:一种测试模式功能,可防止核心与核心或核心与 UDL(即用户定义逻辑)之间的交互。
3.1.15 核心输出:未包装核心的输出端。

3.1.16 core provider: An entity that designs cores that can be reused in other designs.

3.1.17 core test: A test methodology that is applied to an embedded core.

3.1.18 core test language (CTL): A standard language for core suppliers to provide test data that can be used to test a core once it is integrated into a system on chip (SoC). The language presents a format to describe test and support data so that the core can be effectively integrated, reused and tested. NOTE—See IEEE P1450.6 reference documentation.

3.1.19 dedicated shift path: A shift path comprising storage elements that do not participate in functional operation.

3.1.20 dedicated wrapper (cell): A wrapper style that does not share hardware with core functionality. This style allows certain test operations to occur concurrently and transparently during functional operation. This definition could apply to individual cells.

3.1.16 核心提供商:设计可在其他设计中重复使用的内核的实体。
3.1.17 核心测试:应用于嵌入式内核的测试方法。
3.1.18 核心测试语言(CTL):内核供应商提供测试数据的标准语言,可用于在内核集成到片上系统(SoC)后对其进行测试。该语言提供了一种描述测试和支持数据的格式,以便有效地集成、重复使用和测试内核。
注——请参阅 IEEE P1450.6 参考文档。
3.1.19 专用移位路径:由不参与功能操作的存储元素组成的移位路径。
3.1.20 专用包装器(单元):不与内核功能共享硬件的包装器样式。此样式允许某些测试操作在功能操作期间同时且透明地发生。
此定义可适用于单个单元。

3.1.21 external safe state: A configuration of safe state in which the outputs of a core are in a state that prevents them from interfering with a block of logic outside the core. See also internal safe state; safe state.

3.1.22 firm core: A predesigned block of functional logic such as a macro, megacell, or memory that has a process technology-dependent netlist representation and may be amenable to some modification.

3.1.23 hard core: A predesigned block of functional logic such as a macro, megacell, or memory that has a physical implementation that cannot be modified.

3.1.24 hybrid instruction: A wrapper instruction that has mixed use of wrapper serial port (WSP) and wrapper parallel port (WPP) terminals.

3.1.25 input cell: A wrapper boundary register (WBR) cell that is provided on a core input.

3.1.21 外部安全状态:一种安全状态配置,其中内核的输出处于一种状态,可以防止它们干扰内核外部的逻辑块。另请参阅内部安全状态;安全状态。
3.1.22 硬核:预先设计的功能逻辑块,例如宏、巨单元或存储器,具有

工艺技术相关的网表表示,并且可能适合进行某些修改。
3.1.23 硬核:预先设计的功能逻辑块,例如宏、巨单元或存储器,具有

无法修改的物理实现。
3.1.24 混合指令:混合使用包装器串行端口 (WSP) 和包装器并行端口 (WPP) 终端的包装器指令。
3.1.25 输入单元:在内核输入上提供的包装器边界寄存器 (WBR) 单元。

3.1.26 internal safe state: A configuration of safe state whereby a core is protected from the impact of a test
outside the core. See also external safe state; safe state.
3.1.27 interoperability: See plug-and-play (PnP).
3.1.28 inward facing (IF) mode: The test mode where core inputs are controlled by the wrapper boundary
register (WBR) and core outputs are observed by the WBR.
3.1.29 mergeable core: With respect to testability, a core that can be integrated with other cores and userdefined logic (UDL) into a system on chip (SoC) so that a uniform design-for-test (DFT) methodology can
be applied across the entire system. A typical mergeable core is provided using a register transfer level
(RTL) or gate-level description.
3.1.30 merged core: With respect to testability, a core that is integrated with other cores and user-defined
logic (UDL) into a system on chip (SoC) so that a uniform design-for-test (DFT) methodology could be
applied across the entire system.

3.1.31 nonmergeable core: With respect to testability, a core that cannot be integrated to apply a uniform
design-for-test (DFT) methodology to the entire system on chip (SoC). A typical nonmergeable core comes
with a physical design implementation that does not accommodate modification of the test methodology. A
nonmegeable core may be represented as a block-box design, making standard automatic test pattern generation (ATPG) impossible on such a core.
3.1.32 nonmerged core: With respect to testability, a core that has not been integrated with other cores and
user-defined logic (UDL) into a system on chip (SoC) so that a uniform design-for-test (DFT) methodology
could be applied across the entire system.
3.1.33 normal mode: The mode in which the wrapper boundary register (WBR) does not interfere with the
functional operation of a wrapped core.
3.1.34 observation: The process of monitoring pattern response.
3.1.35 output cell: A wrapper boundary register (WBR) cell that is provided for a core output.

3.1.31 非合并核心:就可测试性而言,无法集成以将统一的可测试设计 (DFT) 方法应用于整个片上系统 (SoC) 的核心。典型的非合并核心带有物理设计实现,无法适应测试方法的修改。非合并核心可能表示为块盒设计,使得在这样的核心上无法进行标准的自动测试模式生成 (ATPG)。
3.1.32 非合并核心:就可测试性而言,尚未与其他核心和用户定义逻辑 (UDL) 集成到片上系统 (SoC) 中的核心,因此无法在整个系统中应用统一的可测试设计 (DFT) 方法。
3.1.33 正常模式:包装边界寄存器 (WBR) 不会干扰包装核心的功能操作的模式。
3.1.34 观察:监控模式响应的过程。
3.1.35 输出单元:为核心输出提供的包装边界寄存器(WBR)单元。

3.1.36 outward facing (OF) mode: The test mode where wrapper functional outputs (WFOs) are controlled by the wrapper boundary register (WBR) and wrapper functional inputs (WFIs) are observed by the WBR.

3.1.37 parallel instruction: A wrapper instruction that uses wrapper parallel port (WPP) terminals and also configures the wrapper bypass register (WBR) between wrapper serial input (WSI) and wrapper serial output (WSO).

3.1.38 pattern set: A collection of test vectors intended for manufacturing test. In the context of core test language (CTL), a pattern set is a collection of pattern constructs and their associated macros and procedures brought together with PatternBurst and PatternExecs.

3.1.39 plug-and-play (PnP): A minimum level of interoperability between various core wrappers in a system on chip (SoC).

3.1.40 safe data: Data that satisfy safe state configuration requirements. These data are user-defined.

3.1.36 向外(OF)模式:一种测试模式,其中包装器功能输出(WFO)由包装器边界寄存器(WBR)控制,包装器功能输入(WFI)由 WBR 观察。
3.1.37 并行指令:一种包装器指令,使用包装器并行端口(WPP)终端,并在包装​​器串行输入(WSI)和包装器串行输出(WSO)之间配置包装器旁路寄存器(WBR)。
3.1.38 模式集:用于制造测试的测试向量集合。在核心测试语言(CTL)的上下文中,模式集是模式构造及其相关宏和程序的集合,与 PatternBurst 和 PatternExecs 一起汇集。
3.1.39 即插即用(PnP):片上系统(SoC)中各种核心包装器之间的最低互操作性级别。
3.1.40 安全数据:满足安全状态配置要求的数据。这些数据是用户定义的。

3.1.41 safe state: A property whereby a test of one block of logic is prevented from interfering with or damaging another block of logic. See also external safe state; internal safe state.
3.1.42 selectWIR: The IEEE 1500 wrapper terminal that determines the selection of a wrapper register
(WR). A value of 1 represents selection of the wrapper instruction register (WIR), and a value of 0 represents selection of a wrapper data register (WDR).
3.1.43 serial instruction: A wrapper instruction that exclusively uses wrapper serial port (WSP) terminals.
3.1.44 serial scan chain: The scan chain configuration inside a wrapped core where an internal scan chain is
concatenated with the wrapper boundary register (WBR) chain for the purpose of running the WS_INTEST_
SCAN instruction.
3.1.45 shared wrapper (cell): The wrapper style that shares logic between the test and functional modes of
operation. Shared cells typically include registered core inputs and outputs that can be used in test mode to
control and observe core test data. This style prevents simultaneous functional and test operation uses of the
shared register.

3.1.41 安全状态:一种属性,通过该属性可以防止一个逻辑块的测试干扰或损坏另一个逻辑块。另请参阅外部安全状态;内部安全状态。
3.1.42 selectWIR:IEEE 1500 包装器终端,用于确定包装器寄存器 (WR) 的选择。值为 1 表示选择包装器指令寄存器 (WIR),值为 0 表示选择包装器数据寄存器 (WDR)。
3.1.43 串行指令:专门使用包装器串行端口 (WSP) 终端的包装器指令。
3.1.44 串行扫描链:包装核心内的扫描链配置,其中内部扫描链与包装器边界寄存器 (WBR) 链连接,以运行 WS_INTEST_
SCAN 指令。
3.1.45 共享包装器(单元):在测试和功能操作模式之间共享逻辑的包装器样式。共享单元通常包括已注册的核心输入和输出,可在测试模式下用于控制和观察核心测试数据。这种样式可防止同时使用共享寄存器进行功能和测试操作。

3.1.46 shiftWR: The wrapper terminal used to enable and control a Shift operation in the selected IEEE
1500 wrapper register (WR).
3.1.47 silent shift path: A wrapper boundary register (WBR) shift path comprising a dedicated shift path
and implemented to support a Shift operation that keeps wrapper functional output (WFO) terminals static.
3.1.48 soft core: A predesigned block of functional logic such as a macro, megacell, or memory with a register transfer level (RTL) representation. Soft cores are inherently process technology independent.
3.1.49 standard test interface language (STIL): The language in IEEE Std 1450™ for representing digital
test vector data. The core test language (CTL) is an extension of STIL to support a standard way of representing test data for a core.
3.1.50 system on chip (SoC): An entire system integrated on a single chip. It may include one or more cores
with user-defined logic (UDL) integrated by the core user or system integrator.

3.1.46 移位WR:用于启用和控制所选 IEEE 1500 包装器寄存器 (WR) 中的移位操作的包装器终端。
3.1.47 静默移位路径:包装器边界寄存器 (WBR) 移位路径,由专用移位路径组成,并实现为支持保持包装器功能输出 (WFO) 终端静态的移位操作。
3.1.48 软核:预先设计的功能逻辑块,例如具有寄存器传输级 (RTL) 表示的宏、巨单元或内存。软核本质上与工艺技术无关。
3.1.49 标准测试接口语言 (STIL):IEEE Std 1450™ 中用于表示数字测试矢量数据的语言。核心测试语言 (CTL) 是 STIL 的扩展,用于支持表示核心测试数据的标准方式。
3.1.50 片上系统 (SoC):集成在单个芯片上的整个系统。它可能包括一个或多个核心,其中由核心用户或系统集成商集成了用户定义逻辑 (UDL)。

3.1.51 test access mechanism (TAM): A feature of a system-on-chip (SoC) design that enables the delivery
of test data to and from cores or core wrappers.
3.1.52 test access mechanism (TAM) harness: Wrapper boundary register (WBR) logic that enables the
coupling of a TAM to cell test inputs (CTIs) and cell test outputs (CTOs).
3.1.53 test input (TI): The serial test data input of a wrapper boundary register (WBR).
NOTE—See TI in Figure 16.
3.1.54 test mode: A configuration whereby a block of logic is made ready for test.
3.1.55 test output (TO): The serial test data output of a wrapper boundary register (WBR).
NOTE—See TO in Figure 16.

3.1.51 测试访问机制 (TAM):片上系统 (SoC) 设计的一种功能,能够将测试数据传送到内核或内核包装器,或从内核或内核包装器传送测试数据。
3.1.52 测试访问机制 (TAM) 线束:包装器边界寄存器 (WBR) 逻辑,能够将 TAM 耦合到单元测试输入 (CTI) 和单元测试输出 (CTO)。
3.1.53 测试输入 (TI):包装器边界寄存器 (WBR) 的串行测试数据输入。
注意 — 参见图 16 中的 TI。
3.1.54 测试模式:一种配置,通过该配置,逻辑块已准备好进行测试。
3.1.55 测试输出 (TO):包装器边界寄存器 (WBR) 的串行测试数据输出。
注意 — 参见图 16 中的 TO。

3.1.56 test protocol: A sequence of control operations required for a test. A test protocol comprises functions and/or sequences. Functions may consist of other functions and/or sequences, while sequences comprise a series of logic 0 and 1 values applied to specified terminals. At the lowest level, a test protocol is just
a series of logic 0 and 1 applied to specified test control terminals. The protocol will typically also contain
symbolic references to the test data that are to be applied to or observed at a specified test data or system
data port. For example, a scan protocol might involve the repetition of the following operations:
a) Apply a logic level to assert an internal scan chain SCAN_ENABLE control signal.
b) Apply a sequence of n clock pulses to a clock port while applying data to the SCAN_DATA_IN of
the scan chain(s). Observe data at the SCAN_DATA_OUT of the scan chain(s) as the data are
clocked through the scan chains.
c) De-assert SCAN_ENABLE and clock the scan chains one or more times while controlling primary
inputs and observing primary outputs.
d) Repeat steps (a), (b), and (c) until the application of the scan chain patterns is complete.
3.1.57 test reuse: The ability to apply a predetermined test pattern associated with a core after this core has
been integrated into a system on chip (SoC). Test reuse is a consequence of design reuse and often requires
the adaptation of a test protocol to reflect the core’s new environment within an SoC.

3.1.56 测试协议:测试所需的控制操作序列。测试协议包括功能和/或序列。功能可能由其他功能和/或序列组成,而序列则包括应用于指定终端的一系列逻辑 0 和 1 值。在最低级别,测试协议只是应用于指定测试控制终端的一系列逻辑 0 和 1。协议通常还包含对要应用于或在指定测试数据或系统数据端口处观察到的测试数据的符号引用。例如,扫描协议可能涉及重复以下操作:
a) 应用逻辑电平以断言内部扫描链 SCAN_ENABLE 控制信号。
b) 将 n 个时钟脉冲序列应用于时钟端口,同时将数据应用于扫描链的 SCAN_DATA_IN。当数据通过扫描链时,观察扫描链的 SCAN_DATA_OUT 处的数据。
c) 取消断言 SCAN_ENABLE 并为扫描链提供一次或多次时钟,同时控制主输入并观察主输出。
d) 重复步骤 (a)、(b) 和 (c),直到扫描链模式的应用完成。
3.1.57 测试重用:在将核心集成到片上系统 (SoC) 后,应用与该核心相关的预定测试模式的能力。测试重用是设计重用的结果,通常需要调整测试协议以反映 SoC 内核心的新环境。

3.1.58 transferDR: The IEEE 1500 wrapper terminal provided to enable and control the Transfer operation
for the wrapper boundary register (WBR).
3.1.60 updateWR: The wrapper terminal used to enable and control an Update operation in the selected
IEEE 1500 wrapper register (WR).

3.1.58 transferDR:IEEE 1500 包装器终端,用于启用和控制包装器边界寄存器 (WBR) 的传输操作。
3.1.59 更新寄存器:用于防止移位寄存器的输出在移位操作期间传播到其他电路的寄存器。移位完成后,相关移位寄存器的内容将并行加载(更新)到更新寄存器中。
3.1.60 updateWR:用于启用和控制所选 IEEE 1500 包装器寄存器 (WR) 中的更新操作的包装器终端。

3.1.61 user-defined logic (UDL): Logic added by the system chip integrator (i.e., not a reused design), as interface circuitry or part of the feature set that differentiates the system-on-chip (SoC) product.

3.1.62 wrapper: Circuitry added around an embedded core to facilitate test reuse and to interface between a test access mechanism (TAM) and the embedded core.

3.1.63 wrapper boundary register (WBR): The portion of a wrapper comprising wrapper cells. See wrapper cell.

3.1.64 wrapper bypass register (WBY): The IEEE 1500 register providing an abbreviated data register between wrapper serial input (WSI) and wrapper serial output (WSO).

3.1.65 wrapper cell: The wrapper element associated with a single core terminal.

3.1.61 用户定义逻辑 (UDL):由系统芯片集成商添加的逻辑(即非重复使用的设计),作为

接口电路或区分片上系统 (SoC) 产品的功能集的一部分。

3.1.62 包装器:在嵌入式核心周围添加的电路,用于方便测试重用以及在

测试访问机制 (TAM) 和嵌入式核心之间进行接口。

3.1.63 包装器边界寄存器 (WBR):由包装器单元组成的包装器部分。参见包装器单元。

3.1.64 包装器旁路寄存器 (WBY):IEEE 1500 寄存器,在包装器串行输入 (WSI) 和包装器串行输出 (WSO) 之间提供简化的数据寄存器。

3.1.65 包装器单元:与单个核心终端关联的包装器元素。

3.1.66 wrapper clock (WRCK): The IEEE 1500 clock.

3.1.67 wrapper configuration: An arrangement of interconnected wrappers in a system on chip (SoC).

3.1.68 wrapper data register (WDR): The IEEE 1500 register [e.g, wrapper boundary register (WBR), wrapper bypass register (WBY)] used to perform IEEE 1500 operations.

3.1.69 wrapper functional input (WFI): The wrapper input terminal corresponding to the functional core input of a wrapped core.

3.1.70 wrapper functional output (WFO): The wrapper output terminal corresponding to the functional core output of a wrapped core.

3.1.66 包装器时钟(WRCK):IEEE 1500 时钟。
3.1.67 包装器配置:片上系统(SoC)中互连包装器的排列。
3.1.68 包装器数据寄存器(WDR):用于执行 IEEE 1500 操作的 IEEE 1500 寄存器[例如,包装器边界寄存器(WBR)、包装器旁路寄存器(WBY)]。
3.1.69 包装器功能输入(WFI):与包装核心的功能核心输入相对应的包装器输入端子。
3.1.70 包装器功能输出(WFO):与包装核心的功能核心输出相对应的包装器输出端子。

3.1.77 wrapper serial input (WSI): The wrapper serial data input.
3.1.78 wrapper serial output (WSO): The wrapper serial data output.
3.1.79 wrapper serial port (WSP): Standard wrapper terminals providing serial access to the IEEE 1500
wrapper. The following signals comprise the WSP: wrapper reset (WRSTN), wrapper clock (WRCK),
SelectWIR, TransferDR, ShiftWR, CaptureWR, UpdateWR, wrapper serial input (WSI), and wrapper serial
output (WSO). Additionally, user-defined auxiliary clock(s) (AUXCKs) may be part of the WSP.

3.1.77 包装器串行输入 (WSI):包装器串行数据输入。
3.1.78 包装器串行输出 (WSO):包装器串行数据输出。
3.1.79 包装器串行端口 (WSP):提供对 IEEE 1500 包装器的串行访问的标准包装器终端。以下信号组成了 WSP:包装器复位 (WRSTN)、包装器时钟 (WRCK)、
SelectWIR、TransferDR、ShiftWR、CaptureWR、UpdateWR、包装器串行输入 (WSI) 和包装器串行
输出 (WSO)。此外,用户定义的辅助时钟 (AUXCK) 可能是 WSP 的一部分。

3.2 Acronyms and abbreviations

ASIC application-specific integrated circuit

ATPG automatic test pattern generation

AUXCK auxiliary clock

CDR core data register

CFI cell functional input

CFO cell functional output

CTI cell test input

CTL core test language

CTO cell test output

DFT design-for-test

FPGA field-programmable gate array

IC integrated circuit IF inward facing

I/O input/output

IP intellectual property

OF outward facing

PnP plug-and-play

RF radio frequency

RTL register transfer level SoC system on chip

STIL standard test interface language

TAM test access mechanism

TAP test access port

TCK IEEE 1149.1 test clock

TI test input

TO test output

UDL user-defined logic

WBR wrapper boundary register

WBY wrapper bypass register

WDR wrapper data register

WFI wrapper functional input

WFO wrapper functional output

WGL waveform generation language

WIR wrapper instruction register

WPC wrapper parallel control

WPI wrapper parallel input

WPO wrapper parallel output

WPP wrapper parallel port

WR wrapper register

WRCK wrapper clock

WRSTN wrapper reset w.r.t with respect to

WSC wrapper serial control

WSI wrapper serial input

WSO wrapper serial output

WSP wrapper serial port

<think>嗯,用户问的是如何在vue.config.js中连接前端和后端。首先,我需要回忆一下Vue.js的配置相关的内容。Vue CLI的项目通常会用vue.config.js来配置开发服务器或者Webpack的设置。连接前端和后端,可能涉及到开发时的代理设置,或者生产环境的API路径配置。 首先,用户可能在开发环境下遇到跨域问题,因为前端和后端可能运行在不同的端口上。这时候,配置devServer的proxy是一个常见的解决方案。代理可以帮助将前端的请求转发到后端服务器,避免跨域限制。比如,设置proxy将/api路径的请求转发到http://localhost:3000,这样前端调用/api/users就会转到后端。 然后,用户可能想知道生产环境的配置。这时候,前端需要知道后端API的地址,可能通过环境变量来设置。比如,使用.env文件来定义不同的环境变量,然后在代码中通过process.env.VUE_APP_API_BASE_URL来获取,这样在构建时就能根据环境自动切换。 另外,可能需要处理跨域的其他配置,比如changeOrigin和pathRewrite。changeOrigin设置为true可以修改请求头中的host为目标URL的host,这对于某些后端服务器检查host的情况是必要的。pathRewrite可以重写请求路径,比如去掉/api前缀,如果后端路由没有这个前缀的话。 用户可能还会混淆开发环境和生产环境的配置。需要明确说明,devServer的proxy只在开发时起作用,生产环境需要另外配置,比如使用Nginx反向代理或者调整API的基础URL。 还可能要考虑是否使用axios或者fetch来发起请求。这时候需要示例代码,展示如何在前端代码中使用配置的代理环境变量。比如,在axios中设置baseURL为process.env.VUE_APP_API_BASE_URL或者相对路径/api,这样在开发和生产环境下都能正确发送请求。 还需要提醒用户关于环境变量的命名规则,必须以VUE_APP_开头,否则不会被加载。同时,修改vue.config.js后需要重启服务才能生效。 总结一下,回答需要分步骤:首先配置开发环境代理,然后处理生产环境的基础URL,接着给出代码示例,最后补充注意事项。这样用户就能清楚如何连接前后端,并解决跨域问题,同时适应不同环境的需求。</think>在 Vue CLI 项目中,`vue.config.js` 主要用于配置前端工程化相关设置(如 Webpack 配置)。**连接前端与后端的核心需求通常体现在以下两个场景**: --- ### 1. 开发环境跨域代理(解决跨域问题) 当你的前端开发服务器(如 `localhost:8080`)需要请求后端 API(如 `localhost:3000`)时,浏览器会因**同源策略**阻止跨域请求。此时可通过 `devServer.proxy` 配置代理: ```javascript // vue.config.js module.exports = { devServer: { proxy: { // 将 /api 开头的请求代理到后端服务器 '/api': { target: 'http://localhost:3000', // 后端地址 changeOrigin: true, // 修改请求头中的 Host 为目标地址(通常需要) pathRewrite: { '^/api': '' // 可移除路径中的 /api 前缀(按需配置) } } } } } ``` **前端代码调用示例(使用 Axios)**: ```javascript axios.get('/api/users') // 会被代理到 http://localhost:3000/users ``` --- ### 2. 生产环境 API 地址配置 生产环境中,通常需要根据部署环境动态设置后端 API 地址。建议使用 **环境变量** 管理: 1. **创建环境变量文件** 在项目根目录创建 `.env.production`(生产环境)和 `.env.development`(开发环境): ```ini # .env.production VUE_APP_API_BASE_URL = '/api' # 生产环境 API 基础路径(可能需要配合 Nginx 反向代理) # .env.development VUE_APP_API_BASE_URL = '/api' # 开发环境使用代理(与 vue.config.js 配置一致) ``` 2. **代码中读取环境变量** ```javascript // 在 Vue 组件或 API 封装文件中 const apiClient = axios.create({ baseURL: process.env.VUE_APP_API_BASE_URL }) ``` --- ### 关键注意事项 1. **代理仅在开发环境生效** `devServer.proxy` 只在 `npm run serve` 时生效,生产环境需通过 Web 服务器(如 Nginx)配置反向代理。 2. **路径重写与后端路由匹配** 使用 `pathRewrite` 时,确保代理后的路径与后端 API 路由匹配(例如移除 `/api` 前缀)。 3. **环境变量命名规则** 自定义环境变量必须以 `VUE_APP_` 开头,否则不会被加载。 4. **修改配置后重启服务** 修改 `vue.config.js` 或 `.env` 文件后,需重启开发服务器才能生效。 --- ### 完整流程示例 1. **开发阶段** - 前端运行在 `localhost:8080` - 后端运行在 `localhost:3000` - 通过代理解决跨域,前端调用 `/api/xxx` 实际请求后端接口。 2. **生产部署** - 前端打包后部署到 Web 服务器(如 Nginx- 配置 Nginx 将 `/api` 请求反向代理到后端服务 - 环境变量指向生产 API 地址(如 `https://api.yourdomain.com`)。 通过以上配置,可实现前后端在不同环境下的无缝对接,同时保持代码环境无关性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值