Re: [oc] file organization

[Rudolf Usselmann <rudi@asics.ws>]

On Monday 29 October 2001 19:50, you wrote:
> > I would like to try to incite some discussion about how the
> > opencores IPs are organized.
>
> I'm glad somebody started discussion about these issues. I hope everybody
> will jump into this disscusion.
>
> > The two main goals, as I see them, are to:
> > 1) allow people to find already written cores
> > 2) attract people to write cores
>
> Correct.
>
> > As an example, I wrote a crc_32, but didn't know where
> > to put it.  I put it somewhere random.
> >
> > Now someone else wants to write a crc_32 with some
> > different characteristics.  What should happen?

This is a serious problem that we need to resolve. However,
I'm not certain that creating another level of hierarchy will help.

So you will end up with:
cores -> ecc_cores -> crc32

The author of an alternative implementation of the crc32 does still
have the same problem: What do I name my core ?

Perhaps we should rename the core from CRC32 to CRC32_xyz1
and then add CRC32_xyz2, where xyz1 and xyz2 is some sort
of implementation key ?

In any case, I don't think we need to restructure the main CVS at
this point as we really don't have that many projects. I believe the
latest count is 70. The projects page is in my opinion very good
now, and gives an excellent overview of what we have to offer.
However, I can see how in the near feature it will become to big
and will have to shrink it. At that point I would like to see just sub-
folders for each section.

Let's try not to over-engineer things !



> > No matter what, new authors should write IP!  But everyone
> > should benefir from everything.
> >
> >
> > Where to put cores should perhaps be obvious if the
> > project layout is clear, and if it changes to include new
> > insights about use as time goes by.  I would propose
> > that big top-level organization ideas should be done
> > by Opencores experts (perhaps those who own the
> > server) with lots of vocal argument from the mailing list.
>
> Let say that I own the box where the main OpenCores web site is hosted.
> But I think decisions how to organize the IPs should be set by the entire
> opencores community. So lets here some suggestions.
>
> FYI, initial organization of IPs (main groups such as Comm, System, etc)
> was done when the opencores went online 2 years ago (now that you
> reminded me - 2 year anniversary was yesterday).

Happy Anniversary, Damjan  !!!


.....
>
> I think the biggest challenge is to allow developers to find out how to
> start, maintain and administrate a project. I think we are not too strong
> here. Ie we need to build a serious community. Any ideas how to do it?

yes, we really should try to revisit this again. We tried to clarify it a 
while back but I have the feeling that either nobody reads those pages
or they are not doing a good job in helping people out.

> Second it is important that some IPs don't get lost. Especially since we
> are now at a point in time where we will have to start integrating the
> blocks together and we want to demonstrate integration as well as reuse.
> So for both of them IP blocks must be easy to find. For example your CRC
> almost got lost.
>
> > It's not a great idea, but is it enough to get people to suggest a
> > better one?
> >
> >
> > Second attempt to get everyone to spout ideas:
> >
> > Are the Opencores top-level projects the best?
>
> Don't forget, it is initial organization just waiting to get improved. I
> think it is time to make changes ... Lets here suggestions.
>
> > The present opencores layout has these main headings:
> >
> > Arithmetic         Communications Controller    Coprocessors
> > Crypto              DSP                                         ECC
> > Memory cores  Microprocessors                     Other
> > Prototype          SOC                                        System
> > Controller
> > Video Controller
> >
> >
> > Xilinx organizes their IP this way:
> >
> > basic elements
> >     contains logic, comparitors, multiplexers, counters, encoders,
>
> decoders,
>
> >     incrementers, decrementers, registers, latches
> > communications and networking
> >     contains ATM, SONET, ECC, telecom, encryption, building blocks
> > video and image processing
> >     contains building blocks
> > digital signal processing
> >     contains correlators, filters, modulation, processors, DPLL,

I don't see any difference here. Except I don't like that Xilinx places
ECC in communications and networking ... it's just as often used in
SoC and non comm peripherals.

We don't really have a basic element section, this is something that is 
very slowly evolving at opencores ... once we have the basic elements 
library, we should create a section for it.

