Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Is the "Gaisler method" of writing "structured VHDL" popular?

Status
Not open for further replies.

matrixofdynamism

Advanced Member level 2
Joined
Apr 17, 2011
Messages
593
Helped
24
Reputation
48
Reaction score
23
Trophy points
1,298
Activity points
7,681
I have come across the idea of "A Structured VHDL Design Method" by Jiri Gaisler. It basically proposes a certain style of describing hardware using VHDL in which we always split the hardware block into two processes, one is (mostly) written using variables and assigns the result into a signal, this process looks like a sequential C program; the other processes is clocked and updates signals inside it using the results from the other first process.

The basic idea is to make it easier to write complex algorithmic code in VHDL. Is this method known/used by anyone on this forum before?
 

Re: Is the "Gaisler method" of writing "structured VHDL" popular?

2 process style has generally fallen out of favour for single process style.
2 process goes back to the start of synth tools where logic and registers had to be separated. I think a lot of designers just learned this method and it became natural for them.
The paper I have found has no date in it (The mention of a LEON SPARC-V8 implies its maybe 20 years old). But I suspect is from a time when records were little used, and seems to talk about the virtues of records as much as the two process style. They are still used far too infrequently, but at least people acknowledge them and understand them. It is also pretty common now to use variables inside synchronous processes to describe combinatoral code.

- - - Updated - - -

And another thought - another thing people probably dont use but it can make your code much more readable is aliases (which are fully supported now). It can really help with self documenting style code:


Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
signal vid_ip  : std_logic_vector(29 downto 0);
 
alias vid_ip_R : std_logic_vector(9 downto 0) is vid_ip( 9 downto  0);
alias vid_ip_G : std_logic_vector(9 downto 0) is vid_ip(19 downto 10);
alias vid_ip_B : std_logic_vector(9 downto 0) is vid_ip(29 downto 20);
 
....
 
vid_ip_R  <= 10x"100";
vid_ip_G <= 10x"3FF";
vid_ip_B <= 10x"3FF";

 
It is a pretty common approach, some will even say it is outdated. I learned and teach the 2 process style, but I always make a strong point to all my students: the power of describing logic in one process or in 2 or in 3 is the same. You don't suddenly create better hardware because of one give style. They are all equivalent.
 

The paper is actually almost 20 years old. IIRC it was 1998 or 1999. I think at the time some of the constructs were not well supported by all tools.

--edit:

1-process is the going fare. It's pretty terrible from a technical standpoint, but you have to learn and understand it. Don't worry though, there is a growing elitism around it. So you can feel good about yourself while you track down hideous corner cases instead of reading warnings...
 

I'm fresh from university, and I learned both styles: 2-process at first (with focus on state machine style), and after that everyone just used the 1-process style for everything. For simple designs, this approach is legitimate (single process, sequential flow, ...), but as soon as I started to use AXI-Streams with registered valid signals and combinatorial ready signals, the 1-process style started to freak me out each time I revisited old code. The valid signals are speficied in the process, and the combinatorial ready signal is specified outside of it, making the code harder to read. Two months ago I first read about the "Gaisler method", and suddenly AXI-Streams are no-brainers for me. Registered and combinatorial signals are handled in the same way, allowing a true "sequential" way of describing logic. Nevertheless I dislike the "records for everything" - style, since it makes generic components really hard to specify. VHDL2008 made some effort regarding generic packages, functions etc., but I still haven't solved each use case with it.
 

    tgreguric

    Points: 2
    Helpful Answer Positive Rating
When I did course in VHDL at my job (it was Doulos Comprehensive VHDL and very expensive), they did not actually teach the Gaisler method. Only for state machines they emphasized that the sequential (that stores current and past states) and combinatorial part (the next state logic) be kept in separate processes. Overall, there was no emphasis on having two processes like it in the Gaisler method.

The way I write code, I may use variables sometimes as it makes it possible to break down a complex operation into simpler sequence of operations that will complete within the same cycle. Thus, for me, I only use them to make code easier to write, sometimes. With this two process method, it seems to use variables a lot.
 

The discussion on a 2 process and 1 process model has been discussed here many times, and will be done again in the future (because most people do not appropriately search the net for the answer the need).

Nevertheless, this article was published a couple of days and discusses bang-on, why a single process model.
MicroZed Chronicles – Finite State Machines Tips : https://adiuvoengineering.com/
I find the above very rational.
 

