Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic TAU (steve huntington)
Decrease font size
Increase font size
Topic Title: SDL Process export to C
Topic Summary:
Created On: 1-Nov-2006 11:36
Status: Read Only
Topic Rating:  Terrible (1 ratings have been cast)
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 1-Nov-2006 11:36
User is offline View Users Profile Print this message


Tim Langgaertner

Posts: 4
Joined: 14-Nov-2005

Hello, I want to use the funktionality of a process which was specified with SDL. Generating an executable from the whole system will need to much resources. Is it possible just to export a process to C. I will bind these in an existing C environment. In detail: I specified a protocoll with SDL and now I want to evaluate the performance in a large scenario with OPNET. Therefore several instances of the entity running the protocoll are needed. The protocol should run in every entity and not as several external programs for the entities. I prefered to embed the protocol in OPNET by simple function calls. There will be only one signal with a set of parameters as input. This will result to one or more signals of the same type as output. I failed by trying to seperate the functionality from the SDL generated C code. Tanks for help. Kind regards, Tim
Report this to a Moderator Report this to a Moderator
 2-Nov-2006 11:38
User is offline View Users Profile Print this message


Ian Barnard

Posts: 91
Joined: 4-Jul-2002

Tim

We don't formally support this sort of use of code generated from SDL, but it is probably technically possible.

To do it you will have to provide a modified Tau kernel (the source code is provided in the installation) which integrates to OPNET instead of e.g. Win32, and provide an 'environment' which allows OPNET to inject the signal into the modified kernel (through xInEnv) and which takes outputs signals from the SDL-generated code (through xOutEnv) and sends them to OPNET.

We have experienced consultants who can help with this customisation; please contact your local Telelogic sales office.

HTH
Ian

-------------------------
=============
Ian Barnard
Principal Consultant
Telelogic UK, an IBM company
Report this to a Moderator Report this to a Moderator
 3-Nov-2006 07:12
User is offline View Users Profile Print this message


Dinesh Kumar

Posts: 3
Joined: 9-Aug-2005

Hello Tim, As per my understanding of your description, there is a working SDL model which has a process of your interest and you need the code for the process to be generated into a different C file. If so, you could try with setting the Separation to Full. (SDL Suite --> Generate Menu --> Make Dialog --> Separation : Full). Another way of doing this would be to Right Click on the Process in the Organizer --> Generate --> Edit Separation --> Separate File, separation name. Hope this helps. Dinesh Senior Application Engineer Telelogic India

-------------------------
Dinesh
Senior Application Engineer
Telelogic India
Report this to a Moderator Report this to a Moderator
 3-Nov-2006 10:07
User is offline View Users Profile Print this message


Tim Langgaertner

Posts: 4
Joined: 14-Nov-2005

Hello Ian, If I understand your approach, I would generate a program out of the SLD code which will communikate with my existing C-code. This is the way I want to avoid. I will need several instances of the SDL program which need a possibility to communicate on dynamic generated phaths. Hello Dinesh, I think you well understood me. I also tryed a lot with the seperation funktionality of SDT. And right, I accomplished the sepereation of the code of the process. BUT the generated code seems to consists of defines and macros. I don't know where is the entry point, what statement should I call? I hoped there is a way like the approach above with a fuunction call (like the xInEnv() ). Furthermore I expect that there will be a large number of SDT libaries which I will need. Lot's of terms seems to be predefined by SDT. I relocated parts of my specified functionality, but I don't found the point where all the filaments come together. - Thanks for help -
Report this to a Moderator Report this to a Moderator
 3-Nov-2006 13:00
User is offline View Users Profile Print this message


Ian Barnard

Posts: 91
Joined: 4-Jul-2002

Tim

No I am not proposing generating a program out of the SDL code.

You can get a file containing generated code for the SDL process in at least two ways: either by generating code for the complete system using separation as Dinesh suggests, or by simply only generating code for the process you are interested in (select the process in the Organiser, then generate code).

Having got this code, you really need to compile/use it unmodified - for example so that you can update the SDL and generate code again and very easily build this new code into your OPNET environment - and the easiest way to do this will be to compile it exactly as it would be compiled when running the code normally. To use the code you need a) a way of calling it, and b) some code/headers which resolve macros and satisfy the API calls the code makes. By far the simplest way of doing this is to simply compile and link it exactly as would normally be done for example by the standard SDL build process using the generated makefile - although obviously at the link stage there will be something different about the build because it should be linked with OPNET code.

"But how does this approach let me integrate it into OPNET?", I hear you asking. The code generated from SDL Suite runs on top of something we call the kernel. This automatically solves both a) and b) in the previous paragraph. The kernel is provided as source code because our customers need to compile it for their target environment, and because it often needs to be changed in minor or major ways to adapt to the target environment. In your case the target environment is OPNET and modifying the kernel is almost certainly the easiest way for you to build code generated from SDL into OPNET.

In the simplest case, the kernel expects something (normally the target environment OS) to provide facilities for memory allocation (for signal buffer allocation/freeing) and timing (for SDL timers). In your case you would modify the kernel to utilise whatever mechanisms OPNET uses for these situations. If your SDL doesn't use timers then you should be able to stub this out. Obviously the default kernel also provides main() and I assume in your case this would be handled by OPNET, so this is another area needing adaptation.

The final piece in the jigsaw is how the 'SDL' code will communicate with OPNET. We call this the 'environment' code. This always has to be implemented specifically for the target environment - so you will have to code it - usually involving writing a few functions of which the most important are xInEnv and xOutEnv, respectively feeding signals into and out of the 'SDL'.

How might it work? In overview, the 'SDL' would be executed by OPNET code calling a function in the kernel which 'runs' it to execute one transition - let's called this function 'ExecuteSDL()'. This polls the environment function (which you have implemented) xInEnv() which should pick up signals destined for the 'SDL', maybe from a buffer. In response to these signals, the 'SDL' will call the environment function (which you have implemented) xOutEnv() with any response signals, and the environment code for xOutEnv() should send these to OPNET by whatever mechanism - maybe storing them in a buffer, then xOutEnv returns, and ultimately the ExecuteSDL() will return and control can pass back to OPNET, at which point the buffered return signals can be injected into OPNET. I don't know the details myself but you will have to make sure that ExecuteSDL is called enough times to make sure all the transitions which result from a particular input signal have been completed - i.e. that the SDL is back to waiting for the next input.

If you need more detail than this, or onsite help, you should contact your local Telelogic sales office and talk to your account manager about getting consultancy assistance. This can make a real difference in helping you to make much more rapid progress than if you had to learn and understand all the technical details yourself; our consultants are expert in doing different integrations of SDL generated code to different targets, and in a few days could do work which might take you weeks or months to learn, understand and develop yourself. Also they know the best approaches to take which greatly helps in avoiding unexpected problems. And of course they free you up to worry about your problem - getting the right traffic model analysis - rather than worry about some detailed technical details of how SDL code gets executed.

HTH
Ian


-------------------------
=============
Ian Barnard
Principal Consultant
Telelogic UK, an IBM company
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic TAU forum.
There are currently 1 users logged in.
The most users ever online was 15 on 31-Mar-2008 at 16:22.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.