Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20688 Discussions

more components in paths

Altera_Forum
Honored Contributor II
1,324 Views

hiii alll i am facing too many components in my critical path.. 

I know it depends on coding..but is there anything i can do in synthesis to reduce this total delay
0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
362 Views

i am attaching the report i got for one such path..

0 Kudos
Altera_Forum
Honored Contributor II
362 Views

the only way I know about is increasing the pipelining.

0 Kudos
Altera_Forum
Honored Contributor II
362 Views

You have a really long IC hop in there too. I wonder if multiple I/O are feeding into this path that are spread around the die, and the fitter is balancing the best placement?  

Even for just decent I/O performance, it is recommended to register your inputs and outputs. Having long delays like that makes them really slow. (I assume you need low latency...)
0 Kudos
Altera_Forum
Honored Contributor II
362 Views

Oh thanks guys...And yes RYSC the inputs and outputs should be registered... 

In this case as you can see the input is fed directly to a priority kinda logic around 4-5 mux...and the result is fed to a reg and den the output.. 

the constraint like fast input reg also fails because the input has not been registered.. 

Do you think the logic needs a change or it can be done with some synthesis constraints???
0 Kudos
Altera_Forum
Honored Contributor II
362 Views

And yes for the same path if i do fast corner analysis is taking around 3.4ns..and the earlier path was for speed grade 4 slow corner..working at 225Mhz

0 Kudos
Altera_Forum
Honored Contributor II
362 Views

It's hard to say. First, I don't know by how much you fail timing. I also don't know what the clock looks like. The only major place for savings is that long IC, but it may be there to balance the delay to the output. You'd have to compare the input and output slacks and see if there is a way to steal from the output timing to help the input.  

If you're not failing by much, it might be possible. If a PLL is feeding the register, you could phase-shift it forward a bit. You could also try hand-placing the register. Just some ideas, but it will be some work.
0 Kudos
Altera_Forum
Honored Contributor II
362 Views

Yes RYSC tried your ideas...a bit of comparison of input and output slacks helped steal some time to the input.. 

Plus would like to add that using Enable Beneficial Skew Optimization provided me a help of 1ns and things came on track.. 

The hand placing of registers offcourse provided a help of 0.3 ns and would like to add that the path was fed to a state machine..do you kno how to optimize the logic of a state machine using binary encoding as seen in the rtl
0 Kudos
Altera_Forum
Honored Contributor II
362 Views

Not sure. You might want to place with the state-machine encoding. (Binary is not necessarily faster, as it depends what states the output is dependent on. Quite often it is slower, but hard to tell until you try).  

Enable Beneficial Skew shouldn't really gain 1ns. Note that there's a small delay in the LAB that can be on or off, and that's what this algorithm controls. Depends on device/speed grade, but I don't think it's more than a few hundred ps. But you may have gotten a different place and route? 

You mention 225MHz. Are you sure your constraints are correct? This is a general statement, but once you account for the external device delays, 225Mhz almost requires the FF in the IO cell. Again, it really depends on clock skew, clock constraints, etc. that isn't being shown. Just a concern.
0 Kudos
Altera_Forum
Honored Contributor II
362 Views

Often timing problems are down to the HDL. With >200Mhz you have to be careful how many gates between registers, usually trying to use no more than 1 or 2 LUTs. Have you got any parts in your statemachine with complicated "if" statements. You can usually break these down and pipeline them.

0 Kudos
Reply