Is this Multicycle?

[kaz]

Assume register r4 is driven by three registers r1, r2, r3
registers r1, r2, r3 drive out their data every 3 clocks, each on
different
clock phase. r1 is driven successively in the order of r1,r2,r3 such that
the D input of register r4 is changing every clock.

Now, if I assign multicycle of 3 on r1 then I assume r1, r2, r3 each wil
each
launch its data without violating r1.

so reg r1 can be assigned multicycle of 3 despite its input changing every
clock cycle.

Any thoughts on that?

Kaz


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

 

[kaz]

correcting typos:

Assume register r4 is driven by three registers r1, r2, r3
registers r1, r2, r3 drive out their data every 3 clocks, each on
different
clock phase. r4 is driven successively in the order of r1,r2,r3 such that
the D input of register r4 is changing every clock.

Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each wil
each
launch its data without violating r4.

so reg r4 can be assigned multicycle of 3 despite its input changing every
clock cycle.

Any thoughts on that?

Kaz


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

 

[kaz]

On Sat, 08 Dec 2012 00:47:40 -0600, kaz wrote:

correcting typos:

Assume register r4 is driven by three registers r1, r2, r3 register
r1,
r2, r3 drive out their data every 3 clocks, each on a different clock
phase. r4 is driven successively in the order of r1,r2,r3 such that the
D input of register r4 is changing every clock.

Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each
will each launch its data without violating r4.

Not quite because there has to be a way of selecting which of R1 ..R3
drives R4. And it won't be implemented as tristates but as a multiplexer

whose outputs (R4 inputs) must settle in a single cycle.

It may be permissible to identify paths specifically from R1..R3 to R4
and multi-cycle those, as long as you can identify the select signals an

ensure they (and therefore the mux) are single cycle, but simply
assigning multicycle on R4 inputs is asking for trouble.

(and in a real world design I would be very surprised if it gave you any
advantage over straightforward single cycle constraints. If it does,
please post numbers!)

- Brian

Thanks Brian, good point.

However, I am assuming some friendly fitter that takes care of data acros

the mux as well i.e. r1 launches its data that is made available whe
sampled
after 3 clocks then r2 and so on in a queue, and each sampled at correc
phase by the design.

Of course if the fitter doesn't respect the order of queue right to
input,
then I am in trouble.

I haven't implemented to see the benefit but I am short of speed an
looking
for any deconstraints.

Kaz

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

 

[Brian Drummond]

On Sat, 08 Dec 2012 00:47:40 -0600, kaz wrote:

correcting typos:

Assume register r4 is driven by three registers r1, r2, r3 registers r1,
r2, r3 drive out their data every 3 clocks, each on a different clock
phase. r4 is driven successively in the order of r1,r2,r3 such that the
D input of register r4 is changing every clock.

Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each
will each launch its data without violating r4.

Not quite because there has to be a way of selecting which of R1 ..R3
drives R4. And it won't be implemented as tristates but as a multiplexer,
whose outputs (R4 inputs) must settle in a single cycle.

It may be permissible to identify paths specifically from R1..R3 to R4
and multi-cycle those, as long as you can identify the select signals and
ensure they (and therefore the mux) are single cycle, but simply
assigning multicycle on R4 inputs is asking for trouble.

(and in a real world design I would be very surprised if it gave you any
advantage over straightforward single cycle constraints. If it does,
please post numbers!)

- Brian

 

[Thomas Stanka]

On 8 Dez., 07:47, "kaz" <3619@embeddedrelated> wrote:

Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each will
each
launch its data without violating r4.

so reg r4 can be assigned multicycle of 3 despite its input changing every
clock cycle.

Any thoughts on that?

This is not multicycle. Assume your logicone has the points P1-P3
before the multiplexing, than you could multicycle the path from r1 to
P1, r2 to P2,.. but I don't think any tool would handle that
constraint correct.

You could insert registers before the multiplexing structure. That
would allow to set multicycle of 2 clock cycles without loosing
latency, but would require carefule enable generation of that
register.

best regards Thomas

 

[Brian Drummond]

On Sat, 08 Dec 2012 04:42:34 -0600, kaz wrote:

On Sat, 08 Dec 2012 00:47:40 -0600, kaz wrote:

correcting typos:

Assume register r4 is driven by three registers r1, r2, r3 registers
r1,
r2, r3 drive out their data every 3 clocks, each on a different clock
phase. r4 is driven successively in the order of r1,r2,r3 such that
the D input of register r4 is changing every clock.

Now, if I assign multicycle of 3 on r4 then I assume r1, r2, r3 each
will each launch its data without violating r4.

Not quite because there has to be a way of selecting which of R1 ..R3
drives R4. And it won't be implemented as tristates but as a
multiplexer,

whose outputs (R4 inputs) must settle in a single cycle.

It may be permissible to identify paths specifically from R1..R3 to R4
and multi-cycle those, as long as you can identify the select signals
and

ensure they (and therefore the mux) are single cycle, but simply
assigning multicycle on R4 inputs is asking for trouble.

(and in a real world design I would be very surprised if it gave you any
advantage over straightforward single cycle constraints. If it does,
please post numbers!)

- Brian


Thanks Brian, good point.

However, I am assuming some friendly fitter that takes care of data
across

the mux as well i.e. r1 launches its data that is made available when
sampled after 3 clocks then r2 and so on in a queue, and each sampled at
correct phase by the design.

Simply won't work. If you try to multicycle the mux, that can only work
by starting to drive R3 to the outputs before R3's phase - i.e. during
R2's or even R1's. In which case, the fast paths arrive at the output a
cycle or two too early! Therefore any path from the mux inputs onwards is
strictly single cycle.

Unless by "sampling at the correct phase" you meant "sampling and
holding..." in which case you are just introducing more registers. That
potentially works but there isn't much scope to pipeline a 3:1 MUX!

You could potentially pipeline it as two 2:1 muxes with a reg in between
them (and a compensating reg for the 3rd input) but you'd have to be
working right at the edge of the FPGA's speed capability for this to be
worthwhile (well over 500MHz in Virtex-5 for example)

The only other benefit of extra regs would be to hide excessive routing
delay. If that's your problem then the simplest answer is to LOC R1, R2,
R3, the mux and Rout next to each other in the floorplanner, and
introduce extra pipe stage if that doesn't work.

- Brian