Jump to content
  • 0

Zybo Z7 Getting Started problem - I'm stuck already!


Rockytop

Question

Trying to get started with the Zybo-Z7 board and following the "Getting Started with Zynq" tutorial ( here ).

Using Vivado 2018.2 because that's what the latest Pcam tutorial uses (my ultimate application). I can get down to the point where you add the 2 gpio IP blocks. But when "Run Connection Automation" is selected, the popup window does not have an option to select the board interface (switches and LEDs). These are un-commented in the constraint file.

I'm using the latest board files and constraint files. Project Summary shows the correct board part.

I have a feeling I'm missing something simple. I've uninstalled/reinstalled everything. It's a fairly new W10 computer. I've looked at several other getting started type tutorials and no clues there.

I've done embedded systems before so not a complete novice, but i feel like one right now...

Link to comment
Share on other sites

12 answers to this question

Recommended Posts

can't help you with that specific tutorial, sorry. But...

>> I've uninstalled/reinstalled everything

... that working mode sounds familiar and I'm not convinced it leads anywhere.

Zynq is a very complex system. Without a systematic way of debugging, it's hopeless (IMHO). As soon as there are two issues at the same time (and this usually happens), any attempt at unsystematic trial-and-error (like reinstalling etc) is doomed to fail. One reason is there are four Vivado versions a year, and porting a "complex" (e.g. camera) demo from one to the other is a non-trivial undertaking.

Especially if you intend to stick with it for a longer time, you might have a better start studying the various ways to blink a LED (from RTL, PL GPIO from ARM, MIO GPIO, from the handoff hook in the bootloader, from an own .elf file).This may sound absurd but it lets you tackle the problems one by one.

But that said, maybe someone else can help with the specific question...

 

Link to comment
Share on other sites

Uninstalled/reinstall is a desperation move - I know that and understand your reply. I also know Zynq is very complex (which makes it very useful). However, getting a basic eval board up and running with the most simple of programs should not be that complex.

What's the best way to study the various ways to blink and LED and read switches? I know I can just write verilog code to do this but that doesn't help learn the block design tool. Long term, I want to get to the SDSoC system. These initial tutorials should be a way to just do the simple startup stuff - what I call a minimum thread.

The Pcam tutorial was posted back in March and uses 2018.2 so it should still be usable. However, I've had problems with that as well. Probably the same problem I'm having now.

I've looked at some of the tcl scripts that define locations of things like board files. My sense is there is something wrong with one or more of these files. I am getting a warning when the project is initialized that says something about the board repository path. The message has some unintelligible characters in it so not sure what it's trying to say.

Thanks for the quick reply!

Link to comment
Share on other sites

what I'd do is use the template for an AXI-Lite slave (appears in the graphical view as RTL block and is recognized in the address editor), route one of the template registers to a LED. Then use this to "pipe-clean" the tools, for example go through the whole PS7 setup once without templates (keep DRAM as it's fairly complex but the other settings I'd rather understand when working with the chip).

