Simplify handling of SW accessible registers in FPGA

[Petter Gustad]

rickman <gnuarm@gmail.com> writes:

Thought about making C, VHDL, or HTML the source format rather than XML.
Either of the first two can be really ugly to parse, and HTML was even
uglier to write than my XML format.

But it wouldn't have to be a full C parser, just any limited subset
you care to specify. In essence the idea is to write a "special"

Rather than writing a parser one could build a small domain specific
language (DSL) on top of an existing HLL or scripting language like
Python, CL, Ruby, TCL, or whatever you prefer. Then it's usually quite
simple to generate HDL, C header files, ralf, xact, LaTeX, etc. from
there.

//Petter

--
..sig removed by request.

 

[rickman]

On 3/15/2016 3:44 AM, Petter Gustad wrote:

rickman <gnuarm@gmail.com> writes:

Thought about making C, VHDL, or HTML the source format rather than XML.
Either of the first two can be really ugly to parse, and HTML was even
uglier to write than my XML format.

But it wouldn't have to be a full C parser, just any limited subset
you care to specify. In essence the idea is to write a "special"

Rather than writing a parser one could build a small domain specific
language (DSL) on top of an existing HLL or scripting language like
Python, CL, Ruby, TCL, or whatever you prefer. Then it's usually quite
simple to generate HDL, C header files, ralf, xact, LaTeX, etc. from
there.

I'm trying to eliminate yet another file and file type. If all the
source can be inserted into a C file that is used as the C header file
with other code in comments adequate to specify the HDL code required,
then this one file would serve as the complete source for the interface
allowing the needed HDL files to be generated.

--

Rick

 

We evaluated various input formats - including VHLD register definition package (or similar C header file, and of course a pure proprietary text-file), but we concluded on JSON. The main reasons as far as I can remember was a) We didn't want one of HDL,C or DOC as the source format, because this could easily lead to forgetting to update the other
b) JSON is a quite human friendly format
c) The support/tools available for a JSON

I guess these evaluations and conclusions will differ depending on previous experience for good and for bad, but at least the JSON format used with Register Wizard is quite readable for anyone, and it is easy to make new modules based on the template/examples.

 

[Colin Marquardt]

Some tools for the IP-XACT format that may be worth a look if you are into code generation:
* https://bitbucket.org/verilab/tanto
* https://andreaslindh.wordpress.com/2013/09/26/ipxact2systemverilog/