EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

Simplify handling of SW accessible registers in FPGA

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - Simplify handling of SW accessible registers in FPGA

Goto page Previous  1, 2

KJ
Guest

Thu Mar 10, 2016 7:42 pm   



On Wednesday, March 9, 2016 at 12:39:25 PM UTC-5, Rob Gaddi wrote:
Quote:

In mine, each register gets its own record type associated with it,
made up of unsigned/signed/std_logic/std_logic_vector based on the
register definition file, and there are conversion functions for
translating records to/from the data bus std_logic_vector, all of which
goes into a package that I import into the module that actually does the
work.


I do the same but I put the actual bit definitions into the record like this...
type t_INPUT_DMA_CONTROL_PORT is record
Start: std_ulogic_vector(31 downto 31);
Reserved: std_ulogic_vector(30 downto 26);
Max_Count: std_ulogic_vector(25 downto 0);
end record;

That way the 'to/from' std_ulogic_vector functions can be written without having to refer to bit locations, like this...
function To_Std_ULogic_Vector(L : t_INPUT_DMA_CONTROL_PORT) return std_ulogic_vector is
variable RetVal: std_ulogic_vector(31 downto 0);
begin
RetVal := (others => '0');
RetVal(L.Start'range) := L.Start;
RetVal(L.Reserved'range) := L.Reserved;
RetVal(L.Max_Count'range) := L.Max_Count;
return(RetVal);
end To_Std_ULogic_Vector;

function From_Std_ULogic_Vector(L : std_ulogic_vector) return t_INPUT_DMA_CONTROL_PORT is
variable RetVal: t_INPUT_DMA_CONTROL_PORT;
variable Lx: std_ulogic_vector(L'length - 1 downto 0);
begin
Lx := L;
RetVal.Start := Lx(RetVal.Start'range);
RetVal.Reserved := Lx(RetVal.Reserved'range);
RetVal.Max_Count := Lx(RetVal.Max_Count'range);
return(RetVal);
end From_Std_ULogic_Vector;

Given the record definition, it is a quick macro run to generate these to/from functions which is completed quickly. If only bit definitions change, then only the record needs to be modified and everything recompiled. If you add/subtract fields then the record and two functions need to be updated and everything recompiled. All in all, not much maintenance.

It's not trying to do as much as I think the OP is doing, but it does handle most of the work and most of the stuff that is error prone anyway.

Quote:
So that gives you automation of defining registers. I never
got around to the next logical step, auto-generating the code that
defines the "register file" as a record of all the subrecords,
and handles the bus transactions against that record in some kind of
DoBusTransaction(regfile) call. It would be straightforward to do
if cumbersome.


I have, but actually I just use a spreadsheet for a lot of the work. Archive the spreadsheet along the source.

rickman
Guest

Fri Mar 11, 2016 12:34 am   



On 3/10/2016 10:13 AM, espen.tallaksen_at_bitvis.no wrote:
Quote:
I see from the discussion above that we should also show the result-files from Register Wizard in the provided download. The result-files are described in the current documentation, but the actual files are not shown. I think everything will be clearer, and hopefully your questions will be answered when we include the result files from the documented example. Most probably we will provide this as a separate zip-file ASAP.

A zip-file showing the generated outputs is now provided for download under http://bitvis.no/products/register_wizard/


Some feedback. Your flyer is way too terse and I'm not inclined to
download a full user manual to learn the first things about a tool. You
might want to have a quick overview manual to give potential customers
an idea of the facilities of the tool without having to learn the whole
thing or wade through a full manual.

The files download is a good start. In addition to the outputs, I found
the input which doesn't look too hard to learn. But your example
includes no bit fields in the registers. Isn't that essential? I would
also include at least one example of logic that is added by the user to
be incorporated in one of the output files, the core file I assume.
Perhaps something simple like a bit that is cleared when read. Some
sort of overview description would be useful explaining each of the
output files and how they are intended to be used including some of the
specifics of each file. Something I can read in 15-30 minutes rather
than hours.

I see your user manual has a tutorial and I was able to scan it quickly
and found it includes the use of "Write-to-Trigger" which would be
interesting to see. Maybe the download could use the files from the
tutorial?

Just my 10 minute look at your materials. :)

--

Rick

michael6866
Guest

Fri Mar 11, 2016 4:30 am   



On Thursday, March 10, 2016 at 7:35:31 AM UTC-5, espen.t...@bitvis.no wrote:
Quote:
There is also a standard IEEE 1685-2009 which uses "IP-XACT" format for defining peripheral registers. Major EDA vendors have tools supporting the format and its extensions for code generation.

IP-XACT is probably very good for data exchange between different tools, but it is not very good as a human-readable format. We made our own format to significantly increase readability for designers. We evaluated XML, but concluded JSON was better.


Yes, that's why there is the RDL languages such as http://www.accellera.org/activities/working-groups/systemrdl


Guest

Fri Mar 11, 2016 11:36 am   



torsdag 10. mars 2016 18.34.29 UTC+1 skrev rickman følgende:
Quote:
On 3/10/2016 10:13 AM, espen wrote:
I see from the discussion above that we should also show the result-files from Register Wizard in the provided download. The result-files are described in the current documentation, but the actual files are not shown. I think everything will be clearer, and hopefully your questions will be answered when we include the result files from the documented example. Most probably we will provide this as a separate zip-file ASAP.

A zip-file showing the generated outputs is now provided for download under http://bitvis.no/products/register_wizard/

Some feedback. Your flyer is way too terse and I'm not inclined to
download a full user manual to learn the first things about a tool. You
might want to have a quick overview manual to give potential customers
an idea of the facilities of the tool without having to learn the whole
thing or wade through a full manual.

The files download is a good start. In addition to the outputs, I found
the input which doesn't look too hard to learn. But your example
includes no bit fields in the registers. Isn't that essential? I would
also include at least one example of logic that is added by the user to
be incorporated in one of the output files, the core file I assume.
Perhaps something simple like a bit that is cleared when read. Some
sort of overview description would be useful explaining each of the
output files and how they are intended to be used including some of the
specifics of each file. Something I can read in 15-30 minutes rather
than hours.

I see your user manual has a tutorial and I was able to scan it quickly
and found it includes the use of "Write-to-Trigger" which would be
interesting to see. Maybe the download could use the files from the
tutorial?

Just my 10 minute look at your materials. :)

--

Rick


Thanks for good suggestions on improving the documentation with simpler get-started-documentation. I will add it in our issue tracking system.

-Espen


Guest

Fri Mar 11, 2016 11:48 am   



fredag 11. mars 2016 03.30.24 UTC+1 skrev michael6866 følgende:
Quote:
On Thursday, March 10, 2016 at 7:35:31 AM UTC-5, espen.t...@bitvis.no wrote:
There is also a standard IEEE 1685-2009 which uses "IP-XACT" format for defining peripheral registers. Major EDA vendors have tools supporting the format and its extensions for code generation.

IP-XACT is probably very good for data exchange between different tools, but it is not very good as a human-readable format. We made our own format to significantly increase readability for designers. We evaluated XML, but concluded JSON was better.

Yes, that's why there is the RDL languages such as http://www.accellera.org/activities/working-groups/systemrdl


Thanks. Seems to be dead though, with no support...

Petter Gustad
Guest

Tue Mar 15, 2016 1:44 pm   



rickman <gnuarm_at_gmail.com> writes:

Quote:
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
Guest

Tue Mar 15, 2016 1:55 pm   



On 3/15/2016 3:44 AM, Petter Gustad wrote:
Quote:
rickman <gnuarm_at_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


Guest

Wed Mar 16, 2016 12:46 pm   



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
Guest

Mon Mar 21, 2016 7:06 pm   



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/

Goto page Previous  1, 2

elektroda.net NewsGroups Forum Index - VHDL Language - Simplify handling of SW accessible registers in FPGA

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map