Unassigned register decode

[Jonathan Bromley]

On Mon, 12 Jan 2009 21:55:24 -0800 (PST), wrote:

[snip Good Stuff]

- the registers per se are not created automagically; they still have
to be written with a procedures

True for my effort too. I didn't make it clear enough
in my first post that the registers themselves live in
individual entities, or procedures, or whatever. I was
only describing the decode and readback mux arrangements.
My arrays-indexed-by-enum make it rather easy to hook up
the "bus" side of each of the register entities, but they
still need to be instantiated.

- pipelining and delay through the central entity have to be managed
somehow - but that's true always

Sure. And there is bus-bridge functionality to be managed; the
common internal "register bus" in your FPGA/ASIC is unlikely to
be as complicated as the external bus structure that needs
decoding.

But it kind of bridges the gap: I can simplify the act of defining a
register to some fairly well-named procedures, and force the designer
to declare some nice descriptors which help the VHDL documentation.
Plus I have a fairly resuable central bus entity.

More stuff for me to think about. Thanks.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Mon, 12 Jan 2009 11:18:26 -0800 (PST), Petrov_101 wrote:

The parser wasn't that difficult to write. It's just a TCL script.

It's worth noting that you can sometimes get Tcl to *be* the
parser for you. Hierarchically-structured things like
register definitions can map nicely on to a Tcl *script*:

reg_bank -base 0x3456 -name Test_reg {
register -name Control_reg -offset 0x00 {
reg_field -bits 15 -mode read_only -name topBit
# add more fields here
}
register -name Data_reg -offset 0x01 {
reg_field -name data -bits 15:8
reg_field -name error -bits 1:0
reg_field -name status -bits {7:5 3}
}
}

Now, by defining appropriate Tcl procs for
[reg_bank], [register] and [reg_field] you can
make your Tcl script generate VHDL code, documentation,
and perhaps even some testbench code.

Explanation: procedure [reg_bank] has three arguments:
the option "-name", the option value "0x3456", and the
script in curly brackets containing two [register] commands.
And so on. I imagine the "-bits" option to reg_field
working like this: it's a Tcl list each of whose elements
is a bit-range; these bit-ranges can either be a single
bit number, or a range like 15:0

ACKNOWLEDGEMENT: Idea shamelessly stolen^wleveraged from
the "RAL" package that forms part of the VMM SystemVerilog
verification methodology toolkit.

EXAMPLE - very incomplete - Tcl code:
Source the following code into any Tcl interpreter,
then source the register-definition script (above)
and see the result...
Lots of error-checking and other details missing.

proc reg_bank {args} {
# last argument is the register description script
set script [lindex $args end]
# pick up option-value pairs:
foreach {option value} [lrange $args 0 end-1] {
switch -- $option {
-base {set ::reg_base $value}
-name {set ::base_name $value}
default {error "Unknown option $option"}
}
}
# display info about this register bank
puts "Processing register bank $::base_name at address $::reg_base"
# execute the script in the calling context
uplevel 1 $script
}

proc register {args} {
set script [lindex $args end]
foreach {option value} [lrange $args 0 end-1] {
switch -- $option {
-name {set ::reg_name $value}
-offset {set ::reg_adrs [expr {$::reg_base + $value}]}
default {error "Unknown option $option"}
}
}
puts [format " Processing register %s/%s at address 0x%08x" \
$::base_name $::reg_name $::reg_adrs]
uplevel 1 $script
}

proc reg_field {args} {
set name "unnamed"
set mode "read_write"
foreach {option value} $args {
switch -- $option {
-name {set field_name $value}
-bits {set bits_list $value}
-mode {set mode $value}
default {error "Unknown option $option"}
}
}
# Make a bits-string from the "bits" option:
set bitmap [split [string repeat . 16] {}]
foreach bit_spec $bits_list {
# Is there a : in it??
if {[regexp {^\d+$} $bit_spec]} {
set bit_spec $bit_spec:$bit_spec
}
if {[regexp {^(\d+)\d+)$} $bit_spec -> hi lo]} {
for {set i $lo} {$i <= $hi} {incr i} {
lset bitmap end-$i X
}
} else {
error "Bit-spec must be N or hi:lo"
}
}
set bitmap [join $bitmap {}]
puts [format " field %-10s: %s %s" $field_name $bitmap $mode]
}


