基于FPGA的CARRY4 抽头延迟链TDC延时仿真

基于FPGA的CARRY4 抽头延迟链TDC延时仿真

基于FPGA的CARRY4 抽头延迟链TDC延时仿真

1 摘要

基于 FPGA 的 CARRY4 抽头延迟链 TDC,核心是利用 Xilinx FPGA 中 CARRY4 进位单元的固定、低抖动级联延迟构建抽头延迟线,通过锁存信号传播位置实现亚纳秒级时间测量,单级进位延迟约 10–30 ps,级联后可覆盖更大时间量程并结合粗计数拓展动态范围。TDC设计利用FPGA的专用进位链硬件,实现了亚纳秒级的时间测量精度,这是传统数字方法无法达到的。虽然需要校准,但其性能优势和数字集成的便利性使其成为高精度时间测量的首选方案。

2 CARRY4 核心结构与抽头延迟链原理

2.1 CARRY4 单元结构(Xilinx 7 系列 / UltraScale)
每个 CARRY4 包含 4 个 MUXCY 进位选择器与 4 个 XORCY 异或门,形成 4 级进位链,CIN 为进位输入,COUT 为级联输出,CO0–CO3 为 4 个抽头输出,可引出每级进位节点信号。级联方式:上一级 CARRY4 的 COUT 接下一级 CIN,形成连续延迟链;抽头 CO0–CO3 分别连接 D 触发器,由停止信号(Stop)或全局时钟同步锁存。

在这里插入图片描述

2.2. 抽头延迟链 TDC 工作原理
①起始信号(Start)从链首 CIN 注入,沿 CARRY4 级联路径以固定延迟传播。
②停止信号触发所有抽头处的 D 触发器锁存当前传播状态,形成 “温度计码”。
③温度计码经编码器转换为二进制细时间值 T_fine,结合粗计数器(如系统时钟计数)得到总时间 T_total=T_coarse+T_fine。

在这里插入图片描述

)

3 Xilinx FPGA CARRY4 单元核

3.1 CARRY4的工作原理
PGA的CARRY4进位单元,每个CARRY4的COUT连接到下一个CARRY4的CIN,这样级联起来,形成延时链。

CYINIT → MUXCY0 → CO[0] → MUXCY1 → CO[1] → MUXCY2 → CO[2] → MUXCY3 → CO[3] ↗ ↗ ↗ ↗ ↗ ↗ ↗ ↗ DI[0] S[0] DI[1] S[1] DI[2] S[2] DI[3] S[3] 

模拟内部结构

`timescale 1ps/1ps module CARRY5( output [3:0] CO, output [3:0] O, input CI, input CYINIT, input [3:0] DI, input [3:0] S ); // 模拟Xilinx CARRY4的行为 reg [3:0] co_int; always @* begin // 传播延迟:每个CARRY4约10ps #10; // CARRY4逻辑 co_int[0] = (CYINIT & S[0]) | (CI & S[0]) | DI[0]; co_int[1] = (co_int[0] & S[1]) | DI[1]; co_int[2] = (co_int[1] & S[2]) | DI[2]; co_int[3] = (co_int[2] & S[3]) | DI[3]; end assign CO = co_int; assign O = co_int; endmodule 

3.2 Xilinx FP

Read more

从‘看得见’到‘看得懂’:PaddleOCR-VL-WEB赋能智能OCR升级

从“看得见”到“看得懂”:PaddleOCR-VL-WEB赋能智能OCR升级 在银行票据处理中心、政务服务中心的档案科、电商商家后台,每天有数以万计的合同、发票、身份证、说明书、学术论文被扫描上传。过去,这些图像交由传统OCR系统处理——结果是一长串无序文字,像打翻的铅字盒:你能看见所有字符,却不知道哪一行是金额、哪个框是签章位置、表格里哪列对应税率、公式中哪个符号是求和变量。 而今天,一张PDF截图上传后3秒内,系统不仅返回清晰文本,还自动标注出“标题层级”“段落类型”“表格结构”“数学公式语义”“图表说明文字”,甚至能回答“这份采购合同的付款条件是什么?”——这不再是OCR,而是文档理解(Document Understanding)。 PaddleOCR-VL-WEB 镜像正是这一跃迁的关键载体。它不是对旧OCR的简单提速,而是用视觉-语言联合建模,把“图像识别”升级为“文档认知”。它不只告诉你“这里有一行字”,更告诉你“这行字是条款编号,属于第3条违约责任下的子项”

PyWebview浅谈

PyWebview浅谈

pywebview是一个轻量级、跨平台的 Python 库,核心功能是在桌面应用中嵌入系统原生的 WebView 组件,让你可以用 HTML/CSS/JavaScript 构建 UI,同时用 Python 处理逻辑——完美匹配“Web 技术做 UI + Python 做后端”的需求。 1. 核心定位 pywebview 不是“打包 Chromium 的 Electron 替代品”,而是复用系统自带的 WebView(如 Windows 的 Edge/IE、macOS 的 WebKit、Linux 的 GTK+Webkit/Qt WebEngine),因此: * 体积极小(

openclaw web UI 无法访问 not found

## 问题解决总结 根本原因 :Gateway 的 resolveControlUiRootSync 函数在自动查找控制 UI 目录时,没有包含 node_modules/openclaw/dist/control-ui 作为候选路径。手动指定相对路径时,可能因为工作目录解析问题无法正确找到目录。 最终解决方案 : 1. 将控制 UI 文件从 node_modules/openclaw/dist/control-ui 复制到项目根目录       E:\你实际的目录\control-ui       (建立一个英文,且没有符号的目录,“-”和“_",会引起混淆) 2. 在配置文件中使用绝对路径指定 controlUi.root: "E:\\你实际的目录\\control-ui" 编辑 openclaw.json "

【硬核排查】挂了代里还是“裸奔”?深度解析 WebRTC 泄露与 Google 账号风控机制

【硬核排查】挂了代里还是“裸奔”?深度解析 WebRTC 泄露与 Google 账号风控机制

本文仅用于技术研究,禁止用于非法用途。 Author:枷锁 前言:一个“玄学”的网络故障 最近在进行网络环境配置时遇到了一个非常反直觉的现象: 我在本地开启了 戴笠,状态栏显示连接正常,访问Gemini毫无压力。但是,当我打开 ip138 或百度搜索 “IP” 时,显示的却依然是我本地的 ISP 真实 IP。更糟糕的是,我的 Google 账号开始频繁触发安全风控——要么是登录时无限弹出验证码,要么是刚登上去就被踢下线。 这不仅仅是“连不上”的问题,而是一个典型的网络协议泄露与安全风控案例。本着“知其然更要知其所以然”的精神,我深扒了其背后的技术原理,发现罪魁祸首主要有两个:路由分流策略与WebRTC 协议漏洞。 第一部分:为什么 ip138 “出卖”了你?—— 聊聊路由分流 (Split Tunneling) 很多新手判断 是否生效的标准是: