Source Files and Project Structure
Each source file and header file should include at the top the following header:
/* * TU Eindhoven * Eindhoven, The Netherlands * * Name : Put filename here * * Author : Name of first author (E-mail address of first author) * * Date : Put date of first version here (format: dd-mm-yy) * * Function : Give a short description of the function implemented in * this file * * History : * 21-04-09 : Initial version (Sander Stuijk). * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the * Free Software Foundation. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * * In other words, you are welcome to use, share and improve this program. * You are forbidden to forbid anyone else to use, share and improve * what you give them. Happy coding! */
Whenever a change is made inside a file, the History field in the header should be extended with the date at which the change is made and a short desciption of the change. At the end of the description, you should add the name of the person who made the change between pararenthesis.
All files that are automatically generated during the build process should be placed inside the build dictory (Linux platform) or inside the visualstudio2010expr directory (Windows platform).
All files and directories should be assigned names that clearly describe their functionality.
An attempt should be made to assign unique names to files and directories. Using unique names simplifies the integration of new source code files inside MS Visual Studio projects. Whenever the use of a unique name would lead to a non-logical name, this rule may be ignored.
The root directory contains a separate directory for each Model-of-Computation that is supported by SDF3.
All source code files related to a particular Model-of-Computation should be placed inside the directory that corresponds to this Model-of-Computation.
Each Model-of-Computation sub-directory must contain the following sub-directories and each directory must contain the source code related to the specified aspect.
|base||Basic data structures used to store and manipulate dataflow graphs.|
|analysis||Dataflow analysis algorithms.|
|generate||Random graph generation algorithms.|
|output||Functions to convert dataflow graph to different formats.|
|resource_allocation||Dataflow mapping and scheduling algorithms.|
|transform||Graph transformation algorithms.|
The source code contained in all directories expect the tools sub-directory will be compiled into a run-time library. The tools sub-directory is the only directory that may contain source code that is compiled directly into an executable.
The tools sub-directory must contain the following sub-directories. Each sub-directory must implment the described functionality.
|base||Basic data structures and functions used by all tools.|
|sdf3analyze||Dataflow analysis tool.|
|sdf3flow||Dataflow mapping and scheduling tool.|
|sdf3print||Dataflow conversion tool.|
|sdf3generate||Dataflow random graph generation tool.|
|sdf3transform||Graph transformation tool.|
The source code inside the tools sub-directory should contains as litlle algorithmic aspects as possible. Preferably it should only contain code to initiliaze the required dataflow structures and call the functions from the libraries.