Hi,

found two tools for Verilog which is supposed to keep documentation
and implementation of control and status registers in sync. Vregs on
www.veripool.com and csrGen.pl on asics.chuckbenz.com. (Actually
csrGen.pl was not downloadable due to an internal error, but the
documentation made it look interesting). I also found a commercial
tool from PDTi which is probably doing the same but I haven't got as
far as getting a demo license.

So far the documentation of the register map is in Word. Many pages
with text and tables and functional description that needs to be kept
in sync. Currently a reorganization of this register map is happening
in OpenOffice calc to be able to see the bits and pieces of the
register map, and to be able to move them around. The VHDL code is
then modified manually according to the spreadsheet and the Word
document is then modified again. In the end the application programmer
is going to take that Word document and type a lot of #defines in his
C-files and I bet we will spend some weeks looking for those nasty
bugs that all this manual work will produce. The project is running on
an FPGA so it is too easy to just add registers and bits as new
features come up, or to move them when they doesn't fit the access
model of the application that is later going to access the registers
(via PCI)

Vregs solves this problem by creating VHDL and C-headers from HTML
exported from a text processor that can export HTML. csrGen.pl will
take input from a definition file. I found both solutions charming,
except from the fact that they generate Verilog instead of VHDL, and
that one wasn't available anymore.

