xc6lx45

Members
  • Content Count

    563
  • Joined

  • Last visited

  • Days Won

    33

Everything posted by xc6lx45

  1. BTW if you search a little, I posted a nasty little 1-bit DAC that should be good enough for audio experiments a while back. You can do MIDI experiments with a UART at 31 kBit with a few external resistors
  2. Hi, an FPGA can be a crazy powerful computing platform for audio but the water in the pool is very deep. If you stick to the shallow end, you're wasting 99.5 % of the potential performance. This only as something to look out for, shouldn't discourage you. The main problem is, audio sample rates are, say, 200 kHz (you will need some oversampling) while the Artix FPGA is happiest beyond 200 MHz. There is a limited number of multipliers, and direct use at audio frequencies will quickly hit the resource wall. If it gets serious, you'll do algorithm prototyping in C (or whatever) anyway, and it may come as a disappointment that even e.g. a Raspberry Pi turns out to be more powerful than the FPGA target... until you start pipelining / folding your data path. For example, I've gotten 18 000 000 000 multiplications 18x18 bit per second out of an Artix 35 T (yes, it does get a little warm...). This would be challenging on a PC CPU, less so on a graphics card. But maybe (opinion) think the trend actually goes away from FPGA to DSPs. For example, check the Axe Fx forum on tube amp modeling details - there isn't just one algorithm and configuration but many different algorithms. This is much easier on a DSP than on an FPGA. Still, one of the biggest challenges in FPGA land is to come up with a meaningful problem 🙂 and audio is not the worst place to start with. Especially if you like fixed-point math (hint: DSP48 has asymmetric multipliers - try a 25 bit data path and use the 18 bit side for coefficients etc). For simple data paths (e.g. mixing console) an FPGA might even have the lead but I didn't do any cost analysis or the like.
  3. I can shave off one more bit... ... nope
  4. 1920x1080, 60 FPS, every pixel is recalculated for each new frame. Standard Julia set with 29 iterations limit. 100 % DSP utilization on a CMOD A7 (35); 9e9 multiplications per second in 25 bits still running on USB power if getting a little warm. Probably more to come later ... stay tuned 🙂
  5. is this the board? https://reference.digilentinc.com/_media/reference/programmable-logic/zybo-z7/zybo-z7_rm.pdf JC should be high speed, yes. I haven't used that specific board but yes, I'd expect cleaner edges at 20 MHz...
  6. Hi, you'll have a hard time learning RTL on hardware only. There are situations where you can't avoid it but then a problem that should take five minutes keeps you busy for half a day. Something to avoid... Fortunately, your problem is easily handled in a simulator. Use conditional blocks `ifdef MYSIM... `endif for example on the clock divider (don't want that in simulation, or at least with a smaller division ratio), and `define "MYSIM" in your simulation testbench. You'll need some clock e.g. reg clk = 0; always begin #250 clk <= 1; #250 clk <= 0; end and want it to stop eventually e.g. initial #10000 $finish(); Put the testbench as far as possible into a separate e.g. sim.v file and `include the design that you want to use also on hardware. A quick-and-dirty way is to define your "testvectors" in the testbench (see clock generation but controlling some registers that mimic your switches). Setting up the testbench will require an hour of work the first time but that effort will pay back for itself within the next hour. I'd recommend you get "iverilog" as simulator. It writes a .vcd file that you can open in "gtkwave". Use a .bat file (assuming Windows) to run the simulation, press shift-ctrl-R in gtkwave to reload. This as a 10 line summary - you can read a lot more about simulation on the web but the above can get you quite far.
  7. Hi, most likely there are resistors in the PMOD port for protection (check the schematic). If I recall correctly, you may find one PMOD port without resistors. Other GPIOs will be fast enough for a clean square wave. BTW, it may be that your scope probe causes most of the capacitive loading that causes the damage to the edges. Try setting it to 1:10 mode (more noise on the scope but less loading to the source).
  8. Hi, hint: You'll find lots of MIDI-controlled synthesizer examples, also legacy sound chip emulations. Spend some time reading instead of re-inventing the wheel ... don't expect other people will do a good job at doing the reading for you ...
  9. reference input for said rubber duck https://web.stanford.edu/class/ee183/handouts/synchronization_pres.pdf Note the "pitfall" slide (13), possibly also slide 7 and the clear language on the last slide (maybe geared more towards an ASIC audience but still).
  10. xc6lx45

    Hello!

    Hi, just an opinion: You'll find that FPGA is an inconvenient medium for game development because the time scale (say, 16 ms for typical 60 Hz framerate) is so far off from where FPGAs are good at (say, 16 ns => a factor of 1 000 000). Bridging that gap leads either to an absurdly inefficient implementation (game logic) or towards conventional sequential programming on a softcore CPU. You can use FPGA to build the gaming platform (or emulate a legacy one). But watch out for scope creep - expect that the interesting "hobbyist" projects that you encounter have consumed ridiculous amounts of time by people who didn't learn FPGA on this project. Especially in a group, plan for the worst when it comes to motivation... One link you could check out is this, the "J1" CPU. I love it for its simplicity - doesn't mean I actually use it (might consider it if I needed a very large and very slow FSM but that would probably give me reason to not use a FPGA in the first place). This is not to kill your motivation or enthusiasm, but be aware that most likely, anything you come up with on an FPGA will be blown out of the water by a first-generation Raspberry PI (the above factor of 1e6 is the main reason). What I'd do is find a project that is better suited for FPGA. One idea is to program "game of life" in a full parallel ("systolic") implementation to run at MHz frequencies. Use FFs for the game state. You can use BRAMs to take periodic snapshots of the game state, then clock it out at VGA pixel frequency to show as image on a monitor. One way to do the copying from game state to BRAM is to combine rows into ring shift registers, then do one cyclic shift of the game matrix for every update of the monitor picture (trying to come up with something that utilizes the FPGA efficiently. Obviously, this can be simplified at the expense of performance in terms of evolutions / second). The same shift register connectivity can also be used to load an initial state into the game e.g. from a UART interface. Another thought would be to abandon the game idea and do something more FPGA-ish. For example, you should be able to implement lowest-level BASE10 Ethernet. I think it needs some external hardware (a scavenged socket with magnetics might be enough) but the topic has not been hacked-to-death yet like most others. You'll find a proof-of-concept design on fpga4fun.
  11. >> However as the AD2 has a 14 bit digitizer, the quantization noise floor limits the measurable THD floor and will create similar harmonic artifacts. Not sure if I'd sign that. When the used number of bits gets very low, quantization noise correlates with the signal, creating harmonic-like artifacts and I might inject dithering to decorrelate it. But with 14 bits and a reasonably set level, the quantization noise is white across the bandwidth, uncorrelated with the signal, uniform amplitude PDF. Good luck with DSP magic ...
  12. Nice that it works. >> I could probe straight on the ground clip and still see the noise. The first thought would be a separate analog ground but I suspect that's hard with a 2-layer board. >> and uses electrolytic caps (because that is what audio nerds are supposed to use!) Note, there are abysmally bad electrolytic caps out there. Check the data sheet (frequency response, ESR). Also they exhibit electro-chemical effects (the oxide layer changes thickness with voltage), causing low frequency noise. Not sure if I'd use them anywhere near a signal path. You could try to set a "SLEW=QUIET" constraint for digital outputs (might be worth a try even if it shows mostly in the MHz range)
  13. Hi, just wondering, could you simply use a mains transformer with an iron core, e.g. for toy railroad or the like (just remembering this as example that uses AC output without rectifier)? It's not exactly a precision measurement, but the secondary site is properly isolated, making it fairly safe to work with.
  14. Hint, you can use a Zynq like an Artix, just disregard the ARM processor and integrate a UART on the FPGA fabric. As the board's built-in serial-to-USB connection is most likely hard-wired to the PS, you'll need an external serial-to-USB (e.g. "FTDI") board. Zynq is a difficult platform for a start from square one. the above-mentioned UART wiring being one of the first snags to run into. The regular FPGA e.g. on the CMOD A7 module is more friendly. Note that the simplicity of the Lattice board you mentioned comes from a heavy layer of code on both PC and FPGA side (bootloader). It's not necessarily a bad thing but be aware that it just postpones hitting the learning curve to the time when you need to leave the well-trodden paths. And then, things get messy (as compared to plain ol' "industry standard" JTAG connectivity).
  15. Some random thoughts: - I don't see why you'd use an FPGA in the first place. From a marketing point-of-view, an industrial-grade Zynq may be the perfect platform, but the learning effort is much higher than for a run-of-the-mill microcontroller. - if you have no or only superficial FPGA design experience, don't use an FPGA. If you can't decide, pick any rubber duck of your choice and explain it the concept of metastability in a few sentences. Is your explanation concise and rock-solid? If not, don't consider FPGA. If you have gaps in your understanding (e.g. the design is missing constraints), every synthesis round gives you a new roll of the dice for possible failures. - taking a shot in the dark: The most likely point of failure of any board you pick from this site is USB connectivity (probably does not matter). The next one is the voltage regulators. You can probably manage this risk (your design is unlikely to need much power in the first place, confirm by measurement and check that the FPGA runs cool). Still, looking at (expensive) industrial FPGA modules, the regulators take a lot of board space, for a reason. - if I had to pick a module from my own experience, I'd look at LPC1768 "MBED". It is very old still not exactly cheap, manufactured in large quantities and I'd guess they have ironed out the bugs by now (on-board Ethernet, just connect a socket with magnetics).
  16. xc6lx45

    Advanced topics

    one recommendation, but check out whether it works for you: Keshab K. Parhi "VLSI Digital Signal Processing Systems: Design and Implementation" It's a very old (pre-FPGA) book, but it'll be as relevant in 20 years since the theory does not change. You can find a condensed version in the lecture slides. Pick what appears interesting: https://www.win.tue.nl/~wsinmak/Education/2IN35/Parhi/ ------- Reading through the Xilinx documentation might be a good idea. There are those people who read manuals and those who don't. Usually it's easy to tell the difference... I'd skim quickly over parts that don't seem relevant at the moment (which may be 99 %, definitely too much material to read cover-to-cover) and spend time with those parts that seem interesting or immediately relevant. ------------ For a practical example regarding timing, speed optimization, critical path, you can try this simple project: implement a pseudorandom sequence (e.g. 9 or 24 bits) and compare against a same-size number that is an input to the block (not hardcoded, e.g. set by switches). This is a simple AD-converter and you can test with a LED that it works. Then try to run at as high clock speed as you can manage e.g. 300 or 400 MHz. Understand all the warnings, fix those that are relevant (some are not but you should understand why), especially the ones related to inputs ("switches") and outputs ("LED").
  17. xc6lx45

    I bricked my CMOD-A7

    You might try to take an old USB cable and put an amperemeter into the 5V wire. I suspect you'll observe that current consumption starts around 80 mA (the FTDI chip waking up) then dropping much lower when the FTDI chip shuts down. I've seen this pattern on other designs when there are issues with USB / power supply. Most likely it has nothing to do with Flash. Hypothetically, I could flash a design that draws more current than USB can provide, and would cause the FTDI chip to run out of juice and shut down. Maybe the PROG_DONE LED goes on for such a short time that the eye does not notice. In this case, the paper clip trick should be sufficient to bypass Flash boot once. And as mentioned above, you can access the boot mode pins, e.g. solder a wire to the FPGA end of the resistor.
  18. xc6lx45

    Offline Installer

    I might chime in with an opinion here: This problem will generally become more severe in the future now that Windows 7 is EOL and obviously unsafe: There is a big number of (pre)-Windows 7 based embedded machines etc out there that came with a 6- or 7 digit price tag and must be isolated from the web nowadays. I am personally aware of one large vendor who is totally oblivious to this problem (e.g. trying to stream a welcome video with their driver installation and failing, relying on 256-bit encryption which is not included in Vanilla Windows 7 as found on a recovery partition) and it has cost them dearly. In a trade fair or marketing presentation, everything is new and shiny but dinosaurs walk the factory floors... which is BTW the reason why GPIB needs so heavy cables 🙂
  19. xc6lx45

    I bricked my CMOD-A7

    Thinking aloud: Is it even possible to "brick" an Artix from Flash? On Zynq it is if the FSBL breaks JTAG, and the solution to the problem without boot mode jumpers is to short one of the flash pins to GND via a paper-clip at power-up. But on Artix? Can't remember having seen such a thing. Through EFUSE, yes, but that's a different story. If you like, you can try this if it's a 35T (use ADC capture at 700 k, it stresses the JTAG port to capacity). For example, it might give an FTDI error. Or if it works, you know that JTAG is OK.
  20. So you have working fixed point RTL (sounds like quite an achievement BTW) and want to hook it up to the Microblaze. I'd look for info how to implement an AXI lite slave. Vivado has several built-in options to help with that - not necessarily the best way, depending who you ask, but it did work for me. For example "Tools / Create and package new IP / create a new AXI4 peripheral". Finish the wizard, then take the Verilog file with its implemented dummy registers and continue editing it by hand. My first step would be - plain registers for input data - a write-sensitive registers for the final input data word or a dedicated "control / start" word that resets/starts the processing state machine and clears an "output-is-valid" bit - a register for the first result that blocks on read for "output-is-valid" from the state machine - plain read-only registers for the remaining output data The control flow of the program is simply "write data, read results, repeat". I'd sell this as "minimum-size approach"... It can be improved in many ways (e.g. output-side FIFO, input-side FIFO, pipelined processing in RTL, full AXI / stream, ...) depending on your specific requirements e.g. throughput, bus utilization, avoid blocking the CPU.
  21. xc6lx45

    Verilog Simulator

    >> student/beginners try to use these non-synthesizable constructs to generate "programs" rather than "designs". Students, beginners and most of industry for testbenches, making pitiful noises from the pain but using it nonetheless. Yes, Verilog is horrible and could be improved in oh-so-many ways, like most successful languages engineers use to get their work done before the deadline (perl, Matlab, C, Excel / Visual Basic, ...). I think you are driving a methodology that is very different from typical industrial use (where designers must deal with a large number of simple problems instead of working on a single hard one for weeks and months). Maybe you should add a disclaimer, like "warning: following this to the letter may make you look really stupid in a non-academic job interview".
  22. xc6lx45

    Verilog Simulator

    As a 2nd opinion, I would not recommend Verilator to learn the language. It does work on Windows (MSYS) but I'd ask for a good reason why you need Verilator in the first place instead of a conventional simulator. Have a look at iverilog / gtkwave: http://iverilog.icarus.com/ It works fine from standard Windows (no need to create a virtual machine). You'd call it through the command line though (hint: create a .bat file with the simulation commands to keep them together with the project. Hint, the abovementioned MSYS environment is pretty good for this, e.g. use a makefile or shell script).
  23. xc3sprog works for flashing with minor modifications e.g. IDCODE. I have used it on Artix. Setting up the compile environment is quite a bit of work, though. If that helps: for uploading to volatile memory (until the next power cycle), I've got source code here.
  24. xc6lx45

    Large Spectrum Generation

    (OT) A curiosity, I've tried to use it for PWM once but the DC average observed on the brightness of a LED seemed to depend on the bit position. Has anybody made similar observations?
  25. xc6lx45

    Large Spectrum Generation

    Hi, there are two important corner cases with regard to the power you're outputting: - slow sweep (wobble / FM): the signal is continuous-wave, its peak-to-average is as low as physically possible. This will output the highest power within a given amplitude limit and (oversimplified) optimally use the dynamic range of the signal chain. - single pulse: use a sample stream ... 0 0 0 1 0 0 0... (which has constant spectrum) or use the impulse response of a suitable bandpass filter. This results in the shortest possible signal within the limitations of the time-bandwidth product (see e.g. "band-limited pulse" on Wikipedia) but the signal has a high (bad) peak-to-average ratio, thus (oversimplified) requiring higher dynamic range in the signal chain. Examples for the two methods are a conventional RF vector network analyzer (continuous wave, at least traditionally) and pulse-based time domain reflectometry, e.g. Teledyne LeCroy Sparq instruments. What can work well is to use a bandpass-filtered (pseudo)random sample stream, possibly with additional clipping / filtering rounds to improve PAR. But at the end of the day, it depends on what statistics of the signal matter how much in your application, e.g. autocorrelation, amplitude PDF, actual spectrum shape. Matlab (Octave) would be my tool of choice for algorithm design, not RTL