Announce: LabToy 0v1 (CMOD A7 35T board)

[xc6lx45]

An FPGA can be a useful "swiss army knife", but all the nice features aren't easily accessible.

Enter "LabToy": A batteries-included collection of utilities, just double-click and go.
As the name implies, this isn't meant to compete against "real" test equipment. The main selling point is like a pocket knife - this fits into a shirt pocket and the power tools don't. And speaking of "selling points", it's free to use.

So what do we have here:
- Digital data: Shows the input state of all pins
- Analog data: Readings from the two ADCs, up to about 700 ksps sustained (XADC "simultaneous sampling" mode, phase-accurate between channels)
- Streaming data logger: Both analog and digital data can be written to a .vcd file, to be shown in gtkwave. There is no limit to the capture length.
- Analog signal generator: 8 fully independent channels, sine, square wave, the usual suspects. Well, the DACs won't win any audiophile awards, but they are usable.
- "Programmable" digital LED mode: Configurable pulse width to suppress short glitches, or edge detect with a built-in pulse generator to highlight them.
- Analog LED mode: Shows the input value of the ADC in real time

Some screenshots:
1k sine / cosine from DAC jumpered to ADC (in gtkwave)
The digital signal is the generator's sync output that can be recorded as a digital input.

Realtime display of the inputs.
With pocket knives in mind ("this button will unlock the large blade, allowing it to be manually returned to its folded position") I decided to keep the screen uncluttered and put descriptions into tooltips.
The large displays are the average voltage readings from the ADC. The smaller ones show the digital inputs in groups of four.

Generator controls (frequency, minimum voltage, maximum voltage, phase).
The voltage scaling is a bit unusual (typically there is "AC magnitude" and "DC offset") but I chose this approach because it shows clearly the limitations of the 0..3.3V output range.
Most people will probably leave all this at the default values for a full-scale signal.

Data capture

Example: The output in gtkwave after I touched a jumper cable to the digital inputs on the DIL connector.
+++ DO NOT USE THE +5V OUTPUT P24 FOR THIS KIND OF TEST +++ (3.3 V is available on the PMOD connector, bottom row)
The red "undefined" marks flag the first input in an 8-bit group. In this example, they aren't too meaningful, but they can alert me to the fact that no data events have been observed yet.

LED control

The two numbers give the number of consecutive 1 or 0 samples (at 125 MHz) before a signal change is propagated to the LED.
E.g. put 125 million there and it'll take one second after changing the input state for the LED to light / go dark.
Those can be used interactively  to study an unknown signal.

• "Level": no further processing ("level" mode and 1 / 1 sample counts is equivalent to directly connecting the LED to the physical input)
• "Edge" mode generates a brief pulse on signal changes, the LED is dark otherwise.
• "Invert" flips the input right next to the pin (0 becomes 1, black becomes white and man gets himself killed on the next zebra crossing -DA).

How to get it:
The file is attached:
labToy0v1_beta.exe
The installer unpacks a single .exe.

Happy hacking!

Requirements:

• Windows 64 bit (!)
• .NET 4.5
• FTDI libraries
• CMOD A7 35 T (not 15 T).

Warnings:
Direct access to digital IO pins is an inherently dangerous activity.
"PROVIDED WITHOUT WARRANTY OF ANY KIND" means Just That.
And beware of the +5V pin.

PS:

If you try it, kindly let me know whether it works, or what goes wrong.

[D@n]

@xc6lx45,

Hey, that looks pretty cool!  Thanks for sharing,

Dan

[xc6lx45]

... a quick update 0v2:

• fixed the list of digital LED-mode inputs (the higher pins had slipped)
• increased the logic analyzer FIFO to 2048 frames (previously 256) => can handle longer bursts of data before dropout
• the digital LED status is logged in a .vcd data dump as digital signals
   

 

labToy0v2_beta.exe

[JColvin]

Sweet! That's a fun way to try out different resources on the Cmod A7.

I also wanted to point out in the interest of being a friendly forum user and wanting to make sure other users reading this thread are aware of other additional resources as well if they were so interested, @zygot also has a similar demo project that tests the resources on the Cmod A7 to verify they are all working as they should in this thread.

Thanks,
JColvin

[zygot]

@xc6lx45,

