artvvb

Technical Forum Moderator
  • Content count

    223
  • Joined

  • Last visited

  • Days Won

    13

artvvb last won the day on November 22 2017

artvvb had the most liked content!

1 Follower

About artvvb

  • Rank
    Prolific Poster

Profile Information

  • Gender
    Male
  1. Unable to add modules to designs

    The Pmod bridge is primarily a remap from one of a couple of different built in interfaces into the Pmod interface used by our board files. If you configure both top and bottom rows to use the GPIO interface, you can expand the interface and manually connect other IPs to the gpio_i, gpio_o, and gpio_t ports. This can be a little tedious and hacky, but it should work fine. Thanks, Arthur
  2. Unable to add modules to designs

    I am not sure why actual syntax errors aren't showing up for you. I guess you could try copying the file into a Vivado project that doesn't use IPI to check them before you go to add the module. The attached file has "do" instead of "d0" on line 11. It is also missing a "`timescale 1ns / 1ps" line at the top of the file (though this may not be required). As a bit of a sidenote, the assign statement on line 11 is a three input and, not a mux. I would expect "assign z = (d0 & ~s0) | (d1 & s0);" or other equivalent syntax. Thanks, Arthur
  3. PMOD COLOUR sensor

    Also, for more information on the auto-increment protocol check out Figure 23 on page 19 of the AMS datasheet.
  4. PMOD COLOUR sensor

    @MD AKRAMUDDIN 1. I am not sure if I understand this question, do you want to create a custom I2C controller in HDL and use it to interact with the Pmod Color? If so, then yes, it is possible. 2. Thank you for pointing this out, I will get it fixed. As an additional note, much of this information is also available in the datasheet for the AMS chip used on the Pmod Color (available here, and linked in the reference manual). 3. Auto-increment is a feature of the chip being interacted with. It may involve slightly more complex verilog, but should be possible. Take a look at the AMS datasheet for timing diagrams. 4. If you are writing your own custom hardware, you do not need to write any C code to interact with the Pmod Color. However, for a Zynq system in particular, you may need to use the ARM processor with C code to collect data from your hardware and forward it to your computer. (Edit, saw that you are using a zedboard, which is a Zynq system...) Let us know if you have any more questions! Arthur
  5. Unable to add modules to designs

    @Android You are looking at the correct window. A couple of GUI tips that might help: In the Sources pane, on the right side of the toolbar there is the orange exclamation point with the number 4 next to it. If you click on that it will open up the messages tab in the pane at the bottom of the screen that currently is displaying the TCL console. This will show the critical warnings, which (hopefully) will be hints that there are syntax errors. If you right click anywhere withing the Sources pane, one of the options is to "Refresh the Hierarchy", which will force vivado to make sure that it is showing everything as it should be. I would try doing this before anything else.
  6. Zybo and PmodCAN

    @mbo Have you completed the Getting Started with Pmod IP Cores tutorial through to using Vivado SDK and programming your board? Your hardware looks fine. Using Pmod Header JF would be significantly more difficult than using any other header, since the MIO/EMIO pins don't use the same drivers as the AXI SPI controller that the Pmod CAN IP core wraps. The MIO pins are configured by customizing the Zynq7 Processing System block in Vivado IPI (they appear in the block design as part of the FIXED_IO interface). You can use the LoopBack.c example to make sure that your Zybo can talk to the Pmod CAN. LoopBack places the CAN controller into a mode where the controller receives it's own messages in hardware, so it is a good way of making sure that your hardware works. After that, you can program your hardware onto both Zybos, connecting each to a CAN, and connecting each of the CANs to one another. You can program one Zybo with the RX.c example and the other with the TX.c example. This set up should be able to send a packet defined in the example code from one Zybo to the other. You can demonstrate that this communication has happened by connecting both boards to serial terminals. Thanks, Arthur
  7. Unable to add modules to designs

    Are any sources in the hierarchy underneath capt_wrapper.v not found? Other than commenting out that line, the other thing I had to do to make the capt_wrapper module appear was comment out the instantiation of prot_mux2 (line 197). Do you have access to this file? You don't need to provide it to us, but if you don't have it, then you will not be able to add the module. The screenshot below shows my hierarchy tab with only line 60 commented out. Thanks, Arthur
  8. Unable to add modules to designs

    @Android Adding all sources at the same time should be fine. The issue that I see is that Vivado is detecting some kind of syntax error in the files - hence categorization under "Non-Module Files". This might be some form of unsupported SystemVerilog syntax (I am unfamiliar with systemverilog). When I try to import capt_wrapper (in a 2017.4 project), I am seeing a syntax error on line 60 (input <clock>, // (required)) that could be causing issues. The "Referencing RTL Modules" section of Xilinx UG994 starting on page 159 lists a few other reason why the sources might not be showing up in the list (although that particular document won't tell you why there might be syntax errors). Thanks, Arthur
  9. PMODGPIO build on Zybo (2016.4)

    You will need to regenerate the BSP for the SDK project. Start by deleting the BSP in you project workspace in SDK. Create a new BSP with the exact same name as the old one through the File -> New menu, targeting your hardware platform. Keeping the old name means that your application project should target the new BSP just how it was previously using the old one. This new BSP should contain the PmodGPIO driver source code in it's libsrc directory, as well as a new version xparameters.h file in it's include directory. Since your application project should now target the new BSP, it will be able to automatically pull in those files when you include them. The XPAR_PMODGPIO_* macros should exist in the new xparameters.h file. Thanks, Arthur
  10. Live video processing on Zybo board?

    Unfortunately it looks like Xilinx's Video Mixer IP requires an additional license to use (I have not looked into pricing). This means that (without buying the license for the mixer) modifying the hardware pipeline would probably require a custom IP, which would be quite difficult. I should also note that I am not aware of anyone at Digilent that has used the Video Mixer IP before, so any questions about that would probably have to go to Xilinx. For the coordinate systems used in the DemoScaleFrame function, the comments at variable declaration are helpful. The most relevant here is at the declaration of xcoDest and ycoDest. int xcoDest, ycoDest; // Location of the destination pixel being operated on in the destination coordinate system The for loop that contains the Bilinear interpolation function "handles all three colors". This means that within the byte-buffer destFrame, each set of three consecutive bytes represents the R,G,B color values for that pixel with 8 bits of data apiece. The macro DEMO_STRIDE defines the line length of the video buffer - noting that the buffer is always sized to be able to contain 1920x1080x3 bytes of color data, regardless of what resolution is actually being used. What this means is that to index into an area of the destination frame outside of the for loop - which may be helpful if the target color of pixels that are indexed earlier in the for loop depends on the color of later pixels - you can set a destination index, iDest, to be 3 * 1920 * (the y coordinate of your pixel) + 3 * (the x coordinate of your pixel). The RGB values of this pixel will be placed at the memory addresses destFrame[iDest], destFrame[iDest+1], and destFrame[iDest+2]. EDIT: I just noticed the phrase pixel averaging in your post, the rest of my response is just describing this. Could you explain what you mean by blurring the area of the input frame? There are a lot of different algorithms to do something like this... As an example of what I mean, you could figure out what each of the pixels in the area to be blurred would be if they were bilinearly interpolated, take a weighted greyscale conversion of each of the pixels, then take the average of these greyscale pixels, then write that average to each of the color channels of each of the pixels in the target area. I don't believe that the result of this method would look particularly good (a grey box, where just how grey it is depends on the input frame), but might be another good step. -Arthur
  11. Unknown Resource

    @deppenkaiser The UART is instantiated and the UART pins are mapped as part of the "Run Block Automation" process, which applies the Zynq preset contained in the board file. You can configure the UART by customizing the Zynq IP. The UART is represented in the block design as a part of the FIXED_IO interface of the Zynq block. In addition, the UART connection cannot be used in a pure-HDL project. Thanks, Arthur
  12. XADC sampling and acquisition timing

    @drewphysics Unfortunately, my personal experience with using the XADC only really applies to DC and low-frequency AC waves. You may need to take into account the additional resistors and capacitors between bank 35 and the JXADC / JA Pmod headers, as seen in the Basys 3 schematic. For the sake of other people who may be reading this, I assume that you are getting the 3pF / 10kOhm numbers from pages 29 and 30 of ug480? To the question itself: I am not sure, I'd recommend asking Xilinx on their forums, or perhaps someone else can chime in here. Thanks, Arthur
  13. XADC sampling and acquisition timing

    Oops, you are correct, address is seven bits. Are your d# signals in the logic analyzer screenshots the do_out pins? My understanding of how the XADC works is that it will continuously capture data without you doing anything. Whenever a conversion is completed, the data from that conversion is loaded into the appropriate channel's register. The eoc_out flag alerts you that there is a new piece of data to check on. Your interface for actually getting at the registers of the XADC is the DRP interface, (daddr_in, den_in, di_in, do_out, drdy_out, and dwe_in). Of these signals, we don't care about the write enable or the data input, and they should be held low. To read a value from a register, we assert den_in and daddr_in (probably at the same time), and when drdy_out is asserted, we latch the data into a reg out of do_out. As for how to tell which sample is which, and which sample is being read, this is what the CHANNEL[4:0] signal in the timing diagram you added to the first post is for. According to page 73 of the 7Series XADC user guide, EOC, CHANNEL, and DRDY are intended to be used together, and should all represent information about the same sample. By this I mean that the second EOC should pertain to sample N. Thanks, Arthur
  14. XADC sampling and acquisition timing

    I reread your post, and to answer the specific question, this sounds correct to me, but you will need to ask Xilinx to make sure, as they are the ones that created the IP. Thanks, Arthur
  15. XADC sampling and acquisition timing

    I have only used Continuous Channel Sequencer mode personally (caveat for the following). I believe that the DRP interface is largely independent of the conversion process (hence tying the den_in and eoc_out ports together). This means that data should be captured from do_out when drdy_out goes low and you have provided a stable daddr_in signal, largely ignoring the End Of Conversion signal for this process. I am curious how you are driving daddr_in, is it tied to GPIO/Buttons/Switches, or is it floating currently? This port is the address port for the DRP interface and needs to be set. In the case of using only the AN6 channel, I believe the register address to get to the data is 6'h16. Thanks, Arthur