XIlinx FPGA使用LVDS的电源与电平关键指南

XIlinx FPGA使用LVDS的电源与电平关键指南

针对 7 Series, UltraScale, UltraScale+ FPGAs 以及 MPSoC 器件使用 LVDS 的注意事项:

1. 适用范围

  • 器件系列:7 Series, UltraScale, UltraScale+, Zynq UltraScale+ MPSoC。
  • 涉及 IO 类型:High Performance (HP) Banks, High Range (HR) Banks, High Density (HD) Banks。

2. 电源电压 (VCCO) 与 输入/输出 的限制

这是该指南的核心内容,根据 Bank 类型和是用作输入还是输出,规则有所不同:

A. LVDS 输出 (Outputs)
  • 严格的电压要求:LVDS 输出驱动器对 Bank 电压(VCCO)有严格要求,必须匹配标准电压。
    • HP Banks (LVDS): VCCO 必须为 1.8V
    • HR/HD Banks (LVDS_25): VCCO 必须为 2.5V
  • 不支持 3.3V 输出:这些器件不支持LVDS_33 标准。你不能在 VCCO 为 3.3V 的 Bank 中使用 LVDS 输出。
B. LVDS 输入 (Inputs)
  • 宽松的电压要求:输入端的 VCCO 电压要求相对宽松,可以不完全匹配标准电压,但有前提条件。
    • HP Banks: 即使 VCCO 不是 1.8V,也可以使用 LVDS 输入。
    • HR/HD Banks: 即使 VCCO 不是 2.5V,也可以使用 LVDS_25 输入。
  • 关键限制 (Termination)
    • 如果在 VCCO 电压不匹配的情况下使用 LVDS 输入(例如在 2.5V 或 3.3V 的 Bank 中接收 1.8V LVDS 信号,或在非 2.5V Bank 接收 LVDS_25),必须将 DIFF_TERM 属性设置为 FALSE
    • 这意味着你不能使用片内终端电阻,必须在 PCB 上使用外部差分终端电阻(通常为 100Ω)。

3. 电气参数合规性 (Signal Integrity)

无论 VCCO 如何连接,必须确保驱动端的信号电平满足 FPGA 接收端的规范(参考具体器件的数据手册 Data Sheet):

  • VOD (差分输出电压) & VOCM (共模输出电压):驱动芯片的输出必须落在 FPGA 接收端的 VIDIFFVICM 允许范围内。
  • VIN (输入电压范围):输入信号的绝对电压电平不能超过 Data Sheet 中规定的 VIN 绝对最大额定值(通常与 VCCO 相关,需注意过压风险)。

4. 关于 “LVDS_33” 的特别说明

  • 无原生支持:现代 Xilinx FPGA(7系列及以后)没有 LVDS_33 I/O 标准。
  • 兼容性设计:如果需要连接旧款 FPGA 或其他芯片的 3.3V LVDS 信号:
    • 作为输出:FPGA 无法直接产生 3.3V 供电的 LVDS 信号。
    • 作为输入:只要信号电平(VOD, VOCM)满足 FPGA 接收端的要求,且不超过 Bank 的输入电压容限,通常可以接收。但务必注意共模电压和摆幅是否在 FPGA 允许范围内,并使用外部端接。

5. 双向 LVDS (Bidirectional)

  • 必须同时满足输入和输出的限制。因此,对于双向 LVDS 信号,Bank 的 VCCO 必须严格设置为对应的标准电压(HP Bank 为 1.8V,HR Bank 为 2.5V),且不能利用输入的宽电压容限特性。

总结检查清单 (Checklist)

  1. 确认 Bank 类型:是 HP、HR 还是 HD?
  2. 确认方向:是仅输入、仅输出还是双向?
  3. 检查 VCCO
    • 输出/双向 -> 必须严格匹配 (HP=1.8V, HR=2.5V)。
    • 仅输入 -> 若 VCCO 不匹配,必须禁用内部匹配 (DIFF_TERM = FALSE) 并使用外部电阻。
  4. 检查电平:对照 Data Sheet 检查驱动端的 VOD/VOCM 是否在接收端的 VIDIFF/VICM 范围内。

Read more

基于STM32的智能小车避障与循迹实战(江科大标准库开发)

