Single process style with Xilinx

Discussion in 'VHDL' started by adamk, Jan 18, 2010.

  1. adamk

    adamk Guest

    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
    adamk, Jan 18, 2010
    #1
    1. Advertising

  2. adamk wrote:

    > 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
    Mike Treseler, Jan 18, 2010
    #2
    1. Advertising

  3. adamk

    adamk Guest

    Thanks for the info.

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

    Cheers
    Adam
    adamk, Jan 18, 2010
    #3
  4. adamk wrote:
    > 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
    Mike Treseler, Jan 19, 2010
    #4
  5. adamk

    adamk Guest

    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
    adamk, Jan 20, 2010
    #5
  6. adamk wrote:

    > 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
    Mike Treseler, Jan 20, 2010
    #6
  7. adamk

    adamk Guest

    > 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
    adamk, Jan 20, 2010
    #7
  8. adamk wrote:

    > 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
    Mike Treseler, Jan 21, 2010
    #8
  9. adamk

    adamk Guest

    > 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
    adamk, Jan 21, 2010
    #9
  10. adamk wrote:

    > 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
    Mike Treseler, Jan 21, 2010
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Randall Parker
    Replies:
    1
    Views:
    588
    S. Justin Gengo
    Dec 12, 2005
  2. fpgaengineer
    Replies:
    7
    Views:
    3,698
    Mike Treseler
    Mar 12, 2007
  3. jasonL
    Replies:
    1
    Views:
    1,196
    jasonL
    Jun 3, 2007
  4. Mike Treseler
    Replies:
    24
    Views:
    1,571
    Mike Treseler
    Jun 22, 2007
  5. Ken Varn
    Replies:
    0
    Views:
    428
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page