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

[attila]

Hi @D@n

These display glitches, thin lines are solved for the next software release.

Thank you again.

[D@n]

@zygot,

The whole point of this post was that the DD could be made better and with a little more help it might "live up to its billing".  I was writing for the purpose of letting the Digilent staff know what my observations were, so as to keep this from being a "poorly supported product."  To date, I've been pleased with the responsiveness of the Digilent staff to issues I've brought up on this forum.  (Thanks @attila for noticing the thread and my comments!)

My frustration with this thread is that it feels like your comments have pulled the thread off track from my observations, by entertaining hypotheses and arguments over those hypotheses which are not consistent with what I have been observing.

Dan

P.S. Give me another half hour or so, and I'll have all the transitions extracted.  It's not going to be hard at all to do, just annoying.

[zygot]

@D@n,

Well now that a staff member has weighed in to support your hypothesis I can stop making suggestions about possible issues. I am still interested in your findings. I still believe that the discussion is useful even if it hasn't revealed the nature of what's been causing your confusion. I'd expect this sort of issue to be discovered and fixed prior to releasing a product if it is in fact just an algorithmic issue. Admittedly, I have expectations for products that I purchase that used to be a given and now seem to be high.

[D@n]

Ok, here's my data set for reference, in a nice 4.3k VCD file.  (The CSV file took up 1.2GB!!!!)  It's not the first data sample set I posted, but it is the sample set I posted most recently.  (No, I didn't keep track of the trigger location, present within the CSV file, although I could have ...)

If you pull the data up with GTKWave, you'll see that there are no phantom transitions within it.  However, Digilent's Waveforms software has a nice continuous zoom capability that GTKWave doesn't have ...   Further, I was enjoying the thicker trace lines in Waveforms that are not present in GTKWave.

Dan

P.S.  @attila, Saving data into a VCD format would be a nice capability to add to the waveforms package.  It's not hard to do, and it only took me only a couple minutes to convert from the CVS to a VCD format.  (Conversion program attached ...)

shotdata.vcd

genvcd.cpp

[D@n]

@zygot,

You are missing a piece of the context ... I didn't purchase the DD.  It was given to me by Digilent's marketing department together with a request that I review the product.  Part of the purpose of this post was to share what I had found. 

Dan

[D@n]

Here's another image showing what I consider to be a problem:

 

Notice the small, single-line pulses, displayed when the setting is set for a thick pulse-width.  While you might argue that this is an accurate representation of very narrow pulses, if the line width is set to be thick, it would make more sense to display these with thicker pulses.

Dan

[zygot]

@D@n,

About the context that wasn't explicitly mentioned until now. Knowing the vastness of your budget for such things I surmised that this was the case. Your general tone bolstered this suspicion.  My suggestion is that Digilent have you review products before they are released and all communication be off public forums until you have any issues resolved... then release the product. I'd trust you to do a thorough job of it. I have found the vast majority of your posts to be very helpful and generally technically correct. I respect you. Given the sketchy way that "reputation" is assessed on the Digilent forums and general feedback about how the less technically knowledgeable view your opinions I suggest you take some time to reconsider doing such work. I have grave concerns about solicited " product reviews"; especially when there are payments involved; even if only in merchandise.  Just because "everybody" is doing it doesn't mean that it's OK. This concern is especially true when not all pertinent information about the relationship surrounding the people involved in such a review is not explicitly and plainly stated prominently up front. I realize that your post wasn't the review which accounts for the third sentence. I've worked for companies who valued their image so Digilent's philosophy is a puzzlement to me; especially since their main customer base consists of students and educational institutions.

[D@n]

@zygot,

Ok, so ... you are troubled by this practice.  Got it.

How do you think it *should* be done?  You skipped the part of your own recommendation.  I'm all ears.  How would you recommend changing things?

Dan

[zygot]

@D@n, Ok, so you are not troubled by this practice. Got it.

[zygot]

@D@n,

Yeah, I don't know that it's worth my time trying to figure out what the logic standard is from the device that you are probing. The threshold that you mention is probably OK for most 3.3V logic but it could be interesting to see if an alternate setting has different results. The decision threshold is but one factor in knowing if a signal is operating within specifications.

[attila]

@D@n

You might also notice gray lines. These mark noise, more than one transition between two sample points when sampling rate is less than 100MHz.

Noise at 160us:

between 7-7.2us

 

In this case you can repeat the acquisition at higher rate to have more information about the transitions.

[D@n]

@zygot,

I am a very conscientious individual.  You seem to believe I am doing something immoral or ethically problematic.  If this is the case, I will change my ways immediately.  That's been the way of my own life for many years.

So. I asked you how you felt the process should be accomplished.  Your response does nothing to help what you see as a problematic process.  (Job 19:4, 16:3)

If you see something immoral, or ethically problematic, please speak up.  Justify your position.  I am particularly responsive to the Bible.  Quote it if you must.  Show me my fault.  However, if you cannot demonstrate that there's anything wrong with the practice, then please be so kind as to hold your peace.

Dan

[D@n]

@attila,

I have not noticed these gray shaded areas.  I've been sampling at 200MHz so far.  I look forward to noticing those gray areas, and seeing them in the future.

Thank you for pointing them out,

Dan

[zygot]

@D@n,

I really don't have anything to add to my suggestion that you rethink doing solicited reviews. If you are guided by divinely inspired works I take you at your word. I know a lot of really unethical crooks who also are guided by a peculiar interpretation of the same sources. I'm unaware of any specific text dealing with the topic under discussion in your source; though there are no doubt plenty of people willing to use as verse or two out of context to justify any conduct.

I know what I'd do... I'd avoid any suggestion of conflict of interest. What you do is up to you and your conscience. At least we know how you feel about it. I'm not attacking your personal moral values... just wondering why we are so far apart on one specific issue.

[zygot]

@attila,

Noise? Talk to me a bit about how you define noise in the sample data.

[D@n]

@zygot,

Tell you what ... there's still enough time today.  I can pick up my DD and drive to your place tonight (Yes, it's a long drive).  Tomorrow we can work with it, and you can offer an unpaid review.  I'll need to head back on Thursday.

