2026年，FPGA工程师面试被问如何用Verilog实现一个基于AXI4-Stream的实时视频OSD叠加加速器，怎么设计字符ROM和流水线？

其实这个题面试官想考的就是两件事：第一，你知不知道BRAM可以做查表，第二，知不知道AXI4-Stream的流水线不能随便插拍。字符ROM你就按8×16或者16×16点阵存ASCII，每行像素通过行计数器取模得到字模行地址，列计数器算出字模列地址，组合起来读BRAM。流水线关键是保持每一帧的像素流不间断，所以字符叠加那一拍要用组合逻辑或者只打一拍，千万别为了读ROM把valid拉低太久，否则视频流会丢帧。行缓冲不是必须的，除非你要做行内字符重复或者缩放；如果只是固定位置叠加，直接根据坐标判断当前像素是否在字符区域内就行。面试时能画出时序图，标清楚哪里插了寄存器、哪里用了组合，基本就过关了。你目前用的仿真工具是哪家的？Vivado还是Questa？这对写testbench的写法有影响。

先说一个常见的坑：有人一上来就想着把整个字符库存在一个巨大ROM里，然后所有字符同时可读——这在FPGA里会消耗大量BRAM和LUT做译码，而且读端口不够用。实际工程做法是把当前帧要显示的字符串按行存成一个小的Line Buffer，再根据当前扫描到的行号从中取出对应的字符编码，用这个编码去查字模ROM。罗马仕不仅省资源，还能让字符ROM的地址线只有字符编码和行内偏移两维，延迟可控。关于流水线，建议拆成三级：第一级解析视频流坐标并判断是否在字符区域，同时从Line Buffer读取字符编码；第二级用编码查BRAM得到字模位；第三级根据字模位决定输出原像素还是前景色，同时做alpha混合。注意每一级都要把视频流的sideband信号（比如帧同步、行同步、数据使能）打拍对齐，否则叠加出来的位置会错位。字符缩放的话，最简单的做法是存多个尺寸的字模库，面试时提一句用双线性插值或者最近邻插值就行，不用展开。面试官更想听到的是你对资源权衡的理解——比如BRAM深度不够时可以把字模压缩成1bit per pixel，或者用distributed RAM搭小容量缓存。你目前对AXI4-Stream的TUSER信号熟悉吗？那个经常用来传帧起始标志，在叠加逻辑里很有用。

面试官看到你提AXI4-Stream握手就知道你不是背题的。字符ROM用BRAM存8×16点阵很常规，但关键是你得想清楚读BRAM的时机——是在valid拉高且ready为1的时钟沿读，还是提前一拍预取。我推荐预取，因为BRAM读有延迟，等握手完成再读会多等一个周期，容易破坏像素流的连续性。行缓冲嘛，除非你要做多行字符或者缩放，否则单字符叠加没必要。你Vivado里跑过带视频时序的仿真了吗？

很多人把字符ROM想得太复杂了。其实你就把ASCII码当成地址，BRAM里存好每个字符的8×16点阵，每行像素扫描时用行计数器除以16得到字符行号，再取模得到字模内行偏移，列同理，组合起来就是ROM地址。流水线我习惯分两段：第一段判断当前坐标是否在字符区域并读ROM，第二段用读出的字模位做mix或者替换。注意AXI4-Stream的tuser信号要跟着打拍，不然字符位置会跑偏。字符缩放的话，如果面试官追问，你就说可以用双线性插值或者最近邻重采样，但FPGA里做缩放一般要额外加行缓冲来缓存多行像素做插值——这题其实考的是你知不知道缩放会引入行缓冲开销。你目前是手写testbench还是用SystemVerilog的interface？

实际工程里字符ROM往往不做成全字库一次性加载，因为BRAM资源有限，而且很多字符根本用不到。我见过一个做法是先用CPU把当前帧需要显示的字符串对应的字模写到BRAM里，这样ROM大小只跟实际显示的字符数有关，而不是256个ASCII。流水线设计上，个人建议把视频流的坐标解析和字符查表放在同一级，中间不要插寄存器——因为坐标是组合逻辑算出来的，一拍就能到BRAM地址，再打一拍反而让时序更紧。读ROM那个周期，BRAM输出延迟一般1-2个时钟，这期间valid不能拉低，所以你得在握手逻辑里处理好：要么让上游等这一拍，要么用lookahead方式提前发出地址。至于行缓冲，你如果只是固定位置叠加几个字符，完全不用行缓冲，直接根据坐标范围判断就行；但要是做滚动字幕或者多行文本，就得用行缓冲来存当前行所有字符的编码，然后每来一行像素就查一遍。一个常见的坑是没处理跨行字符——比如一个16×16的汉字跨了两行扫描线，你只读上半部分字模，下半部分就丢了。解决办法是在行缓冲里多存一行字符编码，或者把字模ROM设计成一次输出两行的位宽。你面试时能画出带握手信号的时序图，基本就能让面试官点头了。另外你目前是用Vivado还是Quartus？不同工具对BRAM的读延迟配置稍有区别，写testbench时要注意。