1-process is the going fare. It's pretty terrible from a technical standpoint, but you have to learn and understand it. Don't worry though, there is a growing elitism around it. So you can feel good about yourself while you track down hideous corner cases instead of reading warnings...
Actually you've repeatedly proven your elitist attitude on using 2-process sequential logic, and in this case spilling into the realm of rude, unwarranted, and demeaning.

I've found your coding style to be a far less maintainable. I've gotten stuck working with code like this....Why? because they think exactly like you do.

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// a simple byte wide 2 stage pipeline
reg [7:0] reg_d1,reg_d2;
reg [7:0] reg_q1,reg_q2;
 
// oh yeah they don't like using begin-end because they want to write efficient code... 
//    always @(posedge clk) has 21 chars, <sp>begin<cr> .... <cr>end has 11 chars
always @(posedge clk)
  reg_q1 <= reg_d1;
 
always @(posedge clk)
  reg_q2 <= reg_d2;
 
// lines and lines of more code here, sometimes 200+ lines one time I had a file from a
// professor on a joint university/industry project that had 1000's of lines between these
// sections of code.
 
// also have run across inconsistent usage of process and assignments for the same part
// of the code for no apparent reason, besides not realizing in their 3000+ line files that
// they had done it differently somewhere else.
always @(*) begin
  reg_d1 = some_input_to_pipeline;
end
 
assign reg_d2 = reg_q1;


Me I just would write it in a single always block violating your elitist rules.

Code Verilog - [expand]
1
2
3
4
reg [7:0] reg1,reg2;
always @(posedge clk) begin
  {reg2, reg1} <= {reg1, some_input_to_pipeline};
end


Writing simple efficient code I guess makes me some elitist cry baby, who can't find their coding mistakes (not that I make many errors besides misspellings and missing ';'s)
 

Re: Is the &amp;quot;Gaisler method&amp;quot; of writing &amp;quot;structured VHDL&amp;quot; popular?

Nevertheless I dislike the "records for everything" - style, since it makes generic components really hard to specify.

It isn't likely that you'll have a module with the same FSM states or same outputs. The record should be fairly close to unique -- it doesn't need to go into a package.

dpaul said:
MicroZed Chronicles – Finite State Machines Tips : https://adiuvoengineering.com/
I find the above very rational.

At the same time, they instantly show why the method is also tricky. "output is a function of the current state only". Now there is a case where you are in "LED_ON" with the led off. For this application, that is probably fine. But this isn't addressed in the article. In a way, it echos the author's lament about inconsistent interfaces with signals arriving at unexpected times. In the 2-process version, this oversight would require some effort to reproduce.

The article also complains about sensitivity lists and latches. These are actually addressed using the Gaisler method from the original post. I'm also suspicious of the advice to have single bit inputs/output. That said, I will often use variables to name common subexpressions in order to reduce verbosity in the core of the FSM.

The basic idea is to make it easier to write complex algorithmic code in VHDL. Is this method known/used by anyone on this forum before?
In theory, Gaisler's method removes many of the downsides of the 2-process style -- sensitivity list is auto-updated and next_x/x are both auto-added when put into the record. A downside is that the signals get somewhat of an extra layer of typing. You have to remember that the outputs were part of the FSM, which isn't something you normally need to know. Another downside is that it makes it seem like a good idea to write more complex logic within FSMs.

--edit: It has been a while since I last read the Gaisler article. I think some of my comments were more about a version that uses the records only for the FSMs.

- - - Updated - - -

Actually you've repeatedly proven your elitist attitude on using 2-process sequential logic, and in this case spilling into the realm of rude, unwarranted, and demeaning.

I've found your coding style to be a far less maintainable.

Perhaps there has been some misunderstanding. I am not suggesting using separate processes for everything. Actually, I really dislike that style. I am also not suggesting using two-process logic for everything, just FSMs.

- - - Updated - - -

Actually you've repeatedly proven your elitist attitude on using 2-process sequential logic, and in this case spilling into the realm of rude, unwarranted, and demeaning.

I've found your coding style to be a far less maintainable.

Perhaps there has been some misunderstanding. I am not suggesting using separate processes for everything. Actually, I really dislike that style. I am also not suggesting using two-process logic for everything, just FSMs.
 
Last edited:
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top