Ideas and Suggestions about functionality

[chrisdoe]

dear fellows and Digilent staff,

I don't know if ideas are welcome in this forum or where to post them. Feel free to move this thread to a different location or completely delete it.

 

For the first time I am using the Digital Discovery for debugging and analyzing of a more complex embedded project instead of just playing with it. It is indeed helpful, although there are some points I would like to report. Imho points to make this tool even more helpful.

I am aware that the following modifications will most likely involve the fpga design and therefore mean more work than changing waveforms only. However I see great potential and would like to communicate my ideas and wishes.

1) DDs memory is massive compared to the AD. Great! But often there is no need for zillions of data lines or complete memory bus, and one single SPI port in addition with some DIOs is enough. Do you see chances to implement a flexible memory layout? If I burst data on a high speed SPI port with relatively long periods of inactivity, monitoring a sufficiently long period soon gets impossible.

1.1) I remember that there was a protocol analyzer some (several) years ago that stored timestamps instead of sampled data of the DIO lines. The software reconstructed the lines from these timestamps.

When expecting  a sparse transistion pattern with periods of inactivity and relatively few edges... how cool would it be to switch from the traditional mode to such a timestamped mode! Imagine your memory limiting the number of edges instead of the number of samples!

2) If there are quite long periods of inactivity it is not possible to do proper Bus decoding in the logic analyzer sections. I like to send diagnostic data via SPI where several ms of inactivity is not uncommon - You just see that there is a bar on the SPI bus but no information about what has been sent cannot be identified. Extraction or a different visualisation could help.

3) scripting.... Can you give sources of inspiration and a place to get started and learn? If you know java script or are used to such things, the documentation under help maybe sufficiant. However I am a child from the last millenium and sadly it does not help me.

thank you and best wishes

[attila]

Hi @chrisdoe

Ideas and observations are welcomed. Such feedbacks drive the soft-hardware development.

1. Such data compression is implemented for Analog Discovery 1/2 and Electronics Explorer with small 4/16k sample /16-32 bits. On these device the FPGA BRAM buffer width could be easily adjusted.
On Digital Discovery I don't think there is real need for such since it has 256MB memory. Compression here would add some limitation due to fixed DDR memory width. Storing timestamp+sample would need double width in worst case scenario.

2. You can use the Protocol tool which performs most of the protocol decoding in the device (AD1/2, EE, DD)

3. Under Example menu you can find some inspiration source.
You can also search on this forum or feel free to post questions.

[chrisdoe]

hi Attila!

 

thanks for the answer so far. Sure I will study the examples. Thank you.

I am aware of the protocol analyzer, tried it in spy-mode but I did not receive anything useful. Tried it again just as you mentioned it and...well it seems to give data (in hex, maybe I'll should try to figure out if that can be set to an other base). pebkac I think. 

edit: Found the decimal setting.  Interesstingly you can only set the frequency to 12.5 MHz, not 16 MHz. (beta 3.11.14) And why would a nominal frequency matter with spi in Three-wire mode when data is clocked in? 

 

I feel encouraged to explain, why my post sprang to mind. I was debugging a system that is dealing with mains-frequency i.e. there is a 10s  to 100s of ms world. But during that the happens to be fast action. I have that SPI-port (running at 16 MHz) I mentiones and some digital lines whose timing is critical (some 10 ns). The maximum number of Samples I can set the logic analyzer to is 100000. That is only ms at a 100 MHz Rate.... Or am I missing something? Is there a better way for me?

You see that evenmany samples start to look less comfortable when you try to monitor signals with a high rate for some time. That is what made me think about the "store the ns-timestamp for an edge" method, which would lead to literally unlimeted observation times with such sparse edges.

 

Thank you. All of you do a great job

 

 

[chrisdoe]

P.S. For information. Maybe fixable.

Sending a Byte over SPI every 60 us makes Waveforms hanging with no response almost instantly.

[attila]

Hi @chrisdoe

The supported frequencies are natural divisions of 50MHz.
In reception and Spy mode 10% of 1/frequency is used to filter glitches on clock signal.

Select Record mode to capture more samples:
The Repeated mode is intended for Scope like analysis, short captures.

 

The number format can be selected here:

[chrisdoe]

That was valuable information. Maybe I could or should have figured that out by myself. Thanks a lot!