Phantom logic in DD

[D@n]

On one of my first attempts to use a DD, I captured a display showing several "phantom" transitions.  (See below, and attached)

I call these "phantom" transitions because when I zoomed in on any of these, they vanished.  You can see many of these just left of the 0.35ms line.  However, there are many others scattered throughout the plot.  For example, the DIO30 line shows a very slow logic waveform--with super fast phantom transitions on it as well.  In general, most of these phantom transitions are very narrow.  However, there are some larger and thicker phantoms.  For example, if you look at the "PP-CLK" trace, just after 0.98ms, there is a simple rise and fall.  However, the rise is thicker than the fall, even though there are no extra transitions there.

Dan

[D@n]

@zygot,

Let's examine the evidence then:

1. You don't have a DD.
2. You haven't examined the picture I presented as evidence, nor have you asked questions so as to fully understand what I'm talking about.
3. The problems you are describing don't match the evidence I've seen and described.  This would be apparent if you had a DD and saw and watched it work, and particularly what I was doing with it.
4. I'm taking fixed snapshots, and watching the effect come and go *after* the snapshot has been downloaded to my PC.  There's only one transfer from USB to PC in this example, once that's finished there's no more room for further USB to PC errors.
5. When zooming in and looking at the DD's samples, on a sample by sample basis, the samples transmitted over the USB to my PC look good and very believable.  They are not displaying any unexpected artifacts such as you are describing.
6. You are comparing the DD to a 50k logic analyzer and not realizing the impacts of 1) the fact that modern electronics has made high rate sampling a cheap commodity, 2) by running software on the PC on my desk the logic analyzer doesn't need to include a high priced display, 3) that by using my computer this device doesn't need any of the knobs or switches the other user interface items that high priced analyzers needed to support, 4) by running on a PC and using the PC hardware, Digilent doesn't have to maintain a large support and maintenance staff to fix broken buttons, etc.

The problem I'm describing has to do with phantom transitions being displayed when massively zoomed out, but not when the display is zoomed in.  It takes place after the interaction over the USB has been completed and the data has been downloaded to the PC.  It seems particularly acute when the display line is thicker.  Sometimes the thick display line gets mixed with small display lines, with confusing results.  I'm sure this was intended to be a feature of the software, but I'm writing in to suggest that it isn't working.

Quit while you have the chance, friend, since the phenomena you are describing, while valid, haven't matched the evidences I'm describing.

I'm still hoping and waiting for @attila to comment.

Dan

[zygot]

@D@n,

Well....

1) True. I've said that already

2) Not true. But your picture doesn't provide the "evidence" that you mention. Perhaps a few pictures. I haven't asked any questions because I haven't used the DD interface. But here's one. Can you define the logic standard for the signals of interest? I could see a possible issue with threshold voltages and other logic specifications if your logic isn't compatible with what the FPGA in the DD is using. While I clearly haven't provided any ideas that make you happy I disagree that I haven't examined the evidence. What you've described just seems to be evidence of something other than a display issue to me.

3) Can't think of anything to say

4) I've understood that from the beginning

5) Same as 4

6) Not true. I'm trying to convey some of the things that a tool that bills itself as a logic analyzer might do. I already mentioned that I don't expect tools in the price category to compete with professional level tools. That doesn't mean that they shouldn't perform properly, to the level expected for the design. I don't know what you mean by high sampling rate but 200 MHz isn't high, nor has it been for a few decades, unless you are capturing logic that toggles at about 1 MHz. I've tried to convey that there's a lot more to a logic analyzer than sampling rates. BTW a real logic analyzer would have programmable threshold voltages. I'm just trying to lay out some ideas about what a logic analyzer might need to do to accomplish its duties. To be frank I disagree with everything that you say in item 6.

Like you, I'm waiting for someone else to explain your issues. Just because it looks to you like a display issue doesn't mean that it is. Really, I'd be more understanding if the display missed logic transitions instead of putting non-existent ones into a plot where there were too many samples for the the number of displayable pixels. That doesn't make sense to me. Which is why I think that perhaps what you are seeing is a symptom of something else going on.

Since it's just you and me so far discussing this I don't feel the need to seize an opportunity to quit until someone who knows what's going on reveals the answer.  If you don't like what I have to say then that's fine. If you want to dispute what I have to say then please do. Don't feel sorry for me, I haven't embarrassed myself... yet.

 

[zygot]

@D@n,

Here's a question. Can the DD allow you to save raw samples to a file? You can then do your own processing to see what the display ought to show.

I think that your assumptions about what's going on in sample processing before the display software even gets started might be wrong.

[attila]

Hi @D@n

Finally I see the "glitches" you are talking about. It is very hard to notice on my high resolution monitor.

These thin vertical lines show up with Plot Width of 3 or 4. Please use width 1 or 2 until this gets fixed.

Thank you for the observation.

[D@n]

Let me try this again.  Attached, please find a figure showing two examples of the same data at different zoom levels.

