Testing

[jack.gassett]

I'm re-posting this from the firmware topic. In my excitement about the results I didn't think about the fact that this should be its own topic.

Checked into svn is a new VHDL project to generate signals for testing the Sump Pump board. This testing core can be loaded on a second Sump Pump board and the two can be connected with a ribbon cable. The code is checked into svn here. A 100Mhz signal is generated on channel 0 of the outside row numbering scheme. The frequency is cut in half for every channel after that.

The initial results from testing with my two prototype boards is located on my wiki page. There were so many pictures that it was not practical to post them all here.
Initial Results in the Project Wiki

The results are that it looks like the 200Mhz sampling frequency is able to capture the 100Mhz signal on both the buffered and unbuffered pins. The unbuffered pins seem to have less noise and glitches than the buffered pins.

[jack.gassett]

RichF asked about testing with series resistors, I will investigate further soon.

[alm]

Thanks for posting the tests Jack, looks pretty good to me.

Since you can't see the actual waveforms, signal integrity is fairly critical for a logic analyzer. You can't tell if your logic analyzer is telling the truth without hooking up a scope (which is probably not even an option for a majority of the target audience), so you should be able to trust it in most cases. You're currently testing with almost perfect waveforms (apart from the degradation from the transport between the FPGA's), right?

It seems a good idea to me to test with marginal waveforms, i.e. the worst possible waveforms that should still work. A pulse train that just barely crosses the max. low and min. high thresholds. Glitches of the minimum specified width (or just how low can you go). A normal pulse train plus noise that almost touches the threshold. Connect a scope close to the 'probe tip' of the SUMP PUMP (i.e. the piece of flatcable/loose wires that function as such), and observe if it still meets the input requirements (which is what, 3.3V CMOS?), and check if the output from the logic analyzer matches the scope. Observing the signal at the FPGA pins (making sure not to load the signal) might also be helpful.

Of course you'll be the one doing the actual work since you're the one with the hardware, so these are merely suggestions/requests.

Alson

[jack.gassett]

Just wanted to post an update.

I've been working on getting the VHDL code updated with more memory and the correct signals in place before doing more testing. I ran into a snag that has made that more difficult than expected but finally figured it out so should be able to get it finished soon.

Once that is done then I will resume testing. I think for now we are leaning towards functional testing to just make sure that everything works as expected. For now perfect waveforms are probably best for making sure everything operates as expected.

Once the hardware is in more hands then we can start testing with marginal waveforms to really test the limits of the hardware.

[RichF]

Jack, has any futther testing been done at the highr sampling rates and suppression of the glitches previously observed?

I was looking at the open LA site ( http://sigrok.org/wiki/Main_Page) in particular at the pictures they have included for the various commercial logic analyzers.  Although, not knowing the design one can not be sure of the purpose, I thought it was very interesting that all have resistor located near the probe connector. 


I bring this to your attention , because I firmly believe serier termination resistors should be added to any revision/upgrade.

Here are the links to hardware photos.

[url]http://sigrok.org/wiki/File:Saleae_logic_pcb_front.jpg[\url]
[url]http://sigrok.org/wiki/File:Eeelec_xla_esla100_pcb_front.jpg[\url]
[url] http://sigrok.org/wiki/File:Sigma.jpg[\url]
[url]http://sigrok.org/wiki/File:Zeroplus_LAPC16032_highres_top.jpg[\url]
[url]http://sigrok.org/wiki/File:Usbee_sx_pcb_front.jpg[\url]
[url]http://sigrok.org/wiki/File:Braintechnology_usb_lps_pcb_front.jpg[\url]
[url]http://sigrok.org/wiki/File:Intronix_Logicport_PCB_Front.jpg[\url]

[jack.gassett]

RichF,

I haven't done conclusive testing but it seems that the glitches only happen on the buffered connector. I wasn't seeing the glitches when I use the Wing connectors. I was going to do some testing with a bus switch to see if it is any better. The other benefit of a bus switch is that it is bidirectional.

Jack.

[leecbaker]

Although, not knowing the design one can not be sure of the purpose, I thought it was very interesting that all have resistor located near the probe connector. 

I bring this to your attention , because I firmly believe serier termination resistors should be added to any revision/upgrade.

When I was in school, this was something that we were told always to do on digital inputs. I think the resistors cover a few things:

* Input protection from voltages a bit too high / too low: the current in/out of the input is limited by the resistor, limiting damage.
* Anti-aliasing / bandwidth limit- in combination with the input capacitance of the buffer or FPGA, the circuit acts as a bit of a low pass. IIRC, signals that switch (hi->lo or lo->hi) work with the inductance of the wiring connection to generate overshoot / a spike on transitions- this helps filter those out.

I think this should at least be considered for the next version.

[rsdio]

I bring this to your attention , because I firmly believe serier termination resistors should be added to any revision/upgrade.

That's an interesting suggestion, Rich. I was trained to design a PCB with series resistors on the sending side of any digital output, and an RC network on the receiving side of any digital input. This allows ringing, overshoots, and other problems to be cleaned up without a PCB rev. The initial version starts with 0Ω jumpers on the sending side and open circuits on the receiving side where the RC network would be, if needed.

The problem with all of this is that it is a design technique for fixed connections - i.e. known situations where two specific boards are connected. I don't see how you can select the "right" resistance for every possible circuit that the OLS might be connected to. In other words, I worry that the termination resistors would skew the timing of the inputs signals under certain conditions, and thus alter the results of the logic analyzer. I suppose it might be possible to calculate values which would work with "any" possible attached circuit being analyzed, but that doesn't sound easy.

I also question whether low-pass filtering on digital sampling makes any sense. Nyquist is certainly a concern with analog sampling, but binary inputs should be Schottky-connected rather than LPFd.  A low-pass filter would introduce phase delay, perhaps enough to alter timing, as mentioned above.

That said, SMD sites on the PCB populated with 0Ω jumpers would not be a bad idea. The problem is that users would not easily be able to change the resistance if needed, but at least they wouldn't need a PCB revision.