Some issues about functional simulation

I don't know, if you are talking about Quartus or ModelSim functional simulation? At least with ModelSim, uninitialized signals show a value of 'U'. That means, e.g. a frequency dividing counter can't work, unless you initialize it.

In VHDL, setting an initial value with the signal definition is the most simple method, e.g.

signal counter : unsigned := (others => '0');

Also an explicite reset initialization works of course.

further more,how to retain registers which is gone after compilation?

thanks.

It seems to me, the Quartus simulator considers the power on reset of FPGA registers and don't need an explicite initialization. It apparently reflects the real FPGA behaviour.

If some signals aren't reset to '0', they most likely aren't in the synthesized design. Quartus synthesis may have inverted some registers due to hardware constraints, but it will issue a warning in this case.

i still don't catch it.

it is a example of a polyphase filter.when i simulate using q ii,simply functional simulation,the signals are not reset to '0'.

PACKAGE n_bits_int IS

SUBTYPE BITS8 IS INTEGER RANGE -128 TO 127;

SUBTYPE BITS9 IS INTEGER RANGE -2**8 TO 2**8 - 1;

SUBTYPE BITS17 IS INTEGER RANGE -2**16 TO 2**16 - 1;

TYPE ARRAY_BITS17_4 IS ARRAY (0 TO 3) of BITS17;

END n_bits_int;

LIBRARY work;

USE work.n_bits_int.ALL;

LIBRARY ieee;

USE ieee.std_logic_1164.ALL;

USE ieee.std_logic_arith.ALL;

USE ieee.std_logic_signed.ALL;

ENTITY db4poly IS

PORT (clk : IN STD_LOGIC;

x_in : IN BITS8;

y_out : OUT BITS9);

END db4poly;

ARCHITECTURE flex OF db4poly IS

TYPE STATE_TYPE IS(even,odd);

SIGNAL state : STATE_TYPE;

SIGNAL x_odd,x_even,x_wait : BITS8;

SIGNAL clk_div2 : STD_LOGIC;

SIGNAL r : ARRAY_BITS17_4; --Arrays for multiplier and trap;

SIGNAL x33,x99,x107,y : BITS17;

BEGIN

Mutiplex:PROCESS --->Split into even and odd

BEGIN --samples at clk rate

WAIT UNTIL clk ='1';

CASE state IS

WHEN even =>

x_even <= x_in;

x_odd <= x_wait;

clk_div2 <= '1';

state <= odd;

WHEN odd =>

x_wait <= x_in;

clk_div2 <= '0';

state <= even;

END CASE;

END PROCESS Mutiplex;

AddPolyphase:PROCESS(clk_div2,x_odd,x_even,x33,x99,x107)

VARIABLE m : ARRAY_BITS17_4;

BEGIN

--compute auxiliary multiplication of the filter

x33 <= x_odd * 32 + x_odd;

x99 <= x33 *2 + x33;

x107 <= x99 + 8 * x_odd;

--compute all coefficients for the transposed filter

m(0) := 4 * 32 * x_even - x_even;

m(1) := 2 * x107;

m(2) := 8 * (8 * x_even - x_even) + x_even;

m(3) := x33;

----> compute the filters and infer registers

IF clk_div2'EVENT and (clk_div2 = '0') THEN

--compute filter G0

r(0) <= r(2) + m(0);

r(2) <= m(2);

--compute filter G1

r(1) <= -r(3) + m(1);

r(3) <= m(3);

--add the polyphase components

y <= r(0) + r(1);

END IF;

END PROCESS Addpolyphase;

y_out <= y / 256; --connect to output

END flex;

You will need to add some sort of reset to the 2nd process. In VHDL, unless specified otherwise, signals and variables default to the left most value. In the case of x_even, x_odd and x_wait, they will initialise to -128. Because 0 is in the middle of the range you will have to manually initialise them like this:

signal x_odd, x_even, x_wait : BITS8 := 0;

Next problem:

Not going to be an issue for simulation, but when you synthesize it you are going to cause timing problems. Do not generate clocks like you have with clk_div2. This is a logic clock and therefore you cannot gauarantee timings. Best to create a clock enable instead of a clock. Then you have the AddPolyphase process sensitive to the standard clk (I dont think you need any other signals in the 2nd process's sensitivity list other than clk).

So like this:

AddPolyphase : process(clk)
begin
     if rising_edge(clk) then
    if clk_div2 = '1' then
      --do variable assignments here, NOT outside the clock 
      --add together r and y values
    end if;
  end if;
end process;

--- Quote Start ---

What makes you think that the integer signals should be initialized to 0 without an explicite initialization? Actually Quartus initializes them apparently to their lower bound. As said, you can use an explicite initialization. I wasn't aware of this particular behaviour with integers that have a negative range, but I'm generally using explicite initialization whenever the initial state of a signal matters.

--- Quote End ---

Every signal/variable in VHDL initialises to left most unless otherwise told to. This is why std_logic starts off as 'U' as its the first listed in the type definition, integer inits to -2**31, naturals to 0 etc.

Thank you for reminding the general VHDL IEEE 1076 rule for default initial values

--- Quote Start ---

If an initial value expression appears in the declaration of a variable, then the initial value of the variable is determined by that expression each time the variable declaration is elaborated. In the absence of an initial value expression, a default initial value applies. The default initial value for a variable of a scalar subtype T is defined to be the value given by T'LEFT. The default initial value of a variable of a composite type is defined to be the aggregate of the default initial values of all of its scalar subelements, each of which is itself a variable of a scalar subtype.

--- Quote End ---

However, Quartus isn't following the rule, except for integer type. As a first point, Quartus doesn't use different synthesis for functional and gatelevel simulation. So it's clear, that STD_LOGIC, as well as all derived composited types (STD_LOGIC_VECTOR, SIGNED and UNSIGNED) can't take a value of 'U' respectively (others => 'U'). These types have '0' as default initial value, according to the default POR state of FPGA registers. Only INTEGER is initialized to 'LEFT, as required by the standard.