Single process style with Xilinx

Mon Jan 18, 2010 11:41 pm   

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

Tue Jan 19, 2010 12:29 am   

adamk wrote:


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


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


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

Tue Jan 19, 2010 1:07 am   

adamk wrote:

You are welcome.
Good luck.



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

-- Mike Treseler

Tue Jan 19, 2010 1:45 am   

Thanks for the info.

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

Cheers
Adam

Tue Jan 19, 2010 7:55 pm   

On Mon, 18 Jan 2010 13:41:26 -0800 (PST), adamk
<adamk.exceltech_at_gmail.com> wrote:

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

This warning seems to be issued every time you declare a variable in
the process declaration section and then assign a value to it in a
procedure. It may not necessarily be specific to Mike's style of
coding. Why? Who knows? I am not so sure Xilinx even knows why. It
seems that XST balks when process variables are assigned within a
procedure. Being a hardware dude, I use the viewers extensively to see
what the software is generating, if happy then onto simualtion and all
that jazz. I find Mike's style easy in that all I have to do is write
procedures and functions. For my use as a hobbyist this makes things
easier.

james

Wed Jan 20, 2010 12:36 am   

On Tue, 19 Jan 2010 13:55:02 -0500, james <bubba_at_bud.u> wrote:


The strange thing about this warning is that XSTworks fine declaring variables
in a process and updating them in procedures (at least I have never caught it
out or heard of anyone catching it out)...

However passing SIGNALS as OUT or INOUT parameters, and updating them in
procedures, it generates faulty logic! Specifically, the update has immediate
(not postponed) effect, as if the signal was a variable.

At least for versions 7 to 10.1.
I haven't re-tested in 11.1 yet, but since the CR was filed against 10.1, I
don't expect a fix until ISE12 comes out.

Oddly, some of the discussion in the Webcase has been deleted (and it wasn't too
heated either!)

- Brian

Wed Jan 20, 2010 6:23 am   

On Tue, 19 Jan 2010 23:36:26 +0000, Brian Drummond
<brian_drummond_at_btconnect.com> wrote:

|On Tue, 19 Jan 2010 13:55:02 -0500, james <bubba_at_bud.u> wrote:
|
|>On Mon, 18 Jan 2010 13:41:26 -0800 (PST), adamk
|><adamk.exceltech_at_gmail.com> wrote:
|>
|>|"WARNING:Xst:1960 Potential simulation mismatch, variable
|>|<spi_clk_cntr> declared in block <main> is assigned in block
|>|<init_regs>"
|>|
|>|++++++++++++++++++++++++++++
|>
|>This warning seems to be issued every time you declare a variable in
|>the process declaration section and then assign a value to it in a
|>procedure. It may not necessarily be specific to Mike's style of
|>coding. Why? Who knows? I am not so sure Xilinx even knows why. It
|>seems that XST balks when process variables are assigned within a
|>procedure. Being a hardware dude, I use the viewers extensively to see
|>what the software is generating, if happy then onto simualtion and all
|>that jazz. I find Mike's style easy in that all I have to do is write
|>procedures and functions. For my use as a hobbyist this makes things
|>easier.
|
|The strange thing about this warning is that XSTworks fine declaring variables
|in a process and updating them in procedures (at least I have never caught it
|out or heard of anyone catching it out)...
|
|However passing SIGNALS as OUT or INOUT parameters, and updating them in
|procedures, it generates faulty logic! Specifically, the update has immediate
|(not postponed) effect, as if the signal was a variable.
|

Brian

I don't claim to be an expert in software, especially VHDL. I just
only report what I see from my end and what appears to be happening on
my end. Don't care to make waves, start flame wars or anything like
that. I have recently started using Mike's template and I too get the
XST:1960 warning. I am using WEBPACK 10.1.3. Most of what I am doing
is just for my own education and home projects. My background is
hardware with some software thrown in. Mostly assembly, Basic and
Fortran.

I went back and looked at someone else's code that was not in the form
of Mike's Single Process. The first thing that stood out that there
were variables declared in the process declaration section that was
not assigned. I tried to put an initial assignment and I still got the
warnings. I am not sure why but I offered a explanation based on what
I observed. If someone can better explain what is going on then I am
all for it. For my usage, I write the code, look at the RTL, and if it
appears what I want then I test my circuit in FPGA hardware. If that
works then I am happy. On to the next stage of the design.

