work around VHDL's lack of a preprocessor

[SiliconWizard]

But yes, if the point is making the code look "cleaner" with fewer if's, then you can structure your code differently. Not sure going through hoops is worth it for the example the OP gave though.

But sometimes you have groups of 'when' clauses depending on a given contant/generic inside a 'case' statement, and using a 'if' for each is clunky. Grouping would look tidier (and probably less error-prone).

I sometimes do that by splitting a 'case' into several 'case', each guarded by an 'if'. With the VHDL rule for a sequence of statements, this works fine.
Such as, taking the OP's example:

Code: [Select]

response <= NOT_IMPLEMENTED;

if VARIANT = THIS_ONE then
    Decoder_THISONE : case token is
        when CMD_XYZ =>
            params.XYZ <= argument;
            response <= HANDLED;
       
        when ... =>
        ...
        when others =>
    end case;
end if;

if VARIANT = OTHER_ONE then
    Decoder_OTHER_ONE  : case token is
        when CMD_SOMETHING =>
            ...
            response <= HANDLED;

        when ... =>
        ...
        when others =>
    end case;
end if;

You get the idea.

[asmi]

Actually you can but you'd use a plain if instead of #ifdef. You basically insist on using #ifdef while there is a VHDL language construct (namely the 'if statement') that does exactly the same from a functional point of view when the condition is based on a constant. The OP's question however seems to be how to create nicer looking code that isn't littered with a whole bunch of ifs and #ifdef doesn't make things any nicer. Take note of SiliconWizzards remark about how and why a synthesizer is already doing the same as the C pre-processor. VHDL code that is never used, is optimised away so why insist on adding an extra layer to the language that does the same?

That's more talking, while I still don't see the code. Please show us the version of a code for my example above. Remember, there are four possible cases as each of EXTENDED_OPs can be enabled or disabled independently. This is a quite common use case, so there's got to be a way to make it happen.

[Someone]

In synthesizable code, functions and procedures in VHDL can only be evaluated at compile time - thus when properly used, they give fancy preprocessing features.

That might be a bad use of the term "evaluated", since both functions and processes are synthesiseable and used to produce complex combinatorial results (the majority of ieee packages are functions alongside operator overrides which are functions themselves). So they are most certainly evaluated at runtime.

Nope nope. This was a carefully choosen term here.

You show a misconception of what functions and procedures are in VHDL, or you just didn't understand or even read what I wrote. When synthesized, they can ONLY be evaluated at compile-time. They always yield static logic structures that reflect their behavior. That's why, for synthesis, they act as preprocessing and nothing else.

Static is a strictly defined term in VHDL (the language) so you cant just redefine and reuse it how you like. Evaluated is not strictly defined but most people would understand it to mean the inputs are parsed to produce the output. Elaboration is probably where you were headed, but your refining/misunderstanding of terms makes your contributions incoherent.

[SiliconWizard]

Static is a strictly defined term in VHDL (the language) so you cant just redefine and reuse it how you like. Evaluated is not strictly defined but most people would understand it to mean the inputs are parsed to produce the output. Elaboration is probably where you were headed, but your refining/misunderstanding of terms makes your contributions incoherent.

Let's not uselessly pollute this thread please.
I'll just reply to this: 1/ that my use of 'static' here was strictly in "static logic structure", which had nothing to do with the "static expressions" which is the only thing defined in the VHDL standard related to the word 'static'. One may object that 'static' here would be sort of redundant, as synthesis tools can only generate a static logic structure anyway. Static as in fixed. 2/ That if anything, the term of "compilation" I used could have been questioned, as it's not how the VHDL standard defines how VHDL input is processed - it talks about analysis and elaboration. But almost anyone using HDL routinely talks about "compilation", including tools vendors. Then whether it actually happens during analysis or elaboration, probably nobody cares here, unless you're writing VHDL tools. Point is, again, (was it really not clear?) that functions and procedures in the context of synthesis are nothing but fancy preprocessing - which was the whole point all along.

[BrianHG]

@Bassman59, have you test compiled placing an 'IF (option_parameter)' inside the optional cases VS selecting 2 groups of functions?

I know in SV, when test compiling two similar scenarios, as long as it is a parameter or fixed value, the compiler prunes out the unused logic and ends up generating A or B as if I wrote out a single selected case group.

The other option is a 2 dimensional case, the outer being the 'option_parameter' and the compiler still simplifies/prunes down the logic to A or B.  The case where this simplification doesn't happen is if the 'option_parameter' is a variable logic input instead of a parameter constant, or hard wired high or low.

[Someone]

