• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by hamster

  1. The AD7193 can be configured to filter at 50 Hz or 60 Hz to solve this issue. However, for this use it isn't such a big deal. The inputs are very low impedance as they are over a 1 ohm shunt, so it would take a very powerful field to make a noticeable signal.
  2. I've been working on a project and it is looking pretty nice. It is an ESP32 microcontroller, talking SPI to a PMOD AD5 that has two inputs across a 1 ohm 5W current sense resistor. At the highest ADC gains the steps are 2.5nA, but full range is about 20mA. I am currently currently running with a gain of 8, and can measure currents from a few nA through to about 300mA. Below is a graph of the startup current of another ESP32, with a spike a little after 30s when I get an image over WiFi - for now the data is just logged to a serial port at 50S/s and then I graphed in a Google Sheet. I intend to use it to test the deep-sleep performance in various modes, and to see the impact of firmware changes.
  3. 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.
  4. 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
  5. 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).
  6. 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.
  7. 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...
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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....
  13. 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.
  14. 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.
  15. 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....
  16. 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?
  17. 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.
  18. Humm.... DATA_P and DATA_N are not mirrors of each other. You might also need to delay DATA_P and DATA_N with respect to the clock signal, so it samples in the middle of the bit.
  19. I know it sounds stupid,. But sorry, that is how long it takes. There is no short cut. For example, global optimization may cause logic to get 'thrown away', and that would need to get inserted back into the design somehow.
  20. hamster

    Basys3 & Pmods as XADC

    The pins have no ability to perform ADC - they are dedicated digital I/O. You could however get an ADC PMOD module, plug that in, and use that.
  21. I think it is best to view it as a car assembly line. The quickest way to assemble a car is for each team to do their step one after each other - a car will take the combined time of all operations, but you are only building one car at a time. Fine if you a build a single Mclaren F1 race car. The quickest way to assemble lots of cars is a production line. Each team does their step, and then the car moves on to the next team for the next process. Making the first car takes (number of steps) * (length of longest step). But once you have your first car you get another car every (length of longest step). But what if mounting a motor takes five minutes, and the next longest operation takes only three minutes? You can only make one car every five minutes, and the rest of the teams are idle for at least 40% of the time. The solution might be to split mounting the engine into two steps, each taking up to three minutes. Then you can make a car every three minutes. In FPGA-speak, this is pipelining to get the highest clock speed. Big gains are easy at first, but then it gets harder and harder to get any faster, as more parts of the design become critical to the timing of the overall pipeline. The other solution might be to combine pairs of the three minute steps so no step takes longer than 5 minutes. That way you only need half the resources, yet can still produce a car every five minutes... this is the "once you meet your FPGA's timing constraints, then re-balancing the pipeline can save you resources" strategy.
  22. Oh, sorry - I forgot to answer. 2) This is a post-implementation view. So any optimizations that could be made have been made. I am guessing (and this is only guessing) that during the optimization thnigs have been pushed around. Are you displaying a full range of colours? or just a couple? The 24bit RGB seems to have been reduced to just a couple of bits. You can assign a "KEEP" attribute to the signals in the video generator block, and it should not optimize them away.
  23. 1) it is easier to explain why this is. An internal PLL had to lock on to the pixel clock. If it fails to lock (because the clock is out of range when it attempted to lock) or it becomes unlocked (e.g. the clock stops or changes frequency) it needs to be reset so it can start liocking back onto the now stable input clock again. I willwill answer (2) when I am not on my phone :-)
  24. I don't think you have to keep it consistent within a module. but it makes sense to. Conventions I have seen and use are: signals are always "downto". This makes numbers make sense - e.g. "00110000"; sig_downto <= "00110000"; assigns binary 48 sig_to <= "00110000"; assigns binary 12; Arrays are always "to". This makes initialization make sense.- the first element in the list goes into slot zero. If you do want to flip bits, this can do it for you: out_sig(0) <= in_sig(2) when rev = '1' else in_sig(0); out_sig(1) <= in_sig(1) when rev = '1' else in_sig(1); out_sig(2) <= in_sig(0) when rev = '1' else in_sig(2);
  25. I can't see what the issue is... can you describe exactly how are you expecting this to reverse the order of the bits? If your assignment into 'reverse_order_bits' does change the order, then when you assign that into 'out_sig' then that will also reverse the order. So if the output is always the input, then 'rev' (and that means 'SW[4]') also has no effect, and can be optimized out. And if the out_sig always equals in_sig, then your design does indeed contains no logic, just three connections from input pins to output pins. All seems consistent to me. Try it with explicitly reversing the order of the bits.