Hello, I posted previously on what apparently is a "dead" mail list. So i follow advice of Jamil Khatib and resend the e-mail here. I am looking for a data base with WEB interface allowing to track modules, registers and bit fields. Preferably open source, Linux based, running some kind SQL data base (mySQL ?), supporting concurrent multi user access, able to generate documentation - PDF - DOC - OpenOffice docs Able to generate C header files with macros to read/write bits/registers Data base should allow to add a new device (SoC or FPGA), add subsystems to the device, specify address of the subsystem, add registers to the subsystems, add description, add bit fields definitions - size, RO/WO/RW, bit fields description, etc. Is there something like this ? We have proprietary MS Access based solution, but this thing has lot of problems, not scalable, Windows only, not portable, is not easy to maintain, does not have WEB interface, etc. - the list of problems is infinite. If there is no such solution and we decide to create something like this (we are considering PHP + mySQL + Symfony) and GPL the product do we have chance to get community participation ? This is short spec I wrote containing the requirements http://www.gomyplace.com/phpDesign-SW-design-v.04.pdf Is there a ready to go, preferably Open Source/GPL solution ? I will appreciate any help, links thank you

I had a quick look through your doc and, with the best will in the
world, I can't see that this would be of any use at all. There isn't any
feature in it that made me stop and think "wow, that's something I/We
could really have used on a project".

What's the point? Have I missed something? At first sight, this looks a
spec whose sole purpose is to waste time and money.

/RT

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 same database, that way I would be sure that the software, hardware , and documentation were all in sync at any moment in time. Honestly, rather than a SQL database, you might want to consider something a little lighter weight that is more easily version controlled. I chose to use a simple XML document (any simple markup would have worked) and found that it worked quite well. As an ASIC designer who also writes drivers for the hardware, I found the tool to be indispensable, and so did the other 25 members of my team (hardware and software alike). On 2/20/07, Richard Tierney rt-opencores at cyconix.com> wrote:

I guess it does make sense when you've got lots of registers. I like the
idea of the code generator.

/RT

Sounds similar to RDL, see: http://www.eetimes.com/news/design/showArticle.jhtml?articleID=181503390 If I got it right, the RDL language is open but the "Denali Blueprint" compiler is a commercial product. I haven't used RDL but we use a similar in-house-developed system, which I find invaluable. Regards Gunnar Dahlgren Jeremy Fillingim wrote:

RDL looks easy enough to parse. I suspect that using this format wouldn't be terribly difficult. XML tools (parsers, validators, the xslt stuff) are easy to use and exist in any language that could possibly tickle your fancy. Sure, it's verbose, and it does make me feel dirty every time I use it, but I have to admit, sometimes it's the right tool for the job. Personally, I'd have a tough time inventing a new standard if there is a pre-existing one (that is open of course). On 2/20/07, Gunnar Dahlgren gunnar.dahlgren at axis.com> 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.

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


something similar many years ago. It

and functions/macros/structures

also had a searchable web

I took it one step

the register

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 at bloglines.com larytet.46060479 at bloglines.com> wrote:

I have used similar tools before at previous companies and created a lightweight version of the tool for my TV80 project. It has a fairly simple set of registers it can generate, and the RTL it outputs is specific to the Z80 bus, but if you're looking for something to use as a starting point or for ideas I'd look at that. Like previous posters, I would stay away from a database solution and stick with something simple and XML-based. XML parsers are a dime a dozen nowadays and you can easily write multiple tools to look at your file and pull out the information they need to write RTL, create reg descriptions, etc. The tool I used before was able to generate multiple "slave" files that could be hooked up to a single master, allocate register spaces and do address maps, automatically generate documentation, and automatically create tests which would check the operation and integrity of the register map. It was web & database based, and the problem with that was mainly unnecessary complexity (now you have another server that can go down), and difficulty building new tools to interface to the database. Also, if you're worried about scalability, command-line tools have no difficulty generating millions of gates worth of RTL in under a second. :) If you're interested in building something open-source, I would be interested in collaborating on it. - Guy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20070220/4cac135c/attachment.htm

All: I've used a tool like this based on exceed.... with a bunch of perl scripts to generate RTL. I hated it. There is no question that design effort was INCREASED rather than lessened by the "tool". There is some real value in forcing standards - register designs - register documentation standards... but that can be done with good design practices.. It does not need to be enforced by tools. None of these tools can insure useful (or even accurate) register descriptions.... it takes good review methods to do this. I've often wondered why people don't think about the most effective ways to use standard design languages (like verilog) to simplify the design process. If the goal is to insure good user documentation, there are many available ways to extract comments from standard design files. bj Porcella 571 245-6861 ----- Original Message ----- From: Guy Hutchison To: Discussion list about free open source IP cores Sent: Tuesday, February 20, 2007 11:15 AM Subject: Re: [oc] data base for ASIC/FPGA develpers I have used similar tools before at previous companies and created a lightweight version of the tool for my TV80 project. It has a fairly simple set of registers it can generate, and the RTL it outputs is specific to the Z80 bus, but if you're looking for something to use as a starting point or for ideas I'd look at that. Like previous posters, I would stay away from a database solution and stick with something simple and XML-based. XML parsers are a dime a dozen nowadays and you can easily write multiple tools to look at your file and pull out the information they need to write RTL, create reg descriptions, etc. The tool I used before was able to generate multiple "slave" files that could be hooked up to a single master, allocate register spaces and do address maps, automatically generate documentation, and automatically create tests which would check the operation and integrity of the register map. It was web & database based, and the problem with that was mainly unnecessary complexity (now you have another server that can go down), and difficulty building new tools to interface to the database. Also, if you're worried about scalability, command-line tools have no difficulty generating millions of gates worth of RTL in under a second. :) If you're interested in building something open-source, I would be interested in collaborating on it. - Guy ------------------------------------------------------------------------------ _______________________________________________ http://www.opencores.org/mailman/listinfo/cores -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20070220/cb8366b8/attachment.htm

I did not think that the tool will generate (or even parse) Verilog files.
I though mainly about synchronization between designers, verification team
and software team. The central point of the tool is generating of datasheet(s)


I do not throw away the idea of actually parsing Verilog files and looking
for some tags, but i think that DocBook already does this. I guess it is possible
in the future to integrate the engines. Meanwhile I want to limit the scope
of the problem and focus the efforts in solving the main problem - replacing
of the Access data base.


exceed....

There is no question that design

by the

designs - register