write only bits in registers

[MM]

Hi all,

This problem has been bugging me since long time ago. Every time I design a
device register map I need to implement several write only bits here and
there. Having these bits prevents me from describing my register file in a
simple and straightforward way... I used to group these WO bits in the MSBs,
so that when I do something of this sort:

process(lclk)
begin
if rising_edge(lclk) then
if cs_ctrl='1' and lwr='1' then
ctrl_reg <= lad(CTRL_SZ-1 downto 0);
end if
if cs_xxx='1' and lwr='1' then
xxx_reg <= lad(XXX_SZ-1 downto 0);
end if
-- etc.
end if;
end process

where CTRL_SZ (assuming the WO bits are in the ctrl_reg) is actually less
than the full register size by the number of WO bits, it kind of solves the
problem, but I don't like the fact that I have to group these bits and that
CTRL_SZ doesn't properly reflect the register size anymore...

So, I was wondering if someone knows a nicer trick to solve this problem...

Thanks,
/Mikhail

 

[Jason Berringer]

You can have your write only bits where ever you choose, you can just assign
your bits to specific locations:
....
if cs_ctrl='1' and lwr='1' then
ctrl_reg(15) <= lad(6);
ctrl_reg(14) <= lad(5);
ctrl(8 downto 4) <= lad(4 downto 0);
end if
....

it really doesn't matter what you assign to what location, the bits that
aren't written to don't get updated so they should be set coming out of
reset. In the above bit of code ctrl_reg(13 downto 9) and ctrl_reg(3 downto
0) are not updated.

Hope that this helps

Jason

 

[MM]

You can have your write only bits where ever you choose, you can just assign
your bits to specific locations:
...
if cs_ctrl='1' and lwr='1' then
ctrl_reg(15) <= lad(6);
ctrl_reg(14) <= lad(5);
ctrl(8 downto 4) <= lad(4 downto 0);
end if
...

it really doesn't matter what you assign to what location, the bits that
aren't written to don't get updated so they should be set coming out of
reset. In the above bit of code ctrl_reg(13 downto 9) and ctrl_reg(3 downto
0) are not updated.

I understand this and that's similar to what I am currently doing, however I
don't like messing with the order of the bits because this makes the code
difficult to maintain and it also complicates writing of software
documentation. The whole issue is about the style I guess. I think what I
want is a universal register file entity, which would take some sort of a
matrix as a description of bits. Something of this sort:

0 0 1 2 1 1 1 1
1 1 2 2 2 2 2 2
2 2 2 2 2 2 2 2
0 0 0 0 0 0 0 2

where 0 means bit is not implemented, 1 - bit is "write only", 2 - bit is
"read/write". I also want to be able to have alias names for all the
registers and register bits in the file. Note that I am not including "read
only" bits, this is because I always implement read separately, which might
be not the best way to do things... So, perhaps 2 should mean "read only"
and 3 "read/write". The problem with the "read only" bits will be that they
need a source of data somehow brought to this entity...


/Mikhail

 

[Ralf Hildebrandt]

I think what I
want is a universal register file entity, which would take some sort of a
matrix as a description of bits. Something of this sort:

0 0 1 2 1 1 1 1
1 1 2 2 2 2 2 2
2 2 2 2 2 2 2 2
0 0 0 0 0 0 0 2

where 0 means bit is not implemented, 1 - bit is "write only", 2 - bit is
"read/write". I also want to be able to have alias names for all the
registers and register bits in the file.

The hard but fine-grain way would be to model every register bit
seperately. So every bit can have an unique name and the concatenation
of all these bits create the register vector ... and the register array
if you want.

I could also imagine a for-generate, that infers with every iteration
one bit. Some generic parameters (similar to your array written above)
decide what to do with every bit.


Ralf