Board Not Found, Arty-A7-35

[PapaMike]

I see there are other questions about Board Not Found, but I have applications already using my board and am at a loss of what to do next. Using Vivado 2019.2, Arty-A7-35. Synthesis and implementation run without any warnings. When I try to write the bitstream, I get "[Board 49-67] The board_part definition was not found for digilentinc.com:arty-a7-35." Can someone point me in a direction that might be helpful? I am also getting an error that no constraints are used, which is contrary to my design (including the "used in" assignments).

[JColvin]

Hi @PapaMike,

When you say you already have applications using the Arty A7-35, I presume this means you already have the Digilent board files (link to Digilent Github page on them) installed? I just ran a project with the Arty A7-35T on Vivado 2019.2 (I don't have Vivado 2019.2.1 installed), but did not get any critical errors.

You can quickly check to see if you have the board files installed by running the TCL command of get_board_parts to see if Arty A7-35T shows up in the list.

Let me know if you have any questions about this.

Thanks,
JColvin

[PapaMike]

Thanks. I already wandered down that path, but it was the obvious answer to my question. I reloaded the board files just to be sure, but that solved nothing. It seems unrelated, but I found an I/O without a constraint reference. Corrected that and the board is now responding. I must say this is all rather confusing for an old software guy. Falling back on my training, change one thing and observe the result... repeat... Maybe you can save me hours of trial and error, however. My problem was with an I/O reset. Using the arty-a7-35-master.xdc and un-commenting the lines I need. I pointed Package Pin F5 at my I/O and the board then responded. But it's not running correctly so that's clearly not the right pin. Is there a reference somewhere that can tell me how these I/O's are used? For you reference, the vhdl file is attached. See the entity top port rst_n. That's the problem I/O.

top.vhd

[D@n]

@PapaMike,

Looks like you've just discovered FPGA Hell.  Here's the problem: Your design doesn't work and you have no idea why not.  Worse, you have no idea how to figure out why it's not working. 

The first lesson at this point is that this is not the way to debug a design.  Bugs in designs are common, but finding bugs in a design after its been placed into hardware is just a really hard problem.  It can be done, but it's not easy.  You could ....

• Place one or more pins into an external oscilloscope.  Digilent sells a Digital Discovery that could work nicely for this purpose, but don't shell out the cash for that just yet.
• Use some kind of proven design to query what's going on within the design--something like an internal logic analyzer.  This works great when you need to communicate with an unknown piece of hardware, but ... it's hardly where you want to start from as a beginner

What next?  You want a simple solution that's not too expensive.  One possibility is to write into the Digilent forum.  You've asked, and sure enough, I can see several problems in your design.  However, that won't really solve the problem you are struggling with.  It might get you to where this design works, but then you'd be stuck as soon as you got to your next design.  Sadly, this is a recipe for both failure and frustration.  What you really need are the tools for success!

Time to learn about simulation!

I think I can guarantee in this case that if you simulated your design you'd see the problem almost immediately.

This is why I argue that the teaching/learning of RTL needs to start with simulation (and formal methods) at the same time you learn the language.  Without those tools, you'll continue to struggle with problems like this.

This sounds like a good time to take a pause from your hardware and learn how to run a simulator.

Dan

[PapaMike]

Dan, Thanks, but the design is simulated and works exactly as hoped, and yes, I do have ideas for what to do next. Been around too long to believe a single dead end is the end of a project. I'm actually getting pretty good at the simulation, but in this case, not good enough.

My problem is more basic, gaining an understanding of what's actually happening on the board. As a software guy, it's a steep learning curve. I'll get there. The more I use Vivado, the more I learn how to better use the reports and messages. That's like learning to read the owners manual after you've driven the car into a ditch. ? I'm still struggling with the interface (you call them constraints), but I see it as nothing more than part of the process.

Specifically, this design uses an I/O as a reset, even though the reset is managed internally. It's a future need thing, and it does appear the reset is the problem. At least I think that's my problem and that's where I will concentrate for now. I just need to learn what works and what doesn't work. 

As to your argument about simulation, I couldn't agree more. It's not open for debate. Still, there's always that little voice in your head that says, "Go ahead. Try it out." Madness, but for me it's still enjoyable to work thru it. And I know I still have way too much to learn about the language before I try hardware debugging.

Stay tuned. I don't give up without a fight! And thanks again for caring enough to comment.

[D@n]

@PapaMike,

Okay, looks like I misunderstood what was going on.

May I assume you have blinky working?  That'd be the first design I'd try.  Just get an LED to blink, then two, then three.

Now, when it comes to the SSD, you build off of blinky.  Use the LEDs to tell you when particular wires within your design are "on".  Yes, it's slow and methodical, but we can speed up later.  That'll at least give you the confidence that your design is properly loaded onto your device and somehow doing the "right thing".  In my own designs I have a special LED pattern I use to tell me the design has been loaded, so this isn't unreasonable or unusual at all.

If that still doesn't work for you then it's time to take a logic analyzer, or perhaps just a simple voltmeter, to the various PMod outputs to make certain you have the XCF file right.  Are those outputs actually being sent to the right pins?  Did you plug the PMod into the wrong port, etc., etc.  Yes, I'm an old hand at this, but I still end up doing similar things with new designs until I know I have the port definitions right.  You might also consider a PMod LED8 for debugging like this, although when compared to the PMod SSD it might only provide you with a limited debugging benefit.

Looking over your reset wire, you still have some problems.  Before ever using it in your design it should be clocked through a minimum of two FF's.  You've clocked it through one before referencing it.  That's not enough.  It needs to go through two before it can be referenced.  Prior to that time some logic might read the rst as high, other logic might read it as low--it's a nasty phenomena known as metastability.  It's also a hard phenomena to simulate, so its most often caught by desk checking.  Further, your shift register approach to generating rst is ... only burdening the timing of the rest of the design.  It's not required.  2FF's should be sufficient.  (You aren't likely to notice this timing burden on such a small design though ..)  Your finger press should also be longer than 10ns, so that shouldn't be a problem there.  In other words, you don't need to stretch the reset at all.  A single pulse is sufficient.

