1.片上系统设计思想与源代码分析书目录
2.IPSOC中的IP
3.谷歌Pixel 2的定制相机SoC真的是由英特尔生产的吗？
4.Versal 自适应 SoC AI 引擎系列 1 - 从 AI 引擎工具开始（2022.1 更新）
5.小白自制Linux开发板 ：Linux内核与文件系统移植
6.Android VNDK/VSDK Snapshot编译框架

片上系统设计思想与源代码分析书目录

       本书《片上系统设计思想与源代码分析》详细探讨了片上系统的设计与实现。第一章首先介绍了片上系统的基础知识，包括集成电路技术的发展、基本概念、设计方法的进步以及设计中的关键问题。DemoSoC作为示例，开源版源码讲解了嵌入式控制器、架构、存储器映射、总线优先级以及代码更新与调试等内容。

       第二章聚焦开源嵌入式处理器OpenRISC ，详细解析了其架构特点、寻址模式、寄存器集、指令集等，并介绍了0R处理器的核心特性，如CPU/DSP核心、内存管理、高速缓存和调试单元等。

       第三章深入探讨片上总线技术，如WISHBONE总线的基本特点、信号定义、互联类型和操作周期，以及与RAM/ROM的交互方式。此外，还提供了接口示例和总线连接设计的深入讲解。

       第四章和第五章分别详细解析了NandFlash和SDRAM控制器，涉及器件原理、操作、设计源代码分析以及验证过程。红绿柱变色源码这些章节详细展示了片上系统中存储器管理的复杂性。

       后续章节涵盖了IIS音频控制器、LCD控制器等接口设计，以及DMA控制器、USB控制器等高级功能。最后两章展望了片上系统技术的未来发展趋势，并提供了相关技术的补充教程。

扩展资料

       《片上系统设计思想与源代码分析》采用Verilog/SystemVerilog和SystemC语言，讲述SoC的设计思想并分析其源代码。本书将片上系统最常见的模块组织起来构成完整的SoC(DemoSoC)，并以DemoSoC为例，讲述片上系统的设计思想和设计方法。并对DemoSoC进行了完善的FPGA验证。

IPSOC中的IP

       IP在IPSOC（集成片上系统）中扮演着至关重要的角色，为了满足TTM（时间到市场）的要求，SoC（系统级芯片）设计需要采用新的设计方法学以提高效率。在多采用基于平台设计方法的同时，集成已设计好的模块，这些模块被称为IP（知识产权）核。IP核根据其特性和功能，主要分为以下几类：

       1. 软核（Soft IP）：以可综合的HDL形式交付，具有更高的灵活性，但在性能（时序、面积、功耗）方面具有不确定性。使用软核增加了知识产权保护的风险，因为使用者可能需要RTL（硬件描述语言）源代码。

       2. 固核（Firm IP）：这类IP核通常已经经过了功耗、尺寸和性能的神武4源码泄漏优化，并以GDSII（光罩数据系统）的形式交付，具有更可预测的优点，但灵活性和可移植性较低，因为它们与特定的工艺相关。

       3. 硬核（Hard IP）：这类IP核在功耗、尺寸和性能方面经过了优化，并且映射到特定工艺，以GDSII形式交付，拥有更可预测的优点，但也具有较低的灵活性和可移植性，由于版权保护，保护硬核的能力更好，且通常不需要RTL代码。

       IP的来源多样，主要包括：

       1. 芯片设计公司的自身积累：公司内部的研发团队可能拥有独特的IP核。

       2. Foundry的积累：专业的晶圆厂（Foundry）可能会拥有特定工艺的IP核，供设计公司使用。

       3. 专业IP公司：专门提供IP核的公司，为设计公司提供广泛的选择。

       4. EDA厂商：电子设计自动化（EDA）厂商可能提供设计工具和IP核，以支持设计流程。

       5. 设计服务公司：提供设计服务的公司也可能拥有特定的IP核，为客户提供一站式服务。

扩展资料

       IP是英文Internet Protocol（网络之间互连的协议）的缩写，中文简称为“网协”，也就是为计算机网络相互连接进行通信而设计的协议。在因特网中，它是能使连接到网上的所有计算机网络实现相互通信的一套规则，规定了计算机在因特网上进行通信时应当遵守的游戏源码剖析02规则。任何厂家生产的计算机系统，只要遵守 IP协议就可以与因特网互连互通。IP地址具有唯一性，根据用户性质的不同，可以分为5类。另外，IP还有进入防护，知识产权，指针寄存器等含义。

