Skip to content
iamscottmoyers edited this page Aug 22, 2011 · 35 revisions

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

  • 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.
  • Test the list code.
  • Get navvie to autogenerate the Makefile dependencies...or use makedepend.
  • 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;
}

#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 #Simulator ##TODO

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