Dan

[zygot]

1 hour ago, PapaMike said:

I'm still struggling with the interface (you call them constraints),

Well, no. Constraints are put into .xdc files and assign pin locations, IO characteristics and timing requirements. Every Vivado project must have at least one constraint file.

1 hour ago, PapaMike said:

I'm actually getting pretty good at the simulation, but in this case, not good enough.

I assume that this means that you have written and added as simulation sources one or more testbench files. Learning how to write a good testbench takes some experience and hence time.

 

1 hour ago, PapaMike said:

"Go ahead. Try it out." Madness, but for me it's still enjoyable to work thru it.

The biggest problem with trying out designs on hardware is that, if you aren't careful,, you can destroy or cripple your hardware. This might be because of bad pin location assignments or making a situation in which 2 drivers are butting heads. I've been doing this for a long time and I'm always cautious about running a new bitstream on hardware. Pilots always go through a mandatory hardware checklist before taking off on a flight. 

Perhaps you could be a bit more descriptive as to your problems.

I'm glad that everyone agrees that simulation is a necessary prerequisite for generating bitstreams, just like pre-flight checklists.

[zygot]

Yeah, I just saw your file after @D@n's last post.

Be very careful using integers in synthesis. Be careful mixing integers, naturals, std_logic_vector, signed/unsigned etc in your design. If you know what you are doing it can be fine or even necessary. If you don't understand the differences between types then it will cause lots of headaches that are hard to resolve for the beginner. Noobs like to roll the dice and choose a signal type at random, because "What could go wrong?". Worse yet, they also like to use integer types for synthesis because it seems more familiar to computer programming.My advice is to stick with std_logic and std_logic_vector until you have a few reasonably complicated designs under your belt. If you MUST use integers or naturals for logic then at least constrain them with the range specifier. You can go through years of designs only using std_logic and std_logic_vector types. There's a difference in using natural or integer in your HDL to control synthesis and for actual logic expression in synthesis. You should understand that difference.

Dan's point about meta-stability is valid though for the earliest stages of very simple designs having a reset that might be ill-behaved once in 1 million assertions isn't really a problem. Having a clocked signal that happens 100 million times a second is a different matter.

Don't try and be an expert on your first designs. Start off mastering a few constructs and expand as you gain experience.

[PapaMike]

Wow. Looks like I stirred a wasps nest. Some really good stuff in there that needs my further attention. Before I get too lost in the woods with this design, let me go back and study up on some of your comments. Particularly, I want to learn more about this meta-stability problem before going further. That's not something I've seen discussed in the references I've read, but I think I understand your concern so I need to know more. So I'll just back down on getting more complex until I've got a better handle on some of these basics. Thanks, guys. Helpful as always.

[zygot]

1 hour ago, PapaMike said:

Particularly, I want to learn more about this meta-stability problem before going further

Meta-stability is a general issue more related to digital logic design than FPGA development per se, but it's still an issue that can plague FPGA designs. I highly support the notion of taking side trips investigating things like this as it breaks up-over focusing on a narrow range of details that trying to finish a design project can engender. I find switching gears now and then to be helpful even to the project that is left behind for  a bit. It is a more advanced topic for someone learning basic HDL skills though. You've got more pressing issues to deal with right now but everyone has a unique way to learn.

Your attitude is great. If you don't enjoy the challenge you're likely to get over-whelmed by it.