PAR taking toooo much time

Status
Not open for further replies.

syedshan

Advanced Member level 1
Joined
Feb 27, 2012
Messages
463
Helped
27
Reputation
54
Reaction score
26
Trophy points
1,308
Location
Jeonju, South Korea
Visit site
Activity points
5,134
Hi all

My Pacemenet and Routing is taking tooo much time, when I do it with UCF file.
If I do it without UCF file it works just fine...

For simplicity what I did was just tried a simple program and it was similar. i.e. with UCF file takes looong time, while without it works fine...
I understand that it the PAR route and re-route but it seems to take too much time at phase-7 , later in the next phase take much longer time

Another noting point was that after phase 6, it run phase 8 then goto phase 7

The design is simplest, even then it takes tooooo much time. (a simple counter , for testing of timing analysis and simulation)

I have put my UCF file here since I cannot understand parameters like offset in and offset out and what values related to clock time I should put there...
Eagerly waiting,

Code:
#Created by Constraints Editor (xc6vlx240t-ff1156-1) - 2013/05/20
NET "clk" TNM_NET = clk;
TIMESPEC TS_clk = PERIOD "clk" 10 ns HIGH 50%;
#Created by Constraints Editor (xc6vlx240t-ff1156-1) - 2013/05/20
NET "a" OFFSET = IN 3 ns VALID 3 ns BEFORE "clk" RISING;
#Created by Constraints Editor (xc6vlx240t-ff1156-1) - 2013/05/20
INST "cntr_out<0>" TNM = cnt_GP;
INST "cntr_out<1>" TNM = cnt_GP;
INST "cntr_out<2>" TNM = cnt_GP;
INST "cntr_out<3>" TNM = cnt_GP;
INST "cntr_out<4>" TNM = cnt_GP;
INST "cntr_out<5>" TNM = cnt_GP;
INST "cntr_out<6>" TNM = cnt_GP;
INST "cntr_out<7>" TNM = cnt_GP;
TIMEGRP "cnt_GP" OFFSET = OUT 3 ns AFTER "clk";

- - - Updated - - -

Also How important is TIMING simulation, once your static simulation is fine...
 

If your entire design is synchronous:
1. Have you got really really good RTL testbenches?
2. Does it meet timing?
3. Fails on bench - reassess 1 and 2.

After several loops through this then you might consider timing simulation.
A good RTL testbench will probably have well designed and well speced behavioural models of your interfaces to check every module works as specced and then the system works as specced (and you usually do them as black box tests). Without good RTL simulation, you're making 2 and 3 more difficult.

If you have asynchronous logic, you may have to dip into timing simulation. Hence why you really really want to make everything synchronous.

PS. I have been writing code for FPGAs for 8 years - I have never done a timing simulation (and its never been a problem on FPGAs).
 

Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…