FPGA光通信2——Aurora 64B/66B的开发使用

FPGA光通信2——Aurora 64B/66B的开发使用

可参考GZH:小蘇的FPGA

        FPGA光通信的开发过程中,最简便的方式为Aurora 64B66B,开发人员无需关注2bit同步头,加解扰等过程,开放给开发人员的主要是AXI-Stream用户数据接口。

        Aurora是一款可扩展的轻量级、高数据速率链路层高速串行通信协议,支持全双工或单工,支持64B/66B,8B/10B编码。

一、Aurora 64B/66B使用介绍

        该核的使用架构主要如下:借助xilinx 核,开发人员可根据用户接口实现多通道间的光通信。最大支持16lane。

1.1 、IP核的介绍

        参考PG074, 该核的内部结构如下:

        其中,Lane logic:每个GT收发器由一个lane逻辑模块实例驱动,初始化每个收发器,处理控制字符的编解码,并执行错误检测。

        Global logic: 全局逻辑模块执行通道绑定以进行通道初始化。在运行过程中,该通道跟踪Aurora 64B/66B协议定义的Not Ready空闲字符,并监控所有通道逻辑模块的错误。

        RX user interface: AXI4-Stream接收用户数据从通道移动到应用程序,并执行流控制功能。

        TX user interface: AXI4-Stream发送用户数据从应用程序移动到通道,并执行TX的流量控制功能。

1.1.1、接口

        IP核如下(不同版本界面有差异,但含义相同):

        主要的接口信息如下,具体含义可查看PG074。

        用户数据接口:USER_DATA_S_AXIS_TX(数据发送)、USER_DATA_M_AXIS_RX(数据接收)

        GT BANK管脚:GT_SERIAL_RX、GT_SERIAL_TX、REFCLK

        控制接口:CORE_CONTROL(回环模式等)

        控制接口:CORE_STATUS

        重配置端口:GT_DRP(比如动态切换线速率场景)

        剩下的为复位、时钟接口:

        INIT_CLK:初始化时钟,来源不同于GT BANK;

        USER_CLK/SYNC_CLK:用户时钟,LineRate × LaneNum x (64/66)/LaneWide,其中USER_CLK为用户收发数据时钟;

        pma_init和reset_pb:复位信号,后文介绍。

       时钟关系如下:

1.1.2 、复位

        复位接口为pma_init和reset_pb,高电平复位释放前要求INIT_CLK和REFCLK保持稳定;先释放pma_init(gt_reset),后释放reset_pb(reset),reset_pb的释放同步于USER_CLK,pma_init复位信号同步于INIT_CLK。

        pma_init的复位会重置收发器的所有物理编码子层(PCS)和物理介质附件(PMA)子组件,即会先复位高速收发器,后复位内核逻辑。而reset_pb只会复位内核逻辑,不会复位底层的高速收发器。先释放pma_init,后释放reset_pb。

        不同模式下,复位时序不一样,本文只介绍双工模式的复位时序:上电阶段复位、其他复位。

        双工模式下的正常复位时序如上图所示,先把reset_pb拉高128个时钟周期,然后再拉高pma_init一段时间。之后先拉低pma_init,最后拉低Reset_pb信号。

        如下图所示:双工模式下reset_pb拉高的最短时间为128个user_clk周期。经过一段时间后,channel_up被拉低,表示传输通道建立失效。

        

        如下图所示:双工模式下的pma_init(gt_reset)复位时序,pma_init至少拉高128个init_clk周期。经过一些时钟周期后,user_clk会暂停产生时钟(因为user_clk的时钟来源是GT收发器txoutclk,pma_init复位从底层的物理层复位)。随后拉低channel_up信号,表示传输通道建立失效。

1.1.3 、初始化

        初始化过程如下:

        Lane up表示通道中的哪些通道已完成通道初始化。仅当所有通道和内部逻辑完成整个初始化过程后,channel_up才会被拉高。Aurora 64B/66B内核可以在Channel_up拉高之前接收数据,但Channel_up拉高之前不能发送数据,可把Channel_up取反用作全双工模式下发送端的复位信号。

1.1.4 、控制及状态接口

        loopback:      回环模式,实际使用一般接到0;

        000:normal;001: Near-end PCS Loopback;010: Near-end PMA Loopback;100: Far-end PMA Loopback;110: Far-end PCS Loopback

        power down: 高电平有效。当其为高时,GT会进入非工作、低功耗的模式。使用的时一般直接拉低。

        pll_not_locked 接 ~pll_locked ;

        lane_up:        "1”状态指示各通道初始化成功,每位代表一个通道

        channel_up:  “ 1”状态指示通道初始化完成,通道已准备好进行数据传输

        hard_err:       主要是硬件类错误

        soft_err:        主要是软件类错误

        frame_err:     当前通道帧协议错误

