If LVFPGA, can i avoid race conditions in a SCTL by only reading local variables

[art_]

My interest is in doing dsp in the fpga's of the reconfigurable USRP software defined radios. I hate to risk an age-old flame fest but I'm coming out of the closet: I use local variables in lieu of long wires. I know it's frowned on but when you've got reset, enable, trigger, and clock signals going to lots of blocks it can rapidly become a rats nest. And bundling things up in clusters and sub vi's only hides the mess. It's still there. And it makes re-use much harder. I've browsed the 'proper' code in the examples and it looks nice but it's awfully hard to follow the signal you most care about and it's a nightmare to change. In SDR there's usually only one data path and I don't use LV's for data, just for ancillary signals like resets, enables, etc. I always use them the same way: write to an indicator in one place (usually a block that creates all these signals) and read local variables linked to the indicator in many places. I never write to local variables. So what do I risk ? Is the compiler smart enough to see through this and wire them up during optimization?

[PiDi]

I've been doing that in FPGA designs. This is fine if you know what you're doing: you have single writer - good, you also need to consider if there could be a problem with writer updating the "variable" faster than reader consumes it. Compiler doesn't "wire" them in any way, if you need the proper sequence of writes and reads you must ensure this yourself.

Lately I've moved to VI-Defined Registers, Memories, FIFOs and Handshakes (see the snippet below), mainly because of much more flexibility. The register is practically one-to-one replacement of local variables, but without the control on the front panel, so it doesn't consume the FPGA resources to create interface when you're in the top-level VI. FIFOs and Memories doesn't need too much explanation. Handshakes are interesting - they act as single-element queue, so you get synchronization that you won't get using registers or local variables. See the LV help on those items, it provides much more information that my short post 😉

[art_]

If I do use a combination indicator/LV in the same SCTL, do the write & read happen on different clock cycles? That would be a deal breaker for anything but very infrequently changing signals like enables.

[PiDi]

Sorry, I've read your post and missed the SCTL part in the topic 😄 But now I'm a bit confused - you're using the indicator and local variables in the same, single SCTL? And you say that this is to avoid long wires? I can't exactly imagine SCTL so big that you would want to avoid wiring - could you provide any examples of that?

[art_]

I'm flattening the USRP Simple Streaming example enough to use it as a starting point for my own work. I'm just getting started but I've already run into issues. Below are 2 versions of the transmitter block diagram. The first is already a little messy but it'll get worse when I flatten the digital upconverter. But it works. The second one uses LV's to avoid some of the wires. It obviously looks better. It's easier to understand. The signal flow is obvious (the signal that matters.) Each function stands alone. All the timing junk is separated from the signal path and even that is easier to follow with well defined indicator names. This would make a way better starting point but it doesn't work. Why?

 

[Intaris · Accepted solution]

Using LVs in SCTLs add a cycle of latency to the datapath.  It's basically pipelining.  LVs written in Cycle X will only have that value read in Cycle X+1.  If all of your other datapaths are synchronised, this can be a big problem.

[art_]

Well that nails it then. And it explains why it works fine with asynchronous signals like enables but not with synchronous signals like handshaking. That's too bad. For this DSP guy the latter diagram is much preferred.

Word to NI: Give us alias's (or virtual wires or symbolic links or whatever you want to call them) that let us connect two points without wires and without registers.

And don't start with 'the spirit of labview' nonsense. I'm not conjuring dead ancestors. I'm building a radio.

[PiDi]

The behaviour described by Intaris is documented in Local Variable topic in help - I'm adding it for further reference:

Timing

A local variable takes at least one clock cycle, whereas a wire takes no clock cycles. For maximum efficiency, avoid using a variable when a wire would suffice.

And about your example: from my personal perspective the one with wires is the one I would understand and analyze quicker given the block diagram, because I can immediately see where the signals come from and what are the dependencies between the nodes. With the "locals" solution I need to search the diagram for the text, which is much less efficient (or, having the actual code, I'd need to right-click and search for the control/indicator, which still requires me to do some clicking). Remember you can also put labels on the wires if the names of the signals is what you're missing in the wired solution.

[billko]

---

@art_ wrote:

Well that nails it then. And it explains why it works fine with asynchronous signals like enables but not with synchronous signals like handshaking. That's too bad. For this DSP guy the latter diagram is much preferred.

Word to NI: Give us alias's (or virtual wires or symbolic links or whatever you want to call them) that let us connect two points without wires and without registers.

And don't start with 'the spirit of labview' nonsense. I'm not conjuring dead ancestors. I'm building a radio.

---

Then create your own method.  You can, and still be "in the spirit of LabVIEW".  https://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/td-p/503801.  Using an A/E with queues, for instance, are the closest thing I've seen to "spooky action at a distance" - although I understand they've already proved it experimentally.

BTW - with an attitude like that, you may not conjure dead ancestors, but you probably will invoke an unwillingness for people to help you.

[Intaris]

AEs won't work in a SCTL will they?