I'm wondering how other VHDL programmers solve their CSR bookkeeping,
or maybe there is a tool out there that I haven't found. It doesn't
need to be open source, if it is any good we will buy it. From the
efforts by Wilson Snyder on Vregs I take that this is not a tool that
I can write overnight myself. Maybe it is portable since it is written
in perl, but Verilog and VHDL does think differently, and I am not a
perl savvy. (Can't even read my own code after six weeks)

--
Svenn

Svenn Are Bjerkem wrote:

> I'm wondering how other VHDL programmers solve their CSR bookkeeping,
> or maybe there is a tool out there that I haven't found. 

I don't automate any process until I've proven to
myself that the manual process warrants the automation time.

If I did decide to automate register documentation, I think I would
make the script read my code, not write it.

I would also make sure there was an audience for my pretty printing,
before I went to the trouble generating it.

       -- Mike Treseler

Svenn Are Bjerkem wrote:
> Hi,
<snip>
> I'm wondering how other VHDL programmers solve their CSR bookkeeping,
> or maybe there is a tool out there that I haven't found. It doesn't
> need to be open source, if it is any good we will buy it. From the
> efforts by Wilson Snyder on Vregs I take that this is not a tool that
> I can write overnight myself. Maybe it is portable since it is written
> in perl, but Verilog and VHDL does think differently, and I am not a
> perl savvy. (Can't even read my own code after six weeks)

That's a very interesting question, one that can play a big role in a product or project
design.

After running into troubles in the past, I have decided to generate both
VHDL and documentation from a single definition file.
The trick is that I do most things in JavaScript,
which is roughly as powerful as Perl but with the added benefit of enabling
"clickodromes".

The defined parts are not registers (yet) but the instruction set.
The desing is not advanced enough for the definition of the configuration
registers (interrupt, I/O, integrated peripherals) but at least,
my assembler (in JS) is mostly in synch with the VHDL code.


If you have Mozilla (or any decent JS-handling browser except MSIE),
have a look at
http://f-cpu.seul.org/whygee/yasep/
http://f-cpu.seul.org/whygee/yasep/tools/opcode_map.html
http://f-cpu.seul.org/whygee/yasep/tools/generate_VHDL.html
(note that some parts are broken, such as the disassembler).

I have found a lot of advantages to this approach.
However it is better applied /after/ the architecture
is defined and stable, or else the generation tools
must be changed (which happens more often that we would want).
In the case of YASEP, I have found that it's not too bad,
it forces me to think further than the problem that I want to solve,
I have to anticipate and plan my actions. Over the last years,
it has paid :-)

Hope this helps,

> Svenn
yg

-- 
http://ygdes.com / http://yasep.org

In article
<7...@mid.individual.net>,
 Mike Treseler <m...@gmail.com> writes:
>Svenn Are Bjerkem wrote:
>
>> I'm wondering how other VHDL programmers solve their CSR bookkeeping,
>> or maybe there is a tool out there that I haven't found. 
>
>I don't automate any process until I've proven to
>myself that the manual process warrants the automation time.

Yes, but there are two reasons to (semi-) automate something.
One is to save time.  The other is to reduce the chances of
errors.  I'm often willing to spend a few hours writing
some hack code if it will help prevent errors.

>If I did decide to automate register documentation, I think I would
>make the script read my code, not write it.

I find it simpler to write complicated formats rather than read them.
I'd (probably) put the data into an extra file with a simple format,
read that, and write a skeleton of the code.

>I would also make sure there was an audience for my pretty printing,
>before I went to the trouble generating it.

Again, yes, but I can be a good-enough audience all by myself.

There may be two parts to this discussion.  One is getting started
where you have to type in lots of stuff.  The same info shows
up in several places.  The other is making changes where you
have to be sure to update all those places.

If you have a formal release process, and you get compare-them
on the check list, it's not too hard to verify that things are
in sync.  (I find it easier with more than one person.)  But
that doesn't cover the debugging stage.


There is a similar problem with coordinating pin assignments.
The code inside the FPGA needs to match the signal names where
the pins hit the PCB.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Have a look at the tool from Duolog called
Bitwise. Is a commercial product
http://www.duolog.com/

Gui that allows you enter register definition. You can then program the
tool to generate anything you want. Examples with the tool generate VHDL CSR type code,
Word documents and C header files.

Very powerful and very quick to enter register definitions.

Svenn Are Bjerkem wrote:
> Hi,
> 
> found two tools for Verilog which is supposed to keep documentation
> and implementation of control and status registers in sync. Vregs on
> www.veripool.com and csrGen.pl on asics.chuckbenz.com. (Actually
> csrGen.pl was not downloadable due to an internal error, but the
> documentation made it look interesting). I also found a commercial
> tool from PDTi which is probably doing the same but I haven't got as
> far as getting a demo license.
> 
> So far the documentation of the register map is in Word. Many pages
> with text and tables and functional description that needs to be kept
> in sync. Currently a reorganization of this register map is happening
> in OpenOffice calc to be able to see the bits and pieces of the
> register map, and to be able to move them around. The VHDL code is
> then modified manually according to the spreadsheet and the Word
> document is then modified again. In the end the application programmer
> is going to take that Word document and type a lot of #defines in his
> C-files and I bet we will spend some weeks looking for those nasty
> bugs that all this manual work will produce. The project is running on
> an FPGA so it is too easy to just add registers and bits as new
> features come up, or to move them when they doesn't fit the access
> model of the application that is later going to access the registers
> (via PCI)
> 
> Vregs solves this problem by creating VHDL and C-headers from HTML
> exported from a text processor that can export HTML. csrGen.pl will
> take input from a definition file. I found both solutions charming,
> except from the fact that they generate Verilog instead of VHDL, and
> that one wasn't available anymore.
> 
> I'm wondering how other VHDL programmers solve their CSR bookkeeping,
> or maybe there is a tool out there that I haven't found. It doesn't
> need to be open source, if it is any good we will buy it. From the
> efforts by Wilson Snyder on Vregs I take that this is not a tool that
> I can write overnight myself. Maybe it is portable since it is written
> in perl, but Verilog and VHDL does think differently, and I am not a
> perl savvy. (Can't even read my own code after six weeks)
> 
> --
> Svenn

"Derek Wallace"
<d...@gmail.com> wrote in message 
news:4...@gmail.com...
> Have a look at the tool from Duolog called Bitwise. Is a commercial 
> product
> http://www.duolog.com/
>

The price is not advertised, which usually means very expensive...


/Mikhail

On Jun 30, 4:24=A0pm, Svenn Are Bjerkem
<svenn.bjer...@googlemail.com>
wrote:

> I'm wondering how other VHDL programmers solve their CSR bookkeeping,
> or maybe there is a tool out there that I haven't found. It doesn't
> need to be open source, if it is any good we will buy it. From the
> efforts by Wilson Snyder on Vregs I take that this is not a tool that
> I can write overnight myself. Maybe it is portable since it is written
> in perl, but Verilog and VHDL does think differently, and I am not a
> perl savvy. (Can't even read my own code after six weeks)

I wrote TCL code compiled into an executable so you don't need TCL
installed to run.  There are two programs, reg2vhdl.exe and
reg2groff.exe, the first generates VHDL and the second groff code.

A snippet of the input text file:

#--------------------------------------------------------------------------=
-----
# Processor Interface Register File
# pint_reg.reg
#--------------------------------------------------------------------------=
-----

#--------------------------------------------------------------------------=
-----
# Revision Register
#--------------------------------------------------------------------------=
-----
NAME: REV
ADDR: 0x0
 DIR: R
BITS: 7:0  Revision  # This register stores the revision of the SPI
module.

#--------------------------------------------------------------------------=
-----
# Control Register
#--------------------------------------------------------------------------=
-----
NAME: CONTROL_WR
ADDR: 0x1
 DIR: W
 BIT: 2    UartMode     # 0 =3D Normal Operation (default). 1 =3D
Configuration Mode.
BITS: 1:0  LoopbackSel  # Selects SPI loop back source.         \
                        #   SPI_0 : LoopSel<1:0> =3D 00 (default) \
                        #   SPI_1 : LoopSel<1:0> =3D 01           \
                        #   SPI_2 : LoopSel<1:0> =3D 10           \
                        #   TEST  : LoopSel<1:0> =3D 11           \
                        # Note: TEST is hardcoded to 0xA5.

NAME: CONTROL_RD
ADDR: 0x1
 DIR: R
 BIT: 2    UartMode     # 0 =3D Normal Operation (default). 1 =3D
Configuration Mode.
BITS: 1:0  LoopbackSel  # SPI loop back source.                 \
                        #   SPI_0 : LoopSel<1:0> =3D 00 (default) \
                        #   SPI_1 : LoopSel<1:0> =3D 01           \
                        #   SPI_2 : LoopSel<1:0> =3D 10           \
                        #   TEST  : LoopSel<1:0> =3D 11           \
                        # Note: TEST is hardcoded to 0xA5.

The portion after the # character are comments and end up in a groff
table (later converted to pdf).  Documentation then becomes part of
the makefile script.

The program wasn't that difficult to write and it's getting lots of
use in our design group.  It's not a huge time saver, but does keep
things in sync because the makefile generates both vhdl and
documentation from the same source file.  I went with groff as a
documentation language because it's pretty easy to learn and is open
source.

Pete