Like I said I am no expert. Far from it. I just offered some input
from what I observed. I am willing to learn. That really is the fun of
things, learning.

james

Wed Jan 20, 2010 7:07 am   

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

Wed Jan 20, 2010 7:22 am   

adamk wrote:


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.


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

Wed Jan 20, 2010 2:49 pm   

On Wed, 20 Jan 2010 00:23:52 -0500, james <bubba_at_bud.u> wrote:


Sounds like you are doing just fine.


Of course, warnings do not necessarily indicate a problem. You have paid
attention to them and confirmed that XST appears to be doing the right thing;
henceforth you can normally ignore that warning (unless you see evidence of
incorrect results; then review the warnings)

My purpose in posting was to give you a heads up that - if you paid too much
attention to the warnings and tried using signals (passed to procedures) instead
of variables - you could write perfectly good VHDL, get no warnings, and have
XST 10.1 generate incorrect results! I will say it's rare in my experience to
catch XST out, but this is one place you can.

I like to write VHDL at the highest level of abstraction I can - and in many
many ways it's better for this than C. Case in point:
http://www.edadesignline.com/showArticle.jhtml?articleID=222300710
Using procedures to abstract out detail and clarify the main process, such as in
Mike's templates, is an excellent example (both of abstraction, and potentially
of C's failings...)

VHDL's problem is rarely the language itself; it's usually that the tools
(especially synthesis) only support low-level uses of it, but they are getting
better. And banging on the tools and asking vendors to remove these restrictions
can only help.

To digress, my hope for the whole "C to hardware" thing is that as fast as "C"
synthesis tools learn to understand higher levels of abstraction, VHDL tools
will keep up. It's certainly possible, if the tool vendors want to.


Then I would say it's very much worth learning how to write a simulation
testbench - Mike's examples are again a good starting point. You have a fairly
competent simulator right there in Webpack 10.1's ISIM (ISE Simulator) or, if
you are running Windows, you have the option of Modelsim Xilinx Edition (a free
version of the gold standard in VHDL simulators. It's limited, but it may be a
while before you hit those limits...)

You can test the behavioral model (the source you wrote), and also verify that
the translated (gate level) model does the same. The latter is usually not
necessary, but sometimes useful to get you out of a hole - e.g. to confirm or
eliminate a suspected tool bug.

- Brian

Wed Jan 20, 2010 3:13 pm   

On Wed, 20 Jan 2010 13:49:32 +0000, Brian Drummond
<brian_drummond_at_btconnect.com> wrote:

|Then I would say it's very much worth learning how to write a simulation
|testbench - Mike's examples are again a good starting point. You have a fairly
|competent simulator right there in Webpack 10.1's ISIM (ISE Simulator) or, if
|you are running Windows, you have the option of Modelsim Xilinx Edition (a free
|version of the gold standard in VHDL simulators. It's limited, but it may be a
|while before you hit those limits...)
|
|You can test the behavioral model (the source you wrote), and also verify that
|the translated (gate level) model does the same. The latter is usually not
|necessary, but sometimes useful to get you out of a hole - e.g. to confirm or
|eliminate a suspected tool bug.
|+++++++++++++++++

i do at times but sometimes I am to lazy. Being more a hobbiest, I can
be. Now if I were doing this for pay, that would be a very very
different story.

james

Wed Jan 20, 2010 6:28 pm   

On Tue, 19 Jan 2010 23:36:26 +0000, Brian Drummond
<brian_drummond_at_btconnect.com> wrote:

|The strange thing about this warning is that XSTworks fine declaring variables
|in a process and updating them in procedures (at least I have never caught it
|out or heard of anyone catching it out)...
|===========

Brian
You are right. Checking with the XST manual it clears what first I
thought. After further examing code from one of Mike's examples and
code that I obtained, I came across one thing that might explain what
is happening. Both examples use a variable as a register and then wire
the output to a output port. This may be what XST does not like? They
flag it as a warning as to not stop synthesis. I do remember that Mike
stated he has no issues with Quartus. So what ever it is, it appears
to be with XST only.

I like said, to me it is not a show stopper and I work on.

james

Thu Jan 21, 2010 1:37 am   

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.


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

Thu Jan 21, 2010 6:11 am   

adamk wrote:


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



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


-- Mike Treseler

Fri Jan 22, 2010 12:07 am   

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