....
> > I am going to make stuff up here.  I would like to see these (and not
> > in alphabetical order!  They should be in the order which leads to
> > the best understanding.)
> >
> >
> > Common Opencore Elements
> > (contains wishbone, example copyrights, example teaching code
> > conforming to the Opencores coding specifications, any stuff to support
> > assertions which
> >   people want to be widely used, any components which should be used
> >   throughout the opencores projects, and any verilog or PLI things
> >  which are of great interest, like file IO stuff for poor verilog.)
> >
> > Libraries
> > (Any libraries, imported or written, which the authors hope will have
> > wide use
> >  inside chips. These could include things like on-chip memory
> > libraries.)
> >
> > Microcontrollers, Microprocessors
> > (contains branches for the various RISC efforts, branches to contain
> > the several instances of 8051's we might get, any other complete
> > processors, and maybe the FPU efforts?)
> >
> > Peripherals
> > (contains branches for Ethernet, ATM, UARTs, IIC, PCI, AC97, Video,
> >  GPIO, PWM, most everything else which is likely to be used in
> >  it's entirity in a Microprocessor or in a system)
> >
> > Cores and Tutorials
> > (Things which are written to explore an idea, but which will need
> >  to be encapsulated or modified to be used.  I see the Math functions,
> >  the ECC stuff, and the Crypto stuff as possible sub-directories.)
> >
> > DSP
> > (because this seems to contain specialized parts which might fall
> >  into Microprocessors or Cores, but which would be hard to find
> >  if separated.)
> >
> >  Board-level Component Library
> > (Simulation models for devices needed for system-level simulation.  I
> >  dont know what people will write, but DRAMs seem likely.  Any special
> >  device needed to simulate a specific system could be parked here,
> > instead of in the originating system directory, so that other people
> > can find them.)
> >
> > Board Level IP
> > (This is stuff like schematics, gerbers, pictures of hardware, who
> > knows)
> >
> > Support Software
> > (The various microprocessor efforts need somewhere to put software
> >   or pointers to software to support their efforts.  And there are many
> >   PERL jocks and/or pre-processor users who need to bring their
> >   stuff to a common place.)
>
> I like what you said.
>
> However your proposal does have a week spot. I'm afraid that right now
> projects are more or less self contained. Meaning a project does have
> libraries contained eve nthough using the new scheme all libraries should
> be put un Libraries section? Does this mean if you want to download a
> project, it would be constructed out of different modules all sitting in
> the CVS under different top level directories. For example let say that a
> project is an open source PDA (awhile ago somebody mentioned we should
> start integrating IPs into an embedded computer or a PDA SoC - btw what
> happened to that thread?) composed out of board schematics, SoC and
> software. SoC is further composed out of different IPs. Different IPs
> might further use different libraries. Also software can have different
> parts. So how is this project put into proposed web/CVS structure?
> I agree that instead of storing entire project it might be better to put
> each piece where it belong in order to promote design reuse.


I do not like the proposal. I find it confusing. Why would crypto stuff
be in "Cores and Tutorials" ??? Several people are using my DES
core in silicon ! It's not a "research project", it's a real core !

I still like the current classifications the best !

I think there is an easy way to move to a shared library. Similar
like linux distributes it's rpms, there should be a section of required
libraries and sub-cores. I think this could be very nicely added in
the new layout of the Projects pages. All required libraries and
parts could be listed (with pointers) in the download box.

I see more serious problems with basic element libraries, as they might
not be very easy to write. I can see somebody writing a basic element
such as a decoder, and it not being very usefull, unless it is heavily
parameterized and can be implemented with ease in various FPGAs
and ASIC libraries. I would rather see us focus on more high level cores
such CPUs and peripherals ...

> > I would like to see a small and mostly fixed set of top-level
> > directories, and under them subdirectories for the various big IP
> > classes.

So why not use the current heading of the Project Page ? I think they
are VERY clear in their description, and make it easy to find things.

Again, I would not collapse the projects page yet. Wait till we have over
a 100 projects and the page gets to big !!!

Cheers,
rudi



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