subject:"\[casper\] timing errors"

Re: Re: Re: [casper] timing errors

2017-06-05 Thread 门云鹏

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" <jsm...@ska.ac.za>
发送时间:2017-06-05 22:19:34 (星期一)
收件人: "Vereese Van Tonder" <vere...@ska.ac.za>
抄送: "门云鹏" <yp...@pku.edu.cn>, "Michael D'Cruze" 
<michael.dcr...@postgrad.manchester.ac.uk>, "casper@lists.berkeley.edu" 
<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 <vere...@ska.ac.za> 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, 门云鹏 <yp...@pku.edu.cn> 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" <jsm...@ska.ac.za>
发送时间:2017-06-04 01:44:39 (星期日)
收件人: "Michael D'Cruze" <michael.dcr...@postgrad.manchester.ac.uk>
抄送: "门云鹏" <yp...@pku.edu.cn>, "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/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.
T

Re: Re: [casper] timing errors

2017-06-05 Thread James Smith

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 <vere...@ska.ac.za>
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, 门云鹏 <yp...@pku.edu.cn> 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" <jsm...@ska.ac.za>
>> *发送时间:*2017-06-04 01:44:39 (星期日)
>> *收件人:* "Michael D'Cruze" <michael.dcr...@postgrad.manchester.ac.uk>
>> *抄送:* "门云鹏" <yp...@pku.edu.cn>, "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.ber

Re: Re: [casper] timing errors

2017-06-05 Thread Vereese Van Tonder

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, 门云鹏 <yp...@pku.edu.cn> 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" <jsm...@ska.ac.za>
> *发送时间:*2017-06-04 01:44:39 (星期日)
> *收件人:* "Michael D'Cruze" <michael.dcr...@postgrad.manchester.ac.uk>
> *抄送:* "门云鹏" <yp...@pku.edu.cn>, "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.dcruze@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 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

2017-06-03 Thread 门云鹏

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" <jsm...@ska.ac.za>
发送时间:2017-06-04 01:44:39 (星期日)
收件人: "Michael D'Cruze" <michael.dcr...@postgrad.manchester.ac.uk>
抄送: "门云鹏" <yp...@pku.edu.cn>, "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/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

2017-06-03 Thread James Smith

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

2017-06-03 Thread Michael D'Cruze

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

2017-06-03 Thread Vereese Van Tonder

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

2017-06-03 Thread 门云鹏

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

2015-11-09 Thread Amit Bansod

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

2015-11-09 Thread Ryan Monroe

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

Re: [casper] Timing Errors ROACH2

2015-11-05 Thread Ryan Monroe

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.

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 have enclosed the map report.

Regards,
Amit

On 04.11.2015 09:37, Ryan Monroe wrote:

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]

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

"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:

(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

LocationDelay type Delay(ns) Physical
Resource
Logical
Resource(s)

Re: [casper] Timing Errors ROACH2

2015-11-04 Thread Ryan Monroe

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

Re: [casper] Timing errors and subsystems

2014-01-30 Thread Jack Hickish

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 pmarg...@nrao.edu 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 jf...@nrao.edu 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

2014-01-30 Thread Paul Marganian



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 pmarg...@nrao.edu 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 jf...@nrao.edu 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

2014-01-30 Thread Jack Hickish

 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 pmarg...@nrao.edu 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 jf...@nrao.edu 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

2014-01-30 Thread Paul Marganian


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 pmarg...@nrao.edu 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 jf...@nrao.edu 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

[casper] Timing errors and subsystems

2014-01-29 Thread Paul Marganian


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 and subsystems

2014-01-29 Thread Paul Marganian



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

Re: [casper] Timing errors and subsystems

2014-01-29 Thread John Ford


 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

2014-01-29 Thread Jack Hickish

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 jf...@nrao.edu 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: Re: Re: [casper] timing errors

Re: Re: [casper] timing errors

Re: Re: [casper] timing errors

Re: Re: [casper] timing errors

Re: [casper] timing errors

RE: [casper] timing errors

Re: [casper] timing errors

[casper] timing errors

Re: [casper] Timing Errors ROACH2

Re: [casper] Timing Errors ROACH2

Re: [casper] Timing Errors ROACH2

Re: [casper] Timing Errors ROACH2

Re: [casper] Timing errors and subsystems

Re: [casper] Timing errors and subsystems

Re: [casper] Timing errors and subsystems

Re: [casper] Timing errors and subsystems

[casper] Timing errors and subsystems

Re: [casper] Timing errors and subsystems

Re: [casper] Timing errors and subsystems

Re: [casper] Timing errors and subsystems

20 matches

Site Navigation

Mail list logo

Footer information