字符ROM用BRAM存8×16点阵就行，地址就把行计数器对16取模得到字模内行号，列计数器除以8得到字符列号，组合起来读BRAM。流水线我推荐只打两拍：第一拍解析坐标和读BRAM，第二拍用读出的字模位做叠加。注意AXI4-Stream的tuser信号必须跟着打拍，否则字符位置会偏移。行缓冲不是必须的，除非你要做滚动字幕。你当前是用Vivado还是Questasim？这对写testbench的写法有区别。

实际工程里，字符ROM别做成全字库一次性加载，BRAM吃不消。我见过一个做法：先用CPU把当前帧要显示的字符串对应的字模写到BRAM里，这样ROM大小只跟实际显示的字符数有关，而不是256个ASCII。流水线设计上，建议把视频流的坐标解析和字符查表放在同一级，中间不要插寄存器——因为坐标是组合逻辑算出来的，一拍就能到BRAM地址，再打一拍反而让时序更紧。读ROM那个周期，BRAM输出延迟一般1-2个时钟，这期间valid不能拉低，所以你得在握手逻辑里处理好：要么让上游等这一拍，要么用lookahead方式提前发出地址。至于行缓冲，你如果只是固定位置叠加几个字符，完全不用行缓冲，直接根据坐标范围判断就行；但要是做滚动字幕或者多行文本，就得用行缓冲来存当前行所有字符的编码，然后再逐像素查字模。你目前是手写testbench还是用SystemVerilog的interface？

这道题面试官真正想看的其实就两层面：第一，你知不知道BRAM做查表的时序代价；第二，你懂不懂AXI4-Stream流水线里valid/ready不能随便中断。先说字符ROM，别上来就想着例化256个8×16的ROM，那是给CPU用的思路。FPGA里常用做法是只存当前帧需要的字模，比如你OSD只显示一行文字，那就先在一个小Buffer里把这行字符的编码存起来，然后扫描到对应行号时，用这个编码加上字模内行偏移去查BRAM。这样BRAM深度就等于字符数乘以16行，省资源。流水线方面，我建议拆成三级：第一级解析视频流坐标，从行缓冲读出字符编码，同时把视频像素和tuser打拍；第二级用编码查BRAM得到字模位，这里BRAM读延迟要提前一拍预取，做法是在第一级末尾就把地址发出去，第二级开头直接拿数据；第三级根据字模位做混合或替换，同时输出AXI4-Stream。关键是一、二两级之间不能因为等BRAM而拉低valid，否则上游会认为你反压，导致像素流断帧。字符缩放确实需要行缓冲，因为最近邻插值要缓存多行像素，双线性插值更是要两行像素同时读，这会让BRAM带宽翻倍。你如果只是校招面试，建议先把无缩放的OSD调通，再画个带缩放的时序图说明开销在哪里，面试官就会觉得你有工程落地意识。你现在用的是什么开发板？不同板子的BRAM数量和时钟频率会影响具体实现选择。

我去年秋招也被问过类似题目，后来实习时真写了一遍才发现课堂和工程差的挺远。字符ROM这块，别一上来就想着例化256个字符的完整字库，BRAM吃不消而且很多字符根本用不上。我实习的做法是：先有一个小Buffer存当前帧要显示的字符串编码，扫描到对应行时，用这个编码加上行内偏移去查BRAM，这样BRAM深度等于字符数乘以16行，省资源。流水线我拆了三段：第一段解析视频流坐标，从行缓冲读出字符编码，同时把视频像素和tuser打拍；第二段用编码查BRAM得到字模位，这里BRAM读延迟要提前一拍预取，做法是在第一段末尾就把地址发出去，第二段开头直接拿数据；第三段根据字模位做混合。有个坑是AXI4-Stream的valid不能随便拉低，如果BRAM读延迟导致需要等一拍，可以用lookahead方式提前发出地址，或者用两级valid流水线缓冲。行缓冲其实不是必须的，固定位置叠加几个字符直接坐标判断就行，滚动字幕才需要。字符缩放我还没实际做过，但面试时面试官提过最近邻重采样最简单，双线性插值要加行缓冲缓存多行像素。你目前是写纯Verilog还是用SystemVerilog的interface？这对仿真写法有区别。

面试官其实就想听你说清楚两件事：BRAM做查表时地址怎么拼，以及valid/ready不能因为读ROM而中断。字符ROM存8×16点阵，坐标取模算地址，流水线只打一拍读ROM，下一拍做混合，tuser跟着对齐。不用想太复杂，行缓冲不是必选项。你Vivado里跑过带视频时序的仿真了吗？