about chip planner in Quartus II

[Altera_Forum]

I tried to change the placement and routing by Chip planner, and estimate the delay time. 

For example, I input a signal to a buffer and then output, the delay time in Chip planner is:  after I generate fan-out connections:  input port to the LE, which is the buffer: 2.590 ns delay time in LE : 0.2 ns LE to the output port : 1.695 ns  then, the total delay time from input to output signal should be around 5 ns.  But, when I use oscilloscope to see the delay between the input and output signal, It is around 15 ns. It is very differnet to the 5 ns of the estimated time.  I dont know if I do something wrong why they are not same.  Thanks for your help.  --- My Quartus II is version 7.1 Web edition

[Altera_Forum]

Does your estimation include input/output buffer delay? Also you need to consider the output delay depends on the output loading.

[Altera_Forum]

Thanks gee for response. 

 I take the picture of my test file:  1) bmp file: the chip planner design of the dely time  (http://mail.sso.ncku.edu.tw/cgi-bin/owmmbox/openwebmail-webdisk.pl/test.bmp?sessionid=l7697401*-session-0.819223314329101&currentdir=%2f&action=download&selitems=test.bmp)http://140.116.5.200/~e9493122/test.bmp (http://140.116.5.200/%7ee9493122/test.bmp)  2) jpg file: the waveform of the input/output signal in oscilloscope  (http://mail.sso.ncku.edu.tw/cgi-bin/owmmbox/openwebmail-webdisk.pl/wave.jpg?sessionid=l7697401*-session-0.819223314329101&currentdir=%2f&action=download&selitems=wave.jpg)http://140.116.5.200/~e9493122/wave.jpg (http://140.116.5.200/%7ee9493122/wave.jpg) in this case, the fan-out connections are:  input port to the LE, which is the buffer: 2.074 ns delay time in LE : 0.2 ns LE to the output port : 0.612 ns  The estimate total delay time is around 3 ns, but the real total delay time is around 15 ns in scope.  You mean I should consider the input/output delay besides the delay time that are shown in chip planner. I cannot find if the chip planner can show the input/output buffer delay as you mentioned. Does it mean that the delay time shown on chip planner is totally not right, or I shoud add extra delay time of the input/output buffer by hand? that is, 3 ns + (input/output delay which cannot be shown) = 15 ns  I am wondering that, when the input/output delay is not correct, how can I trust the delay time shown in chip planner of other elements?  Thanks for your attention and help.

[Altera_Forum]

Hi ccmkn, 

 You can use the TimeQuest or Classic Timing Analyzer for more detailed timing analysis. They will give you accurate tpd including all components delay. Which are you using?  Regards,

[Altera_Forum]

Hi, 

 I didnt use the Timing analysis of TimeQuest or Classic timing analyzer.  Doesn't the timing analyzer just restrict the max time of the delay, not analysize the about delay time of my design in chip planner?  Maybe I confused you, sorry.  In my design, I have to make all elements, like buffers, have the same delay time, that is why I use chip planner to arrange the logicelements. Its OK for me if the delay times are not short, as long as they are the same.  I will check if the Timing analysizer has other functions that I didnt know.  Thanks again

[Altera_Forum]

Hi, 

 The path delay you want to see may be shown in the Timing Anlayzer report. If it contains only logics and not FFs, you can find what you want in "tpd" report. Once you find the path under "tpd" report, right clik after seleting(left clicking) it and choose "list path.jpg". (shown in the tpd.jpg). Double click the path delay list which appears in the message window, it locates to the ChipPlanner. Now you can see what is shown in ChipPlanner and what is not.  Thanks,

[Altera_Forum]

Thanks gee very much. 

 I just followed the steps you replied. There are surely some delay time in the input/output ports that are not shown in Chip planner.  That is a really help, thank you.  Though, the delay times in the report are still not match what I measured in scope.  If the report shown are the real delay times of my design, maybe it is wrong of my way to measure signals with the scope.

[Altera_Forum]

Hi, gee 

 According to your reply, I am wondering that why I cannot use the report when I have FFs?

[Altera_Forum]

Hi, 

 Yes, you can, but in the case you need to see tco report instead of tpd.  Regards!

[Altera_Forum]

--- Quote Start ---  Hi,  I didnt use the Timing analysis of TimeQuest or Classic timing analyzer.  Doesn't the timing analyzer just restrict the max time of the delay, not analysize the about delay time of my design in chip planner?  Maybe I confused you, sorry.  In my design, I have to make all elements, like buffers, have the same delay time, that is why I use chip planner to arrange the logicelements. Its OK for me if the delay times are not short, as long as they are the same.  I will check if the Timing analysizer has other functions that I didnt know.  Thanks again  --- Quote End ---    Hi,  why do you need this constraint ? It will be very difficult to fulfill such requirement, especially if you have to do it for a lot of elements.

[Altera_Forum]

Hi, 

 Thanks your attention, and sorry for my reply so late.  The reason why I must have the same delay time of elements is that I am going to design the TDC(Time to Digital Convertor) by CPLD or FPGA.  The main goal is to design several stages that each one has the same delay time. After the pulse signal pass several stages and stop, say, n stages. I can have the pulse signal has time=n*(delay time of each stage).  There is a short and simple explaination.  If it is not worthy to change the placement by hand to achieve my goal. Is there a more convenient way?  Thanks.

[Altera_Forum]

Some general remarks. Most FPGA tools are mainly designed to synthesize synchronous logic. They have limited capabilities in asynchronous logic synthesis. 

 I understand, that you intend a delay chain with uniform stage-to-stage delay. The feasibility may depend on the number of stages. You can expect almost equal delays within a logic array block, but surely get additional delays when routing through LAB interconnects.   So, even with completely manual placement of logic elements by location assignments, it may be difficult to achieve the intended timing.  Finally, I reviewed the waveform you posted at start of the thread. With this kind of slow rising signals, it's effectively impossible to decide about any real device delay. The said 15 ns should be expected a measurement artefact rather than a real value. Delta delays determined at the digital side may be valid anyway.

[Altera_Forum]

--- Quote Start ---  Some general remarks. Most FPGA tools are mainly designed to synthesize synchronous logic. They have limited capabilities in asynchronous logic synthesis.  I understand, that you intend a delay chain with uniform stage-to-stage delay. The feasibility may depend on the number of stages. You can expect almost equal delays within a logic array block, but surely get additional delays when routing through LAB interconnects.   So, even with completely manual placement of logic elements by location assignments, it may be difficult to achieve the intended timing.  Finally, I reviewed the waveform you posted at start of the thread. With this kind of slow rising signals, it's effectively impossible to decide about any real device delay. The said 15 ns should be expected a measurement artefact rather than a real value. Delta delays determined at the digital side may be valid anyway.  --- Quote End ---    Thanks your suggestions, it is truly help to me.  But I am a little confused about your last two lines.  Do you mean that the delaytime is not truly 15 ns as I thought, because it rose too slow to measure it directly, and the delaytime which I show in Chipplanner is more correct?

[Altera_Forum]

You didn't tell, which device you have been using in your test, but neither the delay nor the rise-times (also of the output signal) are in a range I'm used to with recent Altera devices. 

 P.S.: You may be able to achieve it using minimum current strength and a high capacitive load, but then you aren't measuring device delays.

[Altera_Forum]

I worked with CPLD, MAX II: EPM570T100C5. 

 And here is my testing: I used function generator to generate 3.3 V square wave as input to CPLD (here has a T-connector to have the input into scope), and CPLD output to the scope to have the waveform.  Is my measurement wrong to have the 15 ns not as my expect delaytime?

[Altera_Forum]

--- Quote Start ---  I worked with CPLD, MAX II: EPM570T100C5.  And here is my testing: I used function generator to generate 3.3 V square wave as input to CPLD (here has a T-connector to have the input into scope), and CPLD output to the scope to have the waveform.  Is my measurement wrong? And have the 15 ns not as my expect delaytime?  --- Quote End ---    Hi ccmkn,  what resolution do you need for your delays ? If I understand you right you are looking for a design which measures the length of a pulse ?  Kind regards  GPK

[Altera_Forum]

Hi, pletz. 

 The main problem is that the delay time which I measured with the scope is not as same as I simulated in Chip planner. The resolution I want to have is at least 0.5 ns, but of course, it is better to have better resolution if possible.  In my design, I am not measure the length of the pulse. Instead, I want measure the delay time of two pulses (That is what TDC does). And I have to measure the delay time of buffers and latches first. That is why I do this test.  By the way, Beside the delay times shown in chip planner, and the pin transition time of gee just tought me. Is it possible there are additioal delays that I didnt figure out?

[Altera_Forum]

--- Quote Start ---  Hi, pletz.  The main problem is that the delay time which I measured with the scope is not as same as I simulated in Chip planner. The resolution I want to have is at least 0.5 ns, but of course, it is better to have better resolution if possible.  In my design, I am not measure the length of the pulse. Instead, I want measure the delay time of two pulses (That is what TDC does). And I have to measure the delay time of buffers and latches first. That is why I do this test.  By the way, Beside the delay times shown in chip planner, and the pin transition time of gee just tought me. Is it possible there are additioal delays that I didnt figure out?  --- Quote End ---    Is the listed path in Gee's attachment one of yours paths ?  If yes, you have a delay of 17.211 ns. The delay is could be splitted into 5.063ns for cell delay ( in the listing all value for "CELL") and 12.148ns for interconnect delay ( in the listing all values for "IC")

[Altera_Forum]

No, the attachments are examples that gee gave to show me how to use it, not my design case.

[Altera_Forum]

--- Quote Start ---  No, the attachments are examples that gee gave to show me how to use it, not my design case.  --- Quote End ---     OK,  I assume that your paths are asynchronous. Is it possible that you post some of your Listed paths ? In case of the claasic timing analyzer you find them under tpd.  Kind regards  GPK

[Altera_Forum]

I wanted to supplement my previous remark regarding the reported pin-to-pin delay of 15 ns. For a pin driven by a short asynchronous logic path (through a single LE), I observe about 5 ns pin-to-pin delay with Cyclone II or III and 3.3V LVTTL IO standard. This delay is also indicated by Quartus timing simulation, and as I suppose by all other tools, that are using the same device data base, e. g. Pin Planner and Timing Analysator. 

 With MAX II, that is utilized by ccmkn, the basic pin-to-pin delay i slightly larger, about 7 ns, but far away from said 15 ns. Also the micro-timing parameters from MAX II datasheet are basically resulting in a similar delay amount.  When designing delay chains with cascaded LEs, you observe a rather uniform delay spacing around 0.5 ns within a single LAB. Advancing to the next LAB, larger steps of e.g. 1.5 ns can be seen. So the basic problem with the said TDC problem is the design of uniform delay chains across LAB boundaries, I think. Besides explicite assignment of LEs, it requires most likely partially parallel structures to get sufficient resolution during LAB boundary crossing.