Would that meet your standard of ethics?  You idea of an unbiased review?  I won't pay you, so you won't be biased by the process.  (I'll need room and board during the next couple days to do this ...)  I'll only request that you write about your experiences.

Would that ease your troubled conscience in this process?

Dan

[JColvin]

I realize that I can't possibly know the full story on both sides of the equation here and wasn't aware of any of this until reading this today, but I will have to ask that this discussion be taken to the messaging side of things rather than posting on the Forum.

Thank you,
JColvin

[zygot]

@D@n,

I was just about to edit my last post....

Believe it or not the mandate to avoid any suggestion of conflict of interest is a typical corporate mandate that employees sign all the time; even if they didn't get it from the Holy Word. ( And even when their bosses tell the to do it anyway... )

I don't see the point in anything that your last post says... I've been scratching my head for a while. I apologize if you took my thoughts as a personal attack. That was in no part an intention. Previously, I wrote: "My suggestion is that Digilent have you review products before they are released and all communication be off public forums until you have any issues resolved... then release the product. I'd trust you to do a thorough job of it. I have found the vast majority of your posts to be very helpful and generally technically correct. I respect you. "

That's seems like a good place to start. After that, this is not my business. I see a conflict of interest. Apparently, you don't. In the end it's the people who plunk down their hard earned cash who will judge. I hope that you are as dogged in making sure that any "review" used as sales material be taken in the proper context as you are in pursuing my suggestion to do some soul searching. I doubt that very technical people will interested in this particular product anyway.

BTW I don't do product reviews, endorsements, marketing, or similar activities for third parties. That's in my own corporate policy. I do point out issues when relevant and I deem necessary.

I think that we've beaten that dead horse enough into the hereafter...

 

[zygot]

@JColvin,Thank you for your input.

[zygot]

@HansV,

Not bad observations for someone who claims that the preceding discussion is over your head, You are correct that expensive equipment can mislead you if you aren't aware of its limitations and the physics of good probing. I don't know that crosstalk is @D@n's issue but it is certainly a possibility with a logic analyzer designed the way that the DD is. He is convinced that what he is looking are representations of a complete record of contiguous samples; and he could be correct. I'm not so sure, based on past experience.

I've made my own "DD" , without the display software so I'm not totally ignorant about what can go wrong. 35 years of using the expensive equipment hunting down complex electronics misbehaviour probably is guiding my responses. 

[zygot]

@D@n,

So, you haven't provided enough information. What's clocking the data sampler? Are all of the captured signals derived form the sampling clock? I've never used the DD but have used a number of similar "digital logic analyzer" tools, including my own. It's possible that what you are showing is an artefact of the display processing but I suspect that something else is going on.

[D@n]

@zygot,

The DD has an internal clock.  From the image, assuming others can see it (I can't), I had the clock set at 200MHz.  The signals are captured using this sampling clock.

Based upon what I've seen, I'm concluding that I'm seeing an artifact of the display processing.  The reason for this conclusion is that when I zoom in (without changing the collection data, or the collected buffer), the transitions vanish.

Let me try attaching the image again.

Dan

P.S. I found the bug in my own code ... the clock on the iCE40 wasn't locking.  I had never checked for that possibility over the last couple of months of struggling with this design.  My logic was not working reliably, and I couldn't figure it out until I saw a transition take place "faster" than my logic clock.  (Sample at 200MHz, logic clock at 40MHz)  That led me to look at the clock and then the light suddenly dawned on me.  Hence, it is now thanks to the DD that I was able to fix my design.

[zygot]

@D@n,

You write: "P.S. I found the bug in my own code"...

I'm glad to hear that you found an error in your HDL. I'm skeptical of your inference from the DD display, however. What you're telling me is that the DD sample clock is unrelated to any of the signals you are looking at. Whenever you are doing asynchronous sampling you will have "artifacts" that need interpretation.  How these will be displayed might be different on an $50K logic analyzer from HP than on a simple $50 logic analyzer from Amazon, but they will be there. When your sampling clock is a few orders of magnitude higher than the clock generating the target signals it's a bit easier to interpret artifacts. If state changes "vanish" when you zoom in on them I would certainly be concerned about the truthfulness of your logic analyzer ( which always involves display processing software ). If you don't understand when you tools are likely to lie to you the result is usually a trip down the rabbit hole where little makes sense.

The same idea about asynchronous sampling applies to logic in your FPGA of course. If glitches are happening to the combinatorial logic between the clock edges and the timing isn't constrained properly then you can do asynchronous sampling even when your HDL says that you are using clocked processes properly. This is what makes FPGA development exciting. A favorable place and route one day can present a design as "working" and the next day a rebuild of the same HDL with portions routed differently can present intermittent errors. A good rule of thumb is to use the minimum number of combinatorial logic levels and the least complex combinatorial logic between clock edges as possible. And, never use a clock derived from logic as a clock in your HDL.

[D@n]

@zygot,

I think you are misunderstanding what I am trying to describe.

I'm setting the logic analyzer to trigger on a condition.  It's triggering nicely.  I'm setting the logic analyzer to sample at 200MHz, and to record a large buffer.  Somewhere within it, running at 200MHz, logic levels are being converted to 1's and 0's and then written to memory.  This memory is then dumped to the waveforms software.  I am aware of problems that can take place during this process--particularly problems associated with sampling logic taking place at 40MHz with an unsynchronized 200MHz clock.  I have no reason to suspect any problems in this processing chain given the information I have seen from the device.  (Other than the interface has crashed during four of those transfers, but we'll ignore those transfers for now ... those are another issue.)

I am also aware of problems that can be created by sampling artifacts that vanish with a new sample buffer, or with a running capture that just captures and then recaptures data.  That's not the case here as I have manually set the DD set to trigger off of a condition, and the sample buffer is not changing as I am then examining it.

My problem is associated with displaying a given buffer.  At some display resolutions, there are phantom artifacts that then disappear at other display resolutions.  Having built displays like this before, I understand the difficulty of fitting more samples on a screen then there are pixels on a screen.  The likelihood of a bug in this part of the display software is non-zero--I've had to chase several down myself with my own software.  If I zoom into the display buffer, though, to the point where I can essentially see the individual samples, and these individual samples are about 20-pixels across or so--the phantom transitions go away.  During this examination process, the sample buffer is not changing--only the display parameters.

That's the evidence I'm dealing with.

As for finding the bug within my code ... this one snapshot doesn't show what I found.  The snapshot of the clock, dumped to a wire that I could then observe, showed the problem--since the clock was anything but regular.  Using a 200MHz sampling clock, I shouldn't have any aliasing problems with 40MHz signals ... and once I had the 40MHz clock working properly, the result was a *drastic* difference.  (My logic started working reliably then too ...)  Even still, though, this 40MHz clock wasn't clocking the logic analyzer, but rather my own logic within an iCE40 (slower) FPGA.  Hmm ... capturing some samples of what I found, showing the bug, might be a fun adventure ... I should be able to re-enact the bug based on the git history for the project ...

Dan

[zygot]

@D@n,

I'm sure that I've been understanding what you are trying to describe. Perhaps I'm not as good at describing my response. ???

When you hook up flying leads to pins there are a number of things that can be problematic. A $50K logic analyzer has pretty sophisticated probe conditioning between the grabber leads and the sampler. A cheap analyzer doesn't. For the DD, between the local DDR sample buffer and the PC software display buffer is a lot of USB software. I don't have access to the DD control software so I don't know how it operates. We can both appreciate, from experience, how easy it is to mess up displaying data with a limited number of pixels to map to.

What you don't see with things like the DD are samples where data is transitioning between 0 and 1. You can't because of the design; it's all digital. If the sampler were, say a 4-bit A/D and the sampling clock period was about 1/10th the signal rise and fall times you could see this transition as well as over-shoot and under-shoot and possibly coupling of channels. This isn't a criticism of the DD ( or any cheap logic analyzer )  as its price precludes such amenities. 

Still, as likely as it is that the artifacts in the compressed display that you show  is the result of poorly designed display software, I don't feel compelled to change my previous comments. The end result is that if your display doesn't represent a "true" picture of what the target signals are doing it doesn't matter how sophisticated the analyzer is; because the display is the information.

While it's hard to see what you are seeing from the pictures ( by browser doesn't let me zoom in very far ) you no doubt noticed that the "phantom transitions" are all near transitions on other signals. I don't think that either of us can make a conclusion as to what exactly is going on.