A new way to define systems of systems?

You might want to think of a new name :)

Yes. Too bad. I kind of liked SMIL.

-Rich

At this point, I believe all pronounceable acronyms up to and including four letters long are taken.

You might want to take a look at telegraph shorthand codebooks from the nineteenth and early twentieth century. Businesses frequently used such codebooks to reduce costs of sending a telegram. Words that could be read aloud were cheaper than random combinations of letters; hence there were published large codebooks of pronounceable non-words.

When you opened this thread I got interested but it seems your idea of high level is up to the point where I would start in with psuedo-code in Forth. High level definition of systems tends, in my mind, to be like the Hatley and Pirbhai structured design methods. Useful for being able to be inclusive of the human elements of a system as well.

Actually what I'm trying to do is to solve a problem that I have seen often in the past and for which I have seen no good solution. I wanted to model the data flow between systems that make up a complete system. But more importantly, I wanted to be able to generate code that implemented the model directly.

Often, communication between systems is represented at a very low level. I've tried to turn that upside down and make the communication definition occur at a higher level. SMIL is very much like your Forth pseudo code, I suppose, except that it isn't pseudo code. It is translated into C and then executed directly.

SMIL (or whatever this thing's name becomes) is a work in progress. Or maybe just an idea that won't go anywhere. I appreciate the fact that you took the time to look at it.

-Rich

Your goal is definitely intriguing. But there are a couple of things that I am not sure of -

1. In a distributed environment, you do not want centralized control. Therefore, the only thing standard between the two devices is the interface. So a unified tool to describe the devices seems kind of skewed from the basis.
2. If a goal of SMIL is to describe an interface and then generate any logic for it straight from C. Isn't this one of the goals of SystemC?

Am I missing something? Best regards, Sanjay

Which is what the Hatley & Pirbhai Structured Design methods were intended to do with the exception of the code generation part. Then some of the UML style modeling tools take over from there as I understand it (although I have never used them).

Considering that I have seen communications between systems modelled at various levels I think that your use of the term often is hardly applicable.

Forth psuedo code can, with little effort, be translated into working Forth based systems. It is only a short step to make from there. The other modeling is often at a higher level of abstraction and is more useful when speaking to clients about their requirements.

As I said, the initial post raised my interest but the linked document dashed any other notions about techniques that may be more useful than what I am currently using at any level.

fpgabuilder wrote: [snip]

Great questions. Part of my problem is explaining what I'm trying to accomplish, I think.

A little background. In my day job I work on a fairly complex medical device that is made up of an operator's console and image reconstruction system that is Linux based. This connects to the actual patient scanner via an ethernet connection to an SBC running vxWorks. Part of the system rotates about an axis and has its own SBC running vxWorks. Both the stationary and rotating sides of the device talk to a variety of other subsystems via Ethernet, CAN, and serial ports.

The interfaces between the systems are currently described with C header files. A lot of code is present on the two SBCs to translate the TCP/IP messages coming from the operators console to forms compatible with the non-Ethernet communication links.

SMIL is an attempt to unify the definition of the communication paths throughout the entire system. It is designed for distributed computing but my emphasis has been on systems of the sort I just described. Pats might come up and go down asynchronously, but generally most of the parts need to be present for the device to function.

I wanted to be able to do semantic checks on the interfaces. SMIL will check that a data packet (a SMIL event) which is generated in a part of the system is consumed in another part of the system, for example. In general events are broadcast in SMIL: You don't have to explicitly say where the event is being consumed. This decouples the system to a great extent, obviously, making for what I think is a cleaner system design. SMIL doesn't really do broadcasts, however. During system generation it can see where events flow and generate code to send the events from the source to the destination(s) automatically.

As to point two, Yes, SystemC can generate code for FPGAs. SMIL's main emphasis is the communication paths between the systems. To that end there are facilities to detect when subsystems power up and go down, trace events, do endian conversions, etc. that are not (I think) directly available in SystemC. Also, SMIL is (or will be) open source. I don't believe that's true of SystemC.

Thanks for the questions.

-Rich

Just a question out of curiosity: Are you familiar with 'Strategies for real-time system specification' written by Hatley and Pirbhai?

The book basically describes a method with which you can link and verify data flows together with the state changes in a complex system.

The only thing that worries me is: yet another language... Can't you make the SMIL language fit inside the C-like syntax? This makes it a lot easier to get started with (see the succes of Java, C# and PHP). It would also be a lot easier get a parser (don't forget the pre-processor for includes, conditional compilation and defines!).