谷歌Pixel 2的定制相机SoC真的是由英特尔生产的吗？

       揭秘Pixel 2的创新相机心脏：英特尔技术的独家合作

       谷歌的Pixel 2凭借其卓越的摄像头性能一跃成为智能手机摄影的翘楚，而它的秘密武器并非仅限于Snapdragon 。这款手机内部隐藏着一颗专为相机打造的SoC，即“Pixel Visual Core”，它是谷歌历史上的首枚消费级图像处理芯片。

       尽管并非自研，英特尔与谷歌的联手却揭示了一个科技巨头间的深度合作。美国消费者新闻与商业频道揭示，这款神秘芯片的背后，正是英特尔的智慧与谷歌的创新理念的交融。代号“Easel”的Pixel Visual Core，它的存在已经在安卓源代码中悄然显现，藏于platform/硬件/谷歌/画架的代码路径中。

       在设备树的二进制文件中，我们发现了“MonetteHill”这一英特尔代号，进一步印证了英特尔在这款SoC中的关键角色。尽管Pixel Visual Core目前尚未完全激活，但随着安卓8.1的发布，它的8核图像处理单元（IPU）将带来革命性的改变。IPU将以五倍的搭建流量卡源码速度运行，同时消耗的能量仅为传统CPU的十分之一，为谷歌的shdr图像处理和机器学习功能提供了强大的可编程平台。

       谷歌对相机技术的执着追求与英特尔的硬核实力相结合，无疑为Pixel 2的影像体验增添了无与伦比的深度和效率。让我们期待这款定制SoC在未来的像素世界中，如何释放出更多摄影的可能。

Versal 自适应 SoC AI 引擎系列 1 - 从 AI 引擎工具开始（.1 更新）

       AI 引擎系列简介

       本文旨在介绍 Versal 自适应 SoC AI 引擎系列，具体聚焦于集成在 Vitis™ 统一软件平台中的 AI 引擎工具。旨在通过实践示例，帮助读者理解如何在 Versal 上使用这些工具进行 AI 应用程序的编程。

       要求

       为了完成本教程，您需具备以下条件。

       简介

       将 Versal 系统分为三个主要领域：AI 引擎 (AIE) 域、处理器系统 (PS) 域和可编程逻辑 (PL) 域。在 Versal 上运行 AIE 应用程序，需要这三个领域协同工作。

       教程：AMD 工具简介

       步骤一：在 Vitis .1 IDE 中启动，并选择工作空间存储库。

       步骤二：若未显示“欢迎”页面，请选择“文件”>“新建”>“应用工程”。

       步骤三：在“欢迎”页面，点击“下一步”。

       步骤四：在平台选择页面，选择 xilinx_vck_base__1 平台，或如未列出，请添加该平台。

       步骤五：在“域”页面，继续进行。

       步骤六：创建名为“simple_application”的新应用，并选择“ai_engine”作为目标处理器，点击“下一步”。

       步骤七：在“模板”页面，选择“简单”模板，完成设置。

       重要提示：此模板适用于 AIE 仿真和 SW (x)。确保导入了所需文件：AI 引擎应用、源文件目录、内核源代码目录和仿真文件目录。

       步骤八：在项目文件中定义顶层文件，此文件包含顶层计算图的例化。

       步骤九：打开项目.cpp 文件，获取完整语法描述，参考《AI 引擎工具和流程用户指南》(UG)。

       步骤十：在项目文件中，添加头文件，包含 adf 数据流库、内核函数原型和顶层计算图声明文件。主函数运行计算图四次，终止程序。

       在后续系列中，我们将深入探讨计算图与内核之间的关系。

