Go Down

Topic: Vidor as lab instrument (Read 418 times) previous topic - next topic

DarioPennisi

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!

sexiewasd

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.

a2retro

#2
Jul 28, 2018, 02:49 pm Last Edit: Jul 28, 2018, 03:23 pm by a2retro
Hi Dario, great topic.


My main LA tool is the (closed source) Intronix Logicport LA1034 logic analyzer. I also have a Open Bench Logic Sniffer (http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer)  and a Xess Logic Pod (http://www.xess.com/shop/product/logicpod/) 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)


DarioPennisi

Hi Glen,
Simply capturing and reviewing pin states is trivial. This is something we can likely put together quite soon.

For analog capture you'll need to wait we do an adc shield. btw would be interesting to hear which sample rates you're looking at..

sexiewasd

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.

Tubical

Hi Dario and all,

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...

Cheers,
TC

cfsterpka

#6
Aug 08, 2018, 02:53 pm Last Edit: Aug 08, 2018, 04:06 pm by cfsterpka
Hi Dario,

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!

blackt1ger

Yes.  Capturing pins should be very easy.  

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 (https://github.com/ZipCPU/wbscope).  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.

--Ken

DarioPennisi

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.

Go Up