06-08-2011 07:21 AM
Hi All,
I need some advise on how to proceed with my project.
I need to send a 32 bit data to my unit under test with the following parameters. CLK+, FS+ and DO+.
The clock runs at 4MHZ. The FS+ sends a 33 bit length of high signal for data processing and within this frame I need to send my 32bit data.
What I did is I created 3 loops as shown in my diagram.
1. The first loop is a timed loop to generate my clock pulses. I run it at 8MHZ with the high and low signals alternating per loop.
2. The second loop is for my frame sync signal which uses the rising edge of the clock plus an external trigger (SEND DATA) to start the sequence. It has two WAIT signals at 0 tick and 330 ticks ( per tick is 25ns).
I compiled up to this version of the code and run it with out any problems. I was able to generate the FS+ signal at 2ns after the clock rises and is having exactly 33 clock cycles of length.
3. The third loop which is I am having trouble right now is designed for the data loop. I also used the Clock Pulse and the external data to start the sequence. I used a single WAIT signal to delay the start of the data in by 1 clock cycle and use a for loop to send in the 32 bit data at 250ns (10 ticks) per loop.
The problem is I am not getting the desired result that I want. The start of the bits is always erratic and not 1 clock cycle delay as I hoped for. Also the first bit is way too small for the 250ns.
Can somebody tell me where did I go wrong? Is there another way to approach this?
Your help will be greatly appreciated.
Solved! Go to Solution.
06-09-2011 10:29 AM
hi there,
any reason that you use three loops? It looks to me you can combine the 2nd and 3rd loop. With assumption that FS and DO happen sequencially.
06-09-2011 11:07 AM
As a short answer, I would recommend combining all three sets of loops into a single state machine. All three loops are intended to be based on the 8MHz derived clock domain.
As a longer answer and to explain the behavior you are seeing... the timing of this code is affected by data crossing clock domains. The details are in this LabVIEW FPGA help post: Implementing Multiple Clock Domains When crossing clock domains (by using a tunnel from inside the 8MHz Timed Loop clock domain to the 40MHz block diagram clock domain), LabVIEW is forced to implement a hand shaking algorithm to ensure the data integrity is maintained. This hand shaking consumes FPGA fabric (logic cells) and takes multiple 25ns clock cycles to execute, so that creates the undesired delay. In addition, the third loop can't guarantee that the data out code will trigger off of the same clock pulse as the second loop because of the handshaking that occurs for data to be passed into the 8MHz loops.
I would recommend you base the entire communication off of a single Timed Loop, in a configuration called a state machine. Essentially, a timed loop with a case structure inside, where each frame of the case structure is a different state. Within a Timed Loop state machine, you cannot use the "wait" function, so delays have to be implemented with a "do nothing" state that is repeated N number of times to equal the delay needed. The following link is to a similar state machine for SPI communication that would be a good example for how to implement this communication: LabVIEW FPGA SPI Example.
The above example implements the following communication scheme, which sounds pretty close to what you are implementing:
This code is a little more complicated than what may be absolutely necessary for your application, but it is a great example of a scalable & flexible implementation of the core concept (this code can easily be migrated to new hardware targets or add multiple replicated or altered communication protocols to the same architecture.)
Cheers,
06-13-2011 12:33 AM
Hi,
Thanks. I think I had figured it out using this solution. I need a few tweaks here and there on my state machine since my clock is required to run non stop. But I guess using a state machine is the best move forward.
I will post my VI here as soon as i have it tested and bug free. Thanks for the help.