artvvb

Technical Forum Moderator
  • Content count

    88
  • Joined

  • Last visited

  • Days Won

    7

artvvb last won the day on March 7

artvvb had the most liked content!

1 Follower

About artvvb

  • Rank
    Advanced User

Profile Information

  • Gender
    Male
  • Location
    Pullman, WA
  1. For what it's worth, the ID is passed properly in this block design as well. The only thing I can think of outside of version differences is some weirdness with the reset block. Cheers
  2. @Notarobot Classic question, which versions/editions of Vivado and SDK are you using? I just threw together a test project in stock 2016.4, haven't written C code to do setup the interrupt controller, but I am picking up the interrupt id in xparameters. Screenshots and code attached. Relevant xparameters lines: /* Definitions for Fabric interrupts connected to ps7_scugic_0 */ #define XPAR_FABRIC_TEST_0_INTR_INTR 61 Likely irrelevant verilog module (added to block design with right click + add module) module test( input clk, output reg intr // the interrupt pin ); parameter COUNT_MAX = 99999999; reg [31:0] count; always@(posedge clk) if (count < COUNT_MAX) begin count <= count + 1; intr <= 0; end else begin count <= 0; intr <= 1; end endmodule screenshot of block design: Thanks, Arthur
  3. @Notarobot Your analysis sounds correct to me. I believe that 61 is the default interrupt address for the IRQ_F2P, rather than the 84 in your code. This shows up defined as XPAR_FABRIC_<device>_INTERRUPT_INTR in xparameters.h. For me the interrupt id definitions appear just above the XSCUGIC device defines. Edit: This can also be determined by re-customizing the Zynq IP and looking at the IRQ_F2P port under the Interrupts tab. The ID field shows "[91:84], [68:61]". Since least significant bit is last, the zeroth interrupt bit has id 61. Hope this helps, Arthur
  4. @s223523 Apologies I didn't explain more earlier. Here is some mostly functional VGA code for a personal project that I haven't had time to revisit recently (creating a "simple" text editor in HDL, it stopped moving forward when I started trying to write link lists in verilog), the code is fairly poorly commented, but it implements a ROM to look up pixels from a character table, ASCII and address within the pixel in, single bit color out. Note that the project itself is overly complicated and might not even be totally functional. There are a few design decisions to make here. First, how many colors do you want to use? You don't have to have each pixel in the ROM have the same depth as the VGA bus, if you have spare cycles in the VGA loop, you can select a full color from based on the reduced version stored in the pixel memory. In my implementation, I chose to only handle black and white, with some additional logic to invert the color at the cursor. As such each of my pixels in the character memory is only a single bit deep, though I did pack several pixels into one address. You can absolutely store multiple images in one memory, as seen in the character memory, but it will be a lot easier to compute addresses into that memory if the images have a size of 2^N addresses. Line 68 of the linked file shows how I calculate the position of a particular horizontal line of pixels for an 8x8 character, just by appending the ASCII value and horizontal position together. The actual size of your memory, exactly how you address it, and how you use it's data depends heavily on what exactly you are trying to do. Since I posted that project, I have been revising it some to take advantage of the Zybo, including using a dual port ram to store images, which the Zybo will fill up on startup, this gets into an entirely different level of complexity though, as it requires an AXI interface, or something else to communicate with the processor. As for creating data files (COE or otherwise, depending on your ROM implementation), you will need to write some more code. The ways I have personally had some success doing this is to write a C program or Python script to parse an image file and turn it into an ascii hex file. (The file format used by the readmem commands is not too dissimilar to the COE format). Python has some decent libraries available for reading from different image formats, and is fairly easy to pick up if you don't already know it. As for C, I know that the Gimp image editor has an option to save an image as a C header, which removes about half of the problem, from there its just down to writing your data file in the correct format. Hope this helps, Arthur
  5. For the block diagram, I notice that ui_addn_clk_0 from the MIG is disconnected? What are the frequencies of ui_clk, the ui_addn_clks, as well as clk_out1 and clk_out2 from the clk_wiz? Clicking on the pin name will give these frequencies. Your clocks all appear to be connected as I would expect. The following would be my starting point for a new pmod ip design, the only notable change is the addition of an axi_uartlite block for a little more debugging - the clk_out3 frequency is 50MHz. (There are potential issues that we are looking into with sourcing the ext_spi_clk from the MIG, we will let you know when that has been answered) I hope this image is readable enough... Thanks, Arthur
  6. @D@n Perhaps I need some more coffee, you are totally right, from the driver point of view, the OledRGB has a single spi transaction with a bitmap buffer per character write, so that behavior makes a lot more sense. If I am reading the driver code correctly, it looks like each character transaction requires sending a few bytes more than 128 bytes, so confirming the ext_spi_clk frequency going into the Pmod IP would be a very good idea. There is a call to usleep per Oled_DrawBitmap call, which is called once per character write, so the sleep headers are also still a possible problem. From what I can tell, these would be the two main plausible sources of per-character delay. Arthur
  7. @BeamPower Once you have attached an image to your post just like any other file, you can insert it into your post with the plus button as seen below. You can zip and attach your project as well. I'm not sure what would cause that slow of an update, and it would certainly be helpful to see the project. What is particularly strange is that it sounds like a full character is being updated once every ten-ish seconds? I'm more familiar with the PmodOLED, which is fairly similar, but I would expect a slow clock to write a vertical line of eight pixels at a time at least for that device. My best guess right now is that perhaps the sleep functions (MB_sleep, usleep, sleep) are acting strangely, Xilinx made some changes to which of those functions can be used in SDK 2016.4 for microblaze. I'd very much like to see your C files at least. Thanks, Arthur
  8. @marco_pavesi One of our engineers will be taking a look at the 2016.4 project as soon as he finds the time, I'm sorry I can't be more specific. All extra information is appreciated Thanks for your patience, Arthur
  9. @marco_pavesi The original project is still on Github as the Projects/user_demo directory of this repo. Thanks, Arthur
  10. @lekgolo167 We don't currently support 2017.1, but are you able to run Report->Report IP Status in the Tools dropdown? I suspect this is a Vivado version problem, so if you can't either bring in the correct xadc_wiz IP from that .xci file, or create an identical one from the IP Catalog, I'd suggest installing 2016.4. Thanks, Arthur
  11. @s223523 I've done a few (less complex) VGA projects before, I don't have any exact examples online at the moment to send you to, but this would be my suggested route: In Vivado, you can instantiate two of Xilinx's Block Memory Generator IP cores in your project and hdl code, set up as Single Port ROMs with a COE initialization files. You can then stream data out of these ROMs to look up specific pixels in your images, depending on where the screen pixel horizontal and vertical count is - the specific math will be nontrivial and depend on your game logic - and then use these pixel values to select specific colors to put out over the VGA connection. This all assumes that you have the COE files to plug into the BRAM, creating these files will likely require a script or program of some kind running on your PC to convert PNG images to the COE format. A simple example of the COE format showing a 4x4 checkerboard pattern with a 2 bit address and 4 bit data would be below: memory_initialization_radix=16; memory_initialization_vector 5,A, 5,A; You might try finding a PNG python library, or something else you would be more familiar with for doing this conversion. As for instantiating the Block Memory cores, you might be able to refer to how the charLib core is used in the Nexys Video XADC example project - created in verilog, but the fundamentals are similar enough in this case. To create your own IP from scratch, you would use the IP Catalog window in Vivado (located under the Project Manager tab) and search for "block memory generator". This will pop up a "Customize IP" window, in which you will likely want to change things to be a "Single Port ROM" with Port A width and depth of your choice, no primitives output register, "always enabled" port type, and to load an init file to be the COE that you would have previously generated. These settings changes from default will get you a Port A read latency of 1 clock cycle (giving you two clocks to compute the address, one to look up data, and one to compute color, if you are running the VGA controller at 100MHz and the VGA at 25) and only the addra, clka, and douta ports. You can click the plus on the BRAM_PORTA interface on the image at the left of the window to check all of the exact port names your instantiation will require. Hope this helps, Arthur
  12. @wanderso When you run block automation in Vivado to connect the Microblaze to memory (Step 4.2 of the Getting Started Guide), you select how much local memory the microblaze has access to, I'm not sure how to check or change this after the fact. If you have the settings displayed in that step, you can increase your stack and heap significantly, just be aware that the program has to fit in that 32K as well (if I recall correctly). You would likely need to up the sizes to 4K apiece (0x8000), depending on where your array is being stored. Alternatively, you could use the AXI BRAM Controller and Block Memory Generator IP cores to create some external memory, the interface should be fairly straightforward, and this is probably easier and safer, though the project may run a little slower. I'll attach some code and screenshots of how to quickly set this up. #include <stdio.h> #include "platform.h" #include "xil_printf.h" #include "xbram.h" #include "xparameters.h" int main() { XBram bram; XBram_Config *pcfg; u32 i; init_platform(); pcfg = XBram_LookupConfig(XPAR_AXI_BRAM_CTRL_0_DEVICE_ID); XBram_CfgInitialize(&bram, pcfg, pcfg->CtrlBaseAddress); while (1) { print("Any key to start test\n\r"); inbyte(); for (i=0; i<8000; i+=4) XBram_Out32(bram.Config.MemBaseAddress+i, i); for (i=0; i<8000; i+=4) if (i != XBram_In32(bram.Config.MemBaseAddress+i)) xil_printf("error: data mismatch at %x\n\r", i); print("Test Complete\n\r"); } cleanup_platform(); return 0; } Hope this helps, Arthur
  13. @wanderso Could you take a screenshot of the lscript.ld file in your SDK application project? You may be able to increase the stack or heap size to support your 2KB array. Thanks, Arthur
  14. @s224071 First, VHDL files should work the same regardless of the version of Vivado, usually version problems come from when you are using IP cores. If you write your own controller, there are several things to take note of: The Zybo master XDC file, found in the sidebar of this page under "design resources", will have a number of pins to control the VGA connector, they are found at the very bottom of the file. The timings for these pins can be found in this project's description. I highly recommend reading that entire page. In order to display different images on the screen, you will need to modify the "At Display Area" comparator, as well as the color selection mux. Hope this helps, Arthur
  15. @shashi My suspicion is that there is an issue in your code when you are constructing the matrices A and B to be sent. I'm not really familiar with HLS, but it looks like XAxiDma_SimpleTransfer needs the buffer parameter to be a single dimensional array? You may be able to see the function prototype and source for that by control-clicking on it's name in SDK. If the second parameter is a u32*, then what you are passing is a list of addresses to your data rather than your actual data. You may need to make your matrix A a nine long buffer, I'm not really sure. As for how to interpret that from the IP core side, I really don't know. Hope this helps, Arthur