OPENCORES.ORG

Our typical ASIC is 4-20K bytes of registers.

A SQL database isn't a bad choice, it's just that it elevates the
amount of effort that will be required from the developer. Version
control is a solved problem.

You might want to investigate SQLite if that's the route that you want
to go. Unless you are going to have thousands upon thousands of users
(maybe even ten thousands) it does the trick.

I chose to use the XML file and place it under version control because
it was easy to integrate into our build process. When developer X
wanted version Y of the software, it was as simple as checking out the
branch and building. The tools were right there in his development
area and the appropriate version of the register interfaces were used
to generate his source.

Just for comparison, the chip that I was working on was a 3d graphics
chip that was about 8 million gates (3 year project) involving 10 ASIC
engineers and 15 OpenGL/driver software engineers. We generated
massive amounts of C/C++ and Verilog code (probably >50000 lines) from
the document. The document itself was probably close to 10000 lines
long (XML is sickeningly verbose).

Good luck with your development, it's a worthwhile effort.

On 20 Feb 2007 13:01:50 -0000, larytet.46060479@b...
<larytet.46060479@b...> wrote:
> Our typical ASIC is 4-20K bytes of registers.
> Development time of the ASIC
> is 0.5-1.5 years.
> I think that SQL data base is inevitable.
> The team is
> 15 designers and verification engineers, may be 10 software guys.
>
> XML
> document is limited by the flexibility of the
> version manager and tools
> to render the file.
> mySQL apparently supports log, rollback and backup
> (I still investigate it)
> Indeed ability to compare different versions
> of
> the file sounds great, but the file itself is
> going to be huge. For example,
> file containing
> macros for the software guys is above 50K lines.
> Data sheet
> describing the registers exceeds 1000
> pages. We really need some data base
> and
> concurrent access to the data base. SQL sounds a
> like a natural choice.
>
>
> I do not know how unique our problem is.
> >From the answers I see that
> some cos do use
> tools like the one I described. Still there is no
> anything
> customizable enough to fit anybody.
>
> I will probably go forward with the
> project. If
> you think you could switch to it in the future
> from the proprietary/commercial
> solutions - this
> is the right time to try to define system
> requirements.
>
>
> greatly appreciating all answers and comments
> thank you
>
> >I authored
> something similar many years ago. It
> >was used to generate
> >C/C++ defines
> and functions/macros/structures
> >for register and
> >bitfield access. It
> also had a searchable web
> >frontend and the ability
> >to annotate test vectors.
> I took it one step
> >further and actually
> >generated the Verilog code for
> the register
> >interface modules from the
>
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores
>