• Content Count

  • Joined

  • Last visited

  • Days Won


hamster last won the day on May 23 2018

hamster had the most liked content!

About hamster

  • Rank
    Overly helpful
  • Birthday 08/23/1969

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    New Zealand
  • Interests
    Electronics, FPGAs, MtBiking, Road Cycling, Linux....

Recent Profile Visitors

5315 profile views
  1. hamster

    Passing FFT result to DDS

    Once you have an idea of the frequency, you then might want to look at using a COSTAS loop to follow the frequency. You can use the frequency and phase information from the tracking loops to recover any modulated data.
  2. I've been working on my first large FPGA project in a long while, implementing DisplayPort in Verilog, using the Nexys Video as my development platform. I've got it working, and better than that I've got the standard 720p resolution working, and tomorrow I should have 1080p working too. Currently it uses 800 LUTs and 700 FFs, and 1 BRAM. If interested you can follow along or help with development at https://github.com/hamsternz/DisplayPort_Verilog
  3. You are not wrong - but for that device ID the tooling will not let you use all the LUTs present on the silicon die. It is a somewhat artificial restriction, and might have some implications for the power and thermal properties of the package (e.g. a smaller package may not be able to dissipate the heat).
  4. My suggestion would be to use one of the push-buttons as a "Store switch value in X", and another as "Store switch value in Y". You could maybe use the other buttons as "Show me X" and "Show me Y", and the center button as "Show me X*Y" - with no buttons pushed it could just show you the value of the switches.
  5. Interestingly enough I do have four different GPS modules sitting on my bench at the moment. I may just try that if I get enough spare time...
  6. I can at least offer you one answer... In a seperate test, 3,684,732,345,578 cycles of the FPGA's 100MHz clock passed over 36,848 (second intervals (a little over 10 hours). That is an average of 100,000,877 cycles per second. The distribution of counts ranged from 100,000,489 to 100,001,193, which is +/- 352 counts, which when graphed look very much like a normal distribution. 90% of counts fell between 100,000,715 and 100,001,010 If we can assume and that the start and end pulse were +/- 400 counts (4us) the maximum worst-case error will be 800 counts, which has little impact on the average frequency of 100,000,877 Hz during the time I was collecting data. I am sure that the reference signal generated by this design is very poor, it will have many terrible attributes. But I am sure that when it comes to measuring the passage of time it will be far better than the on-board crystal oscillator, which is off by around 8.77 parts per million at standard lounge conditions.
  7. I had some spare time the other night, and connected the pulse per second output of a GPS module to a BASYS3, and then worked of the world's worst GPS disciplined 1MHz source - maybe better described as 1,000,000 pulses per second, because of jitter in the output. http://hamsterworks.co.nz/mediawiki/index.php/GPSDO It would be an interesting project for somebody to rework/extend this, add CORDIC sine function and an DAC, to make a GPS referenced sine wave generator.
  8. set_value: process(btn) begin if rising_edge(btn1) then value1 <= switches; end if; end process; display: process(btn2,value1, switches) begin if btn2 = '1' then leds <= std_logic_vector(unsigned(value1)+unsigned(switches)); else leds <= switches; end if; end process; I haven't coded it and tested it, but with something like the above code should be possible to make an "add two binary numbers" calculator. It is filled with errors in form and style (e.g. using a button input as a clock), but it should be possible to get something close to what you describe working, without jumping head-first into the technicalities of synchronous design.
  9. Hi! You are welcome - notes added: http://hamsterworks.co.nz/mediawiki/index.php/Simple_AXI_Slave#Notes_from_the_Internet Answers: 1) Might be a bug - if it is, email me the fix 2) No idea - but you need to have the correct number of transfers to stop the bus form locking up. I suspect DMA might be needed. 3) "Where WRAP type is necessary? How to use PS to work in WRAP mode?" Interesting question. I assume that it is used to fill cache lines. The data at the address being requested is delivered first, then the rest of the cache line is filled. As this address range is uncached I suspect it is unused.
  10. Yes, of course. But at the time I was playing with that project was only interested in developing a working understanding of AXI. I assume there is a magical binary file that contains all the configuration bits for the PS subsystem block, that forms part of the configuration/boot image for the Zynq....
  11. 1) That is based on the address window assigned to the AXI port in the PS configuration. Look at the screen grab below the block diagram for the PS in that web page. 2) The hello Program was made in the Eclipse IDE that Vivado provides for bare-metal development. Under linux you will either need a devices driver, or using shared memory or something, or I would tend to open /dev/mem and seek and write in there for a quick hack.
  12. Yes. An AXI Slave interface would be needed to read/write to one of the BRAM ports, and the PL design can read/write to the second port on the BRAM. Another other option might be to make an AXI master, that can write into and/or read from the PS's memory., but architecting this way seems wrong. The last option would be to route some of the MIO pins into the fabric, but this gives you a very narrow, restrictive low bandwidth connection compared to a AXI slave.
  13. Hi, I haven't been around here much lately, but I saw your post and thought I had something of use to you. Here is an AXI Slave, connected to the a PL, written in only VHDL: It only decodes a few addresses, and doesn't decode the entire assigned address range. http://hamsterworks.co.nz/mediawiki/index.php/Simple_AXI_Slave Feel free to drop me an email, but it has been a while since I've had spare time to do any of this stuff....
  14. Depending on what you are after, a full FFT might not be appropriate. It also depends on your desired throughput rates (e.g. 48KS/s for audio, or 100MS/s for radio work). 'Srreaming' FFT functions are possible, where the oldest sample is removed from the calculation and the new sample added - but the data can't be 'windowed', which can be a problem. Maybe if you told.us more.about the.end result you are after?
  15. Remember to add current limiting resistors. The drive strength settings for the I/O pins are how much current can be sourced/sunk and still give valid logic voltages. Short circuit currents are much higher - 50mA or higher.