--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

"Jim Lewis" <jim@synthworks.com> wrote in message
news:cOmdnfstZc5yYPHUnZ2dnUVZ_sLinZ2d@posted.easystreetonline...

KJ,
Lastly, a minor nit is the defaulting of the register read back data to
'0'. This is not needed and just adds additional routing and can slow
down performance in the (likely) critical path for muxing the data.

I do this in all of my blocks / cores that are integrated into a chip.
This makes your top level mux an "OR" gate. Should you have a performance
problem, an OR at the top level should be easier to restructure than
a multiplexer with an address going to it.

My only point here was that a straight mux will be the minimal logic/routing
resource usage solution. Adding the default to zero if nothing is being
addressed (or any other solution really) will use at least as much or more
resources as compared to the straight mux, it will not use less than the mux
unless that other solution is able to map into some special hardware
resource of some kind in the device. If there is no such special beast, and
this data path is in the critical timing path, you might find that zeroing
the data bus when an unsupported address is being indexed is a luxury that
is not worth the price...whether or not it is a problem in a given design
depends on how many ports are addressable and the logic block resources of
the FPGA that is implementing them...like I said, it's a minor nit,
something to be aware of when the situation arises.

Kevin Jennings

 

On Jan 13, 6:59 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Mon, 12 Jan 2009 11:18:26 -0800 (PST), Petrov_101 wrote:
The parser wasn't that difficult to write.  It's just a TCL script.

It's worth noting that you can sometimes get Tcl to *be* the
parser for you.  Hierarchically-structured things like
register definitions can map nicely on to a Tcl *script*:

<snip>

Quite true... one of the reasons I like the language so much. I
designed a VHDL processor years ago and needed an assembler for it. I
defined each mnemonic as a tcl procedure. My make file would concat
the mnemonic file with my assembly probram and run it through the tcl
shell. The output was a xilinx block ram preloaded with machine
instructions.

 

[Andreas Ehliar]

On 2009-01-14, KJ <kkjennings@sbcglobal.net> wrote:

I've only seen the and-or take the same or more, never seen it take
less. I'd be interested in seeing an example of one where it took
less resources with the and-or then with the mux to perform the same
function.

I see the same results in a quick test where a mux like structure was
compared with an or-type structure). Registers were used on both the
inputs and the outputs (and the design was coded so that the reset
inputs of the input flip-flops should be used).

When optimized for speed, the area of both solutions were very similar
(within a few percent) but when synthesized for area, the or-based
structure was 8 percent larger than the plain mux.

