is this multicycle?

[kaz]

Hi all,

A counter runs on system clock, counting from 0~95 in steps of 1.
every 3 counts, registers for two signals are updated (data signal an
write signal to ram).

I first assumed both data and write target registers are multicycle but no
have doubts since that implies that fitter may delay data signa
differently from write signal though each is multicycle leading to wron
data being written into ram.

Any thoughts please?

Thanks

Kaz

---------------------------------------
Posted through http://www.FPGARelated.com

 

[kaz]

reposting sorry

Hi all,

A counter runs on system clock, counting from 0~95 in steps of 1.
every 3 counts, registers for two signals are updated (data signal andwrit

signal to ram).

I first assumed both data and write target registers are multicycle but no

have doubts since that implies that fitter may delay dat
signaldifferently
from write signal though each is multicycle leading to wrongdata bein
written
into ram.

Any thoughts please?

Thanks

Kaz

---------------------------------------
Posted through http://www.FPGARelated.com

 

[kaz]

On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote:
Hi all, A counter runs on system clock, counting from 0~95 in steps o
1.=
every 3 counts, registers for two signals are updated (data signal an
wri=
te signal to ram). I first assumed both data and write target register
are=
multicycle but now have doubts since that implies that fitter may dela
da=
ta signal differently from write signal though each is multicycle leadin
t=
o wrong data being written into ram. Any thoughts please? Thanks Ka
------=
--------------------------------- Posted throug
http://www.FPGARelated.com

First, registers are not multi-cylce paths. Paths are multicycle.=20

We cannot tell from your description whether you intend the paths into th
=
registers might be MC, or whether the path from the registers to the RA
mi=
ght be MC.=20

Depending on how the RAM is enabled, the path from the registers to th
RAM=
might be multi-cycle.=20

It is impossible to know about the paths into the registers. Do ALL th
sig=
nals that drive ANY combinatorial logic that drives the registers (apar
fr=
om the implied clock enable) also only change on the same clock edge
every=
3rd clock?

Finally, multi-cycle (and false) path constraints are the most difficul
to=
verify that you specified them correctly, and did not unintentionall
rela=
x the timing constraint on a specific path that is actually NOT MC/F
Verif=
ying this takes either very expensive analysis tools, or carefull
construc=
ted, extensive simulations (with full timing) at the gate level. STA jus
a=
ssumes you specified the constraint correctly.=20


Andy

Thanks Andy

The count value itself is used as enable(rather than using explici
clkenable)
My intention was that the path to above two registers is to b
multicycled
and I didn't include the paths to ram (though they might be as well).
There are no other comb signals entering the scene.
The data itself come from its registers that change every 3 clocks. The
write is meant to be one clock pulse and is assigned from a wire set t
'1'
always.