1.1.5 、数据接口

        该核支持两类数据接口:

        Framing接口:在AXI4-Stream的基础上IP核自动加入帧头、帧尾,并在固定时间内完成时钟补偿,但是会降低传输效率和使用较多资源。

        Streaming接口:简化的AXI4-Stream接口,只有数据有效、握手和数据信号,此种方式传输效率高,但无法保证传输的准确性。

           本文只介绍Frame类型接口,即用户接口类型为AXIS模式。由于64B/66编码,aurora的设计上在发送端需要ready信号握手。发送端用户只需要在发送、接收双方完成握手后,即可发送数据,通信双方均可通过握手信号来反压对方;接收端用户仅需要在valid信号有效时从总线上拿数据即可

        当s_axi_tx_tready反压与s_axi_tx_tvalid握手成功后,即可发送数据,使用s_axi_tx_tlast来表示当前发送最后一个数据,s_axi_tx_tkeep来表示最后一个数据的有效字节。

        接收数据:当m_axi_rx_tvalid为高时,接收的数据是有效数据,可以拿来用了,m_axi_rx_tkeep与m_axi_rx_tlast的用法与发送端对应的信号一致。

1.2 IP核配置

        根据本人开发板原理图配置如下:

    GT Refclk :GT参考时钟,板子时钟为156.25Mhz

    Lane Rate : 以10.3125Gbps作为测试

    INIT clk    :初始化时钟,根据工程自行选择设计

    GT位置及lane数目:根据板子原理图设计

    Dataflow Mode:选择全双工

    Interface:Framing类型

    流控:不使用

        little Ednian support:小端数据(小端:[15:0] 大端:[0:15])

        动态重配置接口类型

        Debug信号

        CRC功能

        Shared Logic:设置IP的逻辑放置的位置,如果GT REFCLK没被别的serdes使用,两种模式都行,否则建议In example design模式。

         In core:在IP核内:support、复位、时钟等逻辑包含在ip内

         In example design:在例子中,support、复位、时钟等逻辑都在ip外

1.3 参考例子

        主要参考support、复位、时钟的使用。

        support模块:包含了对时钟、复位、IP等的例化处理等一系列操作;在应用中此部分可不需要修改。

        frame_gen数据生成模块,采用LFSR的方式生成伪随机序列;在实际工程中替换为自己的数据模块即可。

        frame_check数据检验模块,对接收的数据进行检验以验证传输的正确性;在实际工程中替换为自己的数据模块即可。

二、工程设计、测试

2.1 、工程设计

        按照上述配置的上进行设计,收发数据流程为,当Channel_up拉高后,可通过VIO使能控制data_test_module测试数据模块产生测试数据。

        data_test_module:当FIFO非空时写入递增数据,根据AXIS接口的ready反压信号读FIFO到Aurora IP核。

2.2 、仿真测试

        对上述工程进行自回环收发仿真测试:

        初始化及收发过程:

        复位关系、状态信号:

        发数据:ready和valid

        收数据主要关注data、valid、last、keep等信号。

2.3 、上板测试

        通过VIO使能控制data_test_module测试数据模块产生测试数据。

        接收到的数据:与发送数据一一对应。

三 、 总结

        有需要代码的请私聊。

可参考GZH:小蘇的FPGA

FPGA实现Aurora光通信应用(8B/10B)

UltraScale/+ FPGA实现万兆网的两种方式:GT核、10G Ethernet Subsystem核

FPGA实现100G UDP通信

FPGA 40G/50G Ethernet Subsystem核的使用

FPGA实现千兆网UDP协议(含ARP、ICMP)

JESD204B的使用系列——3、DAC的应用(AD9164 9.6GSPS)

JESD204B的使用系列——2、协议及ADC的应用(AD9689)

JESD 204B的使用系列—1、时钟芯片的应用

FPGA外挂存储器应用3——NVMe协议 M.2硬盘的读写功能测试

Read more

全球AI绘画与多模态开发指南:详解 /v1/chat/completions 接口参数与 4SAPI 实战技巧

