• Content Count

  • Joined

  • Last visited

Everything posted by dfergenson

  1. I'm writing to report that the design problem was completely solved for me by the updated design but I want to mention an experience that I had because I didn't understand what was happening myself until a few months later. I was one of the people who requested and received a replacement Cmod. That one suffered from the same disconnecting issues so I had just assumed that the issue remained. But I ordered two more Cmods a few weeks ago and neither had the issue. I mentioned this to my customer service rep and she sent a replacement for the replacement. That one worked well, too. I think that the channel may not have been flushed out initially but it is now. If you've replaced your Cmod and are still experiencing the problem, check with Digilent. The new boards work reliably.
  2. My company uses a CMOD A7 to drive a set of SPI-based peripherals, a few interlocks and some slow-moving analog controls. The 0.1" headers are plenty fast for SPI interfacing and make field repairs and upgrades simple. Speaking only for our application, I would not chose a higher pin density if one were available. I will, however, probably need an upgrade path at some point either to an Artix7 105T or a Zynq Z7-20. -David
  3. Thank you. Will instructions for how to make an exchange be posted to this thread? -David
  4. Thanks. Got it. I'm going to attempt to implement the fix and will report back when I've been able to reproduce it. Do you know if this will be addressed in future revisions to the Cmod A7 product line? -David
  5. Vicentiu, Thanks for doing this. I'm having a bit of trouble identifying the pads since some of the features are covered by components. Can you possibly post a photograph so that I can attempt to perform this modification? Thanks again for looking into this problem. -David P.S. I also found that using a USB 3.0 hub made my connection much more stable.
  6. 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.
  7. 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
  8. 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.
  9. Thank you. I will follow the Pmod specification. -David
  10. 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
  11. 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
  12. 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
  13. 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.
  14. @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?
  15. 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.
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. Thanks, Jon. I'll run some controlled experiments with BRAMs of different sizes. I don't think that the complexity of the code explains it. I've synthesized far more complex projects in the same ~3 minutes. Something tells me that this is a Synthesis 101 level issue but I may be underestimating it. In any event, I'll post my results to the forum. -David
  22. Thanks, Jon. Actually, could you compare it to the synthesis time of the Basys3 basic demo file which has similar VGA functionality? The most obvious difference between the two is the population of the BRAM but I can't imagine that that would add 6-7x the synthesis time. -David
  23. Thanks. I'm running on a 4 core 2.6 GHz Core I7. I have Windows7 running through Parallels simultaneously with MacOS X. It's running on an SSD. So it's hard to say exactly how much processing power is being brought to bear against the synthesis but it's a medium amount. The issue, as far as I'm concerned, isn't the total time that it takes but rather how much longer it takes. If its much faster to synthesize the Basys3 example with more features then there must be an issue with synthesizing the ported Nexys4 example.
  24. Thanks, jpeyron and whosaidturkey. I was able to implement the COE and see the logo. The BMP to COE m file will be extraordinarily useful for the work that I'm doing. I can't wait to test it out. I'm investigating an issue that may be related to the BRAM and definitely involves the Nexys4DDR demo so I'm including it here, though I can move it to a new thread if that would be helpful. It also involves the Basys3. I synthesized and implemented the Nexys4DDR demo file that jpeyron provided and it took roughly 25 minutes from initiation to a generated bitstream. It took about 3:20 to synthesize the Basys3 demo and I'd initially chalked that up to there being more fabric on the Nexys4's Artix7 100T vs. the Artix7 35T on the Basys3. I now know that to be incorrect and I'm trying to find what's causing the hang up. I've managed to put the problem in a box. Because I had misattributed the long synthesis time to the more capable FPGA and because I'm probably not going to use most of the 100T's fabric, I tried porting a simple mouse and monitor GUI from the Nexys4 project to the Basys3 in Vivado 2017.1 (which is worthwhile upgrade from 2016.X). It takes the same ~25 minutes to synthesize on my computer while the Basys3 GPIO demo takes the same 3:20 or so. I've posted my code to a project on GitHub: https://github.com/dfergenson/GUI_LogoAndMouseLongSynthTime I looked on the Xilinx Vivado forums for typical reasons for slow syntheses and they mentioned two possibilities: clock domain conflicts requiring extraordinary syntheses to resolve and RAM being implemented in flip flops. I looked through both synthesis reports and the flip-flop issue does not seem to be a problem. My VHDL seems to keep the clock flows clean, too. I've attached both synthesis and utilization reports to this document. So I haven't been able to resolve the issue. Have you observed the long synthesis time yourself? Do you have any thoughts as to what the bottleneck may be? Thanks. David Basys3GPIO_demo_utilization_synth_Report.txt Basys3GPIO_demoSynthesisReport.txt PortedNexys4_utilization_synthReport.txt PortedNexys4SynthesisReport.txt
  25. I'm appending this to this thread because it references the zip file posted in response to the initial question. Please feel free to recategorize it and to remove this header if you chose to move it. I was able to successfully synthesize and implement the demo using Vivado 2016.4. Thanks for pushing out the update. When I run it, I see a black rounded rectangle where the Vivado logo should be. I think that this is because I overwrote the logo in memory when writing the .BIN file, though I can't be sure. I was unable to find a logo file to replace it which I'd like to do because I'm trying to work out how to implement an HMI of my own. Can you please point me towards the original logo file? There's a comment within LogoDisplay.vhd that says that it is located in the bram_1.ngc file but I was unable to locate that file. I see that a component called BRAM_1 is declared and it appears to use IP to reserve the memory space for that data. Am I correct to assume that the bram_1.ngc file should be loaded as the Init file under the Other Options tab in the IP configuration generator? The file extension that that options uses is .coe. Is there a .coe version of the logo then? Or is my explanation of what has happened simply incorrect? Any instructional resource that you could point me towards would be greatly appreciated. -David