IP和Soc的概念、安全设计、验证和调试
pre-silicon
带有逻辑仿真的主机代码模式
主机代码模式是一种编译嵌入式系统软件的技术，它不是针对硬件设计中的嵌入式处理器，而是针对主机工作站的。这也称为本机编译。
为了执行协同验证，在主机上运行最终的可执行文件，并将其连接到执行硬件设计的逻辑模拟器。
需要某种类型的进程间通信（IPC）在主机编译的嵌入式软件和逻辑模拟器之间交换信息。
IPC实现可以是一个套接字，它允许两个进程中的每一个位于网络上的不同计算机上，或者是在同一计算机上运行两个进程的共享内存。
主机代码模式不限于使用逻辑模拟器作为硬件执行引擎。可以使用任何硬件执行引擎。
与主机代码模式一起使用的其他一些工具是加速器/仿真器和原型平台。
在主机代码模式下，硬件执行引擎中使用了总线功能模型来为微处理器的总线接口创建总线事务。
主机编译程序与总线功能模型的组合用作微处理器模型.
主机代码模式为软件和硬件工程师提供了一个诱人的环境。
软件工程师可以继续使用他们已经在使用的软件工具，包括源代码调试器以及主机上的其他开发和调试工具。
硬件工程师还可以在设计过程中使用已经使用的工具。 Verilog或VHDL逻辑模拟器以及相关的调试工具。
这对两组工程师都要求最小的方法更改，并且可以使软件和硬件验证都受益。
当处理器尚不存在时，进行硅前验证的能力将是一个很大的好处。 基本架构如图4-8所示。
当软件不通过微处理器总线访问硬件设计，而是通过诸如PCI之类的通用总线接口访问硬件设计时，也可以使用主机代码模式。
许多芯片没有嵌入式微处理器，但是设计时将PCI总线作为可编程寄存器的主要接口。
在这种情况下，软件可以在主机上运行，并且可以在硬件执行引擎中将对软件的读写操作转换为PCI总线事务。
这是一个很好的例子，说明何时将软件执行抽象到主机并将其链接到PCI接口上的硬件执行是有用的。
主机代码模式要求嵌入式软件通过总线功能模型访问硬件设计时，需要对其进行修改以执行功能调用。
如果已经有很多嵌入式软件，那么进行特定函数调用的过程可能会很痛苦，或者如果代码是从头开始编写的，
并且所有内存访问都经过编码以进行通用函数调用，那么这种过程可能会很麻烦，或者几乎没有问题。
图4-9中显示了用于主机代码执行的C库调用示例。
参考书籍：
- Co-Verification of Hardware and Software for ARM SoC Design-Elsevier (2005).pdf
- System-on-Chip Security_ Validation and Verification-Springer International Publishing (2020).pdf
post-silicon
SoC与IP安全的格局landscape
设备类型：手机，平板电脑，消费品(冰箱，灯泡，恒温器)，可穿戴设备
使用场景：购物，银行业务，跟踪，提供行车路线
只能健身跟踪器记录数据：脉搏率，位置，速度
soc设计由硬件和软件模块组成，通常称为design intellectual properties 或者design IPs (IPs for short)
明显的ip包括: cpu, 内存controller, dram, 外设控制器。 IP可以指代任何独立子组件的模块，soc设计
架构需要将各个ip连接，为了实现这些连接，需要network-on-chip(NOC)，为IP提供标准化的消息基础结构以协调并合作定义完整的系统功能。
soc设计是通过获取许多第3方ip实现的，这些ip设计包括硬件组件(用vhdl或verilog之类的硬件描述语言编写)，软件组件，固件firmware。
硬件设计由OEM原始设备制造商或者平台开发商完成。
soc的供应链包括：ip提供商， soc集成公司， 代工厂，和oem。
代表性的soc设计包括： 《--》 jtag scan 《--》 arm processor 《--》 voltage regulator 《--》
外设bridge | 《--》 内存控制器 《--》 ebi 《--》
| 《--》 内存控制器 《--》 sram 《--》
| 《--》 内存控制器 《--》 flash 《--》
《--》 pio 《--》 ethernet mac 《--》 | 《--》 can 《--》 ebi 《--》
《--》 pio 《--》 uart0-1 《--》 | 《--》 usb device 《--》 pio 《--》
《--》 pio 《--》spi 《--》 | 《--》 pwm ctrl 《--》 pio 《--》
设计复杂性的挑战
cpu仅仅代表soc设计中大量ip之一，添加交叉设计功能如电影管理，性能优化，多个voltage islands，时钟逻辑等都导致复杂性增加。
现代SoC设计中的安全性验证
安全验证活动的关注点：1. 要保护的asset有哪些？ 2. 对哪些攻击需要防范？
| Usages | Assets Exposed |
| Browsing | Browsing history |
| Fitness tracking | Health information,sleep pattern |
| GPS | Location |
| Phone call | Contacts |
| Banking,Stock trading | Finances |
Fig. 2.1 Some typical smartphone applications and corresponding private end user information
在智能手机领域的oems和制造商，不希望泄漏的的信息有：加密方式， drm keys， premium content lock，固件执行流，
调试模式等。
供应链安全威胁 SoC从概念到部署的生命周期涉及许多安全性 涉及各方的各个阶段的威胁。图2.2b显示了SoC的生命周期 以及贯穿整个生命周期的安全威胁。 在SoC设计过程中，越来越依赖可重用的预验证硬件IP， 通常会从不受信任的第三方供应商那里收集，严重影响 SoC计算平台的可信度。由于IP越来越复杂 以及SoC集成过程中，SoC设计人员越来越倾向于对待这些 IP作为黑匣子，依赖IP供应商的结构/功能完整性 这些IP。但是，这样的设计实践大大增加了不受信任的数量 SoC设计中的组件，使整个系统安全成为紧迫的问题 岑 从不受信任的第三方供应商处获得的硬件IP可以具有多种安全保护措施。 IP设计过程可以故意插入恶意植入物或对设计进行修改， 以合并隐藏/不需要的功能。此外，由于许多 IP供应商是小型的供应商，他们的工作进度非常积极， 确保在此生态系统中严格的IP验证要求是困难的。 设计功能可能还会引入意外漏洞，例如，信息漏洞 通过隐藏的测试/调试接口或通过旁通道的 功率/性能profile。同样，IP可以具有未表征的参数。 攻击者可以利用这些行为（例如，功率/热量）导致无法恢复的行为 严重损坏电子系统。有记录的实例 攻击。例如，2012年，一组研究人员在剑桥进行的一项研究 在高度安全的军用级中发现了一个无证的硅级后门 MicroSemi的ProAsic3 FPGA器件（以前是Actel），后来 描述为片上调试基础设施无意间导致的漏洞 。在最近的一份报告中，研究人员证明了这种攻击， 会通过影响固件来破坏其处理器的 电源管理系统[3]。它为IP展示了一种新的攻击模式，其中固件/软件更新可能会恶意影响功率/性能/温度用来破坏系统 受信任和不受信任的CAD工具会给SoC设计带来类似的信任问题。 此类工具旨在优化功耗，性能和面积的设计。 在当今的工具中，安全性优化不是一个选择，因此有时在 优化中引入了新的漏洞。例如，在将设计外包给测试设计设施的情况下 Design-for-Test(DFT) or Design-for-Debug (DFD)的插入会 损害soc的完整性。 安全策略：设计要求
CIA范式：
∙ Confidentiality: 除非获得授权，否则代理商无法访问资产 所以。
∙ Integrity: 资产可以变异（例如，安全存储位置中的数据可以 只能由授权的代理商修改）。
∙ Availability: 资产必须可供需要以下访问权限的代理访问： 正确的系统功能的一部分。
2个例子说明以上准则：
example 1 在启动期间，加密引擎传输的数据无法
被SoC中的任何其他ip观察到，除了目标ip可观察到数据。
example 2 包含安全密钥的可编程fuse可以在制造过程中进行更新，
不能在生产后更新。
示例1是保密性的一个实例，而示例2是保密性的一个实例
诚信政策；但是，这些策略处于较低的抽象级别，因为它们
旨在翻译为“可操作的”信息，例如架构或设计
特征。上面的示例（尽管是假设的）说明了一个重要特征-
安全策略的逻辑：同一个代理可能会或可能不会被授权访问（或
更新）取决于（1）执行的阶段（即，
开机或正常），或（2）设计生命周期的阶段（即制造或制造
）。这些因素使安全策略难以实施。
SOC debug架构
post-silicon 调试可以在产品不同周期阶段进行：包括post-silicon验证，
laboratory bring-up, application software
debugging by authorized developers, and field return evaluation收益评估.
旨在发现的问题：功能bugs，电气errors，性能issues，软件bugs，以及未解决的缺陷制造测试。