Re: Re: Re: [casper] timing errors
Hi James, I probably learned about it. Thanks a lot. Best wishes, Yunpeng --- Yunpeng Men PhD student Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, Peking University Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China -原始邮件- 发件人:"James Smith" 发送时间:2017-06-05 22:19:34 (星期一) 收件人: "Vereese Van Tonder" 抄送: "门云鹏" , "Michael D'Cruze" , "casper@lists.berkeley.edu" 主题: Re: Re: [casper] timing errors Hello Yunpeng, Black boxing can help speed up compile time but the place-and-route needs to run every time, so it won't really help the design meet timing. In my experience that's the thing that takes long. Good luck. Regards, James On Mon, Jun 5, 2017 at 9:58 AM, Vereese Van Tonder wrote: Hi Yunpeng, You can try "Black Boxing" parts of your design, that you know works. There's a tutorial on the CASPER wiki here: https://casper.berkeley.edu/wiki/Tutorial_HDL_Black_Box I hope this helps. On Sun, Jun 4, 2017 at 4:43 AM, 门云鹏 wrote: Hi James, Michael, and Vereese, Thanks for your reply. I have read the timing report to find the failing paths, and tried to add delay blocks or increasing adder / multiplier latency. It works well but not always, especially for timing errors in some yellow blocks, for instance I will try SmartXplorer and PlanAead, and see if they work. What's more, the casper_xps toolflow often takes a few hours, which makes me crazy (>﹏<). I guess this is because timing constraints are difficult to meet. I wonder if there is any good method to accelerate the xps toolflow. (Map uses 2 processors, and par uses 4 processors by default. The cpu is @2.70GHz 8M) Thank you all again, Yunpeng --- Yunpeng Men PhD student Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, Peking University Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China -原始邮件- 发件人:"James Smith" 发送时间:2017-06-04 01:44:39 (星期日) 收件人: "Michael D'Cruze" 抄送: "门云鹏" , "casper@lists.berkeley.edu" 主题: Re: [casper] timing errors Hello Yunpeng, Just to echo what Michael and Vereese said - those tools can help you get a bit more insight into what's going on, and how badly your timing problem is, but the timing report should tell you how by how much you're missing timing (should be some nanosecond value). If it's just a small amount then sprinkling a few delay blocks in-between major sections of your design, or increasing adder / multiplier latency in your DSP blocks can usually help. Regards, James On Sat, Jun 3, 2017 at 6:54 PM, Michael D'Cruze wrote: Hi Yunpeng, all, I recently wrote a memo which describes how you can use Xilinx SmartXplorer to help with timing issues. Have a look on the casper wiki in the Memos section: https://casper.berkeley.edu/wiki/images/f/f8/SmartXplorer_memo.pdf . It isn’t a free pass – you need to get fairly close using knowledge of individual hardware types on the FPGA, and you need to space out your design reasonably, by using pipelines. But it should help get over the final hurdle if you’re doing a reasonable job initially. Best, Michael From:门云鹏 [mailto:yp...@pku.edu.cn] Sent: 03 June 2017 16:00 To:casper@lists.berkeley.edu Subject: [casper] timing errors Dear all, I am using ROACH2 to develop digital receiving backend, but I often encounter timing errors when I run casper_xps toolflow. I wonder if there is any general solution to these timing errors. Thanks a lot, Yunpeng --- Yunpeng Men PhD student Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, Peking University Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this gr
Re: Re: [casper] timing errors
Hello Yunpeng, Black boxing can help speed up compile time but the place-and-route needs to run every time, so it won't really help the design meet timing. In my experience that's the thing that takes long. Good luck. Regards, James On Mon, Jun 5, 2017 at 9:58 AM, Vereese Van Tonder wrote: > Hi Yunpeng, > > You can try "Black Boxing" parts of your design, that you know works. > There's a tutorial on the CASPER wiki here: > > https://casper.berkeley.edu/wiki/Tutorial_HDL_Black_Box > > I hope this helps. > > > On Sun, Jun 4, 2017 at 4:43 AM, 门云鹏 wrote: > >> Hi James, Michael, and Vereese, >> >> Thanks for your reply. I have read the timing report to find the failing >> paths, and tried to add delay blocks or increasing adder / multiplier >> latency. It works well but not always, especially for timing errors in some >> yellow blocks, for instance >> >> I will try SmartXplorer and PlanAead, and see if they work. >> >> What's more, the casper_xps toolflow often takes a few hours, which makes >> me crazy (>﹏<). I guess this is because timing constraints are difficult >> to meet. I wonder if there is any good method to accelerate the xps >> toolflow. (Map uses 2 processors, and par uses 4 processors by default. The >> cpu is @2.70GHz 8M) >> >> Thank you all again, >> >> Yunpeng >> >> >> >> >> --- >> Yunpeng Men >> PhD student >> Department of Astronomy & Kavli Institute for Astronomy and >> Astrophysics, Peking University >> Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China >> >> -原始邮件- >> *发件人:*"James Smith" >> *发送时间:*2017-06-04 01:44:39 (星期日) >> *收件人:* "Michael D'Cruze" >> *抄送:* "门云鹏" , "casper@lists.berkeley.edu" < >> casper@lists.berkeley.edu> >> *主题:* Re: [casper] timing errors >> >> >> Hello Yunpeng, >> >> Just to echo what Michael and Vereese said - those tools can help you get >> a bit more insight into what's going on, and how badly your timing problem >> is, but the timing report should tell you how by how much you're missing >> timing (should be some nanosecond value). >> >> If it's just a small amount then sprinkling a few delay blocks in-between >> major sections of your design, or increasing adder / multiplier latency in >> your DSP blocks can usually help. >> >> Regards, >> James >> >> >> On Sat, Jun 3, 2017 at 6:54 PM, Michael D'Cruze < >> michael.dcr...@postgrad.manchester.ac.uk> wrote: >> >>> Hi Yunpeng, all, >>> >>> >>> >>> I recently wrote a memo which describes how you can use Xilinx >>> SmartXplorer to help with timing issues. Have a look on the casper wiki in >>> the Memos section: https://casper.berkeley.edu/wi >>> ki/images/f/f8/SmartXplorer_memo.pdf . It isn’t a free pass – you need >>> to get fairly close using knowledge of individual hardware types on the >>> FPGA, and you need to space out your design reasonably, by using pipelines. >>> But it should help get over the final hurdle if you’re doing a reasonable >>> job initially. >>> >>> >>> >>> Best, >>> >>> Michael >>> >>> >>> >>> *From:* 门云鹏 [mailto:yp...@pku.edu.cn] >>> *Sent:* 03 June 2017 16:00 >>> *To:* casper@lists.berkeley.edu >>> *Subject:* [casper] timing errors >>> >>> >>> >>> Dear all, >>> >>> I am using ROACH2 to develop digital receiving backend, but I often >>> encounter timing errors when I run casper_xps toolflow. I wonder if there >>> is any general solution to these timing errors. >>> >>> Thanks a lot, >>> >>> Yunpeng >>> >>> >>> >>> >>> --- >>> >>> Yunpeng Men >>> >>> PhD student >>> >>> Department of Astronomy & Kavli Institute for Astronomy and >>> Astrophysics, Peking University >>> >>> Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from i
Re: Re: [casper] timing errors
Hi Yunpeng, You can try "Black Boxing" parts of your design, that you know works. There's a tutorial on the CASPER wiki here: https://casper.berkeley.edu/wiki/Tutorial_HDL_Black_Box I hope this helps. On Sun, Jun 4, 2017 at 4:43 AM, 门云鹏 wrote: > Hi James, Michael, and Vereese, > > Thanks for your reply. I have read the timing report to find the failing > paths, and tried to add delay blocks or increasing adder / multiplier > latency. It works well but not always, especially for timing errors in some > yellow blocks, for instance > > I will try SmartXplorer and PlanAead, and see if they work. > > What's more, the casper_xps toolflow often takes a few hours, which makes > me crazy (>﹏<). I guess this is because timing constraints are difficult > to meet. I wonder if there is any good method to accelerate the xps > toolflow. (Map uses 2 processors, and par uses 4 processors by default. The > cpu is @2.70GHz 8M) > > Thank you all again, > > Yunpeng > > > > > --- > Yunpeng Men > PhD student > Department of Astronomy & Kavli Institute for Astronomy and > Astrophysics, Peking University > Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China > > -原始邮件- > *发件人:*"James Smith" > *发送时间:*2017-06-04 01:44:39 (星期日) > *收件人:* "Michael D'Cruze" > *抄送:* "门云鹏" , "casper@lists.berkeley.edu" < > casper@lists.berkeley.edu> > *主题:* Re: [casper] timing errors > > > Hello Yunpeng, > > Just to echo what Michael and Vereese said - those tools can help you get > a bit more insight into what's going on, and how badly your timing problem > is, but the timing report should tell you how by how much you're missing > timing (should be some nanosecond value). > > If it's just a small amount then sprinkling a few delay blocks in-between > major sections of your design, or increasing adder / multiplier latency in > your DSP blocks can usually help. > > Regards, > James > > > On Sat, Jun 3, 2017 at 6:54 PM, Michael D'Cruze manchester.ac.uk> wrote: > >> Hi Yunpeng, all, >> >> >> >> I recently wrote a memo which describes how you can use Xilinx >> SmartXplorer to help with timing issues. Have a look on the casper wiki in >> the Memos section: https://casper.berkeley.edu/wi >> ki/images/f/f8/SmartXplorer_memo.pdf . It isn’t a free pass – you need >> to get fairly close using knowledge of individual hardware types on the >> FPGA, and you need to space out your design reasonably, by using pipelines. >> But it should help get over the final hurdle if you’re doing a reasonable >> job initially. >> >> >> >> Best, >> >> Michael >> >> >> >> *From:* 门云鹏 [mailto:yp...@pku.edu.cn] >> *Sent:* 03 June 2017 16:00 >> *To:* casper@lists.berkeley.edu >> *Subject:* [casper] timing errors >> >> >> >> Dear all, >> >> I am using ROACH2 to develop digital receiving backend, but I often >> encounter timing errors when I run casper_xps toolflow. I wonder if there is >> any general solution to these timing errors. >> >> Thanks a lot, >> >> Yunpeng >> >> >> >> >> --- >> >> Yunpeng Men >> >> PhD student >> >> Department of Astronomy & Kavli Institute for Astronomy and >> Astrophysics, Peking University >> >> Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- Kind Regards, Vereesé -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: Re: [casper] timing errors
Hi James, Michael, and Vereese, Thanks for your reply. I have read the timing report to find the failing paths, and tried to add delay blocks or increasing adder / multiplier latency. It works well but not always, especially for timing errors in some yellow blocks, for instance I will try SmartXplorer and PlanAead, and see if they work. What's more, the casper_xps toolflow often takes a few hours, which makes me crazy (>﹏<). I guess this is because timing constraints are difficult to meet. I wonder if there is any good method to accelerate the xps toolflow. (Map uses 2 processors, and par uses 4 processors by default. The cpu is @2.70GHz 8M) Thank you all again, Yunpeng --- Yunpeng Men PhD student Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, Peking University Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China -原始邮件- 发件人:"James Smith" 发送时间:2017-06-04 01:44:39 (星期日) 收件人: "Michael D'Cruze" 抄送: "门云鹏" , "casper@lists.berkeley.edu" 主题: Re: [casper] timing errors Hello Yunpeng, Just to echo what Michael and Vereese said - those tools can help you get a bit more insight into what's going on, and how badly your timing problem is, but the timing report should tell you how by how much you're missing timing (should be some nanosecond value). If it's just a small amount then sprinkling a few delay blocks in-between major sections of your design, or increasing adder / multiplier latency in your DSP blocks can usually help. Regards, James On Sat, Jun 3, 2017 at 6:54 PM, Michael D'Cruze wrote: Hi Yunpeng, all, I recently wrote a memo which describes how you can use Xilinx SmartXplorer to help with timing issues. Have a look on the casper wiki in the Memos section: https://casper.berkeley.edu/wiki/images/f/f8/SmartXplorer_memo.pdf . It isn’t a free pass – you need to get fairly close using knowledge of individual hardware types on the FPGA, and you need to space out your design reasonably, by using pipelines. But it should help get over the final hurdle if you’re doing a reasonable job initially. Best, Michael From:门云鹏 [mailto:yp...@pku.edu.cn] Sent: 03 June 2017 16:00 To:casper@lists.berkeley.edu Subject: [casper] timing errors Dear all, I am using ROACH2 to develop digital receiving backend, but I often encounter timing errors when I run casper_xps toolflow. I wonder if there is any general solution to these timing errors. Thanks a lot, Yunpeng --- Yunpeng Men PhD student Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, Peking University Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] timing errors
Hello Yunpeng, Just to echo what Michael and Vereese said - those tools can help you get a bit more insight into what's going on, and how badly your timing problem is, but the timing report should tell you how by how much you're missing timing (should be some nanosecond value). If it's just a small amount then sprinkling a few delay blocks in-between major sections of your design, or increasing adder / multiplier latency in your DSP blocks can usually help. Regards, James On Sat, Jun 3, 2017 at 6:54 PM, Michael D'Cruze < michael.dcr...@postgrad.manchester.ac.uk> wrote: > Hi Yunpeng, all, > > > > I recently wrote a memo which describes how you can use Xilinx > SmartXplorer to help with timing issues. Have a look on the casper wiki in > the Memos section: https://casper.berkeley.edu/ > wiki/images/f/f8/SmartXplorer_memo.pdf . It isn’t a free pass – you need > to get fairly close using knowledge of individual hardware types on the > FPGA, and you need to space out your design reasonably, by using pipelines. > But it should help get over the final hurdle if you’re doing a reasonable > job initially. > > > > Best, > > Michael > > > > *From:* 门云鹏 [mailto:yp...@pku.edu.cn] > *Sent:* 03 June 2017 16:00 > *To:* casper@lists.berkeley.edu > *Subject:* [casper] timing errors > > > > Dear all, > > I am using ROACH2 to develop digital receiving backend, but I often encounter > timing errors when I run casper_xps toolflow. I wonder if there is any > general solution to these timing errors. > > Thanks a lot, > > Yunpeng > > > > > --- > > Yunpeng Men > > PhD student > > Department of Astronomy & Kavli Institute for Astronomy and > Astrophysics, Peking University > > Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
RE: [casper] timing errors
Hi Yunpeng, all, I recently wrote a memo which describes how you can use Xilinx SmartXplorer to help with timing issues. Have a look on the casper wiki in the Memos section: https://casper.berkeley.edu/wiki/images/f/f8/SmartXplorer_memo.pdf . It isn’t a free pass – you need to get fairly close using knowledge of individual hardware types on the FPGA, and you need to space out your design reasonably, by using pipelines. But it should help get over the final hurdle if you’re doing a reasonable job initially. Best, Michael From: 门云鹏 [mailto:yp...@pku.edu.cn] Sent: 03 June 2017 16:00 To: casper@lists.berkeley.edu Subject: [casper] timing errors Dear all, I am using ROACH2 to develop digital receiving backend, but I often encounter timing errors when I run casper_xps toolflow. I wonder if there is any general solution to these timing errors. Thanks a lot, Yunpeng --- Yunpeng Men PhD student Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, Peking University Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu<mailto:casper+unsubscr...@lists.berkeley.edu>. To post to this group, send email to casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>. -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] timing errors
Hi Yunpeng, You can use Xilinx's PlanAead tool to help with the timing errors. You can place your PFB in a "pblock" which helps with timing. I haven't worked with this in awhile but there's a tutorial on the CASPER wiki here: https://casper.berkeley.edu/wiki/Tutorial_PlanAhead I hope that helps Vereese On Sat, 03 Jun 2017 at 5:00 PM 门云鹏 wrote: > Dear all, > > I am using ROACH2 to develop digital receiving backend, but I often encounter > timing errors when I run casper_xps toolflow. I wonder if there is any > general solution to these timing errors. > > Thanks a lot, > > Yunpeng > > > > --- > Yunpeng Men > PhD student > Department of Astronomy & Kavli Institute for Astronomy and > Astrophysics, Peking University > Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- Kind Regards, Vereesé -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
[casper] timing errors
Dear all,I am using ROACH2 to develop digital receiving backend, but I often encounter timing errors when I run casper_xps toolflow. I wonder if there is any general solution to these timing errors.Thanks a lot,Yunpeng --- Yunpeng Men PhD student Department of Astronomy & Kavli Institute for Astronomy and Astrophysics, Peking University Yi He Yuan Lu 5, Hai Dian Qu, Beijing 100871, P. R. China -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
Re: [casper] Timing Errors ROACH2
Assuming that the pblock is not overlapping with any other pblocks, and that you have not constrained any other resources in the pblock, I have used 99% of the resources in a pblock (simply made it as small as possible). The trouble comes into play when there are resources which are not in the pblock, but also somehow constrained in the region. If my errors are especially egregious, I'll often relax my timing constraints, try to close timing at a lower speed, and then increase the goal once it becomes more reasonable. The tools really do not handle failing constraints miserably very well. Cheers, -Ryan On 11/09/2015 07:40 AM, Amit Bansod wrote: Hi Ryan, I could get rid of those errors but the tool had hard time in placing with huge setup timing errors. How much utilization is good to set on p-blocks ? Currently, I had 60-70% for different components. Cheers, Amit On 05-Nov-15 9:46 AM, Ryan Monroe wrote: Hi Amit, FYI, I am CC'ing the CASPER list on all of these emails, so that they can be searchable for people in the future. The placements I gave you were for my personal design, and may not work for yours. When choosing pblock size, be sure to look at the pblock utilization in planahead. odds are that you had either 1. a pblock which was outright too small for the components placed within (tools error out almost instantly) 2. multiple overlapping pblocks, in such a way that it's impossible to satisfy both constraints simultaneously (tools error out after much longer). pblock statistics don't help with this one, but you can bash it out by hand with more difficulty. look at the error from line 327-561 on your report. this indicates the constraints which caused the issue, as well as some of the components involved. that's a good place to start! --Ryan On 11/05/2015 12:20 AM, aban...@mpifr-bonn.mpg.de wrote: Hi Ryan, I tried to place the 10gbe pblocks as you suggested. Unfortunately, the tool was unable to place all components. The pblock statistics were more than enough. Do you know how to avoid this problem ? The tool took long time to give out errors (~11 hrs). I have enclosed the map report. Regards, Amit On 04.11.2015 09:37, Ryan Monroe wrote: np! the 10gbe core wasn't really intended to run at fast clock rates. Be sure to constrain it to the east-ish side of the chip, this is almost either a 1. device utilization issue (you are trying to do too much stuff on the chip), or 2. placement issue (probably this)-- the tools are terrible at placing things in the right spots Send me any questions you have, but I'm pretty busy and reserve the right to be bad about answering ;-) --Ryan On 11/04/2015 12:32 AM, Amit Bansod wrote: Hi Ryan, Thanks a lot! I will give this a try! Cheers, Amit On 04-Nov-15 9:31 AM, Ryan Monroe wrote: Dear Amit, Please consider my memo 50 on the CASPER list: "Performance optimization for Virtex 6 CASPER designs" [1] As it turns out, I have a design open right now, which must close 8 10gbe cores at 312.5 mhz. Attached is an image of where I placed my tge_tx_inst and tge_rx_inst pblocks, which I hope will be helpful for you. Wish I had time to do more for you, but such is life :-/ Cheers! --Ryan Monroe [1] https://casper.berkeley.edu/wiki/Memos On 11/04/2015 12:17 AM, aban...@mpifr-bonn.mpg.de wrote: Dear All, I am getting following timing errors on 10GbE yellow blocks which I am finding it hard to get rid off. I am running my design at 200 MHz. I have given the device utilization summary if it is useful. I have also enclosed the files. Best Regards, Amit Timing Errors: Timing constraint: PERIOD analysis for net "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ mmcm_clkout1" derived from PERIOD analysis for net "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ adc_clk_div" derived from NET "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/adc_clk" PERIOD = 2.5 ns HIGH 50%; multiplied by 2.00 to 5 nS and duty cycle corrected to HIGH 2.500 nS For more information, see Period Analysis in the Timing Closure User Guide (UG612). 1594959 paths analyzed, 343705 endpoints analyzed, 63 failing endpoints 63 timing errors detected. (63 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 5.727ns. Slack: -0.727ns (requirement - (data path - clock path skew + uncertainty)) Source: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR (FF) Destination: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP (RAM) Requirement: 5.000ns Data Path Delay: 5.721ns (Levels of Logic = 1) Clock Path
Re: [casper] Timing Errors ROACH2
Hi Ryan, I could get rid of those errors but the tool had hard time in placing with huge setup timing errors. How much utilization is good to set on p-blocks ? Currently, I had 60-70% for different components. Cheers, Amit On 05-Nov-15 9:46 AM, Ryan Monroe wrote: > Hi Amit, > > FYI, I am CC'ing the CASPER list on all of these emails, so that they > can be searchable for people in the future. > > The placements I gave you were for my personal design, and may not work > for yours. When choosing pblock size, be sure to look at the pblock > utilization in planahead. odds are that you had either > 1. a pblock which was outright too small for the components placed > within (tools error out almost instantly) > 2. multiple overlapping pblocks, in such a way that it's impossible to > satisfy both constraints simultaneously (tools error out after much > longer). pblock statistics don't help with this one, but you can bash > it out by hand with more difficulty. > > look at the error from line 327-561 on your report. this indicates the > constraints which caused the issue, as well as some of the components > involved. that's a good place to start! > > --Ryan > > On 11/05/2015 12:20 AM, aban...@mpifr-bonn.mpg.de wrote: >> Hi Ryan, >> >> I tried to place the 10gbe pblocks as you suggested. Unfortunately, >> the tool was unable to place all components. The pblock statistics >> were more than enough. Do you know how to avoid this problem ? The >> tool took long time to give out errors (~11 hrs). >> >> I have enclosed the map report. >> >> Regards, >> Amit >> >> On 04.11.2015 09:37, Ryan Monroe wrote: >>> np! the 10gbe core wasn't really intended to run at fast clock >>> rates. Be sure to constrain it to the east-ish side of the chip, this >>> is almost either a >>> 1. device utilization issue (you are trying to do too much stuff on >>> the chip), or >>> 2. placement issue (probably this)-- the tools are terrible at >>> placing things in the right spots >>> >>> Send me any questions you have, but I'm pretty busy and reserve the >>> right to be bad about answering ;-) >>> >>> --Ryan >>> >>> >>> >>> On 11/04/2015 12:32 AM, Amit Bansod wrote: Hi Ryan, Thanks a lot! I will give this a try! Cheers, Amit On 04-Nov-15 9:31 AM, Ryan Monroe wrote: > Dear Amit, > > Please consider my memo 50 on the CASPER list: "Performance > optimization > for Virtex 6 CASPER designs" [1] > > As it turns out, I have a design open right now, which must close 8 > 10gbe cores at 312.5 mhz. Attached is an image of where I placed my > tge_tx_inst and tge_rx_inst pblocks, which I hope will be helpful for > you. Wish I had time to do more for you, but such is life :-/ > > Cheers! > > --Ryan Monroe > > [1] https://casper.berkeley.edu/wiki/Memos > > On 11/04/2015 12:17 AM, aban...@mpifr-bonn.mpg.de wrote: >> Dear All, >> >> I am getting following timing errors on 10GbE yellow blocks which >> I am >> finding it hard to get rid off. I am running my design at 200 MHz. I >> have given the device utilization summary if it is useful. I have >> also >> enclosed the files. >> >> Best Regards, >> Amit >> >> Timing Errors: >> Timing constraint: PERIOD analysis for net >> "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ >> mmcm_clkout1" derived from PERIOD analysis for net >> "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ >> adc_clk_div" derived from NET >> >> >> "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/adc_clk" >> >> >> PERIOD = 2.5 ns HIGH 50%; multiplied by 2.00 to 5 nS and duty >> cycle >> corrected to HIGH 2.500 nS >> For more information, see Period Analysis in the Timing Closure >> User >> Guide (UG612). >> >>1594959 paths analyzed, 343705 endpoints analyzed, 63 failing >> endpoints >>63 timing errors detected. (63 setup errors, 0 hold errors, 0 >> component switching limit errors) >>Minimum period is 5.727ns. >> >> >> >> >> >> Slack: -0.727ns (requirement - (data path - clock >> path skew + uncertainty)) >> Source: >> >> d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR >> >> (FF) >> Destination: >> >> d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP >> >> (RAM) >> Requirement: 5.000ns >> Data Path Delay: 5.721ns (Levels of Logic = 1) >> Clock Path Skew: 0.054ns (2.112 - 2.058) >>
Re: [casper] Timing Errors ROACH2
Hi Amit, FYI, I am CC'ing the CASPER list on all of these emails, so that they can be searchable for people in the future. The placements I gave you were for my personal design, and may not work for yours. When choosing pblock size, be sure to look at the pblock utilization in planahead. odds are that you had either 1. a pblock which was outright too small for the components placed within (tools error out almost instantly) 2. multiple overlapping pblocks, in such a way that it's impossible to satisfy both constraints simultaneously (tools error out after much longer). pblock statistics don't help with this one, but you can bash it out by hand with more difficulty. look at the error from line 327-561 on your report. this indicates the constraints which caused the issue, as well as some of the components involved. that's a good place to start! --Ryan On 11/05/2015 12:20 AM, aban...@mpifr-bonn.mpg.de wrote: Hi Ryan, I tried to place the 10gbe pblocks as you suggested. Unfortunately, the tool was unable to place all components. The pblock statistics were more than enough. Do you know how to avoid this problem ? The tool took long time to give out errors (~11 hrs). I have enclosed the map report. Regards, Amit On 04.11.2015 09:37, Ryan Monroe wrote: np! the 10gbe core wasn't really intended to run at fast clock rates. Be sure to constrain it to the east-ish side of the chip, this is almost either a 1. device utilization issue (you are trying to do too much stuff on the chip), or 2. placement issue (probably this)-- the tools are terrible at placing things in the right spots Send me any questions you have, but I'm pretty busy and reserve the right to be bad about answering ;-) --Ryan On 11/04/2015 12:32 AM, Amit Bansod wrote: Hi Ryan, Thanks a lot! I will give this a try! Cheers, Amit On 04-Nov-15 9:31 AM, Ryan Monroe wrote: Dear Amit, Please consider my memo 50 on the CASPER list: "Performance optimization for Virtex 6 CASPER designs" [1] As it turns out, I have a design open right now, which must close 8 10gbe cores at 312.5 mhz. Attached is an image of where I placed my tge_tx_inst and tge_rx_inst pblocks, which I hope will be helpful for you. Wish I had time to do more for you, but such is life :-/ Cheers! --Ryan Monroe [1] https://casper.berkeley.edu/wiki/Memos On 11/04/2015 12:17 AM, aban...@mpifr-bonn.mpg.de wrote: Dear All, I am getting following timing errors on 10GbE yellow blocks which I am finding it hard to get rid off. I am running my design at 200 MHz. I have given the device utilization summary if it is useful. I have also enclosed the files. Best Regards, Amit Timing Errors: Timing constraint: PERIOD analysis for net "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ mmcm_clkout1" derived from PERIOD analysis for net "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ adc_clk_div" derived from NET "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/adc_clk" PERIOD = 2.5 ns HIGH 50%; multiplied by 2.00 to 5 nS and duty cycle corrected to HIGH 2.500 nS For more information, see Period Analysis in the Timing Closure User Guide (UG612). 1594959 paths analyzed, 343705 endpoints analyzed, 63 failing endpoints 63 timing errors detected. (63 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 5.727ns. Slack: -0.727ns (requirement - (data path - clock path skew + uncertainty)) Source: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR (FF) Destination: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP (RAM) Requirement: 5.000ns Data Path Delay: 5.721ns (Levels of Logic = 1) Clock Path Skew: 0.054ns (2.112 - 2.058) Source Clock: adc0_clk rising at 0.000ns Destination Clock:adc0_clk rising at 5.000ns Clock Uncertainty:0.060ns Clock Uncertainty: 0.060ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.070ns Discrete Jitter (DJ): 0.097ns Phase Error (PE): 0.000ns Maximum Data Path at Slow Process Corner: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR to d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP LocationDelay type Delay(ns) Physical Resource Logical Resource(s)
Re: [casper] Timing Errors ROACH2
np! the 10gbe core wasn't really intended to run at fast clock rates. Be sure to constrain it to the east-ish side of the chip, this is probably either a 1. device utilization issue (you are trying to do too much stuff on the chip), or 2. placement issue (probably this)-- the tools are terrible at placing things in the right spots Send me any questions you have, but I'm pretty busy and reserve the right to be bad about answering --Ryan On 11/04/2015 12:32 AM, Amit Bansod wrote: Hi Ryan, Thanks a lot! I will give this a try! Cheers, Amit On 04-Nov-15 9:31 AM, Ryan Monroe wrote: Dear Amit, Please consider my memo 50 on the CASPER list: "Performance optimization for Virtex 6 CASPER designs" [1] As it turns out, I have a design open right now, which must close 8 10gbe cores at 312.5 mhz. Attached is an image of where I placed my tge_tx_inst and tge_rx_inst pblocks, which I hope will be helpful for you. Wish I had time to do more for you, but such is life :-/ Cheers! --Ryan Monroe [1] https://casper.berkeley.edu/wiki/Memos On 11/04/2015 12:17 AM, aban...@mpifr-bonn.mpg.de wrote: Dear All, I am getting following timing errors on 10GbE yellow blocks which I am finding it hard to get rid off. I am running my design at 200 MHz. I have given the device utilization summary if it is useful. I have also enclosed the files. Best Regards, Amit Timing Errors: Timing constraint: PERIOD analysis for net "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ mmcm_clkout1" derived from PERIOD analysis for net "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/ adc_clk_div" derived from NET "d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/adc_clk" PERIOD = 2.5 ns HIGH 50%; multiplied by 2.00 to 5 nS and duty cycle corrected to HIGH 2.500 nS For more information, see Period Analysis in the Timing Closure User Guide (UG612). 1594959 paths analyzed, 343705 endpoints analyzed, 63 failing endpoints 63 timing errors detected. (63 setup errors, 0 hold errors, 0 component switching limit errors) Minimum period is 5.727ns. Slack: -0.727ns (requirement - (data path - clock path skew + uncertainty)) Source: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR (FF) Destination: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP (RAM) Requirement: 5.000ns Data Path Delay: 5.721ns (Levels of Logic = 1) Clock Path Skew: 0.054ns (2.112 - 2.058) Source Clock: adc0_clk rising at 0.000ns Destination Clock:adc0_clk rising at 5.000ns Clock Uncertainty:0.060ns Clock Uncertainty: 0.060ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.070ns Discrete Jitter (DJ): 0.097ns Phase Error (PE): 0.000ns Maximum Data Path at Slow Process Corner: d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR to d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP LocationDelay type Delay(ns) Physical Resource Logical Resource(s) --- SLICE_X81Y192.CQTcko 0.337 d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR SLICE_X23Y278.A6net (fanout=5)4.173 d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR SLICE_X23Y278.A Tilo 0.068 d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/ram_wr_en d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/gl0.wr/ram_wr_en_i1 RAMB36_X1Y54.WEAU3 net (fanout=16) 0.628 d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/ram_wr_en RAMB36_X1Y54.CLKARDCLKU Trcck_WEA 0.515 d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.
Re: [casper] Timing errors and subsystems
wow. Thanks a lot Jack! Paul On 01/30/2014 10:15 AM, Jack Hickish wrote: I've toyed with Planahead a bit, and quickly found I was in way over my head. Could you recommend a good starting point for learning this tool? I'm sure you've found the planahead user guide, which is a bit of a documentation behemoth, but useful if you have a vague idea of what setting you're trying to change and just want to find the right thing to click. There's a reasonable "quick" intro here -- http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/PlanAhead_Tutorial_Quick_Front-to-Back_Overview.pdf And in general a bunch of tutorials: http://www.xilinx.com/support/index.html/content/xilinx/en/supportNav/design_tools/planahead.html A couple of potentially handy methodology guides are also available for floorplanning: http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/Floorplanning_Methodology_Guide.pdf And planahead in general: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/PlanAhead_Methodology_Guide_11_1.pdf (there's probably a more up to date version of this but i haven't stumbled on it yet) These are all much shorter than the full user guide, and might help give a better overview of what's going on. Ryan Monroe also wrote a summary of some work he did to optimize a ROACH2 design which he posted on the maillist a while ago: https://dl.dropboxusercontent.com/u/2832602/roach2_timing.zip And there's a very brief overview on the wiki -- https://casper.berkeley.edu/wiki/Speed_Optimization_with_PlanAhead I think some combination of these documents and experimentation is probably as good a start as any. I'd recommend starting with the planahead overview, and go from there [with the caveat that I count myself only marginally proficient with planahead, so ymmv]. Good luck! Jack Cheers, Jack On 30 January 2014 11:57, Paul Marganian wrote: Thanks Jack and John, Yes, wtf was certainly the first TLA that came to mind :) Well, I took my test model and changed the name of a subsystem, and after compiling, the number of timing errors went from 153 to 151. Obviously not a significant change, but the mere fact that they changed at all lends me to believe that the algorithm's start seed has indeed been changed. Is this seed at all exposed in any of the configuration files? In other words, is there a way to roll the dice and see if you can get a better timing score by simply changing this seed and compiling again? Thanks for your help, Paul On 01/29/2014 06:07 PM, Jack Hickish wrote: I'm not sure what, if any, difference a subsystem will make to the mapped design (I thought none), but I believe it's the case that changing module names etc. can affect the place and route algorithm's start seed. I seem to remember seeing this mentioned in a Xilinx doc under the heading "I've saved my project under a different name, now it won't meet timing, wtf?!" On 29 January 2014 22:44, John Ford wrote: On 01/29/2014 01:03 PM, Paul Marganian wrote: Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. Try saving the model and compiling it again, just changing a comment or something else non-substantive. John thanks Paul Marganian NRAO, Green Bank
Re: [casper] Timing errors and subsystems
> I've toyed with Planahead a bit, and quickly found I was in way over my > head. Could you recommend a good starting point for learning this tool? I'm sure you've found the planahead user guide, which is a bit of a documentation behemoth, but useful if you have a vague idea of what setting you're trying to change and just want to find the right thing to click. There's a reasonable "quick" intro here -- http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/PlanAhead_Tutorial_Quick_Front-to-Back_Overview.pdf And in general a bunch of tutorials: http://www.xilinx.com/support/index.html/content/xilinx/en/supportNav/design_tools/planahead.html A couple of potentially handy methodology guides are also available for floorplanning: http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/Floorplanning_Methodology_Guide.pdf And planahead in general: http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/PlanAhead_Methodology_Guide_11_1.pdf (there's probably a more up to date version of this but i haven't stumbled on it yet) These are all much shorter than the full user guide, and might help give a better overview of what's going on. Ryan Monroe also wrote a summary of some work he did to optimize a ROACH2 design which he posted on the maillist a while ago: https://dl.dropboxusercontent.com/u/2832602/roach2_timing.zip And there's a very brief overview on the wiki -- https://casper.berkeley.edu/wiki/Speed_Optimization_with_PlanAhead I think some combination of these documents and experimentation is probably as good a start as any. I'd recommend starting with the planahead overview, and go from there [with the caveat that I count myself only marginally proficient with planahead, so ymmv]. Good luck! Jack > > >> Cheers, >> Jack >> >> On 30 January 2014 11:57, Paul Marganian wrote: >>> >>> Thanks Jack and John, >>> Yes, wtf was certainly the first TLA that came to mind :) >>> >>> Well, I took my test model and changed the name of a subsystem, and after >>> compiling, the number of timing errors went from 153 to 151. Obviously >>> not a >>> significant change, but the mere fact that they changed at all lends me >>> to >>> believe that the algorithm's start seed has indeed been changed. >>> >>> Is this seed at all exposed in any of the configuration files? In other >>> words, is there a way to roll the dice and see if you can get a better >>> timing score by simply changing this seed and compiling again? >>> >>> Thanks for your help, >>> Paul >>> >>> >>> On 01/29/2014 06:07 PM, Jack Hickish wrote: I'm not sure what, if any, difference a subsystem will make to the mapped design (I thought none), but I believe it's the case that changing module names etc. can affect the place and route algorithm's start seed. I seem to remember seeing this mentioned in a Xilinx doc under the heading "I've saved my project under a different name, now it won't meet timing, wtf?!" On 29 January 2014 22:44, John Ford wrote: >> >> On 01/29/2014 01:03 PM, Paul Marganian wrote: >>> >>> Hi all, >>> Should such software (simulink) features as subsystems and and gotos >>> have any affect on the final circuit created when I build my bof >>> file? >>> >>> I am compiling models on Roach I that use almost all of the available >>> Logic Slices (~97%). That the subsequent build should contain timing >>> errors is not a surprise, but I recently noted a change in my timing >>> errors that puzzled me. >>> >>> I have assumed up till now that certain types of features in my model >>> are superficial, and will not change how the bof file is built. I >>> wanted to test this theory, and rebuilt my model after selecting part >>> of my model and turning it into a subsystem. I was surprised to see >>> that this new build had very different timing errors then the >>> previous >>> one (from 18 errors to just 3). >>> >>> Is it the subsystem that caused this change, or is another one of my >>> assumptions, that timing errors are deterministic and can be >>> reproduced with subsequent builds of identical models, false? >> >> I've made a test of this, and indeed, I think my assumption is >> correct: >> I get the same timing errors after two subsequent builds. > > Try saving the model and compiling it again, just changing a comment or > something else non-substantive. > > John > >>> thanks >>> Paul Marganian >>> NRAO, Green Bank >>> >>> > >
Re: [casper] Timing errors and subsystems
On 01/30/2014 07:33 AM, Jack Hickish wrote: Hi Paul, I believe the "placement cost table" is the parameter you want to change (See http://www.xilinx.com/support/answers/35534.html). You should be able to change this and other compile parameters in xps_base/XPS_ROACH[2]_base/etc/fast_runtime.opt Thanks Jack! There's a lot for me there to sink my teeth into. I'll check it out. I did a few more experiments which I believe confirms what you've been telling me: * changing a subsystem name changes results * replacing an edge with gotos does *not* cause changes * adding a random comment does *not* cause changes You might find that you get on better changing the effort/optimization settings than the starting placer cost table. I'd be interested to hear any changes which you find particularly useful. FWIW, I would just import a compile into planahead, and vary the options from there. Then you can save the different strategies and keep track of which ones work (and have a nice gui to tell you what the options actually do). You can also spawn multiple compiles with different options (on multiple servers, if you have them), for when things get *really* desperate... I've toyed with Planahead a bit, and quickly found I was in way over my head. Could you recommend a good starting point for learning this tool? Cheers, Jack On 30 January 2014 11:57, Paul Marganian wrote: Thanks Jack and John, Yes, wtf was certainly the first TLA that came to mind :) Well, I took my test model and changed the name of a subsystem, and after compiling, the number of timing errors went from 153 to 151. Obviously not a significant change, but the mere fact that they changed at all lends me to believe that the algorithm's start seed has indeed been changed. Is this seed at all exposed in any of the configuration files? In other words, is there a way to roll the dice and see if you can get a better timing score by simply changing this seed and compiling again? Thanks for your help, Paul On 01/29/2014 06:07 PM, Jack Hickish wrote: I'm not sure what, if any, difference a subsystem will make to the mapped design (I thought none), but I believe it's the case that changing module names etc. can affect the place and route algorithm's start seed. I seem to remember seeing this mentioned in a Xilinx doc under the heading "I've saved my project under a different name, now it won't meet timing, wtf?!" On 29 January 2014 22:44, John Ford wrote: On 01/29/2014 01:03 PM, Paul Marganian wrote: Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. Try saving the model and compiling it again, just changing a comment or something else non-substantive. John thanks Paul Marganian NRAO, Green Bank
Re: [casper] Timing errors and subsystems
Hi Paul, I believe the "placement cost table" is the parameter you want to change (See http://www.xilinx.com/support/answers/35534.html). You should be able to change this and other compile parameters in xps_base/XPS_ROACH[2]_base/etc/fast_runtime.opt You might find that you get on better changing the effort/optimization settings than the starting placer cost table. I'd be interested to hear any changes which you find particularly useful. FWIW, I would just import a compile into planahead, and vary the options from there. Then you can save the different strategies and keep track of which ones work (and have a nice gui to tell you what the options actually do). You can also spawn multiple compiles with different options (on multiple servers, if you have them), for when things get *really* desperate... Cheers, Jack On 30 January 2014 11:57, Paul Marganian wrote: > Thanks Jack and John, > Yes, wtf was certainly the first TLA that came to mind :) > > Well, I took my test model and changed the name of a subsystem, and after > compiling, the number of timing errors went from 153 to 151. Obviously not a > significant change, but the mere fact that they changed at all lends me to > believe that the algorithm's start seed has indeed been changed. > > Is this seed at all exposed in any of the configuration files? In other > words, is there a way to roll the dice and see if you can get a better > timing score by simply changing this seed and compiling again? > > Thanks for your help, > Paul > > > On 01/29/2014 06:07 PM, Jack Hickish wrote: >> >> I'm not sure what, if any, difference a subsystem will make to the >> mapped design (I thought none), but I believe it's the case that >> changing module names etc. can affect the place and route algorithm's >> start seed. I seem to remember seeing this mentioned in a Xilinx doc >> under the heading "I've saved my project under a different name, now >> it won't meet timing, wtf?!" >> >> >> >> On 29 January 2014 22:44, John Ford wrote: On 01/29/2014 01:03 PM, Paul Marganian wrote: > > Hi all, > Should such software (simulink) features as subsystems and and gotos > have any affect on the final circuit created when I build my bof file? > > I am compiling models on Roach I that use almost all of the available > Logic Slices (~97%). That the subsequent build should contain timing > errors is not a surprise, but I recently noted a change in my timing > errors that puzzled me. > > I have assumed up till now that certain types of features in my model > are superficial, and will not change how the bof file is built. I > wanted to test this theory, and rebuilt my model after selecting part > of my model and turning it into a subsystem. I was surprised to see > that this new build had very different timing errors then the previous > one (from 18 errors to just 3). > > Is it the subsystem that caused this change, or is another one of my > assumptions, that timing errors are deterministic and can be > reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. >>> >>> Try saving the model and compiling it again, just changing a comment or >>> something else non-substantive. >>> >>> John >>> > thanks > Paul Marganian > NRAO, Green Bank > > >>> >>> >
Re: [casper] Timing errors and subsystems
Thanks Jack and John, Yes, wtf was certainly the first TLA that came to mind :) Well, I took my test model and changed the name of a subsystem, and after compiling, the number of timing errors went from 153 to 151. Obviously not a significant change, but the mere fact that they changed at all lends me to believe that the algorithm's start seed has indeed been changed. Is this seed at all exposed in any of the configuration files? In other words, is there a way to roll the dice and see if you can get a better timing score by simply changing this seed and compiling again? Thanks for your help, Paul On 01/29/2014 06:07 PM, Jack Hickish wrote: I'm not sure what, if any, difference a subsystem will make to the mapped design (I thought none), but I believe it's the case that changing module names etc. can affect the place and route algorithm's start seed. I seem to remember seeing this mentioned in a Xilinx doc under the heading "I've saved my project under a different name, now it won't meet timing, wtf?!" On 29 January 2014 22:44, John Ford wrote: On 01/29/2014 01:03 PM, Paul Marganian wrote: Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. Try saving the model and compiling it again, just changing a comment or something else non-substantive. John thanks Paul Marganian NRAO, Green Bank
Re: [casper] Timing errors and subsystems
I'm not sure what, if any, difference a subsystem will make to the mapped design (I thought none), but I believe it's the case that changing module names etc. can affect the place and route algorithm's start seed. I seem to remember seeing this mentioned in a Xilinx doc under the heading "I've saved my project under a different name, now it won't meet timing, wtf?!" On 29 January 2014 22:44, John Ford wrote: >> >> On 01/29/2014 01:03 PM, Paul Marganian wrote: >>> Hi all, >>> Should such software (simulink) features as subsystems and and gotos >>> have any affect on the final circuit created when I build my bof file? >>> >>> I am compiling models on Roach I that use almost all of the available >>> Logic Slices (~97%). That the subsequent build should contain timing >>> errors is not a surprise, but I recently noted a change in my timing >>> errors that puzzled me. >>> >>> I have assumed up till now that certain types of features in my model >>> are superficial, and will not change how the bof file is built. I >>> wanted to test this theory, and rebuilt my model after selecting part >>> of my model and turning it into a subsystem. I was surprised to see >>> that this new build had very different timing errors then the previous >>> one (from 18 errors to just 3). >>> >>> Is it the subsystem that caused this change, or is another one of my >>> assumptions, that timing errors are deterministic and can be >>> reproduced with subsequent builds of identical models, false? >> I've made a test of this, and indeed, I think my assumption is correct: >> I get the same timing errors after two subsequent builds. > > Try saving the model and compiling it again, just changing a comment or > something else non-substantive. > > John > >> >>> >>> thanks >>> Paul Marganian >>> NRAO, Green Bank >>> >>> >> >> > > >
Re: [casper] Timing errors and subsystems
> > On 01/29/2014 01:03 PM, Paul Marganian wrote: >> Hi all, >> Should such software (simulink) features as subsystems and and gotos >> have any affect on the final circuit created when I build my bof file? >> >> I am compiling models on Roach I that use almost all of the available >> Logic Slices (~97%). That the subsequent build should contain timing >> errors is not a surprise, but I recently noted a change in my timing >> errors that puzzled me. >> >> I have assumed up till now that certain types of features in my model >> are superficial, and will not change how the bof file is built. I >> wanted to test this theory, and rebuilt my model after selecting part >> of my model and turning it into a subsystem. I was surprised to see >> that this new build had very different timing errors then the previous >> one (from 18 errors to just 3). >> >> Is it the subsystem that caused this change, or is another one of my >> assumptions, that timing errors are deterministic and can be >> reproduced with subsequent builds of identical models, false? > I've made a test of this, and indeed, I think my assumption is correct: > I get the same timing errors after two subsequent builds. Try saving the model and compiling it again, just changing a comment or something else non-substantive. John > >> >> thanks >> Paul Marganian >> NRAO, Green Bank >> >> > >
Re: [casper] Timing errors and subsystems
On 01/29/2014 01:03 PM, Paul Marganian wrote: Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? I've made a test of this, and indeed, I think my assumption is correct: I get the same timing errors after two subsequent builds. thanks Paul Marganian NRAO, Green Bank
[casper] Timing errors and subsystems
Hi all, Should such software (simulink) features as subsystems and and gotos have any affect on the final circuit created when I build my bof file? I am compiling models on Roach I that use almost all of the available Logic Slices (~97%). That the subsequent build should contain timing errors is not a surprise, but I recently noted a change in my timing errors that puzzled me. I have assumed up till now that certain types of features in my model are superficial, and will not change how the bof file is built. I wanted to test this theory, and rebuilt my model after selecting part of my model and turning it into a subsystem. I was surprised to see that this new build had very different timing errors then the previous one (from 18 errors to just 3). Is it the subsystem that caused this change, or is another one of my assumptions, that timing errors are deterministic and can be reproduced with subsequent builds of identical models, false? thanks Paul Marganian NRAO, Green Bank
Re: [casper] timing errors
Hi John, I think timing errors of 100ps or so are probably not too much of a concern, but I'd be a little worried about the ~1ns errors you're seeing. Some suggestions to try and improve timing: on software registers and brams, I've found that adding delays with register retiming enabled to the addr, data_in, we signals (same delay on each) or on the input/output of the software register can help a lot. The idea is that since you don't care about a few cycles of latency when the software accesses these resources, you can allow for more latency in the connections which should free up fast routing resources for areas where they are actually needed. The same is true of the rx_valid and out of band outputs from the XAUI, since these represent 72 lines that have to be routed around the chip, and the links have huge latency anyway. I think the compiler should be smart enough to optimize out the higher bits of your 32 bit counter driving the blinking LED, but large counters can use up fast counter resources that you might need elsewhere. Same goes for the counters in the pulse extenders because there they definitely won't be optimized down to fewer bits. You also have a relational with zero latency in that thing that is 32 bits wide, so that's going to eat up fast resources. Add a unit or two of latency. This will make the extended pulse a few counts longer than you set the register for, but in this particular case that's not an issue. Have you tried running this design? Hope this helps, these are just anecdotal things that I've found to help, but not sure if my reasoning is actually sound. Glenn On Thu, Apr 24, 2008 at 7:45 AM, John Ford wrote: > > > Hi all. We're closing in on a release of our pulsar machine. We have > > been ignoring the timing errors in the builds, but I want to clean them up > > before we release the system for use. I have attached the model and a > > timing report from the latest model, an 8K point pfb/fft, with 2 xaui > > ports inputting data samples, some shared bram for debugging, some > > software registers, and output of the specral information over bee2 pipes > > to another fpga chip. These timing errors seem to be coming from inside > > the system, in the first instance from some fifo's internal to the system, > > and in the second case from the PFB coefficient generator. > > > > Can you suggest ways to fix these errors? Or should I just ignore them? > > (Seems like a *bad* idea...) > > Well, it would be helpful if I had sent the attachments... > > Here they are! > > > > > Thanks! > > > > John > > > > > > >
Re: [casper] timing errors
> Hi all. We're closing in on a release of our pulsar machine. We have > been ignoring the timing errors in the builds, but I want to clean them up > before we release the system for use. I have attached the model and a > timing report from the latest model, an 8K point pfb/fft, with 2 xaui > ports inputting data samples, some shared bram for debugging, some > software registers, and output of the specral information over bee2 pipes > to another fpga chip. These timing errors seem to be coming from inside > the system, in the first instance from some fifo's internal to the system, > and in the second case from the PFB coefficient generator. > > Can you suggest ways to fix these errors? Or should I just ignore them? > (Seems like a *bad* idea...) Well, it would be helpful if I had sent the attachments... Here they are! > > Thanks! > > John > > > <>
[casper] timing errors
Hi all. We're closing in on a release of our pulsar machine. We have been ignoring the timing errors in the builds, but I want to clean them up before we release the system for use. I have attached the model and a timing report from the latest model, an 8K point pfb/fft, with 2 xaui ports inputting data samples, some shared bram for debugging, some software registers, and output of the specral information over bee2 pipes to another fpga chip. These timing errors seem to be coming from inside the system, in the first instance from some fifo's internal to the system, and in the second case from the PFB coefficient generator. Can you suggest ways to fix these errors? Or should I just ignore them? (Seems like a *bad* idea...) Thanks! John