VI communication, modeling bus architecture (newbie questions)

[mgenovese]

I am a new user to LabView, and am evaluating it as part of my graduate work.  I would like to architecturally model a bus subsystem using LV, as it seems useful for measuring aspects of performance, such as bandwidth, memory utilization, latency, etc.  Note that I want to do this entirely in VI, and will not be using any hardware.  It's essentially just a software model, designed in VI.

I come from an HDL background, so I'm used to authoring blocks which connect to each other via ports.  So my first inkling was to design an abstract bus master in a VI that communicates with an arbiter of some type (in a different VI).  They would be connected together in a top-level VI.

However, it's not clear to me how I can accomplish this; I don't really see any inputs and outputs that allow me to communicate between VI's (essentially wire outputs and inputs).  I'd like one VI to be this bus master, and another VI to be an arbiter.  Then It would be very convenient to then start connecting up multiple instantiations of these bus masters (given the arbiter was written correctly to handle multiple masters), and simulate to understand performance.  I think you get the idea.  Can anyone give me some guidance with regard to designing some VI's so they can communication on some type of interface boundary, and be instantiated multiple times in some object-like fashion?  I'm afraid I may not be understanding the programming paradigm here.

If anyone has done this type of architectural modeling before using LabView, I'd really appreciate any suggestions or even sample code to bootstrap me.

Thanks very much,

Matt
mgenovese@mail.utexas.edu
--

[tst]

First, I will start by saying I know nothing about what you're asking, but It is important to understand one thing first - LV is a programming language, just like C++. It is not a design or modeling tool.

That said, I will add that this does not sound like a trivial exercise in a language you do not know, nor does it sound like a trivial exercise (scope-wise) even if you know LV. Additionally, your suggestion is not clear to me. Do you want to create a software simulation of the bus in LV and then write a program to test that simulation (and eventually the real bus)? LV provides several ways for talking between VIs and writing master\slave programs, but that would be hard to explain without more details.

The first step would be to learn about LV. I would suggest that you start by searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. If you can go through any kind of course or get a book, even better. In addition, I suggest you read the LabVIEW style guide and, for some heavier reading, the LabVIEW user manual.

If you are already past this point, you can try asking some more specific questions, and I'm sure people will be happy to help you. Or maybe someone who knows about this already understands your general direction and can help you.

[mikeporter]

I would say that there are certainly the tools within LV to do what you are wanting to do. Given your university affiliation, you might want to talk to NI directly about you project. The original LV design team were all UT students and there is still a strong UT presence at the company--though EEOC regulations has required them to hire several Aggies as well

But in general, the way you get data in and out of VIs is through wires you connect to terminals on a connector pane. In additon, the language implements queues, semaphores and many other things that might be of use in this endeavor.

Mike...

[Ben]

I as well am not clear on what you are trying to develop. I will throw out some ideas that pop to mind from your question.

LV uses a dat flow paradym that makes me want to turn this project inside out from how you envisioned it.

I would first desgn the "bus". It could be implemented as a action-engine.

All of the things you would do dto a bus would be done to the action-engine init, Interupt request, bus granted, bus write, bus read, release bus, etc.

The bus arbitrator could be astand-alone thread that waits for bus interupts (queues?) and grants control by acting on the bus.

Bus masters would assert interupts (using the bus) and monitor the bus looking for its ID as having contorl.

blah, blha, blah...

It would be a nice exercise in resource sharing,

Ben

[mgenovese]

All,

First, thanks very much for all the suggestions and insight.  It helped a great deal.  The links provided by tst in the first response gave some good training material.

