Re: [Open-graphics] OGP website part 2 - project management and file formats

[André Pouliot]

Lourens Veen wrote: On Monday 03 April 2006 23:17, I wrote: There are still other issues, like software and file formats to use, but they are really part of the next stage I think. If you have any ideas on those please save them for later, or if you really can't wait, send them off-list so as to not drag this thread off-topic too much. I'm currently trying to figure out who uses the site, what they want to do, and what kind of data is needed for that and in what formats. I don't have any experience with hardware development however, so I have a few questions. First, should the hardware development process be constrained to a fixed development model? The site could keep track of the stage of each project (i.e. requirements gathering, high-level analysis/design, low-level design (HDL, artwork, and so on), production (at Traversal)) and then freeze the results of each stage as it is completed, but it could also be free-form, with some repositories for files and a mailing list and a wiki, and a bunch of developers who figure out for themselves what to do when. I suppose we need the flexibility to change the design if it turns out to have a flaw that makes implementation difficult, but we don't really want the design documents to be changed all the time while people are using them to e.g. write drivers or design other systems that will work together with this one. If I could suggest something use different granularity depending on the people targeted. User want to see a shipping date. System architect want more of a general view of the meta-bloc completion stage and documentation on the behavior of each bloc to compare with the specification. Developper want to see what feature are already implemented, and what need to be done next, with good specification. It seems to me that a hardware project would need to be a little more rigid than a software project, because once it's done it's done and you can't tell people to download a patched version, but again, I have no experience with this. What would you prefer in terms of development cycle support? Oh, and if anyone could give an overview of a typical hardware design process that would be very useful. Thanks :-). Normal hardware developpement process pass several state and reiterate some of them until your (hopefully) bug free. 1. Specification (text document, schematic) 2. Definition of the interface and the bloc(more schematic and text document) 3. Hardware design (Pcb design, logic design using HDL)(mostly text file except for the hardware schematic) 4. Software simulation (go to 3 until right)(Spice simulation or HDL simulation : text file) 5. Test on some actual hardware(go back to 3 again)(binary file) 6. Go trough 3 to 5 until you use the less component possible 7. Fabricate and ship 8. Roll in money, hopefully :) Second, which kinds of documents are typically created in a hardware project, and what formats are used? Where should these documents be stored, in a source code version management system, or is it just binary data that might as well be stored in a file system? Are there open standard formats in this arena, or do we need to standardise on a single application and its file format? Do we want to? Most document are either text or schematic in the initial design phase. When you start doing the actual project what file type you get are either text file or binary because of the tool. For management of the resulting file, habitually a CVS or something near for some file type like code and specification. For the binary file, via a standard file system coud do a great job. Since most people who need that file type need a special program to use it. I don't expect many people wan't to invest that much in software tool for a hobby. I hope it answer some of your question André

_______________________________________________
Open-graphics mailing list
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)