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.

Register Log in

VHDL code optimization

Status
Not open for further replies.
A

arkoudinos

Newbie level 4
Joined
Apr 14, 2016
Messages
7
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
94
I have a particularly weird control unit to implement, which generates some control signals based only on the value of an internal counter, obviously counting clock cycles. Firstly I would like to ask how (un)common is to generate control signals based solely on the number of clock cycle?

Secondly, in order to design this, I've came up with a process having in its sensitivity list only the counter output signal.

At this point I should note that there is a specific procedure taking place on regular intervals - every 47 clock cycles - (re-reading from the same memory addresses) something that it could be efficiently represented in a programming language with a for-loop.

So, inside that process I've started writing a HUGE sequence of if...elsif... statements, something I find quite stupid. Is there a better way to implement this (fewer lines of code, most efficient in terms of maintenance, etc)?

Here you can find that procedure which should be done every 47 cycles:

Code VHDL - [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
25
26
27

-- One strip has been completely checked. Reset memory counter.
        -- Start reading submemory 1. Writing only 16 pixels on submemory 3.
        elsif (count = x"050") then -- Cycle number 80
            cs_en_col_load <= '1';
            cs_colcnt <= "00000";
            cs_en_wr_mem3 <= '1';
            cs_datasel <= "11";
            
        elsif (count = x"051") then -- Cycle number 81
            cs_en_col_load <= '0';
            cs_en_wr_mem3 <= '0';
        
        -- Start reading submemory 2. Writing only 16 pixels on submemory 1.
        elsif (count = x"60") then -- Cycle number 96
            cs_en_wr_mem1 <= '1';
            cs_datasel <= "01";
        
        elsif (count = x"61") then -- Cycle number 97
            cs_en_wr_mem1 <= '0';
        
        -- Start reading submemory 3. Writing only 16 pixels on submemory 2.
        elsif (count = x"70") then -- Cycle number 112
            cs_en_wr_mem2 <= '1';
            cs_datasel <= "10";
            
        elsif (count = x"71") then -- Cycle number 113
            cs_en_wr_mem2 <= '0';


Before that, there are some necessary initialization signals, during the first cycles.

Thank you in advance for your time.
 
Last edited by a moderator:

arkoudinos said:
I have a particularly weird control unit to implement, which generates some control signals based only on the value of an internal counter, obviously counting clock cycles. Firstly I would like to ask how (un)common is to generate control signals based solely on the number of clock cycle?
Click to expand...
Yes it is common. The counter is a state machine. The outputs simply decode the state
Secondly, in order to design this, I've came up with a process having in its sensitivity list only the counter output signal.

At this point I should note that there is a specific procedure taking place on regular intervals - every 47 clock cycles - (re-reading from the same memory addresses) something that it could be efficiently represented in a programming language with a for-loop.
Click to expand...
OK

So, inside that process I've started writing a HUGE sequence of if...elsif... statements, something I find quite stupid. Is there a better way to implement this (fewer lines of code, most efficient in terms of maintenance, etc)? **broken link removed** you can find that procedure which should be done every 47 cycles. Before that, there are some necessary initialization signals, during the first cycles.
Click to expand...
Personally, I like the look of a case statement:

Code: 
process(count)
    variable vcount: natural range 0 to 255;
begin
    vcount := to_integer(count)
    case count is
        when 80  => cs_en_col_load <= '1'; cs_colcnt <= "00000"; cs_en_wr_mem3 <= '1'; cs_datasel <= "11";
        when 81  => cs_en_col_load <= '0'; cs_en_wr_mem3 <= '0';
        when 96  => cs_en_wr_mem1 <= '1'; cs_datasel <= "01"; -- Start reading submemory 2. Writing only 16 pixels on submemory 1.
        when 97  => cs_en_wr_mem1 <= '0'; -- Start reading submemory 3. Writing only 16 pixels on submemory 2.
        when 112 => cs_en_wr_mem2 <= '1'; cs_datasel <= "10";
        when 113 => cs_en_wr_mem2 <= '0';
        when others => null;
    end case;
end process;
Kevin Jennings
 
Last edited:
There are a few methods that can be used.

1.) if-else, basically what you have done.
2.) case statement. Marginally less verbose.
3.) the above, but with the addition of procedures. Procedures are synthesizable if they describe synthesizable code. When you do similar operations on many cases there is an advantage to writing the concept once. (procedure is a VHDL construct similar to Verilog's "task")
4.) some form of CPU. In this case, the actions become the elements of the switch statement, and a small RAM is initialized with a program telling the proccessing unit when to perform them.

if-else is fine for a handful of cases, or when cases have complex logic. The case structure is good for small-ish designs with maybe a dozen cases. Procedures are useful here, but may lead to confusion as some developers incorrectly assume they are simulation only. Once you get above a few dozen cases, the CPU based approach starts to make sense -- the only question is how complex to make it. I'll make simple CPUs for operations taking a few hundred cycles for example, but the CPU might have only a few registers and only one conditional jump.
 
Not clear if the generated signals will be processed in sequential logic or send off chip. Decoding counter states into output signals with combinational logic is likely to create glitches. Placing the decoder in a clocked process would avoid it.
 
FvM said:
Not clear if the generated signals will be processed in sequential logic or send off chip. Decoding counter states into output signals with combinational logic is likely to create glitches. Placing the decoder in a clocked process would avoid it.
Click to expand...

The generated signals are not being sent off chip, but are used as signals to other components of the design. You're also right about glitches.

vGoodtimes, the design is relatively small and it will be used as a peripheral to an existing CPU. So designing another CPU will add extra complexity, even though it seems the proper solution for larger designs. Procedures or case statements seem the better solutions for my case.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top