Leaderboard


Popular Content

Showing content with the highest reputation since 01/15/18 in all areas

  1. 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.
  2. 2 points
    Hi @attila Thank you again for all the support you've provided me for the past weeks. I am now capable of receiving more than 409 characters using the Wrapper I created base from your example. It uses the Record acquisition mode and I set the buffer size to 3 million for now. I'll increase it when the need arises. I used 1 UART controller and branched out its Tx pin to 2 DIO pins of the AD2 (DIO #0 & 1). I transmitted 500 characters: (If Record mode is not the acquisition mode, the received result will be blank) For DIO # 0, it received: with a length of: For DIO #1, it received: with a length of: I could not have done it without your guidance, thank you again and more power to you and Digilent Best regards, Lesiastas
  3. 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.
  4. 2 points
    kwilber

    Pmod DA3 clocking

    It seems to me the AXI Quad SPI block is sending address + data. Looking at the .xci file again, I see C_SPI_MEM_ADDR_BITS set to 24 bits. So 24 bits of address and 16 bits of data would yield 40 bits.
  5. 2 points
    Hi @neocsc, Here is a verified Nexys Video HDMI project updated from Vivado 2016.4 to Vivado 2017.4. You should be able to find the updated project in the proj folder . Here is a GitHub project done in HDL using the clocking wizard, DVI2RGB and RGB2DVI IP Cores for another FPGA. Here is a unverified Nexys Video Vivado 2017.4 HDMI pass through project made from the linked Github project. In the next few days I should have the bandwidth to verify this project. thank you, Jon
  6. 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.
  7. 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.
  8. 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
  9. 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
  10. 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!
  11. 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!
  12. 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.
  13. 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.
  14. 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.
  15. 1 point
    Hi @Lesiastas You should use higher sample rate to capture raw data than the UART rate. Otherwise due to clock jitter and signal slew rate the capture could be wrong. Imagine on sample could be captured exactly on bit start and next bit on the end of the same bit, instead of next bit start... Anyway, here I have modified the decodeUart to work with sample rate = uart rate, see the lines marked with ' ' ' ' Module Module1 Function decodeUart(ByRef rgData() As UShort, ByVal cSamplePerBit As Integer, ByVal pin As Integer) As List(Of Byte) Dim pData As Boolean Dim fData As Boolean = False Dim cSamples = rgData.Length Dim rgUart As New List(Of Byte) For i As Integer = 0 To cSamples - 1 Dim s = rgData(i) pData = fData fData = 1 And (s >> pin) If pData <> 0 And fData = 0 Then Dim bValue As Integer = 0 For b = 0 To 7 Dim ii = Math.Round(i + (1.499 + b) * cSamplePerBit) ''''' If ii >= cSamples Then Exit For End If s = rgData(ii) fData = 1 And (s >> pin) If fData Then bValue += (1 << b) End If Next rgUart.Add(bValue) i += cSamplePerBit * 9.499 - 1 ''''' 1 start + 8 bits + 0.5 stop -1 because For will increment End If Next Return rgUart End Function Sub Main() Dim hdwf As Long If FDwfDeviceOpen(-1, hdwf) = False Then Dim szError As String FDwfGetLastErrorMsg(szError) System.Console.WriteLine("Device open failed" & vbCrLf & szError, vbExclamation + vbOKOnly) End End If Const hzUart = 9600 Const hzRate = hzUart * 3 ''''' Const cSamples = 1000 Dim hzDI As Double FDwfDigitalInInternalClockInfo(hdwf, hzDI) FDwfDigitalInTriggerSourceSet(hdwf, trigsrcDetectorDigitalIn) FDwfDigitalInTriggerSet(hdwf, 0, 0, 0, &HFFFF) 'any falling edge 'FDwfDigitalInTriggerAutoTimeoutSet(hdwf, 10.0) FDwfDigitalInDividerSet(hdwf, hzDI / hzRate) FDwfDigitalInSampleFormatSet(hdwf, 16) FDwfDigitalInBufferSizeSet(hdwf, cSamples) FDwfDigitalInTriggerPositionSet(hdwf, cSamples - 10) FDwfDigitalInConfigure(hdwf, 1, 1) Dim sts As Byte While True If FDwfDigitalInStatus(hdwf, 1, sts) = 0 Then Return End If If sts = DwfStateDone Then Exit While End If End While FDwfDigitalInDividerGet(hdwf, hzRate) ' get the actual rate Const cSamplePerBit = hzRate / hzUart Dim rgData(cSamples) As UInt16 FDwfDigitalInStatusDataUShort(hdwf, rgData, 2 * rgData.Length) Call FDwfDeviceCloseAll() Dim rg0 = decodeUart(rgData, cSamplePerBit, 0) System.Console.Write("Hex 0: ") For i = 0 To rg0.Count - 1 System.Console.Write(" 0x" + Conversion.Hex(rg0(i))) Next System.Console.WriteLine() System.Console.WriteLine("Text 0: " + System.Text.Encoding.ASCII.GetString(rg0.ToArray)) End Sub End Module
  16. 1 point
    Actually, I'm not sure what Diglent's policy is about questions that aren't specific to Xilinx or Digilent products. The various FPGA vendors are certainly competitors but I have a hard time seeing non-commercial customers as 'competitors' regardless of which vendors' products they are using. I would agree that, even though some of the people who respond to questions posted to Digilent's Forum have recent experience with a variety of FPGA vendor's devices and tools, posting questions to a website dedicated to Xilinx based products when your question is specific to Intel is a good way to get bad information and probably unwise. Also, and this hasn't happened yet, I suspect that having a lot of questions about non-Xilinx devices and tools would be confusing to a lot of readers and make the experience for many of them of reading posts to Digilent's forum less useful. Intel has a community forum as does Xilinx. Neither is, in my experience, as helpful as Digilent's most of the time. Intel is, well not Altera, and even Altera's community support wasn't that great. Digilent's Forum is a great place to ask about Digilent products and Xilinx tools. Even restricted to that it' must be hard for people to find answers that have already been posted because a a lot of questions keep getting repeated. I do heartily suggest that it would be more appropriate to seek out answers to questions like saif1's at forums where people who hang out there are very knowledgeable about the tools and devices for the platform that you are working on. There also must be vendor agnostic forums out there somewhere dealing with FPGA development tools and devices. My last word is that an awful lot of questions would be answered if the poster only took the time to read through the vendors' literature. If there's any practice that's bad form it's wasting other peoples time because you can't be bothered or don't have the time to read readily available literature. Everyone's time is as important to them as yours is to you.
  17. 1 point
    D@n

    Custom IP

    @PoojaN, You're not the first person who has asked this. If you just want to blink an LED, then I'd recommend a different approach that avoids all the pain with AXI in the first place. (You don't need AXI ...) If you want to start interacting with AXI cores, then you'll need to learn AXI. Sadly, this isn't as simple as it sounds. Xilinx picked the AXI bus to connect all their components with. This may have something to do with their ARM integration, since if I understand correctly AXI is an ARM creation AXI is not a simple bus to work with. Unlike Wishbone, it has five channels associated with it each of which can stall. These are the read address channel, the write address channel, the write data channel, the read response channel and the write response channel. One bus failure, and your device will lock up. In my experience, using an ARM+FPGA chip, lockups could only be fixed by cycling the power leaving you ever wondering what had caused the problem. Part of the problem is that the AXI standard has no way of recovering following a dropped response other than a total system reset. As I've implemented Wishbone, you can just adjust one wire (the cycle line--but that's another story) and start over. You can even use a timeout to clear the bus if a peripheral has not responded within an expected period of time. Not so with AXI. AXI is so difficult to work with that not even Xilinx could get it right. (See the links above) When I first discovered these bugs, I wondered that no one had found them before. For example, two writes in a row would lose a response and lock up the bus if ever there was the slightest amount of backpressure on the return channel. (Something Wishbone doesn't have to deal with, since there's no way to stall a Wishbone acknowledgement) It would seem as though very few individuals ever simulated their cores with backpressure (i.e. either BREADY or RREADY signals low), and so they never noticed these bugs. Similarly, some configurations of the interconnect might trigger the bugs while others wouldn't. Imagine adjusting the glue that holds your design together only to find your design starts failing. What would you blame? The interconnect, right? When in fact it was their demonstration core logic at fault that everyone was copying. I've now fielded several questions in the last several months alone on Xilinx's forums from users who've struggled with these bugs. If you do searches, you'll discover that folks have been struggling with these sorts of problems ever since Xilinx started using AXI. In one recent post, a software engineer posted that his FPGA engineer had left, leaving them with a "working" design. He then adjusted the software within the design and the whole design now froze any time he tried to write to their special IP core twice in succession. I'm hoping Xilinx will fix these bugs (soon). I haven't checked their latest release since reporting them, but I do expect them to fix the bugs in the near future. It's not just Xilinx either. I'm currently verifying the (ASIC) soft core of a major (unnamed) vendor. Much to my surprise, despite a team of highly paid professional engineers working to produce this amazingly complex core , and despite the fact that they created a simplified subset of the AXI interface standard to work with ... they still didn't get the AXI interface right. Realizing how difficult this was, I tried to simplify the task by creating a couple of cores. One showing how to build a bug-free AXI-lite slave (link above), another showing how to build a bug-free AXI slave (link above again). I also shared an AXI bridge implementation that, if you place your core downstream of it, you'd be guaranteed to meet the AXI protocol--even if it slowed you down a touch. I also shared the code for verifying that an AXI-lite component works--you are free to try it out yourself to know if your core still works after changing it. If you like using Wishbone, I've posted an AXI-lite to Wishbone bridge, or even a Wishbone to AXI bridge in case you want to access your DRAM memory. I also think you'll find that all of these cores, save perhaps the bus fault isolator core, will have better performance than Xilinx's logic ever had. Whether or not you use these options (or give up on AXI as I've tried to do) ... well, that's up to you. Forget what the sales brochures tell you, we aren't playing with legos here. There's more required to hook things together then just plugging them into each other--especially if you want something that works reliably when you are done. Just want something simple? Learn Verilog or VHDL. At least then you'll be the one responsible for your own bugs. Dan
  18. 1 point
    yes, for an application with basic requirements, like receiver gain control this will probably work just fine (it's equivalent to an analog envelope detector). Now it needs a fairly high bandwidth margin between the modulation and the carrier, and that may make it problematic in more sophisticated DSP applications (say "polar" signal processing when I try to reconstruct the signal from the envelope) where the tolerable noise level is orders of magnitude lower.
  19. 1 point
    Nothing to worry about if only one is up at a time. It would mean that the frequencies of adjacent oscillators affect each other if they are running at the same time ("injection pulling", to the point that they agree on a common frequency ("locking"). Consider the oscillator as an amplifier with a feedback loop. The feedback path plus phase shift lead to a fairly narrow frequency response around the oscillation frequency or harmonically related frequencies). Weird things can happen with the gain - while it is unity in average steady-state operation, the circuit can get highly sensitive to external interference that is (near)-correlated with the oscillator's own signal. Wikipedia: Perhaps the first to document these effects was Christiaan Huygens, the inventor of the pendulum clock, who was surprised to note that two pendulum clocks which normally would keep slightly different time nonetheless became perfectly synchronized when hung from a common beam
  20. 1 point
    D@n

    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
  21. 1 point
    Hi @ahmedengr.bilal, Like I mentioned in the previous post there is no HDMI output from the Linux side, neither the embedded rootFS provided by petalinux nor the kernel configuration we give out is set to accommodate this feature. Regarding the missing media-ctl and v4l2-ctl, you have not activated the v4l-utils in the rootfs configuration of the petalinux. to do this you need to navigate to your petalinux project folder and run: petalinux-config -c rootfs Once the menu appears you need to go to Filesystem Packages->misc->v4l-utils and activate: v4l-utils, libv4l, media-ctl. Rebuild the whole project and it should be working now. -Ciprian
  22. 1 point
    jomoengineer

    Howdy from NorCal

    Thanks Jon. And thanks for the links. Cheers, Jon
  23. 1 point
    Hi, as I may not have time for FPGA work for a while - just started in a fascinating new role related to high-speed digital diaper changing - I decided to post this now. Here's the Github repo (MIT-licensed) The project provides a very fast (compared to UART) interface via the ubiquitous FTDI chip to a Xilinx FPGA via JTAG. Most importantly, it achieves 125 us response time (roundtrip latency), which is e.g. 20..1000x faster than a USB sound card. It also reaches significantly higher throughput than a UART, since it is based on the MPSSE mode of the FTDI chip. Finally, it comes with a built-in bitstream uploader, which may be useful on its own. I implemented only the JTAG state transitions that I need but in principle this can be easily copy-/pasted for custom JTAG interfacing. So what do you get: On the software side an API (C#) that bundles transactions, e.g. scattered reads and writes, executes them in bulk and returns readback data On the RTL side a very basic 32 bit bus-style interface that outputs the write data and accepts readback data, which must be provided in time. See the caveats. In general, a significant increase in complexity over a UART. The performance comes at a price. In other words, if a UART will do the job for you, DO NOT use this project. For more info, please see the repo's readme file. For CMOD A7-35, it should build right out-of-the-box. For smaller FPGAs, comment out the block ram and memory test routines, or reduce the memory size in top.v and Program.cs. I hope this is useful. When I talked to the FTDI guys at Electronica last week I did not get the impression that USB 3.0 will make FT2232H obsolete any time soon for FPGA: They have newer chips and modules but it didn't seem nearly as convenient, e.g. the modules are large and require high density connectors. In FPGA-land, I think USB 2.0 is going to stay... Cheers Markus
  24. 1 point
    HI xc6lx45: Well, to my surprise, when I got home and loaded the .BIT file onto the board...it works perfectly. [1:0]sw is changing the frequency the the led is blinking at properly. So this tells me that I don't quite have my testbed code done properly. I tried to attach it into this text but it kept getting reformatted so I've simply attached the actual file. If somebody could look at it and tell me what (if anything) I've done wrong I'd greatly appreciate it. THANKS! NOTE: In the actual module code, above, I had changed the CASE choices to the 0, 1st, 2nd and 3rd flip-flops in order to better see the led changing value on the wave panel. However I've changed the code back to the actual flip-flops I wanted; the 26th, 25th, 24th and 23rd flip-flops. As I said...the board is working perfectly now and the switch setting are appropriately changing the led blinking frequency. It HAS to be something wrong with the TestBench code...or me not using the simulator properly. THANKS MUCH! clock_divider.tb
  25. 1 point
    jpeyron

    Nexys 2 - transistor part number

    Hi @CVu, Welcome to the Digilent Forums! Q1 information is below: NTS2101P Single P-Channel Power Mosfet 1.4A, 8VSOT-323 (SC-70) best regards, Jon
  26. 1 point
    kwilber

    Pmod DA3 clocking

    You may not have to build your own. That becomes a design decision that only you can make based on the requirements/specifications your design must meet. If the performance you are getting out of the Digilent IP meets your requirements, there is no reason to roll your own. On the other hand, if you are not able to meet your requirements and you are running up against limitations of the IP, then either look for a more performant IP or consider designing purpose specific logic. According to your measurements, it takes 40 bits sent at a rate of 3.125 Mhz for each update of the DAC. That is at least 12.8 microseconds per update. Take the inverse of that and you have a maximum update rate of 78,125 updates/second. Is that sufficient for your design?
  27. 1 point
    jpeyron

    Pmod DA3 clocking

    Hi @Ahmed Alfadhel, In section 2 Interfacing with the Pmod on page 1 of the reference manual for the Pmod DA3 here it states the pmod should use spi mode 0. thank you, Jon
  28. 1 point
    D@n

    Conflicting Voltages in Bank Arty-A7

    @zygot, @Ahmed Alfadhel is not using a Basys3 board, and so this is really a bad example of attaching one question to another post. @Ahmed Alfadhel appears to be using an Artix-A7 board. In that case, the sys_clk is properly constrained, but he may well have some of the DDR3 I/O pins improperly constrained. These are the pins located on Bank 35. I think the problem in this case is that @Ahmed Alfadhel has improperly constrained in DDR DQS pins. For example, ddr3_dqs_[0] should be set to pin N2, not to A6. Compounding the problem is the way these pins are hidden in a "board definition file" rather than in the XDC file, making it likely to have conflicting pin definitions. @Ahmed Alfadhel, If you are following Digilent's instructions, you might want to double check that you have the appropriate board definition file. If you are trying this on your own, using only an XDC file, then you might find these instructions valuable. Also, I would recommend you not attach unrelated issues to old posts. Perhaps the Digilent staff might be kind enough to separate these two issues into separate forum posts--since they really are quite different. For example, the Basys3 board doesn't have the DDR3 memory which is the source of your pin-connection troubles. Dan
  29. 1 point
    are you maybe using a low-speed analog output with 200 ohms series resistor? Check the schematic of the board for a direct output.
  30. 1 point
    Nianyu Jiang

    PmodIA Extension

    https://www.researchgate.net/publication/236037769_A_four-electrode_low_frequency_impedance_spectroscopy_measurement_system_using_the_AD5933_measurement_chipt this is the paper I am talking about. Thanks for the further explaination, I start understanding the working principle and trying to combine everything. Will go back to you once I have more question. Nianyu Jiang
  31. 1 point
    kotra sharmila

    sdsoc_opencv error

    Hi , Thank you very much for this platform its showing video i/o demo and build perfectly i will try with my own project if i got any doubts i will ask you. Regards, K Sharmila
  32. 1 point
    Hi @Sami Malik, On Monday Ii will make a project and share it on this thread that I believe you are trying to do. thank you, Jon
  33. 1 point
    Notarobot

    How to read from SD card on ZYBO

    shahbaz, Typically src folder contains C-code written by the person who design the project. It should contain the main function. You can try attached Xilinx test code. It's rudimentary but you can change it to your needs. Also you don't need to copy Xilinx files into src folder, they will be added to your project from the BSP. TestSD.c
  34. 1 point
    StijnVM

    CMOD A7 Unable to program

    Thank you Jpeyron! I reprogrammed the eeprom with your tool and now Vivado can find the CMOD A7 No idea how it went wrong in the first place however.. If I find something, I will let you know. Thanks everyone!
  35. 1 point
    jpeyron

    issue with design.txt file in xadc

    Hi @farhanazneen, Looking at your previous posts it appears that you are using a Zedboard for this project. Here is a forum thread the discusses using the ps with the xadc Header that has a completed project for the Zedboard. Here is a tutorial with the ps and xadc Header for the zedboard. Looking at your screen shots the first thing i see is you are selecting vaux0 through vaux3. If you are using the XADC header then these are the wrong channels. If you look at the zedboard reference manual here on page 26 it shows that vaux8 and vaux0 are the only channels available on the xadc header. The rest of the channels are connected to the FMC. You will need a FMC mezzanine to access the other channels. thank you, Jon
  36. 1 point
    @rpickeri Thanks for posting your solution. Did you get the prebuilt image working too? I will investigate the problem further if not.
  37. 1 point
    jpeyron

    SDSoC - couple of questions

    Hi @theUltimateSource, Download the reVISION-Zybo-Z7-20-2017.4-2.zip from here. Once you have unzipped the folder the live io can be found in the samples folder(zybo_z7_20\samples). thank you, Jon
  38. 1 point
    sbobrowicz

    gcc for petalinux

    @TheGuyWithQuestions You will want to use petalinux-config -c rootfs and enable the packagegroup-buildessential option (it will be in the "misc" folder). It may be called packagegroup-petalinux-buildessential, I'm going off memory here. I know there is also a "selfhosted" packagegroup, but I think I remember determining that the additional packages it adds were not needed in most cases. You can try enabling that packagegroup too if you are not concerned about rootfs size. Once that is enabled you should have gcc, g++, ld, etc installed into your rootfs. This will allow you to do the "self hosted" type of development, for example writing the program on your host machine, transferring the source using scp, and then building on the running system by calling g++ from the command line. Petalinux also provides a simplified environment for cross compilation development, which can be better in some situations (for example, when linking in libraries but trying to keep rootfs size small). This is handled by installing "app" recipes into your petalinux project, which will then automatically be built and installed into your rootfs when petalinux-build is run. For information on developing petalinux apps, see UG1144 from Xilinx.
  39. 1 point
    JColvin

    Pin mapping for JTAG-SMT2-NC?

    Hi @Sarah, Based on the JTAG SMT2 Reference Manual, the GPIO can be used for a number of applications, though the usual application for the GPIO2 would be to connect to the PS_SRST_B pin in Zynq based devices as you have noted. We (Digilent) do not have the timing information about when the Xilinx tools use this pin to reset the Zynq's processor core at various times during debugging operations, though it looks like Xilinx does have a little bit more information about it in their Zynq-7000 Technical Reference Manual here as well as some additional documentation for Zynq devices here. Thanks, JColvin
  40. 1 point
    Ignacas

    FPGA audio - ADC and DAC

    Just got new green PCBs for line out board. So much better than prototype..
  41. 1 point
    Hi @BYTEMAN, I am not aware of a way to have those specific microblaze configuration pages to be used after the initial block automation. I would suggest to reach out to xilinx about this question. I believe you are correct about the xdc overriding the board file defaults. thank you, Jon
  42. 1 point
    Hi @BYTEMAN, The easiest way to get the 12 mhz clk would be to use the clocking wizard. Here is a project that uses the clocking wizard with VHDL that you can use as an example for using the clocking wizard. cheers, Jon
  43. 1 point
    xc6lx45

    FPGA audio - ADC and DAC

    If I take it to extremes, the answer is surprisingly complex (this is how it's done inside the clock management tiles or a cellphone, for example). For household use, take (e.g.) a 32 bit counter and add "delta" at a high frequency, e.g. 100 MHz. Don't check for overflow, it will wrap around cyclically (which is the "correct" way to behave in this application. E.g. 0xFFFFFFFF + 3 becomes 0x00000002) For example, at 100 MHz clock, a delta of 1 gives a cycle time of 42.9 seconds (2^32 / 100e6). A delta of 43 gives a cycle time of one second. A delta of 42950 gives a cycle time of exactly 1 ms => 1 kHz. Now we've got a 32 bit number. Take the highest bits (as many as the DAC needs), voilà, a sawtooth generator. Plug that into your wavetable (you'll have to recalculate for a 0..31 range if using five ramp bits). Simple lookup from a block RAM (aka "nearest-neighbor / zero-order interpolation") will give abysmal audio quality, or the wavetable grows so large that it doesn't fit into the FPGA. So I need higher-order interpolation or a different algorithm (e.g. CORDIC for sine), and things get messy. PS: When working with signed numbers, check Verilog's "signed" keyword. It's not mandatory, but makes life easier.
  44. 1 point
    jfdo

    Welcome!

    Hi, I am Harendra Fernando (one can use Julian if it is easier) from Australia. I am a new member just started using this forum, in fact yesterday.
  45. 1 point
    jessekotsch

    Zybo HDMI Tutorial Help

    Thank you!!! it seems to be working. It says all of our IP cores are up to date
  46. 1 point
    jpeyron

    Vivado version for Arty Z7-20

    Hi @Mahesh, I was able to get the arty-Z7-20 hdmi out to generate a bitstream in vivado 2017.4. To do this you new a fresh project. Then upgrade the ip cores by clicking tools->repots->report ip status and upgrade/generate the ip cores. Then create a wrapper. The DVI2RGB ip core has been updated since this project was made. Because of the updated ip core you will need to change the xdc pin names in the xdc file. From hdmi_hpd_tri_i to HDMI_HPD_tri_i , from hdmi_ddc_scl_io HDMI_DDC_scl_io and from hdmi_ddc_sda_io to. HDMI_DDC_sda_io. Next generate bitstream. The rest should be the same steps to get project working. cheers, Jon
  47. 1 point
    I searched for inactive driver in the Windows device manager and found out that there appear 2 x USB Serial Converter A and 2 x USB Serial Converter B. I deleted all of them and powered the board. Now both boards work.
  48. 1 point
    zygot

    Feedback on a register file design?

    Your instincts are very good.. it's great to not have to give advise because the audience has already figured it out for them self.. Insight is hard to come by and can be as important as textbook knowledge. The RTL view of post-route logic ( not the board design schematic ) is a good way to verify that what you want is what you got... and can help resolve confusion. Sometimes you just have to rework your logic to get what you want from the synthesis tool. I still create play projects just for the purpose of understanding the nuances of a particular design/syntax strategy and see what the simulator says and how the bitstream behaves in real hardware.
  49. 1 point
    OK thanks. Yes, updating that tutorial would save a lot of time and confusion. I later noticed that Xilinx's page for 2017.2 has a bit more description relating to free WebPACK than the page for 2017.3, though it's still not clear how to invoke the free aspect. Further confusion is added by the Xilinx page you arrive at from Vivado's License Manager, as that page omits the Activation-based licenses, and the licenses it does show include a Free one for pre-2015, as though you can't license 2016 and later for free. Evidently that doesn't mean you can't use 2016 and later, it means that no license is required, and you don't need to be using the License Manager at all!
  50. 1 point
    hamster

    MMCM dynamic clocking

    I feel a bit bad about posting a minor novel here, but here is an example of going from "5 cycles on, 5 off" (i.e. divide by 10) to "10 on, 10 off" (device by 20). The VCO is initially to 800 MHz with CLK0 being VCO divide by 8.... so after config you get 100MHz. Push the button and you get 800/20 = 40MHz, release the button and you get 80MHz. It is all really hairy in practice! EDIT: Through experimentation I just found that you don't need to reset the MMCM if you are not changing the VCO frequency. So the 'rst' signal in the code below isn't needed (and LOCKED will stay asserted). -------------------------------------------------------------------------------------------------------- -- Playing with the MMCM DRP ports. -- see https://www.xilinx.com/support/documentation/application_notes/xapp888_7Series_DynamicRecon.pdf -- for the Dynamic Reconviguration Port addresses -------------------------------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; library UNISIM; use UNISIM.VComponents.all; entity mmcm_reset is Port ( clk_100 : in STD_LOGIC; btn_raw : in STD_LOGIC; led : out STD_LOGIC_VECTOR (15 downto 0)); end mmcm_reset; architecture Behavioral of mmcm_reset is signal btn_meta : std_logic := '0'; signal btn : std_logic := '0'; signal speed_select : std_logic := '0'; signal counter : unsigned(26 downto 0) := (others => '0'); signal debounce : unsigned(15 downto 0) := (others => '0'); signal clk_switched : std_logic := '0'; signal clk_fb : std_logic := '0'; type t_state is (state_idle_fast, state_go_slow_1, state_go_slow_2, state_go_slow_3, state_idle_slow, state_go_fast_1, state_go_fast_2, state_go_fast_3); signal state : t_state := state_idle_fast; ----------------------------------------------------------------------------- --- This is the CLKOUT0 ClkReg1 address - the only register to be played with ----------------------------------------------------------------------------- signal daddr : std_logic_vector(6 downto 0) := "0001000"; signal do : std_logic_vector(15 downto 0) := (others => '0'); signal drdy : std_logic := '0'; signal den : std_logic := '0'; signal di : std_logic_vector(15 downto 0) := (others => '0'); signal dwe : std_logic := '0'; signal rst : std_logic := '0'; begin MMCME2_ADV_inst : MMCME2_ADV generic map ( BANDWIDTH => "OPTIMIZED", -- Jitter programming (OPTIMIZED, HIGH, LOW) CLKFBOUT_MULT_F => 8.0, -- Multiply value for all CLKOUT (2.000-64.000). CLKFBOUT_PHASE => 0.0, -- Phase offset in degrees of CLKFB (-360.000-360.000). -- CLKIN_PERIOD: Input clock period in ns to ps resolution (i.e. 33.333 is 30 MHz). CLKIN1_PERIOD => 10.0, CLKIN2_PERIOD => 0.0, -- CLKOUT0_DIVIDE - CLKOUT6_DIVIDE: Divide amount for CLKOUT (1-128) CLKOUT1_DIVIDE => 1, CLKOUT2_DIVIDE => 1, CLKOUT3_DIVIDE => 1, CLKOUT4_DIVIDE => 1, CLKOUT5_DIVIDE => 1, CLKOUT6_DIVIDE => 1, CLKOUT0_DIVIDE_F => 8.0, -- Divide amount for CLKOUT0 (1.000-128.000). -- CLKOUT0_DUTY_CYCLE - CLKOUT6_DUTY_CYCLE: Duty cycle for CLKOUT outputs (0.01-0.99). CLKOUT0_DUTY_CYCLE => 0.5, CLKOUT1_DUTY_CYCLE => 0.5, CLKOUT2_DUTY_CYCLE => 0.5, CLKOUT3_DUTY_CYCLE => 0.5, CLKOUT4_DUTY_CYCLE => 0.5, CLKOUT5_DUTY_CYCLE => 0.5, CLKOUT6_DUTY_CYCLE => 0.5, -- CLKOUT0_PHASE - CLKOUT6_PHASE: Phase offset for CLKOUT outputs (-360.000-360.000). CLKOUT0_PHASE => 0.0, CLKOUT1_PHASE => 0.0, CLKOUT2_PHASE => 0.0, CLKOUT3_PHASE => 0.0, CLKOUT4_PHASE => 0.0, CLKOUT5_PHASE => 0.0, CLKOUT6_PHASE => 0.0, CLKOUT4_CASCADE => FALSE, -- Cascade CLKOUT4 counter with CLKOUT6 (FALSE, TRUE) COMPENSATION => "ZHOLD", -- ZHOLD, BUF_IN, EXTERNAL, INTERNAL DIVCLK_DIVIDE => 1, -- Master division value (1-106) -- REF_JITTER: Reference input jitter in UI (0.000-0.999). REF_JITTER1 => 0.0, REF_JITTER2 => 0.0, STARTUP_WAIT => FALSE, -- Delays DONE until MMCM is locked (FALSE, TRUE) -- Spread Spectrum: Spread Spectrum Attributes SS_EN => "FALSE", -- Enables spread spectrum (FALSE, TRUE) SS_MODE => "CENTER_HIGH", -- CENTER_HIGH, CENTER_LOW, DOWN_HIGH, DOWN_LOW SS_MOD_PERIOD => 10000, -- Spread spectrum modulation period (ns) (VALUES) -- USE_FINE_PS: Fine phase shift enable (TRUE/FALSE) CLKFBOUT_USE_FINE_PS => FALSE, CLKOUT0_USE_FINE_PS => FALSE, CLKOUT1_USE_FINE_PS => FALSE, CLKOUT2_USE_FINE_PS => FALSE, CLKOUT3_USE_FINE_PS => FALSE, CLKOUT4_USE_FINE_PS => FALSE, CLKOUT5_USE_FINE_PS => FALSE, CLKOUT6_USE_FINE_PS => FALSE ) port map ( -- Clock Outputs: 1-bit (each) output: User configurable clock outputs CLKOUT0 => clk_switched, CLKOUT0B => open, CLKOUT1 => open, CLKOUT1B => open, CLKOUT2 => open, CLKOUT2B => open, CLKOUT3 => open, CLKOUT3B => open, CLKOUT4 => open, CLKOUT5 => open, CLKOUT6 => open, -- Dynamic Phase Shift Ports: 1-bit (each) output: Ports used for dynamic phase shifting of the outputs PSDONE => open, -- Feedback Clocks: 1-bit (each) output: Clock feedback ports CLKFBOUT => clk_fb, CLKFBOUTB => open, -- Status Ports: 1-bit (each) output: MMCM status ports CLKFBSTOPPED => open, CLKINSTOPPED => open, LOCKED => open, -- Clock Inputs: 1-bit (each) input: Clock inputs CLKIN1 => clk_100, CLKIN2 => '0', -- Control Ports: 1-bit (each) input: MMCM control ports CLKINSEL => '1', PWRDWN => '0', -- 1-bit input: Power-down RST => rst, -- 1-bit input: Reset -- DRP Ports: 16-bit (each) output: Dynamic reconfiguration ports DCLK => clk_100, -- 1-bit input: DRP clock DO => DO, -- 16-bit output: DRP data DRDY => DRDY, -- 1-bit output: DRP ready -- DRP Ports: 7-bit (each) input: Dynamic reconfiguration ports DADDR => DADDR, -- 7-bit input: DRP address DEN => DEN, -- 1-bit input: DRP enable DI => DI, -- 16-bit input: DRP data DWE => DWE, -- 1-bit input: DRP write enable -- Dynamic Phase Shift Ports: 1-bit (each) input: Ports used for dynamic phase shifting of the outputs PSCLK => '0', PSEN => '0', PSINCDEC => '0', -- Feedback Clocks: 1-bit (each) input: Clock feedback ports CLKFBIN => clk_fb ); speed_change_fsm: process(clk_100) begin if rising_edge(clk_100) then di <= (others => '0'); dwe <= '0'; den <= '0'; case state is when state_idle_fast => if speed_select = '1'then state <= state_go_slow_1; -- High 10 Low 10 di <= "0001" & "001010" & "001010"; dwe <= '1'; den <= '1'; end if; when state_go_slow_1 => if drdy = '1' then state <= state_go_slow_2; end if; when state_go_slow_2 => rst <= '1'; state <= state_go_slow_3; when state_go_slow_3 => rst <= '0'; state <= state_idle_slow; when state_idle_slow => di <= (others => '0'); if speed_select = '0' and drdy = '0' then state <= state_go_fast_1; -- High 5 Low 5 di <= "0001" & "000101" & "000101"; dwe <= '1'; den <= '1'; end if; when state_go_fast_1 => if drdy = '1' then state <= state_go_fast_2; end if; when state_go_fast_2 => rst <= '1'; state <= state_go_fast_3; when state_go_fast_3 => rst <= '0'; state <= state_idle_fast; end case; end if; end process; dbounce_proc: process(clk_100) begin if rising_edge(clk_100) then if speed_select = btn then debounce <= (others => '0'); elsif debounce(debounce'high) = '1' then speed_select <= not speed_select; else debounce <= debounce + 1; end if; -- Syncronise the button btn <= btn_meta; btn_meta <= btn_raw; end if; end process; show_speed_proc: process(clk_switched) begin if rising_edge(clk_switched) then counter <= counter + 1; led(7 downto 0) <= std_logic_vector(counter(counter'high downto counter'high-7)); end if; end process; led(15) <= speed_select; end Behavioral;