• Content Count

  • Joined

  • Last visited

Posts posted by dfergenson

  1. 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.


    P.S. I also found that using a USB 3.0 hub made my connection much more stable.

  2. 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.

  3. 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.


  4. 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.

  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?



    Screen Shot 2019-01-02 at 10.34.00 AM.png

  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. @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?

  8. 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:


    [BD 41-1665] Unable to generate top-level wrapper HDL for the BD-design 'design_1.bd' is locked. Locked reason(s):
    * BD design contains locked IPs. Please run report_ip_status for more details and recommendations on how to fix this issue. 
    List of locked IPs: 

    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.


  9. 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

  10. 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?


  11. 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:

    1. I added the Digilent-specific IP.
    2. I dealt with an IP version issue.
    3. 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:


    [DRC 23-20] Rule violation (NSTD-1) Unspecified I/O Standard - 12 out of 159 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: hdmi_out_ddc_scl_i, hdmi_out_ddc_scl_o, hdmi_out_ddc_scl_t, hdmi_out_ddc_sda_i, hdmi_out_ddc_sda_o, hdmi_out_ddc_sda_t, hdmi_in_ddc_scl_i, hdmi_in_ddc_scl_o, hdmi_in_ddc_scl_t, hdmi_in_ddc_sda_i, hdmi_in_ddc_sda_o, hdmi_in_ddc_sda_t.

    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.


  12. 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.


  13. 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.

  14. 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?







  15. 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.


  16. I've been looking through the technical documentation and schematics for the IOXP pin assignments. I hope that I'm not just the world's biggest idiot here but I'm having a lot of trouble figuring the pin assignments out from the documentation. They just don't seem to be given at all in most cases and the ones at https://reference.digilentinc.com/reference/pmod/pmodioxp/start appear to be inconsistent with the hardware that I have in front of me.

    For example, in the documentation, J1 and J2 both have twelve pins but the pin assignments at refer to 8 pin headers for those. J3 has eight pins and only 3 are assigned and those don't correspond to the inputs that they would line up with on a standard Pmod. On the schematic, J1 and J2 do, however, refer to 12 pin headers.

    If I understand the schematic of the ADP5589 data sheet correctly (http://www.analog.com/media/en/technical-documentation/data-sheets/ADP5589.pdf), the RST, SDA and SCL inputs really seem like they should be found on input header J3, along with Vcc and Ground (not documented). And there should be 19 bidirectional digital input/outputs, R0 through R7 and C0 through C10, that I would assume would be distributed between J1 and J2. On the schematic (https://reference.digilentinc.com/_media/reference/pmod/pmodioxp/pmodioxp_sch.pdf), C0 through C3 and R0 through R3 are on J1, C4 through C7 and R4 through R7 are on J2 and C8 through C10 are on J4 which is not referred to in the documentation.

    So, am I missing something very obvious or is the documentation incomplete/incorrect? And since the schematic contradicts the documentation but seems to be more closely aligned with the part in front of me, do I assume that the schematic is correct?

    In either case, does anyone have definitive pin assignments on this? And can a Digilent engineer please update the doc wiki to reflect them?

    If nobody has this information, I'll have to do some detective work and will post the pin assignments here.

    For completeness: I am using the IOXP on a Nexsys4 CDR attached to header JC, pins 3 through 6 and 9 through 12. I am planning to drive it using I2C coded in VHDL.

  17. 5 minutes ago, D@n said:

    I'm using the Basys3 board and communicating with my PC at 4MBaud.  Communicating over the USB is done via the UART protocol.  Hence, to talk to the FT2232 you mention, you simply use the two wires of a UART.  This shows up inside my Linux box as /dev/ttyUSBx and acts ... just like a UART on both ends.

    If you are looking for UART RTL code, you can find the UART code I'm using for my Basys3 copied into my S6SoC project here.  (It's in the trunk/rtl directory, in the rxuart.v and txuart.v files).  Cranked up, I've ran this UART from my Basys3 board to/from my host PC at 4MBaud while clocking the design at 10MHz.  (Sorry, I don't have my Basys3 project posted anywhere ...)


    Thanks, Dan. I may look to the community for more help but when I do have a simple PC host application communicating with a simple VHDL program on a Basys3 I'll post it or a link to it here (unless someone beats me to it). -dfergenson