Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Output pins are stuck...

Hello,

I am a new user of Quartus II and I am using it to help me learn VHDL. I have written a function to multiply two std_logic_vectors and return the same type. The function adjusts to the size of the incoming operands so the returned product vector length is the sum of the input vector lengths. Everything works fine until the product width exceeds the input vector width (with both the same) by 2. The algorithm essentially constructs a matrix of three-input half-adders propagating any carry bits one position at each level of the matrix. After all multiplier bits have been accounted for, the matrix is extended with layers of two-input half-adders to complete carry propagation. It appears that Quartus II quits generating matrix layers after generating a number of layers equal to the input vector length plus two. I get the same result with any equal input vector lengths greater than four.

During compilation, I get the following warning messages (with 5-bit input operands):

"Warning: Output pins are stuck at VCC or GND

Warning (13410): Pin "p[7]" is stuck at GND

Warning (13410): Pin "p[8]" is stuck at GND

Warning (13410): Pin "p[9]" is stuck at GND

I am using the web version of Quartus 9.1 with Service Pack 2 installed.

I have attached a copy of my function code. Any suggestions will be greatly appreciated.

Thanks in advance.

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    i suspect a problem with your multiplier code, can you add the package here?

    have you run a simulation?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hello pancake,

    Thanks for the quick response. Yes, I have simulated quite a bit with varing combinations of operands and operand sizes. The results are pretty consistant. I also used the RTL Viewer to verify that Quartus II quit synthesizing after two layers past the operand size.

    I wouldn't be surprised if there were bugs in my code but I just haven't been able to find them. I have a fair amount of experience programming in C/C++ and Java but this is my first exposure to an HDL and it has taken some getting used to. I did attach the package code to the original posting but here it is again:

    --------------------------------------------

    library ieee;

    use ieee.std_logic_1164.all;

    --use ieee.std_logic_signed.all;

    --------------------------------------------

    package mult_package is

    -- constant n: integer := 7;

    function "*"(signal multer, multand: std_logic_vector)

    return std_logic_vector;

    end package mult_package;

    --------------------------------------------

    package body mult_package is

    function "*"(

    signal multer, multand: std_logic_vector)

    return std_logic_vector is

    type mult_matrix is array (0 to multer'length + multand'length-1)

    of std_logic_vector(multer'length + multand'length-1 downto 0);

    variable a, b, c: mult_matrix;

    variable prod: std_logic_vector(multer'length + multand'length-1 downto 0);

    begin

    -------- initialize first row in multiplication matrix --------------

    if ((multer(0) xor multer(multer'left)) = '1') then

    b(0)(b(0)'left downto multand'length) := (others => multand(multand'left));

    b(0)(multand'left downto 0) := multand;

    else

    b(0) := (others => '0');

    end if;

    a(0) := (others => '0');

    c(0) := (others => '0');

    prod(0) := b(0)(0);

    -------- load multiplicand matrix and generate products -------------

    for j in 1 to multer'left loop

    if((multer(j) xor multer(multer'left)) = '1') then

    a(j)(a(j)'left downto multand'length) := (others => multand(multand'left));

    a(j)(multand'left+j downto j) := multand;

    else

    a(j) := (others => '0');

    end if;

    for i in j to multand'length+j loop

    b(j)(i) := a(j )(i) xor b(j-1)(i) xor c(j-1)(i-1);

    c(j)(i) := (a(j )(i) and b(j-1)(i))

    or (a(j )(i) and c(j-1)(i-1))

    or (b(j-1)(i) and c(j-1)(i-1));

    end loop;

    prod(j) := b(j)(j);

    end loop;

    --------------------- final carry propagation -----------------------

    for j in multer'length to b'high loop

    b(j)(b(j)'high downto j) := b(j-1)(b(j-1)'high downto j) xor c(j-1)(c(j-1)'high-1 downto j-1);

    c(j)(c(j)'high downto j) := b(j-1)(b(j-1)'high downto j) and c(j-1)(c(j-1)'high-1 downto j-1);

    prod(j) := b(j)(j);

    end loop;

    --return "00" & prod & "00" & a(n) & "00" & c(n-1) & "00" & b(n) & "00" & c(n);

    return prod;

    end function "*";

    end package body mult_package;

    --------------------------------------------

    There are a couple lines of debug code included and commented out.

    The sythesizer seems to quit after two iterations of the second loop.

    Thanks again for your reply and your interst.

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    can I ask why you're writing your own * function, when they are already defined in standardised packages? with the standard versions, quartus can place either dedicated hardware or optimised versions. This is not guaranteed when you write your own * function.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Tricky,

    It's just a learning exercise. I'm new to FPGAs and just learning VHDL so when this function didn't appear to properly synthesize I wanted to find out what I am doing wrong. In the real world, I would definitly let Quartus pick the best way to implement the function for the particular device I am working with.

    Thanks for your interest, please let me know if you see the source of my problem.

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The problem is because you have a complicated function, its difficult to follow. The error you get can also be caused by the inputs having bits stuck at ground. Are you aware designs should be clocked? I would have thought a better learning exercise would be to pipeline your design.