Creating custom IP for zedboard

[shlomishab]

Hi all,

I'm working on a video streming project with a zedboard and an ov7670 camera module. 

I found a similar project online, made by Mike Field, and I was able to make it work.

But I want to buid the project using custom IP's. and I found this project:

https://lauri.xn--vsandi-pxa.com/hdl/zynq/zybo-ov7670-to-vga.html

I used the same (working) VHDL code, the same XDC file, the same setup, and followed his instructions,

but for some reason, whenever I try to create custom IP's (with or without AXI), I can't make it work, and the monitor says "no signal".

Can anyone please help to figure out what I'm doing wrong here?

Thanks, Shlomi.

[D@n]

@shlomishab,

Can anyone help you?  Perhaps, but you'll have to do some more digging into what's going on.  From what you've given above it'd be hard to know where to start looking.  Let me recommend you start by breaking the problem up in a proper engineering fashion.  Break up the operation into steps, and then check for success or failure at the end of each step.  Incidentally, this is much easier to do in simulation ...

Dan

[shlomishab]

I've been digging, a lot, and I'm back to same place. That's why I'm here.

I can't figure out what I'm missing.

Is there a way for me to check the functionality of each IP, separately? 

I know the VHDL codes are good, because they work when I don't custom the IP's

[D@n]

@shlomishab,

4 hours ago, shlomishab said:

Is there a way for me to check the functionality of each IP, separately?

Absolutely!  This is the job of the engineer, to know how to break a project up into subcomponents and measure which of those subcomponents are at fault.  This is also what makes FPGA design difficult: because it is a challenge to debug designs after they are placed on a circuit board.  Indeed, debugging FPGAs is perhaps the hardest part of the job.  It requires a methodology and discipline that isn't necessarily carried over when coming to FPGA design from other fields.  Why?  Because you can't "see" into the FPGA.  Unlike software, where you can stop it with a debugger at every step and examine every variable, you can't do that with an FPGA.  (You can do it with simulation ...)  Worse, it's hard to even examine variables from within an FPGA at all.

Here are some good rules of thumb:

• Your first step to debugging is what's known as "static" checking, sometimes called "linting" in the software world.  I like to use "verilator -Wall" for this--but that only works with Verilog modules.  Vivado will also present warnings to you when it synthesizes your designs.  (Verilator's warnings are more usable ...)  When things aren't working, look over the warnings.  It might save you hours of debugging.
• *EVERY* module within a design should have a "bench test" of some type, some way of determining that it works before it ever moves forward.  In the larger companies that I've counseled over the years, a bug "escaping from unit test" is a *BIG* deal that gets a lot of engineering attention.  It happens, but your goal should be to keep it from happening--it just "costs" a lot more work to find a bug after a module has left unit test.  I do most of my bench testing using formal methods.  Others set up rather elaborate simulation scripts to find bugs in individual modules.  The difficult part of building simulation scripts is that ... you can't always predict everything that will go wrong.  Formal methods often help you pick out things that might go wrong.
• When you purchase IP from someone else, or otherwise acquire it, look for this bench test.
• Vivado tries to make this easier by building a simulation script for you when you choose to create a custom IP.  I don't use this script.  I don't trust it.  Their simulation script misses too many bugs.  For example, I know (and have blogged about) bugs in every one of their AXI slave examples--both AXI and AXI-lite, and their AXI-stream master is also broken.  These bugs don't show up under their simulations, but they do show up under a formal methods check.
• SymbioticEDA makes a product called SymbiYosys which you can use to formally verify Verilog designs.  They sell a SymbioticEDA Suite for handling SystemVerilog and VHDL designs.  They've also posted a similar product called mcy (mutation coverage with Yosys) which can be used to determine if your test bench is good enough or not.  That is, if some piece of logic gets mutated (i.e. broken), can your test bench catch it?  Evaluating your test bench to determine if it is "good enough", therefore, is the purpose of mcy.
• Once *EVERY* component has been formally verified (or otherwise bench tested), and only then, should your methodology move on to an integrated test.  Integrated tests are still simulation tests.  Why?  Because, in simulation, you can see every variable, every value, at every time step.  Sure, it's slow.  Sure, it's clunky.  However, it's much easier to figure out what's going right or wrong from simulation than it is from hardware.
• Only after your hardware passes an integrated simulation test should you ever move forwards onto real hardware.  In the digital design field, this usually means FPGAs.  For some of us, the design work stops at the FPGA level.  For others, it goes on from FPGAs to ASICs, but FPGAs are usually a good first step before ASICs.  Debugging a design within an FPGA is usually much harder than in simulation, but with the tradeoff that the FPGA can run at full speed (or close to it), whereas the simulation cannot.
• In order to debug a design from within an FPGA, you'll need a special piece of FPGA logic sometimes called an In-circuit Logic Analyzer (ILA). I like to call them "internal scopes". This will cost you logic and block RAM resources within your FPGA.  Using a "scope" you can capture a limited number of values from within your design.  As an example, I might capture 32-bits for 1024 clock cycles and read them back later.  Inside a devices with thousands of flip-flops and millions of clock cycles per second, this is like trying to drink the ocean through a straw.  There's an art an science to getting the right values, and to capturing them at the right time.
• Sometimes even the scope fails.  In these cases, I like to use LEDs to try to debug what's going on.  Using an LED, you can often debug missing clock problems, problems with clock not locking, and more.  Sometimes a scope helps, and Digilent's Digital Discovery has been invaluable to me.

Returning to the idea of using graphics on an FPGA, feel free to check out my own video simulation here.  Since that article was posted, I've written AXI versions of the various demonstrators.  Once you can run your design in simulation, then feel free to try running it in actual hardware.  Then, when/if it dosn't work, feel free to write back telling us what piece isn't working, whether it's not working in simulation or in hardware, and be specific--isolate the problem as much as you can, so we can then help you.  Or if you can't isolate it, tell us what you've tried, and we might be able to offer suggestions--similar to those above.

Dan