Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20644 Discussions

What Altera tool can we use to manually place and route, especially LUT locations

Altera_Forum
Honored Contributor II
1,977 Views

Hi All, 

 

What Altera tool can we use to manually place and route, especially assign LUT contents and locations? 

 

As I know, Xilinx has a tool named Editor which can be used to do manually place and route. It also has a tool called PlanAhead (maybe has another name now) which can be used to do area constraint. Do we have some similar tools? 

 

Thanks! 

 

Sincerely, 

Sam
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
852 Views

If for some reason, you *really* want to do this, you can do it in the Chip Planner, the Assignment Editor, or the Resource Property Editor. Doing this, however, is very much discouraged. What exactly are you trying to accomplish that you can't do with a Logic Lock region or just letting the Fitter do its thing (preferred)?

0 Kudos
Altera_Forum
Honored Contributor II
852 Views

If you want to constrain logic to a particular area of a chip, that is what LogicLock regions are for as sstrell mentions.  

 

With LL regions you basically define a region of the chip in and then assign portions of the design such as partitions or specific registers/LUTs/DSP blocks/RAMs etc. You can then specify what you wish to be constrained within the block - for example you might assign a partition but only want M20Ks or DSP blocks to be constrained, so you could exclude things like LUTs or routing. 

 

LL regions have a distinct advantage over assigning specific LUTs to specific regions in that it still allows the fitting tools to use their very good optimisation abilities to decide where bits should go whilst solving the issue of the fitter not being able to see the forest for the trees. If you have lots of chunks of the design with interconnections, the fitter can get confused and struggle to optimise what should be where. By constraining these chunks into regions it helps the fitter see what bits should be grouped and so start optimising those groups internally more strongly as it knows you want them to be packed.
0 Kudos
Altera_Forum
Honored Contributor II
852 Views

In fact, I want to build Ring-Oscillators as thermal sensors, which require placing LUT manually. 

Thanks for your reply!
0 Kudos
Altera_Forum
Honored Contributor II
852 Views

 

--- Quote Start ---  

If you want to constrain logic to a particular area of a chip, that is what LogicLock regions are for as sstrell mentions.  

 

With LL regions you basically define a region of the chip in and then assign portions of the design such as partitions or specific registers/LUTs/DSP blocks/RAMs etc. You can then specify what you wish to be constrained within the block - for example you might assign a partition but only want M20Ks or DSP blocks to be constrained, so you could exclude things like LUTs or routing. 

 

LL regions have a distinct advantage over assigning specific LUTs to specific regions in that it still allows the fitting tools to use their very good optimisation abilities to decide where bits should go whilst solving the issue of the fitter not being able to see the forest for the trees. If you have lots of chunks of the design with interconnections, the fitter can get confused and struggle to optimise what should be where. By constraining these chunks into regions it helps the fitter see what bits should be grouped and so start optimising those groups internally more strongly as it knows you want them to be packed. 

--- Quote End ---  

 

 

I would argue that even using LL regions may not be preferred. Without LL regions, the Fitter can use any resources in the device and select the best ones based on the design and the timing constraints. Floorplanning with LL limits what the Fitter can choose. The grouping you mentioned is not really required by the modern Fitter. It was an issue in the past, though. Accurate timing constraints are essential. 

 

Some design flows, though, absolutely require LL, such as partial reconfiguration and periphery design block reuse.
0 Kudos
Altera_Forum
Honored Contributor II
852 Views

@sstrell the grouping issue is very definitely not a thing of the past at all. We have a design which is split into 12 DSP processing cores which each take a fraction of incoming data from a bus, process it, and then remerge at the end. When left to its own devices the fitter is either unable to fit the design, or it fails timing miserably. By grouping each core into its own LL region, the design fits well (~60% resource usage) and meets timing with ease - removing ~5ns of negative slack in the process (which is a lot at 200MHz). Similar story on another design with multiple cores. 

 

But anyway, not what the OP is looking for it seems.
0 Kudos
Altera_Forum
Honored Contributor II
852 Views

 

--- Quote Start ---  

I would argue that even using LL regions may not be preferred. Without LL regions, the Fitter can use any resources in the device and select the best ones based on the design and the timing constraints. Floorplanning with LL limits what the Fitter can choose. The grouping you mentioned is not really required by the modern Fitter. It was an issue in the past, though. Accurate timing constraints are essential. 

 

Some design flows, though, absolutely require LL, such as partial reconfiguration and periphery design block reuse. 

--- Quote End ---  

 

 

Q15 is hardly in the past. Ive needed LL regions to make a design using 90% logic. Without locking down specific entities, it would just spread them out and fail timing. locking them pretty much guaranteed timing. 

And then another design (Q10 mind you) had 15 regions because it had 90% ram and 90% dsp usage. If you didnt lock down the regions, again, it just died a miserable death. Even then, it needed 10 seeds to get 1 good one. But it didnt help that one clock was running at 350+Mhz. This strategy was recommended by Altera! 

 

Leaving it to the fitter is all fine until you consistantly fail timing, and your failing paths are spread all over the chip.
0 Kudos
Altera_Forum
Honored Contributor II
852 Views

If the timing constraints are correct, accurate, and detailed, failing paths should not be spread all over the chip. There are always reasons why the Fitter does what it does, and going back to the design and timing constraints and correlating with timing reports is your first best step. Now, isolating critical logic from non-critical logic with LL can certainly help after this, but an initial compile without LL can be used to help you understand what the Fitter is doing and decide if LL is really necessary.

0 Kudos
Reply