08-26-2011 07:05 PM
In FPGA viewer my design looks like a football because the tools are trying to place instances of a module around the source of a bus that runs to each. I have tried to pipleine the buses in question however what I really need is two things:
1- to allow all of these buses 10 cycles (for example) to route the signal. There are many of these buses and they are all 64b, the contraints editor crashes when I try to do this. I need to find a way to prevent the tools from trying to meet single cycle routing requirement and turning my design into a football.
2-Prevent the design from being contorted. I was thinking placement contraints but am afraid it would lead to a time consuming scalability problem. My design is grid based and the post place and route should also be that way. I am not concerned that the wrapping logic will fail because I can just add a ton of registers.
for example If I have four instances of a module AA, AB, BA and BB, and I wanted AA in to be closet to X0Y0 and BB X"N"Y"N" does anyone have any ideas how to do this? I want to avoid absolute constraints because I think the tools can do a better job, however the relative order is important to me.
I also need scaleability because my grid has more than 4 elemants.
Im aware there is an RLOC contraint however what I really need is a solid example I can follow.
Im using command line tools, version 12.3, for vertex 6.
thanks in advance!
Solved! Go to Solution.
08-26-2011 09:42 PM
Besides contortion what is the problem exactly? Is the design failing to route due to the congestion created by an overly compact placement? There is a new feature available in 13.2 that allows you to limit the number of input/output connections per CLB (2 slices) by setting an environment variable. This will force the placer to spread the logic out more.
setenv XIL_PAR_CLB_INPUT_OUTPUT_LIMIT 20
I use 20 as an example but experiment with a range of values. I've attached a SmartXplorer strategy file that can be used to test a range of values.
08-29-2011 09:50 AM
Density does not seem to be the issue, the design seems to be spreading out as much as setup time requirements will allow.
the problem is that there are a large number of identical modules with inter-routing. because of this routing, there is a specific order that the modules should be placed in. If these modules are not placed in this order there really is no hope for routing, it just becomes a mess I find.
Unfortunately, I am finding that the routing requirements of some other module is causing all of these to be placed around it in a circular pattern.
I would rather the important routing mentioned first happened in a logical way, and if that breaks timing for the other module then I can pipeline those signals.
08-29-2011 11:39 AM
I think density is an issue if the design is failing to route and the placement is compacted into a round ball. The problem comes from the placer trying to reduce wirelength for high fanout busses and there are just too many components that need to be placed close to each other. You can try to spread the logic with the new option I mentioned in my first post or you can try to floorplan the design which would add some of the structure that you mention. Creating RPM macros would add very detailed structure. You could also restructure the design to lesson the fanout issue.
08-30-2011 02:21 PM - edited 08-30-2011 02:21 PM
so ultimately what I ended up doing what restructuring the design as suggested to add more register stages to certain buses and allow to the tools to make the correct routing decisions. This seems obvious to me now but it is important to note that if the design does not have layout constraints and has confliction in routing requirements (due to path lengths), that the tools will produce a report and a result that does not always indicate the true offending paths. In my case these were routed correctly for timing at the expense of other paths.
Looking at the final layout in the FPGA editor really helped. I learnt a lot doing that as well.
I did not have the time to invest in learning to creat RPM macros, but will consider it if I find myself in this situation again.
I also did not have access to 13.x features.
Thanks for the help!