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核通常已经经过了功耗、尺寸和性能的手眼标定 源码优化，并以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（网络之间互连的协议）的缩写，中文简称为“网协”，也就是为计算机网络相互连接进行通信而设计的协议。在因特网中，它是能使连接到网上的所有计算机网络实现相互通信的一套规则，规定了计算机在因特网上进行通信时应当遵守的维修oa源码规则。任何厂家生产的计算机系统，只要遵守 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生态系统提供了有力支持。