Newbie vs VHDL: season 01 episode 01

[Altera_Forum]

Hi all 

 Since I am new to VHDL I have some questions (that probably you will find trivial):  1. Is good practice to define a behavioural architecture with one single process inside or it is better to have several process? (assumed that for different signals - if correlated - they have to stay in the same process)  2. If I have to implement a high order counter let's say a 24-bit counter it is better to have 2 12 bit counter or FPGAs can handle 24bit with the same effort of a 12 bit, for example:  -- 2 12 bit counter  BEGIN  IF rising_edge(clk_in) THEN -- clk_in is the clock signal input  count1 <= count1 + '1'; -- 12 bit counter    IF count1 = cnst THEN adder <= '1'; -- cnst = "111111111111"  ELSE adder <= '0';  END IF;  count2 <= count2 + adder; -- 12 bit counter    END IF;    END PROCESS;  -- 24 bit counter  BEGIN  IF rising_edge(clk_in) THEN  count1 <= count1 + '1'; -- 24 bit counter  END IF;    END PROCESS;   3. When defining entities and/or signals we have to iniatalize them, in which way is more efficient (if there are any differences):  SIGNAL count1 : STD_LOGIC_VECTOR (11 downto 0) := "000000000000"; SIGNAL count2 : STD_LOGIC_VECTOR (11 downto 0) := X"0000";   4. Is good practice to use as much as possible only STD_LOGIC types? Is this the best option for efficiency and speed?   Thank you all :)

[Altera_Forum]

1) If your design only requires a single process, then sure, but there's no reason not to have multiple processes. Different signals can be written to in different processes based on different circumstances, but you do have to watch out for multiple drivers on a signal. The Quartus compiler will flag any errors like this making it easy to fix them. 

 2) There's no reason I can think of to not just create the 24-bit counter. Is your concern functionality, timing, resources..?  3) No difference though you only need x"000" for the second one.  4) STD_LOGIC_1164 and NUMERIC_STD are the libraries you should be using for all designs and they make it much easier to design with.

[Altera_Forum]

1. Use whatever is most readable for someone who has never seen your code before. 

2. Id just go with the 24 bit counter. Quartus knows what you want and will be more readable for someone whos never read your code before after you've left the company. 3. They are both the same. Think about the poor intern who has to read your code when you're out sick. 4. Yes and no. Use appropriate types for the situation. Unsigned/signed for arithmetic. Integers if life is easier. Booleans sometimes for quick code:   signal something_happened : boolean; something_happened <= (ip = '1'); .... if something_happened then --react end if;   Think about your replacement when you've been promoted and you dont want your workers to laugh at your terrible code.

[Altera_Forum]

--- Quote Start ---  1) If your design only requires a single process, then sure, but there's no reason not to have multiple processes. Different signals can be written to in different processes based on different circumstances, but you do have to watch out for multiple drivers on a signal. The Quartus compiler will flag any errors like this making it easy to fix them.  2) There's no reason I can think of to not just create the 24-bit counter. Is your concern functionality, timing, resources..?  3) No difference though you only need x"000" for the second one.  4) STD_LOGIC_1164 and NUMERIC_STD are the libraries you should be using for all designs and they make it much easier to design with.  --- Quote End ---      --- Quote Start ---  1. Use whatever is most readable for someone who has never seen your code before. 2. Id just go with the 24 bit counter. Quartus knows what you want and will be more readable for someone whos never read your code before after you've left the company. 3. They are both the same. Think about the poor intern who has to read your code when you're out sick. 4. Yes and no. Use appropriate types for the situation. Unsigned/signed for arithmetic. Integers if life is easier. Booleans sometimes for quick code:   signal something_happened : boolean; something_happened <= (ip = '1'); .... if something_happened then --react end if;   Think about your replacement when you've been promoted and you dont want your workers to laugh at your terrible code.  --- Quote End ---    Ok thank you both now it's everything clear, I would go for the 24-bit, I was more familiar with this kind of split structure for previous designs I have studied/designed -- of course they were not on FPGAs  I should offer you a pint for the advices  Stay tuned for episode 2 :lol:

[Altera_Forum]

newbie vs vhdl: season 01 episode 02 

 Hi all  I have a few more question:  1. I read that it is good practice to avoid latches but I cannot understand why they are so bad, in particular I had designed a state machine for a counter: on state A it counts and update a signal, let's call this signal internal_counter, on state B it gives internal_counter as an input to the output value output_counter <= internal_counter. In this way I had latches for all the elements of the std_logic_vector called internal_counter but if I try to reset those value for instance wiriting  when stop => output_counter <= internal counter; internal_counter <= X"000"; next_state <= start;   this proves to be a concurrent statement and so the output is just zeros and so not working. I would like to avoid a third state as long as I do not want to miss any rising edge of the clock controlling the switching between states and I would like to output just a single value at the end of the counting operations. So a concurrent statement out of the process it is likely to avoid any kind of latches and reset issues but give several outputs, not just a single value.   when stop => internal_counter <= X"000"; next_state <= start; end process; output_counter <= internal_counter;   2. How do you implement sequential statements working on the same signal and does it make sense? It would mean using an FPGA like a microprocessor...

[Altera_Forum]

1. Latches are bad because they are basically asynchronous circuits and prone to glitches, timing is affected by process, voltage, temperature and you cannot analyse them in timing analysis. In an FPGA they have to be built from luts so you're not using the registers that are provided to provide clean timed designs. 

In your case - why not synchronise the whole lot to a system clock (not a logic generated clock) with clock enables if you need them.  2. It makes no sense. This is not software - circuits cannot have actions occur in some given order based on some language. For any output, there must be an input. Think about the circuit you are writing for - not the code you are writing. It is a hardware description language (not a programming language) afterall. If it makes more sense - an FPGA can be used to build a microprocessor - it is not a microprocessor iteself.

[Altera_Forum]

--- Quote Start ---  1. Latches are bad because they are basically asynchronous circuits and prone to glitches, timing is affected by process, voltage, temperature and you cannot analyse them in timing analysis. In an FPGA they have to be built from luts so you're not using the registers that are provided to provide clean timed designs. In your case - why not synchronise the whole lot to a system clock (not a logic generated clock) with clock enables if you need them.  2. It makes no sense. This is not software - circuits cannot have actions occur in some given order based on some language. For any output, there must be an input. Think about the circuit you are writing for - not the code you are writing. It is a hardware description language (not a programming language) afterall. If it makes more sense - an FPGA can be used to build a microprocessor - it is not a microprocessor iteself.  --- Quote End ---     Could you make me clear what you mean in "why not synchronise the whole lot to a system clock (not a logic generated clock) with clock enables if you need them."?  I am not getting it.

[Altera_Forum]

synchronisation means using a clock. The template is: 

  process(clk, reset) begin if reset = '1' then -- reset goes here elsif rising_edge(clk) then --synchronous stuff goes here - including state machines case state => when state1 => -- do something ....etc end case; end if; end process;   The good thing about doing a state machine this way is you only need a single process, and you will never get latches.