[cross-post]path verification

[alb]

Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]

1. multicycle constraints need not only a /from/ and /to/
parameter, they also
need a /through/ parameter. When you have a logic depth of 111 gates
you start to
understand why a multicycle constraint cannot be a sustainable solution.

I can't say I follow that. I have only ever specified a from and to
parameter for a timing constraint. I have never needed to indicate a
"through" parameter. If you have special sections of the logic that
need a shorter timing constraint than others, I would expect that to be
a subset of the from and to, not a special "though" path. Is there
something unique about your design that a simple from and to spec
doesn't capture the nuance?

Imagine your path between two registers (A and B) is set by another
register C. The resulting operation is to be stored in register D. If
you do not set a /through/ clause you will constraint each path with the
maximum delay, which is not desirable.

2. My experience in setting up multicycle constraints is nearly
zero and starting
off with such an approach on this type of project would be begging
for troubles.

How much experience do you have with any of the other approaches you are
trying? I mean, you are here asking for advice. So clearly there are
things about each of these approaches you are not familiar with.

I've often done post-par sims, but it was combined with an STA,
therefore I've always been sure the design was correct as long as STA
did not report anything fishy *and* post-par sim succeeded.

Recently I started to look at post-par sims as an additional step which
is not necessarily required for synchronous logic as long as your input
constraints are well defined.

In this case we cannot use STA to do time analysis and I'm
unconfortable.

a. is difficult to maintain them; if the logic path has been
optimized the
constraint does not work anymore

I don't follow that either. It is seldom that any from/to path would be
optimized away. If it is, it is likely due to an error in your code
which you will need to fix anyway.

I certainly was talking about the /through/ clause I mentioned earlier.
The synthesis tool might optimize away (or maybe rename) certain nets
and you're constraint will not be applicable anymore.

b. is difficult to verify them; if the path *is not* multicycle you
may wrongly
relax the timing too much and never realize until another
optimization takes place
and your circuit does not work any more.

ALL timing constraints are difficult to verify... no, make that
impossible. That has always been one of my complaints about static
timing analysis, there is no way to verify the constraints other than
the coverage number which is just a pass/fail sort of thing.

That is why you'd be better off if you didn't have them!

 

[KJ]

On Friday, April 4, 2014 5:53:20 PM UTC-4, alb wrote:

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

Unless you obtain a deep knowledge of the design, if you try to do what you described 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 late and you're shipping product and 'wierd' things are happening when the board warms up or cools down or whatever.

That's correct. Post route sim really tells you nothing about timing.
The only 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.

you mean it wasn't implemented correctly in the p&r tool?

That's correct. Actually, I had two instances. One was if you passed into an 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 build and 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.

My suggestions:

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

Seems like this would be your best option. Right now, you're caught in the project 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 sounds like 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 performance will 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 for some 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

 

[alb]

Hi Kevin,

KJ <kkjennings@sbcglobal.net> wrote:
[]

Imagine an fpu, with two input registers for the operands, one for the
operator and an output register for the result. The result register is
the one that will receive the output enable.

Depending on the operator I will have a different path. If I wildcard
the path sources than I'm overly constraining and a 'nop' operation will
take as much as a division operation, which is not what we want.


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 opcode decode level they're not separate...but maybe that
occurs on a different clock cycle.

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.

Since most of the combinatorial functions are reused several times in
each operation, the datapath starts to be painfully complicated. That is
the main reason why I discarded the option to setup multicycle
constraints.


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 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
block...jeez).

The alternative, though, is not very palatable either. We decided to set
false paths between the above mentioned registers and let post-par sim
figure out whether we are in or out with our output enable. The problem
is that post-par simulation may not cover the whole set of timing
scerarios the logic will encounter.


That's correct. Post route sim really tells you nothing about timing.
The only 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.

you mean it wasn't implemented correctly in the p&r tool?

For instance I do not know if a backannotated simulation includes clock
skew, while AFAIK it shoudl be taken into account in STA.

