Author Topic: VHDL CODE QUESTION  (Read 13489 times)

0 Members and 1 Guest are viewing this topic.

Offline AustinTopic starter

  • Newbie
  • Posts: 4
  • Country: jp
VHDL CODE QUESTION
« on: April 03, 2024, 02:27:10 am »
I'm trying to make a pulse width counter with 32bit counter on FPGA.
I haven't tried it on the actual board yet.(I don't have the board around me right now)
The question I came up with is this.
When the rst is1,TMP<=cnt; and cnt <=X"00000000"; will be executed simultaneously.
At least that's what I thought ...
Will this code run stably and reliably?





library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity Top is
    Port ( clk : in STD_LOGIC;
           rst : in STD_LOGIC;
           count : out STD_LOGIC_VECTOR(31 downto 0);
           hold : out STD_LOGIC_VECTOR(31 downto 0)
           );
end Top;

architecture Behavioral of Top is
    signal cnt : STD_LOGIC_VECTOR(31 downto 0) := (others => '0');
   signal  TMP : STD_LOGIC_VECTOR(31 downto 0) := (others => '0');
begin
    process(clk, rst)
    begin
        if rst = '1' then
        TMP<=cnt;
        cnt <=X"00000000";
        elsif rising_edge(clk) then
            cnt <= cnt + 1;
        end if;
    end process;

    count <= cnt;
    hold <= TMP;
end Behavioral;
« Last Edit: April 03, 2024, 02:29:21 am by Austin »
 

Offline pgo

  • Regular Contributor
  • *
  • Posts: 69
  • Country: au
Re: VHDL CODE QUESTION
« Reply #1 on: April 03, 2024, 07:10:53 am »
Hi,
You are using an asynchronous  signal rst.
When active the value in X'00.." will flow to CNT and also will flow to TMP  after propagation delays.

I suspect you want something like:

Quote
library ieee;
use ieee.std_logic_1164.ALL;
use ieee.numeric_std.all;

entity Top is
   port (
      clk : in std_logic;
      reset : in std_logic;
      capture : in std_logic;
      count : out std_logic_vector(31 downto 0);
      hold : out std_logic_vector(31 downto 0)
   );
end Top;

architecture Behavioral of Top is
   signal cnt : unsigned(31 downto 0);
 
begin
   process (reset, clk)
   begin
      if (reset = '1') then
         cnt  <= (others => '0');
         hold <= (others => '0');
      elsif rising_edge(clk) then
         if (capture = '1') then
            hold <= std_logic_vector(cnt);
            cnt <= (others => '0');
         else
            cnt <= cnt + 1;
         end if;
      end if;
   end process;

   count <= std_logic_vector(cnt);
 
end Behavioral;

PS. I should probably be using unsigned for the counter and add conversions as needed.
PPS. Please don't double-post.
« Last Edit: April 03, 2024, 07:26:49 am by pgo »
 
The following users thanked this post: Austin

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27420
  • Country: nl
    • NCT Developments
Re: VHDL CODE QUESTION
« Reply #2 on: April 03, 2024, 08:47:44 pm »
As a general rule: when writing VHDL, use a numeric type (in most cases unsigned) instead of std_logic_vector for everything which is a number or an index. Yes, an address is an index as well. This way you can index arrays with less code by casting the unsigned type to an integer AND numeric types can be used in 'math' expressions directly.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Austin

Offline jahonen

  • Super Contributor
  • ***
  • Posts: 1054
  • Country: fi
Re: VHDL CODE QUESTION
« Reply #3 on: April 04, 2024, 06:40:19 am »
Generally in a VHDL process, all updates to signals happen only when process ends. So you can "change your mind" several times in a process and the last decision will remain effective. This also means that you always see the value of the signal which it had before the process started, even after you changed it (on the same execution).

That means that your TMP signal will contain the value of cnt just before reset. Then cnt will be reset. This also means that cnt signal is an inferred latch, which is generally a bad idea on a FPGA. You should try to implement this synchronously, like suggested.

Also note that reset signal will usually need to obey some timing constraints (recovery/removal) for the implementation to work reliably. So even if reset is "asynchronous", it still usually needs to be synchronized with the clock.

Regards,
Janne
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf