[oc] file organization

["llbutcher" <llbutcher@veriomail.com>]

Folks:

I would like to try to incite some discussion about how the
opencores IPs are organized.

The two main goals, as I see them, are to:
1) allow people to find already written cores
2) attract people to write cores

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?

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.


The second goal is harder, because I think we need
to try to have an organization which invites people to
do their own implementation of an already-existing core.

Writing a core is the best way to learn the subject material.
Alternate cores will each have special advantages.  Plus,
if we have alternate cores we will be able to run them
together to compare the correctness of the cores.

This is where I want to get you to send in suggestions.


I would like to suggest that all projects existing and contemplated
be PUSHED DOWN ONE LEVEL OF HIERARCHY.

For instance, the present scheme is Arithmetic core -> CORDIC core

It should become Arithmetic core -> CORDIC -> CORDIC core.

This would allow a new author to write another CORDIC core, and
have an obvious place to put it.  This should induce more people to
write IP, even if they contemplate writing stuff which overlaps with
existing cores.

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?


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, transforms,
building blocks
math functions
    contains adders, subtractors, comparitors, complementers, CORDIC,
dividers,
    reciprocal functions,  format conversion, integrator, multiplier, square
root,
    arythmetic and logical unit, building blocks
microprocessors, controllers, and peripherals
    processor peripherals, processor cores, uarts, building blocks
standard bus interfaces
    PCI32, PCI64, PCMCIA, other, other standard interfaces, building blocks
memories and storage elements
    CAMS, FIFOs, RAMs, ROMs, delay elements,  registers and shifters,
building blocks

Their partners provide Color Space Conversion, DCT, Reed-Solomon, T1/E1, and
other IP

Mentor organizes their Inventra cores this way:
Communications, DSP, Microcontrollers, Microprocessors and Peripherals,
Multimedia,
Storage, Wireline Communications

They have a very nicely formatted document listing all of their IP by more
detailed headings.


Lets be honest.  None of these are bad, and none are better than the others.
What can Opencores swipe to become the best?

I would like to see Opencores organized differently, to try to help
new authors know where to get common building blocks, and to
try to help them know where to put new projects.

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 would like to see a small and mostly fixed set of top-level directories,
and under them subdirectories for the various big IP classes.

Under those sub-directories, I would like to see a second level
of indirection to try to leave room for alternate implementations.

And finally the directory roots of individual efforts, managed by
the IP teams.

To get this to work, there should be a second parallel tree made
for the present IP, to try to see how things fit.  Then, if everyone
thinks it is better, we can start using the new tree as the preferred
one.

That's it for tonight.  Can anyone think more clearly about this and
suggest a better scheme?

Blue Beaver


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