FPGA Central

Hi

How do I tell quartus that a signal has a propergation delay of 2
clocks?

That is to say the value does not have to become valid for 2 clocks,
instead of the usual 1 clock. You geussed this is the current fmax
path, and so all other timing is being affected. The 2 clock limit is
correct as far as operation is concerned, but the fmax result is
adversly wrong.

cheers jacko

On Wed, 29 Apr 2009 08:20:19 -0700 (PDT), jacko <[email protected]>
wrote:

>Hi
>
>How do I tell quartus that a signal has a propergation delay of 2
>clocks?
>
>That is to say the value does not have to become valid for 2 clocks,
>instead of the usual 1 clock. You geussed this is the current fmax
>path, and so all other timing is being affected. The 2 clock limit is
>correct as far as operation is concerned, but the fmax result is
>adversly wrong.

set_multicycle_path is what you need. Check out
http://www.altera.com/literature/an/an481.pdf
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

jacko wrote:

> How do I tell quartus that a signal has a propergation delay of 2
> clocks?
> That is to say the value does not have to become valid for 2 clocks,
> instead of the usual 1 clock. You geussed this is the current fmax
> path, and so all other timing is being affected. The 2 clock limit is
> correct as far as operation is concerned, but the fmax result is
> adversly wrong.



Because I find timing constraints tedious,
I generate synchronous clock enable strobes
at just the right tick.

If the strobe isn't used otherwise,
the register gets optimized away.

For example, a_v'left, below becomes
an asynch carry out.

-- Mike Treseler
_________________________________________
if a_v(a_v'left) = '1' then -- a carry?
a_v(a_v'left) := '0'; -- clear carry
b_v := b_v + 1;
...

d <=fn(c,din);
if(rising_edge(clk) and second_cycle = '1') then
c <= d;
end if;
if(rising_edge(clk) and second_cycle = '0') then
-- din <= din; -- self held assignment programmer knowledge
end if;

is there anyway to specify that the combinational fn is two cycle? the
register retiming options seem to remove the carry bit, and replace it
with and implicit signal. Maybe the retiming does an eval of the state
machine order and realizes??

It seems that because the synthesis tool does not realize the data in
port remains constant, because the address bus remains constant, it
freaks a little and routes accordingly. As a latch is totally un-
necessary.

I don't have timing quest money or time.

Fair enough if din did change then it would be a mistake, but it
don't.

cheers jacko

Jacko wrote:

> is there anyway to specify that the combinational fn is two cycle? the
> register retiming options seem to remove the carry bit, and replace it
> with and implicit signal. Maybe the retiming does an eval of the state
> machine order and realizes??

I think my synthesis discussion confused the issue.
To avoid a timing constraint, I have to treat fn()
like a rom and do a read cycle
with a wait counter in a synch process.

count to n, set ready bit, wait for ack bit.

> It seems that because the synthesis tool does not realize the data in
> port remains constant, because the address bus remains constant, it
> freaks a little and routes accordingly. As a latch is totally un-
> necessary.

Synthesis does what the code says.
I need a simulator to check the code, not synthesis.

> I don't have timing quest money or time.

A free simulator is good enough to verify this controller.
The only timing requirement inside a synch design is Fmax.
Luts and flops are cheap.

-- Mike Treseler

On Apr 30, 5:42*pm, Mike Treseler <mtrese...@gmail.com> wrote:
> Jacko wrote:
> > is there anyway to specify that the combinational fn is two cycle? the
> > register retiming options seem to remove the carry bit, and replace it
> > with and implicit signal. Maybe the retiming does an eval of the state
> > machine order and realizes??
>
> I think my synthesis discussion confused the issue.
> To avoid a timing constraint, I have to treat fn()
> like a rom *and do a read cycle
> with a wait counter in a synch process.
>
> count to n, set ready bit, wait for ack bit.
>
> > It seems that because the synthesis tool does not realize the data in
> > port remains constant, because the address bus remains constant, it
> > freaks a little and routes accordingly. As a latch is totally un-
> > necessary.
>
> Synthesis does what the code says.
> I need a simulator to check the code, not synthesis.
>
> > I don't have timing quest money or time.
>
> A free simulator is good enough to verify this controller.
> The only timing requirement inside a synch design is Fmax.
> Luts and flops are cheap.
>
> * -- Mike Treseler

The point was to get the synthesis tool to do it. But no matter
anymore. I moved onto the half width (byte) data bus interface version
got 49MHz estimate (nibzC.vhd) This avoids many of the propergation
problems as each instruction takes 4 cycles. Which a over 10 MIPS will
be fine. A big endian design which loads the little end first...

The code is so simple...at 394 LEs, and highly orthogonal instruction
decode and execution. The delayed write of the high byte consumes
quite a few gates, but it does prevent the need for multiphasing the
clock as the instruction fetch interleaves the two written bytes, so
RW SRAM line has no need to be async to get the two rising edges.

cheers jacko

http://nibz.googlecode.com

Jacko wrote:

> The point was to get the synthesis tool to do it. But no matter
> anymore. I moved onto the half width (byte) data bus interface version
> got 49MHz estimate (nibzC.vhd) This avoids many of the propergation
> problems as each instruction takes 4 cycles. Which a over 10 MIPS will
> be fine. A big endian design which loads the little end first...
> The code is so simple...at 394 LEs, and highly orthogonal instruction
> decode and execution. The delayed write of the high byte consumes
> quite a few gates, but it does prevent the need for multiphasing the
> clock as the instruction fetch interleaves the two written bytes, so
> RW SRAM line has no need to be async to get the two rising edges.
> cheers jacko
>
> http://nibz.googlecode.com

Thanks for the link.
That looks like a good place to collaborate.

Sorry I didn't follow your problem,
but thanks for posting the solution.
I always prefer changing my design over
turning the knobs on synthesis.

-- Mike Treseler