Leaderboard


Popular Content

Showing content with the highest reputation since 09/29/16 in all areas

  1. 5 points
    attila

    WaveForms beta download

    3.11.4 digilent.waveforms_beta_v3.11.4_64bit.exe Added: - Scope: - set/reset zero offset in each channel option - precision option for measurements Fixed: - Script: access to traces and channels from Instrument.Export - unit conversions V to Ṽ, A to à - I2S 32 bit data 3.11.3 digilent.waveforms_beta_v3.11.3_64bit.exe digilent.waveforms_beta_3.11.3_amd64.deb digilent.waveforms_beta_3.11.3.x86_64.rpm Fixes 3.11.2 digilent.waveforms_beta_v3.11.2_64bit.exe digilent.waveforms_beta_3.11.2_amd64.deb digilent.waveforms_beta_3.11.2.x86_64.rpm Added: - Spectrum, Network and Impedance Analyzer store time data when this view is open Fixed: - runscript argument - loading of docked views geometry 3.11.1 digilent.waveforms_beta_v3.11.1_64bit.exe digilent.waveforms_beta_3.11.1_amd64.deb digilent.waveforms_beta_3.11.1.x86_64.rpm Added: - Scope: out of range warning in measurements - Protocol/UART: - support up to 32bit/word - TX/RX format: text, binary, decimal, hex - Wheel Direction option - Logic Analyzer: option to swap previous/next events - Spectrum Analyzer: allowing higher number of BINs for CZT 3.10.7 digilent.waveforms_beta_v3.10.7_64bit.exe Added: - Spectrum: logarithmic magnitude scale for voltage units - Protocol: datetime stamp for SPI/I2C Spy Fixes 3.10.6 digilent.waveforms_beta_v3.10.6_64bit.exe Added: - Scope - access to digital channels from custom mathematic channels - digital measurements view Fixes 3.10.5 digilent.waveforms_beta_v3.10.5_64bit.exe digilent.waveforms_beta_3.10.5_amd64.deb digilent.waveforms_beta_3.10.5.x86_64.rpm Added: - Power Supplies for AD2: tracking, slider, min/max - Logic Analyzer: Measurements - Impedance Analyze: DC mode compensation - SDK VB wrapper, C# wrapper updated Fixed: - EExplorer Wavegen AM/FM index precision for sine 3.10.4 digilent.waveforms_beta_v3.10.4_64bit.exe Fixed: - decimal resolution in Export, Data and Event views 3.10.3 digilent.waveforms_beta_v3.10.3_64bit.exe digilent.waveforms_beta_v3.10.3.dmg digilent.waveforms_beta_3.10.3_amd64.deb digilent.waveforms_beta_3.10.3.x86_64.rpm Added: - UART format option (binary, decimal...) - SDK I2C without clock stretching - SDK examples: Digital_I2c_PmodAcl.py, Digital_I2c_PmodGyro.py - Spectrum Analyzer THDN measurement, THDp and THDNp in percentage units - Impedance Analyzer: - constant current, voltage, custom script for amplitude and resistance control - Option to disable mouse drag and wheel operations on plots - Impedance/Network Analyzer: averaging time - Wavegen: extended frequency option Changed: - special values (none, off) moved to end of the preset list 3.10.2 digilent.waveforms_beta_v3.10.2_64bit.exe digilent.waveforms_beta_v3.10.2_32bit.exe digilent.waveforms_beta_v3.10.2.dmg digilent.waveforms_beta_v3.10.2_mavericks.dmg digilent.waveforms_beta_3.10.2_amd64.deb digilent.waveforms_beta_3.10.2_i386.deb digilent.waveforms_beta_3.10.2.x86_64.rpm digilent.waveforms_beta_3.10.2.i686.rpm Added: - Impedance Analyzer - voltage, current and custom plots - edit Meter list - Resistance mode for Meter, Frequency DC option - step mode in Time view - Netowrk Analyzer - step mode in Time and FFT views - amplitude table and custom function Fixed: - Help minor fix - Protocol SPI and I2C Sensor rate improvement - StaticIO button lock 3.8.22 digilent.waveforms_beta_v3.8.22_64bit.exe digilent.waveforms_beta_v3.8.22_32bit.exe Added: - Impedance differential setup, W1-C1P-DUT-C1N-C2-R-GND 3.8.21 digilent.waveforms_beta_v3.8.21_64bit.exe digilent.waveforms_beta_v3.8.21_32bit.exe digilent.waveforms_beta_v3.8.21.dmg digilent.waveforms_beta_3.8.21_amd64.deb digilent.waveforms_beta_3.8.21_i386.deb digilent.waveforms_beta_3.8.21.x86_64.rpm digilent.waveforms_beta_3.8.21.i686.rpm Added: - data property for impedance/network channels. - Impedance.Resistor.reference property - instruments accessible without index in Script tool like Scope. Fixes... 3.8.20 digilent.waveforms_beta_v3.8.20_64bit.exe Added: - Logger function access to other channels value, average, min, max - Script access to Logger channel set data property, getting average, minimum, maximum Fixed: - Logger Show/Maximum - Script Protocol.I2C.Clear() function 3.8.18 digilent.waveforms_beta_v3.8.18_64bit.exe digilent.waveforms_beta_v3.8.18_32bit.exe digilent.waveforms_beta_v3.8.18.dmg Added: - Network Analyzer - logarithmic scale and percentage unit - spectrum measurements: Carrier, THD+N, THD, HD# - FFT view - Averaging option 3.8.17 digilent.waveforms_beta_v3.8.17_64bit.exe digilent.waveforms_beta_v3.8.17_32bit.exe digilent.waveforms_beta_v3.8.17.dmg digilent.waveforms_beta_3.8.17_amd64.deb digilent.waveforms_beta_3.8.17_i386.deb digilent.waveforms_beta_3.8.17.x86_64.rpm digilent.waveforms_beta_3.8.17.i686.rpm Added: - Scope - persistence support for smooth curve and min/max sampling - custom math - current value in custom math function, can be used for averaging - initialization code for integration purposes - examples - unit presets for: ohm, degree, VAC, AAC - Spectrum - Import/Export samples for Traces - trace information option - Range option to adjust all the scope input ranges - Network and Spectrum - Script support for set magnitude property - Step size and steps per decade settings - Network Analyzer - custom plots: THD, HD2, HD3 - Protocol - I2C/Spy glitch filter based on frequency setting - Device options - On Close: Run (keep running), Stop, Shutdown - USB Power: Always ON or Stop with AUX for AD2 - USB Limit: USB current limitation AD1,2 - Audio Output: AD1, 2 - WaveForms SDK FDwfParamSet/Get, FDwfDeviceParamSet/Get - DwfParamOnClose, DwfParamUsbPower, DwfParamLedBrightness, DwfParamAudioOut, DwfParamUsbLimit - Notes toolbar show/hide option - on/off icon for toggle buttons: supply enable, network analyzer reference... - show entire capture button Changed: - renewed mouse wheel, drag and key (left,right,up,down) operation on plots and axis Fixed: - EExplorer output glitch during first device connection - NI VI crash when initializing without device connected - Scope XY plot 3.8.11 digilent.waveforms_v3.8.11_64bit.exe digilent.waveforms_v3.8.11_32bit.exe digilent.waveforms_v3.8.11.dmg digilent.waveforms_3.8.11_amd64.deb digilent.waveforms_3.8.11_i386.deb digilent.waveforms_3.8.11.x86_64.rpm digilent.waveforms_3.8.11.i686.rpm Added: - Digital Discovery: - LED brightness option - Logic Analyzer - ASCII format for: Bus, SPI, I2C, I2S - Format option for I2C - Logic Analyzer and Patterns - Line Color option - Protocol - Format option for SPI and I2C: Hexadecimal, Decimal, Binary, ASCII - Plot Width option in application settings Changed: - drawing quality improvement for thicker lines - color dialog buttons renamed to Close and Reset 3.8.9 digilent.waveforms_v3.8.9_64bit.exe digilent.waveforms_v3.8.9_32bit.exe digilent.waveforms_v3.8.9.dmg digilent.waveforms_3.8.9_amd64.deb digilent.waveforms_3.8.9_i386.deb digilent.waveforms_3.8.9.x86_64.rpm digilent.waveforms_3.8.9.i686.rpm Added: - WF/Settings/Options: Locale with System or English US regional option, export and import options - SDK: FDwfParamSet/Get function - Scope: measurement resolution Fixed: - minor issues 3.8.8 digilent.waveforms_v3.8.8_64bit.exe digilent.waveforms_v3.8.8_32bit.exe digilent.waveforms_v3.8.8.dmg Added: - WF SDK: - examples updated to be Python v3 compatible - FDwfAnalogImpedance functions for impedance/network analysis - Protocol: CAN receiver filter by ID - Impedance: Export information about amplitude and offset Fixed: - WF SDK: FDwfDigitalSpi functions read MISO/RX 3.8.7 digilent.waveforms_v3.8.7_64bit.exe Fixed: - Scope: save/load of coefficients for custom Math channel filter 3.8.6 digilent.waveforms_v3.8.6_64bit.exe digilent.waveforms_3.8.6_amd64.deb Added: - Export: Wavegen and Supplies information added to Scope, Spectrum, Impedance, Network export comments Fixed: - Script Tool.exec timeout - CAN high polarity option in Protocol tool and WF SDK 3.8.5 digilent.waveforms_v3.8.5_64bit.exe Added - Script functions: getSaveFile, getOpenFile, getDirectory - Scope: multiple scales, zero offset - Notes view - Export options: notes, header as comment - Help tab: floating/undock option, find with highlight Fixed: - Impedance Analyzer frequency scale in export 3.7.22 digilent.waveforms_v3.7.22_64bit.exe digilent.waveforms_v3.7.22_32bit.exe digilent.waveforms_v3.7.22.dmg digilent.waveforms_3.7.22_amd64.deb digilent.waveforms_3.7.22_i386.deb digilent.waveforms_3.7.22.x86_64.rpm digilent.waveforms_3.7.22.i686.rpm Added - Scope/Logic View/Logging picture format - Script: - Export function for instruments - access to Protocol/UART/RX using Receiver, Receive and ReceiveArray functions, SendArray Fixed - Scope edge trigger position for all devices, when only one or two samples are above the threshold - other minor fixes 3.7.21 digilent.waveforms_v3.7.21_64bit.exe digilent.waveforms_v3.7.21_32bit.exe digilent.waveforms_3.7.21_amd64.deb digilent.waveforms_3.7.21_i386.deb digilent.waveforms_3.7.21.x86_64.rpm digilent.waveforms_3.7.21.i686.rpm Added - Wavegen dynamic configuration, adjustments without restarting the generator - SDK support for CAN bus TX, RX - more detail in Spectrum, Network and Impedance Analyzer export comments - import data orientation option Fixed - Network Analyzer Meter export and copy - Data Logger quick measurements - other fixes and optimizations 3.7.19 digilent.waveforms_v3.7.19-2_64bit.exe digilent.waveforms_v3.7.19-2_32bit.exe digilent.waveforms_v3.7.19.dmg digilent.waveforms_3.7.19-2_amd64.deb digilent.waveforms_3.7.19-2_i386.deb digilent.waveforms_3.7.19-2.x86_64.rpm digilent.waveforms_3.7.19-2.i686.rpm Added: - Logic I2S Show channel option - SDK functions for UART, SPI, I2C master and UART receiver Changed: - OS-X rollback to FTDI driver 1.2.2 Fixed: - Impedance Analyzer: save/load of views positions - other fixes and optimizations 3.7.15 digilent.waveforms_v3.7.15_64bit.exe digilent.waveforms_v3.7.15_32bit.exe Added: - Logic Analyzer: position (Nth word) option for SPI trigger on value - Impedance: Nyquist plot; settle time, minimum periods options - Wavegen, Network/Impedance Analyzer: external Amplification option - Tabbed/Docking window switching from main window Changed: - lower frequency limit for Scope, AWG, Network, Impedance Fixed: - 10ns delay in Logic Analyzer Sync and Protocol interface - Sound Card device CPU usage 3.7.14 digilent.waveforms_v3.7.14_64bit.exe digilent.waveforms_v3.7.14_32bit.exe Added: - Protocol I2C ACK/NAK last read byte option Changed: - Windows XP, Vista compatible FTDI driver in 32bit installer 3.7.13 digilent.waveforms_v3.7.13_64bit.exe digilent.waveforms_v3.7.13_32bit.exe digilent.waveforms_v3.7.13.dmg digilent.waveforms_3.7.13_amd64.deb digilent.waveforms_3.7.13_i386.deb digilent.waveforms_3.7.13.x86_64.rpm digilent.waveforms_3.7.13.i686.rpm Added: - Sound Card device of the computer can be used as Scope and Wavegen - Scope sampling clock for Electronics Explorer - Logic Analyzer data compression for recording, for Electronics Explorer - Scope and Wavegen support for 4th device configuration of Analog Discovery 1 & 2 - Scope Logging Repeat option - Scope Audio view: Stereo, Tempo options - MacOS option for application menu 3.7.12-2 digilent.waveforms_v3.7.12-2_64bit.exe Fixed: - Analog Discovery 2 configuration file descriptions 3.7.12 digilent.waveforms_v3.7.12_64bit.exe digilent.waveforms_v3.7.12_32bit.exe Added: - Scope sampling clock under time options, for Analog Discovery 1 & 2. The trigger IOs can be used as sample clock with delay and edge options. - Logic Analyzer data compression for recording, for Analog Discovery 1 & 2 Changed: - Windows installer: - embedded prerequisites: Windows Installer, Visual C++ Redistributable 9 32/64bit, 12 64bit - split installer for 32bit and 64bit WF applications, but the included WF runtime for custom applications support both architectures Fixed: - Logic Analyzer UART frame error threshold 3.7.10 digilent.waveforms_v3.7.10.exe Added: - Spectrum Analyzer Markers Fixed: - SDK Electronics Explorer enumeration - Scope Math channel unit presets 3.7.9 digilent.waveforms_v3.7.9.exe Fixing: - Logic Analyzer Event view double click for signals 3.7.8 digilent.waveforms_v3.7.8.exe Changed: - Impedance Analyzer: - view names - solid line for magnitude Fixed: - Impedance Analyzer admittance |Y| value 3.7.7 digilent.waveforms_v3.7.7.exe Added: - Scope and Logic trigger detector for trigger source Fixed: - warning message when connecting to EExplorer - Patterns trigger on Digital Discovery.
  2. 3 points
    Ciprian

    Digital Twin

    Hi @Kris Persyn, It depends on how you manage your resources, driving immersive visuals on a HDMI display can be done in multiple ways at different resolutions, some are PL taxing others are DDR taxing; you could generate entire frame buffers in PL or PS or you could find a optimal algorithm to change just the previous frame or you could allocate a high number of frame buffers and then run them in a loop. It also depends on how math lab synthesizes the IP you will need to add to your design. If you design your project properly and don't aim for a resolution higher more 720p( I'm being conservative, we managed to drive the HDMI at 1080p with processing filters without a problem) I think it should be enough for what you want to do, resource wise. My suggestion, download and install Vivado, download and install the board files, create and implement your project look at the resource consumption and then buy a board. - Ciprian
  3. 3 points
    In your constraint file, the ddc pins have lowercase "ddc_scl_io" and "ddc_sda_io". Your block design has the port in uppercase "DDC". The case must match. Try editing your constraint file to have "DDC_scl_io" and "DDC_sda_io".
  4. 3 points
    jpeyron

    pmod wifi

    Hi @harika, I believe the HTML web page error is related to the materials on the SD card. 1) Please attach a screen shot of the contents of the Sd card you are using. 2) Please follow the YouTube video here from about 6 minutes and 28 seconds on for how to set up the HTTP server project. Make sure to update the login an password for the router/modem you are using. thank you, Jon
  5. 3 points
    @thobie, the bare-metal purchase option for the Zybo was done to enable a lower price point for those who do not require the accessories. For the rest of our customers, adding the Accessory Kit is recommended during the purchase process. You are not the first and the last to complain about version compatibility. It is economically unfeasible for us to update all support projects, IP and support packages provided for free four times per year for each Vivado version. Instead we made a commitment to consider the last Vivado release in each year stable and do a once-a-year update cycle. In that regard, 2017.4 is the version we are upgrading projects to. There is a question whether OOB designs should be updated at all, or kept at the version which generated the binary image shipped with the board. The board presets are not versioned for Vivado (no version-specific releases in our git repo), because these should be forward-compatible with Vivado versions. The critical warning itself related to CK-to-DQS delays being negative appears starting with 2017.4. The negative values are due to CK trace being shorter than any of the four DQS traces. In the early days of Zynq board design negative values where listed as sub-optimal, but not erroneous. Tree topology instead of fly-by was also among the routing recommendations for DDR3 layouts. So the Zybo was designed with this sub-optimal layout due to space constraints. During Write Leveling calibration, 0 is used as an initial value instead of the negative preset delays. After calibration, if the skew is still too low, the clock is inverted. See ug585 pg 316 for more details. All Zybos shipped to customers are functionally tested and pass the DDR3 calibration process. Xilinx recommendations changed in the mean time, both in terms of routing topology and delay values. A trace of this can be found here: https://www.xilinx.com/support/answers/53039.html. The > 0ns requirement was introduced to be in line with non-Zynq MIG-based designs, where negative delays were never permitted. Since these delays are board-dependent, we would need to re-design the board to make the delay positive. This is impossible with the current form-factor. Another option would be modifying the board preset file and forcing a zero value instead of the actual delay. The tools seem to be using zero anyway for calibration. This will have to be thoroughly verified first.
  6. 3 points
    Hello, I've posted the next part in my FPGA graphics series using the Arty + VGA Pmod or Basys 3. It shows you how to make use of double buffering to animate sprites using simple Verilog. https://timetoexplore.net/blog/arty-fpga-vga-verilog-03 Feedback very welcome, Will PS. I'll add the source to GitHub shortly.
  7. 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.
  8. 3 points
    attila

    Using script with Spectrum on AD2

    Hi @tomtektest, @abzza With WaveForms Script THD and other measurement logging and plotting can be automated, like this: function doTHD(){ var rgTHD = [] var rgFreq = [] for(var idx = 1; idx <= 100; idx++){ Wavegen1.Channel1.Simple.Frequency.value = 1000*idx Wavegen1.run() // start AWG wait(0.01) // settle time for the external circuit, expressed in seconds Spectrum1.Frequency.Stop.value = 20*Wavegen1.Channel1.Simple.Frequency.value // adjust analyzer stop frequency Spectrum1.single() // start acquisition if(!Spectrum1.wait()){ // wait to finish return; } rgFreq.push(Spectrum1.Trace1.measureFreq("FF")) rgTHD.push(Spectrum1.Trace1.measure("THD")) } Wavegen1.stop() print(rgFreq, rgTHD) // print data for copy paste // draw in plot1, View / Add plot plot1.X.Units.text = "Hz" plot1.Y1.Units.text = "dBc" plot1.X.data = rgFreq plot1.Y1.data = rgTHD } doTHD();
  9. 3 points
    zygot

    Rants about FPGA tool chain(s)

    @D@n , Here's a secret; I'm whispering because this is just between you and me: At places where they do a lot of quality FPGA development work no one ever brings up a GUI for anything. All of the toolchain invocation is done using Perl and TCL/TKL. Shhhh. Don't tell anyone....
  10. 3 points
    A few reasons are... a - The introduction of logic hazards can cause glitches : https://en.wikipedia.org/wiki/Hazard_(logic) b - Routing of clocks is very complex - It is hard to ensure that the same clock edge appears all over the FPGA at almost exactly the same time. Sometimes this is achieved with 'slight of hand' (e.g. using a on-chip PLL to advance phase of the clock, so that by the time it reaches the edge of the chip is in back phase with the original signal). Low-skew paths also exist, but are restricted to small areas of the FPGA, and the clock has to be connected to the correct pin to be placed and routed correctly. c - FPGAs and their tools are designed to behave predictably under the "synchronous digital design" paradigm (something like https://hps.hs-regensburg.de/scm39115/homepage/education/courses/red/2_SynchronousDigitalCircuitDesignRules.pdf). If you work outside the paradigm you will be fighting against the tools and their assumptions. d - There is almost nothing that you are unable to code in an FPGA friendly way, but there are infinitely many ways to write FPGA-hostile code. If you want your FPGA to place nice with you, you have to play nice with it. So you can either add an RC filter to debounce you switch, or you can sample it using a reliable clock.
  11. 3 points
    D@n

    Just for fun: Frequency Resolution challenge

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

    OpenScope Mechanical STL Files

    Printed out on the Form Labs at my local TechShop.
  13. 3 points
    jpeyron

    Cmod A7 35T GPIO demo Error

    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
  14. 3 points
    D@n

    Lots of fun UART testing code

    Hello Digilent Community! I just finished putting the finishing touches on a UART demonstration project that you can find here. The project was originally intended to share a C++ class that could work with Verilator to prove that anyone's UART implementation was working. However, after I got into it, I realized the project had a lot of value that others might appreciate. As an example, consider this post by @martin16. Had he used any of the testing mechanisms listed below, he might have known which side of the RS232 port he was working with was at fault. The core contains a complete implementation of both a transmit and receive UART encoder/decoder. These can be easily taken from my project and placed within your own. (Subject, of course, to the limits of the GPL v3) The core also contains a (fairly) generic FIFO implementation. For those wondering how to implement a FIFO, you may find this valuable as well. For those who would rather interact with a serial port over a bus, such as the wishbone bus, there are two approaches within the project that can be used to hook it up to a wishbone bus. One can be used within a larger wishbone slave module, the second as a standalone module. Both are Wishbone B4 compliant, and both use the pipeline mode--allowing you to read/write multiple values on consecutive clocks from/to the controller. Of course, this only really makes sense when using the FIFO. Those might be valuable enough on their own, but you can probably find without too much additional work other implementations of the above. Therefore this project includes some even more valuable files: It includes a series of test programs/configurations that can be used to determine if the hardware on your board is working properly. If you are like me, you've struggled every time you've tried to get a serial port working on a new board. Should you connect your output to the TX or to the RX line? Do you have the UART set up properly, at the right baud rate? Can you handle more than just single values at once? How fast can you transmit/receive? To help you answer these questions, the project file contains the following test configurations: Hello World: You know, that old fashioned hello world program? I would recommend trying this program on your board after you can blink an LED at your favorite rate, or equivalently after you know that your clock works. This particular project is so simple that it depends upon only the clock input and the UART transmit output. Getting this program running on your board will demonstrate that you understand your clock, and that you can modify your I/O constraint file properly, and that you know how to connect a terminal program to your board in order to observe the results. Line Test: Once you've got a hello world program running, so that you know the output UART pin works, then it is time to test the input UART pin. This is the purpose of the line test testing program. It works by reading a line of data (either until a newline or 80--characters), and then dumping that line to the output. (Don't forget to turn off hardware flow control, and be aware of the differences between a new line and a carriage return!) SpeechFifo: Finally, there's a program that can be used to test the FIFO capabilities found within the wishbone UART peripheral. This program uses the FIFO capability to make certain the transmitter stays fully loaded for over a thousand characters of output bytes. (No, this isn't computer speech generation, but rather a computer dumping a Abraham Lincoln's Gettysburg Address across the UART port.) Each of these configurations has a corresponding Verilator simulation file associated with it, allowing you to simulate the functionality within them as part of Verilator. The project includes, like I mentioned above, a C++ class that can be used to determine if your own UART is transmitting correctly under a Verilator simuation. This class can also be used generate UART signaling in order to test if your RTL can receive it properly. (See the line test C++ harness discussed below for an example of this.) As complements to each of the testing configurations above, the project contains C++ files to drive each of those within a Verilator context. Some unique features include: The Line Test C++ test harness automatically generates a linetest.vcd file that can be used together with GTKwave to study how the core works. Further, it can be run in either an interactive or an automated mode. The Speech Test C++ test harness can be used in an automated mode, or with the -i switch in a more interactive mode. In this latter mode, the speech test program generates a speechtrace.vcd file that can be used with GTK wave to understand how the UART transmitter, FIFO, the wishbone bus decoder, or even the test harness itself. I hope you find these as valuable as I have. Please feel free to post any questions or comments you might have about this project below. Dan
  15. 3 points
    LariSan

    Birth of an OpenScope!

    We got a series of photos of the OpenScope going through the manufacturing line. Unfortunately, Kickstarter didn't allow me to load all of them onto the update.
  16. 3 points
    D@n

    Nexys 4 DDR

    @gnicholls, Wow, what a good and thorough question. You've hit the nail on the head, and you are asking something a lot of users are asking. So in answer, may I reply, Welcome to the wonderful world of FPGA design! DDR memory is hard. I mean, really hard. I tried for about two solid months to get a DDR3 memory up and running, and eventually moved on because it was taking too much time to do. You can still find the project here, though--and I still hope to return to it--eventually. Xilinx has written a variety of App notes describing how they've gone about creating their reference solution. For 7-series devices, you can find their note here--but it just doesn't tell you much. I've found the most useful information in their note from a couple generations back, found here for a Virtex-5. Bottom line: it's *really* hard--most people only use the reference solution, and then make the reference solution work for their design. I love the examples found at fpga4fun.com. They tend to work through many of the basic I/Os that FPGAs need to work with, and how to build controllers for each of them. Another useful website is Asic-World--it's just not one I've ever gotten into. Xilinx has tried to make your problem easier with their platform studio and now its Vivado replacement--allowing you to connect via point and click various different Xilinx components together to make one of many (fairly) pre-canned designs. Many of the Digilent based "tutorials" or "examples" are of this type. I personally find them wanting, for many reasons: They are "too easy"--offering you no insight for how they are accomplished internally. They are so much of a black box that you cannot examine what they did or how they did it in order to modify it, debug it, or even learn from it. It can be difficult to integrate your own work with their components. They are all focused on how to use someone else's components, but offer little in the way of teaching you how to build your own. In the end, they leave you stuck with Xilinx solutions. Any components you create/develop will only ever work with Xilinx. This leaves you forever wedded to the Xilinx platform, or forced to relearn all you have learned. Verilog (and <gasp> even VHDL) is a better language than that--capable of doing a lot more. And if that's not enough, your design that works with one version of Vivado may well break when the next one comes out because ... they changed something. (This is an ongoing problem, and a thorn in Digilent's side--suggestions are always welcome.) I have personally been trying to work to create somewhat of a solution to your problem, but I'll admit my own designs are perhaps far from the professor's materials that you are looking for. You can find many of my Verilog designs on github here. A recent design I've put together for both beginners and more experienced types alike can be found here. It contains examples of how to create a serial port, both transmitter and receiver, together with some top level designs that use such a port. As the task of figuring out which pin is which on any board is fairly common--even among experienced users, these offer examples you can work with to make sure you have your serial port working. My efforts have gone so far as to even build my own CPU, flash controller(s), SD-card controller, GPS controller, real-time clock, 7-segment controller, FFT, VGA controller, etc. I mean, why when you buy a board would you only learn to work with some of it, right? You can find a fairly complete design here, using a CMod-S6, that places a CPU onto the S6 with a minimal multi-tasking "operating system". I'm also working on a more complicated design for the Arty here--this one uses the Xilinx generated MIG DDR3 SDRAM, such as you have on your Nexys 4 DDR. This design is currently somewhat on hold, as I am trying to update the CPU within it to a more mainstream CPU that will even support the C-library. (Today's success: I managed to get newlib to compile for it! This is after updating the assembler, linker, GCC compiler backend, etc.) If you are a hard-core VHDL type, Xess.com has put together a fascinating library of VHDL routines to demo how to use their boards. To my knowledge though, the tutorial information within their libraries is ... a bit harder to follow than the simple point and click designs Xilinx peddles. One of the things I've noticed about many (most, all?) of the more complicated FPGA designs I've come across is that they all depend upon some form of internal bus by which things can be connected. Once you get past learning about how to build the simple peripherals fpga4fun wishes to teach you, you're next step is really to learn about that bus structure. Why? If for no other reason than memories seem to be best accessed via a bus, so anything using a DDR type of memory tends to send its requests over a bus. This can easily become a bottleneck to your design, but ... it sort of comes with the territory. You can build other memories and distribute them throughout your FPGA, but the amount of block RAM memory you will get within any FPGA tends to be ... never enough. Hence you are often stuck with the external memory chip(s). Xilinx uses the AXI bus protocol. You can find the specification for it here. I haven't found any good tutorials on how to use it, but there's a way you can get Vivado to generate a sample AXI-lite design that you can interface with. (I can google it if you are interested--I just don't have it at my fingertips.) I've personally used the Wishbone Bus protocol, version B4, pipelined mode. Many others use version B3. I find that I can transfer data 3x faster using B4. To get from the Wishbone Bus to a DDR memory, controlled via Xilinx's Memory Interface Generated AXI controller, I built a wishbone-AXI bridge. Others of these also exist. There's an open source package manger out there called fusesoc which was designed to facilitate composing solutions from many different FPGA components together. In particular, the OpenRISC team has put a lot of work into making sure their CPU's, peripherals, and board designs can be built using this package manager. (These tend to connect to each other via the wishbone B3 standard.) If you dig into this, you can probably find many, many examples of working peripherals for various boards--although that community does tend to focus more on the Altera boards than the Xilinx boards, and Verilog more than VHDL. So ... when I build a new design, how do I do it? For every board of Digilent's that I have bought, I start with the reference page, look up the schematic to see how the components are connected, and then google the part numbers on the schematic. Those will contain the instructions you need to access the various chips on your board. They are usually where things pick up next after you leave the canned tutorials and examples. I hope I haven't overwhelmed you, but really ... where you go next is up to you. What would you like to do? Dan P.S.: My favorite description of RTL design for those who know nothing about FPGA's is, "Infuriatingly complex in its simplicity." Everything you do will be simple--like the clock divider. But too many of these very "simple" components can become so complex that it very quickly gets under your skin.
  17. 3 points
    hamster

    Welcome!

    My name is Mike, and I've developed a bit of an obsession with FPGAs. You might be able to find some project ideas or inspiration on my WIki at http://hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects I'm always happy to talk FPGAs, so feel free to drop me an email sometime
  18. 2 points
    JColvin

    Pin Mapping for JTAG-SMT3-NC

    Hi @RussGlover, I apologize for the delay; the details you are looking are as follows: TCK - ADBUS0 TDI - ADBUS1 TDO - ADBUS2 TMS - ADBUS3 OEJTAG - ADBUS7 OESRSTN - ACBUS4 Let me know if you have any more questions. Thanks, JColvin
  19. 2 points
    The hot plug detect should be on the rx side. The source will see that and will then initiate the DDC conversation.
  20. 2 points
    attila

    AD2 over voltage :-(

    Hi @peter taylor This was a ferrite between the Analog Discovery and USB ground. Supposed to filter noise from USB cable/PC which acted as a fuse... You can solder a simple short instead this ferrite. Hopefully only this was damaged. Be careful. The devices and circuits should have the same ground. The AD ground is connected to the PC ground over the USB cable.
  21. 2 points
    Ciprian

    Zynq book - tutorial 5 Zybo Z7

    Hi @n3wbie, Th working project is attached. what you have to take in to account when using this audio codecs with Digilent products is that you need to configure the codec (using I2C) as well as receive the samples using I2S IP core. Basically one is for the control of the codec and the other one is to receive the samples. I have written a small driver for both the I2S core and the I2C SSM2603 which is in the source files of the SDK project (in the sdk folder) which configures the registers for the codec and I2S IP core; the documentation for the codec can be found here. The IP core has not yet been documented which is the main reason we have not added it to the Digilent vivado-ip library, but it needs a 100MHz input for it to be able to synthesize the 12.228 MHz MCLK and the subsequent clocks for the I2S protocol. The demo project reads the buttons and based on the ones you press it will: BTN0 - Record 1s BTN1 - Set Mic input BTN2 - Set Line In input BTN3 - Playback 1s The project is not really optimized so it uses a variable "RecSamples", allocated to the stack memory which holds the recorded samples(48000 samples representing 1s at a 48KHz sampling rate) and it is also used fro play back, so don't press play back before record. The rest should be easily traceable from the comments in the driver and the main source code. If you have any other questions feel fr to ask. Ciprian ZyboZ7Audio.zip
  22. 2 points
    JColvin

    Zedboard 3.3V Aux

    Hi @JeffL, For the Rev D version of the board, this pin (D32 on the FMC) will also be a VCC 3.3V supply, much like it is for @zygot's Rev C. From the specification for VITA 57.1, this pin is "a 3.3V auxiliary power supple available for IO Mezzanine module use and is not intended to provide primary power to the module but rather to accommodate system management functionality which might need to operate even if the onboard power conversion circuitry fails." Based on rule 5.101 though, we (Digilent) have chosen to service this pin by using the main 3.3V line. So, the short answer to your question is that the pin specifically on the Zedboard is a 3.3V source, though from my understanding this auxiliary supply should not be connected with any 3.3V primary paths on the mezzanine side. Thank you, JColvin
  23. 2 points
    Hi @dbkincaid The LED dimming option for Digital Discovery is added for next WaveForms version 3.8.11
  24. 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!
  25. 2 points
    Hi Jon, Just want to give you an update. I got it working using the PL AXI Quad SPI controller after I fixed my IO constraints. And I did contact the Avnet support you mentioned above. Here is the thread if you are interested. Again thank you very much for your help on my project. -Iris
  26. 2 points
    artvvb

    Zybo and PmodCAN

    @mbo Have you completed the Getting Started with Pmod IP Cores tutorial through to using Vivado SDK and programming your board? Your hardware looks fine. Using Pmod Header JF would be significantly more difficult than using any other header, since the MIO/EMIO pins don't use the same drivers as the AXI SPI controller that the Pmod CAN IP core wraps. The MIO pins are configured by customizing the Zynq7 Processing System block in Vivado IPI (they appear in the block design as part of the FIXED_IO interface). You can use the LoopBack.c example to make sure that your Zybo can talk to the Pmod CAN. LoopBack places the CAN controller into a mode where the controller receives it's own messages in hardware, so it is a good way of making sure that your hardware works. After that, you can program your hardware onto both Zybos, connecting each to a CAN, and connecting each of the CANs to one another. You can program one Zybo with the RX.c example and the other with the TX.c example. This set up should be able to send a packet defined in the example code from one Zybo to the other. You can demonstrate that this communication has happened by connecting both boards to serial terminals. Thanks, Arthur
  27. 2 points
    Hey @tester11, Lets clean up the history really quick because I feel like I am unclear on something still: 1) Are you using the Arty Z7-10 or the Arty Z7-20? I can provide some links to petalinux materials, but before I do that we should make sure that is the right route for you... I think this will be determined by how you want to do your Wifi, as Dan suggested above. Really, if you are locked down with the Pmod Wifi, then I actually recommend you use baremetal (no Petalinux) instead, because that wifi module only works with our bare metal TCP/IP stack (not the Linux stack). If you are OK with using a USB wifi dongle instead, then that opens you up to Petalinux. Here is a breakdown of the different experiences you will have integrating Wifi into your project if you go bare metal vs. petalinux: Petalinux Hardware: USB Wifi Dongle System setup: Medium-Hard. You have to build a linux system and load it onto an SD card. If your needs for the system are not very advanced (e.g. not a lot of third party software), this is easier. The process can be difficult if you run into problems or need to do something that is not typical. Good news is this process is well documented for the Arty Z7-20 by digilent with complete petalinux docs from Xilinx. Additional help provided on this forum. Network Software Development: Easy. You can use the third-party networking library of your choice. Basically the experience will be the same as if you wanted to write a simple networking program that worked on a Linux PC. Bare Metal Hardware: Pmod Wifi System Setup: Easy. Export to SDK, use the demos included with our Pmod Wifi IP core. Software is developed directly in Xilinx SDK and and can also be programmed/debugged on the hardware directly from this tool. Easy to generate an SD card image with your final program too that will run right when the Arty Z7 is powered on. Digilent has several tutorials for this available here: https://reference.digilentinc.com/reference/programmable-logic/arty-z7/start . You should check out the Getting started with Vivado IP Integrator and then Getting Started with Digilent Pmod IPs. Network Software Development: Medium-Hard. You will need to modify the bare-metal examples to satisfy your application requirements. If you are comfortable with bare-metal (think Arduino-like, but without all of the fancy C++ libraries) programming, this should be approachable for you. The fact that Xilinx SDK has a good integrated debugger will be helpful for you to debug this application as it is running. Based on those description, which route would you choose?
  28. 2 points
    @hassan_3md, I'm not sure why you are getting a ticking sound ... there are just too many possibilities to be dogmatic about it, sorry. What I will say is ... I've gotten ticking sounds in the past in a couple of places, and perhaps that might suggest some places to look. So, in my experience, here are some places I've gotten annoying ticking sounds: When my code starts or stops. You'll recognize this easily enough because it only happens once at the beginning (or end) of a test. Between buffers, if you don't keep the data filled. For example, if you miss a ND opportunity, or if there is any other discontinuity in your source data, you might get annoying clicks. You may also hit this problem if you are using two separate clocks--one to generate the data and the D/A clock that is reading the data. Be aware that the clicks may not show up during simulation, so you may wish to be prepared to chase them down while the design is running. I'd start by using an LED and checking, internally, whether or not you are meeting your own timing requirements. If you can succeed there, your next step will be to use that as a trigger for some type of internal scope. (Vivado calls theirs an ILA, open source options exist through) Dan
  29. 2 points
    TE_JH

    PMOD with Trenz board

    Hi, the most Bank voltages (not all) are variable on TE0720, you can select different Bank voltages on TE0701, with Jumper, see: https://wiki.trenz-electronic.de/display/PD/4+x+5+SoM+Integration+Guide https://wiki.trenz-electronic.de/display/PD/TE0701+TRM You must use the value, which is set on the bank with your PMOD IOs. br John
  30. 2 points
    Although I flaunt here with other people's feathers it seemed to me a nice topic for the forum. I love practical examples for the Analog Discovery 2. I think this mix of old school technology with modern technology is fascinating, don't you think so? If you don't want this on the forum feel free to throw it off with confidence. Greetings, Hans
  31. 2 points
    D@n

    Buttons bounce

    For all of those who have never dealt with a contact bounce, I just finished measuring the response of pushing a whole slew of buttons: those on the Arty, the CMod-S6, the PMod-Keypad, and even on an icoBoard. It was a fun project. Here's an image showing one of the responses I came across, I'm hoping to post the others soon, but I thought this was just too fun not to share, Dan
  32. 2 points
    Hello, Hoping that this might help you, I am sending you a demo application. It is a 3D Vision demo, based on VmdoCAM. Please note that this demo was not released, so it is not "polished". https://www.dropbox.com/s/zoyo4ja8cbgzv2j/3D Camera Demo Project.zip?dl=0. Good luck!
  33. 2 points
    Hi, i modified attila script slightly so that the thd values are in % and the range is in the usual audio band. Hope it could be useful for others. function doTHD(){ var rgTHD = [] var rgFreq = [] for(var idx = 20; idx <= 20000; idx+=19980/30){ Wavegen1.Channel1.Simple.Frequency.value = idx Wavegen1.run() // start AWG wait(0.01) // settle time for the external circuit, expressed in seconds Spectrum1.Frequency.Stop.value = 20*Wavegen1.Channel1.Simple.Frequency.value // adjust analyzer stopfrequency Spectrum1.single() // start acquisition if(!Spectrum1.wait()){ // wait to finish return; } rgFreq.push(Spectrum1.Trace1.measureFreq("FF")) rgTHD.push(100*Math.pow(10,Spectrum1.Trace1.measure("THD")/20)) } Wavegen1.stop() print(rgFreq, rgTHD) // print data for copy paste // draw in plot1, View / Add plot plot1.X.Units.text = "Hz" plot1.Y1.Units.text = "%" plot1.X.data = rgFreq plot1.Y1.data = rgTHD } doTHD();
  34. 2 points
    zygot

    Rants about FPGA tool chain(s)

    About 90% of my posts to the Digilent Forums have been rants, of one form or another, on the topics relative your post. No one has encouraged me to post more rants so I'll accept your invitation. I have been warned not to post particular observations on certain subjects like Xilinx IP and the board design flow by Diligent staff. As your perspective is Verilog geared I'll pass on anything Verilog specific; except to say that Verilog is more amendable to simulation... but I tend to write in VHDL. As to Xilinx IP, like Microblaze, we're getting into that danger area that I've been told not to make my opinions known. But as your ZipCPU has been made an official topic I can say this. I agree with you about using a soft CPU that you have total control over and isn't broken with Xilinx toolset version releases. I've used a Atmel-like CPU because it's compatible with a well known software toolchain. That's the key for me; a well supported, standard ( like ANSI ), software toolchain that let's me write code in C or C++. I happen to love the FPGA devices with an embedded hardware ARM core(s). They still aren't an SOC but getting closer. As of my last use of such a device the Xilinx ARM SDK is by far my favoured one. I understand that the ZipCPU is a labour of love and fully support it; just haven't wanted to use it. I find that the good old state machine works best most of the time. When those get too complicated or I need something that can be programmable on the fly ( without reconfiguring the FPGA device ) I can write a nice simple programmable controller. When the ARM makes sense, that's what I use. Just don't believe that you can easily port one FPGA/ARM from vendor to vendor. I disagree with @notarobot about his comment on job security. HDL only designs are the most portable that you can write. As to poorly written "anything" whether C, RUST, ADA, and HDL, a schematic.... the poor soul who has to turn it into something useful is indeed cursed. Any company that allows ( usually they push people into creating poor code and documentation because they are too cheap and short-sighted to understand how to develop anything ) a developer to provide it with crap deserves both the crap and the developer who may be just incompetent or looking for "job" security. I've seen everything on this subject. The main thing to say about this is: If you demand high quality and are willing to pay for it and have in house standards that must be met then you can find qualified people to provide that. If you want crap at the cheapest price, in the shortest amount of time, have no idea how to do development, consider experienced engineers as over-priced blow-hards who interfere with your way of doing things, then buying crap is a trivial pursuit and you will be well rewarded with those goals. I use FPGA devices from a number of vendors and all of them have issues with their toolsets. This is particularly true when you mix in a hard CPU core like an ARM or a in-house soft CPU core. The experienced engineer will learn to minimize the headaches and land mines buried in the toolchains. The more control that you want over your work product the more work you will have to do. But the up side is that the more work that you have to do the more you will learn and the bigger your personal IP cache will grow. Follow the easy path and you will become just someone who can use a GUI for one FPGA vendor to do a limited number of things if you have the money for their IP licenses. That's all for my first reply. PS There probably should be a special forum for this kind of topic.
  35. 2 points
    Notarobot

    PmodRS485 on Zybo

    Hi @artvvb and @jpeyron I need to tell that I have experience using rs485 for communication of industrial controllers with equipment. The most important for me is its ability to talk with several clients using two wires only. To my knowledge RTS and CTS pins are needed only for the flow control which is optional. In my recent research I've found that UART16550 can be used for making rs485 working but only between two controllers. In order to make multiple client communication a signal disabling TX should accerted after the end of each transmission. There is no other obvious way to do it but via GPIO. However, proper timing becomes a problem since this signal is not a part of AXI controlling the uart. There are some other options but facing a deadline on my project I decided to abandon rs485 and switch to CAN which is supported by Xilinx. I am going to add CAN interface breakout board to one of the Pmod ports. I've used CAN in the past as well and it is even better than rs485 in many respects. I will share results with you, and you might add PmodCAN to your store in the future. Thank you for your input I appreciate it very much Best!
  36. 2 points
    Kristoff

    Useful Links

    OpenScope MZ Getting Started Guide Resource Center Landing Page Setup Update Firmware Calibration Wifi Setup Instrument Panel Function Generator Oscilloscope GPIO and Logic Analyzer Power Supply Triggers Math and Cursors Offline Support Reference Manual WaveForms Live Getting Started Resource Center Reference Manual Digilent Agent Resource Center Digilent Instrumentation Protocol JavaScript / TypeScript Developer Guide
  37. 2 points
    Hello Digilent Community, I am now officially done with my term and I want to share what my experience was like, as per @D@n's question. I would like to attach our final report here (we got an 86 on it, so please understand that it won't be the rest report haha). It was quite rushed since my partner and I were travelling during the last few days before the turn in date and the code in the appendices are quite scuffed. Vivado won't print PDFs in color and I haven't figured out how to fix the sizing or formatting, which is really inconvenient because it looks bad and not easy to read. If anyone has any questions about the code or writing at all, please feel free to private message me or just respond on this forum by tagging me! The idea behind how we wanted it to work, what it actually became, the struggles we had, and our theory on why it did not work again are included in the report along with our VHDL files and some testbench images. If they end up being too small of pictures, just let me know and i can attach the original ones here so it's easier to see. Thank you all for your help and consideration; it means to the world to me now and it meant the world to me before while I was working on this project.
  38. 2 points
    jpeyron

    Quad SPI flas and .bin file upload

    Hi @ThomG, I found a thread on the xilinx forums here that says to program the flash using the non-project stand alone mode. I was not able to program the flash in Vivado 2017.1 using the hardware manager in the project but I was able to program the flash using the stand alone hardware manager on the main page under the tasks section. I have included a screen shot. I also included a completed project that programs the flash with the hello world and following the this tutorial. Screen shot below of tera term. hello_world.zip
  39. 2 points
    Check this out: https://github.com/Digilent/meta-manifest/wiki/Quick-start-guide#using-sdimg Basically you need to add a second partition to your SD card (use ext4 and make it at least 3.5 GB), then dd sdimg to it. The first partition should be FAT formatted and have the same download.bit, the same boot.bin, and sdroot-fitImage. You will need to rename sdroot-fitImage to fit.itb
  40. 2 points
    Kristoff

    Datalogger for two 16-bit sensors

    Hey Beleg, OpenScope uses the ADCs on the PIC32MZ which can be oversampled to provide increased resolution. Right now we're trying to stay focused on the 'general instrumentation' use case and our idea of logging will be pretty simple to start (just grab some point on demand and log them to a file, db, or similar). That being said we're already kicking around ideas for ways to get more channels at higher resolutions and we'd love to see some community firmware modifications that head in this direction. Feedback like this will help us determine what exactly we mean by 'more channels' and 'higher resolution' . Thanks! -Kristoff
  41. 2 points
    Hi Arthur, If you are going to stay with the Basys 2. Here is a link to the PmodBT2 resource page, here is a link for the PmodCDC1 and here is a link for the PmodGYRO that has an example for the Nexys 3 that shouldn't be to hard to make work with the Basys 2. Biggest change should be the ucf needs to be changed to the basys 2. cheers, Jon
  42. 2 points
    D@n

    UART

    @zahid, Yeah, ... but ... we still haven't solved your original problem--that of receiving every other letter when you pipe things directly from the GPS to your computer. But, at least now, we know some new things: We know that your computer isn't broken, neither is the serial port or terminal on it, and the cable you are using appears to be good then. We know there are no foreign character set issues, such as things that take 2 characters to print one. We know that it can successfully receive at 9600 Baud. (We're you trying with the extra stop bit, or not? So, the question now is, what happened and what can we do to fix it? Here's my thought: when you used the echo test program to read from your GPS device, we rounded the number of baud clocks downward (as the spec suggests). The result, though, was that the receiver--which calibrates its input to the start bit of each character, was receiving the characters in just a couple clocks fewer than the transmitter was using. The result, then, was that when the receiver was done with the second character -- the transmitter was still transmitting the last one. The receiver strobes the line for the transmitter to start (i_wr inside txuart.v), but the transmitter is still busy ... so it ignores the write request. By the time the next byte is received, the transmitter is now idle and ready to accept the next request. As a result, you got what you saw above: every other character received. The problem was in your FPGA code, and not within your host. Suppose we test this? If you want to go back to your echo test and try again, then try setting the i_setup register to one or two clocks faster. When I personally ran the test to echo what was received from the GPS receiver to the PC/host (I haven't posted the code for this), I switched the line speed from 9600 Baud up to 115,200 Baud or faster, such as 1MBaud. At this high speed, you wouldn't have a problem. To do this, you'd need to set the setup register on the transmitter (txuart) for 115,200 Baud and that on the receiver (rxuart) for 9600 Baud--you'd also set your PC for the 115,200 Baud. Another possibility might be to try the line testing program. This one should manage to do large strings without losing anything, but I expect it would still struggle after a long series of things were received--only to recover by the top of the next second. So, at this point, I think we know what's going on and can move forward successfully. Feel free to tell me how any of these new tests work! Dan
  43. 2 points
    There are also open source RTCC cores out there as well. Dan
  44. 2 points
    Hello, After re-building the supply , I changed the barrel connector and the board now gets powered up . Thank you JColvin sir for your reply :-)
  45. 2 points
    D@n

    XADC demo

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

    Problems FFT IP CORE v 9.0

    Wow, that really looks like a fun problem! I've always loved debugging FFT's. (No, seriously! You can find my own FFT core here.) One of the things that makes FFT's so fun to debug is that they are such black boxes. It's hard to see what's going on inside them, even when you have all the internals to them at your finger tips--such as I did. You sort of need to learn to choose good input/test waveforms (sine waves and impulses are wonderful choices), and watch what happens. Then ... you look at the output. What does the output tell you? Your two outputs above tell different stories. The first one looks like the output of a complex FFT, with a complex sine wave input. To my knowledge, the XADC doesn't produce anything complex ... are you using a real or complex FFT? The first output you have also suggests that you have something other than your sine wave going into your FFT---something that's changing slowly (together with something changing faster), but that has almost a random component to it. Then your second FFT, looking so drastically different suggests that the amplitude is doing something ... nonlinear. All of these tell you things. As a wildcard guess, did you reverse your bit order going into the core? Or are you placing values into the core (or not) when it's not ready for them? For example, the XADC can only go as fast as 1Msps, but you are running at 100MHz ... are you dealing with the non-samples appropriately? i.e., how are you handling those clocks where you don't have new valid data? Both on the input as well as the output of your core ...? While a lot of your discussion above discussed numerical precision, somehow ... I just don't think that's your problem at this point. Sorry, enough of the wild guesses. Let's move back to sound engineering principles ... I've also used the Xilinx FFT core before, and I trust that it works. If you are really worried about it, you can always use the core I mentioned above as an alternate, although ... experience and intuition suggests that Xilinx FFT will be good enough. So, let's figure out what's going on with your design. Starting at the top ... You've got at least four systems in your design above and you are testing them as a whole: 1) an external signal generator, 2) your XADC, 3) your FFT, and 4) ... whatever you are doing/using to produce and read a result. Any one or multiple of these systems may be in error. The first goal of any engineering endeavour is to split up the various blocks and prove that each works individually. There are several ways of doing this, mostly dependent upon your confidence in the other systems that form a part of your design. (Even if you have such confidence, you should be able to do these tests--I usually keep `define'd code around for this purpose, at least until I know things work.) Let's prove step #4 works. Remove steps #1-3 from your design, and place a counter into your design. Do you get a counter out? Add a portion step #2 back into your design, so that you only count up when a sample is present. Are you getting doubled or missing counter values? Replace the FFT synch signal with your own synthetically made signal. (I forget the name of this -- you know, the one that tells you that you are looking at FFT bin 0?) We're only doing this because we've removed the FFT from the design.... can you grab FFT output frames when you want them as necessary? Now, let's look at the FFT input. Can you generate a sine wave digitally, skipping the external signal generator, XADC, and FFT, and then verify that it looks like an appropriate sine wave? Can you adjust the frequency of the sine wave, the amplitude, etc., does it still look right? Make sure you test the full amplitude of your sine wave, from one bit all the way up to 16 bits. Use MATLAB/Octave or whatever, and perform FFT's of this output. Does it look good? Do histograms of the output. Are all the bits in place like they should be? Repeat (as necessary) at the speed of values coming out of your XADC--making sure you only get valid values out when you should be seeing valid values out. Incidentally, my favourite way to do this is to place individual samples into the FFT, chosen and selected by the host computer. Sure, the data rate is poor, the FFT isn't being tested at its full speed, that USB/UART interface is painfully slow, etc., but there are a lot of bugs you can work out by doing this. Indeed, when I last needed to debug an FFT, I used the USB UART to write values to an internal bus within the FPGA. Then, when the last value of any complex pair was written, I'd clock the FFT once and read the outputs using roughly the same interface. This includes reading and verifying the signaling wires too. Only at this point are you ready to test your FFT. Place this synthetic signal into your FFT. You know exactly what it is from the previous step, right? So then you know exactly what the FFT output should look like. Does it look right? If so, your FFT is working and the problem lies somewhere else in your design. Now, connect your signal generator and XADC to your output recorder, bypassing the FFT. Are you getting a sine wave out of the XADC like you are expecting? If not, its not the FFTs fault. Make certain you keep track of when values are valid, though, such as when the XADC clock is taking place, etc. If everything to this point passes, then your FFT (and indeed your whole system) should work. You do realize that the fundamental assumption in all debugging, that there is only one bug in any design, is rarely true, right? Your goal is to remove as many possible sources of error/bugs as possible to get down to the one that is giving you the hassle. I hope this helps. Let us know what you discover! Dan
  47. 2 points
    attila

    Analog discovery 2

    Hello, Yes, you can open a Wavegen and a Spectrum interface in the same WaveForms application instance and control them independently. Only one application can be connected to a device at the same time. The instruments in the device (oscilloscope, waveform generators, logic analyzer, pattern generator, power supplies, static i/o) can operate independently. The instrument interfaces in the application control one or more device instruments: - Scope: controls the oscilloscope, and the logic analyzer when digital view is enabled - Wavegen: controls one or more waveform generator channels running independently or synchronized; the power supplies of EExplorer and Analog Discovery 2 can be used as slow waveform generators - Supplies: controls the power supplies - Logic: controls the logic analyzer - StaticIO: controls the static i/o; these DIO signals are multiplexed in the device with pattern generator - Patterns: controls the pattern generator - Spectrum: controls the oscilloscope - Network: controls the oscilloscope and the selected waveform generator channel or relies on custom/external signal
  48. 2 points
    JColvin

    PMOD TMP3 on a Zybo

    Hello again, I spoke with the Pmod Product Manager and learned that for the Zybo Pmod Pack demo they ran into the same problem and just ended up using female right angle header (visual reference) they had lying around to get the Pmod TMP3 attached. She (the product manager) is going to look into getting a cable and header or something similar incorporated into the Pmod Packs (as needed per pack type). As a side note, I also learned that the new I2C style will be a 6-pin header (or 12-pin) with the I2C lines and the ground/power so that all of the I2C based Pmods can just plug into Pmod Host ports without any fuss. The function of the two extra pins will probably vary from Pmod to Pmod as necessary and how the pull-up resistors will be implemented needs to be ironed out, but I'm at least personally encouraged that oddball group of the Pmod family is being more formally accepted. Thanks, JColvin
  49. 2 points
    D@n

    XADC demo

    @Manas, Your problem lies between your top level file and your .xdc file. Basically, your top level file is trying to use pins that are not defined in your xadc file. As a result, Xilinx is finding these pins at your top level undefined, and it is causing an error when you try to build. So basically, the way to use XDC files is ... Download the master XDC file for your board from among the board support files. Comment out any pins you will not be using ('#' starts a comment, the comment continues to the end of the line) Rename any pins from your top level design file in the XDC file whose names don't match, so that the pin names do match between XDC and your top level. For the most part, you can name things in your top level to be anything you want--as long as you then match the names in the XDC file. (It is the XDC file that translates the names within your project to pins on the chip) Now, use that modified XDC file in your project. Dan
  50. 2 points
    shockmonky

    Zybo ZYNQ Beginners help

    I had the same problem and switching the "reset Processor" to "Reset entire system" worked like a charm! Love you guys at Digilent!