Re: [oc] file organization

[karrarh@hotmail.com]

Respected Sir

 Please send me the VHDL code for ATM mutipelxer. I will be very 
thankful to you.

Regards
karrar hussain.


----- Original Message ----- 
From: "llbutcher" <llbutcher@v... > 
To: <cores@o... > 
Date: Fri, 26 Oct 2001 02:49:01 -0700 
Subject: [oc] file organization 

> 
> 
> 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