Sims do not take into account any timing variation. You may be able
to run them with 'min', 'typical' or 'maximum' but not combinations.
It is no substitute for static timing analysis (nor is it intended to
be).

This is indeed what I also thought (I hate to be right!).

My suggestions:

1. Since this is purchased IP, go back to the supplier, pay them some
money and tell them you need validated timing constraints for their
design.

out of question, the developer is a chinese who left to Brazil hoping to
find his karma... (cannot truly blame him)

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.

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.

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]

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.

> [1] http://www.bluepearlsoftware.com/sdc/

any user here?

 

[KJ]

On Friday, April 4, 2014 9:44:55 PM UTC-4, KJ wrote:

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 performance
will 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
for some 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.

Here is another company that seems to have a timing constraint verification product
http://www.averant.com/products-solidtc.html

Kevin Jennings

 

[rickman]

On 4/4/2014 11:27 AM, KJ wrote:
....snip...

The described
approach tries to verify timing, but I'm not sure this is really going
to be risk free.

Certainly I can add some jitter to my clock within the simulation itself
to make it more /realistic/ , but I will certainly not cover all the
cases.

Considering the target FPGA is an RTAX2000 (~20'000$), we are kind of
unconfortable to proceed without a fully consistent picture.

My suggestions:
1. Since this is purchased IP, go back to the supplier, pay them some
money and 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

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.

--

Rick

 

[rickman]

On 4/4/2014 10:09 AM, alb wrote:

Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]
1. multicycle constraints need not only a /from/ and /to/
parameter, they also
need a /through/ parameter. When you have a logic depth of 111 gates
you start to
understand why a multicycle constraint cannot be a sustainable
solution.

I can't say I follow that. I have only ever specified a from and to
parameter for a timing constraint. I have never needed to indicate a
"through" parameter. If you have special sections of the logic that
need a shorter timing constraint than others, I would expect that to be
a subset of the from and to, not a special "though" path. Is there
something unique about your design that a simple from and to spec
doesn't capture the nuance?

Imagine your path between two registers (A and B) is set by another
register C. The resulting operation is to be stored in register D. If
you do not set a /through/ clause you will constraint each path with the
maximum delay, which is not desirable.

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

2. My experience in setting up multicycle constraints is nearly
zero and starting
off with such an approach on this type of project would be begging
for troubles.

How much experience do you have with any of the other approaches you are
trying? I mean, you are here asking for advice. So clearly there are
things about each of these approaches you are not familiar with.

I've often done post-par sims, but it was combined with an STA,
therefore I've always been sure the design was correct as long as STA
did not report anything fishy *and* post-par sim succeeded.

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.

Recently I started to look at post-par sims as an additional step which
is not necessarily required for synchronous logic as long as your input
constraints are well defined.

In this case we cannot use STA to do time analysis and I'm
unconfortable.

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.

a. is difficult to maintain them; if the logic path has been
optimized the
constraint does not work anymore

I don't follow that either. It is seldom that any from/to path would be
optimized away. If it is, it is likely due to an error in your code
which you will need to fix anyway.

I certainly was talking about the /through/ clause I mentioned earlier.
The synthesis tool might optimize away (or maybe rename) certain nets
and you're constraint will not be applicable anymore.

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?

b. is difficult to verify them; if the path *is not* multicycle you
may wrongly
relax the timing too much and never realize until another
optimization takes place
and your circuit does not work any more.

ALL timing constraints are difficult to verify... no, make that
impossible. That has always been one of my complaints about static
timing analysis, there is no way to verify the constraints other than
the coverage number which is just a pass/fail sort of thing.

That is why you'd be better off if you didn't have them!

I think of it like getting old. It is the worst thing in the world
except for the alternative.

--

Rick

 

[HT-Lab]

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

Hi Rick,

On 4/3/2014 10:22 AM, HT-Lab wrote:> On 03/04/2014 14:30, KJ wrote:
On Thursday, April 3, 2014 8:33:39 AM UTC-4, HT-Lab wrote:
IMHO a multicycle path delay is a propagation delay specified as
relative to the clock period. Hence it *does* depend on the clock
frequency, while the propagation through your gates does not (it
depends
on the technology).

