[Cryptech Tech] Keeping magic numbers in sync between Verilog and C

[Pavel Shatov]

On 29.09.2015 19:42, Rob Austein wrote:
> Even with the work Paul and I have been doing on a configuration tool
> for the core_selector, there are still going to be a lot of magic
> numbers buried in .v and .c files.  Having magic numbers in multiple
> places usually means they get out of sync.
>
> I'm wondering if it might be practical to declare the .v files
> authoritative for such numbers, then write short iverilog programs to
> extract those numbers into C header files (and possibly Python files
> too while we're at it, but that's a minor frill).  This would also let
> the author of the Verilog code declare which magic numbers are
> supposed to be exported.

I see, that right now every core has a wrapper, and this wrapper 
contains an array of localparams. Many of these localparams are repeated 
in different cores, since we decided, that similar cores should have 
similar address space layout. I think, an elegant solution will be to 
move all magic localparams into a separate .v file. This file will 
contain only localparams, and every core will then `include this .v file 
and get access to magic constants.

> Yes, I know we could just scrape definitions out of .v files using
> regular expressions, and we might even decide to do that if the
> iverilog route proves too painful, but since we have a perfectly good
> Verilog interpreter available, using a real Verilog parser might be
> both cleaner and less fragile than the usual regexp-from-hell mess.
>
> Comments?

Converting .v file with localparams into .h file with #defines in 
another question. I faced the same problem several times in previous 
projects, but I still don't have any good enough solution. The first 
annoying thing is that numbers in Verilog are like 16'hABCD and like 
0xABCD in C. I personally have a crazy PHP script, that can do the 
trick, but I won't share it. In Russia we have a law, that prohibits 
distribution of explicit adult content, you know.

--
With best regards,
Pavel Shatov