HDL vs Software Mentalities

[redsees]

Hello everyone,

Anyone knows a book or something that can help my brain leave the "software programming" perspective. I can't seem to easily switch to HDL mindset.
I mean, every HDL project I try to code, I end up being intensively criticized for how ugly my HDL code design is, and it's almost a software rather than an HDL.
How can I optimize and/or correct my way of thinking for doing better HDL code?
I worked with multiple hardware logical gates projects, built a simple ALU on hardware (using discrete chips/components), that didn't help much in the code, even though HDL is a digital design afterall.

Much Regards

 

[FlyingDutch]

Hello,

just try to think about modules(entities) in your design as a "digital elctronic circuits" connected together with wires ;-)

In my case it helps.

Regards

 

[pbernardi]

Which HDL do you use?

Verilog is a lower level language and should help you to go away from "software mentality", even because some higher-level concepts (floating point for example) simply does not exists here.

VHDL, for other side, being a higher level language, has a lot of temptations from a guy that has a "software mentality" - although I am sure that many will say that the important is not the language and bla bla bla.

What are the most common design issues your colleagues point out?

 

[FlyingDutch]

Hello everyone,
...
I can't seem to easily switch to HDL mindset.
I mean, every HDL project I try to code, I end up being intensively criticized for how ugly my HDL code design is, and it's almost a software rather than an HDL.

Much Regards

Hello,

and what about "HLS" (High Level Synthesis) in such context. Last times Xilinx and intel make much clamour about "HLS" to help software developers making digital designs with FPGAs? And what in case using soft-processors in HDL designs? More and more tools support thinking about hardware designs as a software - what think about such tendencies?

Regards

 

[ThisIsNotSam]

Verilog is a lower level language and should help you to go away from "software mentality", even because some higher-level concepts (floating point for example) simply does not exists here.

VHDL, for other side, being a higher level language, has a lot of temptations from a guy that has a "software mentality" - although I am sure that many will say that the important is not the language and bla bla bla.

Sorry, what? Both languages can be used for RTL description, which is what you should use to describe digital logic. Verilog and VHDL have the exact same capability to describe hardware in RTL, your argument makes no sense.

 

[barry]

Sorry, what? Both languages can be used for RTL description, which is what you should use to describe digital logic. Verilog and VHDL have the exact same capability to describe hardware in RTL, your argument makes no sense.

