Popular Content

Showing most liked content since 03/28/2017 in all areas

  1. 3 likes
    Hi @coloradosensors, I just generated bitstream on this project in Vivado 2015.4. You need to right click on the clocking wizard and remove it. Then under project manager click on ip catalog and re-add the clocking wizard with default settings. This will fix your issues with using an older version of Vivado for this project. cheers, Jon
  2. 2 likes
    Hi @RisinT96, As you observed, the AD7873ARUZ is not loaded on the FMC-HMI. Section 1.5 of the reference manual states: "The AMS header is there to provide support for the XADC feature of seven-series system boards. Operators can use the AMS header signals to bias the touch panel by selecting the analog MUX inputs and carrying the differential analog signal to the FPGA pins for measurement." You can learn about 4-wire resistive touch screens here: https://www.sparkfun.com/datasheets/LCD/HOW DOES IT WORK.pdf http://www.ti.com/lit/an/slaa384a/slaa384a.pdf The idea is to use [X|Y]D[+|-] (drive) pins in the AMS header to bias two electrodes and use the ADG709CRUZ analog multiplexer to switch the [X|Y]S[+|-] (sense) lines to VP/VN pins of the AMS header. The drive pins in the AMS header are digital and are expected to be controlled from a 3.3V FPGA bank. Just output '1' and '0' conform the biasing scheme. The sense lines that need to be measured can be selected with A0 and A1, which are also in the AMS header. Finally, VP/VN is the dedicated input to the XADC primitive that needs to be used to digitize the measurement. The coordinate can be calculated from there.
  3. 2 likes
    @Assane, You know what's really cool about this then? I get to get the credit for being the "more experienced engineer" @jpeyron mentioned ... when I really know very little about this interface. Dan
  4. 2 likes
    In Vivado versions 2015.X-2016.2 there is a bug in the AXI_GPIO Core when adding a board part to the GPIO2 interface on the AXI_GPIO IP block in Vivado IPI (block design). You may get the following error: [IP_Flow 19-3452] Invalid long/float value '16]' specified for parameter 'GPIO Width(C_GPIO2_WIDTH)' for BD Cell 'axi_gpio_0'. To fix this go into Vivado/2016.2/data/ip/xilinx/axi_gpio_v2_0/xgui/axigpio_v2_0.tcl and remove the extra ']' at the end of line 246. Hopefully Xilinx will fix this small typo in the 2016.3 release. Hope this helps!
  5. 2 likes
    @MrKing, Looking back over my answer, I think I'd like to amend it with the following: First, I didn't recommend these forums before. I'd like to do so now. Lots of folks working on their designs come to these forums for help. The help and advice I've seen given here ranges anywhere from helping the very beginner get their first design up and running, all the way to more experienced engineers trying to build a commercial product. You are more then welcome to come back and ask for help on Digilent's forum (here), and I have to imagine Digilent would be very thankful if you did: it raises the profile of their site, and hence their products. Other beginners have asked for advice here, much like you, and rather than repeat that advice, I'd like to reference you to it. It's not necessarily for the Arty, but often generic to any board: Please feel free to come back with more questions if you have more. I'd offer to help you get started, but ... I think the posts above outline how to go about that. So, instead, write back if this is confusing, or if you have further questions, Dan
  6. 1 like
    I would like to suggest that you abandon or at least rethink your ratings of people posting to this site based on the number of posts. I myself, find that I have been given a rating one might associate with a dizzying level of competence simply by passing the century mark in posts. On the other hand there are posters who clearly are superbly knowledgeable and labelled as a "newbie". I think that this is a disservice to everyone but especially those who lack the technical knowledge to ignore it. By the way, it's not that I consider myself to be on the low end of competency and expertise among posters, including those on the payroll offering presumed technical expertise. I would hope that the whole idea of rating people isn't a cynical sales choice.
  7. 1 like
    Hi BeamPower, I've worked on the project you are trying to use. The error you are seeing arises because the clk_wiz IP block is outdated and needs to be upgraded. Thankfully this is easy to do within Vivado. What you need to do is open up the GPIO project, and underneath tools git Report>Report IP Status. This will open a new tab at the bottom of your screen that shows any IP that is being used by the design. The status for the clk_wiz should say that it needs to be upgraded, so check the box next to clk_wiz, and then Upgrade Selected should become active. Click that, and if you see a confirmation that asks you to use Core Containers, make sure you select that option that doesn't use them. After that, you should be asked if you want to generate new output products, and you can do so. Once that is completed, give a shot at generating the bitstream. I've updated the online repositories to contain the updated clk_wiz ip cores. Let me know how everything works out for you! Regards, AndrewHolzer
  8. 1 like
    Hi @sychu, We are in contact with Mathworks but would not be able to give an ETA or timeline. cheers, Jon
  9. 1 like
    By the way , the more you write the more convinced that you really need some help grasping the basics. VHDL was designed as a simulation language but was co-opted for synthesis because of its popularity. The language doesn't care about issues of synthesis but the synthesis tool sure does. A cursory reading of the syntax is not likely to be a helpful guide. With this in mind it should be clear that you can write perfectly fine VHDL code that can't be synthesized into something that works on hardware.
  10. 1 like
    Hi @sychu, Here is a blog post that explains the situation with the AD2 and Matlab Data Acquisition Toolbox. With your second question, you can have two AD2's going with two different Waveforms 2015 up and running. You can use scripts with triggers to have one AD2 trigger the other ad2 to start. cheers, Jon
  11. 1 like
    I think your latest issue is caused by a bug in the uvc gadget driver. I think you need to apply this patch to the kernel: https://www.mail-archive.com/linux-usb@vger.kernel.org/msg89422.html
  12. 1 like
    Hi @Torfey, Glad to hear you were able to get this part of your project going! Thank you for posting how you accomplished it. cheers, Jon
  13. 1 like
    @kuangjiqingma, I think you'll find very quickly that very few folks on this forum are familiar with HLS. May I invite you to start answering the HLS questions that others have here on this forum? I am personally working on an HDMI implementation myself. I've discovered that there are many, many, steps to producing an HDMI signal. These steps go well beyond just dumping pixels to an interface, but also include checking for whether the hot-plug detect signal is high, reading the EDID signaling, and then the TMDS signal itself. The TMDS signal encodes video and horizontal frame syncs, audio side channels, as well as pixel data. These syncs themselves take a bit of work, and there's a lot of details (all simple, but still a lot of them) required to getting the right number of V and H sync clocks, the right pixel clock, and so forth. Knowing all of this ... I have to admit, it's a bit of a struggle to imagine that the code you've posted above is producing an HDMI signal. You might be right, maybe it does, but if so there's got to be a *lot* of stuff going on under the hood. Dan
  14. 1 like
    Hi @akshata@94, Welcome to the forum! I moved your thread to a section that would get viewed by more fpga experienced forum members. I have not worked with md5 so i'm sure how much help i would be. I have reached out to other forum moderators to see if they would have any input for you. Can you attach the errors you are getting. cheers, Jon
  15. 1 like
    Hello everyone, PIC32MX and PIC32MZ base support has been merged in RIOT-OS. In addition, basic support for the chipKIT Wifire has also been merged. RIOT is a small operating systems for embedded devices with the following features: Multi-threading support, with a full stack for each thread Some POSIX compatibility network stack with IPv6 support Drivers for various sensors And many other things The current support for the chipKIT Wi-Fire is still very incomplete: only a small GPIO driver has been merged. I have written some drivers for SPI, I2C, Random Number Generator (available on my github repository) but it would help a lot if more people contribute: writing drivers for peripherals, reviewing & verifying pull requests, writing documentation in the wiki... How to try RIOT-OS on the Wifire If you are on Windows, follow the instructions on the wiki: https://github.com/RIOT-OS/RIOT/wiki/Build-RIOT-on-Windows-OS. Install the MIPS toolchain Set MIPS_ELF_ROOT environment variable to the MIPS toolchain directory export PATH=$PATH:$MIPS_ELF_ROOT/bin cd examples/hello-world make BOARD=pic32-wifire The file to flash is bin/pic32-wifire/hello-world.hex. The UART output is configured as baudrate 9600, one stop, no parity bit. Useful links: - RIOT repository: https://github.com/RIOT-OS/RIOT/ - toolchain: https://community.imgtec.com/developers/mips/tools/codescape-mips-sdk/download-codescape-mips-sdk-essentials/ François
  16. 1 like
  17. 1 like
    Tickstart,these I haven't made any "description" of you nor do I think that you're stupid... so please don't amend my comments to garner an unearned insult. If I want to insult you I will do so without there being any doubt about it. Actually, there was the one time I DID try and insult someone intentionally and he just thought that I was funny.... what an ass ( a MENSA member ) so I've given that up. Really, I don't want to insult anyone ( other than that guy...) but seem to have a knack for doing it unintentionally. It's a "gift" I suppose.... So, thanks for the background. This is helpful and I think that we can get somewhere. First off, the fact that even with over 20 years of experience writing HDL code professionally I write test benches for all of my design modules should be a big hint as to what kind of advice you will get from me, Learn how to write testbenches. There is help on the internet if you look for it. Testbenches don't solve all problems as they only do what you make the test... meaning that you have to understand what to test for. This reason alone is why you need to use them. Your skill designing solutions to problems will get better as your testbenches improve. Trust me on this. You state: "I don't really like vhdl's functions and processes and procedures, they're confusing and obfuscating." Yes they are... until you understand the concepts. Until you do using VHDL or Verilog will be a very painful exercise for you. And will System C and whatever becomes popular down the road as well. This is something that I can't help you with... you need to decide that it's worth your time and effort. Having some sort of mentor might help. You don't have to take a course but it wouldn't hurt either. As I mentioned before FPGA design concepts are different from standard computer languages ( I've used C, PASCAL, ADA, PYTHON, numerous assembly languages, custom languages, etc, etc.) . If you don't have an interest in learning them you will be a very frustrated person doing your FPGA development. That's just advice not a judgement about you. So, it should be no surprise to you that I disagree with your last statement: "Just need a fresh pair of eyes". But you are under no obligation to take my advise.
  18. 1 like
    I'll be straight up with you, I've never used any of the linux USB gadget drivers before, so I'm probably not going to be much help. Maybe someone else will chime in who has some experience with this. Your question is actually not specific to Digilent or Xilinx materials, so you might have some success reaching out to the larger, more general linux community. You could try linuxquestions.org or even stack overflow. Basically just ask around about how to use the linux usb webcam gadget driver on an embedded ARM target. K, I just found this post that might help too, it is Xilinx specific: https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/ZC702-as-UVC-Device-USB-Webcam/td-p/563957 I also noticed that it looks like Xilinx also suggests you insert configfs.ko... Make sure you have set the following to 'M' (not '*') in the menuconfig: <M> USB Gadget Drivers <M> USB functions configurable through configfs
  19. 1 like
    Hi @SMatt, I am not experienced enough in embedded linux to help you. I have reached out to an experienced embedded linux engineer to look at this forum. cheers, Jon
  20. 1 like
    @SUSHMA MANTAGANI, I think what you are wondering is what is wrong with your design. To answer that question, you really need to use wireshark for debugging it. That will allow you to look at and inspect the packets that are crossing the wire, so that you can see if they are properly formed or not. Indeed, that will also allow you to figure out whether or not it is the fault of the computer you are transmitting from, or the fault of the one you are transmitting to, and what part of the packet(s) are actually at fault. Dan
  21. 1 like
    @neil, @zygot had made a comment some time ago that the XADC pins really worn' good enough for high speed I/O. I haven't dug into what he was referencing. I will note that the circuitry on the XADC pins is different from that of of a normal PMod, so ... they wouldn't be my first choice if I had a choice. Further, I think the XADC0 pin on the Nexys-DDR has a low-pass filter on it--not at all what you'd want to use for high speed. You might be stuck with needing different hardware if you really want the high speed ports. Dan P.S. Don't tell @zygot (yet) ... but I think I can make an interface that'll get nearly 150MB/s (that's mega-Bytes per second) using a differential PMod port. I wouldn't want you to tell him yet, 'cause it's a work in progress, but I do intend to smash his record in due time ...
  22. 1 like
    There's a Github repo (that's not linked from anywhere) at https://github.com/Digilent/Arty-Z7-20-linux_bd - "This project is an internal project used by Digilent for the Arty Z7-20 Petalinux Project. You are free to use it as you please, but it isn't documented on our Wiki." Are there instructions anywhere on how to actually build the thing? The Arty Z7 reference manual says "To help you get started, Digilent provides a Petalinux project that will get you up and running with a Linux system quickly. For more information, see the Arty Z7 Resource Center." The resource center link goes to the wiki - which has no info on Petalinux in it. I'm willing to wait a week before requesting a refund.
  23. 1 like
    @wanderso Could you take a screenshot of the lscript.ld file in your SDK application project? You may be able to increase the stack or heap size to support your 2KB array. Thanks, Arthur
  24. 1 like
    A few suggestions to debug: 1) Can you access vp/vn? These pins are always connected, so as long as you enable them in the sequence (and enable sequence mode) they will be read. 2) Are you using unipolar or bipolar mode for your inputs? A battery like signal should be configured as unipolar. 3) It is also good to connect vn to analog ground for unipolar signals. There must be a relationship between analog ground and the signal you are monitoring. This is due to the common mode input specs and all ADCS require this. 4) Transfer function: unipolar mode is 0 to 1v. Taking 12 bit data divide the code by 4096 gives the value. There is no other scaling required. 5) If internal sensors are good then calibration is good. There is no extra calibration for external channels required.
  25. 1 like
    @plazma33, Ok, thanks for posting the pictures. That helps. I'm not sure why you think you need the PMod USBUART, though. It might make more sense to Connect the Zybo to your PC via the USB UART (No PMod required--it's built into the Zybo), Connect the accelerometer to one of the Zybo PMod ports, Read the accelerometer using the Zynq chip on the Zybo,, and Report the data back through the USB UART (still built into the Zybo) to the PC host. Does this make any more sense to you? Dan
  26. 1 like
    @paolo_unice, You may be asking in the wrong forum. I'm sure if you asked in the simulink forum, you'd get a different answer. But, for now, I'll give you my own background. As a government official, in my past life and years ago, I was asked to evaluate the simulink design process and tool flow. A contractor we had hired loved the flow and swore by it. So, he did a bunch of work for us and delivered it to us using simulink. Here are some of the conclusions from my experience with the project: Simulink files can only be read with simulink. If, years down the line, you decide you can no longer afford simulink, you will lose any and all of the code you have written for it. (This happened to us. The project died, we had no more reason to maintain our license, but years later I wanted to use and examine some of the circuits we had created--I could not do so.) It is very difficult to do diff's of binary objects, whereas diff's of text files (either VHDL or Verilog) is fairly easy to do. Hence measuring changes is easier with text than simulink. Sure, simulink can be used to create verilog or VHDL ... but like most computer generated code, no one will be able to read it. At one time, I wanted to find how the contractor had built a particular circuit within his simulink design. With VHDL or Verilog, I would've started from the external bits at the top level, and just followed them into the design. However, with his simulink design, I had to do a search through the various components of his design before I could find (about four levels deep) the pins that connected to the part in question. In VHDL or Verilog, you are presented with the low level details of how an implementation must work. These details, such as how many bits a particular number gets, where the decimal point is, etc., are very important to a design. When I watched my contractor work with simulink, these details were hidden behind menus, so it was harder to tell if the fine print was done properly. So, to answer your question, is it a good idea to put something through a simulink encoder process, my answer would be that I would not recommend it. I'm sure others would give you other answers. I also had the opportunity to work on a design where I wanted MATLAB's scripting capabilities, and I wanted to mix these with my design. I chose instead to build my own very simple interface (4 hrs complexity), to then get relevant parts and pieces of my design in and out of matlab. Simulink wasn't required, I saved a boatload of money, and had all the info I needed on my design. As for whether or not interfacing something with simulink is possible, ... you might wish to check on the simulink forum. Just my two cents, Dan P.S. I just built a decoder for the PModMIC3 A/D, and I have built an example of testing it from C++ that you can find here, if you are at all interested in alternatives. I think the PModMIC3 uses a similar A/D based interface.
  27. 1 like
    Hi, I'm currently designing a board with the same TPS65400 that is used on Arty-Z7 board. Looking at the schematic, I see that all ENSW pins of this IC are connected to +5V rail (VCC5V0 on schematic) via 20K resistor. However datasheet says that these pins are supposed to be referenced to VDDD pin and maximum allowed voltage is 3.6V, so having +5V there is beyond this restriction. According to datasheet these pins already have weak internal pullups, so they can simply be left unconnected if not used for power rail sequencing, but feeding 5V in them would force these resistors to sink current instead of sourcing it, which is probably not what they were designed to do. I would really appreciate if someone would explain what I'm missing here as I'm really confused.
  28. 1 like
    @Clarissa, Yes, it means you can adjust the frequency standard of those pins used on the FMC connector, as well as the power used by the switches, the buttons, and the XADC PMod (not all of the PMods) FPGA's handle their I/O voltages by bank. Hence, when you adjust the I/O voltage of a bank, you adjust the I/O voltages of all of the signals on that bank. This is the reason why you can't just specify a voltage for an I/O pin and expect it to suddenly have that voltage (a common misperception). The voltage needs to first be set in the voltage rail for the whole I/O bank. Hence, for most Digilent boards, this I/O voltage is fixed. This is also true for most of the Nexys Video board, although only one bank's voltage may be adjusted. If you look across the top of page 10 of the Nexys Video schematic, the Digilent Nexys Video engineer has been kind enough to write above the various I/O banks the voltage standard being used for each bank. The third I/O bank on that page, labeled as "Bank 15", is the adjustable voltage bank. If you look further, on page 15, you can see how the SET_VADJx and VADJ_EN lines are connected. If you'd like, you can even look up the various specifications for the chips that are then used to control that output voltage. As for the difference between LVCMOS and LVTTL, I would caution you against ascribing the only difference as being to the I/O voltages. According to Xilinx's SelectIO Resources user guide, starting at page 51, LVTTL is available at 3.3V, whereas LVCMOS is available in 1.2, 1.5, 1.8, 2.5, and 3.3 Volts (p54). In other words, the difference goes beyond voltage since both LVTTL and LVCMOS can handle 3.3V. Dan
  29. 1 like
    Hi Notarobot, Thanks for the help, I get the message printed.
  30. 1 like
    @jpeyron, Thanks! I had misunderstood the question to suggest you had been selling these already. What I saw while browsing makes more sense if it is a work in progress and the device hasn't sold yet. Dan
  31. 1 like
    Hi You want to map the values of [-128 to +127] to [0 to 255]. So either just add 128, or XOR with binary 10000000
  32. 1 like
    Thanks, it works. In SDSoC you only have to add #include "xilffs.h" and use the API. The example: https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilffs/examples/xilffs_polled_example.c See you soon ! Raúl
  33. 1 like
    Hello, For four wire SPI please add two interpreters, one for MOSI and another one for MISO, same select and clock but different data pin.
  34. 1 like
    Gosh, you guys charge for that stuff? You should look at all of the free advice that myself and others have been giving out on this forum. Dan
  35. 1 like
    Hi @Nakazato1, Our programming solution which includes the FTDI chip is considered proprietary. That is why there is a blank page in the schematic. Unfortunately I would not be able to assist with this. Hopefully one of the more experienced forum members will be willing to help you with this. thank you, Jon
  36. 1 like
    Just as a follow up I made a BCD controller out to ten digits that can be found here. https://gist.github.com/SamKLowe/b126dd6f2e77bb31e3235c6e588c5c0a
  37. 1 like
    Hello, Such option is not yet available from the WaveForms application, but having so many requests for this it will be implemented soon.
  38. 1 like
    First, the AD8195 buffer on port 2 only supports up to 2.25 Gbps. Second, high rise/fall times (<250ps) in current-driven I/O standards have real issues with the high pin capacitance of FPGA user I/O pins. There is nothing really that can be done about this. However, if the carrier board follows reasonable FMC routing guidelines, it will be functional at lower resolutions. We validated the FMC-HDMI with the Zedboard and was able to do 720p@60Hz (742.5MHz) on port 2. Even 1080p@60Hz (1485MHz) worked on the limited number of boards we tested it with. Furthermore, the carrier card also needs to support 3.3V on VADJ for the TMDS_33 I/O standard for port 2 to work.
  39. 1 like
    Based upon figure 4 of this document, it looks like about 10mA. Dan
  40. 1 like
    Filipe In a professional world any connections to the grid wires require series safety precautions. There is a special floating voltage probe (TI or Fluke) made for measurements beween AC phase wires. Voltage probes which will be connecting to grid potentials should not have connection to the ground. In the US all instruments typically have neutral (ground) wire connected internally to the metal enclosure. If your instrument has BNC coaxial connector there are high chances that it is connected to the ground eventually, thus it can't be connected to any potential grid wires. The easiest way to measure AC voltages is through an isolation transformer (not autotransformer). Be safe!
  41. 1 like
    @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
  42. 1 like
    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:
  43. 1 like
    Hi @corina, If your goal is getting current and not so much needing to use the PmodISNS20 then Here is a thread talking about using a math function with the Analog Discovery 2(can be used with the EE board) to get current. Otherwise Here is the resource page for the PmodISNS20 which has the Digilent Pmod™ Interface Specification document here. I would suggest to look at the datasheets for the IC's here and here for usage. In this case page 3 on the datasheet for the ADCS7476AIMF/NOPB has some information about the usage for SPI communications attached below. It states that the Digital clock input has a range of frequencies for input at 10 kHz to 20 MHz, with ensured performance at 20 MHz. This clock directly controls the conversion and readout processes. As well as the CS conversion process begins on the falling edge of CS. While using Waveforms you should be able to zero in the frequency you should be using for the CS. cheers, Jon Edit: On page 9-11 on the datasheet for the ADCS7476AIMF/NOPB has the timing requirements as well as 3 timing diagrams for the CS.
  44. 1 like
    We have a Pmod Bundle Option that is enabled on the Digilent.com. If you cart 6 items from the Pmod Category : http://store.digilentinc.com/pmod-modules/ your 7th item is free! (Includes cables, clips and accessory boards).
  45. 1 like
    @Assane, As I recall, there's an action required by the udev subsystem when you insert a USB Xilinx into your system. Without the udev action, it will show under lsusb (which I think is what you meant earlier, not libusb, right?), but nothing will recognize it. Getting the udev action to take place when you plug in your device requires installing the Xilinx device drivers as root. Basically, Xilinx and Digilent want to install two separate files into /etc/udev/rules.d/. Just to see if these files have been installed, can you "ls" this directory for me? You are looking for files "52-xilinx-digilent-usb.rules" and "52-xilinx-pcusb.rules". Thanks, Dan
  46. 1 like
    Hi @Assane, I will reach out to a more experienced engineer about this question. Also did you use the EnumDemo.cpp? cheers, Jon
  47. 1 like
    @rb251415, So ... can you teach it to play any music? What does it sound like? Sort of like a flute perhaps? A pipe organ? Congratulations again, Dan
  48. 1 like
    @MrKing, Have you taken a look at fpga4fun.com? They have some wonderful beginner tutorials. You can also find some fairly simple(ish) UART examples here that can be used to test the UART without requiring other parts of the board to be up and running. Those examples have been tested both in simulations and on the Arty, so they are known to work. That includes a simple hello-world example. It's not a step-by-step tutorial, though, that can be found here on fpga4fun.com. My own approach to the Arty has been to create a set of memory-mapped peripherals on a wishbone bus. I've applied this to the UART, the color LED's, block RAM, DDR3-SDRAM memory, Quad-SPI flash, Xilinx's Internal Configuration Access Port (allowing me to restart the FPGA from one of any number of configurations) a GPS timing peripheral (requires the GPS PMod), the ethernet MDIO and packet interface, an OLED interface (requires the PMod OLEDrgb), a wishbone scope (for debugging things), and even an SD-card peripheral (requires the PModSD). While this makes peripheral generation fairly easy, newcomers tend to struggle with getting an initial bus up and running, and not necessarily knowing how to modify a (nearly empty) working bus to add new peripherals. What makes the project worse is that setting up the DDR3 memory using the MIG was non-trivial, and having done it, I never made any screen captures of the process I went through to help newcomers (Yes, I need to do that). Right now, the best help I've seen and found for young FPGA types has been the IRC chat-rooms on freenode. In particular, ##fpga and ##verilog tend to be good forums. I've seen several experienced engineers talk younger ones through their struggles, just ... no one is doing anyone else's work. Other forums are more specific to what you are up to, such as the #openrisc forum for those working with the OpenRISC soft-core, the #riscv forum for those working with the RISC-V soft-core, or even the #yosys forum for those who wish to learn how to use an open-source toolchain. I personally handle Arty and ZipCPU questions on the #openarty forum, and personally help get people started ... should they wish to fire up my design. If you've never used IRC before, be prepared to wait a while (24 hrs?) for someone to answer--not everyone is on the same timezone, and not everyone is at their desk 24/7. (Sort of like this forum.) Dan
  49. 1 like
    Hi @Medtronic, Here is a youtube video that walks you through using the MYRio and the PmodTMP3 as well as changing the upper and lower temperature set points. cheers, Jon
  50. 1 like
    Hi Assane, I'm not the most familiar with the Adept API, but it looks like you can use the DmgrGetInfo() command with the "dinfoUsrName" parameter value to query the device to find out it's name since I imagine it's something like "HS3". I found these in the DMGR Progammer's Reference Manual on page 2 and the Digilent Adept System Programmers Reference Manual on page 8 that came with the Adept SDK download. Again, I'm not the most familiar with this so I personally can't speak towards the accuracy of this, but I'll make sure you get the help you need. Thanks, JColvin