I like the "alternate" demo. I probably won't try it because I'm risk-averse to running .exe demos ( that's just (probably) me ). Looks like an interesting project though. For the record I haven't figured out this free added value deal either. But I do encourage all participation. Well, that's my 2 (copper free) cents

[xc6lx45]

Hi,

we may have a misunderstanding here: This is the full-featured project, not a "demo".

For a "free added value deal" (and where did this come from?) I suspect you know as much as I do

 

 

 

[JColvin]

"Demo" was probably my fault for using that particular descriptor and then it just happened to be reused in the next post. I think @zygot's comment on free added was referencing that you had free as a "selling point" (quotations included). Is it possible to "sell" a free product in the first place and is that supposed to make sense? Just my guess though

[zygot]

On 2/4/2018 at 6:52 AM, xc6lx45 said:

The installer unpacks a single .exe.

My comments about your project was based on this statement.

As to "free added value deal" ( I understand your confusion as I and possibly D@n are the only ones who understand what I meant to say ) I was referring to posting uncompensated content that involves time and effort but becomes "added value" to a third party. Again, this comment was in the context of the idea that you were posting nothing but an executable application. Simply trying to answer Digilent customer questions is also a form of uncompensated work but less time consuming. This is how user forums work and there isn't any subterfuge involved so I'm not complaining.

 

[xc6lx45]

OK I think I understand the point.

It's mainly a testcase for my own framework, has evolved some life of its own... OK sometimes it just feels good to do something useful (well, potentially hypothetically useful or whatever as long as it's not powerpoint slides...)

The GUI stuff is the fun part, but the real work is in the FTDI-MPSSE USB engine beneath, 125 us round-trip time... I can turn that into a DLL or an application-specific command line utility within a couple of minutes, with any number of independent FIFOs to custom RTL via copy-and-paste.

[zygot]

4 hours ago, xc6lx45 said:

OK sometimes it just feels good to do something useful

You never know when a random project idea might evolve into something more interesting, and perhaps become a spark in another person's imagination ( if you post your work somewhere...). In my experience not many people try these project and respond with critiques or suggestions... so you may not get the pleasure of knowing about where those spark have landed. My main point is that expanding people's perspective is generally a very good enterprise, so thanks.

I like the idea of doing your own development using FTDI drivers... I've done so as well. As it's possible to brick these chips it might be prudent to use a cheap module external to the FPGA board but if you know what you're doing and are careful then things are good. At least I haven't destroyed anything yet.

One point of feedback. I haven't embraced Windows 10 as a real OS so my Microsoft development projects are limited. I might be ( probably am ) an outlier in this regard. None of my WIN7 boxes ever get to see the internet any more though I do still use them for hardware/FPGA development. A demo project with GUI bells and whistles might have a broader audience if it weren't OS specific. (Yeah I do have a pretty good idea what this might involve...)

 

[xc6lx45]

I'll see whether I can get this compiled as MSIL instead of x64.

[zygot]

@xc6lx45,

I'm just thinking out loud.... but getting your data into/out of OCTAVE or SCILAB would be pretty cool..... that would cover a few OS possibilities....

I'm going to get over my qualms and try it out so that I can at least provide useful feedback.

 

[zygot]

@xc6lx45,

OK. Ran the installer. So it does end up with a single executable file. Not my idea of a "full featured project" but none the less here's my first thoughts.

A teensy bit of documentation might be nice, say in an README ascii text format. You can look through one of my projects in this same forum to get an idea of what I'd like to see. What are the requirements? What does the demo do? How do you use it? What do I need to know to avoid damaging anything? I realize that you have some of this information in the thread but why would I want to go online to see that?

[zygot]

@xc6lx45

Now, I did run the demo successfully. This is certainly a slick demonstration of your GUI skills. Very nice. The pop up help is very nice. I still don't find the interface clear as far as what pins your channels refer to though I did figure out that PMOD pin 1 is channel 1 of your waveform generator. Clearly you are PWMing the output pins so on an oscilloscope the sine and ramp waveforms are a bit "hairy". Also the waveform generator pins make a nice interference generator for my FM radio... I can select a ramp to hiss out the content that doesn't appeal to me ( NPR was currently what I was tuned into; 89.5 ). Bet you didn't intend that as a feature.

I understand what it is that you've done and it is indeed impressive. But what do I do with it except verify that my CMOD-A7 is functional? I guess that this is where my idea of what a "full featured project" comes into play. Still Kudos!

[xc6lx45]

OK, I recompiled it, shouldn't require 64-bit now. Attached.
There is a tooltip for the generator output pin and its location if I hover over the checkbox to enable the generator.

More documentation, maybe later. Rome wasn't built in a day.

Now the DACs: You may be surprised but it was designed in on purpose (not as a FM radio jammer). The keyword is "noise shaping".

