Hi guys,
i'm starting this thread to collect ideas and proposals on a FPGA image to create a powerful lab tool.
the idea is to implement a logic analyzer, pattern generator and eventually oscilloscope/waveform generator adding external hardware.
i got a suggestion to be compatible with sigrok (https://sigrok.org/) and that for sure is going to happen.
main idea is we could sample pins at high speed, store data in SDRAM and then download it slowly through USB via SAMD21. of course the opposite could be done to generate signals or exercise busses.
think of it as an open window to whatever hardware you're developing or a quick way to test new devices or inject commands to existing boards...
think for example about being able to pick up I2S signals and translating them to analog, monitor I2C transactions capturing not only protocol but also timing and stuff like that...
please suggest what your wildest dreams are and we'll try to make it happen!
I want to be able to capture and analyze automotive ignition waveforms. Capturing requires protecting the vidor from high voltage spikes (200v) or so, but the really interesting bit is in the analysis.
Reading ignition waveforms is a bit of a dark art right now. It’s used to find misfires, and that part is fairly easy, you pick out the waveform that doesn’t look like the rest, but inferring why there is a misfire is much much more difficult. My goal is to have the vidor do the analysis. It could tell a technician if a misfire is caused by a rich or lean condition, a compression or timing issue, an issue with the ignition, even separating if the problem is a coil, sparkplug, or driver, and which cylinders are effected when, and combined with can obdii functionality under what conditions the misfires occure. On many cars it would require probing one fuse, plugging in the obd connector and taking the vehicle for a drive.
A ton of money is wasted by poorly trained technicians thowing new parts at misfires and drivability problems based on statistics, and that’s a problem I want to help solve.
My main LA tool is the (closed source) Intronix Logicport LA1034 logic analyzer. I also have a Open Bench Logic Sniffer (Open Bench Logic Sniffer - DP) and a Xess Logic Pod (Logic-Pod | XESS Corp.) both open source.
Having an addon option for the Vidor would be most welcome as well.
I think this is also an opportunity to use the Vidor built in wifi as a channel back to the display device (tablet or laptop/PC) in addition to a USB connection.
What I would really like to see is some kind of easily configurable IP block that would let you nicelly monitor the internal state of all the FPGA pins. It seems to me that the FPGA vendors hold you hostage to expensive internal debugging solutions. Edit: Actually it looks like Xilinx Chipscope Pro for example is bundled with ISE and not an extra charge anymore)
For my analog uses I think that a image best describes my needs. Two things in the image are important. First the kv scale is interpreted the signal is never actually in the kv range. The secondary side of the circuit is around 10-20kv, but measurments are taken either with a grounded inductive pickup, or directly on the primary side of the coil and on a good spark is around 60-65v on the peak, and can be 150ish volts on a bad ignition event.
The second thing to note is that it is important to measure the height of the voltage spike which can happen very quickly.
Picoscopes are a popular choice in the automotive field and make do with 20Mhz per channel.
i would suggest you to deliver some basic I/O shields first, let it be for audio, video and a general purpose (RF) flavor and see what the userbase will do with them.
Because we also need some FPGA IP-blocks to work with.
I know it´s not easy to develop something without knowing what the users want.
But it´s nice to have something basic to start with. Even a single channel audio input/output hardware would help to start with something.
The IP-blocks will do the work, and since it´s all parallel (as long as the FPGA can handle it) we simply could mix any poly stuff down to that single output (for creating audio-synthesis stuff)
All it´s need in order to do this is coefficients, multiplier, adders and something to store samples (RAM)
If the code works, it usually can be made polyphonic and/or routed to a multichannel I/O if these are available in the future...
Excellent question - I think the number one thing that would make this an awesome lab platform is an easy to use and well documented bus interconnect to send data back and forth from FPGA to the NINA chip, SAMD21, and of course the RAM. In addition to this having the ability to easily interface custom logic to the bus through verilog or other means.
Second to this I would say is the ability to read and write data from the FPGA directly to an SD card through SDSPI, but other crazy ideas are high speed ADC sampling from the FPGA, a basic FFT block, an open soft core processor block like openRISC or zipCPU, basic counters, and generic blocks for all the common serial protocols: SPI, UART, I2C...
That would make this an amazing platform and instantly useful for a lot of projects
Best,
-Chris
P.S. This is an amazing platform and I am very excited to see it evolve!
First, as mentioned before the OLS (dangerous prototypes) is an Open-Source IP Core (search demon-core). And ZipCPU has an open source wishbone based scope (GitHub - ZipCPU/wbscope: A wishbone controlled scope for FPGA's). Combining the two could give you very nice triggers, all configurable on a wishbone bus.
This is sort of what I would like to do. I want to test Verilog IP Cores on a clean environment. I can push the core into the FPGA and I can validate the results from the SAMD. Better than ModelSim….. When I know it works, I can then move the core to something more difficult to test and debug.
Hi Ken,
Thank you for your message. Actually unless your religion prevents you to use closed source tools, quartus, like any other tools has an integrated Logic analyzer that allows also displaying "analog' values. This will offline course work well for your purpose of checking new cores functionality but less for the purpose i'm discussing here.
Signaltap, along with sources and probes are quartus features you Will be able to use as soon as we'll be allowed to release the USB Blaster emulator.
main idea is we could sample pins at high speed, store data in SDRAM and then download it slowly through USB via SAMD21
I need an adc solution with up to 16Bit at a samplerate of 1 MHz minimum. Will it be possible to realize this with this new board without a new extension board?
Or: How fast can 16Bit (parallel Data from external adc-Board) can be catured and stored in SDRAM with this new board.
Hi,
Fpga can store data at any dynamic range in internal memory at around 150-200 mhz. Frequency depends on logic complexity, depth depends on width but consider fpga has around 52 kbyte of ram and some should be used for mailbox communication to arm.
If using sdram you have a theoretical bandwidth of around 140 mhz at 16 bits but you will have some hard time closing timings and you have to consider latency. A more realistic figure would be something close to 80/90 msample/sec at 16 bit.
Right now we can't acquire analog signals without an external ADC however there are some samples around on how to create a signal Delta ADC using lvds pins...
performing an FFT on board and/or do some further processing on a cpu
based on the data, i would like to kinda feedback control (PID) the output of some DAC´s.
This would be handy for (fast) real time process-controlling (chemistry).
other things which would be awesome:
An Impedance analyzer in the range up to 1 MHz. I am still looking for an open source device which could handle that frequency range, with a good precision.
A Digital Lock in Amplifier. Haven´t seen an open source lock digital lock in amplifier anywhere.
A few things that would be of interest to me and I'm sure others:
A polled I2C block that takes a slave address, data address, byte count, and clock divider and fills a looping buffer with data values that can be read by RAM
A block that connects to a common IMU, performs filtering (low pass, kalman, etc) to give clean and accurate position, velocity, and acceleration data.
A block that connects to a brushless motor controller (ESC) and an optional encoder to allow you to do fine-grained motor control.
A block that calculates PWM duty cycles for complex curves (splines, cubics, sinusoids, FM modulation) for motion or waveform synthesis.
A block that interfaces with a common PLL chip to allow you to set and maintain a stable clock.
An always-running G-code interpreter to free up CPU time (the CNC nerd in me is strong).
FFT, windowed average, PID, and other filter/control blocks (floating point maybe????)
Has this project moved to a development stage? I have a function generator use case that could benefit from the timing accuracy of the FPGA. I'm measuring 3.3us of jitter using the tone() method implemented on the SAMD21. It looks like the ATmega328 has 9.27us of jitter. I have to believe an FPGA implementation would bring these jitter values down further.