Let's not uselessly pollute this thread please.
[barely coherent waffle]
Point is, again, (was it really not clear?) that functions and procedures in the context of synthesis are nothing but fancy preprocessing - which was the whole point all along.

Functions are functions as defined by the language, their implementation is important to keep in mind but its much clearer in VHDL than in some other languages. In VHDL functions are evaluated at execution ("runtime") and not limited to evaluation at compile time.

Restricting the design at compile time is one of the significant differences in HDL design vs normal software development, as the FPGA resources are typically scarce/precious. You keep flaming your poor communication:

In synthesizable code, functions and procedures in VHDL can only be evaluated at compile time - thus when properly used, they give fancy preprocessing features.

No, functions are still able to be evaluated/executed after compilation. You said only, I left you ample room to be gracious, but you just dig in.

[Someone]

Will it result in the unpossible command selectors being optimized away? There's only one way to find out: code it and synthesize it, which will be project for tomorrow.

Cant wait to hear the result! Since you are chasing that implementation concept, I took another to test out:

type VARIANT_TYPE is (E_ALL,E_VAR1,E_VAR2,E_TEST);
constant THIS_VARIANT : VARIANT_TYPE := E_VAR2;

type STATE_TYPE is (S_BLEEP,S_BLOOP,S_NUREEK,S_HERUNGER,S_ROATUT,S_UNIMPLEMENTED);
signal command : STATE_TYPE;

constant VARIANT_WIDTH : INTEGER := integer(ceil(log2(real(VARIANT_TYPE'pos(VARIANT_TYPE'high)+1))));
constant STATE_WIDTH   : INTEGER := integer(ceil(log2(real(  STATE_TYPE'pos(  STATE_TYPE'high)+1))));

function state_encode(
  variant : in VARIANT_TYPE;
  state   : in STATE_TYPE)
  return STD_LOGIC_VECTOR is
  variable encoded : STD_LOGIC_VECTOR (VARIANT_WIDTH+STATE_WIDTH-1 downto 0);
begin
  encoded := std_logic_vector(to_unsigned(VARIANT_TYPE'pos(variant), VARIANT_WIDTH) & to_unsigned(STATE_TYPE'pos(state), STATE_WIDTH));
  if variant = E_ALL then
    encoded(encoded'high downto encoded'high+1-VARIANT_WIDTH) := (others => '-');
  end if;
  return encoded;
end function;

begin

process(all)
begin
if rising_edge(clock) then
  case state_encode(THIS_VARIANT,command) is
    when state_encode(E_ALL,S_BLEEP) =>
      params.bleep  <= arguement;
      response      <= R_OK;
    when state_encode(E_VAR1,S_BLOOP) |
         state_encode(E_VAR2,S_BLOOP) =>
      params.bloop  <= arguement;
      response      <= R_OK;
    when state_encode(E_VAR1,S_NUREEK) =>
      params.nureek <= arguement;
      response      <= R_OK;
    when state_encode(E_VAR1,S_ROATUT) =>
      params.roatut <= arguement;
      response      <= R_OK;
    when state_encode(E_TEST,S_HERUNGER) =>
      response      <= R_OK;
    when others =>
      response      <= R_UNIMPLEMENTED;
  end case;
end if;
end process;

(get stuffed scrolling "code" box)

The if in the function is a little inelegant with its verbose range indexing, but the optimization rips through it and does what you were asking for in the original post. Most of the declaration above can be pushed back into a suitable package and it ends up quite nice to use.

[nctnico]

The problem the OP has is a code structuring one. First thing that needs to be done is for the command handling part to always support all commands (so the enumeration needs to be complete with all commands). Secondly a layer (translation table, function, whatever) needs to go between the input and command processing. That layer uses the variant type to check if a certain command is supported or not. This likely takes some restructuring of the code but that advantage is that determining which commands are supported by what type is in 1 location. This will help to keep code maintainable.

@Someone: it is better when your function returns an enumeration. Then the synthesizer can decide what kind of encoding is the most efficient.

[asmi]

The problem the OP has is a code structuring one. First thing that needs to be done is for the command handling part to always support all commands (so the enumeration needs to be complete with all commands). Secondly a layer (translation table, function, whatever) needs to go between the input and command processing. That layer uses the variant type to check if a certain command is supported or not. This likely takes some restructuring of the code but that advantage is that determining which commands are supported by what type is in 1 location. This will help to keep code maintainable.

That's more useless talk. Show us the code already!

[nctnico]