My concern is that the write signal(one high pulse every three clocks
may
misalign with its data at ram leading to one extra wrong data o
duplicate.

Kaz

---------------------------------------
Posted through http://www.FPGARelated.com

 

On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote:

Hi all, A counter runs on system clock, counting from 0~95 in steps of 1. every 3 counts, registers for two signals are updated (data signal and write signal to ram). I first assumed both data and write target registers are multicycle but now have doubts since that implies that fitter may delay data signal differently from write signal though each is multicycle leading to wrong data being written into ram. Any thoughts please? Thanks Kaz --------------------------------------- Posted through http://www.FPGARelated.com

First, registers are not multi-cylce paths. Paths are multicycle.

We cannot tell from your description whether you intend the paths into the registers might be MC, or whether the path from the registers to the RAM might be MC.

Depending on how the RAM is enabled, the path from the registers to the RAM might be multi-cycle.

It is impossible to know about the paths into the registers. Do ALL the signals that drive ANY combinatorial logic that drives the registers (apart from the implied clock enable) also only change on the same clock edge, every 3rd clock?

Finally, multi-cycle (and false) path constraints are the most difficult to verify that you specified them correctly, and did not unintentionally relax the timing constraint on a specific path that is actually NOT MC/F. Verifying this takes either very expensive analysis tools, or carefully constructed, extensive simulations (with full timing) at the gate level. STA just assumes you specified the constraint correctly.

Andy

 

On Monday, January 14, 2013 10:19:09 AM UTC-6, kaz wrote:

On Monday, January 14, 2013 9:34:14 AM UTC-6, kaz wrote: >> Hi all, A counter runs on system clock, counting from 0~95 in steps of 1.= > every 3 counts, registers for two signals are updated (data signal and wri= >te signal to ram). I first assumed both data and write target registers are= > multicycle but now have doubts since that implies that fitter may delay da= >ta signal differently from write signal though each is multicycle leading t= >o wrong data being written into ram. Any thoughts please? Thanks Kaz ------= >--------------------------------- Posted through http://www..FPGARelated.com > >First, registers are not multi-cylce paths. Paths are multicycle.=20 > >We cannot tell from your description whether you intend the paths into the = >registers might be MC, or whether the path from the registers to the RAM mi= >ght be MC.=20 > >Depending on how the RAM is enabled, the path from the registers to the RAM= > might be multi-cycle.=20 > >It is impossible to know about the paths into the registers. Do ALL the sig= >nals that drive ANY combinatorial logic that drives the registers (apart fr= >om the implied clock enable) also only change on the same clock edge, every= > 3rd clock? > >Finally, multi-cycle (and false) path constraints are the most difficult to= > verify that you specified them correctly, and did not unintentionally rela= >x the timing constraint on a specific path that is actually NOT MC/F. Verif= >ying this takes either very expensive analysis tools, or carefully construc= >ted, extensive simulations (with full timing) at the gate level. STA just a= >ssumes you specified the constraint correctly.=20 > >Andy > Thanks Andy The count value itself is used as enable(rather than using explicit clkenable) My intention was that the path to above two registers is to be multicycled and I didn't include the paths to ram (though they might be as well). There are no other comb signals entering the scene. The data itself come from its registers that change every 3 clocks. The write is meant to be one clock pulse and is assigned from a wire set to '1' always. My concern is that the write signal(one high pulse every three clocks) may misalign with its data at ram leading to one extra wrong data or duplicate. Kaz --------------------------------------- Posted through http://www.FPGARelated.com

OK, first, the functionality (whether clock cycles and data align properly is not affected/dictated by a multi-cycle path constraint. The constraint only relaxes the normal one-period STA-allowable propagation delay from any register to any other register on the same clock signal.

Whether the clock cycles and data align or not is a function of the RTL, and should be observable in RTL simulation, and certainly in full-timing gate level simulations. The gate level sims will also, if the correct conditions are simulated, show you whether the RTL plus the final timing and delays will still perform correctly.

From the sounds of it, if (and only if) the data to the registers is provided by registers that only update themselves on the SAME clock cycle. It is not enough to say that they both are enabled (only) every three clocks. They must be enabled (only) at the same time every three clocks. Then you can probably put a multi-cyle path constraint of 3 clock cycles on the data path between the registers.

My rule of thumb is to NEVER add a multi-cycle path constraint unless the synthesis and/or P&R tool is having problems making the timing, and there are no other reasonable alternatives to resolve the problem (pipelining, etc).. The reason is, as I said earlier, these constraints are very hard to verify that they are accurately specified.

I used to go ahead and put multi-cycle path constraints in as soon as I was aware of them (e.g. in RTL coding/simulation, before I even tried to synthesize or P&R), so that the P&R tool would not work so hard to meet timing I did not need. Then I got bit a time or two with bad assumptions about the path and data (or changed the logic, and did not update the constraints!), and learned (the hard way) why that was not a good idea.

There could be times when not having a MCP constraint could cause the placer to distort the register placement such that other, single-cycle paths cannot be routed and meet timing. I'll run off that bridge when I get there... It hasn't happened yet.

Hope this helps,

Andy

 

[kaz]

Thanks Andy, it all makes sense.

I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycl
of
input register itself) to improve timing which we are struggling with. The
design was showing malfunction pointing to that multicycle area.
I removed the multicycle (only this change made to build) and it is now
outputting correct expected spectrum.

So I have to assume it was wrong multicycle but my own paper analysi
indicated
it could be multicycle.

I believe the issue of multicycle must be automated by tools as part o
timing
analysis as it is indeed very hard to get right in many cases.

Kaz

---------------------------------------
Posted through http://www.FPGARelated.com

 

On Tuesday, January 15, 2013 6:52:23 AM UTC-6, kaz wrote:

Thanks Andy, it all makes sense. I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle of input register itself) to improve timing which we are struggling with. The design was showing malfunction pointing to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum. So I have to assume it was wrong multicycle but my own paper analysis indicated it could be multicycle. I believe the issue of multicycle must be automated by tools as part of timing analysis as it is indeed very hard to get right in many cases. Kaz --------------------------------------- Posted through http://www.FPGARelated.com

I believe you have hit upon the main reason I avoid MCP constraints. It is too easy to overly broadly specify the paths that are covered by an MCP, which lead to issues that may be difficult to identify and debug. You were lucky that the effects showed up quickly.

STA is strictly a structural analysis of the results of placing and routing the FPGA. It does not include any knowledge about the functionality of the logic, other than what is a combinatorial primitive, and what is a sequential primitive. Therefore, adding identification or verification of MCP constraints to this process would be very difficult (the necessary information is not available in this process).

There are SW tools that perform analysis or even generation of multi-cycle and false path constraints from the RTL. Blue Pearl Software has one such tool. I do not know much at all about it. If such capability were to be integrated into the tool suite, it would likely be into the synthesis process, not the timing analysis process.

Andy

 

[GaborSzakacs]

jonesandy@comcast.net wrote:

On Tuesday, January 15, 2013 6:52:23 AM UTC-6, kaz wrote:
Thanks Andy, it all makes sense. I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle of input register itself) to improve timing which we are struggling with. The design was showing malfunction pointing to that multicycle area. I removed the multicycle (only this change made to build) and it is now outputting correct expected spectrum. So I have to assume it was wrong multicycle but my own paper analysis indicated it could be multicycle. I believe the issue of multicycle must be automated by tools as part of timing analysis as it is indeed very hard to get right in many cases. Kaz --------------------------------------- Posted through http://www.FPGARelated.com

