+ Post New Thread
Results 1 to 7 of 7
  1. #1
    Newbie level 2
    Points: 21, Level: 1

    Join Date
    Nov 2013
    Posts
    2
    Helped
    0 / 0
    Points
    21
    Level
    1

    Signal Connected to Multiple Drivers Help?

    I am trying to make a sequential multiplier. The code is supposed to recieve a product and add each bit of the product at the rising edge of the clock while emitting the corresponding LED. What is the problem?

    •   AltAdvertisment

        
       

  2. #2
    Advanced Member level 5
    Points: 23,052, Level: 36
    barry's Avatar
    Join Date
    Mar 2005
    Location
    California, USA
    Posts
    4,406
    Helped
    978 / 978
    Points
    23,052
    Level
    36

    Re: Signal Connected to Multiple Drivers Help?

    I THINK (could be wrong again) that your chain of "IF" statements in PROC1 might be the problem; should be if-elsif. What signal does your error message identify as the culprit?



    •   AltAdvertisment

        
       

  3. #3
    Newbie level 2
    Points: 21, Level: 1

    Join Date
    Nov 2013
    Posts
    2
    Helped
    0 / 0
    Points
    21
    Level
    1

    Re: Signal Connected to Multiple Drivers Help?

    individual bits of s and t are the culprits



    •   AltAdvertisment

        
       

  4. #4
    Advanced Member level 5
    Points: 23,052, Level: 36
    barry's Avatar
    Join Date
    Mar 2005
    Location
    California, USA
    Posts
    4,406
    Helped
    978 / 978
    Points
    23,052
    Level
    36

    Re: Signal Connected to Multiple Drivers Help?

    Quote Originally Posted by tkim20 View Post
    individual bits of s and t are the culprits
    Like I said, use if/elsif, not individual if statements.



  5. #5
    Full Member level 4
    Points: 3,952, Level: 14

    Join Date
    Nov 2005
    Location
    Penang
    Posts
    216
    Helped
    49 / 49
    Points
    3,952
    Level
    14

    Re: Signal Connected to Multiple Drivers Help?

    The problem is with the following statements:

    DividerSegments <= s;
    DividerLEDS <= t;

    You are driving these two signals in proc0's if .. else statements and then trying to drive them outside the process again.

    proc0: process(DividerCLK, DividerRST)
    begin
    if (DividerRST = '1') then
    DividerLEDS <= "00000000";
    DividerSegments <= "00000000";
    cnt_dig <= "000";
    elsif (rising_edge(DividerCLK)) then
    cnt_dig <= cnt_dig + 1;
    end if;
    end process;

    This is multiple drivers for the two signals. Put the final assignment inside the if loop if you can restructure your code. This should solve the multiple drivers issue.



  6. #6
    Advanced Member level 5
    Points: 23,052, Level: 36
    barry's Avatar
    Join Date
    Mar 2005
    Location
    California, USA
    Posts
    4,406
    Helped
    978 / 978
    Points
    23,052
    Level
    36

    Re: Signal Connected to Multiple Drivers Help?

    vlsi-whiz is correct. I missed that.

    But those independent if statements may still cause you problems with inferred latches.



    •   AltAdvertisment

        
       

  7. #7
    Advanced Member level 3
    Points: 5,700, Level: 17

    Join Date
    Jul 2010
    Posts
    923
    Helped
    294 / 294
    Points
    5,700
    Level
    17

    Re: Signal Connected to Multiple Drivers Help?

    yes, for example, no bit of t is ever set to 0. You should add a t <= (others => '0') line (and same for s) at the top of that process. In VHDL and verilog, the nonblocking assignment effectively performs whatever the last assignment was. It is common to use this property to give defaults to the signals in a combinatorial process. This is easy to understand and prevents latches formed by forgetting to assign the signal in all code paths. It can also be used with some synthesis tools (XST/Vivado/Synplify, maybe more) to make mixed resets easier. Any other use is still valid, but can make it difficult to determine the complexity of the logic for any given signal, and can make it easy to misread code that now has a priority encoder spread throughout the process.

    Code:
    p_label : process ( clk ) is
    begin
      if rising_edge(clk) then
        -- defaults
        valid_out <= '0';
        data_out <= data_in;
        -- logic
        -- This logic sends a valid pulse for every other valid_in.
        -- The value of cnt will be retained (unless reset).
        -- The value of "valid_out" will transition back to 0 if these conditions aren't met (due to default)
        if valid_in = '1' then
          if cnt = 1 then
            valid_out <= '1';
          end if;
          cnt <= (cnt + 1) mod 2;
        end if;
        -- resets, sync
        -- this infers a reset on the register "valid_out" and "cnt"
        -- no register is applied to the registers "data_out".  
        -- This style of resets is common in FPGA designs, but not ASICs.
        if rst = '1' then
          cnt <= 0;
          valid_out <= '0';
        end if;
      end if;
    end process;
    This is a simple process, so the benefits are not that apparent vs:

    Code:
    p_label : process ( clk ) is
    begin
      if rising_edge(clk) then
        if rst = '1' then
          cnt <= 0;
          valid_out <= '0';
        elsif valid_in = '1' then
          if cnt = 1 then
            valid_out <= '1';
          end if;
          cnt <= (cnt + 1) mod 2;
        else
          valid_out <= '0';
        end if;
        data_out <= data_in;
      end if;
    end process;
    Though the benefits become clear when there is a large mixture of signals with/without resets and/or defaults.



--[[ ]]--