FPGA Design Code Cleanliness 2

mdy-吴伟杰

FPGA Design Code Cleanliness 2 [Copy link]

Ron Jeffries , author of Extreme Programming Practice, carefully studied Baker's simple code rules and listed them in order of importance:

& can pass all tests

& No duplication of code

＆ Embody all the concepts involved in the system

& Include as few entities as possible, such as classes, methods, functions, etc.

The ability to pass all tests will be explained in detail in the architectural design later. Here we will use a small example to illustrate some techniques of "no duplication of code".

Once I printed out several different program codes on A4 paper and spread them on my bed for comparison. My daughter who was still in primary school said: Dad, do you just watch these caterpillars crawling around every day? Always, if, else, begin, yes, and end, probably these are the ones. The childish words of the child made me laugh. When I looked back at the codes, I suddenly remembered what a master said: Most programs are composed of very similar elements. It is true! At the same time, due to this similarity, repeated codes appear in many programs. Let's take a look at the following set of codes:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

assign data0 = {1'b1,din0,1'b0}; assign data1 = {1'b1,din1,1'b0}; assign data2 = {1'b1,din2,1'b0}; always @(posedge clk or negedge rst_n)begin if(rst_n==1'b0)begin dout <= 0 ; end else if(sel0)begin dead <= data0[9-cnt2]; end else if(sel1)begin dead <= data1[9-cnt2]; end else begin dout <= data2[9-cnt2]; end end

This is the code of a serial port sending program. The function it implements is to send three data 0, 1, and 2. Obviously, in lines 2 to 4, the same thing is done three times in the program. Lines 10 to 19 are also selected three times, which is repeated code. As the number of signals increases, four, five, and N signals are needed. The program becomes more and more cumbersome.

The repeated appearance of the same code makes the boundary of "uniqueness" blurred and confusion is likely to occur. In other words, the author's idea is not implemented optimally. In this example, if you enter " ? " in the search engine, you will get similar results . Remember the "do simple things" mentioned in the previous article? At this time, we should think about whether the code itself is redundant or whether the object has too many functions. If it is the former, we should improve it from effective naming, etc.; if it is the latter, we should "simplify complex things" and take some means to reconstruct it so that the functions can be clearly explained and implemented.

As for the code above, what should be the correct idea and approach? Let's look at the following code.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

always @(*)begin if(sel0) from_sel = from0 ; else if(sel1) from_sel = from1 ; else din_sel = din2 ; end assign data = {1'b1,din_sel,1'b0}; always @(posedge clk or negedge rst_n)begin if(rst_n==1'b0)begin dout <= 0 ; end else begin dout <= data[9-cnt2]; end end

First, select din0, 1, and 2. If it is se10, then din-se1 is equal to din0; otherwise, if it is se11, then din-se1 is equal to din1; otherwise, din-se1 is equal to din2;

Next we add 0 and 1;

Then select the timing. The change of dout is XXXXXX , and the code is complete.

By comparison, it is not difficult to see that in the second code, whether it is padding 0 or 1, or sending dout, it is only done once. One line of code only does one thing and does it well, making the programming language look like it exists specifically to solve this problem.

Another point is that in the two examples in this section, the first code needs to verify the signals din0, din, din2...din N in sequence. Any error in the process will be very troublesome; while the second code only needs to verify that the logical relationship between them is correct.

It should be noted that this section uses a very small signal output code as an example. The larger and more complex the code, the greater the efficiency and quality gap between the two methods. The next section "Signal naming and definition should be clear"