artvvb

Technical Forum Moderator
  • Content count

    188
  • Joined

  • Last visited

  • Days Won

    9

artvvb last won the day on August 10

artvvb had the most liked content!

1 Follower

About artvvb

  • Rank
    Prolific Poster

Profile Information

  • Gender
    Male
  1. Keyboard interfacing in basys 3

    @Archana100@ It looks like the main addition you have made to the code is the Process module? I may just be missing it, but where is the count register being changed? Is it meant to stay constant 2'b00? -Arthur
  2. DPG1 Pmod

    Also, update on the DPG1 IP, it is now fully supported by the tutorial you linked.
  3. DPG1 Pmod

    @Sandokan The only code that is needed in SDK is to control the things connected over AXI. The way that I think about it is that since the C code is running on the ARM processor, which is contained within the Zynq IP in the block design, the only C code that gets written is the stuff that controls the things that the Zynq block is connected to. The above block diagram is intended as a generic example, in that the two Pmod GPIO cores can be replaced with other relevant IPs (AXI Quad SPI or AXI IIC, for example). Note that if an IIC pmod needs to be used, there is some extra work that might need to happen to configure the pins to use pull up registers, I am not sure what this would be off of the top of my head. For the Pair of DPG1s, the Pmod GPIO IP cores should be replaced with Pmod DPG1 IP cores, with the Pmod_out interface pins connected the same way. (Admittedly, manually connecting 32 different pins is a massive pain). Thanks, Arthur
  4. Size series resistors used on PS/2 PMOD?

    @dcooper The Pmod PS/2's schematic, which is also linked from the Pmod PS/2's Resource Center, looks like it has what you need. Thanks, Arthur
  5. DVI to RGB IP Core - problems with resolutions above 720p

    Could you provide your project or at least a screenshot of your block design? I suspect that the problem lies in how PixelClock is being generated, but can't really tell exactly how the problem is being caused without seeing the design. Are you using the AXI_DynClk IP core from vivado-library? If you haven't already, referring to the Zybo HDMI IN demo may help.
  6. Zybo: Access the LD_MIO LED from the FPGA

    @FarmerJo I am currently using Vivado 2016.4, but to my knowledge, this should work in 2017.2 as well (hopefully). In your block design, go to recustomize the Zynq block (double click on it). Go to Peripheral I/O Pins in the Page Navigator. Scroll to the bottom of the page or until you can see the GPIO MIO line in the table. If the check box next to it is checked and column 7 is highlighted, then the configuration is fine, and this will only require writing C code (the attached image is the correct configuration here). If not, check the box, hit OK, and re-generate the bitstream. I believe that the highlighted values are set by the Zybo board file, but could be wrong. In SDK, the MIO GPIO pins use the gpiops driver, rather than the standard gpio driver. The following code worked for me to blink the led. #include "xparameters.h" #include "xgpiops.h" #include "sleep.h" int main() { XGpioPs_Config ledcfg = {XPAR_PS7_GPIO_0_DEVICE_ID, XPAR_PS7_GPIO_0_BASEADDR}; XGpioPs led; XGpioPs_CfgInitialize(&led, &ledcfg, ledcfg.BaseAddr); // initialize the driver device XGpioPs_SetOutputEnablePin(&led, 7, 0b1); // set MIO7 as output XGpioPs_SetDirectionPin(&led, 7, 0b1); // set MIO7 tristate as output (idk if both are required) XGpioPs_IntrDisablePin(&led, 7); // disable interrupts on MIO7, (just in case) while (1) { XGpioPs_WritePin(&led, 7, 0b1); // set MIO7 high sleep(1); // wait a second XGpioPs_WritePin(&led, 7, 0b0); // set MIO7 low sleep(1); } } Hope this helps, Arthur
  7. DPG1 Pmod

    @Sandokan Unfortunately the DPG1 IP is not yet supported by that tutorial. However, it should be within the next week. We are currently working on making sure that each of Pmod IP cores in the vivado-library repository are fully working, and the DPG1 hasn't been checked yet (I'll push it up the priority list). In the overview section of the tutorial you linked, there is a drop-down labeled "Pmods Supported" that contains a table with the full list of the IP cores that we have validated in 2015.4. As for solving your errors more quickly, are SDK or Vivado giving you any error messages? There are a few different reasons this may not be working, but it may be a little more difficult to fix if it is just failing silently. Additionally, what board are you using? The SDK C code used in the example code changes a little, depending on whether you are using a Zynq board or not, so narrowing in on whether the issue may be Microblaze or Zynq related could be helpful. Apologies, Arthur
  8. XADC demo

    I suppose I should mention that the fix of spreading the operation out over multiple clock cycles that Sam mentioned back in December was applied to the XADC demo for the Nexys Video. (Though the dirty 'negedge dready' clocking still exists in that project).
  9. UART and XADC

    @cristian_zanetti A few ideas: You could wait to send a sample over UART until you have two samples available, stored in a simple FIFO, then send out a three-byte group, with four bits of each of the samples packed into the third byte. If you don't need full 12 bit resolution, you could just send the eight uppermost bytes of each sample. If UART bandwidth isn't a problem, you could send each sample as two bytes in sequence, with one of the bytes containing four dummy bits. To get a better idea of what implementation you might want, we would need a better idea of your needs. Do you want your application to run in real time? How high of a resolution do you need? Meaning both the size of the samples the application is receiving, and how frequently the application can receive them. Thanks, Arthur
  10. How to modify Zybo Master.xdc to use inbuilt clok?

    @Nilakshan The following XDC code may or may not work #Clock Signal set_property -dict {PACKAGE_PIN L16 IOSTANDARD LVCMOS33} [get_ports clk_50] create_clock -add -name sys_clk_pin -period 20.00 -waveform {0 10} [get_ports clk_50] You need to use the create_clock line to define the frequency of the clock, where the period and waveform parameters take values in nanoseconds. The more normal way to create a slower clock is to use Vivado's Clocking Wizard IP core to use the clocking hardware (MMCMs and PLLs) on the Zybo - I am unsure if Vivado interprets the period and waveform changes so as to use this hardware. Hope this helps, Arthur
  11. Welcome @Yannick! You can use either Microblaze or pure VHDL, depending on the needs of your project. If you want to do some heavier calculations involving the ADC data later, it will be easier to use Microblaze. Pure VHDL uses less onboard resources, but takes more work to do properly for complicated designs. For your first step, you have two options, use one of the provided Pmod IPs for a dual SPI/GPIO interface, and modify the C drivers for your design on Microblaze. I do not believe any of our provided designs support an equivalent of the CNV conversion pin on your ADC, hence, tying that to a bottom-row GPIO interface is likely the way to go (perhaps hacking something together from the Pmod ACL IP core). Or, you can write a custom VHDL SPI controller, with a small top-level controller sitting above it capturing data and handling your "connection established" LED. Which route you choose is up to you, but consider how complex your final design needs to be, Microblaze might not be worth it at this stage, but if you want to control your design through C later, you will want it. Hope this helps, Arthur
  12. basic AXI_timer cannot interrupt successfully

    @Cynthia The first thing I see here is the error "Path for project must only have one segment", this means that the directory your project is in is too far away from the root or C: directory for Vivado to handle. You may try moving it and trying again. Hope this helps, Arthur
  13. @rnelsonee It's a bit hard to tell how the GPIO is set up without seeing it's settings, or the input/output direction of the ports inside of the interface - if you click the plus next to GPIO/2 it will show the ports the interface is made up of. As for custom cores, I believe that most of what Vivado is doing is creating a wrapper that it can interpret for the existing HDL code. For connecting to the GPIO bus, you need to make sure that the bus widths and input/output type are the same, and connecting them by first expanding the GPIO interface (click the plus symbol on the IP in the design), then "drawing" a line from the gpio_io_[i/o] bus to your HDL bus of the same width. The input/output type of the buses to be connected need to match, which you can do by configuring the GPIO IP core. If you have a lot of different signals that need to be touched by the processor, you may want to pack them all into an inout bus in your HDL. The following example is intended to be used with a 16 bit wide, one channel GPIO core configured for neither all inputs nor all outputs. //verilog example module myhdl ( /* other signals, */ gpio_bus); // input/output other signals, likely includes clk inout [15:0] gpio_bus; wire [3:0] in1, in2; wire [3:0] out1, out2; assign gpio_bus[3:0] = out1; assign gpio_bus[7:4] = out2; assign in1 = gpio_bus[11:8]; assign in2 = gpio_bus[15:12]; //do stuff endmodule Whether or not you are using the Add Module + GPIO method, or otherwise, I'd recommend starting your C code as follows. I think this will use standard configuration, so you may not have to worry about the XGpio_Config. The biggest differences here are the use of XGpio_Initialize and _SetDataDirection. // C example (following the bus bit directions from the HDL example) #include "xparameters.h" //[...] XGpio myDevice; // I think _Initialize handles setting this object up XGpio_Initialize(&myDevice, XPAR_AXI_GPIO_0_DEVICE_ID); // or whatever your connected gpio base address is called in xparameters XGpio_SetDataDirection(&myDevice, 1, 0xff00); // pointer, channel number - starts at 1, in/out bits - out is 0 val = XGpio_DiscreteRead(&myDevice, 1); Hope this helps, Arthur
  14. @rnelsonee You have this mostly correct. If you are using Vivado 2016.2 or later, you will be able to use the "Add Module" selection from the right-click menu in the block design to add in any custom HDL code included in the project. I just checked, and there doesn't appear to be any initial bus type conflict with tying a module to an AXI GPIO controller like this. The GPIO method will be less efficient in terms of resource usage than creating an IP core to do the same thing, but if you want to get a project running quickly, might give it a shot. You will need to use AXI to communicate, and this is why you will need to use a GPIO controller or other packaged AXI IP core. You may want to read through these forum threads for more discussion of your questions, first, second. Hope this helps, Arthur
  15. Issues with dvi2rgbEDID files on Zybo

    @whoooo I've run into this issue with the dvi2rgb before myself while looking into the NexysVideo HDMI demo, but haven't gotten to looking for a workaround. We're working on updating many of our demos to 2016.4 and this one is on the list. There might be a slightly less clunky workaround that could be done by adding a pre-synthesis TCL script that re-includes the edid file/s each time Synthesis is run - adding the script through Synthesis Settings -> Synth Design -> tcl.pre - but I haven't tried this personally and don't know if it will work. -Arthur