Anonymous Struct Members / Struct Constants

S

Stephen

Guest
I am looking for a synthesizable means to represent typical control
registers found in a microcontroller. In typical use, I would select
the register to read or write to and then write or read data from the
bus.
For example, consider SFR0, an eight bit register defined as:

7 - 6: reserved bits.
5: Enable A bit.
4: reserved bit.
3: Flag 1 bit.
2: Enable B bit.
1 - 0: Status bits.

I could represent this in SystemVerilog as a function for writing
purposes, as such:

// Begin example code. //
function [7:0] SFR0
(
input EnableA,
input Flag1,
input EnableB,
input [1:0] Status
);

SFR0 = { 2'bzz,
EnableA,
1'bz,
Flag1,
EnableB,
Status };

endfunction

module Foo
(
);

// ... Code.

always_ff @ (posedge Clock)
begin

// ... Code

// Else, tell the microcontroller to enable A and reset everything
else:
SFR0Register <= SFR0
(
.EnableA(1), // Enable A.
.Flag1(0), // Clear our flag 1.
.EnableB(0), // Disable B.
.Status(0) // Clear out the Status
bits.
);
// ... Code.

end

// ... Code.

endmodule

// End example code. //

But it wouldn't be of much help in setting or clearing individual
bits, so I thought I would use a stuct, perhaps as such:

// Begin example code. //
typedef struct packed
{
reg [1:0];
reg EnableA;
reg;
reg Flag1,
EnableB;
reg [1:0] Status;
} SFR0;
// End example code. //

Unfortunately, it seems I cannot have anonymous struct members, and I
also cannot seem to have constant members, such as:

// Begin example code. //
typedef struct packed
{
const reg [1:0] = 2'bzz;
reg EnableA;
const reg = 1'bz;
reg Flag1,
EnableB;
reg [1:0] Status;
} SFR0;
// End example code. //

I've considered using macros, but this would remove the ability to
access bits through their names ( .EnableA(1) ), which defeats my main
purpose readability. In addition, I would like to avoid code along
the lines of extending EnableA to occupy four bits or giving dummy
names to the reserved bits. I would much appreciate any advice.
 
Maybe something like this

....
wire [7:0] mask = 8'h01 << bitposition;
SFR0 |= mask; // to set a bit
SFR0 &= ~mask; // to clearit
....

bitposition could be defined in an enum which will improve your
readability.

I presume you're talking about 8 bit core with a dedicated operation
to clear/set bits in the I/O space. Because normally this is done on 3
steps read/modify/write and involves the entire register anyway, so
all the above remains simply an excercise.
 
On Jun 20, 12:55 am, krustev.svi...@googlemail.com wrote:
Maybe something like this

...
wire [7:0] mask = 8'h01 << bitposition;
SFR0 |= mask; // to set a bit
SFR0 &= ~mask; // to clearit
...

bitposition could be defined in an enum which will improve your
readability.

I presume you're talking about 8 bit core with a dedicated operation
to clear/set bits in the I/O space. Because normally this is done on 3
steps read/modify/write and involves the entire register anyway, so
all the above remains simply an excercise.
Have you tried using classes .There you can have defualt members, You
can write classes in DUT by using the flags -ntb_opts dtm , I am
talking of VCS though
 
Thanks for the help. Unfortunately I don't have access to VCS for
this project. I'm using Quartus II for synthesis and Active-HDL for
simulation. Quartus II supports SystemVerilog and the version of
Active-HDL I have supports Verilog 2001. This has removed a number of
possible solutions, including my initial idea of using functions, as
Quartus II does not seem to support the .argument notation for
functions. I'll see how well masking works out.
 
I've fooled around with a masking scheme, but for the number of masks
and registers I have, I couldn't find a pragmatic method of doing it.
The problem I ran into was being able to bundle bit masks with
registers without giving long or alphabet soup names. For instance,
some registers have bits with the same as other registers, but in
different positions. This means I have to have a means to identify
register A's enable bit from register B's enable bit, for example. I
could of course name them A_Enable, and B_Enable, but most of the
registers I must access have long names that don't abreviate well,
such as DcDMAConfiguration. If I did bite the bullet, giving them
short prefixes representative of their full register names, it would
make more difficult to harmonize the data sheet and code, which was
one of my purposes in fooling with it anyway.

As such, I'm open to further suggestions that would work well in
Verilog 2001.
 

Welcome to EDABoard.com

Sponsor

Back
Top