With single-bit outputs I have no other option than PWM (one-bit quantization). That's incredibly noisy and there's nothing I can do about the total noise. What I can do is move most of it to higher frequencies. A sigma-delta converter would do that smoothly but there are reasons why they don't work too well in this application (rail-to-rail output, idle tones for DC-ish signals).
I'm clocking the DACs at 250 MHz, with a four-bit deterministic PWM reference and the other bits pseudorandom => noise spikes at n*15.6 MHz.
I guess you're listening to the 6th harmonic of 250/16 MHz. Have to admit I didn't even simulate this. Just tried in hardware, and it worked well enough (the sigma-deltas didn't).

The "take-no-prisoners" approach to output drivers (LVTTL, 24 mA, fast slew rate) might also play a role in its efficiency as interference generator... I might take the thing to the shielded room at work just for laughs. Hope the radiated emissions don't burn the expensive EMI scanner... If in doubt, use a capacitor to ground as lowpass filter. The PMOD outputs already provide the series resistor.

BTW, the purpose is a "swiss army knife" style electronics application. It'll generate a test tone for a guitar amp, measure what happens to the bias voltages (use appropriate series resistors with the ADC..) and even spit out 440.0 Hz to tune the guitar. It's not meant to self test or "demo" the FPGA / board, that's out of scope.

   
 

 

labToy0v2_MSIL_beta.exe

[zygot]

5 hours ago, xc6lx45 said:

I'm clocking the DACs at 250 MHz, with a four-bit deterministic PWM reference and the other bits pseudorandom

Well I have to commend your creativity ( should I add chutzpah? ). I guess that I'd not try using digital outputs pins as psuedo DACs or presenting them as such. Have you looked at these outputs on a good oscilloscope? Admittedly I tend to be picky about claims as to what my work does. I mention this in the context of the following statements:

5 hours ago, xc6lx45 said:

purpose is a "swiss army knife" style electronics application.

 

5 hours ago, xc6lx45 said:

It's not meant to self test or "demo" the FPGA / board

Of course your choice of FPGA board as a platform might not optimal for such an application. None of these comments takes anything away from the general effort. Don't take this as a snarky comment but... one way to turn your "wiss army knife" into a "Swiss Army Knife" would be to use external resistor networks to create a few DAC channels a la the tried and true Digilent VGA display driver. I don't think that anyone would fault you for offering a better tool even if it does require a bit of "user assembly". 

[zygot]

5 hours ago, xc6lx45 said:

The "take-no-prisoners" approach to output drivers (LVTTL, 24 mA, fast slew rate) might also play a role in its efficiency as interference generator

Likely having improperly terminated IO drivers ( I'm including the PCB traces and connector pins ) is a bigger contributor to the noise or what you refer to as "noise shaping". I'm taking your comments as having had spent some time in an EMC chamber trying to pass FCC regulations.

[xc6lx45]

16 minutes ago, zygot said:

I guess that I'd not try using digital outputs pins as psuedo DACs or presenting them as such.

There's no drama involved. There exists an official Xilinx application note for (I think) a first order sigma-delta converter that does just the same. There's also no shortage of designs that use this approach (e.g. this one). And generating an analog signal with a digital output is the standard approach nowadays for audio, used in just about any CD player, iPod etc within the last 20 years or so.

[zygot]

@xc6lx45,

I'm not challenging the theory... just the implementation. You can't do 70% of the work and declare it complete. The scope ( and my FM receiver ) does the grading (certainly not a A+)  A broad-band noise radiator is not "noise-shaping" ( or even a DAC ) regardless of the intent or implementation details. But I accept your premiss that "Rome wasn't built in a day".

I guess that I'd be happier if you just stuck to what the CMOD-A7 does well for your tool. Perhaps there will be a flood of testimonials that contradict my preference.

I have ( packed somewhere ) an application note from Motorola for the DSP56002 that discusses  sigma-delta converters and that I still refer to on occasion.

[xc6lx45]

There is no way to filter the noise digitally. Only move it where filtering is most convenient. But you need an analog filter in any case, or just live with it.

It's a pocket knife, remember. Feel free to use it in creative ways. If RF noise is a problem for you (and it won't be for most people), just add adequate filtering. A parallel capacitor and / or a simple RF choke will work wonders.

[zygot]

14 minutes ago, xc6lx45 said:

If RF noise is a problem for you (and it won't be for most people), just add adequate filtering.

So this is where some commentary is required. I suspect that most people won't have an oscilloscope tool and will have something entirely different than what they are expecting from your 8 "DAC" channels. You are free of course to make any claims that you see fit. I am free to challenge them... Since the audience here includes a lot of less technical people I tend to have their interests at heart.

But previously I did suggest that you could do better by completing the hardware portion of your design ( or alternately just drop the waveform generators altogether).

[xc6lx45]

"Pocket knives" have no business in any commercial kitchen. They don't meet basic hygiene standards, pose an increased risk of injury and aren't particularly good at anything.
Still people happily use them to slice pizza.

[xc6lx45]

=== 0v3 released ===

• export binary ADC data
• tweak to sinc8 multitone waveform (8th harmonic was slightly off)

=== DAC performance ===

Here is some experimental data. It's completely taken with "on-board tools" using the XADC, no external filtering. Anybody can repeat the experiment with a patch cable.
The test signal is a sine wave at 1 kHz (use vMin = 0.1 V and vMax = 3.2 V, leaving 0.1 V headroom on either side). It's the "X" on the left.

The fuzzy stuff on the right are harmonics and spurious products but they are about 60 dB down (1 millionth of the signal energy each). There are about three dozen of them => the signal is fairly clean.

At the bottom we see the noise floor, well below the -80 dB line (I may not directly compare noise and signal levels from the plot, but I can compare two plots).

The spurs at 180k and 360 k are caused by the noise shaping of the DAC.

Zooming in on the signal:

The 4th harmonic sticks out at -57 dBc (distortion: 1/500000 of the signal), otherwise they are at or below -60 dBc

=== Frequency response ===

There is a built-in multitone test signal (sinc8) with 8 harmonics.

This is the measured result for 10 kHz fundamental frequency. Harmonics largely below -40 dBc.

Zooming in on the passband, there is 2 dB amplitude drop at 80 kHz.
Is this the DAC or the ADC? A question for another day... it actually works much better than my expectations.

Finally, a note on the "noise shaping": First, any DAC requires a reconstruction filter (lowpass). This one is no exception. See Wikipedia.
A "noise shaping" DAC moves noise to higher frequencies so that it can be filtered away easier (the higher the better) and does not impair the frequency band of interest.

This is the measured performance when I disable the "noise shaping". Comparing with the first picture, the noise floor is about 17 dB up.
In absolute terms, noise shaping gets rid of 95 % (=17 dB) of the unavoidable noise and moves it to higher frequencies. Works as designed.

=== Attached ===

The latest release (the DAC is the same BTW), and an Octave script to generate the above plots from captured data.

Happy hacking (and beware of the +5 V pin...)!

dacCheck.m

labToy0v3_beta.exe

[zygot]

Here's a different view of channel 1 with a 10 KHz sinewave and squarewave using your noise shaping. A more reasonable frequency analysis would reveal why this is such a good broadband noise source. My only point here is that as presented your swiss army knife needs quite a bit of consumer warnings on the label. You are only supplying part of the sigma-delta DAC. The nice thing about a real Swiss army knife is that it is usable as sold for the purpose advertised.

 

[xc6lx45]

Thanks for the measurement. Please note:

17 hours ago, xc6lx45 said:

 First, any DAC requires a reconstruction filter (lowpass). This one is no exception. See Wikipedia.

You're showing the PWM digital bitstream with an almost sufficiently fast scope. Obviously it's a sequence of 0 and 1.
And I replied to this already once before:

On 2/10/2018 at 9:56 AM, xc6lx45 said:

 If in doubt, use a capacitor to ground as lowpass filter. The PMOD outputs already provide the series resistor.

 

Here is the 10 kHz waveform, using the built-in XADC with ~1 MHz bandwidth. Anybody can repeat this without additional hardware.

And the same on my favorite electronics pocketknife (which is BTW the inspiration for labToy):

If there is any confusion on the topic, please refer to Xilinx application note 154. There is a detailed analysis on filtering.
For "typical household use", it may work well enough without explicit filtering . E.g. the built-in XADC or a LM741 opamp in a typical breadboard circuit have an inherent bandwidth of about 1 MHz, which will do the job.

Now regarding the square wave measurement:

You're showing the "Square 01" signal, which involves PWM => filtering discussion as above.
Now there are two options in the waveforms menu:

• "Square 01" is an analog signal and allows level control. This shows the PWM bitstream on a fast scope.
• "LOGIC 10" is a digital signal and shows cleanly on any scope. But, it's always digital fullscale (no PWM), therefore the level controls are grayed out.

The "01" or "01" denotes the phase relative to the generator's sync signal that can be logged in the logic analyzer.