怎么使用Verilog和Nexys4 FPGA进行图像跟踪

你可以只为谷歌代码BCD和7段。
你将获得丰富的verilog和VHDL。
首先尝试模拟，然后再移动硬件。
在硬件中实现。
您需要使用正确的IO标准/引脚配置来构建设计
谢谢和RegardsBalkrishan -----------------------------------------------
---------------------------------------------请将帖子标记为
一个答案“接受为解决方案”，以防它有助于解决您的查询。如果一个帖子引导到解决方案，请给予赞誉。



以下为原文

you can just google  code for BCD and 7 segment . You will get plenty in both verilog and VHDL .
Try simulation first and than move on hardware.
To implement in hardware . You need to build the design with correct IO standard/ pin configurationThanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.

您可能想要开始为设计制作基本构建块。
相机连接需要UART。
你可以自己设计或者找一个像picoBlaze一样的UART-Lite。
你需要一个用于VGA的定时发生器，我假设某种帧缓冲器的存储器接口，除非你的图像非常小。
如果您不想处理JPEG解压缩，则需要将相机设置为原始模式，这实际上会限制图像大小。
您可以将这些图像放入块RAM中的FPGA内部。
但是，此图像尺寸需要映射到VGA，其最小分辨率远大于图像。
因此，您可以选择将像素复制到VGA输出上的较大的正方形或矩形像素块中，或者只是以1：1（本机）分辨率将图像居中放置在屏幕中。
您可以先制作静态显示，然后将其替换为相机中的数据，然后最终开始处理图像跟踪算法，可能使用第二个窗口显示结果。
总而言之，对于初学者来说，这是一个非常雄心勃勃的项目。
祝你好运！
-  Gabor



以下为原文

You probably want to start making basic building blocks for the design.  The camera connection will need a UART.  You could design your own or find one like the UART-Lite packaged with picoBlaze.  You'll need a timing generator for the VGA, and I assume some sort of memory interface for a frame buffer, unless your images are quite small.  If you don't want to deal with JPEG de-compression, you'll need to set up the camera for Raw mode, which in fact does limit the image size.  You could probably fit these images inside the FPGA in block RAM.  However this image size will need to be mapped to the VGA, which has a minimum resolution much larger than your image.  Thus you have a choice of replicating pixels into larger square or rectangular blocks of pixels on the VGA output, or just centering the image in the screen at 1:1 (native) resolution.
You could start by making a static display and then replace that with the data from the camera, and then finally start to work on your image tracking algorithm, possibly using a second window to display the results.
All in all this is a pretty ambitious project for a beginner.  I wish you luck!
-- Gabor

正如gszakacs所说，从基础开始。
这个项目你需要多少分辨率？
如果160x120（原始模式下的uCam-II最大值）足够，则使用它。
它很容易适应块RAM  - 每个图像总共只有307200位，只需要10个Block RAM。
Nexys 4有135个Block RAM，因此即使进行双重或三重缓冲也有很大的空间。
如果你需要640x480像素，那将会更加困难。
你需要一个JPEG解码器和外部RAM，这两者都有些棘手。
看看VGA的显示方式（就帧时序而言）。
第一步应该是让它显示简单的图案;
例如，如果您只是在移动时递增每个像素上的12位输出值（并清除每行开头的计数器），您将获得红色的快速（16像素）锯齿效果，另外还有
绿色较慢的锯齿（256像素），加上非常轻微的蓝色渐变（它在4096像素后产生一个完整的锯齿）。
我建议在60Hz时瞄准640 * 480;
地球上的每个VGA显示器都应该理解（较新的显示器可能不了解低分辨率VGA模式，如320 * 200）。
为此目的的状态机并非微不足道，但它也不是非常复杂;
应该有很多可用的示例代码。
一旦你有了这个，将一堆数据加载到块RAM中，看看你是否可以显示它。
它应该是一个相当简单的修改;
而不是增加每个像素的颜色值，而只是增加RAM地址。
您可以将图像显示16次（平铺），或者您可以在每个方向上将其向上吹四倍，或者您可以只以正常尺寸显示一次，并用黑色填充图像的其余部分。
那就是UART。
根据uCam-II需要多少配置，我很想做一个超基本的移位寄存器UART。
希望你只需要向摄像机发送一个字符串来设置模式/分辨率（这可以通过从配置FPGA后立即移出的大移位寄存器开始），然后有一个UART接收器，
接收像素并将它们放入块RAM（可能与显示器使用的块RAM不同）。
一旦你完成了这项工作，就应该直接进行视频直通 - 一旦你有视频直通，你需要看看如何进行所需的图像处理。
考虑哪些算法能很好地映射到FPGA。
通常，可以在连续像素（如卷积）上运行的算法非常适合FPGA。
需要快速随机访问许多像素和/或递归函数（例如泛洪填充）的算法非常不适合。
不经常做一堆讨厌的数学的算法也很不适合;
如果您不得不用硬件填充一半的芯片来进行浮点运算，那么您希望始终使用该硬件。



以下为原文

As gszakacs has said, start with the basics. How much resolution do you need for this project? If 160x120 (uCam-II maximum in raw mode) is sufficient, then use that. It'll fit easily into block RAM - it's only 307200 bits total per image, which will only need ten block RAMs. The Nexys 4 has 135 block RAMs, so there's loads of space even to do double or triple buffering.
 
If you need 640x480 pixels then that's going to be far more difficult. You'll need a JPEG decoder and external RAM, both of which are somewhat tricky.
 
Have a look at how VGA is displayed (in terms of frame timings). The first step should be to just have it display simple patterns; for example, if you just increment the 12-bit output value on each pixel as you move across (and clear the counter at the start of each line) you'll get a quick (16-pixel) sawtooth effect in red, plus a slower sawtooth in green (256-pixel), plus a very slight gradient in blue (it'd generate a full sawtooth after 4096 pixels). I suggest aiming for 640*480 at 60Hz; every VGA monitor on the planet should understand that (newer monitors might not understand lower-resolution VGA modes, like 320*200). The state machine for this is not trivial, but it's also not horribly complex; there should be plenty of example code available.
 
Once you've got that, load a bunch of data into block RAM and see if you can display that. It should be a fairly straightforward modification; instead of incrementing the colour value on each pixel, you just increment the RAM address instead. You can display the image 16 times (tiled), or you can blow it up by a factor of four in each direction, or you can just display it once at normal size and fill the rest of the image with black.
 
Then there's the UART. Depending on how much configuration the uCam-II needs, I'd be tempted to just do a super-basic shift register UART. Hopefully you only need to send a single string to the camera to set mode/resolution (which can be done just by starting with a big shift register that gets shifted out as soon as the FPGA is configured), and then there's a UART receiver that takes in pixels and drops them into block RAM (possibly not the same block RAM that the display is using).
 
Once you've got that going it should be straightforward to do a video passthrough - and once you've got a video passthrough, you need to look at how you can do the required image processing. Have a think about what algorithms will map well to an FPGA. In general, algorithms that can run on sequential pixels (like convolutions) are well-suited to FPGAs. Algorithms that require fast random access to many pixels and/or recursive functions (eg. flood-fill) are poorly suited. Algorithms that do a bunch of nasty maths very infrequently are also poorly suited; if you're going to have to fill half the chip with hardware for doing floating-point maths, you want that hardware to be utilised all the time.