Antonio Fasano

Members
  • Content Count

    50
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Antonio Fasano


  1. HI, Guys,

    I have a C# application sending/receiving TCP telegrams to/from the ARTY-Z7-20.  I am using the lwIP TCP server model, with some modifications to receive commands from the computer and execute some tasks.

    When I send a TCP stream of, say, A0h, Arty will start executing a task that will take 5 minutes to complete.

    My VB code keeps waiting for the TCP answer.

    My question is:  Suppose I need to interrupt the task before the 5 minutes runs out. 

    How do you suggest I should do it ?

    Thanks

    Antonio


  2. Hi, Guys,

     

    I have a project in Vivado 2018.3 on Arty-Z7-20. I have been archiving the project at several points along the development. I noticed that if we take one archived file and decompress it, we need to copy it to exactly the same folder name as the original project . When we don't do it,  the SDK project won't open correctly and does not find the developed C project for the project.

    I wonder if there is a way to get rid of that problem and be able to open that archived project in a folder with another name with correct SDK results.

    Thanks

    Antonio


  3. Hi, Guys,

     

    Sorry for this question.

    I am developing a project on Arty-Z7-20 on Vivado 2018.3

    AFter I generate Bistrstream and export hardware and Launch SDK, when I get to the point when I need to download my project to the ARTY board, I get two choices of Hardware platforms to choose from:

    MyProject_wrapper_hw_platform_1   or

    MyProject_wrapper_hw_platform_2

    My question is:  Where do those 02 different designs coma from ? I noiced that the first one is an old implementation, when the project was not as developed as it is now.

    I did not define 02 variants of VHDL implementation in Vivado. Why do 02 options appear in SDK ?

    Thanks

    Antonio


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


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


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


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


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


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


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


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

     


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


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


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


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


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