The problem the OP has is a code structuring one. First thing that needs to be done is for the command handling part to always support all commands (so the enumeration needs to be complete with all commands). Secondly a layer (translation table, function, whatever) needs to go between the input and command processing. That layer uses the variant type to check if a certain command is supported or not. This likely takes some restructuring of the code but that advantage is that determining which commands are supported by what type is in 1 location. This will help to keep code maintainable.

That's more useless talk. Show us the code already!

Stop trolling and do your own homework. Maybe you can add something useful to this thread instead of trying to bait people into yet another VHDL versus systemVerilog thread. The OP uses VHDL and needs a solution that is written using VHDL.

[asmi]

Stop trolling and do your own homework. Maybe you can add something useful to this thread instead of trying to bait people into yet another VHDL versus systemVerilog thread. The OP uses VHDL and needs a solution that is written using VHDL.

There is no trolling. Show us the solution already. Or admit that there isn't one. Empty talk doesn't help anyone over here.

[Bassman59]

LOL you guys as always went deep into the woods in your attempts to defend that POS of a language As I understood, what OP wants is this (code in C so that even VHDLers would understand):

Code: [Select]

switch (op)
{
case OP_FOO:
//handing operation FOO
break;
case OP_BAR:
//handing operation BAR
break;
#ifdef OP_EXTENDED_1_SUPPORTED
case OP_EXTENDED_1:
//handing operation OP_EXTENDED_1
break;
#endif
#ifdef OP_EXTENDED_2_SUPPORTED
case OP_EXTENDED_2:
//handing operation OP_EXTENDED_2
break;
#endif
default:
//handing unknown operation
break;
}
Important point is that OP_EXTENDED_x opcodes are treated as unknown ones if such support is disabled. Now please show us how to implement this trivial code. And no, a bunch of generate's with copy-pasted switched for all possible permutations of supported opcodes is not acceptable.

So yes, "use SystemVerilog" is the only sureway solution to avoid having to deal with this garbage again.

Well, despite being a VHDL partisan with an allergy to all things Verilog, I will state that what asmi writes above is exactly what I want.

I will again note that VHDL-2019 actually supports this, but like I said, I expect tool support for VHDL-2019 to arrive sometime after the universe has gone cold and shrunk back into a pea-sized lump of coal.

And that still won't make me switch to SystemVeriilog.

[Bassman59]

The 'generate' statement is the way to get this kind of things done.

Generate does not work within a process. Come on, this is freshman VHDL.

[Bassman59]

One way: make a component for the body of each case statement. That component's contents can have a generate statement that creates output based on what is being generated. There is zero code replication. In fact, closely related functions can be implemented using the same component.

You can't instantiate an entity within a process.

It's the same problem as trying to put a generate within a process.

[nctnico]

One way: make a component for the body of each case statement. That component's contents can have a generate statement that creates output based on what is being generated. There is zero code replication. In fact, closely related functions can be implemented using the same component.

You can't instantiate an entity within a process.

It's the same problem as trying to put a generate within a process.

Don't get too hung up on details; you can use a function or procedure as well. I'm just trying to help you while juggling a boat load of other projects in my mind (none of them dealing with VHDL so forgive me for not having that clear). However, looking at the big picture I see that the root of the problem is the overall structure of how you organised your code.

[Bassman59]

Attached is an archive of a small test design I hacked up to test the two suggested methods of implementing a command parser that has a way of not firing the case selector for commands we'd like to disable. As a side effect of disabling a command, a signal assigned in that select should also get optimized away if it is not referenced in higher-up code.

For purposes of discussion, the design has three variants: DEFAULT, A and B. In the default, all commands are handled. In A, some commands are disabled. In B, the other commands are disabled. The variant is set with a generic at the top level.

A command sets or clears an output, depending on the bit in the argument. If the command is valid, the signal cmd_ok is strobed. If the command is invalid (because it is disabled) the signal cmd_nok is strobed.

The two methods of disabling commands are:
1. a function is used to "filter" out invalid commands, based on the variant chosen. Commands not handled are "invalid." In the parser case statement, all possible commands are listed as selectors, but the commands not handled in a given variant have been "remapped" by the parser to the invalid command, so their selectors are never invoked.
2. in each case selector, if the variant chosen allows the command, it is handled: the output bit is assigned and cmd_ok asserted, otherwise the output signal is ignored and cmd_nok is asserted.

The source code is three files.

cmd_pkg.vhdl defines a few useful types and two functions. One function handles that remapping and outputs an enumerated type. The other simply converts the std_logic_vector command to that same enumerated type.

parser.vhdl is the parser. It has two architectures: one, called "filter," uses the filter method described above to get the case expression. The other, "nofilter," does as #2 described above and tests each case selector to see whether it should be handled in the chosen variant.

