Re: [casper] Compiler merging SRLs

[Matt Strader]

To finish up this thread:
I unchecked 'Use behavioral HDL' in all the delays and counters (which also
wanted to combine in bad ways).  At least I unchecked it in any instances
that weren't already assigned to a pblock.
At least once, I still saw a delay with behavioral HDL turned off combine
with another delay, but the timing errors have mostly gone away.

Thanks for the help guys!

Matt

Re: [casper] Compiler merging SRLs

[Ryan Monroe]

Turning off Behavioral HDL on the relevant instances *is* the correct 
answer.  This should not impact resource utilization significantly.


If it does, that means you have a large-fanout net, and can improve 
timing and utilization simultaneously by doing fanout in a couple steps 
(ie, one step with a fanout of 6, followed by 6x steps with fanout of 6 
each (=fanout 36 across two steps).


I agree with Jack.  DOWN WITH ISE!!!  Scarab looked good, if a tiny bit 
pricey.


--Ryan

On 01/25/2016 07:17 AM, Jack Hickish wrote:


Ha, I just read my email in the thread you linked. I guess turning off 
behavioural hdl isn't (ever? always?) the solution.



On Mon, 25 Jan 2016 5:14 pm Jack Hickish > wrote:


Hi Matt,

You can resynthesize the "main" simulink netlist, but off the top
of my head I don't know the exact way to go about this. I think
you can dig out the netlist from the sysgen build directory and
use the resynth script on that. Perhaps Dave MacMahon (who I
believe wrote that script) could comment further.
My experience was that adding the lc_off flag helped sometimes,
but I still found luts combined on some occasions - I never got
satisfactorily to the bottom of this.
You can explicitly prevent combining of some blocks (eg. delays)
by turning off any behavioural hdl options they have, but this
isn't viable if it needs doing to so many blocks that resource
utilisation ends up being too horrifically impacted.

Having just seen the skarab/roach3 presentation in South Africa, I
fondly await the demise of virtex 6 and ISE.

Jack


On Sat, 23 Jan 2016 10:48 pm Matt Strader
mailto:mstra...@physics.ucsb.edu>> wrote:

Hello Casperites (especially Jack),

I've run into the problem that Jack describes in this thread:
http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05581.html
The compiler keeps wanting to combine unrelated LUTs on
opposite sides of the Virtex 6, resulting in timing errors
that are 90% routing.

At the end of the thread Jack says the solution is to use the
"-lc off" option in resynth_netlist and in map.
I'm using only one black box containing my pfb and fft.  The
rest of my design is not black boxed.  I used resynth_netlist
on the black box's ngc file, but it looks like I can't use it
on the netlists generated by casper_xps.  Is that right?
I also added "-lc off" to the map options in
XPS_ROACH2_base/etc/fast_runtime.opt

After doing this, I'm still getting timing errors from LUT
combining.  Is there somewhere else I need to turn this off? 
Any suggestions?


Thanks,
Matt Strader

Re: [casper] Compiler merging SRLs

[Jack Hickish]

Ha, I just read my email in the thread you linked. I guess turning off
behavioural hdl isn't (ever? always?) the solution.

On Mon, 25 Jan 2016 5:14 pm Jack Hickish  wrote:

> Hi Matt,
>
> You can resynthesize the "main" simulink netlist, but off the top of my
> head I don't know the exact way to go about this. I think you can dig out
> the netlist from the sysgen build directory and use the resynth script on
> that. Perhaps Dave MacMahon (who I believe wrote that script) could comment
> further.
> My experience was that adding the lc_off flag helped sometimes, but I
> still found luts combined on some occasions - I never got satisfactorily to
> the bottom of this.
> You can explicitly prevent combining of some blocks (eg. delays) by
> turning off any behavioural hdl options they have, but this isn't viable if
> it needs doing to so many blocks that resource utilisation ends up being
> too horrifically impacted.
>
> Having just seen the skarab/roach3 presentation in South Africa, I fondly
> await the demise of virtex 6 and ISE.
>
> Jack
>
> On Sat, 23 Jan 2016 10:48 pm Matt Strader 
> wrote:
>
>> Hello Casperites (especially Jack),
>>
>> I've run into the problem that Jack describes in this thread:
>> http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05581.html
>> The compiler keeps wanting to combine unrelated LUTs on opposite sides of
>> the Virtex 6, resulting in timing errors that are 90% routing.
>>
>> At the end of the thread Jack says the solution is to use the "-lc off"
>> option in resynth_netlist and in map.
>> I'm using only one black box containing my pfb and fft.  The rest of my
>> design is not black boxed.  I used resynth_netlist on the black box's ngc
>> file, but it looks like I can't use it on the netlists generated by
>> casper_xps.  Is that right?
>> I also added "-lc off" to the map options in
>> XPS_ROACH2_base/etc/fast_runtime.opt
>>
>> After doing this, I'm still getting timing errors from LUT combining.  Is
>> there somewhere else I need to turn this off?  Any suggestions?
>>
>> Thanks,
>> Matt Strader
>>
>>
>>
>>
>>

Re: [casper] Compiler merging SRLs

[Jack Hickish]

Hi Matt,

You can resynthesize the "main" simulink netlist, but off the top of my
head I don't know the exact way to go about this. I think you can dig out
the netlist from the sysgen build directory and use the resynth script on
that. Perhaps Dave MacMahon (who I believe wrote that script) could comment
further.
My experience was that adding the lc_off flag helped sometimes, but I still
found luts combined on some occasions - I never got satisfactorily to the
bottom of this.
You can explicitly prevent combining of some blocks (eg. delays) by turning
off any behavioural hdl options they have, but this isn't viable if it
needs doing to so many blocks that resource utilisation ends up being too
horrifically impacted.

Having just seen the skarab/roach3 presentation in South Africa, I fondly
await the demise of virtex 6 and ISE.

Jack

On Sat, 23 Jan 2016 10:48 pm Matt Strader  wrote:

> Hello Casperites (especially Jack),
>
> I've run into the problem that Jack describes in this thread:
> http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05581.html
> The compiler keeps wanting to combine unrelated LUTs on opposite sides of
> the Virtex 6, resulting in timing errors that are 90% routing.
>
> At the end of the thread Jack says the solution is to use the "-lc off"
> option in resynth_netlist and in map.
> I'm using only one black box containing my pfb and fft.  The rest of my
> design is not black boxed.  I used resynth_netlist on the black box's ngc
> file, but it looks like I can't use it on the netlists generated by
> casper_xps.  Is that right?
> I also added "-lc off" to the map options in
> XPS_ROACH2_base/etc/fast_runtime.opt
>
> After doing this, I'm still getting timing errors from LUT combining.  Is
> there somewhere else I need to turn this off?  Any suggestions?
>
> Thanks,
> Matt Strader
>
>
>
>
>

Re: [casper] Compiler merging SRLs -- Timing performance

[Jack Hickish]

Hi Everyone,

Thanks all for the advice. Based on a few experiments so far (skip to
4 for what I think is a disappointinly simple solution, that I was too
stupid to see in the XST manual) --

1. My fabric utilisation isn't that high, although digging around
planAhead there are some areas with high routing congestion. I wonder
how much this throws off the compiler.

2. Making the shift registers that are causing problems implement as
cores, rather than behavioural HDL doesn't seem to solve the problem,
the tools will quite happily combine two such cores into one LUT.

3. Explicitly disabling SRLs (by either putting lots of single delays
as cores / adding resets / (*shreg_extract = "NO"*)-ing HDL code makes
the problem go away for the individual delay (since now there aren't
any LUTs to combine). But mostly the symptom will just appear
somewhere else. (I haven't tried the nuclear SRL global disable, but
I'd be amazed if that didn't just cause my design to explode).

4. Resynthesizing the netlists with "-lc off" seems to have made all
the issues I was having disappear. At least in the timing report I've
read the headline spectacular fails have gone. Map reports that there
are still some SRLs using both O5 and O6 outputs, but I've got a bunch
of pcores, and I haven't resynth'd them all yet.
I'm a bit surprised that this option is needed in XST to avoid
combining luts that exist in different pcores, I would have thought
turning it off in map would be sufficient, but I guess I was wrong.
Maybe I would have figured this out sooner if I'd properly read an
up-to-date XST manual -- it appears that the default behaviour of lut
combining in XST has gone from 'off' in Virtex 5, to 'auto' in Virtex
6.

So bottom line, maybe -lc is an option worth playing with in future if
designs are failing timing with bizarre signal paths.

Thanks again for the help (and big shoutout for resynth_netlist, which
I certainly didn't realise was added by Dave 4 YEARS AGO!).

Jack

On 5 December 2014 at 07:01, Jason Manley  wrote:
> I often re-run XST with:
>
> register_balancing yes
> optimize_primitives yes
> read_cores yes
> shreg_extract no
>
> shreg_extract prevents adjacent registers from being combined into SRL16s.
>
> Jason Manley
> CBF Manager
> SKA-SA
>
> Cell: +27 82 662 7726
> Work: +27 21 506 7300
>
> On 05 Dec 2014, at 6:27, Henno Kriel  wrote:
>
>> Hi Jack,
>>
>> In Simulink if have seen similar issues when trying to add more "register" 
>> pipelining, to decrease routing delay's and thus increase Fmax.
>> However, ISE just collapses all the pipelining into a single SRL, which 
>> yields the frustrations you mentioned.
>> You can prevent this from happening, by adding a synchronise reset (one of 
>> the tick boxes on delay block) to your pipelining registers.
>> You will have to connect up a reset signal from a register (but you don't 
>> actually need to use it),
>> to ensure that it does not get optimized away.
>> In my case this normally resolves the routing issue and achieves timing 
>> closure.
>>
>> Hope this helps.
>> HK
>>
>>
>>
>> On Thu, Dec 4, 2014 at 9:37 PM, Jack Hickish  wrote:
>> Hey Mark,
>>
>> Yeah, I guess I could manually force the locations of the two offending 
>> shift-regs to stop the combination, but the problem SRLs seem to be a fairly 
>> arbitrary selection of those in the design. I don't really want to have to 
>> start constraining at the LUT level if I can help it. But maybe I'll try and 
>> see if the problem goes away, or just emerges somewhere else.
>>
>> Hi Dave,
>>
>> I have been through all the planAhead options, as well as the 
>> fast_runtime.opt settings in the base package (I've been using both flows) 
>> and (tried to) set everything to optimize for speed. The -lt option to me 
>> seems like it should control the behaviour I'm seeing, but it doesn't seem 
>> to. I'm using pblocks, but have been almost exclusively been constraining 
>> only rams/dsps. As above, I'm about to try forcing the placements. I haven't 
>> run resynth netlist on my simulink design, but equivalent register removal 
>> is turned off in planAhead and some of the signals it appears to be 
>> LUT-combining belong to different pcores, so I thought that planahead 
>> settings should be enough. (obviously I could be wrong).
>> In any case, I didn't think this was an equivalent register removal problem. 
>> It's not like multiple copies of the same register are being merged at the 
>> expense of fanout, just a 2-clock data delay inside an X-engine might be 
>> merged with a 2-clock delay of some data signal in an FFT. But again, maybe 
>> I'm understanding the options wrong, so I'll try resynthing the netlist and 
>> see if that helps.
>>
>> Thanks for your help, both.
>>
>> Jack
>>
>>
>>
>> On Thu Dec 04 2014 at 19:18:35 David MacMahon  
>> wrote:
>> Hi, Jack,
>>
>> Are the tools are optimizing for area instead of speed?  Are you using 
>> Pblocks?
>>
>> I don't know if this is relevant to your situation, but I've run 

Re: [casper] Compiler merging SRLs -- Timing performance

[Jason Manley]

I often re-run XST with:

register_balancing yes
optimize_primitives yes
read_cores yes
shreg_extract no

shreg_extract prevents adjacent registers from being combined into SRL16s.

Jason Manley
CBF Manager
SKA-SA

Cell: +27 82 662 7726
Work: +27 21 506 7300

On 05 Dec 2014, at 6:27, Henno Kriel  wrote:

> Hi Jack,
> 
> In Simulink if have seen similar issues when trying to add more "register" 
> pipelining, to decrease routing delay's and thus increase Fmax.
> However, ISE just collapses all the pipelining into a single SRL, which 
> yields the frustrations you mentioned. 
> You can prevent this from happening, by adding a synchronise reset (one of 
> the tick boxes on delay block) to your pipelining registers. 
> You will have to connect up a reset signal from a register (but you don't 
> actually need to use it), 
> to ensure that it does not get optimized away. 
> In my case this normally resolves the routing issue and achieves timing 
> closure.
> 
> Hope this helps.
> HK
> 
> 
> 
> On Thu, Dec 4, 2014 at 9:37 PM, Jack Hickish  wrote:
> Hey Mark,
> 
> Yeah, I guess I could manually force the locations of the two offending 
> shift-regs to stop the combination, but the problem SRLs seem to be a fairly 
> arbitrary selection of those in the design. I don't really want to have to 
> start constraining at the LUT level if I can help it. But maybe I'll try and 
> see if the problem goes away, or just emerges somewhere else.
> 
> Hi Dave,
> 
> I have been through all the planAhead options, as well as the 
> fast_runtime.opt settings in the base package (I've been using both flows) 
> and (tried to) set everything to optimize for speed. The -lt option to me 
> seems like it should control the behaviour I'm seeing, but it doesn't seem 
> to. I'm using pblocks, but have been almost exclusively been constraining 
> only rams/dsps. As above, I'm about to try forcing the placements. I haven't 
> run resynth netlist on my simulink design, but equivalent register removal is 
> turned off in planAhead and some of the signals it appears to be 
> LUT-combining belong to different pcores, so I thought that planahead 
> settings should be enough. (obviously I could be wrong). 
> In any case, I didn't think this was an equivalent register removal problem. 
> It's not like multiple copies of the same register are being merged at the 
> expense of fanout, just a 2-clock data delay inside an X-engine might be 
> merged with a 2-clock delay of some data signal in an FFT. But again, maybe 
> I'm understanding the options wrong, so I'll try resynthing the netlist and 
> see if that helps.
> 
> Thanks for your help, both.
> 
> Jack
> 
> 
> 
> On Thu Dec 04 2014 at 19:18:35 David MacMahon  
> wrote:
> Hi, Jack,
> 
> Are the tools are optimizing for area instead of speed?  Are you using 
> Pblocks?
> 
> I don't know if this is relevant to your situation, but I've run into 
> annoyances when the tools use "equivalent register removal" to save a few 
> flip-flops but end up causing fan-out/routing issues.  That can be turned 
> off, but it's a synthesis option so if you want to apply it to a System 
> Generator netlist, you have to use the "resynth_netlist" Matlab function from 
> the casper library to re-synthesize the entire netlist.
> 
> Dave
> 
> On Dec 4, 2014, at 10:48 AM, Jack Hickish wrote:
> 
> > Hi all,
> >
> > This is something I've been fighting with for a while now, and I wonder if 
> > anyone on this maillist has any insight (because I'm pretty sure I may just 
> > be doing something wrong with the tools).
> >
> > The problem:
> > I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz. 
> > However, every now and then I'll make a small change to the design and the 
> > compile will fail timing catastrophically, with paths failing sometimes 
> > with -2 ns (or worse) slack.
> > When I look at the failing path(s), the delays are usually ~80% routing. 
> > I'll see a signal take a huge detour to use a shift register in some 
> > arbitrary location on the chip. Upon closer inspection of the relevant SRL, 
> > it appears that the LUT concerned is being used for two signal paths, one 
> > on the O5 output, one on the O6. The result seems to be that it is poorly 
> > placed for both it's roles.
> >
> > I'm only using ~50% of the slices and about 30% of the registers / luts on 
> > the FPGA, and there are plenty of sensibly located SLICEMs the placer could 
> > use if it so desired. I've switched lut combining off (with the -lt flag), 
> > in planahead which doesn't seem to have made any difference.
> >
> > Can anyone offer me any words of advice / wisdom which might reduce my 
> > confusion at what's going on (or, even better, help me solve the problem)?
> >
> > Despairingly yours,
> > Jack
> >
> >
> 
> 
> 
> 
> -- 
> Kind regards,
> Henno Kriel
> 
> DBE: Hardware Manager
> 
> SKA South Africa
> Third Floor
> The Park
> Park Road (off Alexandra Road)
> Pinelands
> 7405
> Western Cape
> South Africa
> 
> Latitu

Re: [casper] Compiler merging SRLs -- Timing performance

[Henno Kriel]

Hi Jack,

In Simulink if have seen similar issues when trying to add more "register"
pipelining, to decrease routing delay's and thus increase Fmax.
However, ISE just collapses all the pipelining into a single SRL, which
yields the frustrations you mentioned.
You can prevent this from happening, by adding a synchronise reset (one of
the tick boxes on delay block) to your pipelining registers.
You will have to connect up a reset signal from a register (but you don't
actually need to use it),
to ensure that it does not get optimized away.
In my case this normally resolves the routing issue and achieves timing
closure.

Hope this helps.
HK



On Thu, Dec 4, 2014 at 9:37 PM, Jack Hickish  wrote:

> Hey Mark,
>
> Yeah, I guess I could manually force the locations of the two offending
> shift-regs to stop the combination, but the problem SRLs seem to be a
> fairly arbitrary selection of those in the design. I don't really want to
> have to start constraining at the LUT level if I can help it. But maybe
> I'll try and see if the problem goes away, or just emerges somewhere else.
>
> Hi Dave,
>
> I have been through all the planAhead options, as well as the
> fast_runtime.opt settings in the base package (I've been using both flows)
> and (tried to) set everything to optimize for speed. The -lt option to me
> seems like it should control the behaviour I'm seeing, but it doesn't seem
> to. I'm using pblocks, but have been almost exclusively been constraining
> only rams/dsps. As above, I'm about to try forcing the placements. I
> haven't run resynth netlist on my simulink design, but equivalent register
> removal is turned off in planAhead and some of the signals it appears to be
> LUT-combining belong to different pcores, so I thought that planahead
> settings should be enough. (obviously I could be wrong).
> In any case, I didn't think this was an equivalent register removal
> problem. It's not like multiple copies of the same register are being
> merged at the expense of fanout, just a 2-clock data delay inside an
> X-engine might be merged with a 2-clock delay of some data signal in an
> FFT. But again, maybe I'm understanding the options wrong, so I'll try
> resynthing the netlist and see if that helps.
>
> Thanks for your help, both.
>
> Jack
>
>
>
> On Thu Dec 04 2014 at 19:18:35 David MacMahon 
> wrote:
>
>> Hi, Jack,
>>
>> Are the tools are optimizing for area instead of speed?  Are you using
>> Pblocks?
>>
>> I don't know if this is relevant to your situation, but I've run into
>> annoyances when the tools use "equivalent register removal" to save a few
>> flip-flops but end up causing fan-out/routing issues.  That can be turned
>> off, but it's a synthesis option so if you want to apply it to a System
>> Generator netlist, you have to use the "resynth_netlist" Matlab function
>> from the casper library to re-synthesize the entire netlist.
>>
>> Dave
>>
>> On Dec 4, 2014, at 10:48 AM, Jack Hickish wrote:
>>
>> > Hi all,
>> >
>> > This is something I've been fighting with for a while now, and I wonder
>> if anyone on this maillist has any insight (because I'm pretty sure I may
>> just be doing something wrong with the tools).
>> >
>> > The problem:
>> > I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz.
>> However, every now and then I'll make a small change to the design and the
>> compile will fail timing catastrophically, with paths failing sometimes
>> with -2 ns (or worse) slack.
>> > When I look at the failing path(s), the delays are usually ~80%
>> routing. I'll see a signal take a huge detour to use a shift register in
>> some arbitrary location on the chip. Upon closer inspection of the relevant
>> SRL, it appears that the LUT concerned is being used for two signal paths,
>> one on the O5 output, one on the O6. The result seems to be that it is
>> poorly placed for both it's roles.
>> >
>> > I'm only using ~50% of the slices and about 30% of the registers / luts
>> on the FPGA, and there are plenty of sensibly located SLICEMs the placer
>> could use if it so desired. I've switched lut combining off (with the -lt
>> flag), in planahead which doesn't seem to have made any difference.
>> >
>> > Can anyone offer me any words of advice / wisdom which might reduce my
>> confusion at what's going on (or, even better, help me solve the problem)?
>> >
>> > Despairingly yours,
>> > Jack
>> >
>> >
>>
>>


-- 
Kind regards,
Henno Kriel

DBE: Hardware Manager

SKA South Africa
Third Floor
The Park
Park Road (off Alexandra Road)
Pinelands
7405
Western Cape
South Africa

Latitude: -33.94329 (South); Longitude: 18.48945 (East).

(p) +27 (0)21 506 7300
(p) +27 (0)21 506 7374 (direct)
(f) +27 (0)21 506 7375
(m) +27 (0)84 504 5050

Re: [casper] Compiler merging SRLs -- Timing performance

[Jack Hickish]

Hey Mark,

Yeah, I guess I could manually force the locations of the two offending
shift-regs to stop the combination, but the problem SRLs seem to be a
fairly arbitrary selection of those in the design. I don't really want to
have to start constraining at the LUT level if I can help it. But maybe
I'll try and see if the problem goes away, or just emerges somewhere else.

Hi Dave,

I have been through all the planAhead options, as well as the
fast_runtime.opt settings in the base package (I've been using both flows)
and (tried to) set everything to optimize for speed. The -lt option to me
seems like it should control the behaviour I'm seeing, but it doesn't seem
to. I'm using pblocks, but have been almost exclusively been constraining
only rams/dsps. As above, I'm about to try forcing the placements. I
haven't run resynth netlist on my simulink design, but equivalent register
removal is turned off in planAhead and some of the signals it appears to be
LUT-combining belong to different pcores, so I thought that planahead
settings should be enough. (obviously I could be wrong).
In any case, I didn't think this was an equivalent register removal
problem. It's not like multiple copies of the same register are being
merged at the expense of fanout, just a 2-clock data delay inside an
X-engine might be merged with a 2-clock delay of some data signal in an
FFT. But again, maybe I'm understanding the options wrong, so I'll try
resynthing the netlist and see if that helps.

Thanks for your help, both.

Jack



On Thu Dec 04 2014 at 19:18:35 David MacMahon 
wrote:

> Hi, Jack,
>
> Are the tools are optimizing for area instead of speed?  Are you using
> Pblocks?
>
> I don't know if this is relevant to your situation, but I've run into
> annoyances when the tools use "equivalent register removal" to save a few
> flip-flops but end up causing fan-out/routing issues.  That can be turned
> off, but it's a synthesis option so if you want to apply it to a System
> Generator netlist, you have to use the "resynth_netlist" Matlab function
> from the casper library to re-synthesize the entire netlist.
>
> Dave
>
> On Dec 4, 2014, at 10:48 AM, Jack Hickish wrote:
>
> > Hi all,
> >
> > This is something I've been fighting with for a while now, and I wonder
> if anyone on this maillist has any insight (because I'm pretty sure I may
> just be doing something wrong with the tools).
> >
> > The problem:
> > I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz.
> However, every now and then I'll make a small change to the design and the
> compile will fail timing catastrophically, with paths failing sometimes
> with -2 ns (or worse) slack.
> > When I look at the failing path(s), the delays are usually ~80% routing.
> I'll see a signal take a huge detour to use a shift register in some
> arbitrary location on the chip. Upon closer inspection of the relevant SRL,
> it appears that the LUT concerned is being used for two signal paths, one
> on the O5 output, one on the O6. The result seems to be that it is poorly
> placed for both it's roles.
> >
> > I'm only using ~50% of the slices and about 30% of the registers / luts
> on the FPGA, and there are plenty of sensibly located SLICEMs the placer
> could use if it so desired. I've switched lut combining off (with the -lt
> flag), in planahead which doesn't seem to have made any difference.
> >
> > Can anyone offer me any words of advice / wisdom which might reduce my
> confusion at what's going on (or, even better, help me solve the problem)?
> >
> > Despairingly yours,
> > Jack
> >
> >
>
>

Re: [casper] Compiler merging SRLs -- Timing performance

[David MacMahon]

Hi, Jack,

Are the tools are optimizing for area instead of speed?  Are you using Pblocks?

I don't know if this is relevant to your situation, but I've run into 
annoyances when the tools use "equivalent register removal" to save a few 
flip-flops but end up causing fan-out/routing issues.  That can be turned off, 
but it's a synthesis option so if you want to apply it to a System Generator 
netlist, you have to use the "resynth_netlist" Matlab function from the casper 
library to re-synthesize the entire netlist.

Dave

On Dec 4, 2014, at 10:48 AM, Jack Hickish wrote:

> Hi all,
> 
> This is something I've been fighting with for a while now, and I wonder if 
> anyone on this maillist has any insight (because I'm pretty sure I may just 
> be doing something wrong with the tools).
> 
> The problem:
> I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz. 
> However, every now and then I'll make a small change to the design and the 
> compile will fail timing catastrophically, with paths failing sometimes with 
> -2 ns (or worse) slack.
> When I look at the failing path(s), the delays are usually ~80% routing. I'll 
> see a signal take a huge detour to use a shift register in some arbitrary 
> location on the chip. Upon closer inspection of the relevant SRL, it appears 
> that the LUT concerned is being used for two signal paths, one on the O5 
> output, one on the O6. The result seems to be that it is poorly placed for 
> both it's roles.
> 
> I'm only using ~50% of the slices and about 30% of the registers / luts on 
> the FPGA, and there are plenty of sensibly located SLICEMs the placer could 
> use if it so desired. I've switched lut combining off (with the -lt flag), in 
> planahead which doesn't seem to have made any difference.
> 
> Can anyone offer me any words of advice / wisdom which might reduce my 
> confusion at what's going on (or, even better, help me solve the problem)?
> 
> Despairingly yours,
> Jack
> 
> 

Re: [casper] Compiler merging SRLs -- Timing performance

[Mark Wagner]

Hi Jack,

Not sure if this will help, but in Planahead I would try to click and drag
that LUT as close as possible to each of the outputs.  And if that doesn't
help or makes it worse, you could also try to duplicate the logic going to
each of those outputs, forcing separate LUTs to be used.

Cheers,
Mark


On Thu, Dec 4, 2014 at 10:48 AM, Jack Hickish  wrote:

> Hi all,
>
> This is something I've been fighting with for a while now, and I wonder if
> anyone on this maillist has any insight (because I'm pretty sure I may just
> be doing something wrong with the tools).
>
> The problem:
> I'm playing with a ROACH2 design that (sometimes) compiles at 312 MHz.
> However, every now and then I'll make a small change to the design and the
> compile will fail timing catastrophically, with paths failing sometimes
> with -2 ns (or worse) slack.
> When I look at the failing path(s), the delays are usually ~80% routing.
> I'll see a signal take a huge detour to use a shift register in some
> arbitrary location on the chip. Upon closer inspection of the relevant SRL,
> it appears that the LUT concerned is being used for two signal paths, one
> on the O5 output, one on the O6. The result seems to be that it is poorly
> placed for both it's roles.
>
> I'm only using ~50% of the slices and about 30% of the registers / luts on
> the FPGA, and there are plenty of sensibly located SLICEMs the placer could
> use if it so desired. I've switched lut combining off (with the -lt flag),
> in planahead which doesn't seem to have made any difference.
>
> Can anyone offer me any words of advice / wisdom which might reduce my
> confusion at what's going on (or, even better, help me solve the problem)?
>
> Despairingly yours,
> Jack
>
>
>