Nico Coesel wrote: [snip]

No, I'm not but it is becoming obvious that I should be, since it has been mentioned by both you and Mr. Bennett. I'll look into it.

Maybe that would be a better approach. I do have a C preprocessor sitting around from a previous project...

I did want to make the definition of the interfaces language independent, however, so the the actual implementation language could be C, C++, Java, VHDL, or something else. Maybe that is too ambitious a goal.

My background is in both embedded systems and in compilers. Last fall I started playing around with a compiler generation tool called Elegant and got off on a tangent which resulted in SMIL. It has been fun for me, at least as a thought experiment.

-Rich

Actually SystemC is open-source and I may just be able to do everything that you are doing in SMIL with a C++ library. The interfaces would plug straight into your code that is running on individual SBCs. Synthesis maybe a problem. I'd be curious to know things that you are able to do with SMIL that you cannot do with SystemC.

Best,

-sanjay

I think I didn't describe what I'm trying to do very well. The way I see it, SMIL would be used along with something like SystemC.

I really wanted SMIL to describe interactions between systems. The functionality of the systems would be created using currently existing tools with SystemC being an example of one.

SMIL is less of a language and more of a tool that allows you to describe interactions. SMIL then generates a communication library based on your description. SMIL currently uses TCP/IP as the communication medium, but eventually I'd like to support other communication paths such as CAN, serial ports, etc.

What I'm really trying to do is define a way to send messages (SMIL events) between these heterogeneous systems as simply and cleanly as possible. When I talk about VHDL generation, I mean I'd like to generate VHDL glue that would all events to pass directly to FPGA hardware.

For example: Let's say a system consists of a Linux box and an Altera FPGA running a NiosII and eCos (I use this example because it's sitting on my desk ;-)

Today, SMIL can generate code for both the Linux box and the Nios system and these two systems can communicate with each other. Nothing fancy here, but SMIL also generates code to do event timing, tracing, etc. which helps me look at performance bottlenecks, etc.

SMIL also can generate code to create threads of execution. In one example I'm working on I have 16 threads of execution and event interactions defined between them. Some are running on the Linux box and some are running on the Nios.

The SMIL code for that is about 600 lines. The bulk of the "application" code would be written in C or C++.

Where it gets more interesting for me is I'd like to generate enough VHDL to allow the Linux box to send events to the FPGA (probably through the Nios) and visa versa. Again, the main "application" code for the FPGA would be SystemC, VHDL, etc. and written outside of SMIL. SMIL would just describe and implement the interfaces, tracing, etc.

I'm not trying to reinvent any wheels. I'm just trying to address a problem that I've seen and found interesting.

-Rich

In news: snipped-for-privacy@q75g2000hsh.googlegroups.com timestamped 10 Apr 2007 08:17:32 -0700, "fpgabuilder" posted: "[..]

Actually SystemC is open-source [..]

The SystemC(R) standard is available without paying money and the reference implementation (as opposed to every SystemC(R) library's implementation) is open source.

Regards, Colin Paul Gloster

It does make sense now and I guess there maybe a value in it as you have created it from need. Did you look at ImpulseC? It is based on work by Dr. Maya Gokhale and others in the field of streams based processing.

-sanjay

fpgabuilder wrote: [snip]

Thanks for the link. I'll look into it.

-Rich