FPGA Loop delay not working

[dkfire]

---

@sivamit2002 wrote:

This might help to understand. The channels have been configured for AOs

---

So what is making your host wait until the FPGA is ready for a new setpoint? 

How do the host know when to give a new setpoint? 

As you have not shown any sign of synchronization between the FPGA code and the host, and you are only able to give the FPGA one value, my bett that your host is updating the control faster than the FPGA is reading the control, due to the wait in the FPGA code. 

[MaxJoseph]

I am not familiar with FPGA IO nodes. I usually use a hardware output channel present on my system to output signals. For instance, you might have an analogue output card with a connector that you can output your signal to. Then you can monitor it on a separate oscilloscope. How do you physically monitor your signal coming from the FPGA?

In the short term, to check the code is working, I would just write the value into an indicator and forget about the IO node entirely. Actually... You could write the code without any interaction from the host at all! Put the command list in as a control and run from there.

For interest, the reason the IO node does not compile is probably because it involves interaction with some non-deterministic protocol. You could get around this by putting the IO node in a while loop outside of the main SCTL. Then you can use local variables to communicate between the two loops (write to the LV in the SCTL and read from the LV in the while loop). This is not great practice, but it will work. Probably.

Finally you can't put a wait inside a SCTL. SCTLs take one cycle. Putting a wait in makes no sense in that context.

[LullabyIsland]

Yes. There is no sync between the host and the FPGA. But I suppose FPGA execution should be faster. The delay is only for FPGA to wait until it reads the next sample- which is not working in my VI.

It is a time controlled execution . I have to run this code for 65 seconds. I get the time info from the number of samples(i.e/ with sample rate and the profile data).

When I finish sending the samples, I stop the operation but I want to make sure it executed for 65 seconds.

 

[dkfire]

---

@sivamit2002 wrote:

Yes. There is no sync between the host and the FPGA. But I suppose FPGA execution should be faster. The delay is only for FPGA to wait until it reads the next sample- which is not working in my VI.

It is a time controlled execution . I have to run this code for 65 seconds. I get the time info from the number of samples(i.e/ with sample rate and the profile data).

When I finish sending the samples, I stop the operation but I want to make sure it executed for 65 seconds.

 

---

The thing is that the FPGA is reading a control, that control can only have one value, and that is the current one. You can update the control as many time as you want and as fast as you want on the host, but the FPGA will only read the current value when it is reading the control. 

If you have no sync between host and FPGA, how do you know when to update the control in the right time, so that the FPGA read all your samples?  

If you do not give the FPGA all the samples at the same time, in a FIFO or like, then your timing needs to be in the host, or you need to have some sort of sync between them. 

[RavensFan]

---

@sivamit2002 wrote:

---

@MaxJoseph wrote:

I do not see how the number of ticks that the FPGA has performed is calculated. So I do not see how the delay is implemented. The use of the while loop (instead of a single cycle timed loop; SCTL) on the FPGA means that the contents do not necessarily operate in a single clock cycle. You are assuming that each cycle of the while loop takes a tick of your 40 MHz clock, using a while loop means that this is not the case (due to dataflow, ask if you want to know more!). To be clear, the operation while take a determined and constant period, you just don't know its length a priori when you use a while loop.

Here are some key steps to the FPGA program I think you want:

1. Initialise a tickCount to 0, initialise cmdCount to 0
2. If Run=true, increment the tickCount, set progComplete to false
3. Perform the required action, send FXPs to AO etc. etc....
4. Check if tickCount is equal to the tickLimit, if so, reset the tickLimit, increment cmdCount
5. Check is cmdCount is equal to cmdLimit, if so, set progComplete to true

Step one is represented by the inputs into a shift register on the SCTL. Steps 2-5 all occur within a single cycle of a SCTL. Run is a command sent from the host which sets off the process. tickLimit and cmdLimit are also commands sent from the host.

You can include some other indicators to show the state; tickCount, cmdCount and progComplete would be interesting, for instance.

---

I can't use the SCTL - I can't compile without error.

---

Either use the timed while loop or use the wait function.  Don't use both.

EDIT:  I see dkfire has said that as well.  I thought I was replying to the last message in the thread and did not see the next page with a few more message.

I would try the time while loop without the wait first.  And if that doesn't help, then I'd used a regular while loop with the wait.

[LullabyIsland]

---

---

Either use the timed while loop or use the wait function.  Don't use both.

---

You mean in the host code?.  Yes I tried wait in the host loop. It works ok with low sample rates like 20 or 40. When I set the sample rate to 500 which drops loop delay to 2ms , it doesn't work because the FPGA code itselt, even with 0 delay, takes approx. 2 ms to execute the VI. I have raised a service request. Just waiting for the NI support team to respond to my email.

[LullabyIsland · Accepted solution]

Update:

Solution: FIFO. 

The old code didn't work. So, we created a FIFO; we send all the data to FIFO and put the delay in the while loop of FPGA code and delay ticks was controlled by the host vi, based on the sampling rate.

Thanks all for the replies and I learned a lot in two days. Arigato.