delay parameters before synthesis

[imbichie]

Hi All,

Is there any standard method to find the delay parameters in a design at the time of coding itself.

Means before going to the synthesis process.

This is for finding the maximum frequency of the design before synthesis

Thanks in advance..

 

[fpgadsgnr]

Hi,

What kind of delay parameters you want to know before synthesis? Maximum freq of the design is calculated based on the critical path of the design, and to calculate that you need to know propagation delays of LUTs, setup & hold times of flipflops of actually used. And this information can be obtained after synthesis only.

Thanks,
Fpgadsgnr

 

[imbichie]

Hi FPGADSGNR,

Thanks for your reply..

I know that the critical path is getting after the synthesis only.

I need to know is there any other method to find the maximum frequency before synthesis, means during the rtl coding...

If no, then how we decides the working frequency of a design...?

Because if we can decide the working frequency only after the synthesis process, then the thing will be danger, because its too time consuming ..

Thanks and Regards,

Shibin Bose K

 

[fpgadsgnr]

Hi FPGADSGNR,

Thanks for your reply..

I know that the critical path is getting after the synthesis only.

I need to know is there any other method to find the maximum frequency before synthesis, means during the rtl coding...

If no, then how we decides the working frequency of a design...?

Because if we can decide the working frequency only after the synthesis process, then the thing will be danger, because its too time consuming ..

Thanks and Regards,

Shibin Bose K

In that case, you manually need to look into the path with max number of levels and estimate using the timing equation (with Tcomb, Tsetup, TclktoQ etc). But that can an estimate only and if the design is complex, it will be difficult and even more time consuming.

Fpgadsgnr

 

[K-J]

I need to know is there any other method to find the maximum frequency before synthesis, means during the rtl coding...

Other than guessing based on previous design experience with the same family of parts, no there is not.

If no, then how we decides the working frequency of a design...?

Assuming no prior experience with the same family of parts, then the method is
- Synthesize the design to see what maximum frequency is reported. Do not wait until the design is 'complete', build what you have.
- Based on multiple synthesis results as the design is evolving from the previous step, you should start to get some idea of about how fast the design will run. Now add a timing constraint to tell synthesis what speed you are looking for. Re-run synthesis to see that it still works.
- As you continue to work on the RTL, continue to do background builds to see if timing is still passing. If it starts failing, it could be that you need to relax the Fmax requested or it could mean that new code that you've added is slowing things down and should maybe be scrutinized a bit to see if there is a faster way to implement

Because if we can decide the working frequency only after the synthesis process, then the thing will be danger, because its too time consuming ..

I'm not sure what danger you see, but the clock will come from either an external oscillator or an internal PLL. If you need to change the external oscillator on a board, that is not that big of a deal. It's a 4 pin device. The trouble there might be if that same oscillator is used by multiple parts on the PCBA. But if that is your situation, then you already knew upfront the operating clock frequency that you needed to meet. If the clock is coming from an internal PLL, then it simply means you adjust the PLL parameters to produce a different frequency which will result in a new binary file to download to the device. This is no different then if you fix some logic problem.

As to 'time consuming', I'm guessing you mean the time spent iterating through the synthesis tool. That's why I suggested running synthesis early and often as the design is still being created. That way it runs in the background, when it finishes take a look, but don't sit there waiting doing nothing while the tool is running. This method can also catch design errors that haven't been caught in compiling or simulation up to that point.

Kevin Jennings