Antonio Fasano

  • Content Count

  • Joined

  • Last visited

  • Days Won


Antonio Fasano last won the day on September 10 2018

Antonio Fasano had the most liked content!

About Antonio Fasano

  • Rank
    Frequent Visitor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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, Jon, I did just that and it worked !!! Thanks Antonio
  4. 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
  5. 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
  6. Hi, Jon, I did not see any way to get in touch with sales through the website. Would you happen to know the contact info for any sales person that I can reach out to ? Thanks Antonio
  7. Hi, Guys, Is it possible for me to have a price break if I purchase, say, 200 ea or 300ea of the ARTY-Z7-20 board ? Thanks Antonio
  8. Hi, Guys, I am trying to write and read from the micr SD card on Arty-Z7-20. I took a look of one of the examples and one of the required libraries is "ff.h" I suppose it has the prototypes for the functions needed to operate the SD card on the Arty. My SDK cannot find that library. What should I do ? Thanks Antonio
  9. 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
  10. 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
  11. 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: This is the link to the modified project that is not working The zynq chip is XC72020 CLG400ABX1701 D5348119A Thank you for your support. Antonio
  12. 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
  13. 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
  14. Attached. Thanks CONSTRAINT.xdc X4000_wrapper.vhd