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
    with
    - 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)
    is
    begin
    if counter = dt then
    state <= next_state;
    counter <= 0;
    end if;
    end advance_state;

    and here a snippet of the state machine code:

    process(clock)
    begin
    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?

    Thanks,
    Thomas
    Thomas Heller, Dec 11, 2012
    #1
    1. Advertising

  2. Thomas Heller

    Pontus Guest

    I noticed that

    signal counter : inout integer range 0 to 1000;

    and

    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
    #2
    1. Advertising

  3. Am 11.12.2012 16:33, schrieb Pontus:
    > I noticed that
    >
    > signal counter : inout integer range 0 to 1000;
    >
    > and
    >
    > advance_state(state, START_B, counter, 2000);
    >
    > 2000 is not in range 0 to 1000, does this compile?


    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.

    > Where do you increment the counter?


    The counter in incremented on every rising_edge(clock)
    elsewhere in the process.

    Thomas
    Thomas Heller, Dec 11, 2012
    #3
  4. On 12/11/2012 10:22 AM, Thomas Heller wrote:
    > Am 11.12.2012 16:33, schrieb Pontus:
    >> I noticed that
    >>
    >> signal counter : inout integer range 0 to 1000;
    >>
    >> and
    >>
    >> advance_state(state, START_B, counter, 2000);
    >>
    >> 2000 is not in range 0 to 1000, does this compile?

    >
    > 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.
    >
    >> Where do you increment the counter?

    >
    > The counter in incremented on every rising_edge(clock)
    > elsewhere in the process.
    >
    > Thomas
    >


    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.

    Chris
    Christopher Felton, Dec 11, 2012
    #4
  5. Am 11.12.2012 17:53, schrieb Christopher Felton:
    > On 12/11/2012 10:22 AM, Thomas Heller wrote:
    >> Am 11.12.2012 16:33, schrieb Pontus:
    >>> I noticed that
    >>>
    >>> signal counter : inout integer range 0 to 1000;
    >>>
    >>> and
    >>>
    >>> advance_state(state, START_B, counter, 2000);
    >>>
    >>> 2000 is not in range 0 to 1000, does this compile?

    >>
    >> 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.
    >>
    >>> Where do you increment the counter?

    >>
    >> The counter in incremented on every rising_edge(clock)
    >> elsewhere in the process.
    >>
    >> Thomas
    >>

    >
    > 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.


    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
    Thomas Heller, Dec 11, 2012
    #5
  6. On 12/11/2012 11:52 AM, Thomas Heller wrote:
    > Am 11.12.2012 17:53, schrieb Christopher Felton:
    >> On 12/11/2012 10:22 AM, Thomas Heller wrote:
    >>> Am 11.12.2012 16:33, schrieb Pontus:
    >>>> I noticed that
    >>>>
    >>>> signal counter : inout integer range 0 to 1000;
    >>>>
    >>>> and
    >>>>
    >>>> advance_state(state, START_B, counter, 2000);
    >>>>
    >>>> 2000 is not in range 0 to 1000, does this compile?
    >>>
    >>> 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.
    >>>
    >>>> Where do you increment the counter?
    >>>
    >>> The counter in incremented on every rising_edge(clock)
    >>> elsewhere in the process.
    >>>
    >>> Thomas
    >>>

    >>
    >> 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.

    >
    > Yes, no errors, and it fits timing.
    > I assume they use different parsers/map/par for s3 and s6.
    > Maybe that explains the issue.


    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.

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


    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,
    delay_end.


    Regards,
    Chris

    Regards,
    Chris
    Christopher Felton, Dec 11, 2012
    #6
  7. Thomas Heller

    Gabor Guest

    Christopher Felton wrote:
    > On 12/11/2012 11:52 AM, Thomas Heller wrote:
    >> Am 11.12.2012 17:53, schrieb Christopher Felton:
    >>> On 12/11/2012 10:22 AM, Thomas Heller wrote:
    >>>> Am 11.12.2012 16:33, schrieb Pontus:
    >>>>> I noticed that
    >>>>>
    >>>>> signal counter : inout integer range 0 to 1000;
    >>>>>
    >>>>> and
    >>>>>
    >>>>> advance_state(state, START_B, counter, 2000);
    >>>>>
    >>>>> 2000 is not in range 0 to 1000, does this compile?
    >>>>
    >>>> 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.
    >>>>
    >>>>> Where do you increment the counter?
    >>>>
    >>>> The counter in incremented on every rising_edge(clock)
    >>>> elsewhere in the process.
    >>>>
    >>>> Thomas
    >>>>
    >>>
    >>> 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.

    >>
    >> Yes, no errors, and it fits timing.
    >> I assume they use different parsers/map/par for s3 and s6.
    >> Maybe that explains the issue.

    >
    > 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.
    >
    >>
    >> How do others write statemachines with certain durations for the states?

    >
    > 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,
    > delay_end.
    >
    >
    > Regards,
    > Chris
    >
    > Regards,
    > Chris

    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
    #7
  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 problem...you 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;
    else
    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
    #8
  9. On 12/11/2012 3:37 PM, Gabor wrote:
    > Christopher Felton wrote:
    >> On 12/11/2012 11:52 AM, Thomas Heller wrote:
    >>> Am 11.12.2012 17:53, schrieb Christopher Felton:
    >>>> On 12/11/2012 10:22 AM, Thomas Heller wrote:
    >>>>> Am 11.12.2012 16:33, schrieb Pontus:
    >>>>>> I noticed that
    >>>>>>
    >>>>>> signal counter : inout integer range 0 to 1000;
    >>>>>>
    >>>>>> and
    >>>>>>
    >>>>>> advance_state(state, START_B, counter, 2000);
    >>>>>>
    >>>>>> 2000 is not in range 0 to 1000, does this compile?
    >>>>>
    >>>>> 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.
    >>>>>
    >>>>>> Where do you increment the counter?
    >>>>>
    >>>>> The counter in incremented on every rising_edge(clock)
    >>>>> elsewhere in the process.
    >>>>>
    >>>>> Thomas
    >>>>>
    >>>>
    >>>> 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.
    >>>
    >>> Yes, no errors, and it fits timing.
    >>> I assume they use different parsers/map/par for s3 and s6.
    >>> Maybe that explains the issue.

    >>
    >> 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.
    >>
    >>>
    >>> How do others write statemachines with certain durations for the states?

    >>
    >> 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, delay_end.
    >>
    >>
    >> Regards,
    >> Chris
    >>
    >> Regards,
    >> Chris

    > 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


    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.

    Regards,
    Chris
    Christopher Felton, Dec 12, 2012
    #9
  10. Thomas Heller

    Gabor Guest

    Christopher Felton wrote:
    > On 12/11/2012 3:37 PM, Gabor wrote:
    >> Christopher Felton wrote:
    >>> On 12/11/2012 11:52 AM, Thomas Heller wrote:
    >>>> Am 11.12.2012 17:53, schrieb Christopher Felton:
    >>>>> On 12/11/2012 10:22 AM, Thomas Heller wrote:
    >>>>>> Am 11.12.2012 16:33, schrieb Pontus:
    >>>>>>> I noticed that
    >>>>>>>
    >>>>>>> signal counter : inout integer range 0 to 1000;
    >>>>>>>
    >>>>>>> and
    >>>>>>>
    >>>>>>> advance_state(state, START_B, counter, 2000);
    >>>>>>>
    >>>>>>> 2000 is not in range 0 to 1000, does this compile?
    >>>>>>
    >>>>>> 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.
    >>>>>>
    >>>>>>> Where do you increment the counter?
    >>>>>>
    >>>>>> The counter in incremented on every rising_edge(clock)
    >>>>>> elsewhere in the process.
    >>>>>>
    >>>>>> Thomas
    >>>>>>
    >>>>>
    >>>>> 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.
    >>>>
    >>>> Yes, no errors, and it fits timing.
    >>>> I assume they use different parsers/map/par for s3 and s6.
    >>>> Maybe that explains the issue.
    >>>
    >>> 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.
    >>>
    >>>>
    >>>> How do others write statemachines with certain durations for the
    >>>> states?
    >>>
    >>> 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, delay_end.
    >>>
    >>>
    >>> Regards,
    >>> Chris
    >>>
    >>> Regards,
    >>> Chris

    >> 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

    >
    > 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.
    >
    > Regards,
    > Chris


    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
    #10
  11. On 12/12/2012 10:13 AM, Gabor wrote:
    > Christopher Felton wrote:
    >> On 12/11/2012 3:37 PM, Gabor wrote:
    >>> Christopher Felton wrote:
    >>>> On 12/11/2012 11:52 AM, Thomas Heller wrote:
    >>>>> Am 11.12.2012 17:53, schrieb Christopher Felton:
    >>>>>> On 12/11/2012 10:22 AM, Thomas Heller wrote:
    >>>>>>> Am 11.12.2012 16:33, schrieb Pontus:
    >>>>>>>> I noticed that
    >>>>>>>>
    >>>>>>>> signal counter : inout integer range 0 to 1000;
    >>>>>>>>
    >>>>>>>> and
    >>>>>>>>
    >>>>>>>> advance_state(state, START_B, counter, 2000);
    >>>>>>>>
    >>>>>>>> 2000 is not in range 0 to 1000, does this compile?
    >>>>>>>
    >>>>>>> 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.
    >>>>>>>
    >>>>>>>> Where do you increment the counter?
    >>>>>>>
    >>>>>>> The counter in incremented on every rising_edge(clock)
    >>>>>>> elsewhere in the process.
    >>>>>>>
    >>>>>>> Thomas
    >>>>>>>
    >>>>>>
    >>>>>> 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.
    >>>>>
    >>>>> Yes, no errors, and it fits timing.
    >>>>> I assume they use different parsers/map/par for s3 and s6.
    >>>>> Maybe that explains the issue.
    >>>>
    >>>> 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.
    >>>>
    >>>>>
    >>>>> How do others write statemachines with certain durations for the
    >>>>> states?
    >>>>
    >>>> 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, delay_end.
    >>>>
    >>>>
    >>>> Regards,
    >>>> Chris
    >>>>
    >>>> Regards,
    >>>> Chris
    >>> 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

    >>
    >> 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.
    >>
    >> Regards,
    >> Chris

    >
    > 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


    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)
    |
    *Synthesis
    |
    output technology agnostic
    structural circuit
    |
    *Mapper
    |
    output technology specific
    structural circuit
    |
    *PaR
    |
    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.

    Regards,
    Chris
    Christopher Felton, Dec 12, 2012
    #11
  12. Thomas Heller

    Gabor Guest

    Christopher Felton wrote:
    > On 12/12/2012 10:13 AM, Gabor wrote:
    >> Christopher Felton wrote:
    >>> On 12/11/2012 3:37 PM, Gabor wrote:
    >>>> Christopher Felton wrote:
    >>>>> On 12/11/2012 11:52 AM, Thomas Heller wrote:
    >>>>>> Am 11.12.2012 17:53, schrieb Christopher Felton:
    >>>>>>> On 12/11/2012 10:22 AM, Thomas Heller wrote:
    >>>>>>>> Am 11.12.2012 16:33, schrieb Pontus:
    >>>>>>>>> I noticed that
    >>>>>>>>>
    >>>>>>>>> signal counter : inout integer range 0 to 1000;
    >>>>>>>>>
    >>>>>>>>> and
    >>>>>>>>>
    >>>>>>>>> advance_state(state, START_B, counter, 2000);
    >>>>>>>>>
    >>>>>>>>> 2000 is not in range 0 to 1000, does this compile?
    >>>>>>>>
    >>>>>>>> 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.
    >>>>>>>>
    >>>>>>>>> Where do you increment the counter?
    >>>>>>>>
    >>>>>>>> The counter in incremented on every rising_edge(clock)
    >>>>>>>> elsewhere in the process.
    >>>>>>>>
    >>>>>>>> Thomas
    >>>>>>>>
    >>>>>>>
    >>>>>>> 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.
    >>>>>>
    >>>>>> Yes, no errors, and it fits timing.
    >>>>>> I assume they use different parsers/map/par for s3 and s6.
    >>>>>> Maybe that explains the issue.
    >>>>>
    >>>>> 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.
    >>>>>
    >>>>>>
    >>>>>> How do others write statemachines with certain durations for the
    >>>>>> states?
    >>>>>
    >>>>> 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, delay_end.
    >>>>>
    >>>>>
    >>>>> Regards,
    >>>>> Chris
    >>>>>
    >>>>> Regards,
    >>>>> Chris
    >>>> 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
    >>>
    >>> 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.
    >>>
    >>> Regards,
    >>> Chris

    >>
    >> 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

    >
    > 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)
    > |
    > *Synthesis
    > |
    > output technology agnostic
    > structural circuit
    > |
    > *Mapper
    > |
    > output technology specific
    > structural circuit
    > |
    > *PaR
    > |
    > 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.
    >
    > Regards,
    > Chris
    >

    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
    #12
  13. Thomas Heller

    rickman Guest

    You guys need to learn to snip...

    On 12/12/2012 11:50 AM, Christopher Felton wrote:
    >
    > 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)
    > |

    *Synthesis front end
    > |
    > output technology agnostic
    > structural circuit

    |
    *Synthesis back end
    |
    output technology aware
    structural circuit
    |
    > *Mapper
    > |

    output technology specific
    structural circuit with specific
    mapping to functional units
    > |
    > *PaR
    > |
    > 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.
    >
    > Regards,
    > Chris


    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.

    Rick
    rickman, Dec 13, 2012
    #13
  14. On 12/13/12 12:32 PM, rickman wrote:
    > You guys need to learn to snip...
    >
    > On 12/12/2012 11:50 AM, Christopher Felton wrote:
    >>
    >> 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)
    >> |

    > *Synthesis front end
    >> |
    >> output technology agnostic
    >> structural circuit

    > |
    > *Synthesis back end
    > |
    > output technology aware
    > structural circuit
    > |
    >> *Mapper
    >> |

    > output technology specific
    > structural circuit with specific
    > mapping to functional units
    >> |
    >> *PaR
    >> |
    >> 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.
    >>
    >> Regards,
    >> Chris

    >
    > The Mapper is not part of the synthesis tool. It is a bit like a linker
    > in a programming language for an MCU.


    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.

    > The synthesis engine has a front
    > end that is technology independent,


    It was stated that the Xilinx parser (frontend) is *not* 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 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.

    >
    > 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.


    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
    resources).

    Regards,
    Chris
    Christopher Felton, Dec 14, 2012
    #14
  15. Thomas Heller

    rickman Guest

    On 12/14/2012 11:16 AM, Christopher Felton wrote:
    > On 12/13/12 12:32 PM, rickman wrote:
    >> The synthesis engine has a front
    >> end that is technology independent,

    >
    > It was stated that the Xilinx parser (frontend) is *not* technology
    > independent!


    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.


    >> 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 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.


    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?


    >> 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.

    >
    > 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 resources).


    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".

    Rick
    rickman, Dec 14, 2012
    #15
  16. Thomas Heller

    rickman Guest

    On 12/15/2012 4:50 AM, Brian Drummond wrote:
    > On Fri, 14 Dec 2012 13:10:35 -0500, rickman wrote:
    >
    >> 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.

    >
    > Technology dependent /= technology aware...
    >
    > The Xilinx parser is technology dependent - not because it is technology
    > aware, but because XST choose a new parser - yes, the bit that translates
    > and arranges tokens - if a new device is the target, and an old one if an
    > older device is the target.


    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
    tool?

    Rick
    rickman, Dec 16, 2012
    #16
  17. Am 15.12.2012 11:20, schrieb Brian Drummond:
    > On Tue, 11 Dec 2012 15:52:41 +0100, Thomas Heller wrote:
    >> 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)
    >> is begin
    >> if counter = dt then
    >> state <= next_state;
    >> counter <= 0;
    >> end if;
    >> end advance_state;
    >>

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

    >
    > There was a catastrophic known bug in ISE7,9,10,11,12 whereby signals
    > passed as OUT parameters to a procedure (probably INOUT too) were
    > incorrectly updated; XST used variable assignment semantics (immediate
    > assignment) instead of signal assignment (postpone assignment).
    >

    [...]
    > When I checked ISE13 I found the bug had gone; however I did not look
    > carefully enough, I only tested with Spartan-6.
    >
    > I have just re-tested with ISE14.3.
    > This bug is still there targeting Spartan-3 but goes away targeting S6.
    >
    > I believe this may be the bug you are seeing...


    Yes it seems this is the bug. Thanks for the confirmation!

    Thomas
    Thomas Heller, Dec 17, 2012
    #17
  18. rickman <> writes:

    > On 12/15/2012 4:50 AM, Brian Drummond wrote:
    >> On Fri, 14 Dec 2012 13:10:35 -0500, rickman wrote:
    >>
    >>> 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.

    >>
    >> Technology dependent /= technology aware...
    >>
    >> The Xilinx parser is technology dependent - not because it is technology
    >> aware, but because XST choose a new parser - yes, the bit that translates
    >> and arranges tokens - if a new device is the target, and an old one if an
    >> older device is the target.

    >
    > Ok, this is what I mean. You are saying "parser", but you mean the synthesis
    > component, not really the parser.


    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.

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.co.uk/capabilities/39-electronic-hardware
    Martin Thompson, Dec 18, 2012
    #18
  19. Thomas Heller

    rickman Guest

    On 12/17/2012 8:57 AM, Brian Drummond wrote:
    > On Sun, 16 Dec 2012 10:22:01 -0500, rickman wrote:
    >
    >> On 12/15/2012 4:50 AM, Brian Drummond wrote:
    >>> On Fri, 14 Dec 2012 13:10:35 -0500, rickman wrote:
    >>>
    >>>> 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.
    >>>
    >>> Technology dependent /= technology aware...
    >>>
    >>> The Xilinx parser is technology dependent - not because it is
    >>> technology aware, but because XST choose a new parser - yes, the bit
    >>> that translates and arranges tokens - if a new device is the target,
    >>> and an old one if an older device is the target.

    >>
    >> Ok, this is what I mean. You are saying "parser", but you mean the
    >> synthesis component, not really the parser.

    >
    > Xilinx really DO change the parser - the nominally tech INdependent bit -
    > selecting between two of them - according to device family.
    >
    > You can use either new or old *parser* for the older devices - in either
    > case, the same tech-dependent back end is employed.


    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.


    >> 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
    >> tool?

    >
    > Because it isn't the synthesis tool. It is only the source analyzer.
    > The second link below suggests they bought it from Verific. It does seem
    > to avoid some of the old bugs, but apparently has a few of its own.
    >
    > The rest of the synth tool is the same for a specific device, whichever
    > of the front ends (parsers) you choose.
    >
    > http://forums.xilinx.com/t5/Synthesis/How-to-enable-the-new-parser-for-
    > XST-in-ISE-12-1/td-p/133272
    >
    > http://www.xilinx.com/support/answers/45245.htm
    >
    > - Brian


    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.

    Rick
    rickman, Dec 18, 2012
    #19
    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. Leon Shaw

    Stored Procedure Problem

    Leon Shaw, Jul 28, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    369
    Jurjen de Groot
    Jul 29, 2003
  2. ElmoWatson

    Stored Procedure/Parameter problem

    ElmoWatson, Aug 4, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    488
    Jerry
    Aug 6, 2003
  3. Bilbo
    Replies:
    3
    Views:
    419
    Bilbo
    Nov 20, 2003
  4. Mike P
    Replies:
    0
    Views:
    3,294
    Mike P
    Jun 19, 2006
  5. AlexWare
    Replies:
    2
    Views:
    752
    Paul Uiterlinden
    Oct 23, 2009
Loading...

Share This Page