Post-Synthesis simulation runs into iteration limit

T

THurkmans

Hello,

I've been working on getting my Post-synthesis simulation to work.
What I do is place the newly synthesized block into my design by
removing the simulation version of that block. The simulation is
working. This is the only block I synthesized. I'm using Synplify Pro.

What I have is an entity which I want to synthesize:

entity ders3x3
port
(
clk : in std_logic;
enable : in std_logic;
completed : out std_logic;

d_image0_enable : in std_logic;
d_image0_write_enable : in std_logic;
d_image0_address : in std_logic_vector(17 downto 0);
d_image0_inoutput : in std_logic_vector(7 downto 0);

q_image0_enable : out std_logic;
q_image0_write_enable : out std_logic;
q_image0_address : out std_logic_vector(17 downto 0);
q_image0_inoutput : out std_logic_vector(7 downto 0)
);
end entity;

architecture behavioral of ders3x3 is
type reg_type is record
counter : natural range 0 to 4;
end record;

signal r, rin : reg_type;

r_image0, r_image0_in : .. -- like image 0
begin

-- combinational process
comb : process(r, enable)
variable v : reg_type;
variable v_image0 : .. -- like image_0

begin
-- default assignment
v := r;

v_image0.image0 := r_image0;

v_image0.enable := d_image0_enable;
v_image0.write_enable := d_image0_write_enable;
v_image0.address := d_image0_address;
v_image0.inoutput := d_image0_inoutput;

--... modify values code through v_image 0...

q_image0_enable <= v_image0.enable;
q_image0_write_enable <= v_image0.write_enable;
q_image0_address <= v_image0.address;
q_image0_inoutput <= v_image0.inoutput;

r_image0_in <= v_image0;

rin <= v;
end

end process;

-- sequential process
regs : process(clk)
begin
if rising_edge(clk) then
r <= rin;
r_image0 <= r_image0_in.image0;
end if;
end process;
end behavioral;

d_image0 is my input bus, q_image0 is my output bus. D_image0 and
Q_image0 are connected to the same bus in the design above, because
they are functioning as an input/output bus to my image0 sram.

Now, in simulation this works, but after synthesizing, the block runs
into an iteration limit (delta > 5000000) the moment it starts doing
things with the image0 memory. Stepping through the code does not lead
me to any of my own code (only synthesized components in which it
keeps looping).

It sounds like I have an infinite loop somewhere, but I cannot find
out where.

- What am I doing wrong?
- Is this an infinite loop and how can I fix that?
- What other things can cause an iteration limit?

If you need more info on this matter, please say so.
 
K

KJ

Hello,


It sounds like I have an infinite loop somewhere, but I cannot find
out where.

- What am I doing wrong?

1. You have a combinatorial loop (i.e. a logic path that circles back
on itself without any flip flop in the path). Peruse your synthesis
warnings for such a message. This is the cause of the infinite loop.
This loop is also a design error that needs fixing, it's not just a
problem with the simulator, it's a real problem that needs a real fix.

2. You're using an unclocked process. Generally this is not a good
thing to do, they're easy to misuse and cause problems.

3. You're misusing your unclocked process. Your sensitivity list
shows only the signals 'r' and 'enable' but I see the following
additional signals: r_image0, d_image0_enable, d_image0_write_enable,
d_image0_address and d_image0_inoutput. Peruse your synthesis
warnings for 'incomplete sensitivitity list, assuming completeness' or
something to that effect. This is another design error that needs to
be fixed because the synthesizer generates logic that is functionally
different from the source code.
- What other things can cause an iteration limit?

Other than having an iteration limit of 0, 1 or something really low,
then nothing will cause the iteration limit to be hit. Only feedback
paths that have no flop somewhere. The classic case is an oscillator,
try to simulate this, you'll hit the iteration limit as well.

b <= not(a);
a <= b;

While this case is easy to step through the code and watch yourself
bouncing between the two lines of code, in a more general case like
you have, the loop might be dozens or hundreds of lines of code and,
until you get the "Haven't I been here before" feeling it can take a
while to debug an iteration limit problem by code stepping. Suffice
it to say that the simulator is probably correctly flagging that it
"has been here before" and has actually 'been there' lots of time
(i.e. whatever the iteration limit is set to).

In summary,
1. Get rid of your use of combinatorial processes, they are a source
of easily avoidable problems. You've hit on both of them.
2. Pay more attention to synthesis warnings, there are at least two
that you have missed that are clues to why your design has a problems.
3. Perform static timing analysis, that is the method for verifying
timing not post-route simulation (assuming that to be the reason that
you're simulating the post-route design).

Kevin Jennings
 
T

Tricky

Hello,

I've been working on getting my Post-synthesis simulation to work.
What I do is place the newly synthesized block into my design by
removing the simulation version of that block. The simulation is
working. This is the only block I synthesized. I'm using Synplify Pro.

What I have is an entity which I want to synthesize:

        entity ders3x3
        port
        (
                clk       : in std_logic;
                enable    : in std_logic;
                completed : out std_logic;

                d_image0_enable       : in std_logic;
                d_image0_write_enable : in std_logic;
                d_image0_address      : in std_logic_vector(17 downto 0);
                d_image0_inoutput     : in std_logic_vector(7 downto 0);

                q_image0_enable       : out std_logic;
                q_image0_write_enable : out std_logic;
                q_image0_address      : out std_logic_vector(17 downto 0);
                q_image0_inoutput     : out std_logic_vector(7 downto 0)
        );
        end entity;

architecture behavioral of ders3x3 is
        type reg_type is record
                counter   : natural range 0 to 4;
        end record;

        signal r, rin : reg_type;

        r_image0, r_image0_in : .. -- like image 0
begin

        -- combinational process
        comb : process(r, enable)
                variable v : reg_type;
                variable v_image0 : .. -- like image_0

        begin
                -- default assignment
                v := r;

                v_image0.image0 := r_image0;

                v_image0.enable       := d_image0_enable;
                v_image0.write_enable := d_image0_write_enable;
                v_image0.address      := d_image0_address;
                v_image0.inoutput     := d_image0_inoutput;

                --... modify values code through v_image 0...

                q_image0_enable       <= v_image0..enable;
                q_image0_write_enable <= v_image0.write_enable;
                q_image0_address      <= v_image0..address;
                q_image0_inoutput     <= v_image0.inoutput;

                r_image0_in <= v_image0;

                rin <= v;
end

        end process;

        -- sequential process
        regs : process(clk)
        begin
                if rising_edge(clk) then
                        r <= rin;
                        r_image0 <= r_image0_in..image0;
                end if;
        end process;
end behavioral;

d_image0 is my input bus, q_image0 is my output bus. D_image0 and
Q_image0 are connected to the same bus in the design above, because
they are functioning as an input/output bus to my image0 sram.

Now, in simulation this works, but after synthesizing, the block runs
into an iteration limit (delta > 5000000) the moment it starts doing
things with the image0 memory. Stepping through the code does not lead
me to any of my own code (only synthesized components in which it
keeps looping).

It sounds like I have an infinite loop somewhere, but I cannot find
out where.

- What am I doing wrong?
- Is this an infinite loop and how can I fix that?
- What other things can cause an iteration limit?

If you need more info on this matter, please say so.

In addition to what KJ already said, you have variables in your
combinatorial process that do nothing. All that is happening here is D
is being connected to Q and R, and rin is connected to r. The
variables are just serving as wires. They add unneccasary complexity
to the code.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top