top.vhdl holds six different top-level entities. Three are for the "filter" parser, with variants default, A and B, and three are for the "no-filter" parser. This could have been boiled down to just two entities, filter and no filter, but the synthesizer doesn't allow setting a generic with an enumerated type from the command line. Please note: the top-level entities do not have the signals assigned in "unused" command case selectors. My real design is like that -- those signals simply don't exist.

In the synthesis directory is a Synplify Pro project file. I used the version of Synplify that ships with Lattice Diamond 3.12, which is Q-2020.03L-SP1.

(Interestingly, this version of Synplify claims to support VHDL-2019's conditional analysis feature -- the preprocessor! But, I didn't test it, because the point was to test how a synthesizer would handle the test cases.)

The project includes the three source files and has two implementations: "top_A_nf" and "top_A_f," for variant A with no filter function and with the filter function. The target is a MachXO2-1200, chosen for no good reason. The correct top level entities are chosen for both.

And the results:

In the filter version, the only obvious synthesis warning is for some input bits not being used. These bits would be assigned to output bits if the command wasn't filtered out. In the non-filter version, the output bits that are not used because their commands don't exist are never assigned, so we're told that. (also the same input-not-used warning is here.)

Let's look at the synthesis outputs.

Here is the RTL schematic of the "filtered command" parser. (The top level schematic is nothing more than ports connected to the parser.) It's down to three flip-flops for the outputs that are enabled (E, F, G) and two more for the OK and NOK flags. The command was turned into a one-hot vector, so three valid commands mean three command bits which are ANDed and drive the flops' enables. Clearly the filter did its job, there is no logic at all for the disabled commands.


Here is the RTL schematic for the "no filter" parser. It's all just ... more complicated.


Now the fun ... the optimized schematics. The top level schematics are the same for both versions, so I'll post only one (the "filter" version):


The parser schematic is highly the same for both versions. Both have one LUT per output (five outputs: three E, F, G flag bits, and the two OK/NOK bits). How the LUTs are configured are slightly different, but they boil down to the same exact resource usage, and of course they are functionally identical. Here is the "filter" parser schematic:

CONCLUSION!
Both styles result in the same resource use for this example. The signals associated with disabled commands are optimized away, as are the decoders for those commands. This is ultimately what I wanted.

So the question is, which should I (we, you) use? Possibly a matter of preference.

I will give an edge to the "no filter" version, where the test for whether the command is enabled is in the decoder selector. Why? Because in my design, the number of commands that are common to all variants is much greater than the number of variant-specific commands. It's a lot more obvious to see what's going on if you put the "if VARIANT = THISONE" in the handful of case selectors that care, rather than to bury the command disable/enable in a function in a package in a different source file. We all like to write code that is very obvious to the reader, right? Of course we do!

I hope this was enlightening, and it shows that we don't need no stinkin' preprocessor! All we need to do is to just ignore a few synthesis warnings about signals not being used or being optimized.

[asmi]

Well, despite being a VHDL partisan with an allergy to all things Verilog, I will state that what asmi writes above is exactly what I want.

And that still won't make me switch to SystemVeriilog.

In my experience people use VHDL because they are too old/too lazy/too stubborn to learn SystemVerilog. I'm yet to meet a person who learned both languages and voluntarily chose VHDL over SV.

So I'll hazard a guess that all these "allergies" are just a lousy coverup for good old laziness.

[Just_another_Dave]

Well, despite being a VHDL partisan with an allergy to all things Verilog, I will state that what asmi writes above is exactly what I want.

And that still won't make me switch to SystemVeriilog.

In my experience people use VHDL because they are too old/too lazy/too stubborn to learn SystemVerilog. I'm yet to meet a person who learned both languages and voluntarily chose VHDL over SV.

So I'll hazard a guess that all these "allergies" are just a lousy coverup for good old laziness.

Well, in Europe VHDL is used because it is the language that most companies ask for in their job offers. Therefore, it is the language that universities usually teach in their EE degrees. Consequently, it is better to focus your efforts on learning about dynamic reconfiguration of FPGAs, reliability, IC design, etc. than learning another language

[asmi]

Well, in Europe VHDL is used because it is the language that most companies ask for in their job offers. Therefore, it is the language that universities usually teach in their EE degrees. Consequently, it is better to focus your efforts on learning about dynamic reconfiguration of FPGAs, reliability, IC design, etc. than learning another language

You still got to learn both at least to some degree because chances are you are going to have to work with third-party IPs written in another language. So you can only really ignore other languages if you are a hobbyist and can afford to roll your own, in professional setting you will have to deal with both.

