Ana-Maria Balas

Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Ana-Maria Balas

  1. Hello @mukunda, Did you manage to find out the problem?
  2. Yes, I've already give him the link with some Reference projects which contains also pdf files with documentation for each project, and it explains very well the Uart component which is used with the PmodRS232 (in Interface Reference Component from the Reference projects). The info is there...
  3. No, I've looked and there isn't an IP for PMOD RS232. But there are some example projects which you can use to create one.
  4. Hello @ESJ, That IP is created by Digilent. You can modify it with the Vivado IP Packger, you can find the IP here There is also some documentation for the IP which you can read.
  5. Hello @SamuelCroteau, Did you checked the chapter for creating custom characters? you can use it to create the Tetris blocks. You can found the source code for the Unit 3 course at the bottom of the page Also you can find some info here: You also have some libraries here which I found them useful:
  6. Hello @stefan5578, The board has a Zynq SoC and can be programmed with applications created in SDK (or Vitis) based on C/ C++ languages. Also you can use it with Petalinux. You can make hardware projects in Vivado Design Suite as with any other FPGA board created by Digilent.
  7. Hello @Antonio Fasano, We currently don't have an IP for Pmod I2S2. You'll have to create one yourself based on the I2S protocol. This pdf file explains very well the I2S bus specification
  8. Hello @farzan, 1. The first critical messages doesn't affect your project. It means that the IP was tested with a project that was created with a different board than yours,but this doesn't have any impact on your project, because it is a generic IP that can be used with all Digilent boards. 2. Because you have errors, then the SDK project cannot be build and therefore you cannot program the FPGA. You have to solve the errors first. The error say that the project you created overflowed the maximum capacity of your allocated BRAM memory with 92408 bytes. This means that you didn't allocate enough internal BRAM memory for the Microblaze processor. You must go back to Vivado project, select the Address Editor tab, then increase the microblaze_0_local_memory for Data and for Instruction to maximum I think 1MB should work. Rerun the generation of bitstream and update the Linker Script (right click on the project name in SDK and Generate Linker Script )
  9. Yes, I think the memory test interfere with the fact that all the data and code section of the project runs from SRAM. It's good that you commented that part of code, if the project runs, then it means there is no problem with SRAM memory. Also if you want to see how the memory test behaves, just change in the linker script to use microblaze internal bram and you can uncomment that part of the test.
  10. Hello @PaulJX, I tried to reproduce the errors and I installed Vivado 2016.4 but when I try to generate the bit-\stream, no matter what project I create, the synthesis remains blocked in "queued" mode and I cannot go further with generating the bitstream. None of the solutions I found online fixed the problem, so I don't think you or me should proceed with Vivado 2016.4 version. I don't know why this is happening, I encountered bugs with this version of Vivado before and I don't use it at all. I recommend Vivado 2018.2 because I personally think is the most stable, free of bugs version, but it's only my opinion. I also saw that there is a release for Vivado 2018.2 for the OOB demo, I generated the bistream myself right know and I can say for sure, that you will not encounter errors. There is not difference between the two OOB projects, only the different versions of Vivado, the one for 2018.2 was upgraded from the 2016.4 version. I attach here the entire project which contains the SDK project, I set the linker script to use the SRAM memory, you only have to run the project on your Cmod because I don't have one to test it. However, if you want to stick with Vivado 2016.4: -As I see from your capture image, the interfaces for gpio 2 leds and rgb led are validated in the Board Flow so I cannot figure out the reason why Vivado doesn't find the constrains for those ports, because I verified the xml files of the Cmod A7-35 board, and the name signals are spelled correctly. That is why I tried myself to recreate the error, but failed as explained above. You could try the following solution: -You can disconnect the interfaces for 2 LEDs and RGB LED from Board flow (right click on them) -Load the constrain file of the board -Change the specific pin names with the correct names found in the top file wrapper, as you can see below ## LEDs set_property -dict { PACKAGE_PIN A17 IOSTANDARD LVCMOS33 } [get_ports { led_2bits_tri_io[0] }]; #IO_L12N_T1_MRCC_16 Sch=led[1] set_property -dict { PACKAGE_PIN C16 IOSTANDARD LVCMOS33 } [get_ports { led_2bits_tri_io[1] }]; #IO_L13P_T2_MRCC_16 Sch=led[2] ## RGB LED set_property -dict { PACKAGE_PIN B17 IOSTANDARD LVCMOS33 } [get_ports { rgb_led_tri_io[0] }]; #IO_L14N_T2_SRCC_16 Sch=led0_b set_property -dict { PACKAGE_PIN B16 IOSTANDARD LVCMOS33 } [get_ports { rgb_led_tri_io[1] }]; #IO_L13N_T2_MRCC_16 Sch=led0_g set_property -dict { PACKAGE_PIN C17 IOSTANDARD LVCMOS33 } [get_ports { rgb_led_tri_io[2] }]; #IO_L14P_T2_SRCC_16 Sch=led0_r
  11. The message error is clear, those signals rgb_led_tri_o[2:0], led_2bits_tri_o[1:0] are not constrained correctly in the xdc file. There are 2 ways to verify those types of errors: 1. Verify that the names of those signals exist at the desired pins and that are spelled correctly, as they are named in the top file of the project in the Cmod_A7.xdc constrain file. 2. The GPIO, memory, and others are directly constrained when adding and IP (AXI GPIO, AXI EMC and other) from Board flow because the signal names are specified in a file from VIVADO BOARDS ( that file is this ). However if you don't have the Vivado Boards installed, then Vivado cannot find that file and therefore cannot constrain those signals. This is where Board flow is: In your case the person who created this project, didn't use a constrain file, but used the Board flow to add IP's for gpio, memory, which uses the internal constrain file. You can see that the features that are used are marked with yellow. Did you installed Vivado Boards? This was specified in the Prerequisites of the tutorial which link I posted If not: -Close Vivado, go to the proj folder, run cleanup.cmd, this will erase the project you created. -Install the Digilent Vivado-Boards -Recreate the project using the create_project.tcl -Go to the Board tab and verify that the features checked, like the picture from above
  12. It's okay. You can get back with the response whenever you want. I'm here!
  13. To test the external 512 SRAM with a project that is working for sure, could you try the OOB Demo for Cmod A7-35 T please? Here are the release sources for Vivado 2016.4: Here is the tutorial: Download, extract it, and follow instructions found in the tutorial above. I wanted to add that the linker script is configured to use microblaze_0_local_memory, but you can change it to use axi_emc to test that project works from SRAM. If it works, then you can follow the "How To Store Your SDK Project in SPI Flash" with the bistream that is generated, and verify that Flash is also working accordingly.
  14. I'm sorry, I was wrong, I was thinking of SDRAM when I gave the indications from above. Yes, you are right, you cannot use MIG but only Axi Emc. But the tutorial "How To Store Your SDK Project in SPI Flash" is still the one which should work for your need. The Cmod A7 has 225 KB BRAM memory so I don't think the internal memory is your problem. I don't understand why isn't running in SDK if you updated the linkerscript and you make the connections right. I will try to look into this tomorrow and I'll get back to you.
  15. Hello @PaulJX, Did you followed the tutorial How To Store Your SDK Project in SPI Flash ? I don't see the the MIG IP for configuring the SRAM memory of your Cmod A7 in the block design. That is why it doesn't work. Please read the Prerequisites and follow the steps for adding QSPI Flash and MIG IP with the right connections.
  16. I've created a simple project for Arty S7 50 with MIG, Microblaze, QSPI and UART. Because of the situation from nowadays I don't have an Arty S7-50 board at home, to test the project. You will have to test it. You only have to follow the steps 3. Program FPGA with bootloader , 4. Flashing FPGA, 7. Program Flash with the Offset address 0x00C00000 and Spansion part number S25FL128S from To see what is printed on the Serial console use Baud rate: 9600, 8 bits, no parity
  17. I assume you followed the Getting Started with Microblaze tutorial step by step. Did you update the linker script? Right click on the project name -> Generate linker script
  18. Could you try address 0x00220000 ? Or a little bigger like try to increase it with 64 KB each time: 0x00230000, 0x240000... if it still doesn't work, but not too much. Because in the reference manual is says that almost 13.92 MB can remain free to store additional data.
  19. Which board do you have? In the tutorial it says the base address:
  20. Hello @kb5pgy, As it says at the begging of the tutorial, it assumes that you already have a Microblaze system built complete with Quad SPI, External Memory, and Uart cores, meaning you already know how to configure the MIG IP (which is used for DDR memory). I understand that you don't know how to add and configure the MIG IP. This tutorial explains how to create a project which contains Quad SPI IP, MIG IP (for external memory) and AXI UART IP. This is an example project which you can use it to learn how to configure the MIG and then you can follow the How To Store Your SDK Project in SPI Flash tutorial. Thank you for your input! We will try to change some things in order to clarify the misunderstandings. Please let us know if there is anything else that we can help you with! Best regards, Ana-Maria
  21. Okay so the first part of the demo is working. Now you have to set up your Ethernet connection with a static IP address. Follow the rest of the steps from Chapter 15 Testing the Server with Tera Term
  22. And with Vivado 2018.3, with SDK, you get the same output in the serial window?
  23. Vivado tells you pretty straight that while generating the bitstream, the signals lock_led and cntr_led could not be constrained. So the first thing you have to do is to see in the constrain file if you named the signals correctly. In your constrained file, I see that you constrained a signal corresponding to position [0] of a vector named lock_led and a signal corresponding to position [4] of a vector cntr_led. In your top level file I see that those signal names are not vectors but simple logic signals. Change the constrain file accordingly: set_property PACKAGE_PIN T22 [get_ports {lock_led }]; # "LD0" set_property PACKAGE_PIN V22 [get_ports {cntr_led }]; # "LD4"
  24. Hello @KiuY, A long time ago I created an IP for Pmod MIC3 with the intention to add it on GitHub IP repository, but I got stuck with something else and I didn't test it overall. I'll give you the IP. The steps you need to follow: 1. Download the repository somewhere to your PC 2. Download 3. Add the PmodMIC3_v1_0 folder to the vivado-library/ip/Pmods/ 4. In Vivado add the IP repository path: Tools->Settings ->IP->Repository 5. In your block design, go to boards tab, select a Pmod header JA, JB and add the PmodMIC3 IP. The steps are similar to this tutorial with the difference that you have to add this IP to the rest of the IPs, in the corresponding Pmods folder because this IP uses an interface which is defined in the vivado-library/if I remember I recorded a sinus wave sound with PmodMIC3, used Tera Term to log the printed values and then in Matlab or Excel I plotted the wave using the results. The DemoRun function from the main.c file (examples folder) looked something like this: void DemoRun() { xil_printf("Demo Run... "); u16 buff[1000]; for(int i=0; i<1000;i++) { /* u16 data = MIC3_Read(&device); */ buff[i] = MIC3_Read(&device); /* xil_printf("%04X\n\r",data); * xil_printf("%d\n\r",MIC3_Read(&device)); */ usleep(10); } for(int j=0; j<1000;j++) { xil_printf("\n%d\r",buff[j]); } } Please tell me how it works after you test it.
  25. Hello @newkid_old, Did you installed the board files for Arty A7-100T? Also did you followed the tutorial and created the block design accordingly?