Shared C defines / VHDL constants

On a couple of occasions, I have wanted to share some C/C++ header (.h)
defines between my firmware apps and VHDL code. This usually is for
memory mapping and enumerated type issues. Here's an example:

C/C++ .h file contains:
//----------------------------------------------//
#define BIN_TYPE_REG 0x05

#define BIN_TYPE_A 0
#define BIN_TYPE_B 1
#define BIN_TYPE_C 2
//----------------------------------------------//

Then in the FPGA VHDL file:
-----------------------------------------------
--- After Arch.
CONSTANT BIN_TYPE_REG : STD_LOGIC_VECTOR(7 DOWNTO 0) := x"05";

CONSTANT BIN_TYPE_A : STD_LOGIC_VECTOR(7 DOWNTO 0) := x"00";
CONSTANT BIN_TYPE_B : STD_LOGIC_VECTOR(7 DOWNTO 0) := x"01";
CONSTANT BIN_TYPE_C : STD_LOGIC_VECTOR(7 DOWNTO 0) := x"02";
---begin
---in some process
CASE(Address)
WHEN BIN_TYPE_REG =>
Data_Bus <= BIN_TYPE_B;
-----------------------------------------------

As you can see the same constants are duplicated in both files, which
is a pain to keep track of. I'm sure someone has run in this before.
Has anyone come up with a workable solution?

I have thought about writing script to parse the C header and replace a
tag embedded in the VHDL, but thought that maybe there was a cleaner
way to accomplish this.

Thanks,
Aaron

 

[Colin Marquardt]

Aaron.R.McFarland@gmail.com writes:

I have thought about writing script to parse the C header and replace a
tag embedded in the VHDL, but thought that maybe there was a cleaner
way to accomplish this.

I have a memory map defined in a complex VHDL constant (array type
consisting of nested records), and I use textio to write out LaTeX
documentation for these register fields. You could write C headers
in the same way. I'd go the VHDL-->C way since arrays, records,
enums etc. allow to express a complex relationship explicitly
(see also
http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=3831#3831).

The same memory map is used for the register test as well as
inferring the registers with the correct properties. Go wild

Cheers,
Colin

 

[Mike Treseler]

Aaron.R.McFarland@gmail.com wrote:

On a couple of occasions, I have wanted to share some C/C++ header (.h)
defines between my firmware apps and VHDL code.
As you can see the same constants are duplicated in both files, which
is a pain to keep track of.

Assuming the C header comes first, I would write a script
to create a package file of constants in the vhdl directory.
The main VHDL files would just include the package and
would not need to be edited.

-- Mike Treseler

 

Mike Treseler wrote:

Assuming the C header comes first, I would write a script
to create a package file of constants in the vhdl directory.
The main VHDL files would just include the package and
would not need to be edited.

This is what I was looking for, I'll check this out. Additional info:
the C header does come first because it is shared across multiple
embedded and PC side C projects and multiple FPGA projects. Plus the
software guy would never give up control of the header. ;-)

--Aaron

 

[Mark McDougall]

Aaron.R.McFarland@gmail.com wrote:

Plus the
software guy would never give up control of the header. ;-)

Now you're going to make the software guy think all the hardware gets
designed around *his* software!

Regards,
Mark

 

[Brian Drummond]

On 23 Feb 2006 15:10:18 -0800, Aaron.R.McFarland@gmail.com wrote:

Mike Treseler wrote:
Assuming the C header comes first, I would write a script
to create a package file of constants in the vhdl directory.
The main VHDL files would just include the package and
would not need to be edited.

This is what I was looking for, I'll check this out. Additional info:
the C header does come first because it is shared across multiple
embedded and PC side C projects and multiple FPGA projects. Plus the
software guy would never give up control of the header. ;-)

I too would recommend going the other way round. The VHDL constants in
your example are more completely specified, the C header is a degenerate
case, and this is normal. Either a "write_header" function in VHDL or an
external parser (TCL, Python, Ruby to taste!) would work but I find VHDL
easier - "why take 2 languages into the shower?"

However... If the software guy won't give up control, I'd encourage him
to specify the constants properly. You may have to educate him to use
typedefs and constants instead of #define but it'll be worthwhile in the
long run.

If you mutually agree typedefs "logic_8", "signed_8" and "unsigned_8" or
some such, your parser can interpret "0x05" into the correct type of
std_logic_vector, signed or unsigned of the correct width. It's also
important to map boolean types onto bit or std_logic instead of
integers!


- Brian