[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] Automatic Core Metrics and Documentation



On Friday 09 May 2003 05:07 pm, Niclas Hedhman wrote:
> On Thursday 08 May 2003 05:09 am, Tom Hawkins wrote:
> > This is a great idea and I think it could be, at least at some
> > extent, automated.
>
> Yes, once you get going, there is so many things one can do. The
> problem,as always, is how to get started.
>
> > I think XML based docs are important.  It would help enforce a
> > common standard, so all docs look and feel the same.  Plus, you
> > wouldn't have to waste time with formatting and layout.  We could
> > take it so far as to specify tags to automatically draw
> > waveforms, and maybe even block diagrams.
>
> Regarding documentation, I would recommend DocBook format, as it is
> a proven format for technical documention, and there are plenty of
> tools surrounding it in the OSS arena, incl (RUDI!) OpenOffice can
> export to it directly (so I have read but not tested).
>
> Apache Cocoon is about web publishing, and Apache Forrest is a
> application of Cocoon, that does complete skinned websites from
> mainly DocBook documents, including PDF generation and much more. I
> can help out to set all of that up, it is not that hard once you
> have done it. But where is the infrastructure? I don't think my own
> servers are suitable, since they are subjected to a fair amount of
> downtime, and access speed is not that great (high latency).
>

We use DocBook for Confluence documentation and it works well, but 
only after we got it working.  The DocBook tool chain is broken in 
spots and was a pain to get up and running.  I think we finally 
settled on OpenJade for pdf gen and xsltproc for the HTML.  I'll have 
to check out Apache Cocoon, however, we didn't have success with 
Apache JOP -- not sure how these 2 are related.

I wouldn't recommend DocBook for OC for one reason:  DocBook is much 
too general.  The whole point of XML was to be able to custom build 
tags for specific document types.  We don't need the generality and 
complexity of DocBook.  But what we do need are specific tags for 
core documentation, such as specifying a core's interface:

<interface>
  <input name="clock" width="1"/>
  <input name="data" width="8"/>
  <inout name="bus" width="16"/>
  <output name="result" width="24"/>
</interface>  

It would also be very cool to use XML to automatically generate 
waveform diagrams:

<waveform_diagram>
  <waveform name="clock" type="bin">0 1 0 1 0 1</waveform>
  <waveform name="result" type="hex">00 34 34 XX XX ZZ</waveform>
</waveform_diagram>

> Another novel concept that seems to work very well is Wiki. Wiki
> allows ANY user to modify a web page, or add new ones, without any
> special access rights. Since it is backed by CVS, if a vandal comes
> by, you just unwind the CVS to before the "attack". And hackers
> like the challange, not the damage.
>
> Niclas

Wiki is a cool idea, but I'm not sure this type of freedom is good for 
OC.  The biggest problem to OC not gaining industrial acceptance is 
the lack of structure.  In a open software community, structure and 
process are not critical.  But for hardware, no high profile 
semiconductor firm will consider using an open core unless they are 
confident it has been developed under a strict set of standards -- 
there is no room for ad hoc: not in the core, nor in the 
presentation.

Therefore, I propose the following:  OC projects enter ALL information 
into an XML document that must adhere to the OcProject.DTD.  This 
includes:
  - General Information
  - Project News
  - Core(s) Documentation
  - Module Information and Compile/Build Constraints
  - Testbench Information

>From this one document (which can be spread across multiple files), OC 
will automatically generate the following:
  - The Project Webpage
  - Documentation (HTML and PDF)
  - Links to CVS
  - Metric table of compilation results (warnings, errors, size, 
speed, etc).

This will give each project the same look and feel derived from the 
common standard, and hence, convince industry and OC is not an ad hoc 
organization.

Regards,
Tom 

-- 
Tom Hawkins
Launchbird Design Systems, Inc.
952-200-3790
tom1@launchbird.com
http://www.launchbird.com/


--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml