Re: [oc] file organization

[Rudolf Usselmann <rudi@asics.ws>]

Hi John !

On Tuesday 30 October 2001 10:07, you wrote:
> The question of file organisation is
> related to what I have just posted on
> a server for cores.  I spotted this thread
> after my server post.
>
> Some suggestions.
>
> 1)
>
> Instead of a simple heirarchy, I would suggest using
> a relational database.  For example, a cordic core
> should have the property 'cordic' attached to it.
> That way it could be grouped with all other cordic
> cores.  At the same time alternative groupings would
> be possible such as behavioural, structural, vhdl, verilog,
> pcb design and so on.  Everything that can be done with a
> heirarchy can be done with a relational database (+ lots more).
>
> The existing heirarchical opencores web pages could be
> generated automatically from the relational database.
>
> Irrespective of what format it chosen, it should be able
> to be easily manipulated by a machine.

I'm not sure why you need a relational database for file storing
and organizing them on opencores. I can see such a database be
usefull for searching, but no additional benefits from organizational
point of view.

As I have stated before, I thing the Projects Page gives a very
logical and clear overview of available cores. When it gets to big,
we will have to colapse the listings in each category, and only
display them when one clicks on the category title (or have some
fancy Java script that will show a pop-up window with all cores in
a sub-section when the mouse is above the sub-section title ...)

If I remember correctly, the original file-organization thread was about
a common directory structure withing a core depository. The goal was
to have a common structure, to ease using various cores from OpenCores,
and to have a joint and common structure. With the new directory layout,
a user has to learn it only once and then should be able to use any core
with great ease.

> 2)
>
> The key to reuse and inviting people to extend existing
> work is *CLEAR* CONCISE DOCUMENTATION.
>
> Perhaps a generic interface language (such as the C++
> ABI) could be used to document the interface to each core,
> encouraging reuse?

I agree about the documentations comment. However, how can we
convince people from all over the world with different English skills
and tools, to follow the same "standard" ? Even the big companies 
have docwriters, because it is not necessarily very easy for an
engineer to describe his/her device in a language that is clear to all.
(Look at my docs ;*)

I think we have stated in several places that all cores *should*
be documented, but I don't see how we can enforce this discipline.

As to the interface, I don't understand your comment about C and ABI.
We have something similar that would apply to hardware: We agreed
that all cores *should* interface to WISHBONE. This will ensure that
cores that follow this recommendation can be easily reused within
the OpenCores community. Again, it is very difficult if not impossible
to enforce this. I'm not even sure we would want to. Somebody who
is a big fan of the CoreConnect standard, might prefer to use it instead
of WISHBONE.

Personally I prefer to have as few "laws" as possible. However, I think
we should provide guidelines. The guideline should guide people who
are undecided and help them to create usefull cores that can be integrated
with other OpenCores cores. However, forcing such "guidelines" is
in my opinion the wrong path.

> Best wishes
> John
> --

Lets keep it simple !!!

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