[oc] Automatic Core Metrics and Documentation

[Tom Hawkins <tom1@launchbird.com>]

>On Tuesday 06 May 2003 10:41 pm, Rudolf Usselmann wrote:
> > On Wed, 2003-05-07 at 13:03, Marko Mlinar wrote:
> > > Actually I just got an idea, which is by my opinion worth 
implementing:
> > > why not add 'core quality votes'. Each registered user can vote 
only once
> > > for each project. If project seems of good enough quality, that 
he/she
> > > would use it (or have already used it), he/she can add vote to 
it.
> > > Maybe we can add several counters:
> > > 1. the idea is good
> > > 2. one for looks like a good quality core, and
> > > 3. have tried it and it works

> > I'm not sure if that will work or if that is what we really want.
> > This kind of voting will be based on objective opinions of people
> > who browse through the cores. These might give a wrong impression
> > about a core (both directions) due to the lack of understanding.

> I agree voting will not show anything.
> A simpler Qualification Chart would be better.

> Code size - number of lines
> Tested against in-house testbench - Tick / NoTick
> Tested against commercial testbench - Tick / NoTick
> Documentation - None / Some / Adequate / Extensive
> Community Support - Tick / NoTick
> Author Support - Tick / NoTick
> Paid Support - Tick / NoTick
> Can be used in Commercial products - Tick / NoTick

This is a great idea and I think it could be, at least at some extent, 
automated.  For instance, each project could have a file specifying 
how to build the various cores in a project, somewhat similar to a 
Gentoo Linux ebuild.  Whenever the cores are updated, or new cores 
are added to a project, OpenCores automatically performs the "ebuild" 
to extract the following:
  - # of cores/modules.
  - # of modules compiled without errors.
  - # of modules compiled without warning.
  - Total number of lines.
  - Some basic measure of logic resource.

Assuming the cores are Verilog, this info would be very easy to 
extract with Icarus.  Of course, we could take this further and 
synthesize the cores for a benchmark platform; maybe a large 
Virtex-II using XST.  This would give us a tangable measure of area 
and speed.

This could be applied to documentation as well.  If documentation is 
written in XML based on an OcProject.dtd, any updates to the docs 
could automatically generate HTML and PDF.  Again, this info could be 
added to the metrics:
  - Project has documentation.
  - # of documentation lines.
  - Documenation is well formed and was able to generated HTML/PDF.
  - Documentation is valid, i.e., meets the DTD spec.

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.

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