Popular Content

Showing content with the highest reputation since 06/11/19 in all areas

  1. 2 points

    FIR compiler 7.2 stopband

    ... and how about a simple impulse response test (feed a stream of zeroes with an occasional 1 and check that the filter coefficients appear at the output). Just wondering, isn't there a "ready / valid" interface also at the output if you expand the port with "+"?
  2. 2 points

    FIR compiler 7.2 stopband

    @Ahmed Alfadhel, Why not run a simulated sweep through the band and read out what the actual filter response is? Dan
  3. 2 points
    Hi @NikosFotias, I heard back from our design engineer about this; the recommend input ranges are 0V to 5V, but the absolute maximum ratings for the PWM inputs are -58V to 58V. Thank you, JColvin
  4. 1 point
    Thank you, JColvin! Last night I hooked it up to the Analog Discovery 2 and I read much better values than the "max bouncing" values in the datasheet of that small (6mm x 6mm) push button. It's actually so good that it's hard to start playing with capacitors to make it better. I'll try again later today with the oscilloscope in higher resolution (startup mode of the AD2). Stuk
  5. 1 point

    Cora Z7 - Booting - Terminal

    I figured out why it wasn't working...On Digilent github, it said to only copy _pre-built/linux/images/BOOT.BIN_ and _pre-built/linux/images/image.ub_ to the SD card. Instead, I copied all the files in the _pre-built/linux/images/ directory and the bitstream to the SD card. It's working now and I see the boot process in my UART terminal.
  6. 1 point

    Measure Clock on Arty

    Hi @PoojaN, Here is project I made in Vivado 2017.4 using the ODDR IP Core. I made two ports by right clicking on the block design. Both are type clock and one direction is input at 100 MHz and the other direction is an output. I connected the appropriate pins from the ODDR to the ports. I then created a wrapper. With the wrapper information I added a xdc using using the pin names in the wrapper. I then generated a bitstream. Next I opened the Hardware Manager and configured the Arty A7 with the bitstream. I then probed the pin 1 on JA (the pin I used for this project) with the Analog Discovery 2. It is showing a 400 KHz signal. I have included screen shots of the process. best regards, Jon
  7. 1 point
    Hi @dmishins, Welcome to the Digilent Forums! Please attach a screen shot of your Block design. Did you connect the 200 MHz clock to the MIG as instructed in section 10? What did you set the local memory and cache when running clock automation for Microblaze? best regards, Jon
  8. 1 point

    BASYS3 and Axoloti

    Thanks @OvidiuD, I'll take one step after another and the forums are quite a good source of knowledge. So far, I plan to start with very basic schemes in order to understand how Vivado works. Then I will work on communicating with the Axoloti through SPI. Best regards
  9. 1 point

    pmod wifi

    Hi @harika, The board connects to the router through the Pmod WIFI. That is why you need the login and password for the router added in the HTTPServerConfig.h. The mode jumper would be set to SD if you were booting your project from the SD card reader. In this case the project is just using the SD card reader and not booting from the SD card reader. You should have the Mode Jumper set to JTAG. best regards, Jon
  10. 1 point

    FIR compiler 7.2 stopband

    true but it's a five-line job e.g. in Verilog reg[15:0] counter = 0; reg [15:0] impulse = 0; always @(posedge clk) begin counter <= counter + 1; impulse <= (counter == 0) ? 16'h7FFF : 0; end plus the protocol interface (e.g. trigger a new valid sample if counter[7:0] == 0)
  11. 1 point

    FIR compiler 7.2 stopband

    @Ahmed Alfadhel, I blogged about how to do this for some of my own filters when using Verilator. You can read that post here if it helps, Dan
  12. 1 point

    BASYS3 and Axoloti

    Hello, @SmashedTransistors! I'm very glad you're looking forward to your project and I have to admit it actually seems very interesting! Don't hesitate to ask questions on our forum whenever you have a question, I'm sure someone will always do their best to help you and eventually succeed by working with you. Best regards, Ovidiu
  13. 1 point
    Hi @m72 The preview will represent such corner cases correctly in the next software release. Thank you for the observation.
  14. 1 point

    use the uart port in nexys 4ddr board

    Hi @shahad, I split this thread here so we are not posting on a completed thread. Please attach screen shots of your block design and the top, xdc file. Here is a VHDL Nexys 4 DDR project that uses the USB UART bridge. best regards, Jon
  15. 1 point

    Noisy Output from FIR Compiler

    @Ahmed Alfadhel, You have a couple of options available to you: It's not clear, from your pictures above, whether or not the -40dB stop band was achieved. Some amount of noise is to be expected due to truncation errors, etc. Without seeing an estimated PSD, I can't tell. It may be that it's doing exactly what you required of it. -40dB is only so good. With more taps, you should be able to go deeper. How deep depends upon your requirements. How good do you want the signal to look? You may also need to provide more bits to both your signal and coefficient values in order to do better. You did prescale your coefficients so that, when rounded to integers, the taps were useful, right? Also, be aware, the filter will be specified for full scale. You'll want to measure it against a full scale input. Anything less will introduce additional truncation error. This is one of those reasons why the dynamic range (i.e. number of bits) of the input and output signals are so important. Enjoy! Dan
  16. 1 point

    Updated ZYBO Base System Design?

    Hi @zwilcox, We weren't readily able to update the Zybo Base System Design to a newer version of Vivado. We do have an unofficial version of a Zybo Base Linux Design for our Petalinux Projects here as well as a Zybo Petalinux BSP Project for Vivado 2017.4 here. Thanks, JColvin
  17. 1 point
    Hi @jpeyron @xc6lx45 Thankyou for the quick reply! Changing the clock frequency setting worked!! Thanks a lot!
  18. 1 point

    Updated ZYBO Base System Design?

    Hi @zwilcox, Unfortunately, we do not have an updated Zybo Base System Design. We are looking into updating this, though since it was originally created in Vivado 2013.4, I do not know how successful this will be. Thanks, JColvin
  19. 1 point

    LabVIEW and IIO data sources

    Thanks for pointers.
  20. 1 point
    Hi everyone, The good folks here at Digilent sent my a PM containing instructions on how to re-flash the JTAG IC. It worked and solved my issue. Thanks again, David.
  21. 1 point
  22. 1 point
    I did some research on Xilinx.com and found this answer record: https://forums.xilinx.com/t5/Embedded-Development-Tools/XSDB-Server-ERROR-Hsi-55-1545-Problem-running-tcl-command/td-p/834915 I had two floating inputs on my concatenation block and once I connected these project creation proceeded correctly.
  23. 1 point

    LabVIEW and IIO data sources

    Hi @Musko, You would receive better support for this question by posting on the National Instruments forum, https://forums.ni.com/t5/Discussion-Forums/ct-p/discussion-forums?profile.language=en; the staff here on the Digilent forum are really only familiar with the LINX add-on for LabVIEW and the LabVIEW 2014 Home Edition. I'm sorry I could not be of more help. Thank you, JColvin
  24. 1 point
    Finally working! Brief description: On right monitor is ssh session from my devel PC to Zyboz7-20 where I start Qt applications (framebuffer and sysinfo on attached picture). Front monitor is connected to ZyboZ7-20 HDMI output port. Monitor resolution is SXGA (1280x1024@60fps). FPGA: - Build with Vivado 2016.4 - Data path for HDMI output: /dev/fb0 DDR image buffer --> Zynq AXI HP port --> AXI Protocol Converter IP (AXI3 to AXI4) --> VDMA IP (mm2s only) --> AXI4 Stream to Video IP --> Digilent RGB to DVI IP --> HDMI connector Video control signals are from Video Timing Controller IP (1280x1024p, Pixel clock is 108MHz). On SD card: - Boot image containing: FSBL, U-boot (Xilinx git tag xilinx-v2017.3), LX 4.6 kernel (configured and build from Xilinx git tag xilinx-v2016.4) and Buildroot-2017.08.1 - Modified Simple FrameBuffer driver. - Xilinx DMA driver. - My custom driver to control FPGA modules (VTC, Xilinx Performance monitor and some others I have in design). - Cross compiled Qt-4.8.6 examples (analogclock, framebuffer) and Qwt-6.1.3 examples (sysinfo, cpuplot). TODOs: - Simple FrameBuffer driver does not starts Xilinx DMA driver transfers, so I have to configure VDMA IP registers manually. But this is good enough for my first run and proof of concept. I will switch to and continue with DRM device driver. - Inputs (mouse and keyboard) to control Qt application.
  25. 1 point
    Hi, For sw part I use Xilinx DMA driver (interface to VDMA IP core) and modified ADI AXI HDMI DRM driver for exposing frame buffer device to GUI sw (e.g. Qt). You can see driver bindings in above attached zyboz7-20.devicetree-1.zip (pl.dtsi). All video memory transfers to FPGA are managed by this two drivers.
  26. 1 point
    Hi @Abdul Qayyum, I am not directly seeing anything wrong with your FSM. Here is a UART RX TX verilog module and here that should be useful for your project. best regards, Jon
  27. 1 point
    Hi, reading between the lines of your post, you're just "stepping up" one level in FPGA design. I don't do long answers but here's my pick on the "important stuff" - Before, take one step back from the timing report and fix asynchronous inputs and outputs (e.g. LEDs and switches). Throw in a bunch of extra registers, or even "false-path" them. The problem (assuming this "beginner mistake") is that the design tries to sample them at the high clock rate. Which creates a near-impossible problem. Don't move further before this is understood, fixed and verified. - speaking of "verified": Read the detailed timing analysis and understand it. It'll take a few working hours to make sense of it but this is where a large part of "serious" design work happens. - Once the obvious problems are fixed, I need to understand what is the so-called "critical path" in the design and improve it. For a feedforward-style design (no feedback loops) this can be systematically done by inserting delay registers. The output is generated e.g. one clock cycle later but the design is able to run at a higher clock so overall performance improves. - Don't worry about floorplanning yet (if ever) - this comes in when the "automatic" intelligence of the tools fails. But, they are very good. - Do not optimize on a P&R result that fails timing catastrophically (as in your example - there are almost 2000 paths that fail). It can lead into a "rabbit's hole" where you optimize non-critical paths (which is usually a bad idea for long-term maintenance) - You may adjust your coding style based on the observations, e.g. throw in extra registers where they will "probably" make sense (even if those paths don't show up in the timing analysis, the extra registers allow the tools to essentially disregard them in optimization to focus on what is important) - There are a few tricks like forcing redundant registers to remain separate. Example, I have a dozen identical blocks that run on a common, fast 32-bit system clock and are critical to timing. Step 1, I sample the clock into a 32-bit register at each block's input to relax timing, and step 2) I declare these register as DONT_TOUCH because the tools would otherwise notice they are logically equivalent and try to use one shared instance. This as an example. - For BRAMs and DSP blocks, check the documentation where extra registers are needed (that get absorbed into the BRAM or DSP using a dedicated hardware register). This is the only way to reach the device's specified memory or DSP performance. - Read the warnings. Many relate to timing, e.g. when the design forces a BRAM or DSP to bypass a hardware register. - Finally, 260 MHz on Artix is already much harder than 130 MHz (very generally speaking). Usually feasible but you need to pay attention to what you're doing and design for it (e.g. a Microblaze with the wrong settings will most likely not make it through timing). - You might also have a look at the options ("strategy") but don't expect any miracles on a bad design. Ooops, this almost qualifies as "long" answer ...
  28. 1 point
    Hi @srce, I have attached the bin file for the Genesys 2 OOB Demo. thank you, Jon genesys_2_demo.bin
  29. 1 point

    Beginner DSP Projects

    @ho0pla, You should thank @zygot for such sensible advice: build it in Matlab or Octave, get it working, then port to hardware. Let me add another step in the middle, though, that I'm sure @zygot would agree with: Octave, then simulation, then hardware. After that, the sky's the limit! Well, you might want to study a particular application of interest as well. DSP is such a varied field, and so many things from so many fields are called DSP that ... well, it's hard for me to pontificate from here. Still, if you are interested in some examples, feel free to read some of ZipCPU's DSP articles on line. (The ZipCPU is the name of a CPU/processor I've built, and now blog about under the name ZipCPU.) They tend to hit on many topics surrounding DSP theory and implementation. Indeed, I recently posted a rather cool simulation demo of a spectrogram to github. There's a nice screenshot avaialble there too in order to give you an idea of how far you might get with simulation. Perhaps these ideas might stir up in your mind a project you'd like to try? Dan
  30. 1 point

    Beginner DSP Projects

    Well, if you want my opinion, DSP on FPGA is a fairly specialized niche application. It's a long walk to come up with a project that really fits into that niche, justifying an FPGA (rather pair a $0.50 FPGA for programmable IO with one or more high-end DSPs for the number crunching if someone claims "we need an FPGA"). For studying, it can be "interesting" in a sense that you get to know quite a few dragons on a first-name basis. But then, is it productive to spend weeks on fixed point math when everybody else uses floats on a DSP / CPU when "time-to-market" is #1 priority. Maybe not. DSP is more fun in Matlab (Octave). And there is no point in FPGA for performance unless you have exhausted the options at algorithm level (again, exceptions e.g. well-defined brute-force filtering problems) A lot of the online material is "sponsored" by companies that sell FPGA silicon by the square meter (Yessir. We have Floats!). But this is largely for the desperate and ill-informed (of course, there are viable use cases - say high volume basestations or automotive with need for EOL in a decade or two. As said, a niche application). When you take the direct route, you'll run into a question like, "how on earth could I implement an audio mixing console when the FPGA has only 96 multipliers". Challenge me or anybody who has read some books and you'll find it can be done on a single multiplier (say, 100 MHz at 96 kHz is 86 multiplications per sample for 12 channels. It's just an example. In reality I'd use a few with "maintainability" of the code my major concern). The point is, the skill ceiling is fairly high but so is the design effort. It only makes sense if I plan to sell at least a hundred gazillon devices. On the other hand, if you separate DSP and FPGA, you'll find that a lot of the Matlab (Octave) magic maps 1:1 to real life on any modern CPU platform by importing e.g. the "Eigen" library into my C code.
  31. 1 point

    Implementation SPI basys3

    @sanrod, So, to handle the DRC violation, stick these two lines into your XDC file: set_property CFGBVS VCCO [current_design] set_property CONFIG_VOLTAGE 3.3 [current_design] At least ... those are the lines that I placed into my own Basys3 XDC file. As for your logic, ... I would *highly* recommend that you do not transition your logic on either the SCK or the CS pins. Use a system wide clock instead. Transitioning on SCK and CS is going to ... set you up for problems when you wish to do anything else with your chip. (That's part of what Vivado is complaining about in those errors--these clocks (SCK and CS) have no timing associated with them--but if you stop using them as clocks and just use them as logic, the errors will go away.) To synchronize the external pins to your system wide clock, clock all of your inputs into flip flops twice before using them. Otherwise, you'll struggle with unpredictable things happening within your design. (See metastability ...) After clocking your inputs twice, look for a SCK line that is high with the previous SCK low, and for CS to be low on both clocks. This logic test, at the speed of your board clock (100MHz) should be sufficient to detect a rising clock edge. On the 8th rising clock edge, a byte has been given to you. Send that byte to the rest of your design, together with a logic "strobe" (true for only one clock) telling the rest of your logic that you have received such a byte. (You might wish to pass another line indicating if this was the first byte received since CS went low.) The approach outlined above, when applied with a 100MHz clock, should still have no problems dealing with SPI clocks 25MHz or above--even though all of your logic is running at 100MHz. You can see a discussion of this, along with other common Diligilent forum requests, on the ZipCPU blog. Dan