Reproducing Base Clock Pulse Train with Derived Clock in LabVIEW FPGA

[Akello]

Hello all,

I am working with a sbRIO 9626 to produce a pulse train with a modifyable duty cycle. The board has a 40MHz base clock but I am trying to achieve a certain resolution to the duty cycle that requires 200MHz. I have been able to add a derived clock at that frequency but ran into some problems trying to manipulate it that I was hoping to get some advice on.

I set up a simple VI on the FPGA where a timed loop connected to the base clock has a NOT gate controlling a pin and a shift register on the loop. This produces a simple pulse train in the shape of a sinusoid with a period of 50ns that I can view with a scope. When I switch the base clock to the derived clock, I get a similar sinusoid with a period of 10ns albeit a lower voltage.

I ran into the problem when I tried to modify the VI to adjust it to have the derived clock and produce a pulse train like the base clock, at least in terms of period. I initially wanted to add a command that said to Wait X Ticks, however, LabVIEW informed me this would only work in a while loop. The while loop did not execute in line with the clock and the following white paper led me to believe the timed loop is my best bet (http://www.ni.com/white-paper/12605/en/). To modify the timed loop, I added a counter that incremented every iteration and when it reached five it activated the NOT gate and reset to zero. I thought this would quintuple the period to 50ns and reproduce the 40MHz sinusoid. The period only increased to about 13ns, however, and I had to raise the 5 to a 9 or 10 to achieve the desired period. Furthemore, the wave was no longer a clean sinusoid but has a bump as well as being 1/3 rise, 2/3 fall.

Reading the same white paper I mentioned earlier, I thought that maybe the derived clock and gates I added would be the source of the timing issue but it takes less not more time as that logic would imply. Furthermore, the program should tell me if the blocks cannot execute in the single clock period they are constrainted to by the timed loop. Finally, I have no idea why the shape of the sinusoid has become so corrupted. I would really appreciate any of your advice, the boards have been an invaluable resource to me so far.

Hope to hear from you,
Yusif Nurizade

P.S. Sorry for not posting the actual VIs, I am not able to do so until Thursday at the earliest. I'm hoping that they are currently simple enough that the description is enough.

[WishKebab]

Hello Akello, 

What FPGA hardware are you using, and what is the digital output hardware?  What version of LabVIEW are you running?  Thanks for posting this interesting question!

[Akello]

Thank you for the response.

I am not currently able to access the device (it's at the office) but I am pretty sure it is a sbRIO-9626. I am using LabVIEW 2012 for my development.

Someone helped me figure out part of the issue. The 5 iteration timer was only applicable to the OFF state whereas the ON state would only run through one iteration. I tried to correct the mistake but the extra gates I had to add gave me a timing error. I tried a two shift register scheme but ran into an even bigger timing error. This derived clock is really making things harder.

At this point I could really use some advice on a minimalistic pulse train with adjustable duty cycle. Even better; would it be possible to get a table for gate timing for this model? Or in general a table that says which gates typically take up the least time? I think this would really help avoid trial and error.

Hope to hear from you,

Yusif

[Prickly_Pear]

This sounds like a very interesting project. I believe that you are using your hardware up close to its physical limits. I searched and there doesn't seem to be anyone on our site that has posted anything that is similar to a high speed adjustable duty cycle FPGA code.

Unfortunately, we do not have tables of values gate timing for individual modules. Timing on LabVIEW FPGA often depends on periferal code, so tables like that would not be accurate. I think that the trial and error approach is the only approach to this problem.

You sound like you have a substantial amount of experience working with LV FPGA. If you haven't already read it, I suggest that you review this knowledgebase article that talks about single cycle time loop performance with LV FPGA: http://zone.ni.com/reference/en-XX/help/371599H-01/lvfpgaconcepts/using_sctl_optimize_fpga/

Could you post a screenshot of your best FPGA code so far? 

Jeremy P.

[Akello]

Jeremy,

Hello and thank you for your reply.

I've read whatever I could find on the site relating to FPGA and my particular task. Unfortunately, as you said, there is not much dealing with my particular goal.

I am away from the office now so I do not have access to my VI or the module. I will try my best to recreate what I did but for now I believe it is simple enough to describe;

Single Timed Loop connected to Derived Clock.

Case Ctructure inside Timed Loop.

Shift Shift Register compared with pin Indicator.

Number initiated at zero.

NOT Gate and pin Control outside case structure.

Number is accessesd, if it is less than 5 it gets incremented by 1 inside case structure and a TRUE is fed to the NOT Gate so pin not changed. 

When number gets up to 5, the Case Structure sends a FALSE to the NOT GATE and restarts the Number at 0.

There were two problems here. The first was that only the off state would get five iterations while the on state would get just one. This was because the zero was only reset in one of the cases. I tried to correct this and anything I came up with ran into timing errors. The second problem was that I was trying to make a basic 50% duty cycle, an adjustable one would only add more elements and cause more timing errors.

I understand that you do not have gate timing information for specific modules but what about a general guide for how they relate to eachother? For example an OR Gate takes less time than a Less Than or Equal To (something I learned by trial and error). That would really help me out in terms of a guideline.

Any and all advice is appreciated,

Yusif Nurizade

[dan_u]

Did you see this page, listing the resource utilization for several functions on the FPGA targets? Unfortunately it hasn't been updated recently so your specific target (Spartan 6) is not listed, but if you look at the documents you'll quickly get an idea on what is resource hungry.

Just a simple question, what's the data type of your counter (number)? Try to make it as small as possible, U8 or maybe FXP<+,5,5> or so might be sufficient.

Also, I don't see how 50% duty cycle should make it more complex. If you place the NOT gate in the case structure (so it only inverts the boolean when the counter reaches the number and you reset it to 0) does not use more logic than what you have now.

[Akello]

Dan,

Thanks so much for that suggestion. I will be calling NI tomorrow to see if I can get an updated RUS.

Regarding your suggestion with the VI; I've tried adjusting the numbers to U8 and still had timing errors. The initial VI that I made actually compiled without issue but was off on the scope when I ran it because of the mistake I made. Essentially, it ran the FALSE state for 5 cycles and the TRUE for only one cycle based on how I set up the case structure. I tried to fix the problem but my best shot was two case structures and shift registers and that just complicated the whole thing to a huge timing error. Ultimately this thing is supposed to adjust the duty cycle and I'm currently stuck on what would be a good, efficient, VI to handle that.

I'm attaching a snapshot of the VI that compiled with the mistake. My attempts to fix it aren't worth posting and I won't have the device for a bit so I can't do more than theoretical constructs.

Any advice is greatly appreciated,

Yusif Nurizade

P.S. I've recreated my original VI on a virtual machine, the FPGA LED was initially a IO pin.

[dan_u]

Your code looks pretty simple, can't get much simpler than that. I'm not sure about reading from/writing to the FPGA pin. Probably you could try storing the LED value in a shift register instead of reading it from the IO Node. Then you will only need the write operation.

Btw, you don't need the device in order to compile the FPGA code.

[MikeeB]

Hi

The reason you cannot go fast enough is teh case structure. Here is some code taht should do the trick as it works in parallel to calculate the next state.

Mike

[Akello]

Dan, Mike,

Thanks so much for the suggestions! I've been sidetracked with another assignment but will definitely be sure to try them out!

Yusif