Agreed! This was obviously written by a Verilog person. (Full disclosure:I'm a VHDL guy).

 

[TrickyDicky]

Which HDL do you use?
Verilog is a lower level language and should help you to go away from "software mentality", even because some higher-level concepts (floating point for example) simply does not exists here.
VHDL, for other side, being a higher level language, has a lot of temptations from a guy that has a "software mentality" - although I am sure that many will say that the important is not the language and bla bla bla.
What are the most common design issues your colleagues point out?

Ive actually seen it argued the opposite - anyone with a C background will be more familiar with Verilog constructs. VHDL will be so alien to them that they can learn hardware description better as its harder to fall back into programming habits.

Sorry, what? Both languages can be used for RTL description, which is what you should use to describe digital logic. Verilog and VHDL have the exact same capability to describe hardware in RTL, your argument makes no sense.

It is generally accepted that VHDL can go to a higher level of abstraction than verilog. But System Verilog fixes all that (and brings the complexity of about 3 languages forced together in some disharmony) and then some (when you get into verification). But then again, most people really dont understand enough VHDL to actually take it to an extreme level of abstraction, with functionality in VHDL2008 comparable to SV in VHDL 2008 when you understand what you can really do in simulation.

To the OP: What is the problem? does the code synthesis to the circuit you expected? if thats the case, then whats the problem? Do you know how you could add extra pipe stages, break up a combinatorial logic infered from all those "ifs" A lot of people do have a problem with "software style" VHDL, mainly because its not their style, or the "conventional" style taught in text books that hasnt really changed for 25 years! And people dont like change.
If you are working in a company, then its a good idea to follow some sort of regular style, as this makes the code more portable and easier for others to understand.

As long as your code is inside a synchronous process, then pretty much any code is fair game, as long as you understand the consequences of your coding style. If you dont know what a line of code will synthesise to, then I suggest sticking with basic templates provided by the vendors in their coding style guides.

---

Code VHDL - [expand]
1
2
3
4
5
6
process(clk)
begin
  if rising_edge(clk) then
    -- Most code here is fair game IMO
  end if;
end process;

---

 

[ThisIsNotSam]

It is generally accepted that VHDL can go to a higher level of abstraction than verilog.

I don't see how.
Please, let's not confuse the OP even more. This is not about the verification features of a language, I am talking strictly about the ability to describe hardware in RTL fashion. VHDL and verilog are equivalent. Sure, verilog allows to model transistor level delays and strength. No one uses that for actual design.

 

[TrickyDicky]

I don't see how.
Please, let's not confuse the OP even more. This is not about the verification features of a language, I am talking strictly about the ability to describe hardware in RTL fashion. VHDL and verilog are equivalent. Sure, verilog allows to model transistor level delays and strength. No one uses that for actual design.

VHDL has libraries, packages, method overloading that Verilog does not. But the higher level of abstraction is mostly for simulation purposes for Modelling and when it comes to synthesisable RTL, then they are equivalent.

 

[ThisIsNotSam]

VHDL has libraries, packages, method overloading that Verilog does not. But the higher level of abstraction is mostly for simulation purposes for Modelling and when it comes to synthesisable RTL, then they are equivalent.

Agreed.

OP, you must make an effort to learn to write synthesizable code instead of to learn the language itself (I know how this sounds paradoxical). As pointed out above, it implies you have to learn coding patterns/styles that are accepted by the synthesis tools. Just stay within that framework and you will be fine.

 

[pbernardi]

Sorry, what? Both languages can be used for RTL description, which is what you should use to describe digital logic. Verilog and VHDL have the exact same capability to describe hardware in RTL, your argument makes no sense.

No, Verilog has way less capabilities.

You cannot directly describe a float in Verilog
You cannot directly describe a string in Verilog
You cannot try to order attributions inside a proccess in Verilog (all occur in parallel)
Among others.

All these characteristics allows VHDL to be far from HW in my opinion, specially if someone comes with a "software programming" perspective. The first thing a SW guy will try to do when learning VHDL is: use float, strings, variable and sequential attributions.

In Verilog, you simply cannot goes this far.

 

[redsees]

Thanks everyone for taking the time to reply.

Unfortunately, the little debate above of VHDL vs Verilog (and others) did confuse me a bit. I wasn't asking which is better or easier, I was asking about how not to embed all my design into one always block sequentially (which is really software coding style). Btw, my language is Verilog.

My code is synthesizable, and it did indeed work as expected when burned it into the board, but imagine having a huge cryptographical core programmed into one sequential always block, with few tasks (which I thought to use as functions in the software world), I showed that code to lots of people, almost all of them agreed that this didn't even look like a hardware code.

I'm really sorry if the question is really newbie and beginner, it's just I need to know how can I optimize my coding in order to look (and run) more like hardware style.

 

[ThisIsNotSam]

No, Verilog has way less capabilities.

Those are useful features at best, but they don't raise the abstraction level.

 

[TrickyDicky]

Thanks everyone for taking the time to reply.

Unfortunately, the little debate above of VHDL vs Verilog (and others) did confuse me a bit. I wasn't asking which is better or easier, I was asking about how not to embed all my design into one always block sequentially (which is really software coding style). Btw, my language is Verilog.

My code is synthesizable, and it did indeed work as expected when burned it into the board, but imagine having a huge cryptographical core programmed into one sequential always block, with few tasks (which I thought to use as functions in the software world), I showed that code to lots of people, almost all of them agreed that this didn't even look like a hardware code.

I'm really sorry if the question is really newbie and beginner, it's just I need to know how can I optimize my coding in order to look (and run) more like hardware style.

Tasks dont really get used alot. The same with functions/procedures in VHDL - people dont use them and so are not comfortable using them, especially when they do anything too complicated. Remember that if a function needs fixing later for timing etc - it can be very hard to put a register in the middle of a task call - you'll need to take the code out of the task and into the body of the code - not much fun.
Is this code for work, or a hobby? if its hobby - who cares what others think? if its work, then you need to be careful - you might get a reputation for being the "crazy code guy".

IMO, tasks should only be used if they are wrapping up code that is used in more than one place - because this will allow a single edit and 2+ mods (ie, where its called). If its used only once - dont use a task.

 

[ads-ee]

IMO, tasks should only be used if they are wrapping up code that is used in more than one place - because this will allow a single edit and 2+ mods (ie, where its called). If its used only once - dont use a task.

And are limited in the amount of logic they produce, with comments related to the maximum depth of logic that will be produced for a given set of inputs, so anyone using it later (if it can be reused) doesn't run into timing issues due to 35 levels of logic at 300 MHz (not going to happen).

 

[asdf44]

One big always block does sound software-ish.

I tent to start by thinking about functions that are needed (counter, shift register, multiplier etc) and by thinking about those functions as their own always block. If coordination is needed that warrants a central state machine that “pulls the strings” of the dumb functional blocks like a puppet master with well named control signals like “shift_en”, “shift_rst” etc.

The point is that if you have a multiply anywhere your code will synthesize a multiplier. An HDL designer will tend to write code which emphasizes that and can be more easily skimmed to inventory the hardware it’s actually creating and the signal flow between those hardware blocks.

 

[TrickyDicky]

One big always block does sound software-ish.

I tent to start by thinking about functions that are needed (counter, shift register, multiplier etc) and by thinking about those functions as their own always block. If coordination is needed that warrants a central state machine that “pulls the strings” of the dumb functional blocks like a puppet master with well named control signals like “shift_en”, “shift_rst” etc.

The point is that if you have a multiply anywhere your code will synthesize a multiplier. An HDL designer will tend to write code which emphasizes that and can be more easily skimmed to inventory the hardware it’s actually creating and the signal flow between those hardware blocks.

I think you can go too far the other way. Ive seen code that put every register and base level primitive in its own always block - Id say this is worse to read than a "software style" coding. Then you can also get annoying situations with uneccessary layers of hierarchy just to stay in keeping with "hardware design", but it makes other engineers lives harder.
There is no universal style and its a very subjective subject. If you keep to the rule that the code is going to be passed to someone else with no/little knowledge of your design, so document and comment it well, the style should be less important (assuming you followed the spirit of the company style guide)

 

[redsees]

I see, that makes sense actually.
And yea, I'm doing it as a hobby actually, I'm mainly into cyber security, just working in digital/embedded electronics in my spare time.


Thanks everyone for the time you took to reply.

Much Regards

 

[pbernardi]

It is not a general rule, but when I have several pipelines in sequence, I separate the always blocks into the pipelines:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
/* PIPELINE 1 */
always @(posedge CLK)
begin
(...)
end
 
/* PIPELINE 2*/
always @(posedge CLK)
begin
(...)
end

---

I guess that instead pipelines you could separate by other classification as well (circuit types for example). As TrickyDicky mentioned, there is no universal style, but a big always block really looks strange.

 

[vGoodtimes]

SW-ish is fine-ish.

Specifically, if you can reasonably guess what a synthesis tool will do with some code -- that you know you have a backup strat -- you can do as much as you can justify with comments.

"SW" design isn't always bad. In some cases "describing a thing" is both a SW and HW problem and the solutions can overlap. The real question is if the description of the logic synthesizes into efficient HW, not if it is easy to understand without specifically describing it in a HW centric manner.

The issue is when you don't understand HW issues and just ignore them because a SW-style solution exists. But general design concepts can apply to HW even when they are more popular in SW. tasks/procedures can be very useful. They can also be terribly misused. The complexity of a circuit is not always related to the length of the statements that infers them.

Using a task once or multiple times is also not always a fair condition. As an example, it is possible to have a "C-style class" that describes a RAM -- a set of signals and a few procedures to assign reads and writes. Using only procedures to for the RAM interface means no accidents. It also means possible lack of optimization due to being overly strict /wrt address when enable = 0. This is a case where a structured use-case could result in a task being used zero to one times while also providing benefits.


(In terms of VHDL vs Verilog-2001, VHDL's highly flexible generics get rid of a lot of pre-processor abuse and code-gen.)