小白自制Linux开发板 ：Linux内核与文件系统移植

       Linux内核

       若要移植F1CS/F1CS至Linux，可直接利用官方源码对licheepi nano的支援。首先，访问kernel.org下载最新长支版本内核源码（建议使用5..），若使用特定版本，如5.7.1，则可直接下载对应链接。解压后，将内核源码复制至Ubuntu虚拟机。

       配置编译

       在Linux内核代码中找到Makefile文件，修改ARCH和CROSS_COMPILE配置为Arm，使用编译工具交叉编译。完成内核配置后，下载licheepi_nano的配置文件，放置于arch/arm/configs目录下。使用图形化配置界面完成内核与开发板soc的对应配置。

       配置TF卡设备树信息

       在arch/arm/boot/dts目录下修改suniv-f1cs.dtsi和suniv-f1cs-licheepi-nano.dts文件，添加相应的头文件与配置选项。确保内核编译成功，生成zImage和dtb文件。

       TF分区配置

       通过Gparted软件分区，将TF卡分为两个分区，一个用于存放zImage、dtb文件，另一个用于根文件系统。格式化为fat和ext4，确保正确分配分区大小并保存配置。

       内核复制与执行

       将内核文件复制至TF卡的BOOT分区，插入开发板后，通过u-boot启动并自动进入内核启动环节。确保TF卡根文件系统正确挂载。

       文件系统移植

       使用Buildroot制作根文件系统，选择目标选项、编译选项、工具链与系统配置，确保文件系统兼容并能正常挂载。构建完成的根文件系统镜像解压至TF卡第二分区。

       执行与升级

       登录自制Linux系统，通过修改/etc/profile文件调整命令行显示。运行GPIO实验，利用Linux GPIO子系统实现LED灯的点灯功能，探索Linux内核的驱动实现。

       总结

       完成了Linux内核与文件系统的移植，从内核配置到文件系统挂载，再到驱动实验，逐步实现自制Linux开发板的操作系统。后续将升级硬件设备并进行更有意义的项目开发，期待你的进步。

Android VNDK/VSDK Snapshot编译框架

       为了解决Android版本碎片化问题，引入了Treble架构。此架构提供了稳定的新SoC供应商接口，并引入了HAL接口定义语言（HIDL/Stable AIDL），用于指定vendor HAL 和system框架的接口，实现了system框架与Vendor HAL的解耦，使Vendor Freeze成为可能。然而，经过调查发现，AOSP源码的vendor组件有%~%的仓库与system组件耦合，这对架构的灵活性和稳定性产生了影响。Google进一步对Treble架构进行演进，引入了VNDK和VSDK的snapshot方案，旨在增强system/vendor组件之间的interface化能力。system组件通过预编译形成vendor Snapshot，可以提供给不同Android版本的vendor组件使用，这也是Treble方案落地的一个重要环节和基础支撑。

       VNDK提供了对Native库进行划分的概念，以达到管控system/vendor组件之间模块耦合度的目的。主要包括core library、vendor-only(proprietary) library、vendor_available library、vndk library和vndk-sp library。这些类别的划分定义了不同类型的相互耦合程度和使用约束，使得system和vendor组件的功能更加独立。

       VSDK则是在VNDK的基础上进一步扩展，包含了Vendor Snapshot。Vendor Snapshot包括系统源码维护的用于Vendor编译或集成的Native模块集合。这些模块主要由系统库、vendor可用库和vndk模块构成，其中vndk模块的使能与vendor模块的直接使用密切相关。

       Snapshot设计旨在解决system和vendor不同时间、不同版本编译搭配的问题。通过预构建系统侧的库，用于vendor侧的编译，减少对system侧源码的依赖。这可以通过两种方法实现：一种是将system仓库直接包含在vendor的manifest文件中，使用旧版本的代码；另一种是使用Google的Snapshot设计，由system侧预构建生成vendor所需的内容，用于vendor侧编译。两种方法各有优缺点，前者简单直接，但可能导致vendor代码量增加和编译时间延长；后者代码量更精简，编译时间短，但需要额外的预构建系统支持。

       Snapshot生成流程可以分为三个阶段：Generate Phrase、Install Phrase和Use Phrase。Generate Phrase阶段通过一定的规则从系统侧源代码中产生出vendor image编译依赖的预置编译模块产物。Install Phrase阶段通过py脚本将生成的prebuilt模块安装到指定源码目录，并生成对应Android.bp文件。Use Phrase阶段通过设置BOARD_VNDK_VERSION变量为具体版本号，触发编译系统使用预先生成的Snapshot参与编译。

       VNDK Snapshot生成流程中，生成逻辑在soong/cc/vndk.go中通过定义VndkSnapshotSingleton实现，最终生成的bp文件包含了vndk_prebuilt_shared模块的配置信息，用于vendor侧的编译。VSDK Snapshot的生成逻辑与VNDK类似，主要通过vendor_snapshot.go的GenerateBuildActions方法实现，同样通过设置BOARD_VNDK_VERSION变量进行编译。

       总的来说，VNDK/VSDK Snapshot的引入和设计旨在减少system和vendor组件之间的源码依赖，减少编译依赖，更容易形成Treble基线。这为构建更稳定、更高效的Android生态系统提供了有力支持。