I believe you have hit upon the main reason I avoid MCP constraints. It is too easy to overly broadly specify the paths that are covered by an MCP, which lead to issues that may be difficult to identify and debug. You were lucky that the effects showed up quickly.

STA is strictly a structural analysis of the results of placing and routing the FPGA. It does not include any knowledge about the functionality of the logic, other than what is a combinatorial primitive, and what is a sequential primitive. Therefore, adding identification or verification of MCP constraints to this process would be very difficult (the necessary information is not available in this process).

There are SW tools that perform analysis or even generation of multi-cycle and false path constraints from the RTL. Blue Pearl Software has one such tool. I do not know much at all about it. If such capability were to be integrated into the tool suite, it would likely be into the synthesis process, not the timing analysis process.

Andy

Tools that automatically create multicycle constraints are not
inexpensive!

I generally only use milticycle constraints on registers that
are clearly coded to use a periodic clock enable. Even then,
using the clock enable itself as a selector for the timing
group can bite you if you have also used the clock enable as
a feedback to itself like:

if rising_edge(clock) then
clock_enable <= not clock_enable;
end if;

If you then use TNM_NET with clock_enable, you'll find that the
clock enable itself is included in this timing group. Obviously
the clock enable should not be considered as a multicycle path.
So you need to be careful how you define your clock enable if
you're using it to determine multicycle paths.

You can of course use the actual net names to define the timing
groups for multicycle paths, but then you can often get into
trouble by using wildcards that match nets you didn't expect.

-- Gabor

 

[Andy]

On Jan 15, 2:33 pm, GaborSzakacs <ga...@szakacs.invalid> wrote:

Tools that automatically create multicycle constraints are not
inexpensive!

I generally only use milticycle constraints on registers that
are clearly coded to use a periodic clock enable.  Even then,
using the clock enable itself as a selector for the timing
group can bite you if you have also used the clock enable as
a feedback to itself like:

   if rising_edge(clock) then
      clock_enable <= not clock_enable;
   end if;

If you then use TNM_NET with clock_enable, you'll find that the
clock enable itself is included in this timing group.  Obviously
the clock enable should not be considered as a multicycle path.
So you need to be careful how you define your clock enable if
you're using it to determine multicycle paths.

You can of course use the actual net names to define the timing
groups for multicycle paths, but then you can often get into
trouble by using wildcards that match nets you didn't expect.

-- Gabor

Agreed on the cost of those tools... Tools like that have to be
leveraged across larger design teams.

Clock enable signals are almost NEVER multicycle themselves,
regardless of how they were generated (feedback or not). They still
have to propagate (on and off) from their source register to every
enabled register in only one clock.

And wildcards are just begging to include paths you did not intend to
include. When done accurately, they work great. The problem is
verifying they were done accurately. And just because a path is multi-
cycle constrained, does not mean it WILL take multiple clocks to
propagate in the final P&R results, making it impossible to know
whether it could have been multi-cycle and still worked. You'll never
know until some design/tool change suddenly lengthens the propagation
to longer than one clock, and boom!

It is relatively easy to add assert statements in the RTL such that
you can detect if the signal ever changes more recently than your
assumed MCP constraint, even in RTL simulation. The problem is making
sure the constrained paths are the same ones checked by the the
assertion!

Andy

 

[rickman]

On 1/15/2013 7:52 AM, kaz wrote:

Thanks Andy, it all makes sense.

I set to multicycle of 2 (rather thn 3 for reasons to do with clock cycle
of
input register itself) to improve timing which we are struggling with. The
design was showing malfunction pointing to that multicycle area.
I removed the multicycle (only this change made to build) and it is now
outputting correct expected spectrum.

So I have to assume it was wrong multicycle but my own paper analysis
indicated
it could be multicycle.

I believe the issue of multicycle must be automated by tools as part of
timing
analysis as it is indeed very hard to get right in many cases.

I find multicycle constraints to be a very simple issue. As was
explained, it is the paths that are constrained, not the registers. So
think in terms of the paths.

You have multicycle paths ending at some registers. These paths need to
be constrained with the correct time values. The register enables (or
write enables in your case) are still single clock cycle paths. So you
need to make sure the enables are constrained with the single clock
period. If you apply the longer, multicycle constraint to the enable
paths, you may well end up with misaligned enables and data because of
excessive path delays. That is all there is to "multicycle" timing
constraints.

But of course the devil is in the details.

I don't know what tools you are using and I'm not familiar with every
tool family, so I likely couldn't give you detailed info on just how to
apply timing constraints in your case.

What was said about the tools not being too smart about verifying timing
constraints is, in my opinion, a major shortcoming of the tools. We
have powerful tools to verify our logic and our timing... but not the
timing constraints which drive the timing analysis. Everything about
engineering is verification. So I find it odd that you can't verify
your timing constraints in any useful way.

If you are concerned that your timing constraints are working correctly,
you can run a post-route simulation which will include timing. This can
help, but likely won't catch all potential issues.

Rick