FPGA Central

Hi all,

In normal design we'd like to pipeline large comb logic to pipelined
design. But I heard there is Multi-cycle Path and need more complex
control logic.

I have some questions according to it.
1. Is most design style don't recommend Multi-cycle Path?
2. Can I change all Multi-cycle Path to Pipelined Path?
3. Can I change all Pipelined Path to Multi-cycle Path?
4. In what circumstance shall we need Multi-cycle Path?

Any recommending reading material is welcome!

Best regards,
Davy

Hi Davy,

Read answers below...

Davy wrote:
> Hi all,
>
> In normal design we'd like to pipeline large comb logic to pipelined
> design. But I heard there is Multi-cycle Path and need more complex
> control logic.
>
> I have some questions according to it.
> 1. Is most design style don't recommend Multi-cycle Path?

In general it isn't recommended to use multi-cycle path. You end up
having to manually tell the timing check part of the tools the explicit
places that you are planning to violate typical synchronous design
style.

> 2. Can I change all Multi-cycle Path to Pipelined Path?

No, most of paths but not all.

> 3. Can I change all Pipelined Path to Multi-cycle Path?

Yes, but why?

> 4. In what circumstance shall we need Multi-cycle Path?

When you have a indivisible chunk of logic, such as a hard macro that
can't be pipelined further.
>
> Any recommending reading material is welcome!

Not off hand. The moral of this story is pipeline when you can,
multi-cycle when you must.
>
> Best regards,
> Davy

Davy wrote:

> I have some questions according to it.
> 1. Is most design style don't recommend Multi-cycle Path?

I don't design using multi-cycle paths,
nor have I (so far) had to include one in a design.

> 2. Can I change all Multi-cycle Path to Pipelined Path?

I prefer to design single-cycle
logic in the first place.
I'd rather create a synchronous clock enable
than keep track of a path constraint for
the life of the design.

> 3. Can I change all Pipelined Path to Multi-cycle Path?
> 4. In what circumstance shall we need Multi-cycle Path?

Multi-cycle is an odd timing spec that I happen to know.
It's not something I need, it's a less than
perfect (but adequate) circuit that I can either fix
or tolerate by using a constraint.

-- Mike Treseler

"Davy" <[email protected]> wrote in message
news:[email protected] oups.com...
> Hi all,
>
> In normal design we'd like to pipeline large comb logic to pipelined
> design. But I heard there is Multi-cycle Path and need more complex
> control logic.

The only logic required is to tell when the output is valid. This can for
example be a simple counter/shift register/fsm etc controlling a FF enable
pin.

>
> I have some questions according to it.
> 1. Is most design style don't recommend Multi-cycle Path?

It has nothing to do with recommendations, it is a design issue. If you have
a large combinatorial block and the output is not required every clock cycle
then why pipeline it? Adding an MCP constraint is much quicker and might
also helps your backend tool meeting timing.

> 2. Can I change all Multi-cycle Path to Pipelined Path?

without any further details, yes.

> 3. Can I change all Pipelined Path to Multi-cycle Path?

without any further details, yes.

> 4. In what circumstance shall we need Multi-cycle Path?

As above, also if you use the enable input of a FF then you might already
have a MCP and not be aware of it :-)

>
> Any recommending reading material is welcome!

I would suggest the Design compiler reference manual (you can find this on
the web) which has some example of MCP's, also have a look at
http://www.fishtail-da.com/

Hans
www.ht-lab.com


>
> Best regards,
> Davy
>

Davy a écrit :
> Hi all,
>
> In normal design we'd like to pipeline large comb logic to pipelined
> design. But I heard there is Multi-cycle Path and need more complex
> control logic.
>
> I have some questions according to it.
> 1. Is most design style don't recommend Multi-cycle Path?
No, there is no such recommendation.
> 2. Can I change all Multi-cycle Path to Pipelined Path?
> 3. Can I change all Pipelined Path to Multi-cycle Path?
> 4. In what circumstance shall we need Multi-cycle Path?
For the previous points perhaps, but you really have to describe your
design as it is.
For example, a configuration register, going in logic using the same
clock, is a real multicycle path.
>
> Any recommending reading material is welcome!
>
> Best regards,
> Davy
>

Hans wrote:

> As above, also if you use the enable input of a FF then you might already
> have a MCP and not be aware of it :-)

Yes, and synthesis can most often arrange
to meet single cycle timing in this case.
I don't *need* to think about timing constraints
unless static timing fails.

If such a path were to fail,
and I happen to know for *sure*
that good data is never needed on
the first tick, then I have a choice.
I can add a constraint or change the design.
This is a matter of style unless my device is full.

-- Mike Treseler