Antonio Fasano

Members
  • Content Count

    46
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Antonio Fasano


  1. Hi, Jon,

     

    I went back to the old computer and VIVADO 2018.1. I did the same change to the IP. Updated the IP and tested the new solution. It worked flawlessly. Then I copied the whole project to the new computer with VIVADO 2018.3 and upgraded the project to 2018.3. Recompiled everything and the new bitstream works OK.

    My concern now is if I make any change to the IP in 2018.3, will it get to the resulting bitstream ?

    What hints should I look for to know that it has eventually not been processed correctly. Those kinds of problems take days to figure out the solution ...

    Is there a short manual where we can find an explanation for the file structure of a VIVADO project ?

    Those endless XILINX manuals take months to read and information is not objective in almost all of them ...

    Thanks

    Antonio


  2. Hi,  Guys

    I am facing another difficulty with Arty-Z7-20. One of the custom IP´s that I made has only one output (square wave).

    I change the output to Output <= ´0´ in the vhdl file using the"Edit IP in Packager" option

    Then I re-generate bitstream in the main project after updating the IP.

    The resulting bitstream seems to be picking the IP vhdl from somewhere else, because in the resulting design, the square wave signal is still present. (The IP packager shows the correct path to the file, though...)

     It seems that the vhdl for the IPs come from somewhere else. No matter what I change in them, the result remains the same ...  Go figure ... 

    Have you ever seen that behaviour ?

    Antonio


  3. HI, Guys,

    I am getting a message "Undefined Reference to Disk_read" in my Arty-Z7-20 project. 

    file ff.c is not resolving call to disk_read and disk_write

    I just changed my computer to a new one and now I cannot compile and run a project that was already working in the old computer. Anyone has a clue as to why it is happening and how to fix it ?

    Thanks

    Antonio


  4. Hi, Guys,

    I changed my computer and installed Vivado 2018.3 instead of VIVADO 2018.1 I had in the old computer.

    I opened an Arty-Z7-20 project that was running well on the old computer and with this new computer I got the following error

    make: *** No rule to make target 'C:/TEST_ZYNQ/A8-X4000/X4000Board.sdk/X4000_wrapper_hw_platform_0/ps7_init.c', needed by 'src/ps7_init.o'.  Stop.    

    Any clue on what is causing it and how I may solve it ?

    Thanks

    Antonio


  5. Hi, Guys,

    I am working iwth Vivado 2018.1

    Suppose I have a complete project with bitstream, Hardware files and SDK files in directory c:\Arty_Test

    If from within Vivado I save the project to another directory, say c:\Arty_Test2 (Even with option "Import All files to new project" clicked) , the new project software files will not open correctly when I invoke SDK. It still looks for files in the original directory.

    Is there a way to make sure it will save all files and update all references to the new directory ?

    Thanks

    Antonio


  6. HI, Jon

    Thank you very much. Now I know what went wrong. In the constraints file I was writing gpio(0), gpio(1), etc. 

    By looking at your example, I noticed that the correct spelling is gpio[0], gpio[1], etc. 

    I changed it in my project and it ran fine.

    Once again thank you very much for your time and for your guidance.

    I owe you another one !!!

    Regards,

    Antonio


  7. Hi, Jon

    I tried to make external the while GPIO output and not only the _t signals.

    The new wrapper file becomes much similar to the one that works, but the  placement error continues to appear.

    This is the link to the project archive that is working:

    https://www.dropbox.com/s/f4w9mpa2lgwoj2s/X4000Board.xpr.zip?dl=0

     

    This is the link to the modified project  that is not working

    https://www.dropbox.com/s/f7ovtbijw3zzv7i/X4000Board.xpr MODIFIED.zip?dl=0

     

    The zynq chip is

    XC72020

    CLG400ABX1701

    D5348119A

    Thank you for your support.

    Antonio


  8. Hi, Jon,

    I inspected both the older wrapper file and the neweer (After I made the customs 13 outputs external instead of the shield pins..

    The older file shows a lot of references to the shield pins, including i / o and t sufixes (See below)

          shield_dp0_dp13_tri_i(13) => shield_dp0_dp13_tri_i_13(13),
          shield_dp0_dp13_tri_i(12) => shield_dp0_dp13_tri_i_12(12),
          shield_dp0_dp13_tri_i(11) => shield_dp0_dp13_tri_i_11(11),
          shield_dp0_dp13_tri_i(10) => shield_dp0_dp13_tri_i_10(10),
          shield_dp0_dp13_tri_i(9) => shield_dp0_dp13_tri_i_9(9),
          shield_dp0_dp13_tri_i(8) => shield_dp0_dp13_tri_i_8(8),
          shield_dp0_dp13_tri_i(7) => shield_dp0_dp13_tri_i_7(7),
          shield_dp0_dp13_tri_i(6) => shield_dp0_dp13_tri_i_6(6),
          shield_dp0_dp13_tri_i(5) => shield_dp0_dp13_tri_i_5(5),
          shield_dp0_dp13_tri_i(4) => shield_dp0_dp13_tri_i_4(4),
          shield_dp0_dp13_tri_i(3) => shield_dp0_dp13_tri_i_3(3),
          shield_dp0_dp13_tri_i(2) => shield_dp0_dp13_tri_i_2(2),
          shield_dp0_dp13_tri_i(1) => shield_dp0_dp13_tri_i_1(1),
          shield_dp0_dp13_tri_i(0) => shield_dp0_dp13_tri_i_0(0),
          shield_dp0_dp13_tri_o(13) => shield_dp0_dp13_tri_o_13(13),
          shield_dp0_dp13_tri_o(12) => shield_dp0_dp13_tri_o_12(12),
          shield_dp0_dp13_tri_o(11) => shield_dp0_dp13_tri_o_11(11),
          shield_dp0_dp13_tri_o(10) => shield_dp0_dp13_tri_o_10(10),
          shield_dp0_dp13_tri_o(9) => shield_dp0_dp13_tri_o_9(9),
          shield_dp0_dp13_tri_o(8) => shield_dp0_dp13_tri_o_8(8),
          shield_dp0_dp13_tri_o(7) => shield_dp0_dp13_tri_o_7(7),
          shield_dp0_dp13_tri_o(6) => shield_dp0_dp13_tri_o_6(6),
          shield_dp0_dp13_tri_o(5) => shield_dp0_dp13_tri_o_5(5),
          shield_dp0_dp13_tri_o(4) => shield_dp0_dp13_tri_o_4(4),
          shield_dp0_dp13_tri_o(3) => shield_dp0_dp13_tri_o_3(3),
          shield_dp0_dp13_tri_o(2) => shield_dp0_dp13_tri_o_2(2),
          shield_dp0_dp13_tri_o(1) => shield_dp0_dp13_tri_o_1(1),
          shield_dp0_dp13_tri_o(0) => shield_dp0_dp13_tri_o_0(0),
          shield_dp0_dp13_tri_t(13) => shield_dp0_dp13_tri_t_13(13),
          shield_dp0_dp13_tri_t(12) => shield_dp0_dp13_tri_t_12(12),
          shield_dp0_dp13_tri_t(11) => shield_dp0_dp13_tri_t_11(11),
          shield_dp0_dp13_tri_t(10) => shield_dp0_dp13_tri_t_10(10),
          shield_dp0_dp13_tri_t(9) => shield_dp0_dp13_tri_t_9(9),
          shield_dp0_dp13_tri_t(8) => shield_dp0_dp13_tri_t_8(8),
          shield_dp0_dp13_tri_t(7) => shield_dp0_dp13_tri_t_7(7),
          shield_dp0_dp13_tri_t(6) => shield_dp0_dp13_tri_t_6(6),
          shield_dp0_dp13_tri_t(5) => shield_dp0_dp13_tri_t_5(5),
          shield_dp0_dp13_tri_t(4) => shield_dp0_dp13_tri_t_4(4),
          shield_dp0_dp13_tri_t(3) => shield_dp0_dp13_tri_t_3(3),
          shield_dp0_dp13_tri_t(2) => shield_dp0_dp13_tri_t_2(2),
          shield_dp0_dp13_tri_t(1) => shield_dp0_dp13_tri_t_1(1),
          shield_dp0_dp13_tri_t(0) => shield_dp0_dp13_tri_t_0(0),
          

     

    while the new wrapper file only shows some _t ocurrences of the gpio_io_t_0 signals

    That´s all that appears in the new wrapper.

    gpio_io_t_0(12 downto 0) => gpio_io_t_0(12 downto 0),

     

    There are several IOBUF  components that do not appear in the new wrapper also.

    Perhaps instead of re-generating the wrapper I should keep the older wrapper and only change the signals, right ?  But what about the other _o  _i  signals ?

     

    Thanks

    Antonio

     


  9. Hi, Jon,

    That was exactly the first thing I did. I followed your instructions thoroughly with the gpio_io_t entries.

    Then I changed it to gpio_io_o to see if the results would be any different.

    But the errors were the same.

    Anything else I could try ?

    Thanks

    Antonio


  10. Hi, Jon

    I did exactly what you say in your post but I keep getting placement errors:

    Portion of the wrapper file:

       SDATSAI2 => SDATSAI2,
          gpio_io_o_0(12 downto 0) => gpio_io_o_0(12 downto 0),                        
          shield_dp26_dp41_tri_i(15) => shield_dp26_dp41_tri_i_15(15),
     

    Portion of hte XDC file:

    set_property -dict { PACKAGE_PIN T14   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(0)  }]; 
    set_property -dict { PACKAGE_PIN U12   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(1)  }]; 
    set_property -dict { PACKAGE_PIN U13   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(2)  }]; 
    set_property -dict { PACKAGE_PIN V13   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(3)  }]; 
    set_property -dict { PACKAGE_PIN V15   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(4)  }];
    set_property -dict { PACKAGE_PIN T15   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(5)  }]; 
    set_property -dict { PACKAGE_PIN R16   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(6)  }]; 
    set_property -dict { PACKAGE_PIN U17   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(7)  }]; 
    set_property -dict { PACKAGE_PIN V17   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(8)  }];
    set_property -dict { PACKAGE_PIN V18   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(9)  }]; 
    set_property -dict { PACKAGE_PIN T16   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(10) }]; 
    set_property -dict { PACKAGE_PIN R17   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(11) }];
    set_property -dict { PACKAGE_PIN P18   IOSTANDARD LVCMOS33 } [get_ports { gpio_io_o_0(12) }]; 

    Errors I get

    [Place 30-58] IO placement is infeasible. Number of unplaced terminals (13) is greater than number of available sites (0). The following are banks with available pins: IO Group: 0 with : SioStd: LVCMOS18 VCCO = 1.8 Termination: 0 TermDir: Out RangeId: 1 Drv: 12 has only 0 sites available on device, but needs 13 sites. Term: gpio_io_o_0[0] Term: gpio_io_o_0[1] Term: gpio_io_o_0[2] Term: gpio_io_o_0[3] Term: gpio_io_o_0[4] Term: gpio_io_o_0[5] Term: gpio_io_o_0[6] Term: gpio_io_o_0[7] Term: gpio_io_o_0[8] Term: gpio_io_o_0[9] Term: gpio_io_o_0[10] Term: gpio_io_o_0[11] Term: and gpio_io_o_0[12]

    What am I doing wrong ?

    Thanks

    Antonio
     


  11. Hi, Guys,

    I am using the AXI GPIO (2.0) IP in a ARTY-Z7-20 projetct.  

    The output of the GPIO goes to teh shield dp0 dp13 outputs. I would like to attach outputs from dp0 to dp12 only to that IP.

    I would like to leave dp13 to another IP in the project. How can I do it ? How can I split DP0-DP12 and link them to the AXI GPIO IP ?

    Thanks

    Antonio


  12. Hi, Jon

    Thank you for your answer.

    I already did the boot.bin file and it is working fine.  Is there any tutotial that has an example on how to write/read data to the microSD card ? Do I need to add an IP to the design ?

    Thanks

    Antonio


  13. Hi,  Guys

    I am configuring my ARTY-Z7-20 through the microSD card. I would like to add data to it in binary form and would like to retrieve that data in a later session. How should I do it ? Do I need to add the SD Card as an SD CARD IP in my project ? Are there any examples about that ?

    Thanks

    Antonio


  14. Hi, Guys,

     

    I had the same application runing on a ARTY-Z7-20 board. I would like to confirm that the output we get is only from 0V to 0.999V (It clips outside that range. I thought we would get readings from 0V up to 2.5V.

    If it is only up to 1V, why is there a integer portion of the reading and a decimal portion of the reading in the SDK software ?

    Thanks

    Antonio