But I was talking about personal choice given both options are on the table. I've never met a VDHL person who also knows SystemVerilog well, but I've met a plenty of SV people which also know VHDL.

[Just_another_Dave]

Well, in Europe VHDL is used because it is the language that most companies ask for in their job offers. Therefore, it is the language that universities usually teach in their EE degrees. Consequently, it is better to focus your efforts on learning about dynamic reconfiguration of FPGAs, reliability, IC design, etc. than learning another language

You still got to learn both at least to some degree because chances are you are going to have to work with third-party IPs written in another language. So you can only really ignore other languages if you are a hobbyist and can afford to roll your own, in professional setting you will have to deal with both.

But I was talking about personal choice given both options are on the table. I've never met a VDHL person who also knows SystemVerilog well, but I've met a plenty of SV people which also know VHDL.

Maybe it is something related to the type of applications that they design, but the companies for which I have worked for didn’t allow us to use any IP programmed in a different language to VHDL

[asmi]

Maybe it is something related to the type of applications that they design, but the companies for which I have worked for didn’t allow us to use any IP programmed in a different language to VHDL

I guess so, in my experience (admittedly not very long) I had to deal with third-party components written in all languages - regular Verilog, and VDHL. While I prefer SV, but I know enough of other languages to read and understand the code, and do some debugging if integration doesn't work like it should.

[Bassman59]

Well, despite being a VHDL partisan with an allergy to all things Verilog, I will state that what asmi writes above is exactly what I want.

And that still won't make me switch to SystemVeriilog.

In my experience people use VHDL because they are too old/too lazy/too stubborn to learn SystemVerilog. I'm yet to meet a person who learned both languages and voluntarily chose VHDL over SV.

So I'll hazard a guess that all these "allergies" are just a lousy coverup for good old laziness.

Thank you for impugning our cocksmanship.

[SiliconWizard]

LOL you guys as always went deep into the woods in your attempts to defend that POS of a language As I understood, what OP wants is this (code in C so that even VHDLers would understand):

Code: [Select]

switch (op)
{
case OP_FOO:
//handing operation FOO
break;
case OP_BAR:
//handing operation BAR
break;
#ifdef OP_EXTENDED_1_SUPPORTED
case OP_EXTENDED_1:
//handing operation OP_EXTENDED_1
break;
#endif
#ifdef OP_EXTENDED_2_SUPPORTED
case OP_EXTENDED_2:
//handing operation OP_EXTENDED_2
break;
#endif
default:
//handing unknown operation
break;
}
Important point is that OP_EXTENDED_x opcodes are treated as unknown ones if such support is disabled. Now please show us how to implement this trivial code. And no, a bunch of generate's with copy-pasted switched for all possible permutations of supported opcodes is not acceptable.

So yes, "use SystemVerilog" is the only sureway solution to avoid having to deal with this garbage again.

Well, despite being a VHDL partisan with an allergy to all things Verilog, I will state that what asmi writes above is exactly what I want.

As you saw later on, I would rather say: no, you *thought* that's what you wanted. But there are more elegant ways to do it in VHDL that get you the exact same thing. As I said, many VHDL features are equivalent to a fancy preprocessor. That's what you could see for yourself.

VHDL has strong similarities with ADA, which doesn't need a preprocessor either for generic programming. Thinking of using a preprocessor mostly comes from our habits with C. For lack of a better approach. So yeah, properly using VHDL for generic programming requires a slightly different mindset and knowing the language a bit better.

Now if warnings about removed logic and removed signals annoy you... well. In a moderately complex design, there will be tons of those warnings, even when there are no conditional exclusions. That's part of logic optimization. Many signals can get optimized out due to being logically equivalent to others in some way. So that doesn't make much difference...

Now you could also do this with 'if generate' statements, which would completely exclude some parts of code conditionally. In the case you showed, that would mean splitting your decoder into several processes/or even entities, which would be pretty cumbersome - and would need additional steps for combining the outputs of the various parts together. I wouldn't recommend it here. (That's what I think nctnico suggested at some point?) But that would be yet another approach.

VHDL-2019 additions look nice, but frankly we can do without them. And, I wouldn't hold my breath for tools support any time soon...

[nctnico]

Yeah, bolting on C-isms to a language is never a good idea. Borland Delphi from the early 2000's comes to mind. What a steaming pile of rubbish! 

Just for clarity: I didn't suggest to break the logic that handles the commands into several pieces but to handle it before (the filtering). It is just that my brain isn't set to VHDL at this moment.