Hi all, > > One of the problems in the code is that there is a serious lack of design > documentation. So, the important concepts and reasoning behind implementation > choices are stored in grey matter rather than publicly accessible binary form. > > While this is understandable for a project mostly done by a single person, > it makes it increasingly harder for others to join.
I agree with that. I was very impressed with how well GHDL works, such that I've decided to make it the current working horse (after some experiences with modelsim and isim). Eliminating bugs in the opensource tradition (if something is broken, go fix it yourself) has been difficult for me though, since I don't know Ada. Using gdb I can only tell WHERE it happens, but not WHY it happens (unless I go down to assembly ...aargh!) Changing working horses right now is no option for me, even if the LLVM approach sounds hot. > Anyway, the biggest obstacle in maintaining GHDL is the lack of documentation, > both at the code level and at the design level (description of file formats, > run time interfaces, generated code models). For any rehosting or other major > updates, starting with writing this documentation, through reverse-engineering > and study of the code, is the best first step. > I've run some of the code through Doxygen, see Doxyfile at http://section5.ch/files/ghdl.Doxyfile.gz Just copy to ghdl source tree, gunzip, rename to Doxyfile, run "doxygen". There's some abuse going on by mapping .adb files to VHDL code, so far it does not seem to make doxygen choke, but I don't know if it's fully parsed, either. Probably some of the options can be tweaked to produce better results. I just used it to quickly get a cross reference. So the next job could be to do a git based fork and start the documentation project. Someone (with more GHDL experience) willing to take the hat or the seashell? Cheers, - Strubi _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
