Re: [casper] Compiler merging SRLs -- Timing performance
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
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
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
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
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 > > >
[casper] Compiler merging SRLs -- Timing performance
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] xport IP address
Thanks everyone. For the sake of time, we just swapped the xport from another roach (roach was broken, but xport was not) and we're back in business. Given all the negative reports on this, it would probably be worthwhile for us to implement an external hardware solution for auto powering on our roaches for the long-term. Thanks again, Jason On 12/4/2014 6:04 AM, Jason Manley wrote: I'm afraid we have also not had long-term success with the Lantronix X-port, nor the Actel Fusion devices in ROACH-1. This is why they are not present in ROACH-2. In my experience, I cannot advise anyone to rely on these devices in production systems. Jason Manley CBF Manager SKA-SA Cell: +27 82 662 7726 Work: +27 21 506 7300 On 04 Dec 2014, at 12:41, Andrea Mattana wrote: Hi all, just to report that even some of our ROACH-1's Xport dead suddenly loosing the great functions of remote power on/off ;( We thought the same solution to use a low cost controller but not yet implemented. We will do it when the new Roach2 rack will be ready. Cheers, Andrea Cheers, Andrea 2014-12-04 2:18 GMT+01:00 Louis Dartez : Hi Jason, I've encountered similar issues with R1's before. I think it comes back to the xports simply being unreliable. I've heard of cases in which the xports work for a few months but unpredictably stop working at some point. There have also been cases in which the xport never works to begin with. The latter has been the case with some of the LoFASM ROACH-1's; xport was dead out of the box. In one particular case this became a problem for us since we really needed to be able to access the auto power-on feature as well as be able to force the R1 on/off remotely. We ended up programming an arduino that was used as a 'digital finger' that emulated the pressing of the power button on the chassis itself. Our ROACH board at LoFASM-II at the LWA North Arm is configured this way. Best of luck, L Sent from my iPhone On Dec 3, 2014, at 18:42, Jason Ray wrote: All, We're having an issue with a roach1 in GB where we can't access the xport. It doesn't seem to respond using a web browser to the default IP of 192.168.20.4. We also had our sys admin add an entry for its MAC address to our DHCP server and we still cannot communicate with it. As far as I know, we have never even tried to access the xport on this roach, much less accidentally set it to some IP we can't remember. We know our laptop is configured correctly because we can access xport on one of the other roaches here. A few questions -- does anyone have a suggestion on how we could get into the xport? Is there a way to reset it to the factory defaults by chance? We need to do this to enable the "auto power-up" feature. Is there any other way to enable this feature besides xport? Thanks, Jason -- Andrea Mattana I.N.A.F. - Istituto di Radioastronomia Radiotelescopi di Medicina Via Fiorentina, 3513 - 40059 Medicina (Bo) Tel. 051/6965834 Fax. 051/6965810
Re: [casper] xport IP address
I'm afraid we have also not had long-term success with the Lantronix X-port, nor the Actel Fusion devices in ROACH-1. This is why they are not present in ROACH-2. In my experience, I cannot advise anyone to rely on these devices in production systems. Jason Manley CBF Manager SKA-SA Cell: +27 82 662 7726 Work: +27 21 506 7300 On 04 Dec 2014, at 12:41, Andrea Mattana wrote: > Hi all, > just to report that even some of our ROACH-1's Xport dead suddenly > loosing the great functions of remote power on/off ;( > We thought the same solution to use a low cost controller but not yet > implemented. We will do it when the new Roach2 rack will be ready. > > Cheers, > Andrea > > > Cheers, > Andrea > > 2014-12-04 2:18 GMT+01:00 Louis Dartez : >> Hi Jason, >> >>I've encountered similar issues with R1's before. I think it comes back >> to the xports simply being unreliable. I've heard of cases in which the >> xports work for a few months but unpredictably stop working at some point. >> There have also been cases in which the xport never works to begin with. The >> latter has been the case with some of the LoFASM ROACH-1's; xport was dead >> out of the box. >> >> In one particular case this became a problem for us since we really needed >> to be able to access the auto power-on feature as well as be able to force >> the R1 on/off remotely. We ended up programming an arduino that was used as >> a 'digital finger' that emulated the pressing of the power button on the >> chassis itself. Our ROACH board at LoFASM-II at the LWA North Arm is >> configured this way. >> >> Best of luck, >> L >> >> Sent from my iPhone >> >>> On Dec 3, 2014, at 18:42, Jason Ray wrote: >>> >>> All, >>> >>> We're having an issue with a roach1 in GB where we can't access the xport. >>> It doesn't seem to respond using a web browser to the default IP of >>> 192.168.20.4. We also had our sys admin add an entry for its MAC address >>> to our DHCP server and we still cannot communicate with it. >>> >>> As far as I know, we have never even tried to access the xport on this >>> roach, much less accidentally set it to some IP we can't remember. >>> >>> We know our laptop is configured correctly because we can access xport on >>> one of the other roaches here. >>> >>> A few questions -- does anyone have a suggestion on how we could get into >>> the xport? Is there a way to reset it to the factory defaults by chance? >>> >>> We need to do this to enable the "auto power-up" feature. Is there any >>> other way to enable this feature besides xport? >>> >>> Thanks, >>> Jason >>> >> > > > > -- > Andrea Mattana > > I.N.A.F. - Istituto di Radioastronomia > Radiotelescopi di Medicina > Via Fiorentina, 3513 - 40059 Medicina (Bo) > Tel. 051/6965834 Fax. 051/6965810 >
Re: [casper] xport IP address
Hi all, just to report that even some of our ROACH-1's Xport dead suddenly loosing the great functions of remote power on/off ;( We thought the same solution to use a low cost controller but not yet implemented. We will do it when the new Roach2 rack will be ready. Cheers, Andrea Cheers, Andrea 2014-12-04 2:18 GMT+01:00 Louis Dartez : > Hi Jason, > > I've encountered similar issues with R1's before. I think it comes back > to the xports simply being unreliable. I've heard of cases in which the > xports work for a few months but unpredictably stop working at some point. > There have also been cases in which the xport never works to begin with. The > latter has been the case with some of the LoFASM ROACH-1's; xport was dead > out of the box. > > In one particular case this became a problem for us since we really needed to > be able to access the auto power-on feature as well as be able to force the > R1 on/off remotely. We ended up programming an arduino that was used as a > 'digital finger' that emulated the pressing of the power button on the > chassis itself. Our ROACH board at LoFASM-II at the LWA North Arm is > configured this way. > > Best of luck, > L > > Sent from my iPhone > >> On Dec 3, 2014, at 18:42, Jason Ray wrote: >> >> All, >> >> We're having an issue with a roach1 in GB where we can't access the xport. >> It doesn't seem to respond using a web browser to the default IP of >> 192.168.20.4. We also had our sys admin add an entry for its MAC address to >> our DHCP server and we still cannot communicate with it. >> >> As far as I know, we have never even tried to access the xport on this >> roach, much less accidentally set it to some IP we can't remember. >> >> We know our laptop is configured correctly because we can access xport on >> one of the other roaches here. >> >> A few questions -- does anyone have a suggestion on how we could get into >> the xport? Is there a way to reset it to the factory defaults by chance? >> >> We need to do this to enable the "auto power-up" feature. Is there any >> other way to enable this feature besides xport? >> >> Thanks, >> Jason >> > -- Andrea Mattana I.N.A.F. - Istituto di Radioastronomia Radiotelescopi di Medicina Via Fiorentina, 3513 - 40059 Medicina (Bo) Tel. 051/6965834 Fax. 051/6965810