1. 项目概述与硬件准备 如果你已经学完了江科大的STM32入门教程,却不知道下一步该做什么,那么这个智能小车项目绝对是你的不二之选!我自己在做完这个项目后,对STM32的各种外设和编程逻辑有了更深刻的理解。今天我就把自己在实现过程中的经验分享给大家,包括避障、循迹等核心功能的实现方法。 智能小车项目需要的硬件其实并不复杂,下面是必备清单: * 主控芯片:STM32F103C8T6最小系统板(核心板) * 电机驱动:TB6612模块(1-2个,根据电机数量决定) * 舵机:SG90(用于超声波模块的旋转扫描) * 传感器:HC-SR04超声波模块(避障)、TCRT5000红外模块(循迹) * 通信模块:HC-04蓝牙模块(手机控制) * 车体框架:某多多上搜索"STM32智能小车框架"(自带四个直流电机) * 烧录器:ST-LINK V2 * 其他:导线若干、面包板或洞洞板(建议用洞洞板,更稳定) 我在第一次组装时犯了个错误,没有先测试电机就直接焊接了,结果发现有个电机是坏的,不得不重新拆焊。所以强烈建议大家先测试所有元件再组装! 2.

前端老铁必看:Mock劫持Ajax翻车实录与避坑指南

前端老铁必看:Mock劫持Ajax翻车实录与避坑指南

前端老铁必看:Mock劫持Ajax翻车实录与避坑指南 * 前端老铁必看:Mock劫持Ajax翻车实录与避坑指南 * 咱就是说,这玩意儿到底咋忽悠浏览器的 * 核心原理:浏览器里的"替身演员" * 那fetch呢?它也跑不掉 * url、rtype、template这三个参数到底咋配合的 * 匹配优先级:谁说了算 * 扒开源码看底裤,拦截逻辑其实是这么玩的 * 源码级别的URL匹配骚操作 * 请求类型(rtype)的判断陷阱 * 数据生成引擎:template是怎么变成真实JSON的 * 延迟模拟:为什么要假装网络很慢 * 爽完之后的贤者时间:这招到底有啥毛病 * 性能陷阱:假数据太多,浏览器直接去世 * 类型安全地狱:TS项目里的Mock灾难 * 复杂业务逻辑模拟不了:鉴权、文件上传、流式数据 * 跨域和CORS的坑 * 真实搬砖场景:我在项目里是怎么靠它摸鱼的 * 场景一:后端接口延迟,先画UI * 场景二:模拟

API 设计的 7 个致命错误:为什么你的接口让前端想打人

API 设计的 7 个致命错误:为什么你的接口让前端想打人

凌晨一点,前端在群里 @了你 “后端大哥,为什么删除用户的接口是 POST?” “为什么获取用户列表要传 20 个参数?” “为什么同一个错误,有时返回 200,有时返回 500?” “能不能别再改接口了?这是这个月第三次了!” 你看着手机,心里一万头草泥马奔腾而过。 明明功能都实现了,为什么前端还是不满意? 因为你的 API 设计,可能犯了这 7 个致命错误。 今天,我们就来聊聊那些让前端抓狂、让自己背锅、让项目延期的 API 设计问题。 错误 1:把数据库表结构直接暴露成 API 灾难现场 // ❌ 直接暴露数据库结构GET/api/user_account_info?user_id=123// 返回{"user_id"

别装了!你写的JS代码全在“裸奔”,99%前端都在背锅!

今天,我想直接撕开一个血淋淋的真相。 在这个行业里,我审查过无数的JavaScript应用程序,甚至包括那些大厂出品的标杆项目。然而,它们几乎无一例外地都藏着致命的安全漏洞。 这不是因为前端开发者们在摸鱼,也并非因为团队对最佳实践视而不见。 真正的原因在于,现代JavaScript这头巨兽实在太复杂、进化太快了,而且它从头到脚都布满了让人防不胜防的暗坑。 无论是在初创公司的草台班子、企业级的豪华看板,还是那些每天处理着真金白银和海量真实用户的核心生产系统里,我一遍又一遍地看着同样的悲剧反复上演。 JS的安全漏洞,最喜欢玩“死一般寂静” 报错导致APP崩溃?那反而是你修了八辈子福得来的福报! 通常来说,当你把代码搞砸了,你立马就能收到反馈。 比如一个直接报错的API请求,一个四分五裂的页面布局,或者测试控制台里那片刺眼的爆红。 但是,安全漏洞根本不跟你玩这套,它们就像隐形杀手一样,蛰伏在死一般的寂静中。 你的UI看起来美轮美奂。你的API跑得顺风顺水。你的自动化测试全绿通过。 可就在同时,在那些你看不见的阴暗角落里,黑客可能正在疯狂窃取你用户的会话令牌(Session