Home

Welcome to the gsim wiki! #Project Proposed directory structure

gsim/
    Makefile
    cli/
        Makefile
        public_header.h
        src/
            private_class.cpp
            private_class.h
        doc/
            Doxyfile
        test/
    com/
    sim/
    aire/
    navvie/

#Navvie Navvie is just a tool and is not part of the simulator. It generates C / CPP from UML files (Class diagrams only). Its main purpose will be to generate template code from the AIRE UML specification, but any component that has an initial design in UML can use it.

##TODO

• Python backend
• Make argument parsing code more like an interpretter, link read/write operations to function pointers and remove the op enumeration. This way multiple --read arguments isn't a problem either.
• Autogenerate CPP unit test files for all instantiatable classes (instantiatable means they do not have the isAbstract flag set in the .uml file). Attempt to autogenerate test cases for easy tests such as getters / setters / constructors / destructors.
• Support doxygen comments for classes. Autogenerate documentation for files etc. Output a Doxyfile?

#AIRE ##TODO

• Make _kind in the IIR class private, it should be initialised through the protected IIR constructor. Could be tedious though as it means all intermediate abstract classes would have to pass the parameter to its base class until the base class is IIR.
• Implement the operator[] overloading from the AIRE spec, keep the setter functions as well though.
• Check which classes I'm supposed to have an IIRBase_ class for.
• Add documentation to the UML model, a lot of the text can be copied from the AIRE specification.
• Reference counted objects. Why does AIRE make them different, can't we overload new / delete?
• Autogenerate a walker for the AIRE model. It will be very useful for... pretty much any backend. Try and make the code reusable, perhaps register a function callback for the walker for each class visited. Think of a good way of stopping the recursions at a particular node (if the caller knows it won't need anything from a particular node there is no point visiting its children... A NULL fn pointer might work, but if you need the children and not the parents you will have to provide a dummy function. hmmm this fn pointer structure would have to be rather large (about 500 classes).

e.g.

walk(IIR *root, struct callbacks *pfns)
{
    case BLAH:
        if(pfns->blah)
        {
            pfns->blah(root);
            for each child
                walk(child, pfns);
        }
        break;
    case MOO:
        // etc...
        break;
}

#Compiler ##VHDL Parser I like the look of the tree walker shown here http://www.antlr.org/article/1170602723163/treewalkers.html . It's much easier to understand than the antlr tree walker syntax. Although http://www.antlr.org/article/1100569809276/use.tree.grammars.tml says USE TREE GRAMMARS mainly because they validate the tree and avoid entangling code. ##Verilog Parser ##Symbol Table Hash the identifier to the type. Do I dare call the frontend HLANG? The frontend should use its own type system so that we can seperate Parse Tree and AST generation from the IR generation. The types should be generic enough that both Verilog and VHDL types map neatly to it. ##Tranformations Interesting section from http://www.aosabook.org/en/llvm.html :

Each LLVM pass is written as a C++ class that derives (indirectly) from the Pass class. Most passes are written in a single .cpp file, and their subclass of the Pass class is defined in an anonymous namespace (which makes it completely private to the defining file). In order for the pass to be useful, code outside the file has to be able to get it, so a single function (to create the pass) is exported from the file.

##Simulation ##TODO

• Go for a breadth first implementation, get a design unit all the way to IR and printed out as a .dot file.