(This is for an ASIC and not an FPGA. Other tradeoffs can sometimes
apply in an FPGA, especially if you need those registers on the inputs
anyway. And it might also be slightly different in another ASIC process
than the one I tested this on. And the synthesis tool could do something
different in a real design and not a synthetic test, etc etc. You probably
shouldn't base company critical decisions on this very quick analysis )

/Andreas

 

[Jim Lewis]

KJ

"Jim Lewis" <jim@synthworks.com> wrote in message
news:cOmdnfstZc5yYPHUnZ2dnUVZ_sLinZ2d@posted.easystreetonline...
KJ,
Lastly, a minor nit is the defaulting of the register read back data to
'0'. This is not needed and just adds additional routing and can slow
down performance in the (likely) critical path for muxing the data.
I do this in all of my blocks / cores that are integrated into a chip.
This makes your top level mux an "OR" gate. Should you have a performance
problem, an OR at the top level should be easier to restructure than
a multiplexer with an address going to it.


My only point here was that a straight mux will be the minimal logic/routing
resource usage solution. Adding the default to zero if nothing is being
addressed (or any other solution really) will use at least as much or more
resources as compared to the straight mux, it will not use less than the mux
unless that other solution is able to map into some special hardware
resource of some kind in the device. If there is no such special beast, and
this data path is in the critical timing path, you might find that zeroing
the data bus when an unsupported address is being indexed is a luxury that
is not worth the price...whether or not it is a problem in a given design
depends on how many ports are addressable and the logic block resources of
the FPGA that is implementing them...like I said, it's a minor nit,
something to be aware of when the situation arises.

If you have only one block that you are reading back, then your

assumptions are correct. So if you collect all of your readable
registers into a single central block in a design, then you can do
this.

OTOH, I tend to like to use separate re-usable cores that each
are independent and integrate them into a chip. As a result,
I have separate readback logic within each block and then another
level at the chip-level. In this case, zeroing the outputs
(or creating AND-OR logic at the lowest level - which is more
directly what I do) generates about the same amount of
total logic that the multiplexers create (sometimes less,
sometimes more).

However, when zeroing outputs of blocks, then at the chip level
(interconnecting cores), only "OR" gates are needed. So the only
routing we have is data. OTOH, with multiplexers, the chip level
also uses multiplexers with control signals - which impact both
the size and routing of this logic.

You also may want to contemplate how the multiplexer control
logic will impact optimization.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis SynthWorks VHDL Training http://www.synthworks.com

A bird in the hand may be worth two in the bush,
but it sure makes it hard to type.

 

[KJ]

On Jan 14, 11:24 am, Jim Lewis <j...@synthworks.com> wrote:

OTOH, I tend to like to use separate re-usable cores that each
are independent and integrate them into a chip.  As a result,
I have separate readback logic within each block and then another
level at the chip-level.  

I do the same.

In this case, zeroing the outputs
(or creating AND-OR logic at the lowest level - which is more
directly what I do) generates about the same amount of
total logic that the multiplexers create (sometimes less,
sometimes more).

I've only seen the and-or take the same or more, never seen it take
less. I'd be interested in seeing an example of one where it took
less resources with the and-or then with the mux to perform the same
function.

On a somewhat more abstract level, the forcing of zeros to the data
while reading from an unsupported address removes an optimization that
would allow for a don't care (thinking more of Logic 101 type of don't
care here then the VHDL synthesis tool interpretation of don't care
'-') so for the case of a purely combinatorial address decode -> read
data function the and-or wouldn't do better than the mux. At best it
would use the same number of logic blocks but that is because of the
granularity of what typical block can work with. Accepting for the
moment that the and-or does not outperform the mux for a purely
combinatorial path, then that would leave open whether it is better
for a pipelined path. Even in that situation though I haven't run
across the case in a typical design where the mux used more resources
so like I said it would be interesting to see a realistic type of
example.

However, when zeroing outputs of blocks, then at the chip level
(interconnecting cores), only "OR" gates are needed.  So the only
routing we have is data.  OTOH, with multiplexers, the chip level
also uses multiplexers with control signals - which impact both
the size and routing of this logic.

You also may want to contemplate how the multiplexer control
logic will impact optimization.

I have...and also recognize that synthesis tool optimization aren't
obstructed by what we refer to as 'chip level' logic 're-usable core
level' logic.

Good points, thanks.

Kevin Jennings

 

[KJ]

On Jan 13, 5:12 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Mon, 12 Jan 2009 08:09:50 -0500, "KJ" wrote:
Lastly, a minor nit is the defaulting of the register read back data to '0'.
This is not needed

Yes it is needed.  The code I presented is an AND-OR mux,
and doesn't work without the zero default.  

I only meant 'not needed' in the sense that you likely have no
functional design requirement to output all zeros on the data bus when
being presented with an invalid address input. Your decision to meet
the design requirements by implement an and-or structure then does
force the need for a default. Sorry about the confusion.

Kevin Jennings

 

[Brian Drummond]

On Wed, 14 Jan 2009 09:31:52 -0800 (PST), KJ <kkjennings@sbcglobal.net>
wrote:

On Jan 14, 11:24 am, Jim Lewis <j...@synthworks.com> wrote:

In this case, zeroing the outputs
(or creating AND-OR logic at the lowest level - which is more
directly what I do) generates about the same amount of
total logic that the multiplexers create (sometimes less,
sometimes more).


I've only seen the and-or take the same or more, never seen it take
less. I'd be interested in seeing an example of one where it took
less resources with the and-or then with the mux to perform the same
function.

Maybe this is one of those cases where theory dictates that one of you
is right (AND/OR requires fewer gates) but practice dictates otherwise
(but only because FPGA vendor brand X optimizes the hell out of big
muxes with special structures like MUXF6)

The other classic example is the enormous body of elegant and detailed
work on carry-save addition etc, which (for FPGA at least) is rendered
utterly redundant by hard-wired carry chains.

In which case it's good to recognise the fact, and remember to
re-evaluate its truth when (if) you jump across the FPGA/ASIC wall or
switch to another technology (possibly even just another vendor).

- Brian

 

[Marcus Harnisch]

From the point of view that the register description might be used in
different places than just VHDL this is IMHO the better
approach. OTOH, I see nor reason why generated (VHDL) code couldn't be
elegant.

Petrov_101@hotmail.com writes:

I'll have to review your approach in more detail but it looks pretty
snazzy. I've taken a different approach to create banks of
registers. My desire was to move away from VHDL and towards a
specification template of sorts that is parsed by software and output
as both synthesizable VHDL and formatted documentation.

Perhaps a bit over the top if all you are concerned about are register
descriptions, but there is an established standard for such kind of
stuff: IP-XACT (http://www.spiritconsortium.org/)

This is an XML based format to describe of all sorts of aspects
(including register maps) of IP blocks and is supported by many tools.

I hear that there is an Eclipse based IP-XACT editor. Never used it.

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

 

[Amal]

On Jan 11, 6:45 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Sat, 10 Jan 2009 17:16:33 -0800 (PST), wrote:

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Clever coding Jonathan. Now try doing the same thing in Synthesizable
SystemVerilog! I have had so many problems with SystemVerilog for
design. Even though it has improved a lot over Verilog and has
verification features, it still lacks many great features of VHDL.
Including unconstrained arrays as function parameters and return
values and some of the clever coding that you did above.

I like VHDL not because I like to just blindly defend a language, but
I like it because writing generic code (synthesizable) is a lot easier
that in Verilog and SystemVerilog. I would like to get your ideas on
the two language and your experiences with SystemVerilog.

-- Amal

 

[Jonathan Bromley]

On Thu, 15 Jan 2009 06:34:32 -0800 (PST), Amal wrote:

I like VHDL not because I like to just blindly defend a
language, but I like it because writing generic code
(synthesizable) is a lot easier that in Verilog and
SystemVerilog. I would like to get your ideas on
the two language and your experiences with SystemVerilog.

I don't really want to take sides, and in any case I think
we've had some similar conversation here before (?), but
I still rather enjoy writing RTL (not so much testbenches)
in VHDL in preference to SV. Why? Principally because of
VHDL's dynamic elaboration of subprograms - most particularly,
the use of unconstrained vector parameters (arguments) to
functions. Almost anything else that I like in
VHDL-for-design, I can find the same or better in SV;
packed unions are *such* a nice way to solve certain
design problems, for example. Otherwise, the differences
(for design, please note) are mainly a matter of taste:
how much do you like a language that enforces strong
typing but pays you back with the convenience of overloaded
operators? My personal vote goes to VHDL here, but I can
see the arguments both ways.

I have always seen the interface construct in SV as being
a potential killer advantage for design, but it is seriously
flawed (I've written on this for DVCon2007 and also for
DVCon2009 next month) and designers have largely ignored it;
I'm keeping my hopes up that it's not too late to fix the
problems in time for SV-2012 (or thereabouts, whenever it
happens) and that we can convince the design and tool vendor
community of the benefits. But that will be embarrassingly
close to the end of my career, so perhaps I should stop
worrying about it right now
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.