Leaderboard


Popular Content

Showing content with the highest reputation since 09/17/14 in all areas

  1. 4 points
    cristian.ignat

    Add board to ISE

    Hi, You can add your own board following the steps: 1. Go to ..\Xilinx\14.7\ISE_DS\EDK\board\Xilinx\boards 2. Create a folder board 3. In your folder board create "data" folder 4. Create a .xbd file 5. Open this file and edit with the necessary parameters For example, I add a Nexys4 board. The path for the Digilent_Nexys4.xbd file, in my case is: C:\Xilinx\14.7\ISE_DS\EDK\board\Xilinx\boards\Digilent_Nexys4\data The file content is: ATTRIBUTE VENDOR = Digilent ATTRIBUTE NAME = Nexys4 ATTRIBUTE REVISION = B ATTRIBUTE SPEC_URL = www.digilentinc.com ATTRIBUTE CONTACT_INFO_URL = http://www.digilentinc.com/Support/Support.cfm ATTRIBUTE DESC = Digilent Nexys4 Evaluation Platform ATTRIBUTE LONG_DESC = '-' BEGIN FPGA ATTRIBUTE INSTANCE = fpga_0 ATTRIBUTE FAMILY = artix7 ATTRIBUTE DEVICE = xc7a100t ATTRIBUTE PACKAGE = csg324 ATTRIBUTE SPEED_GRADE = -1 ATTRIBUTE JTAG_POSITION = 1 END Please see the result: Best regards, Cristian
  2. 4 points
    attila

    Waveforms For Linux

    We are working on a new cross platform WaveForms software. The beta version of this, supporting Windows, OS X and Linux, will be published soon.
  3. 3 points
    An FPGA can be a useful "swiss army knife", but all the nice features aren't easily accessible. Enter "LabToy": A batteries-included collection of utilities, just double-click and go. As the name implies, this isn't meant to compete against "real" test equipment. The main selling point is like a pocket knife - this fits into a shirt pocket and the power tools don't. And speaking of "selling points", it's free to use. So what do we have here: - Digital data: Shows the input state of all pins - Analog data: Readings from the two ADCs, up to about 700 ksps sustained (XADC "simultaneous sampling" mode, phase-accurate between channels) - Streaming data logger: Both analog and digital data can be written to a .vcd file, to be shown in gtkwave. There is no limit to the capture length. - Analog signal generator: 8 fully independent channels, sine, square wave, the usual suspects. Well, the DACs won't win any audiophile awards, but they are usable. - "Programmable" digital LED mode: Configurable pulse width to suppress short glitches, or edge detect with a built-in pulse generator to highlight them. - Analog LED mode: Shows the input value of the ADC in real time Some screenshots: 1k sine / cosine from DAC jumpered to ADC (in gtkwave) The digital signal is the generator's sync output that can be recorded as a digital input. Realtime display of the inputs. With pocket knives in mind ("this button will unlock the large blade, allowing it to be manually returned to its folded position") I decided to keep the screen uncluttered and put descriptions into tooltips. The large displays are the average voltage readings from the ADC. The smaller ones show the digital inputs in groups of four. Generator controls (frequency, minimum voltage, maximum voltage, phase). The voltage scaling is a bit unusual (typically there is "AC magnitude" and "DC offset") but I chose this approach because it shows clearly the limitations of the 0..3.3V output range. Most people will probably leave all this at the default values for a full-scale signal. Data capture Example: The output in gtkwave after I touched a jumper cable to the digital inputs on the DIL connector. +++ DO NOT USE THE +5V OUTPUT P24 FOR THIS KIND OF TEST +++ (3.3 V is available on the PMOD connector, bottom row) The red "undefined" marks flag the first input in an 8-bit group. In this example, they aren't too meaningful, but they can alert me to the fact that no data events have been observed yet. LED control The two numbers give the number of consecutive 1 or 0 samples (at 125 MHz) before a signal change is propagated to the LED. E.g. put 125 million there and it'll take one second after changing the input state for the LED to light / go dark. Those can be used interactively to study an unknown signal. "Level": no further processing ("level" mode and 1 / 1 sample counts is equivalent to directly connecting the LED to the physical input) "Edge" mode generates a brief pulse on signal changes, the LED is dark otherwise. "Invert" flips the input right next to the pin (0 becomes 1, black becomes white and man gets himself killed on the next zebra crossing -DA). How to get it: The file is attached: labToy0v1_beta.exe The installer unpacks a single .exe. Happy hacking! Requirements: Windows 64 bit (!) .NET 4.5 FTDI libraries CMOD A7 35 T (not 15 T). Warnings: Direct access to digital IO pins is an inherently dangerous activity. "PROVIDED WITHOUT WARRANTY OF ANY KIND" means Just That. And beware of the +5V pin. PS: If you try it, kindly let me know whether it works, or what goes wrong.
  4. 3 points
    A few reasons are... a - The introduction of logic hazards can cause glitches : https://en.wikipedia.org/wiki/Hazard_(logic) b - Routing of clocks is very complex - It is hard to ensure that the same clock edge appears all over the FPGA at almost exactly the same time. Sometimes this is achieved with 'slight of hand' (e.g. using a on-chip PLL to advance phase of the clock, so that by the time it reaches the edge of the chip is in back phase with the original signal). Low-skew paths also exist, but are restricted to small areas of the FPGA, and the clock has to be connected to the correct pin to be placed and routed correctly. c - FPGAs and their tools are designed to behave predictably under the "synchronous digital design" paradigm (something like https://hps.hs-regensburg.de/scm39115/homepage/education/courses/red/2_SynchronousDigitalCircuitDesignRules.pdf). If you work outside the paradigm you will be fighting against the tools and their assumptions. d - There is almost nothing that you are unable to code in an FPGA friendly way, but there are infinitely many ways to write FPGA-hostile code. If you want your FPGA to place nice with you, you have to play nice with it. So you can either add an RC filter to debounce you switch, or you can sample it using a reliable clock.
  5. 3 points
    D@n

    Just for fun: Frequency Resolution challenge

    Hello everybody! Since I was sharing this image with others, I thought I'd share it here at Digilent as well. The attached image shows the frequency response of several FFT windows, including the well-known rectangle and Hanning windows. The blue window is one I've put together, but haven't shared the FPGA source code used to implement it. I challenge anyone to do better. Oh, and one other comment ... all but the Hanning window can be used in an invertible FFT process. Dan
  6. 3 points
    hamster

    Nexys3 Best Practice for Unused Pins

    Hi! By default the tools configure all unused I/O pins are configured with a weak pull-down on them (I'm away from my laptop at the moment so can't verify what I am saying, but I am a little bit sure that it is pull-down) So you can either: * change the "Generate Bitstream" properties to change this default behaviour (IIRC the other options are either pull up, pull down or floating). * Define the anode pins and force them to turn the display off * Ignore it, and consider it a feature. Mike
  7. 2 points
    Hi @Blake, I was struggling with the same problem. In Adam's project is mistake which result is an FMC-HDMI module is not recognizable by other devices. The reason for that is not sending EDID at all. The cause of this situation is wrong initialized EDID map. In Adams example EDID is initialized by: but the correct way is: the body of iic_write2 is from LK example: By the way, in LucasKandle example initialization is done in same way as in Adam's example so is the reason why it not worked in your case. I hope it will helps. If you want I will post my working code for a ZedBoard with FMC-HDMI when I clean it because at the moment is kind of messy.
  8. 2 points
    The warning you pasted is benign and simply means there are no ILAs present in your design. The real issue could be your clock. You should review the datasheet for the dvi2rgb.Table 1 in section 5 specifies RefClk is supposed to be 200Mhz. Also, your constraint should follow the recommendation in section 6.1 for a 720p design. Finally, @elodg gives some great troubleshooting information in this thread.
  9. 2 points
    Hi @akhilahmed, In the mentioned video tutorial, the leds are controlled using "xgpio.h" library but the application is standalone. If you want to use a linux based application you have to use linux drivers for controlling. In the current Petalinux build, which is used in SDSoC platform, UIO driver is the best approach. Steps: 1. Vivado project generation: - Extract .dsa archive from /path_to_sdsoc_platform/zybo_z7_20/hw/zybo_z7_20.dsa - Launch Vivado - In Tcl Console: cd /path_to_extracted_dsa/prj - In Tcl Console: source rebuild.tcl - In this point you should have the vivado project which is the hardware component of SDSoC platform. Open Block Design. Change to Address Editor Tab. Here you will find the address for axi_gpio_led IP: 0x4122_0000 2. Petalinux UIO driver: - Launch SDx - Import zybo-z7-20 SDSoC platform - Create a new SDx linux based project using a sample application (e.g. array_zero_copy) - Build the project - Copy the files from /Dubug/sd_card to SD card - Plug the SD card in Zybo Z7. Make sure that the JP5 is set in SD position. Turn on the baord - Use your favorite serial terminal to interact with the board (115200, 8 data bits, 2 stop bits, none parity) - cd to /sys/class/uio - if you run ls you will get something like: uio0 uio1 uio2 uio3 uio4 uio5 - Now you have to iterate through all these directories and to search for the above mentioned axi_gpio_led address: 0x4122_0000 - For example: cat uio0/maps/map0/addr will output: 0x41220000, which means that the axi_gpio_led can be accessed using linux uio driver through uio0 device. - Code: #include <stdio.h> #include <stdlib.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <stdint.h> #include <unistd.h> #include <fcntl.h> #define UIO_MEM_SIZE 65536 #define UIO_LED_PATH "/dev/uio0" void UioWrite32(uint8_t *uioMem, unsigned int offset, uint32_t data) { *((uint32_t*) (uioMem+offset)) = data; } uint32_t UioRead32(uint8_t *uioMem, unsigned int offset) { return *((uint32_t*) (uioMem+offset)); } void led_count_down(uint8_t *ledMem) { uint8_t count = 0xF; uint8_t index = 0; for (index = 0; index < 5; index++) { UioWrite32(ledMem, 0, count); count = count >> 1; sleep(1); } } int main() { // Set Leds as output int led_fd = open(UIO_LED_PATH, O_RDWR); uint8_t *ledMem = (uint8_t *) mmap( 0, UIO_MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, led_fd, (off_t)0); UioWrite32(ledMem, 4, 0x0); // Set all leds as output while(1) { // Start led count-down led_count_down(ledMem); } return 0; } - Build the project and copy the content of Debug/sd_card on SD sd_card - Power on the board and connect to it using a serial terminal - run the following commands: mount mmcblk0p1 /mnt cd /mnt ./project_name.elf - Result: A countdown should be displayed on leds.
  10. 2 points
    attila

    Electronics Explorer Troubleshooting

    In case your Electronics Explorer board is not detected by WaveForms application try to do the followings: 1. Check if it is properly supplied with 12V and the Red Power LED is on? The USB controller is powered by this supply, connecting only the USB cable is not suffice. 2. Check if the Yellow USB LED is on when the USB cable is connected? Otherwise, try to use another micro USB cable and computer plug. 3. Remove the board supply, wait a minute then connect it back. Do this, to make sure that all the internal circuits are reset. 4. Check the Windows Device Manager if any new device is listed after you supply the board or connect the USB? It should appear: Digilent USB Device or Unknown Device. 5. In case you see Digilent USB Device but it is not detected by WaveForms: restart the computer, reinstall the application including the Adept Runtime section. 6. In case you see Unknown Device, verify the Hardware IDs under Properties, Details tab. If this is USBVID_04B4&PID_8613... ask for USB EEPROM reprogramming application.
  11. 2 points
    JColvin

    Arty A7 flash chip

    Hi @D@n, I believe the new part that is used in the Arty A7 boards (and other A7 boards) is now a Spansion S25FL128SAGMF100; based on old schematics, I believe this was added in Rev D of the Arty A7 (dated August 2017), though I do not know when that particular Rev was then released (or if it even was released) to the public. I confirmed that the Arty S7 also uses this part and I wouldn't be surprised if most of our other Artix 7 based boards use it now as well. I've requested that the chip name and images are updated in any appropriate tutorials and requested that the pdf version of the reference manual (updated wiki) is updated as well. Thanks, JColvin
  12. 2 points
    attila

    Math on FFT traces

    Hi @lab!fyi In the Network Analyzer extended option lets you use Wavegen channels at up to 20MHz and with external up to 50MHz. In the Spectrum Analyzer you can select frequency range up to 10MHz but with auto option lets you set Stop frequency up to 50MHz. Selecting the dB unit will let you specify custom reference, for dBm I think it should be 0.316V
  13. 2 points
    @hamster I was able to run your AXI Slave interface. It works great! It is now very easy to exchange information between PS and PL, and it even supports execute-in-place (e.g. I can put ARM instructions to register file and run PS CPU directly from it). I have some questions about your AXI Slave design: 1) AXI_a*size has no effect on INCR type of burst transactions, but according to AXI protocol: the increment value depends on the size of the transfer. You set it only for WRAP type, is it correct? Thus, burst size is always 0 for INCR type? 2) Do you know how PS initiates INCR burst type? A kind of memset/memcpy need to be used for that or an incrementing pointer will also work? 3) Where WRAP type is necessary? How to use PS to work in WRAP mode? You may also update your wiki page with following: 0) Create provided VHDL files 1) Create a block-diagram and add PS IP core to it 2) Apply configuration provided by your board's pre-settings; this will set all necessary initialization settings for PS (e.g. clock frequencies, DDR bindings, etc.) 3) Press auto-configure (or how it's called) ==> this will connect PS IP to DDR and to fixed IO 4) Add "External ports" to the diagram (create new AXI_CLK and AXI external ports) and connect them to PS ports 5) Generate VHDL wrapping code for this block diagram 6) Put generated system under axi_test_top by renaming it to axi_test_wrapper (default name is design_#_wrapper in my Vivado version) 7) This will auto-connect block-diagram external ports with axi_test_top 8 ) Add constrains file and rename/uncomment external ports where necessary 9) Generate bitstream 10) File->Export->Hardware and create .hwf file which contains PS configuration 11) Open Xilinx SDK and create a new project: select .hwf file as Hardware BSP for this project 12) Now, Xilinx SDK will auto-generate few .c and .h files which contain necessary PS initialization ==> clocks, IRQs, DDR, etc. 13) Add hello_world.c application to the project @hamster Thank you very much. I've learned a bunch of new things thanks to your help!
  14. 2 points
    mohammadhgh

    Zybo z7-20 Zynq Presets

    Hi @Mahesh, As @jpeyron said in the post marked as accepted solution, the Zynq processing system will be configured with the board presets when you first add the Zynq processing system IP core to the block design and run the block automation task from the green message that appears! Just remember to keep the Apply Board Preset option checked as shown in he picture. So this means if you are using the pre-built block design from the example project, a possible solution can be to remove the existing Zynq processing system block and adding a new one!
  15. 2 points
    xc6lx45

    Cmod A7 oscillator question

    PS: Reading the above post: I suggest you DO use the IP wizard, not calculate it manually. Pain does not equal gain.
  16. 2 points
    xc6lx45

    Vivado slowness reality check

    For comparison: My labToy project on CMOD A7 35 builds in 3:40 min (excluding clock IP, measured on my wristwatch by resetting synthesis, then "generate bitstream"). It's not a large project - about 20 % of DSP used and slices touched - but not trivial either. A hello-world project compiles in maybe 1 min, give or take some. But my desktop was built for the job (water-cooled i7 4930 @ 4.5G, 32G quad-channel RAM, M2 SSD). Most of this doesn't help with a one-LED design, but there are a number of things that will slow down the run considerably: - Use correct timing constraints: For example, a LED driven from logic clocked at 200 MHz can be very difficult to route (but at the 12 MHz crystal frequency it shouldn't matter much). A simple set_false_path -to [get_ports LED] makes it "don't-care". - Throw in extra registers where appropriate, especially between blocks (which tend to be physically separate). Most of the time, it does not matter whether the signal arrives one or two clock cycles late, and some spare registers will simplify implementation. This is especially useful for register rebalancing. - For the extra registers, it may make sense to use a "don't touch" attribute. E.g. in Verilog: (* DONT_TOUCH = "TRUE" *)reg [5:0] wa [1:NWRDELAY]; (* DONT_TOUCH = "TRUE" *)reg [17:0] wd [1:NWRDELAY]; (* DONT_TOUCH = "TRUE" *)reg we [1:NWRDELAY]; When I have multiple, parallel instances of a timing-critical block, the input registers are logically equivalent, get optimized away, and then P&R takes ages because timing is so difficult. The "don't touch" attribute" keeps them separate, possibly using a couple of FFs more than strictly necessary. - Removal of redundant logic can take a long time. For example, when I simulate pipelined DSP like the "labToy" generators I simply carry all data all the way through the pipeline, even though most of it isn't needed. Optimization will eventually remove it, but the cost is runtime. The LabToy example includes 8 instances each with a 6-lane 14-cycle 18-bit wide pipeline, and it adds minutes to the synthesis time if I don't remove the unused ends of delay chains in the source code. - Read and understand every warning, and read the timing report. "The compiler is my friend" For example, with PLL blocks it is easy to create duplicate clocks with the same frequency (one from the constraints file, one from the IP block). Timing analysis tries to (and will eventually) sort out all possible interactions, but it takes a lot of time and can create meaningless but difficult routing constraints. - Fix "critical warnings" related to timing. Even if common sense tells the design will work e.g. classroom demo with buttons, Vivado will waste a lot of time trying the impossible.
  17. 2 points
    I solved my ethernet problem and the specific connections to make it work. I didn't have I2C enabled on the Zynq7 customisation. so I also enabled I2C over EMIO. I think this hampered it's ability to communicate with the address chip I changed in the Zynq 7 processor MIO configuration - the ENET0 MDIO device is now MDIO pins MIO 52-53.
  18. 2 points
    HansV

    AD2 THD

    https://www.youtube.com/watch?v=lQbg7hilS2U
  19. 2 points
    @Shuvo Sarkar What exactly needs to be done depends on what you mean by "region of interest" and "binary mask". I will assume that you are trying to replace some area of what is being displayed on the screen with a rectangular image. A good starting point would be to take the input stream and output it with modifications. The DemoScaleFrame function in video_demo.c does this. The resolution scaling being done by this function also may or may not be desirable for your project. The Bilinear interpolation function implemented on line 473 of the original source is the primary point of interest here. The three variables required to tell what is being written to in the destination frame are the index, i, which can be used to determine the color channel being written to, and the destination coordinate variables xcoDest and ycoDest. A good starting point to be able to see changes being made would be to add extra code to black out a rectangular area of the screen. This can be accomplished by wrapping the destFrame[iDest] statement within an if statement, that either writes a zero to destFrame[iDest] or runs the bilinear interpolation of the source frame, depending on the coordinates of the target pixel in the destination frame. How you store, access, and process the binary mask (overlay image?) is a large topic that I would need more details to provide information on. Let us know if you have more questions. -Arthur
  20. 2 points
    attila

    Analog Discovery 2 vs Raspberry Pi 3

    FTDI USBs like AD, AD2, DD are not working with RPI model B (1,2,3) data packets/bytes are randomly lost. The EExplorer with different USB controller is working fine on these. All devices are working with other embeddeds: Zed, Zybo, BeagleBone… According reports AD is working with the original RPI model A and probably Zero because it has similar chipset/USB. The problem seems to be with FTDI or RPI B USB, library or hardware. You can find such comments regarding RPI problems with other devices too. Unfortunately we couldn't remediate this problem.
  21. 2 points
    @Sam_a Should be fixed this time. Thanks for your patience, Arthur
  22. 2 points
    Notarobot

    Zynq PL-PS Interrupt issue

    @artvvb The issue seems to solved after I've added the statement: XScuGic_SetPriorityTriggerType(IntcInstancePtr, INTC_INTERRUPT_ID,0x00, 0x3); Now the applications responds and counts interrupt sisgnals coming fro PL. Regards, N
  23. 2 points
    @dcc, If you actually want to set/read memory, you'll need to learn how to interact with a bus. I like to use a B4 pipelined wishbone bus. I find it very simple and easy to use. For example, you can find a very simple block RAM device here that interacts with a wishbone bus. (It would be even simpler if I wasn't keeping my high speed and low speed code in the same file ...) Xilinx has committed themselves to the AXI bus--a bus that requires the management of five separate data paths just to get right. If you want access to DDR3 SDRAM, you'll need to use Xilinx's memory interface generator (MIG) to build an interface for you. (I tried without MIG, made lots of progress, but ... after two months of full time work on it hadn't finished the task. It's a shame. The memory access delay would've been about half of what Xilinx's delay is.) Xilinx's MIG generates a DDR3 interface to a memory using an AXI controller. You can see how I interact with that AXI controller in my own Arty design here. Within that file, take a look at the mig_axis component and then roll your eyes with me at the quantity of wires and communications paths you need to handle just to read or write from memory. Yuck. That's why, in the same file, you'll find a wishbone to axi bridge, one I call wbm2axisp, or wishbone master to AXI slave pipelined. As a result, I can interact with that core using wishbone signals, such as i_wb_cyc to indicate that I am accessing the bus (needs to be high throughout the transaction), i_wb_stb to request a memory interaction (only needs to be high for one clock while o_wb_stall is low per request), i_wb_addr (specifying the address of my request, must be valid any time i_wb_stb is high), i_wb_we (specifies if I am reading or writing), i_wb_data (data to write, must be valid anytime i_wb_stb and i_wb_we are high), o_wb_ack (true any time a memory access completes), o_wb_stall (true if the memory isn't ready to accept a transaction), and o_wb_data (the data result of any read transaction). The number of wishbone signals are truly ... much less than that giant AXI bus. (10 signals, of which 4 have multiple bits associated with them.) Looking at the AXI bus, to interact with it you will need 35 signals, of which 23 have multiple bits. Take your pick. (By the way, going from an 8-bit data width to the 128 bit data width used by the DDR3 SDRAM is not nearly as hard as it sounds, if that's something you would be struggling with.) If you are trying to read/write from memory to support both an ADC and a DAC, you'll need a couple of things. One of them is a FIFO. You can see an example of a FIFO supporting a UART here. DDR3 memory speed can be unpredictable, and it can drop out suddenly for a refresh cycle while you are trying to interact with it. Worse, that MIG interface takes upwards of 24 clocks to complete a transaction. (If you pipeline your requests, only the first will take 24 clocks, the rest can take one clock. See the wishbone B4 spec for a discussion of this.) However, with a FIFO you can weather some of these problems without dropping samples, and even get on and off the memory bus faster. Second, you'll need an arbiter--something that decides of the two transactions you'd like to make, which of them actually gets access to the bus. You can find my own wishbone arbiter here. If you are wondering just how to get a wishbone transaction working, I have examples ranging from simple to complex. For example, here is a simple prefetch example that just reads a single value from memory (i.e., the next instruction for a CPU). Here's another, similar example, which reads two values from memory at a time. (When working with that SDRAM, the first can take 24 cycles per read, the second can do two reads in 25 clock cycles.) And, while we are at it, here's an example which reads 2^N values at once--but since it's got a cache within it, it ... tends to be more complicated. Another example would be the code I've used for building my own DMA. Take your pick. How deep would you like to dive into this? I could go on and on for a while with more examples ... Is this the sort of thing you are looking for? Let me know, and I can offer more, explain any of the above, or ... you tell me. Yours, Dan
  24. 2 points
    The trick is your code does not need to infer a block memory generator. It will actually need to explicitly implement the block memory generator INTERFACE. This is because the block memory generator is already being instantiated in the block diagram. You will need to design a state machine in VHDL that properly implements the interface. For a description of the signals (en, we, addr, etc.) you should refer to the block memory generator Product Guide. You can find the guide by double clicking the block memory generator IP and selecting Documentation in the upper left corner. The end goal will be to create a custom IP core that contains this custom VHDL. Since you do not have an AXI interface on your core, this should be pretty easy. I believe you can just create a new project that targets the ZYBO and has its top level ports be the desired ports on the IP block. Then I think you can run the Create and Package IP wizard from the tools menu to convert the project to an IP core so it can be inserted into you block diagram (which will be in a different vivado project). I'd recommend simulating your project before you convert it to an IP core to help make sure it is functioning as expected. BTW, you can just expand the BRAM_PORTB interface on the block memory generator IP core and manually connect each of the signals to your IP core if you have difficulty making you custom IP implement the BRAM interface. See the picture below for an example of what your end goal will be:
  25. 2 points
    @silverwolfman, I don't have my S6 on my desk to tell you how much time it took me to load the flash, but I do know I didn't use iMPACT. You can find my work here. In particular, the flash loader is called zipload, and depends upon the using the Digilent Adept utilities to load an initial configuration (generated from this toplevel file) into the flash. Dan P.S. I'll be redoing my work again soon, to prove that the updated ZipCPU can still fit (and work) on the device. You can see some of my update works in the 8-bit branch of the s6soc project, but ... although it builds, it hasn't been tested yet so ... it's still a work in progress.
  26. 2 points
    @Hassan Iqbal, Can I try to answer? Your solution will have two parts. The first part will feed the camera image constantly into memory. When you get the vertical sync to start again at the top of the page, you just reset your write memory pointer. The second part of your solution will read the image out of memory on your other clock. This will read out with the synchronization parameters you are trying to achieve. This way, if you write faster than you read, you'll quietly and slowly drop a frame, and if you read faster than you write, you'll eventually get a full frame stuffed into your stream--but either way things will work. This approach will use a "nearest-neighbor" interpolator, and will handle over and underruns by frame dropping or stuffing respectively. The trick you will have is that you only have one interface to memory. For that reason, both video streams will need to buffer their work into a FIFO. When the writer's FIFO is roughly half full, then it will need to write to memory until it's FIFO is empty. Likewise, when the reader's FIFO is half full, it'll want to initiate a read until its FIFO is full. This way, if both the writer and the reader want to access memory at the same time, they'll both be able to wait until the other completes it's memory access request/requirement. I haven't checked on your memory timing requirements at all. That could make things difficult. If it makes things impossible, then drop color bits and you should be able to get back into the realm of possible again. As for how to handle the multiple clocks, you will have three clocks you will need to deal with and work from. Two of these are your pixel clocks. The third is your memory clock. You can synchronize from the pixel to the memory clock and back again using the single "FIFO is half-full" wire. Dan
  27. 2 points
    WereCatf

    Stretch Goals?

    I ain't got anything specific in mind. For now, I'm just throwing spaghetti at the fridge and seeing if any of it sticks!
  28. 2 points
    D@n

    XADC demo

    @Manas, Sam is trying to turn voltage = (12-bit-code)/4096 into microvolts = (1000)*(1000)*(12-bit-code)/4096, and he's trying to avoid division. Rearranging: 1000*1000/4096 = 500*500/1024 (just by dropping common factors of two from both numerator and denominator) Shifting right by ten is equivalent to dividing by 1024, and then he multiplies by 500*500. Looks like it works alright. I might be concerned personally about losing any precision in the divide by 1024 (i.e. shift right by 10), especially since it is being done before the multiply if I understand correctly--leaving you with only 2-bits of precision (did I read that right?). Looking at the above, you might simplify it further into a shift right by 6, followed by a multiply of 15625. To get here, all I did was cancel out any factors of two that were in both the numerator and denominator. Then --- rearrange your order of operations, so the multiply is done first. What makes this choice special is that 15625 can fit within an 18-bit multiplier. Hence you can do: A = 15625*(12-bit-voltage-code) inside a DSP multiplier, and hence inside one clock. The result of this multiply will be a 30-bit number. If you ignore the bottom six bits, the 24-bit number that remains will be the number of microvolts that you are looking for. Converting this to a decimal display might take some more work though. Dan
  29. 2 points
    Bianca

    Joseph

    Hello, R254 is a 0 ohm resistance. you can find it on bottom of the board. See picture attached. It is true though, that it has a tolerance of few miliOhms. They are not different from one board to another. Best regards, Bianca
  30. 2 points
    Hello saleksin, Sorry for the late response, one great source of information, demos and tutorials for the Zedboard in Vivado is at zedboard.org. I believe it requires you to register but there is no cost. Once registered follow this path : Home->Support->Reference Design / Tutorials->Zedboard. Also a good blog for information for the zedboard is at http://svenand.blogdrive.com/archive/160.html#.V2r2RvkrJhG. In the near future we will be posting a demo for the Zybo that uses the PmodOLED that with some little changes that will enable users to use onboard OLED on the Zedboard. Thank you, Jon
  31. 2 points
    Hello, I think the demo project for the Genesys2 would be a good place to start. You can find all the information about it here. Sergiu
  32. 2 points
    While I haven't used this memory generator before, it occurrs to me that the singular characteristic of DDR memory is that it clocks data on both rising and falling edge of the clock. I can't be certain, but I can imagine that 400MHz clock is exactly what you are looking for. Dan
  33. 2 points
    Sergiu

    Nexys 4 FPGA board

    Please try manually installing the cable drivers. You can find them in the Vivado installation folder. In my case, they are located here: C:\Xilinx\Vivado\2015.3\data\xicom\cable_drivers\nt64 You can find instructions on how to install them here. You could also run "install_digilent.exe" from the "digilent" folder also found at the location from above. Let me know if this helps.
  34. 2 points
    Hello, You can install the "Digilent WaveForms VIs" hardware support package which provides simple VIs to use the Analog Discovery 1&2 and EExplorer. This package is based on Virtual Bench VIs and does not provide all the features that WaveForms SDK has. https://decibel.ni.com/content/docs/DOC-44838 http://vipm.jki.net/#!/package/digilent_waveforms_vis You can also access all features of WaveForms SDK importing the dwf library, like the following project is done: http://www.instructables.com/id/Analog-Discovery-USB-Oscilloscope-LabVIEW/ The WaveForms installs the Application (GUI), Runtime (dwf library) and SDK (manual, examples). An SPI transmission using the DigitalOut (Pattern Generator) in Python looks like this: from ctypes import * import math import time import sys if sys.platform.startswith("win"): dwf = cdll.dwf elif sys.platform.startswith("darwin"): dwf = cdll.LoadLibrary("/Library/Frameworks/dwf.framework/dwf") else: dwf = cdll.LoadLibrary("libdwf.so") #print DWF version version = create_string_buffer(16) dwf.FDwfGetVersion(version) print "DWF Version: "+version.value #open device hdwf = c_int() print "Opening first device" dwf.FDwfDeviceOpen(c_int(-1), byref(hdwf)) if hdwf.value == 0: print "failed to open device" quit() hzSys = c_double() dwf.FDwfDigitalOutInternalClockInfo(hdwf, byref(hzSys)) # SPI parameters CPOL = 0 # or 1 CPHA = 0 # or 1 hzFreq = 1e6 cBits = 16 rgdData = (2*c_byte)(*[0x12,0x34]) # serialization time length dwf.FDwfDigitalOutRunSet(hdwf, c_double((cBits+0.5)/hzFreq)) # DIO 2 Select dwf.FDwfDigitalOutEnableSet(hdwf, c_int(2), c_int(1)) # output high while DigitalOut not running dwf.FDwfDigitalOutIdleSet(hdwf, c_int(2), c_int(2)) # 2=DwfDigitalOutIdleHigh # output constant low while running dwf.FDwfDigitalOutCounterInitSet(hdwf, c_int(2), c_int(0), c_int(0)) dwf.FDwfDigitalOutCounterSet(hdwf, c_int(2), c_int(0), c_int(0)) # DIO 1 Clock dwf.FDwfDigitalOutEnableSet(hdwf, c_int(1), c_int(1)) # set prescaler twice of SPI frequency dwf.FDwfDigitalOutDividerSet(hdwf, c_int(1), c_int(int(hzSys.value/hzFreq/2))) # 1 tick low, 1 tick high dwf.FDwfDigitalOutCounterSet(hdwf, c_int(1), c_int(1), c_int(1)) # start with low or high based on clock polarity dwf.FDwfDigitalOutCounterInitSet(hdwf, c_int(1), c_int(CPOL), c_int(1)) dwf.FDwfDigitalOutIdleSet(hdwf, c_int(1), c_int(1+CPOL)) # 1=DwfDigitalOutIdleLow 2=DwfDigitalOutIdleHigh # DIO 0 Data dwf.FDwfDigitalOutEnableSet(hdwf, c_int(0), 1) dwf.FDwfDigitalOutTypeSet(hdwf, c_int(0), c_int(1)) # 1=DwfDigitalOutTypeCustom # for high active clock, hold the first bit for 1.5 periods dwf.FDwfDigitalOutDividerInitSet(hdwf, c_int(0), c_int(int((1+0.5*CPHA)*hzSys.value/hzFreq))) # SPI frequency, bit frequency dwf.FDwfDigitalOutDividerSet(hdwf, c_int(0), c_int(int(hzSys.value/hzFreq))) # data sent out LSB first dwf.FDwfDigitalOutDataSet(hdwf, c_int(0), byref(rgdData), c_int(cBits)) dwf.FDwfDigitalOutConfigure(hdwf, c_int(1)) print "Generating SPI signal" time.sleep(1) dwf.FDwfDigitalOutReset(hdwf); dwf.FDwfDeviceCloseAll()
  35. 2 points
    LariSan

    ASEE 2015- Workshop Materials

    If you attended our ASEE 2015 workshop with Kathleen Meehan and wanted a digital copy of the workshop materials-- I've loaded them here. The material features Waveforms, a few analog components and the Analog Discovery. 5-_back_Digilent-2015-AnalogAccessories-infosheet-1.pdf 4-front_and_back_page_color_Digilent-2015-Discovery-infosheet-1.pdf 3-Design a night light lab.pdf 1-front and back front page- color.pdf 2-555 Timer Lab.pdf 5- front page color Digilent-2015-WaveForms-infosheet-1.pdf
  36. 2 points
    lijieming

    Help With A Zybo Video Design

    Dear Chris, 1. Like Run suggested, the error "IO Group: 0 with : SioStd: LVCMOS18 VCCO = 1.8 Termination: 0 TermDir: BiDi RangeId: 1 Drv: 12 has only 0 sites available on device, but needs 2 sites." such kind of problem is caused by one or more unconnected external ports on your block diagram. Please check your diagram first to make sure all unused external ports are deleted. (this problem will occur on both 2014.4 and 2015.1) 2. For the DDC part, the HDMI protocol described it clearly that this is a mechanism to let video transmitter and receiver to communicate which each other. By exchanging information, the transmitter could know the detail configuration(ability) of the receiver part (what resolution, frame rate, format of signal the receiver can process). This is a necessary part in HDMI transmission and can not be ignored or deleted. 3. Currently the problem you encountered is how to synthesis the Bi-Directional inner control ports into a signal Bi-Di external port. To solve this problem, first you should understand what is a bi-di port and its mechanism(I am sure you know it). Secondly, in Xilinx ISE, three bi-di control ports can be easily synthesized together by adding a constrain command in the .ucf file. In vivado the goal can't be achieved by only modify the .xdc. In my way, i directly modified the DVI2RGB ip core, the top_module i mentioned is the top module of the ip core (the dvi2rgb.vhd file). The core is written by VHDL, modify the following: a. In the port description change DDC ports to below -- Optional DDC port DDC_SDA : inout std_logic; DDC_SCL : in std_logic; b. add HPD and CEC port in the end of port def HDMI_HPD : out std_logic; HDMI_OUT_EN : out std_logic c. in the behavioral part add signal def and logic architecture Behavioral of dvi2rgb is ....... signal hpd : std_logic; ....... begin DDC_SCL_I <= DDC_SCL; DDC_SDA <= DDC_SDA_O when DDC_SDA_T = '0' else 'Z'; DDC_SDA_I <= DDC_SDA; HDMI_OUT_EN <= '0'; HDMI_HPD <= hpd; ....... d. in the TMDS_ClockingX call add port "hpd" TMDS_ClockingX: entity work.TMDS_Clocking generic map ( kClkRange => kClkRange) port map ( ......... hpd => hpd ); f. in the TMDS_ClockingX module(vhd file) add "hpd" def. this will active the HDMI transmittion only after the sink core has been locked entity TMDS_Clocking is Generic ( kClkRange : natural := 1); -- MULT_F = kClkRange*5 (choose >=120MHz=1, >=60MHz=2, >=40MHz=3, >=30MHz=4, >=25MHz=5 Port ( ......... hpd : out std_logic); end TMDS_Clocking; architecture Behavioral of TMDS_Clocking is .......... begin hpd <= aDlyLckd; ......... the above is all you need to make this core compatible with HDMI. after modification -> save -> repackage ip core 4. All you need in your project xdc file is really sample if modification has been done inside ip core. below is my xdc set_property PACKAGE_PIN H16 [get_ports HDMI_CLK_P] set_property PACKAGE_PIN H17 [get_ports HDMI_CLK_N] set_property PACKAGE_PIN D19 [get_ports {HDMI_D_P[0]}] set_property PACKAGE_PIN C20 [get_ports {HDMI_D_P[1]}] set_property PACKAGE_PIN B19 [get_ports {HDMI_D_P[2]}] set_property PACKAGE_PIN D20 [get_ports {HDMI_D_N[0]}] set_property PACKAGE_PIN B20 [get_ports {HDMI_D_N[1]}] set_property PACKAGE_PIN A20 [get_ports {HDMI_D_N[2]}] set_property IOSTANDARD TMDS_33 [get_ports HDMI_CLK_*] set_property IOSTANDARD TMDS_33 [get_ports HDMI_D*] set_property PACKAGE_PIN G17 [get_ports HDMI_SCL] set_property PACKAGE_PIN G18 [get_ports HDMI_SDA] set_property IOSTANDARD LVCMOS33 [get_ports HDMI_SCL] set_property IOSTANDARD LVCMOS33 [get_ports HDMI_SDA] set_property PACKAGE_PIN E18 [get_ports HDMI_HPD] set_property IOSTANDARD LVCMOS33 [get_ports HDMI_HPD] set_property PACKAGE_PIN F17 [get_ports HDMI_OUT_EN] set_property IOSTANDARD LVCMOS33 [get_ports HDMI_OUT_EN] create_clock -name sysclk -period 25 -waveform {0 12.5} [get_ports HDMI_CLK_P] this is all you need for your project. Jieming
  37. 2 points
    studogger

    Hi

    Hi, My name is Stuart and I have been programming with my Zedboard for about 8 months now. I am primarily interested in parallel computing and am currently scouring the Internet trying to figure out how to use my PMODs on my Zedboard utilizing Vivado. Nice to meet you all!
  38. 2 points
    gmv

    Nexys4-ddr Resource Center Updates?

    Hi, some news about Nexys4-DDR Resource Center updates? ‚ÄčI bought the board and I'm interested in sections: - Embedded Linux Materials - Advanced Microblaze Design with MIG, Ethernet, UART & GPIO - Constraint Files - Xilinx Memory Interface Generator (MIG) Project - XADC Demo
  39. 2 points
    Hmm, I tried just unplugging and replugging in my board from the power supply and now both versions of the Wire library seem to have no issue and keep the demo running as expected. So that's not really an "issue" that I can bring up to Keith... I'll let you know if happen to find anything in the future related to this. Thanks, JColvin
  40. 2 points
    I realised a Vivado ip axi controller for basys3 4 digits display. You can find ip and test project here https://www.dropbox.com/sh/62c4uoar3lf9gzn/AABWfCCFOgShxkID7U6OjXdha?dl=0 It's easy to expand for nexys4 8 digit display. Actually the controller manage the number of digit to use in hex or bcd mode with the limitation of overflow. Dp are not managed. It will be helpful if Digilent can develop some ip templates for Pmod modules .... just a suggestion
  41. 2 points
    Hi, I've hauled my PMOD I2S out of the cupboard, and got it going on my Basys3, under Vivado First, the I2S interface ---------------------------------------------------------------------------------- -- Engineer: Mike Field <hamster@snap.net.nz> -- -- Description: Generate I2S audio stream ---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; Library UNISIM; use UNISIM.vcomponents.all; entity i2s_output is Port ( clk : in STD_LOGIC; -- Interface to the source of the audio data_l : in STD_LOGIC_VECTOR (15 downto 0); data_r : in STD_LOGIC_VECTOR (15 downto 0); data_accepted : out STD_LOGIC; -- Interface out to the DAC i2s_sd : out STD_LOGIC; i2s_lrclk : out STD_LOGIC; i2s_sclk : out STD_LOGIC; i2s_mclk : out STD_LOGIC); end i2s_output; architecture Behavioral of i2s_output is signal step : unsigned(8 downto 0) := (others => '0'); signal shift_out : std_logic_vector(16 downto 0) := (others => '0'); signal hold_r : std_logic_vector(15 downto 0) := (others => '0'); begin -- Set the output signals i2s_lrclk <= std_logic(step(8)); i2s_sclk <= std_logic(step(3)); i2s_sd <= shift_out(shift_out'high); mclk_ODDR: ODDR generic map( DDR_CLK_EDGE => "OPPOSITE_EDGE", -- "OPPOSITE_EDGE" or "SAME_EDGE" INIT => '0', -- Initial value for Q port ('1' or '0') SRTYPE => "SYNC") -- Reset Type ("ASYNC" or "SYNC") port map ( Q => i2s_mclk, -- 1-bit DDR output C => clk, -- 1-bit clock input CE => '1', -- 1-bit clock enable input D1 => '1', -- 1-bit data input (positive edge) D2 => '0', -- 1-bit data input (negative edge) R => '0', -- 1-bit reset input S => '0' -- 1-bit set input ); process(clk) begin if rising_edge(clk) then -- Default to telling the source to wait data_accepted <= '0'; if step = "111111111" then -- start sending the left sample, and signal the source -- that we have started sending both channels shift_out(15 downto 0) <= data_l; hold_r <= data_r; data_accepted <= '1'; elsif step = "011111111" then -- switch to sending the right sample shift_out(15 downto 0) <= hold_r; elsif step(3 downto 0) = "1111" then -- Just send the next bit. shift_out <= shift_out(shift_out'high-1 downto 0) & '1'; end if; step <= step + 1; end if; end process; end Behavioral; Second, the top level source library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity i2s_test_top is Port ( clk100 : in STD_LOGIC; -- Interface out to the DAC JA : out std_logic_vector(3 downto 0)); end i2s_test_top; architecture Behavioral of i2s_test_top is component i2s_output is Port ( clk : in STD_LOGIC; -- Interface to the source of the audio data_l : in STD_LOGIC_VECTOR (15 downto 0); data_r : in STD_LOGIC_VECTOR (15 downto 0); data_accepted : out STD_LOGIC; -- Interface out to the DAC i2s_sd : out STD_LOGIC; i2s_lrclk : out STD_LOGIC; i2s_sclk : out STD_LOGIC; i2s_mclk : out STD_LOGIC); end component; signal clk : std_logic := '0'; signal toggle : std_logic := '0'; signal accepted : std_logic; signal data : STD_LOGIC_VECTOR (15 downto 0) := x"C000"; signal count : unsigned(7 downto 0) := (others => '0'); begin i_output: i2s_output Port map ( clk => clk, -- Interface to the source of the audio data_l => data, data_r => data, data_accepted => accepted, i2s_mclk => ja(0), i2s_lrclk => ja(1), i2s_sclk => ja(2), i2s_sd => ja(3) ); p_clk: process(clk) begin if rising_edge(clk) then if accepted = '1' then if count = 99 then count <= (others => '0'); data(15) <= not data(15); else count <= count + 1; end if; end if; end if; end process; p_clk100: process(clk100) begin if rising_edge(clk100) then if toggle = '1' then clk <= not clk; end if; toggle <= not toggle; end if; end process; end Behavioral; Third, the constraints: ## Clock signal set_property PACKAGE_PIN W5 [get_ports clk100] set_property IOSTANDARD LVCMOS33 [get_ports clk100] create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports clk100] ##Pmod Header JA #Sch name = JA1 set_property PACKAGE_PIN J1 [get_ports {JA[0]}] set_property IOSTANDARD LVCMOS33 [get_ports {JA[0]}] set_property PACKAGE_PIN L2 [get_ports {JA[1]}] set_property IOSTANDARD LVCMOS33 [get_ports {JA[1]}] set_property PACKAGE_PIN J2 [get_ports {JA[2]}] set_property IOSTANDARD LVCMOS33 [get_ports {JA[2]}] set_property PACKAGE_PIN G2 [get_ports {JA[3]}] set_property IOSTANDARD LVCMOS33 [get_ports {JA[3]}] As it is running at 25Mhz, and using a 512 clocks per frame the audio rate will be 48,828 samples per second. As the top level module drives it with a square wave taking 200 sample, it should be a buzz of 244.14Hz: It looks quite noise, but that is actually because of the filtering on the edges - they contain no frequencies over 24kHz or so and so they 'ring' a little:
  42. 2 points
    Greetings! This is a project that I've been working on for a little while now, and now... well, it's dressed up for Halloween! I've been playing around with the (utterly awesome) WS2812 LED strips for a while now, with an eventual goal of semi-permanent lighting for the classier portions of my already classy abode. Using a Max32, a Basic I/O Shield, and MPIDE, I've been playing with various techniques & routines in order to control the lights as well as I'd eventually like. The first challenge was to get my sketch working with HSB instead of RGB. As a guy who plays with colors all the time, the idea of defining a color in RGB seems needlessly complex, but that's how the hardware works. My first efforts at doing on-the-fly HSB to RGB conversion are here: http://blog.digilentinc.com/index.php/controlling-led-strips-with-chipkit/ Once that was in place, I could focus on making cool colors, waves, etc. At this point I have a number of routines that look quite nice, and the below video shows one of my favorite. Yes, he's wearing a hat. What if it rains while trick-or-treating? https://www.youtube.com/watch?v=u4XjqhxhSx4
  43. 1 point
    Yes, I used the weighted method for converting to gray scale. I did it using integer math, which makes it a bit more complicated, but basically I just multiply each color by (W*256), then divide the result by 256. This allows the avoidance of floating point arithmetic.
  44. 1 point
    I haven't used the JDK on zedboard or zybo, but I did run Android on zedboards and was able to get its GUI to display, which uses quite a bit of Java. Android really needs a GPU, which zynq does not have, so I do not recommend this path for a GUI. If JFRAMES works in Ubuntu 16.04, you might be able to run it on the ARM processor of a zybo, if you run Ubuntu on the zybo. In this case, you only need a small program to run on the zybo. Another option, if you have some skill with networking, is to run your UI on another machine and stream the data to it over ethernet from the zybo. If you know javascript, websockets is a good option for interaction between the GUI and a small amount of code on the zybo.
  45. 1 point
    The next WaveForms 2015 release will draw smooth waveforms. Thank you for the observation.
  46. 1 point
    logansam

    Q&A setup

    Sam and I have been discussing this, I think it would be worse to have multiple threads, but calling every reply an "answer" isn't really the right thing to do. We'll let everyone know when we have a solution.
  47. 1 point
    zygot

    PID controller on Nexys3

    This can be quite a complex topic, but I'm assuming that you want something useful but not too didactic. I suggest that you check out the excellent material provided here: http://brettbeauregard.com. You will find an answer that is both practical and easy to understand.
  48. 1 point
    Cristian.Fatu

    PCB Design Files Basys 3

    Unfortunately the PCB design files are not public. What you can find are the Basys3 schematics https://www.digilentinc.com/Data/Products/BASYS3/basys_3_sch_public.pdf.
  49. 1 point
    hamster

    Pmod Ad5

    Hi i1116345, From a quick read of the datasheet, it seems that you need to send a few register writes to switch ADC into continuous sample mode, and then you can just clock the data in every time DRDY is asserted. You can take either the high road (with lots of levels of abstractions in your design) or the often-muddy low road (where you do all the work on paper, and then just make a design that achieves the desired result). The high road most likely involves a soft CPU, with a SPI peripheral interface, and software that talks SPI that will configure the device and retrieve the samples. The low road involves a long shift register to send out the SPI signals needed to configure the eight registers in the device, and then a simple FSM that clocks in the samples when they are available, storing the values into a flip-flops connected to the LEDs. So to me the low road looks to be something like two or three 128-bit shift registers (as it has to program up to eight 8-bit registers), a counter to act as a clock divider, and a small FSM that clocks in the samples . I know which road I would take - but that is just me. Mike
  50. 1 point
    It's not on an Atlys, but here is how to make a DDR frame buffer on anther Spartan 6 board, using the on-chip Memory Controller: http://hamsterworks.co.nz/mediawiki/index.php?title=MCB_Frame_Buffer You will also want to have a good read of Spartan-6 FPGA Memory Controller User Guide (http://www.xilinx.com/support/documentation/user_guides/ug388.pdf) to start making sense of it all.