[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] file organization
> 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?
>
> 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 bythe 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).
>
>
> 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.
I understand reasons for this. But I'm kind of afraid that too much
hierarchy will prevent _fast_ access to the "goods". Somebody browsing the
IPs will spent more time browsing the hierarchy. Maybe I'm wrong ...
>
> 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.
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?
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 demostrate 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,
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.
Me too. I like Xilinx approach. I think it is well thought out. Mentor looks
pretty much like existing opencores organization of blocks.
>
> 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 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.
>
Again, generally I like the idea. But like to hear what others think.
> 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.
I think having two three might be too much of an adiministrative task. I
think it would be better to discuss this thoroughly on the mailing list and
implement the best ideas.
regards,
Damjan
>
> 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
>
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml