M
ma740988
I often peruse source that use memory mapped registers as a
configuration and/or command and status interface between embedded
software and FPGA logic. In doing so you're given a register name
accompanied by descriptions and a location in memory for reading/
writing data.
For ex:.
Revision Register - Location 0x0000
[31...15] spare
[14...00] number
Control Register - Location 0x0001
[31..3] -- Spare
[2] -- Address Line 3
[1] -- Address Line 2
[0] -- Address Line 1
To describe these registers in source one could do:
struct RevisionRegister {
unsigned short number : 16;
unsigned short spare : 16;
};
struct ControlRegister {
unsigned int Spare : 29;
unsigned short AddressLine3 : 1;
unsigned short AddressLine2 : 1;
unsigned short AddressLine1 : 1 ;
} ;
The trouble with the composite type ControlRegister is sizeof
(ControlRegister) is not 32 bits. That said, its not possible to
receive ControlRegister in it's current form from an end user and
overlay it at the appropriate location. The fundamental issue
surrounds the use of bitfields and implementation defined nature of
POD types. The question: What are some of the - if you will - tips
for dealing with this issue?
Would it make sense to eliminate the fields ... so now:
struct ControlRegister {
unsigned int Spare ;
unsigned int AddressLine3 ;
unsigned int AddressLine2 ;
unsigned int AddressLine1 ;
} ;
Upon receipt of the type layout ContolRegister (something I have to do
anyways) according to the needs of the memory mapped location.
Trouble with this is you give the end user free reign to put in
values outside of the bit range.
configuration and/or command and status interface between embedded
software and FPGA logic. In doing so you're given a register name
accompanied by descriptions and a location in memory for reading/
writing data.
For ex:.
Revision Register - Location 0x0000
[31...15] spare
[14...00] number
Control Register - Location 0x0001
[31..3] -- Spare
[2] -- Address Line 3
[1] -- Address Line 2
[0] -- Address Line 1
To describe these registers in source one could do:
struct RevisionRegister {
unsigned short number : 16;
unsigned short spare : 16;
};
struct ControlRegister {
unsigned int Spare : 29;
unsigned short AddressLine3 : 1;
unsigned short AddressLine2 : 1;
unsigned short AddressLine1 : 1 ;
} ;
The trouble with the composite type ControlRegister is sizeof
(ControlRegister) is not 32 bits. That said, its not possible to
receive ControlRegister in it's current form from an end user and
overlay it at the appropriate location. The fundamental issue
surrounds the use of bitfields and implementation defined nature of
POD types. The question: What are some of the - if you will - tips
for dealing with this issue?
Would it make sense to eliminate the fields ... so now:
struct ControlRegister {
unsigned int Spare ;
unsigned int AddressLine3 ;
unsigned int AddressLine2 ;
unsigned int AddressLine1 ;
} ;
Upon receipt of the type layout ContolRegister (something I have to do
anyways) according to the needs of the memory mapped location.
Trouble with this is you give the end user free reign to put in
values outside of the bit range.