Can't say whether the "various" ways are that more interesting but for example you need a MIO-driven LED to emit blink codes from the FSBL because the PL isn't yet awake (hopefully you don't need this anyway. Take it as advance warning that running a design from flash is not necessarily as straightforward as e.g. on Artix...)

Link to comment
Share on other sites

@Rockytop,

Let me echo @xc6lx45's comment that if you can't pinpoint the bug, then your design methodology is wrong.  Indeed, not knowing what the bug is within your design is a common FPGA problem, and there are several tools to keep it from happening.

  1. The most obvious tool is "deskchecking".  When you desk check your code, you read it over again to yourself to see what's wrong with it.  If you can find a bug, cool.  The problem with desk checking, though, is that you can't always find the problem when doing so.
  2. The next tool is "blinky", this is the one @xc6lx45 has recommended.  It's a great beginner tool, and will often help you find a lot of those early bugs.  It's so powerful, that the first thing I do when I bring up a new board is to get an LED to blink.  You can then use that LED and whatever pattern it blinks to find bugs in your design.  The problem with "blinky" is that you only get a single bit of information, and that single bit needs to be slowed down to the point where you can recognize it.  It doesn't scale well.
  3. The easiest way to debug a design is by using the simulator.  Sure, it's slow.  Sure, it takes a bit to set up.  But a trace from a simulator will give you access to every single wire within your design over the course of a simulation run.  If you've come from the software world, you may find that (in many ways) it's better than a debugger.  That said, traces can get rather long, and finding bugs and tracing them back to their source with a trace visualization tool can be a real brain twister.  The biggest downside to the simulator is that it doesn't necessarily simulate any hardware your design might be connected to.  Your simulation will only be as good as your simulation of the hardware you are working with.  Still, any time I can get a bug to appear in the simulator, I consider it a success.  A painful success, but a success nonetheless.
  4. Only a bit harder than the simulator are internal logic analyzers (ILA).  These are very powerful debugging tools that you should also learn to use early on.  An Internal Logic Analyzer of a soft-core that you add to your design--i.e. you pay for it in terms of fabric on your chip that cannot be used for your user design.  Because your design has to move over to make room for the ILA, you can't record everything.  When using an ILA, it's important to pick the right signals to capture, the right trigger to start the capture, and the right size of the capture.  Also, because the ILA is added to your design, if you don't pick the right signals or the right trigger etc., you'll have to rebuild the design to try again.

These are the traditional tools of the trade in the FPGA world.  Using these tools, you should be able to hone in quickly on whatever bug you might have to see why you are having the bug.

There's also a newer tool available to the FPGA design engineer, formal verification.  There's an open formal verification tool called SymbiYosys that can formally verify Verilog designs.  There's also a version that does both SystemVerilog and VHDL, it's just not free.  Formal is similar to simulation in that it's a problem you can run on your desktop, and it will give you access to every register within your design.  It's different in that, unlike simulation, it doesn't examine a single trace through your design.  Rather, it examines every possible set of inputs to your design in a breadth first search for a bug.  As a result, it finds more bugs than simulation does.  Indeed, simulation can be shown to "mask" bugs, whereas formal tends to find them anyway.  The problem with formal tools is their great strength: because they work on a breadth first search, they have a (rough) exponential complexity.  This limits the size of the design you can apply them to, and the length of time you can apply the tool for.  Even with that limitation, however, formal is known for finding all kinds of bugs simulation misses.  You can read more about formal verification on my blog, zipcpu.com.  You can also try out my tutorial--it goes through teaching simulation and formal verification from square one (this is a wire), all the way through serial ports.

Hope this helps!

Dan

Link to comment
Share on other sites

D@n

Thanks for the advice! I do appreciate it. However, I can't get Vivado set up to allow me to do a simple blinky light! I don't yet have a program to debug. I wish I did. I think I could handle that.

I can get down to the point where you add axi_gpio IP blocks in the simple Getting Started Tutorial. But when "Run Connection Automation" is selected, the popup window does not have an option to select the board interface (switches and LEDs).

On the tcl Console, there are a couple of warnings about "Board Repository Path", but the path it gives in the warning message is valid.

How do I get Vivado to use the board file that was selected when the project was created?

Link to comment
Share on other sites

Does the "valid" path have spaces in it?  As I recall, Vivado had a problem with spaces in board paths.

Personally, "AXI-GPIO" is not where I'd recommend you begin.  I'd recommend you begin here, but that's another story entirely.  The problem with starting at AXI GPIO is ... there's so much background you don't have in order to debug things when you start there.

To provide a perspective, you might be curious to know that ... I've never used a "board file".

Dan

Link to comment
Share on other sites

The warning message with file path has missing letters and a few boxes where letters should be. In one message there are no slashes in the path.

I'm beginning to think board files are a waste of time. Vivado can't seem to handle them properly.

Presets are something else I've found that don't appear to show up where some tutorials say they should be.

If I could just connect the output of the axi_gpio_0 block to an LED then I could proceed.

Anybody out there who knows how to make this happen?

Link to comment
Share on other sites

Jon, Thanks for your reply. I think I have finally found the problem. My project folder was within a Dropbox folder, and this does not work consistently with Vivado.

After I saw the post above late yesterday afternoon, I created a few new projects and Vivado did bring in the board file properly. This morning I tried to create a few more new projects, just to make sure I wasn't imagining things yesterday, and Vivado did NOT bring in the board file. (Bordering on insanity at this point.) I remembered reading somewhere that it is recommended files be under the C:\ drive, and I know these Windows machines go off and do things on their own - especially in the mornings, so I created a new project folder and created new projects there. It works! Consistently!

So, don't put Vivado projects in a Dropbox folder.

I've used Dropbox folders for all the other work we do here and that includes several programming systems (LabView for one). I'll have to find a different way to backup the Vivado projects.

Does this make sense to you?

Thanks for all the replies above. I'm sure I'll have other questions along the way, but hopefully they will be about the Zynq itself.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...