Is this Multicycle?

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

formatting link

Reply to
kaz
Loading thread data ...

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.

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

Any thoughts on that?

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz

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

Reply to
Brian Drummond

r1,

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.

Of course if the fitter doesn't respect the order of queue right to D input,

then I am in trouble.

I haven't implemented to see the benefit but I am short of speed and looking

for any deconstraints.

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz

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

Reply to
Thomas Stanka

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

Reply to
Brian Drummond

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.