• Content Count

  • Joined

  • Last visited

About dfergenson

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've stumbled upon what seems to be a complete solution to this problem. First, I switched cables, which did help but I still couldn't run the ILA through the new cable. In order to get ILA working, I lowered the connection speed. To do this: 1. In the lower left corner of Vivado, right click on "Open Hardware Manager" and press the menu that pops up to close it. This is poorly labeled but what it actually does is disconnects the Cmod. 2. Regular click on "Open Target" and select "Open Hardware Target..." A window will pop up in the middle of the screen. 3. Click "next". Make sure that Local Server is selected in the popup before clicking "next" again. 4. In the next window, you'll have the option to select the connection speed. Select a slower speed and click to connect. In my case, I'm routing my USB circuitry through a PCB because I need to be able to select between bus power and PCB power. That made my connection unstable so to get things up and running I just directly connected (at the default 15000000 Hz) with a new cable. But I couldn't run ILA successfully. So I had to connect at slower speeds to use ILA (6000000) but when I did that it made the JTAG connection more stable as well, even through the PCB. I went to an extreme and the system was stable at 125000 Hz but at this speed it begins to hurt my personal productivity. I'm going to do a binary search to see what I can get away with. Can anyone else confirm that this works for them? Would anyone else care to post their successful connection speeds? If this is a complete solution, then it would seem to obviate the need for a redesign of the Cmod USB/JTAG circuitry.
  2. Please forgive a nitpicky post but if I had trouble with these issues then so will others. I looked through the Cmod A7 Reference Manual and a few pieces of critical information seem to be just plain missing. 1. The addresses for the PCB pins aren't listed. They are for the pmod but not for the pins that actually set into a socket. 2. The clock speed and address aren't listed. I've been able to figure out these values from other forum posts and from the .XDC file but can someone please put them in the manual itself? If they're already there and I somehow just missed them then I apologize and will, forthwith, get myself fitted for reading glasses. -David
  3. I just checked my Cmod A7 mating to two Sullins Connector PPPC062LFBN-RC (DigiKey p/n S7109-ND) and they fit. Because each connector is independent of the other, you'd have to solder the connectors into a PCB with the Cmod connected to make sure that they don't rock out of alignment with each other.
  4. Thank you. I will follow the Pmod specification. -David
  5. I'm preparing to embed a Cmod A7 on a PCB and I want to provide similar circuit protection for some of its pins to those found on a Pmod output. I looked at the schematics for the Basys3 and found a 200 Ohm series resistor on each output pin and a zener diode directly from pin to ground. I have two concrete questions: 1. Just to confirm, the Zener voltage should be 3.4V, right? 2. What power does Digilent recommend for the 200 Ohm resistor? Thanks. -David
  6. I think that part of the problem is that the locations of these files are inconsistent between different resource centers. I was looking for the STEP file for the Cmod A7 and I found it in the Design Resources section of the table but not in the Additional Resources area. Can you have someone look into documentation consistency among similar products? It's not the most pressing of concerns but it's also a pretty easy fix. Thanks. -David
  7. I had been referring to the Basys3 but looking at the resource page I found it. It was under the Additional Resources area. Thanks. -David
  8. The .STEP files that were attached to jpeyron's post were hugely helpful. I didn't see them among the resources on the product pages myself. If I didn't just miss them somehow, can you request that they be added? Thanks.
  9. @freakuency, I had the same problem with the HDMI example as you did and ran into the same stumbling block. Here's how I resolved the issue with @jpeyron's help. The IP report window is confusing. When you click on the Upgrade IP link, it just reminds you of the importance of checking the log and then upgrading the IP. Not helpful... But at the bottom of the screen (and this is sometimes obscured on different sized windows) is a button to upgrade the IP. If you check the box next to the out of date IP, (in the case of the HDMI Zybo Z7-20 demo, its DVI2RGB) you can update it. The outdated IP creates a downstream problem because it prevents an HDL wrapper from being created around the block diagram which you now need to do by right clicking on the .bd in the source code browser. If you do this, you can generate a bitstream. I'm still stumbling over actually getting the SDK to work. I ran into the same problem that you did and so far haven't gotten past it. @jpeyron, although it didn't help @freakuencycan you tell me where to find the .meta file to delete?
  10. I don't know if I missed it earlier or if it was just added today but the flash memory part number is absolutely mentioned in the Zybo Z7 specifications. It is a Spansion S25FL128S. Either thank you very much or else sorry to have bothered you.
  11. Thanks, Jon. I was able to synthesize and generate a bitstream and memory configuration file. I would like to note that the model of the memory is not explicitly described in the specifications and there are three models of Spansion memory that seem to fit that general description. Can the specifications be updated to reflect the actual memory module for configuration file generation? I also think that I've determined the root cause of the problem. In the -10 version of the example code, I think that all of the IP was already up to date. In the -20 version, the DVI2RGB version was 1.7 when the current version was 1.8. This hung up a critical step in the TCL script. I read through the logs and found the following error had been thrown: So the out of date IP interfered with the creation of the top level wrapper (which you instructed me to create once I had updated the IP). That wrapper was created automatically in -10. What I had done instead was specify design1.bd as the top level file for synthesis. Vivado lets you do that if you type in the name but I now realize that, while permissible, it's not a good practice because it caused those ports not to be recognized when Vivado encountered them in the .XDC file. So, if whoever maintains the Git could update that IP, that would permanently solve the problem. Thanks again for your guidance. Adding the wrapper HDL was, indeed, the missing link. -David
  12. Thanks. I had downloaded the .zip from the link on the resources page. I did use Vivado 2016.4 and reconstituted the demo using the TCL command. Yes, I'm using a Zybo Z7-20, though I hadn't gotten far enough on the -20 demo for it to have come into play. I will run through the process again and will let you know how things go. -David
  13. Jon, Thanks. After reviewing the Zybo Z7-10 version of the code and the specifications of both -10 and -20 PCBs and processors, I decided that the simplest route would just be to change the board definitions file in the -10 version to a Zybo Z7-20. As before, everything synthesized. Can you see anything wrong with this approach? -David
  14. I'm attempting to get the Zybo Z7 HDMI demo running on my Zybo Z7-20. I was able to get a bitstream generated from the Zybo Z7-10 version of the demo working without issue but not from the Zybo Z7-20. I'm running Xilinx SDx version 2016.4. I ran into and resolved some unrelated issues such as: I added the Digilent-specific IP. I dealt with an IP version issue. I specified the top level of the project as being the diagram itself. After having done this, I've been able to synthesize and implement the project. But I could not generate a bitstream and the problem seems to be an incompatibility between the diagram as drawn and the board as described in the documentation which is specifically being raised as in issue in the XDC file. Here is the specific error that I get: This seems like it should be a fairly simple problem to work around but I've been unable to determine how to do so. But perhaps I'm missing something very obvious? So, my concrete questions are: 1. Has anyone successfully gotten the Zybo Z7-20 version of the HDMI example to synthesize "out of the box"? 2. Does anyone have an edited version of the .XDC for the Zybo Z7 that has been made to work? Otherwise, I'll reply to this post with a working .XDC if I'm able to get it working. I've attached the default .XDC to this post just in case it helps. Zybo-Z7-Master.xdc
  15. I've been continuing development and I'm using fairly large blocks of BRAM (40 of the 50 BRAM blocks available on the Basys3) and I'm still getting synthesis times of ~3 minutes. So there is something about the Nexys4DDR VHDL example code that specifically takes a long time to synthesize. I'm still curious as to what it might be but I've found a functional workaround in the form of the streamlined code that I'm synthesizing. If the problem rears its ugly head again, then perhaps by comparing the two offending projects with the successful one I'll be able to figure out what's going on. If I do so, I'll create a new thread since it's really a different problem. So anyone who is watching this one for the answer should follow my account instead or else send me a private message and I'll let you know if I do start that thread. Thanks again for all of the help. -David