In red, I have drawn a circle on the left around a feature that looks like a thin impulse followed by a thicker impulse.  (Not the block feature, nor the phantom thin impulse before it, but rather the thick and thin impulse before that.)  Now, if you zoom in on that feature, WITHOUT MAKING A NEW COLLECT, WITHOUT TRANSFERRING ANY MORE DATA OVER USB, WITHOUT MODIFYING THE BUFFER, you find the well-defined logic pulses on each of the two traces to the right.

Let's see if I can draw a line around just the feature I am talking about on the left hand side a little clearer ...

This is the feature I am talking about.  When zoomed in, there's only one pulse on each trace.

My argument is that when zoomed out, these SAME SIMPLE LOGIC PULSES look like a pair of pulses--one a thin vertical line next to a thicker vertical line.  But when zoomed in, only the simple logic pulses (one per trace) is apparent.

The problem appears to be associated with both the zoom level, and a "feature" in the display having to deal with the extra thick lines.  (Notice that these phantom signals have thin lines, whereas I have requested thicker lines from the display.)  If you zoom out far enough, it seems as though the waveforms software tries to replace the "thick lines" I have requested (due to my poor eyesight) with thin lines.  These thin lines, however, don't match up with the location of the original features.

I'd like to take this opportunity to say that I am in wholehearted opposition to ANY feature on a display that mis-characterizes the data upon which the display was built.  I am also in complete opposition to replacing thick lines (for my poor eyesight) with thin lines--especially if these thin lines create a view of the data that is not consistent with the actual data that is present.

I also think that part of this problem is related to the fact that the x-axis is getting pixellated at the line width, rather than at the underlying pixel width.  This is creating aliasing problems in the display where features appear to appear and disappear as the display zoom is adjusted.  I find this both annoying and confusing.

@zygot, You may wish to note as well that there are no "glitches" showing up when zoomed in.  I understand how such "glitches" can appear and show up in a data collector.  Were that the case here, I would expect that when I zoom in on the samples, I would see the glitches.  I also understand how such glitches might show up in one collect and not another.  That's not the issue here, because I'm talking about THE SAME COLLECT.  We are examining ONE SET OF DATA.  When zoomed in, there aren't any there.  When zoomed out, they appear.  This is why I call them "phantom"s.

Dan

[zygot]

@D@n,

Yeah, your last set of pictures is a lot better at illustrating what you want to say. As of this moment I don't wish to change any of my previous comments. I still think that you are making incorrect assumptions about what the tools' software is doing.

You haven't answered my 2 questions:

1) can you dump data capture samples to a file in a format that you can read with your own program and analyze?

2) Do you have control over what the DD FPGA input IOSTANDARD is set to?

regards 

[D@n]

@zygot,

1. Yes, I can save the data file.  It saved nicely to a 1.2GB CSV file.  I should be able to convert that to a VCD file for another viewer (GTKWave perhaps?), although ... I would rather have a viewer that worked out of the box without either phantoms or my needing to "prove" it.
2. As for the voltage standard, it is set to 3.3V digital I/O with a 1.42V threshold.

Dan

 

[zygot]

@D@n,

BTW, I got your inference that you believe that the DD software is working on a single contiguous record of sample data the first time; you don't have to emphasize it each time you post here.

[D@n]

@zygot,

Ok, but then ... I don't get your comments.  They seem to me to be only relevant if their is a glitch in the capture portion of the software, something that I believe the data disproves.  It's not that such glitches can't or don't exist, it's just that ... I haven't seen any such glitches in the data I'm talking about.  Hence I can't understand why you keep going back and suggesting that a capture glitch is responsible for the artifacts I am seeing.

Dan

[zygot]

@D@n,

OK. "set to 3.3V digital I/O with a 1.42V threshold.". What device(s) are you probing? For my own version of the "DD" or even for csv formatted dumps from my oscilloscope I've written some simple programs to run through very large data sets to extract transitions. With a scope this is a bit more complicated as I have 8-bit A/D data but everything is timestamped and the analysis program doesn' have to be very complicated.

[D@n]

I am probing the pmod port P2 of an icoboard gamma.

C/C++ is my native language.  Converting from CSV to something (anything) else isn't difficult, it's just annoying. 

Dan

[zygot]

@D@n,

My comments rarely explicitly dive deeply into all of the ideas floating around in my mind. I like to start simply as possibly. I understand that you are having difficulty with my not making the same inferences as you are making. You can ( somewhat ) easily extract the transitions from the data dump for the channel that has the confusing display and see what's there. This should narrow the discussion considerably. Personally, I think that this whole post has been interesting and might be useful to everyone. Anyone reading it who wants to question any of the statements should weigh in.

My concern is that your tool might be another poorly supported product that doesn't quite live up to its billing. There are alternatives that are 4-5 times the price but much more robust. I have no problem with the concept as long as it does what it is advertised to do and doesn't over sell its capabilities to the less technically inclined. Using non-staff for technical support just isn't a very good thing for a vendor to be doing.