procedure problem

Discussion in 'VHDL' started by Thomas Heller, Dec 11, 2012.

  1. I have a statemachine that needs to maintain each current state for a
    certain time, then switch to another state.
    To save tedious typing, I wrote a helper procedure that I call
    - the state signal instance,
    - the next state value,
    - the counter signal instance which is used to count the remaining
    clock cycles,
    - and the number of clock cycles to wait.

    Here is the procedure:

    procedure advance_state (
    signal state : inout state_type;
    constant next_state : in state_type;
    signal counter : inout integer range 0 to 1000;
    constant dt : in integer)
    if counter = dt then
    state <= next_state;
    counter <= 0;
    end if;
    end advance_state;

    and here a snippet of the state machine code:

    if rising_edge(clock) then
    case state is
    when IDLE =>
    if we = '1' then
    state <= START_A;
    counter <= 0;
    end if;

    when START_A => advance_state(state, START_B, counter, 2000);
    when START_B => advance_state(state, START_C, counter, 2000);
    when START_C => advance_state(state, WRITE_A, counter, 2000);

    Code like this works fine when synthesized in ISE14.1 for a Spartan6
    device, but it does not work for Spartan3.

    Does anyone see a problem with the above?
    Are there better ways to implement a state machine with state-duration?

    Thomas Heller, Dec 11, 2012
    1. Advertisements

  2. Thomas Heller

    Pontus Guest

    I noticed that

    signal counter : inout integer range 0 to 1000;


    advance_state(state, START_B, counter, 2000);

    2000 is not in range 0 to 1000, does this compile?

    Where do you increment the counter?

    -- Pontus
    Pontus, Dec 11, 2012
    1. Advertisements

  3. Am 11.12.2012 16:33, schrieb Pontus:
    This is an error that I made when copying the code into
    the message. I tried to simplify it a bit.
    Yes, it does compile, and, as I said, it does even work
    for Spartan 6.
    The counter in incremented on every rising_edge(clock)
    elsewhere in the process.

    Thomas Heller, Dec 11, 2012
  4. When you say compile, it synthesizes without errors and passes PaR with
    no timing errors (timing errors don't error out the software). Unless
    it is a resource issue, I can't see why a S3 vs. S6 would make a difference.

    Christopher Felton, Dec 11, 2012
  5. Am 11.12.2012 17:53, schrieb Christopher Felton:
    Yes, no errors, and it fits timing.
    I assume they use different parsers/map/par for s3 and s6.
    Maybe that explains the issue.

    How do others write statemachines with certain durations for the states?

    Thomas Heller, Dec 11, 2012
  6. It shouldn't have a different parser, I believe the Xilinx synthesis is
    device aware but typically synthesis will synthesize to generic
    primitives (gates) and then the mapper will translate to device
    specific. I would expect only the mapper to be significantly different.
    But there should be some kind of warning or error that there are not
    enough resources etc., hmmmm.
    If you mean simple time delays, I usually have a local counter,
    something like your example.. Other times I will make a generic state
    delay, where the return state (next state out of the delay state) is a
    register and the delay is a register. Then it is like calling a
    function in CPU programming, you have to program the delay and return
    state before transitioning to the delay state. It is a reusable delay
    with the extra overhead of the programmable delay (expiration) and
    return state. And normally it is three states, delay_start, delay_wait,


    Christopher Felton, Dec 11, 2012
  7. Thomas Heller

    Gabor Guest

    S6 and newer devices use the "new parser" for XST. Older devices
    do not, unless you add "-use_new_parser yes" to the command line
    options for XST. This could very well explain the difference in
    behavior between the two. You need ISE 12 or newer to use the
    new parser.

    -- Gabor
    Gabor, Dec 11, 2012
  8. Thomas Heller

    KJ Guest

    On Tuesday, December 11, 2012 9:52:41 AM UTC-5, Thomas Heller wrote:

    - The state machine has no reset. There is nothing to get it into a valid state which then can be stepped through once reset completes. That alone would cause it to work in simulation but not always work in actual hardware.

    - Signal state is an output only of the procedure. That shouldn't matter for the problem you're seeing (which is not clear what exactly is the didn't say).

    - Since you asked, I would've written it like this...

    if rising_edge(clock) then
    if (reset = '1') then
    state <= idle; -- I presume
    counter = 0;
    elsif (counter = dt) then
    counter = 0;
    case state is
    when START_A => state <= START_B;
    end case;
    counter <= counter + 1;
    end if;
    end if;

    Not that what you have is wrong, but you asked how others would write it that are 'better'. Whether you think yours is better or not is up to you based on your own criteria.

    Kevin Jennings
    KJ, Dec 12, 2012
  9. Seems odd to me, wonder what the rational was. That is, a new release
    of software to use a different parser (frontend of synthesis) for
    different devices.

    Christopher Felton, Dec 12, 2012
  10. Thomas Heller

    Gabor Guest

    The rationale is very simple actually. They didn't want to run
    regression testing on all of the older device families. They
    give you a switch to turn on (or off) the new parser regardless of
    the FPGA family, but if you decide to use the new parser on an
    older device you should not expect support.

    -- Gabor
    Gabor, Dec 12, 2012
  11. I must be missing something here, when you say parser I assume the
    frontend of the synthesis engine? I am having a hard time seeing the
    direct connection between the "parser" and a device. I guess if you
    wanted to be super paranoid you could regression test against the device
    but it seems pointless?

    The tools flow:

    input VHDL (hardware description)
    output technology agnostic
    structural circuit
    output technology specific
    structural circuit
    output technology and physical
    details (FPGA case config stream)

    *indicates the FPGA eda software.

    If a 3rd party synthesis vendor changed their "parser" would they test
    against all possible target devices or would they simply test enough
    VHDL input test cases?

    I guess the Xilinx synthesis tool must incorporate device specific
    technology early on? Seems dangerous to me.

    Christopher Felton, Dec 12, 2012
  12. Thomas Heller

    Gabor Guest

    By "parser," Xilinx means their synthesis front-end. And yes, it
    does have some technology-awareness. This makes sense when you
    realize that they only target their own devices, and that the
    third-party synthesis engines have a longstanding advantage at
    doing synthesis well in the traditional way. For newer versions
    of XST, "synthesis" also includes the first stage of mapping, including
    packing logic elements into slices. So there is not such a clear
    line in terms of where the "parser" ends and the "physical synthesis"
    begins. Thus, you would presume that a large amount of testing
    would be needed to fully support the older devices, even when only
    the "parser" changes.

    -- Gabor
    Gabor, Dec 12, 2012
  13. Thomas Heller

    rickman Guest

    You guys need to learn to snip...

    *Synthesis back end
    output technology aware
    structural circuit
    output technology specific
    structural circuit with specific
    mapping to functional units
    The Mapper is not part of the synthesis tool. It is a bit like a linker
    in a programming language for an MCU. The synthesis engine has a front
    end that is technology independent, but also a technology aware back end
    that knows the device it is compiling for because it does need to know
    what functional blocks it will be mapped to.

    I think some things have already been decided before it reached the
    mapper. For example, whether FFs will be used for a shift register or
    the SRL in a Xilinx part.

    rickman, Dec 13, 2012
  14. Not sure where the confusion was but I explicitly listed synthesis, map,
    P&R as separate tools. The discussion was around my surprise and
    learning that the Xilinx tools are device specific from the very
    beginning of their tool flow, in this case the parser. Thanks for
    reiterating the point.
    It was stated that the Xilinx parser (frontend) is *not* technology
    I agree, generally this is true but it doesn't have to be. It just
    means the *mapper* has to do more work. As your description indicates,
    the syn will map and then the mapper (fitter) will map also.
    Agree, but it probably depends on the flexibility and descriptability
    (new word) of the intermediate format. I can't think of a reason why
    the mapper couldn't perform the mapping you described (e.g. identifying
    a bunch of FF as a shift-register and use the technology specific

    Christopher Felton, Dec 14, 2012
  15. Thomas Heller

    rickman Guest

    We seem to be pretty much on the same page. I think the only issue is
    what people mean when they say the "parser". I assume this is being
    used loosely as synthesis. If someone is really saying the "parser",
    that is the part that just looks at the code and turns it into internal
    tokens, is technology aware, I am sure they are wrong. This makes no
    sense at all.

    Perhaps in theory you are right, but I think they use some info in the
    source to key them into intentions of the coder. This info might be
    lost once the design is optimized in the synthesis back end. But I'm
    not a tool writer, so I don't really know. I expect you can easily look
    at a netlist and figure out some optimizations just as a C compiler can
    do optimizations on the assembly language.

    I do know that way back when I started using VHDL the (really crappy)
    Orcad VHDL tool would barf on very small deviations from the ideal
    source. But they they got out of the compiler writing business for a
    reason, didn't they?

    Yes, I agree. The only thing required to recognize the optimization for
    an SRL would be that the FFs meet the limitations of the SRL. But what
    about other, more complex features like multipliers? Wouldn't it be a
    lot easier to let the synthesis tool recognize that a multiply operation
    could be implemented as a primitive in the target device rather than
    have the mapper recognize a multiplier implemented in LUT fabric and
    swap it out? If the mapper is given a generic multiply function and
    told to "figure it out", isn't that pushing synthesis into the mapping
    operation? Mapping is supposed to be a limited precursor to placement
    that just figures out how to map logic to the hardware such as "this LUT
    can co-exist with this FF in the same CLB".

    rickman, Dec 14, 2012
  16. Thomas Heller

    rickman Guest

    Ok, this is what I mean. You are saying "parser", but you mean the
    synthesis component, not really the parser. No one is saying the
    synthesis tool is not technology dependent, are they?

    The parser just analyses the source and turns it into internal tokens
    that are just machine understandable representations of the language.
    This is only a small part of the synthesis process and should not be
    used as the name for the entire process. Why not call it the synthesis

    rickman, Dec 16, 2012
  17. Am 15.12.2012 11:20, schrieb Brian Drummond:
    Yes it seems this is the bug. Thanks for the confirmation!

    Thomas Heller, Dec 17, 2012
  18. No, he really means the parser. That "tiny bit" of the process *did*
    change between 2&3-devices and 6-devices, and you have to jump through
    hoops (well, give a switch and give up on support) to use it on the
    older devices.

    *As well* as that there are the technology specific synthesis parts - but
    that's (as you say) expected to the tech dependent.

    Martin Thompson, Dec 18, 2012
  19. Thomas Heller

    rickman Guest

    That doesn't make much sense to me. There is no reason to make the
    actual parser any different because the parser only translates the ASCII
    text into internal machine representations. I would expect nothing
    specific to any technology other than the language being used.

    I read the references you give below. I'm still not clear that you can
    say the parser is technology dependent. These reports are about
    properties that are outside of the language.

    'The 13.3 XST Verific Parser still prevents SRL inference even if the
    Save net attribute is set to "false".'

    The problem is that the parser has a bug regarding some flag that
    affects one device set and not others. I'm not sure this is the same
    thing as saying the parser is technology dependent.

    Thanks for the links. This makes it all clear. The fact that they
    allow you to choose different parsers doesn't make them technology
    specific. I think I disagree with the terminology of saying the parser
    is technology specific because it has bugs in property assignments that
    affect one line of parts and not another, but whatever, it's not a big
    deal. I think I understand what you are saying now, so thanks.

    rickman, Dec 18, 2012
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.