Debugging FPGA-VI

[bunchabowl]

Hey

I created a FPGA-VI for the myRIO which uses the single-cycle-loop and I/O-Pins using LABVIEW 2019

Depending on a counter (lets call it the photon-counter) another counter (program-counter) is reset to zero. The problem is is that this reset does not happen every time. When simulating, the error does not show up.

So far I've tried to use some logic and a I/O-Pin for a "flag" to be set when the error happens (of course without changing the reset-logic). When I do this though, the error kinda vanishes, meaning that it starts working but when observing the Output-Pins of the FPGA, there seem to be some time-glitching regarding the code that follows the reset-code, when there actually shouldn't be any time-variances. the code that follows normally uses the program-counter which got reset, but because of the error the workaround has been to add a second counter, and by doing that, everything seems to work fine.

My question therefore is, if there's a way to implement a core that enables the user to observe the registers and signals on the FPGA while its running, much like the Reveal-Core from the Diamond-Lattice-Software.

My guess is a race condition.

Best

[rolfk]

Your giess is very likely accurate. And since you wrote a lot of prosa text but forgot to attach your VI, this affirmation is pretty much all we can do!😀

LabVIEW including LabVIEW FPGA has reached a state of maturity where 99% of the bugs I encounter are my own misunderstanding, stupidity, or ignorance! 😀

That’s for a small part also because I don’t tend to spring on the bandwagons to use the latest hyped features but usually prefer to lag behind about two versions, and maybe also because I tend to program a bit more defensively than strictly needed.😀

[Bob_Schor]

I agree with Rolf (of course) -- attach your FPGA VI so we can see what you are doing (feel free to explain, in words, what you want to do, which is probably subtly different from what your code "asks" the FPGA to do, hence the bug).  If nothing else, it will be an interesting "learning experience" for those (such as I) who are relatively new to FPGA programming and can learn, ourselves, from the Experts on the Forum.

Bob Schor

[bunchabowl]

Hey Rolf

The code is quite complex which is why I'm looking for a way to debug the code myself. Implementing a core like chipscope, would be really nice but it doesn't seem to be an option for the myRIO, which uses a zynq-7010 chip. Having a look at the generated VHDL-files doesnt seem to be an option since they're encrypted.

I would appreciate it though if someone would have a look at the code. The stripped down version is in the attachments (stripped_VI.vi), the full code as well (broken_VI.vi).

So the cases 0 and 1 of the case-structure have a step-counter which is used in both cases and is reset at least before the case change from 0 to 1.The step-counter is incremented every clock-cycle.

Every case has its own max. amount of clock-cycles before the step-counter is just reset and/or reset and a new number is stored inside the program-counter-variable, which means in the next clock-cycle the succeeding case is active.

In case 0, the condition for going into the next case is for a threshold to be met. When that happens, the step-counter should be set to 0 and the program-counter to 1. If the max length of case 0 is reached the case 0 sequence is repeated until the threshold is met.

In case 1 the step-counter is used to time laser-pulses and to determine when the case is finished.

There is also a separate counter with its own logic that does the timing for microwave-pulses (Laufvariable1&2). Microwave 2 is used to change the max output level of channel 2.

The screenshot of the oscilloscope shows channel 1 [yellow] (microwave1 -pin) and channel 2 [blue] (laser 2-pin). channel 1 is pulsed when a case change from 0 to 1 occurs. channel 2 is pulsed once per sequence during case 0 until the threshold is met. as soon as the threshold is met, there is a short time where the channel 2 is at 0V followed by a pulse with 2 different voltage levels and then followed by a longer period again with 0V. At the start of case 1, a trigger occurs (microwave 2-pin) in order to change the max output voltage from 100% to about 50%. then the first pulse and only pulse during case 1 starts. near the end of said pulse, the voltage is changed again from 50% to 100%.

The right event (error) shows that only one output level trigger occurs and the whole case 1 sequence seems the be cut off in the beginning  (missing the 0V at case change and case 1 pulse if shorter).

We assumed that the step-counter does not get reset to 0 at all. When we force the step-counter-value into a certain range at the end of case 0,

the sequence in case 1 does not pick up at that value.

The work-around has been to have 2 step-counters that alternate, which mean for case 0 and 2 we use step-counter1 and for case 1 and 3 we use step-counter2. the only wiring that changes is inside the case where the used step-counter changes.This VI is also in the attachements (workaround_VI.vi).

Thanks a lot!

Best

[rolfk]

Could you save your VIs as LabVIEW 2017 or 2018?

[Bob_Schor]

I've just written my first myRIO FPGA routine (this is really, in fact, my first "real" FPGA routine, meaning something other than useful "Tutorial Exercises" that I picked up).  I have some suggestions, based on looking (only) at "Stripped"):

• Use an Enum for your States.  Given them meaningful names (for example, my SPI Enum has states Idle (where nothing is happening, but waiting for User Input to do something), Write (where the routine accepts up to 32-bits of "command", along with a Bit Count, and sends all of the Bits out through the MOSI line), Convert (a command for the one SPI chip, an A/D Converter, that returns data to the User), and Read (which pairs with Convert to MISO the data, via an RT FIFO, back to the User).
• Simplify and "neaten" your Block Diagram.  Do not use Icons for Controls and Indicators (too much space).  Keep wires running straight left-to-right.  Put them in a logical order, and try to minimize White Space (so you can see the Forest for the Trees).
• Before writing the "One FPGA VI to Rule them All", write (and test) smaller VIs that do "one part" of the task, to make sure that it works.

Because I'm currently working from home (a myRIO is wonderfully portable), I don't have access to a fancy Digital Scope.  So I "invented" a "scope" I named after my Supervisor, who suggested that I use one of the myRIO's LED as a "heart-beat", turning it off and on at a rate of 1 Hz just to show that the myRIO was working.  I said "Hmm, why don't I slow down the myRIO's Master Clock from 80 MHz to 8 Hz (or put 100 msec Loop Timers and Delays where I need them) and use the 4 LEDs as either a 4-bit "register" or 4 one-bit "registers"?  I ended up making LED 1 Chip Select, LED 2 SCLK, LED 3 MOSI, and LED 4 a "Conversion-in-Progress" flag.  This enabled me to "see" the timing without a scope, verify that I had the phases right (I didn't, originally), and then send the code, with the LED code removed and the FPGA clock restored to 80 MHz, to my colleagues with the Digital 'Scopes to verify that it really worked.  Feel free to use this idea to slow down your FPGA code and make its workings "more visible" to you as you work to simplify and organize your code.

Bob Schor 

[bunchabowl]

Hey Rolf

I tried to change the version as described on this page but the version of the FPGA-VIs wont change...

[bunchabowl]

Hey Bob

Thanks for the tips. As we dont have much time to redo the code we'll probably just use the workaround.