So I do understand that LV is a programming language - no mixup there.  Just like SystemC can be used for modeling parallel systems in C++ (though C++ along works well if you don't mind writing a simulator kernel), it seems like LV has the same capability with a graphical programming paradigm.  As mentioned by Mike, the included queues and other control and data structures are analogous to the C++ STL in many ways.  So it's quite interesting to learn as I start testing some LV implementation of my transactional model of a bus subsystem.

I have been able to create a bus master Sub-VI, and in it assemble free-running TX and RX queues (i.e. in their own while loops / threads), and am working on some simple logic for making requests and handling grants from the arbiter.  It seems like the best way to approach it is using a state machine in a while loop of the master.  Additionally, for passing data between the master and other bus components during the transaction, I am planning to use the queue names (strings) as outputs of the master, such that other bus components can use that string to get the reference back to the queues for popping out or pushing in data.  Is there a better way to accomplish this?  (Sub-VI references for queues in other Sub-VI's)

I have a top-level VI where I have instantiated two of these masters using the same Sub-VI - one named "P0" and one named "P1".  Their internal TX & RX queues are based off those names, so they are uniquely named.  However, when the Front Panel (for the masters) display appears during simulation, I only see either the Front Panel for either P0 or P1, but not both.  Again, coming from an OOP background, instantiating two Sub-VI's would lead me to believe I'd see two Front Panels for those Sub-VI's (one for P0, one for P1).  What am I missing here?

As for the very last response, can you elaborate on the term "action-engine"?  Is this a LV-related term, or a general term for the "bus"?  I'm trying to distinguish how we are thinking of the implementation differently, because from what you described, it sounds similar to what I envisioned.  Essentially, a free-running (i.e. separate thread) "bus arbiter" that handles requests from all the masters, and determines who to grant to.  In turn, each master is running in its own thread (actually with several threads each under the hood), asserting requests and reacting to the grants from the arbiter, and performing data transfer according to some protocol I develop.  Is this different than what you described?  It's a similar same approach as I'd use in an HDL.

Again, thanks for all the input - much appreciated.

Matt
--

[tst]

I see that Ben has caught on to your idea, so you're in good hands now.

I still don't understand the stuff you're talking about, so I will just make a couple of comments which will hopefully help the discussion:

I don't know SystemC, but I would like to point once again that graphics you're seeing on the block diagram are the code. The binary representation of the diagram is translated directly to machine code. While LV does have some tools to automate tasks (Express VIs, State Diagram Toolkit, GOOP wizard), most of the work is done by writing and debugging code just like in any other language. It seems you understand that LV is a full-featured compiler, so perhaps it is my lack of C++ knowledge that prevents me from understanding what you mean when you talk about LV's ability for modeling. If you were refering to the parallelism, that's not modeling, that's practically writing the code in parallel - if two things on the block diagram are not connected, they will execute in parallel, and it seems you've understood that as well.

Another thing I'm having trouble understanding is your level. You clearly know about programming (C++), and it seems you're new to LV, yet you talk about concepts which, for most people, require some experience with LV before being implemented. Perhaps you're applying terms you brought from C++ to LV and that's what's throwing me off. For example, your use of the word "instantiated" seems a bit weird. In LV, it's usually used when calling things dynamically. In your case, it seems you've simply placed the same subVI on the block diagram twice. In this case, you will not have 2 seperate threads, but the same VI will run once for each place (unless you make it reentrant and then you can only have one FP for it).

My suggestion to you is to post the code you've already written. Knowing Ben, I can tell you this will probably get you a much better answer from him.

It sounds like you could be a good contributor to this site once you get the hang of LV. It can be rewarding and fun. Try checking out the BreakPoint for some of that fun.

[Ben]

I was just responding to your idea and trying to answer in kind.

An action engine maybe a LV only term, not sure.

It is a term that its applied to a VI construct that encapsulates related data operations. At teh heart of an action engine is a case structure that let callers of the action-engine VI to specify a desired operation. All bu the most simple action-engines use a loop structure to support static data that persist from call to call.

i posted a simple action engine example in this thread

http://forums.ni.com/ni/board/message?board.id=170&message.id=123721&requireLogin=False

As I mentioned earlier the actions would be specific to the bus you are trying to model.

The queues would not fit into any bus designs I am familiar with and would probably go with some similar to real hardware where it effectively pools the status of the bus at specific times.

Attached is a llb that shows a first guess at a bus that resembles an "Unibus". I have thrown together a action engine called "bus". it stroes the stae of the bus lines and allows callers to monitor and manipulate the bus lines.

The Bus-Demo Vi has a start at an arbitrator. It first inititalizes the bus and then watches for an interupt request. If a interupt is detected it determins who requested the bus and grant the bus bus.

I will let you put together the bus master which should assert the interupt and provide its ID at the time of the request. Once should then use a "Check Bus Grant" until it sees it has been given the bus. It should then set its addrees and data lines (two operations) and then assert address valid.

Anothoer loop should do the work of the slave address that watch the address valid line and when it sees its address, respond by setting or reading the data lines and setting address ack'd.

The maset should then relesase the bus and this will signal the arbitrtor that it can service other interupts.

Have fun,

Ben

Message Edited by Ben on 07-10-2005 06:15 PM

[mgenovese]

Ben, tst - thanks again for the advice and sample code.

Just for some background, SystemC is just C++ that has a simulator kernel built-in, such that you have can logical threads running concurrently (not OS threads, but "logical threads" which are managed by the event-driven simulator).  I believe this gives you the same type of parallelism that you have in LV VI's (e.g. adjacent unconnected while loops that run all at the same time.)  Similarly, in Verilog, if you have two "always @" blocks, they run concurrently / "in parallel" in the same fashion. 

Back to LV - so I think one of the gotcha's (or "got me's") was that the Sub-VI's were not reentrant by default.  When I said "instantiate", I was thinking like an SystemC / Verilog programmer, such that the Sub-VI would be free-running and run in parallel to other (same) Sub-VI's being used without local variable collision (i.e. reentrant).  However, from what I understand, unless it's reentrant, it seems that if one Sub-VI is running in a given time-step, any other attempt to use another instance of that same Sub-VI will be blocked.....an implicit mutex to avoid local variable collisions.  So the first thing I did was make my "master" Sub-VI reentrant so they can be instantiated multiple times and free-run like I originally expected them to.

Also, Ben - the queues I was using were for data transfer storage.  As data is sent from the master, or received by the master, the outbound/inbound data could be queued up.  This would allow for interesting performance measurements during simulation....  most basically, how does the queue depth affect performance of the system?  (i.e. are there latency bottlenecks because the data can't be fed fast enough to the bus.)

So after a number of nights looking at what I've learned so far, I'm wondering if this is the right path to go down.  I don't mean this in a negative way, but because I'm so new to this graphical language (though generally I think I understand how it works), I keep thinking how quickly I could accomplish the same task in hand-written code because I already know the language.  The reason I wanted to use LV (besides a professor's suggestion) was to use the graphical measurement & analysis capabilities of the language and environment.  Incidentally, I look at this graphical programming, and think that if I was really fluent with the language, I could possibly code more quickly than in C/C++.

One option:  I understand there is an LV to C/C++ interface available, though I'm even more novice w.r.t. this interface.  I wonder if this approach would be best.  If C/C++ code is written once, and instantiated multiple times in a VI (assuming this can be done), does this mean the code runs in parallel in the same manner as normally done in VI's?  I'm thinking perhaps I could write the code in C/C++, and then instantiate it at the top-level and connect them up.  Perhaps it's just that easy, but then again..... 

Do you all have any experience with this approach?

Sorry for the zig-zagging I've been doing with these posts.  You're granted a perhaps an unanticipated view into my thought processes as I waver on how to use LV for something perhaps not originally intended.

Thanks again to you all for the help.

Matt
--

[tst]

Here is a quote from app note 114, which deals with multithreading in LV:

A few nodes or items on the block diagram are synchronous, meaning they do not multitask with other nodes. In a multithreaded application, they run to completion, and the thread in which they run is monopolized by that task until the task completes.
Code Interface Nodes (CINs), DLL calls, and computation functions run synchronously.

This means that you can't make 2 seperate DLL calls and have them work at the same time. One of the nodes will have to completely finish running the DLL before the other can start.

Another option which should work is running a C++ Executable file. The problem there would be to communicate with the C++ apps. There are several ways, from using a DLL to ActiveX to TCP, but you will need to know how to implement them on both sides. This is usually very easy on LV's side, but the problems will probably be in ensuring a connection and in getting the data properly from one program to the other (endianess, data types and such).

LV is very versatile and it's good when it comes to things like communication and synchronization. The only thing is that you need to know how to do it in LV. Stick with Ben and he can probably help you. Also, I will suggest once again that you post whatever code you have. This will help in seeing what direction you're taking.

Once again, you may wish to watch your language. Your use of the word "instantiated" is still confusing in LV, because, as said, it's usually used in LV when calling something dynamically. Since you simply placed the same VI twice, we can simply describe it as that - calling a reentrant VI twice. Another example - "an implicit mutex to avoid local variable collisions" - I understand what you mean, but this can once again be confusing. In LV, the wires are usually used as "the variables". Controls and indicators can also be used as variables, particularly if they are accessed through "local variables" (you see how this can be confusing?). I understand the "local" is seperate from the "variable collisions", but such things can still be confusing. That's why showing the code will be a good idea.

[Ben]

tst wrote

"Also, I will suggest once again that you post whatever code you have. This will help in seeing what direction you're taking."

Ditto that!

I am done guessing. Post some code if you want us to help with your project. In LV a picture is worth a 1000 lines of text.

Ben