Single process style with Xilinx

[adamk]

After reading lots of going points about Mike et al's single process
coding style i've decided to give it a try myself. When I synthesis a
basic example Xilinx's XST gives a warning that the variables decalred
in the process are modified in the procedure and will lead to a
simulation mismatch.

"WARNING:Xst:1960 Potential simulation mismatch, variable
<spi_clk_cntr> declared in block <main> is assigned in block
<init_regs>"

I've found the somewhat old AR #18452 which states that XST does not
produce a netlist that will agree with simulation.

I had a very simple example that produced these warnings but appeared
correct in behavioural and post-route simulation. On the other hand i
was reading a thread on this group between Mike and a few others from
a few years ago discussing the same warning where there was a
simulation mismatch.

Does anyone have any recent experience using XST with this coding
style? Should i just plough ahead and be on the look out for
simulation errors?

Cheers
Adam

 

[Mike Treseler]

I had a very simple example that produced these warnings but appeared
correct in behavioural and post-route simulation.

That has been my experience as well.
XST netlists sim the same as the source code
if you stick to my template.

On the other hand i
was reading a thread on this group between Mike and a few others from
a few years ago discussing the same warning where there was a
simulation mismatch.

Yes, there was an odd case submitted that failed
using a different style. Even this case worked
fine on Quartus.

Does anyone have any recent experience using XST with this coding
style? Should i just plough ahead and be on the look out for
simulation errors?

My reference design did a good gate sim in ISE last I tried.
It is always a good idea to do a gate sim
before releasing a design in any case.
I mostly use Quartus and have never had a synthesis problem.

-- Mike Treseler

 

[adamk]

Thanks for the info.

Forgive my ignorance but is a gate sim the same as post-route sim.

Cheers
Adam

 

[Mike Treseler]

Thanks for the info.

You are welcome.
Good luck.

is a gate sim the same as post-route sim.

That's what I had in mind.
Good luck.

-- Mike Treseler

 

[adamk]

So it all went rather well except for a minor hiccup. I'm using a
synchronous reset and following that template from the uart example i
ended up synthesising an extra register on one of my outputs.

Changing this:

if rising_edge(clk) then
if rst = '1' then
init_regs;
update_ports;
else
update_regs;
update_ports;
end if;
end if;

to this (like in the default template):

if rising_edge(clk) then
if rst = '1' then
init_regs;
else
update_regs;
end if;
end if;
update_ports;

ended up synthesising how i intended the description.

I'm sure i've likely messed up the description but i thought that the
two templates above should be equivalent and infer wires from the
register (variable) to the output port.

Cheers
Adam

 

[Mike Treseler]

So it all went rather well except for a minor hiccup. I'm using a
synchronous reset and following that template from the uart example i
ended up synthesising an extra register on one of my outputs.

With template_s_rst, you may see duplicate
registers in the RTL viewer.
These will be removed during a full synthesis.
Check the utilization.

Since I have to synch the reset pulse in any case,
I use template_v_rst to get the clean schematics.

Changing this:

if rising_edge(clk) then
if rst = '1' then
init_regs;
update_ports;
else
update_regs;
update_ports;
end if;
end if;

to this (like in the default template):

if rising_edge(clk) then
if rst = '1' then
init_regs;
else
update_regs;
end if;
end if;
update_ports;

ended up synthesising how i intended the description.

Your reset logic updates on the falling clock edge.
You get messy gating on the reset lines this way.

-- Mike Treseler

_________________________
procedure template_v_rst is
begin
if reset = '1' then
init_regs;
elsif rising_edge(clock) then
update_regs;
end if;
update_ports;
end procedure template_v_rst

 

[adamk]

With template_s_rst, you may see duplicate

registers in the RTL viewer.
These will be removed during a full synthesis.
Check the utilization.

I saw the duplicate registers in the RTL viewer but it doesn't look
like they are removed during synthesis. Comparing the utilization
from the v_rst and s_rst templates i see that the s_rst template has
exactly the extra number of flops that are duplicated on the outputs.
I checked on your uart example and found the same thing.

Your reset logic updates on the falling clock edge.
You get messy gating on the reset lines this way.

Sorry, but i don't understand how the reset logic updates on the
falling edge. Shouldn't the registers only be reset on a rising clock
when reset is asserted (init_regs) and the output of those registers
be wired to the output pins (update_ports)? Unless i have this wrong
i thought that it shouldn't matter where the update_ports went as long
as it was after the where all the registers were updated because it is
just inferring wires.

Interestingly (strangely) if you pull the code out of the procedures
and paste it into the main process XST synthesises it differently. I
didn't think there was any difference between having the code in the
process or a procedure called in a process other than for clarity.

Cheers
Adam

 

[Mike Treseler]

I checked on your uart example and found the same thing.

I get 52 FF and 96 LUTs.
What did you get?

Sorry, but i don't understand how the reset logic updates on the
falling edge.

I think you are right if you change
process(reset, clock) to
process(clock)


-- Mike Treseler

 

[adamk]

I get 52 FF and 96 LUTs.

What did you get?

template_v_rst: 46 FF 97 LUT
template_s_rst: 54 FF 100 LUT
my changed template: 45 FF 100 LUT

They all pass the sim.

As far as i can tell the extra registers on the outputs don't get
removed in template_s_rst.

What's baffling me is that for my design tempate_s_rst and my modified
one both behaviourly sim the same but for a gate sim template_s_rst is
different and fails while the modified one passes and looks the same
as the behioural sim.

Cheers
Adam

 

[Mike Treseler]

template_v_rst: 46 FF 97 LUT
template_s_rst: 54 FF 100 LUT
my changed template: 45 FF 100 LUT

They all pass the sim.
As far as i can tell the extra registers on the outputs don't get
removed in template_s_rst.

Since it passes sim, I assume you mean duplicates like this:

A--[dq]--B_v---[dq]--B---[..feedback.]
\----[dq]------------------------> B_q [port]

What's baffling me is that for my design tempate_s_rst and my modified
one both behaviourly sim the same but for a gate sim template_s_rst is
different and fails while the modified one passes and looks the same
as the behioural sim.

Maybe yours it better.

For the synchronous reset case, you might want
to wrap the design with input and output flops
to make valid comparisons.

-- Mike T