Electronics > FPGA

work around VHDL's lack of a preprocessor

<< < (10/10)

asmi:

--- Quote from: Just_another_Dave on September 27, 2021, 01:07:31 pm ---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

--- End quote ---
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:

--- Quote from: asmi on September 27, 2021, 11:41:49 am ---
--- Quote from: Bassman59 on September 26, 2021, 07:39:24 pm ---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. ;)

--- End quote ---
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.

--- End quote ---

Thank you for impugning our cocksmanship.

SiliconWizard:

--- Quote from: Bassman59 on September 26, 2021, 07:39:24 pm ---
--- Quote from: asmi on September 25, 2021, 07:11:44 pm ---LOL you guys as always went deep into the woods in your attempts to defend that POS of a language :palm: As I understood, what OP wants is this (code in C so that even VHDLers would understand):

--- Code: ---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;
}

--- End code ---
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.

--- End quote ---

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.

--- End quote ---

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!  :-BROKE

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.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version