在2026年的AI多态创作热潮中,高效开发者对稳定、接口需求已从复杂的文本生成延展到视觉控制与创意落地的全流程。4SAPI作为聚合全球顶尖AI模型的服务平台,其核心接口/v1/chat/completions不仅完美兼容OpenAI接口规范,更无缝支持了AI绘画相关的提示词(提示)工程化、贸易视觉风格定制及多模态需求。 本文将深度拆解该接口的核心参数、调用流程与实战技巧,助你无意中开发中的暗礁,快速构建下一代AI创意工具。 一、接口核心信息速览 * 接口地址:https://4sapi.com/v1/chat/completions * 请求方式:POST * 兼容特性:完全兼容OpenAI API标准,可重构代码即可平滑迁移。支持Claude 4.5、GPT-5.2、Gemini 3.0 Pro等全球30+主流模型。针对绘画场景,推荐优先选择擅长场景描述的增强型模型。 * 核心功能:支持根据自然语言生成精准的绘画提示、风格参数配置,或直接对接多模态模型进行图文交互。支持服务器发送事件(SSE)流式响应、

从论文到实践:Stable Diffusion模型一键生成高质量AI绘画

从论文到实践:Stable Diffusion模型一键生成高质量AI绘画

🏡作者主页:点击!  🤖编程探索专栏:点击! ⏰️创作时间:2024年12月24日10点02分 神秘男子影,   秘而不宣藏。 泣意深不见, 男子自持重,    子夜独自沉。  AI绘画一键生成美图-变成画家 本地部署SD模型,一键即可生成自己想要绘制的图画,本文包括论文原理讲解和代码复现 论文讲解 论文题目:High-Resolution Image Synthesis with Latent Diffusion Models(基于潜在扩散模型的高分辨率图像合成) 论文被计算机视觉顶会CVPR 2022收录 Stable diffusion是一个基于Latent Diffusion Models(潜在扩散模型,LDMs)的文图生成(text-to-image)模型。它建立在自注意力机制和扩散过程的基础上。它的设计灵感来自于扩散过程模型(Diffusion Models),这些模型在自然图像建模领域取得了巨大成功。 Stable Diffusion通过一系列的扩散步骤来生成图像。在每一步中,模型逐渐“扩散”图像,从含有较少信息的噪声开始,到包含更多细节的图像。

技术速递|GitHub Copilot SDK 与云原生的完美融合

技术速递|GitHub Copilot SDK 与云原生的完美融合

作者:卢建晖 - 微软高级云技术布道师 排版:Alan Wang 引言 在当今快速演进的 AI 技术格局中,我们已经见证了从简单聊天机器人到复杂智能体系统的转变。作为一名开发者和技术布道者,我观察到一个正在形成的趋势——重点不在于让 AI 无所不能,而在于让每一个 AI Agent 在特定领域做到极致、做到专业。 今天,我想分享一套令人兴奋的技术组合:GitHub Copilot SDK(将生产级智能体引擎嵌入任意应用的开发工具包) + Agent-to-Agent(A2A)Protocol(实现智能体标准化协作的通信规范) + 云原生部署(支撑生产系统的基础设施)。这三者结合在一起,使我们能够构建真正具备协作能力的多智能体系统。 从 AI 助手到智能体引擎:重新定义能力边界 传统的 AI 助手往往追求“全能”——试图回答你抛给它的任何问题。但在真实的生产环境中,这种方式会遇到严重挑战: * 质量不一致:一个模型同时写代码、做数据分析、

DeepSeek-R1-Distill-Llama-8B在Ollama上的最佳实践

DeepSeek-R1-Distill-Llama-8B在Ollama上的最佳实践 你是否试过在本地快速跑起一个真正擅长数学推理和代码生成的开源大模型,既不用配CUDA环境,也不用写几十行部署脚本?DeepSeek-R1-Distill-Llama-8B 就是这样一个“开箱即用但能力不妥协”的选择——它不是轻量玩具,而是经过严格蒸馏、在AIME和MATH等硬核基准上稳定超越GPT-4o的8B级推理模型。而Ollama,正是让它从镜像变成你日常生产力工具最平滑的桥梁。 本文不讲抽象原理,不堆参数表格,只聚焦一件事:如何在Ollama中真正用好这个模型——从零启动、高效提问、规避常见陷阱、榨取它在数学推导、代码生成和逻辑分析上的全部潜力。 我们全程基于ZEEKLOG星图镜像广场提供的预置镜像 DeepSeek-R1-Distill-Llama-8B,所有操作均可在浏览器中完成,无需命令行、不装依赖、不碰Docker。哪怕你昨天才第一次听说“大模型”,今天也能跑通一条完整的推理链。 1. 为什么是DeepSeek-R1-Distill-Llama-8B?——能力与实用的平衡点 很