Jump to content

thinkthinkthink

Digilent Staff
  • Posts

    130
  • Joined

  • Last visited

Posts posted by thinkthinkthink

  1. If you go to Releases in the root repo for the Genesys ZU you'll find two SD card images for each board variant but it also tells you that: "Use a suitable imager tool to write the image file to the SD card. On Windows we recommend SDImager, an open-source tool. On Linux use the "dd" tool. Extract the *.img file from the archive and load it with the imager tool. Keep in mind that this will overwrite ALL data on the SD card.".

    Personally, I think Rufus would work too on windows in this case but I haven't tried. Hope this helps.

  2. image.png.26b42f8dddfdb76b2b97ea5d15a7e71e.png

    In the Board Flow tab right-click on the connector that's assigned to your Pmod's output and select Disconnect Board Component. Then right-click the output port of the Pmod and select Make External (or select the port and press Ctrl+T to make it external).

    image.png.c66c27a1f3691579fc0f642887296c53.png

    You can get the XDC file for the Zybo Z7-10 from here, add it to your project and uncomment the lines corresponding to the JA Pmod Header. Now replace the name of the ports with the name of your Pmod output interface, it should look something like this:

    image.png.85c23c110c08bc7b10a0a2d587703847.png

    If you want to know how I knew the exact names of the Pmod_out interface you should open your wrapper file and look at the ports of the wrapper entity.

    image.png.35fcdb8bbcf04aa8e5b7a63807dca64b.png 

    ##Pmod Header JA (XADC)
    set_property -dict { PACKAGE_PIN N15   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin1_io }]; #IO_L21P_T3_DQS_AD14P_35 Sch=JA1_R_p		   
    set_property -dict { PACKAGE_PIN L14   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin2_io }]; #IO_L22P_T3_AD7P_35 Sch=JA2_R_P             
    set_property -dict { PACKAGE_PIN K16   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin3_io }]; #IO_L24P_T3_AD15P_35 Sch=JA3_R_P            
    set_property -dict { PACKAGE_PIN K14   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin4_io }]; #IO_L20P_T3_AD6P_35 Sch=JA4_R_P             
    set_property -dict { PACKAGE_PIN N16   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin7_io }]; #IO_L21N_T3_DQS_AD14N_35 Sch=JA1_R_N        
    set_property -dict { PACKAGE_PIN L15   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin8_io }]; #IO_L22N_T3_AD7N_35 Sch=JA2_R_N             
    set_property -dict { PACKAGE_PIN J16   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin9_io }]; #IO_L24N_T3_AD15N_35 Sch=JA3_R_N            
    set_property -dict { PACKAGE_PIN J14   IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_0_pin10_io }]; #IO_L20N_T3_AD6N_35 Sch=JA4_R_N

    But as to why the Board workflow doesn't seem to work for some Pmod IPs anymore I do not know. Have Xilinx messed something up or have we messed something up ? 

  3. 13 minutes ago, Nik said:

    Thank you. It helped me a lot.

    But I am having little problem in IIC data writing. The program control stuck infinitely in the following code.

     

    
    while ((!TransmitComplete && !slave_nack_flag_)|| (XIic_IsIicBusy(IicInstance) == TRUE));

     

    Thanks,

    Which board are you running that on, Zedboard or Genesys 2 ? Did you just copy and paste the code from the Genesys 2 vitis project to your Zedboard vitis workspace ? The Zed project uses the PS_IIC i2c controller that's inside the ZYNQ processing system while the Genesys 2 one uses an AXI_IIC IP with SCL frequency set to 400kHz. There's a lot of driver differences between the two i2c controllers.

     

    Why your processor is stuck on that line of code is because you're either not getting an ACK from your i2c slave and you're not getting a NACK either somehow, or maybe because the i2c bus is busy. What to do in this situation is to put some breakpoints in the Status and/or Send Handlers to see what happens with those flags. Another thing to do is to check with an ILA what happens with the SDA and SCL lines.

    Right-click on the IIC line and select Debug.

    image.png.5036a14bfd08aeb20082a6ca024bf13c.png

    Then click on the huge horizontal green bar that says Run Connection Automation, once a new window pops up you can choose a clock on which that ILA will run, I recommend the clock output from the ZYNQ and then press Ok.

    image.thumb.png.a2cb07fb14f2758149e5ed74e62bf242.png

    Double click on the ILA IP and increase Sample Data Depth to as much as your design allows you (your bitstream might fails a couple of times until you get the right value, it's dependent on available BRAM so yeah...) and make sure to check the Capture Control box then press Ok.

    image.png.f10dded46950ca7fc717e0b564b61822.png

    Validate design and Generate Bitstream.

    After updating hardware platform and rebuilding the entire vitis workspace (hardware platform + application project) run the project in in Debug mode, before going through the code step by step you should go back to Vivado, open the Hardware Manager tab and connect to your board then an ILA window should open as well.

    Change Capture Mode to BASIC and in the Capture Setup tab add scl_i and sda_i signals. Also make sure to set capture condition to 'Global OR'.

    image.png.6555b90207b774690ea0da5b875eeddb.png

    image.png.ab128c01bcf220951b2824a013d12e2c.png

    image.png.a227f07ebf05a42088eefebf32b409fe.png

    Run trigger for this ILA core and see what happens when you go through the code step by step.

  4. For the Genesys 2 FMC Pcam Adapter Demo I rewrote everything in C so it should be easier to understand. 

    The a_pin parameter refers to those address lines (A0, A1, A2) on the I2C mux IC that's on the FMC Pam Adapter. As you can see the A2 line is already tied to GND so all that's left are A0(GA1) and A1(GA0) which come from the FMC connector. For those you have to check what they are tied to on the FMC connector that's on the Zedboard.

    image.png.47e38a1cb54edbc32dac84199fc57705.png

    image.png.141821c8c50354766423bc44585ac390.png

    image.thumb.png.b4ff14fb1795113a76b0583ead53d59f.png

    As you can see from the schematic, on the Zedboard the FMC pins corresponding to A1(GA0) and A0(GA1) are tied to GND.

    So that makes the values of A0, A1, A2 to be 000, which makes a_pin be equal to 0 (or 0x00 in hex).

    Basically, what you have to do is first address the I2C mux at address (0xE0 >> 1), tell it which channel to open (0, 1, 2, or 3) and then config your pcams through I2C at the (0x78 >> 1) address.  

     

  5. That's because those PMOD ports are connected to FPGA pins which can be reconfigured (inside the FPGA) for a lot of different functions/protocols while on the microcontroller those are wired to peripheral pins that only have a limited set of hard-wired functions. On an FPGA board you can make a custom design and be able to literally connect 4 different I2C devices to 1 PMOD port and have 4 different SCL and 4 different SDA lines (you'll need a bunch of wires but whatever). Basically you can customize those PMOD pins however you like/want/need.

  6. Go to your hardware platform in vitis and double click on platform.spr, once that opens click on the Modify BSP Settings... button.

    image.thumb.png.2d2e23073961a209589f3908f91117f6.png

    A new window will popup and then go to standalone under the Overview dropdown. Make sure that both stdin and stdout have their Value field set to axi_uartlite_0 (or whatever name your axi uartlite ip that you added later has). If you had to change them then don't forget to rebuild the whole workspace (meaning both the hardware platform and the application project).

    image.png.9c90af7f8583bc884d942fa18d72c225.png

    I don't get any of the errors you get while trying to create a project like yours, except that Vitis can't create an .elf file and my theory, just like James Colvin has told you, is that unfortunately the Basys3 does not have sufficient BRAM and no RAM to run applications like this one.

  7. Also, if you want to use UART 1 you'll have to route it to EMIO (and then constrain it to a physical Pmod port, or keep it all internal in the FPGA) since all other MIO pins are already hard-wired to other circuits on the board.

  8. HUGE DISCLAIMER! You'll have to write your own I2C driver using the iic functions in Xilinx's embeddedsw repo (XIic_MasterRecv, XIic_MasterSend etc.).

    image.thumb.png.e8c5388b135168ca2b609735df313f8f.png

    Add the two AXI IIC IPs to your block design and let Run Connection Automation do its job or you can manually make the IIC ports external. Then go to our XDC Repo and get the Zybo-Z7-Master constraints file. 

    Right click on Constraints and select Add Sources. 

    image.png.99ca333156c2e45ce27d83b4c4746290.png

    Click on Add Files and look for the .xdc file wherever you downloaded/saved it on your PC. Make sure Copy Constraints files into project is checked, this makes it so if you modify this .xdc file (which you will) you'll still have a fresh unmodified original which can then be imported into other projects.

    image.png.5f5b1a9392de58f15b587c3ecd41df0f.png

    Uncomment the lines corresponding to the Pmod port which you'll want to use, in this example I'm using JD but because of the HYGRO and AQS pmod pinout you'll only need to uncomment jd[2], jd[3] and jd[6], jd[7].

    image.png.a3deed2a072f538fedf10a5e4157e9dd.png

    This is the pinout for the PmodAQS and you might want/need to also use the IO/INT or WAKE/RST pins so make sure to read through its Reference Manual.

    image.png.a9eb13d8b5d8c6171423988ac9dcb762.png

    Make the following changes in the XDC, Validate Design, Generate Bitstream and you're good to go.

    image.png.8cfb7992e109c86f07090ed942e9a585.png

     

    image.png

  9. image.png.c787552191ef15297fec4d90c115fc50.png

    This is the pinout of the PmodHYGRO, to be able to use it on both top and bottom rows of a Pmod port you're going to need to use two AXI IIC IPs, or just one AXI IIC together with the I2C controller inside the ZYNQ processing system, with their interface IIC constrained to the Pmod port (one top row and the other bottom row) you're going to plug it into (double check to make sure you've nailed the pinout correctly). The PmodHYGRO IP also has an AXI TIMER inside it so maybe you're gonna want to add that to your block design as well (although you might be able to manage without it, not sure, since the ZYNQ also has some timers inside).

  10. Hi,

    Make sure to check your board's Resource Center, there you can find links to all sorts of tutorials and example projects. Also I strongly suggest to at least skim through its Reference Manual for a very detailed description of your hardware.

    The Zybo Z7 HDMI Demo should run you through both Vivado and Vitis and you only need an HDMI cable and a monitor to get it working. Don't miss the "Using the Latest Release" drop down on the demo page which has more detailed descriptions with screenshots for Vitis.

    When starting a new Vitis Application, what I do is Generate Bitstream in Vivado, export hardware (make sure the Include Bitstream is checked) to anywhere on your pc. Create a new folder and then open Vitis while choosing that folder as my workspace. Then once Vitis finishes opening that workspace I create a hardware platform, when prompted search for the XSA file you exported from Vivado previously. Next you should Build the hardware platform and once that's done you can create an Application Project based on that hw platform.

  11. We were working on a demo project for zynq ultrascale+ with the MIPI CSI RX Subsystem however it got postponed indefinitely. But you can check out Adam Taylor's own demo for our Genesys ZU board, he is using it in his block design.

    As for why some of our IPs are disabled when adding them to your project's IP Repository there could be multiple answers. What board is your project set to target ? I know for a fact our MIPI IPs are NOT compatible with the zynq ultrascale+ architecture so they're greyed out for me too when trying to add them to a Genesys ZU project.

    Or maybe when the source files were packaged into IPs, compatibility for Kintex7 wasn't added. However, I'm pretty sure our MIPI IPs work great on Kintex7 too, we have a FMC-Pcam-Adapter demo project for the Genesys2.

    What you can try is to open your Zedboard project, right-click on the IPs that are disabled elsewhere, go to Edit in IP Packager and press OK. It will open a new vivado tab, go to Compatibility and click on the "+" button and choose Add Family Explicitly....

    image.thumb.png.60c356ed66f082196d1313f69408d76e.png

    From there you can select to add the Kintex7 (Kintex-7) family to IP compatibility, just be aware that our MIPI IPs don't work on ultrascale and ultrascale+ families.

    image.thumb.png.1d3131751f20251b575ecced9e46ba3d.png

    And that should be it, also make sure to check our Genesys2 FMC-Pcam-Adapter DEMO too, it might literally be exactly what you need for your KC705 board. Here's the wiki page (don't let the un-updated photos fool you). 

     

×
×
  • Create New...