[cross-post]path verification

Discussion in 'VHDL' started by alb, Mar 17, 2014.

  1. alb

    KJ Guest

    I have to find out how much time I need to wait before sampling the
    You're assuming (and you may be correct since you know the design better than I) that the logic path taken by the 'nop' operation is in fact segregated from that of the division operation. Certainly at the instruction opcodedecode level they're not separate...but maybe that occurs on a different clock cycle.
    And makes me think that things are not implemented in the logic in a segregated fashion which could mean that seemingly unrelated instructions like 'nop' might depend on logic used by division.
    That's correct. Post route sim really tells you nothing about timing. Theonly use I've found for that sim can be for finding that something wasn't implemented correctly which then resulted in finding a work around and submitting a service request to the software provider. That has only happened once (for me).
    Sims do not take into account any timing variation. You may be able to runthem with 'min', 'typical' or 'maximum' but not combinations. It is no substitute for static timing analysis (nor is it intended to be).
    My suggestions:
    1. Since this is purchased IP, go back to the supplier, pay them some moneyand tell them you need validated timing constraints for their design.
    2. If #1 is not feasible for whatever reason, then see about altering the IP to insert pipeline registers. This may be ugly and means you will have to reverse engineer the design but it is verifiable since you will be able to get through STA without having to wonder if your constraints are correct and you can run original and modified sims to verify function is unchanged.
    3. This might actually be the best option but I don't know how well it really works since I've never tried it. You can buy software that claims to verify that timing constraints are correct [1]

    Kevin Jennings

    [1] http://www.bluepearlsoftware.com/sdc/
    KJ, Apr 4, 2014
    1. Advertisements

  2. alb

    alb Guest

    Hi Kevin,

    there are a certain number of 'atomic' operations that are reused among
    several floating point ops, so there's no such a clear separation among
    them. The decode is performed on a different cycle, therefore is not of
    a concern.
    That is correct. And this is why the need of a set of /through/ clauses
    need to be in place. Imagine the following:

    opcode path multicycle constraint
    X a + b + c -through a -through b -through c
    Y a + d + e + f -through a -through d -through e -through f
    Z q + r + t + a + d ...

    The rest of the constraint definition is the /from/ and /to/ clause
    which are simpler since they are the input registers and the output one.

    Now, since 'atomic' operations are separated into different entities (as
    far as I can tell) I may take the input ports to identify a path through
    that entity and maybe survive net renaming and the like, but you can
    imagine how much fun it might be to trace all individual paths.

    Oh and I forgot! some of the operations (notably the division) they do
    need registers to hold temporary results, therefore they will have to be
    treated separately (so I cannot really false path the whole
    you mean it wasn't implemented correctly in the p&r tool?
    This is indeed what I also thought (I hate to be right!).
    out of question, the developer is a chinese who left to Brazil hoping to
    find his karma... (cannot truly blame him)
    This was my very first proposal. Rejected with a simple: 'no design
    changes'. I understant - partially - the philosophy to keep the IP as is
    (considering that has been functionally verified), but maybe here it
    would be simpler and _safer_ to add a pipeline.

    I thought about C-slowing and retiming, I can start with large logic
    depth (maximum is 113!) and maybe add registers at the input ports of
    the 'atomic' operations I mentioned earlier.
    I was wondering if they let us try their tool for a short period of time
    (maybe a couple of weeks), enough to get ourselves out of this painful
    situation and maybe convince the management is really a must have tool.
    any user here?
    alb, Apr 4, 2014
    1. Advertisements

  3. alb

    rickman Guest

    On 4/4/2014 11:27 AM, KJ wrote:
    money and tell them you need validated timing constraints for their design.
    the IP to insert pipeline registers. This may be ugly and means you
    will have to reverse engineer the design but it is verifiable since you
    will be able to get through STA without having to wonder if your
    constraints are correct and you can run original and modified sims to
    verify function is unchanged.
    it really works since I've never tried it. You can buy software that
    claims to verify that timing constraints are correct [1]
    I concur. Right now I don't see how the design can be analyzed for
    timing. If the OP wants to set different timing constraints for
    different paths through the combinatorial logic, there either has to be
    some clearly identifiable approach to isolating the paths for static
    timing analysis or the design has to change.

    I guess one question would be why use the IP from this particular vendor?

    Another would be if there are clearly different paths within the
    combinatorial logic, can these could be broken out in some way to allow
    timing constraints to be applied separately? It would not be
    unreasonable to duplicate the input registers so that each differently
    timed operation would not have the same starting point in the design
    allowing separate from/to timing constraints. If information on the
    operation is available at the time the input registers are loaded each
    one could have a separate enable so the tools would clearly know they
    are equivalent. Otherwise the tools might try to be too smart for their
    own good and you may need to use modifiers to keep the duplicate
    registers from being optimized away.
    rickman, Apr 5, 2014
  4. alb

    rickman Guest

    Ok, so where is the problem with specifying the through parameters if
    you know them?

    I have never done post-par sims because they are pointless for timing
    verification and the logic should be good by construction. In essence
    this is only verifying the synthesis tools, not the design.

    I think uncomfortable would be an understatement. There is no other way
    to properly and fully verify timing than STA. Either make it work or
    find a different way to implement your design is my advice.

    If the tool optimizes away some part of your design you have problems. I
    believe the renaming is done with synonyms so that a constraint should
    still apply. You might want to get in touch with support. Who's parts
    are you using? If a specified through target can be optimized out it
    isn't a very useful feature to have in the STA tool is it?

    I think of it like getting old. It is the worst thing in the world
    except for the alternative.
    rickman, Apr 5, 2014
  5. alb

    KJ Guest

    Unless you obtain a deep knowledge of the design, if you try to do what youdescribed above, you're likely screwed. There's always the chance that it's not quite as bad as it appears right now, but there is an equally good chance that it is actually worse...and you won't know it until it's too lateand you're shipping product and 'wierd' things are happening when the board warms up or cools down or whatever.
    That's correct. Actually, I had two instances. One was if you passed intoan entity a generic that happened to be a vector, it treated the elements of the vector as '1 to n', even though the entity definition specifically defined them as 'n downto 1'. The other case had to do with not initializing the contents of an inferred memory.

    Using the post-route sim model was conclusive evidence of an improper buildand the cool thing is that the sim really only had to run for a couple nanoseconds to prove the memory initialization problem; an assertion printing out the details of the vector comes out simply from starting the simulator.
    Seems like this would be your best option. Right now, you're caught in theproject management iron triangle: you don't have the right resource (off in Brazil), you don't have schedule time to modify the design and it soundslike management might not want to spend the $$ to get the design correct. The only end result that will have a functional design in this case is to punt on performance and accept whatever slow speed you can get out of the IP core by only specifying constraints that you know for absolute fact are correct and stop trying to figure out if this path through this hunk really can wait a clock or not.

    Even if you spend the money and the tool happens to guarantee that they will produce valid constraints, there is no guarantee that the end performancewill actually be any better...you will simply know that you've got it properly constrained. You might also want to do some more Google searching forsome other tools that perform this constraint validation. I don't think the link I gave you previously is the one I remember from a while back either in this forum or possibly comp.lang.vhdl so there might be at least one other company to look for to generate valid constraints.

    Kevin Jennings
    KJ, Apr 5, 2014
  6. alb

    KJ Guest

    Here is another company that seems to have a timing constraint verification product

    Kevin Jennings
    KJ, Apr 5, 2014
  7. alb

    HT-Lab Guest

    On 03/04/2014 23:21, rickman wrote:

    Hi Rick,
    Yes, let me try again.

    What I am saying is that you should not use an MCP for a path that is
    not controlled. What Al seems to be doing is to use P&R to extract a
    path delay, he then chops it up into a number of clock delays and use
    that to set an MCP constraint. This create a design which will be
    difficult to maintain. Changing speed grade/device type/synthesis
    tool/version/settings/P&R settings etc will all make this process pretty
    painful for the next user. I also believe Al is working on some mission
    critical design (satellite?) so his current method will definitely fail
    the CDR.

    As suggested by others his only option is to modify the design and add
    e.g. output control to his FP paths, then set an MCP constraint on it
    and add some assertions to verify it. This should pass the CDR.

    HT-Lab, Apr 7, 2014
  8. alb

    alb Guest

    Hi Rick,

    The main problem is that I do not know them all and is a PITA to trace
    I share your point, my manager doesn't! Ouch!

    Is not only a matter of optimization, which might happen since a
    resource might be shared and suddenly a gate does not have the same
    nets' names anymore. On top of that I'm not quite familiar with
    synthesis tools name mangling techniques, therefore I cannot be sure the
    name I use for my /through/ clause will remain constant throughout
    several synthesis runs.

    I guess there are other attributes I can set to maintain certain names
    as they are, but the exercise becomes more and more difficult to maintain.

    Someone said the same about democracy :)


    p.s.: FYI I guess your Thunderbird 24.4.0 has serious issues with
    quoting, I'm not use if it might be related to your Win8 or a
    combination of the two, but your quoting is all screwed up.
    alb, Apr 7, 2014
  9. alb

    alb Guest

    alb, Apr 7, 2014
  10. alb

    alb Guest

    Hi Kevin,

    I guess I have no choice but trace all the paths. Do port names get
    completely wiped out when the netlist is generated? I ask because I was
    thinking about using ports' names for /through/ clauses and I was
    wondering whether they are kept in some form on the output netlist (I'm
    using synplify_pro).

    Uhm, that would be a show stopper. The 'hunk' limits the speed to 1/5th
    of the target one and this will compromise system performances beyond an
    acceptable level. We must constraint the 'hunk' properly.
    A set of multicycle constraints should allow the tool to make the design
    meet the system clock frequency target and keep the 'hunk' running at a
    lower pace (through the output enable).

    alb, Apr 7, 2014
  11. alb

    alb Guest

    Hi Hans,

    Thanks for rephrasing it so clearly!
    I agree with you. This exercise will be needed every time we will change
    target, clock frequency, etc... We advocated for the design change path,
    but, as you may know, there might be other factors to consider in the
    equation for the best choice and only time will say if not changing the
    design would be the best one (even if rarely it is).
    How would the assertions help me in verifying it?
    alb, Apr 7, 2014
  12. alb

    HT-Lab Guest

    Hi Al,

    The assertion is on the control logic of the MCP path. Thus the
    assertion will fail if data can flow from your input to your output
    registers in less than the specified number of cycles (your MCP clock

    Look at the Fishtail link I send earlier, you might want to read up on
    the term sensitization before looking at the example.

    Good luck with your project,

    HT-Lab, Apr 7, 2014
    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.