complex code : signals or variables (vhdl)

[ajrox]

i'm writing a vhdl code for modbus protocol.
crc calculations for a frame in modbus involve many arithmetic and logical operations.
most of the calculations require immediate operations on the same object.
i've used variables for this purpose and the simulation works to fine.

however is it appropriate to use variables for actual hardware instead of signals?

 

[std_match]

It can work, but you will probably waste resources and have a bad maximum frequency.
If your goal is to be a good VHDL designer, don't use variables until you understand what the hardware will look like after synthesis.

As an example, you should not use a variable to loop through the frame in one clock cycle.
You will not see a problem in simulation, but the code will probably be useless for synthesis.

CRC calculations are normally extremely simple to realize in hardware if you understand what is going on.
It is much more complicated to do it in software, so a very bad approach is to start with a software implementation and then convert it to vhdl.

The most effective CRC implementation is to calculate it on the fly, as each byte/word is going in/out.
The core equations can easily be generated here: https://www.easics.com/webtools/crctool

 

[ajrox]

thanx std_match!
also i wanted to ask-is it better to write modules for structural modelling or subprograms for behavioral modelling while designing a chip

 

[permute]

Behavioral should be preferred when you are confident:
1.) it could/does have an efficient implementation.
2.) you could check and change it if needed.

One of the least used tools is sandboxing -- trying out a small coding construct examples to see what it creates. This can be massively useful. For example, using "+" works better than carry-lookahead in FPGAs. For-loops often work just fine if the logic inside the loop is simple.

Variables can be used for convenient combinatorial logic, but try to avoid inferring registers from them. It is ok, but can make the code less readable.