You still have your terminology wrong, here is a SDC example of an
typical MCP constraint:

set_multicycle_path 2 -from reg_alu* -to reg_mult*

Notice there is no time, just a natural number of clock cycles.

The value of '2' though is computed based on the clock period. Alb
already pointed that out earlier in the thread "If your path takes
12.3 ns you would have to set a multicycle constraint of 2 with a
100MHz clock, but 3 with a 200MHz one."


We are taking about different issues here. My argument is that you
should not exchange a clock constraint for an MCP one,

I think you are misreading what is intended. It is assumed there is
already a clock timing constraint of 100 MHz. That is for the general
logic in this clock domain. But for a certain section of logic the
output of the logic is not used for some number of clock cycles that
will be determined by the delay through the logic which is expected to
be longer than one clock cycle.

The OP wants to set this number of clock cycles in the timing
constraints of that special path to verify that the P&R output will work
with the timing he has picked. If the timing fails he has the options
of working to improve the timing in the P&R or changing the logic of the
register enable to allow more clock cycles for this path.

In no case would he want to change the timing constraint on the clock
since that constraint is set by other aspects of his design goals.

Do I misunderstand what you are trying to say?

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.

Regards,
Hans.
www.ht-lab.com

 

[alb]

Hi Rick,

rickman <gnuarm@gmail.com> wrote:
[]

Imagine your path between two registers (A and B) is set by another
register C. The resulting operation is to be stored in register D. If
you do not set a /through/ clause you will constraint each path with the
maximum delay, which is not desirable.

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

The main problem is that I do not know them all and is a PITA to trace
them.

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.

I share your point, my manager doesn't! Ouch!

[]

The synthesis tool might optimize away (or maybe rename) certain nets
and you're constraint will not be applicable anymore.

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?

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.

[]

That is why you'd be better off if you didn't have them [timing
constraints]!

I think of it like getting old. It is the worst thing in the world
except for the alternative.

Someone said the same about democracy

Al

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]

Hi Kevin,

KJ <kkjennings@sbcglobal.net> wrote:
[]

Here is another company that seems to have a timing constraint verification product
http://www.averant.com/products-solidtc.html

thanks a lot, Hans suggested me this a week or so ago.

http://www.fishtail-da.com/

I hope one of them has a trial period.

Al

 

[alb]

Hi Kevin,

KJ <kkjennings@sbcglobal.net> wrote:
[]

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.


Unless you obtain a deep knowledge of the design, if you try to do
what you described 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 late and you're shipping product and 'wierd'
things are happening when the board warms up or cools down or
whatever.

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

[]

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


Seems like this would be your best option. Right now, you're caught
in the project 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 sounds like 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.

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.

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 performance will actually be any better...you will simply know
that you've got it properly constrained. []

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

Al

 

[alb]

Hi Hans,

HT-Lab <hans64@htminuslab.com> wrote:
[]

The OP wants to set this number of clock cycles in the timing
constraints of that special path to verify that the P&R output will work
with the timing he has picked. If the timing fails he has the options
of working to improve the timing in the P&R or changing the logic of the
register enable to allow more clock cycles for this path.
[]

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.

Thanks for rephrasing it so clearly!

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.

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

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.

How would the assertions help me in verifying it?

 

[HT-Lab]

On 07/04/2014 10:00, alb wrote:

Hi Hans,

HT-Lab <hans64@htminuslab.com> wrote:
[]
The OP wants to set this number of clock cycles in the timing
constraints of that special path to verify that the P&R output will work
with the timing he has picked. If the timing fails he has the options
of working to improve the timing in the P&R or changing the logic of the
register enable to allow more clock cycles for this path.
[]

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.

Thanks for rephrasing it so clearly!

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.

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

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.

How would the assertions help me in verifying it?

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

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,

Regards,
Hans.
www.ht-lab.com