1. Home
  2. Field-Programmable Gate Arrays
  3. XST question

XST question

Hello everybody,

Iam using ISE 6.2 with XST as synthesis tool. So far so good. But Now I have a design with plenty of timing margin (just 36 MHz ;-) and the goal is to fit it into a XC2S50E. At the end, it doesnt. So looking a little closer to the reports, I saw in the MAP report something like this.

blabla

1000 LUTs used 300 LUTs used a s route-thru.

How is this to understand? I understand it this way, that XST (and the other tools) use a LUT to feed data into a FF, but only 1 input is used, so the LUT has no real function, maybe only a inversion. Is this how it works? So how can I tell the software not to use LUTs as route thru, even if this will decrease timing performance? I mean it is tecnically possible to use th BY input to feed data into a FF.

Regards Falk

Reply to
Falk Brunner
Loading thread data ...

Not sure if this will help, but might be worth a try out the following MAP options -

map -cm area or map -k {4 5 6} (default is 4) or both of them together.

Reply to
Vikram

I tried it before, doesnt change a bit. The number of route-thru LUTs stays.

Regards Falk

Reply to
Falk Brunner

basically.. yes... The LUT as a router is the same as a via on a PCB. annoying to have.. but imposable to live without

How to fit the design... first... try the optimisations others suggest... second.. check with marketing ... it may not be worth the effort when it would fit comfortably in a 100e third.. use a better tool ($$$) forth... use as many built in routines as you can find. fifth.. hand place and route the design (see second above) sixth.. your 30% over budget so throw it away and start again with a better algorithm... or see second above. seventh... just throw functionality out until it fits eighth.. ask your Xilinx reseller to give you a better price on 100e

Simon

have

something

other

th

Reply to
Simon Peacock

Are you sure this is the output from MAP? My understanding is that it is the routing tool that will add route-thru LUTs, not the mapper. There would be no point to the mapper adding them since it would have no idea of where routing is a problem.

I am thinking that perhaps your synthesis tool is adding them because of some mistaken option. Or maybe your design won't fit anyway!!! I just checked and the XC2S50 only has 864 LUTs ignoring the data sheet that says 972. Does your design require 1000 *plus* 300 for routing or just

700?

If it is the router that is adding the routing LUTs, then your design just won't route in the XC2S50 unless you perhaps try floorplanning the design to ease routing congestion.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

formatting link

MAP indeed documents the route-thru's, although I haven't been able to find any *detailed* information on how/when it decides to use route-thru or not (I assume it is routing congestion, but I was looking for a bit more detail than that). Nor did I find anything on how to influence their use.

Anyone have ideas?

I'd be real suprised if the synthesis tool did it, since you can syth a design using larger or smaller size targets than what you finally create a bit-stream for.

This is what peaked my interest in wanting to know more about route-thru's. Regardless if he has 700+300 or 1000+300 (both of which easily exceed 864), the route-thru's are over 30% of his design - that strikes me as a huge percentage. Could this be caused by anything except a larger number of timing domains that are poorly placed?

Marc

Reply to
Marc Randolph

"Simon Peacock" schrieb im Newsbeitrag news:41a9a25e$ snipped-for-privacy@news.actrix.gen.nz...

If there would'nt be the BY input . . .

Been there done that. Suprisingly the option "Keep hierachy = NO" in XST makes it possible to merge more unrelated logic. Hmmm??

Is already in the pipe an will be most probably the final solution, since there are more functions waiting for beeing implemented.

Hmm, but this is not the answer at all. And its not sooo smart to solve any problem by throhging a lot of money at it.

??? You mean optimized Xilinx Macros?

Not worth the trouble and doesnt answer the core question. Is there a way to tell XST (the synthesizer) and MAP, that we have plenty of time and want maximum density. The usuall settings Speed/Area change nothing here. My design achives 10 ns cycle time, where I have 27 ns.

better

This is MY design, so it already has the best algorithm available ;-))

No option. Everything is needed. No possibilities of time sharing/MUXing.

Already in progress.

Regards Falk

Reply to
Falk Brunner

"rickman" schrieb im Newsbeitrag news: snipped-for-privacy@yahoo.com...

Yes, its the MAP report.

Yes, but XST does some kind of secret/magic look ahead synthesis, so I guess it does add the route-thru LUTs.

It has 1536, 4 per CLB.

1000 for logic PLUS 300 for route-through, according to the MAP report. This somewhere 85 %. But it does not fit since slice usage is then somewhere 110 %.

Its not a routing problem, the design flow gets killed after MAP (overmapped)

Regards Falk

Reply to
Falk Brunner

"Marc Randolph" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

Yes, but maybe using the LUT as route through gives better maaping/placement/routing possibilities and in the end better timing. So XST add them (I guess). But it would be nice if there is a switch for "slow" designs.

Its 1526 LUTs in the XC2S50E.

Its a one clock design (36 MHz). It achives 10ns cycle time, but I can spent

27ns.

Regards Falk

Reply to
Falk Brunner

I really do not understand why the synthesis tool would be adding route-thru LUTs. The tool can figure an estimated speed for the design by making assumptions about route speeds, but it would be pretty hard for it to make any intelligent estimates of routing congestion since that is very highly dependent on placement.

This just makes no sense!

I guess I was looking at the wrong row in the data sheet. But what about the synthesis options or attributes? I am adding "keep" attributes and found the tool added empty LUTs if I added the keep in more than one place in the heirarchy.

Have you contacted Xilinx about this? With your speed constraints, I can't understand why the tools would be doing this at all, and certainly it should not be done by the synthesis tool! It may be perfectly routable without any of the route-thrus with your speed constraints.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

- snip -

Another obvious question is how many slice Flip-flops are used. This is often the source of route-throughs. If you are making shift registers with slice flip-flops you can often reduce total resources using SRL16's which allows the use of a LUT that would otherwise be a route-through to implement a portion of the shift register chain. Another trick I've used in Virtex is to use TBUF's for mux functions when I run out of slices, but I don't think you have those in the 2e (map should tell you this).

Generally, though, if your design uses more than about 70% of the LUTs in the part the mapper will fail to fit it in my experience.

Reply to
Gabor Szakacs

"Gabor Szakacs" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

Its somewhere 60 %. So the FF/LUT ratio is close to 1.

Thanks for the advice but I already had a look at this point. No improvement possible here.

I just use a few, als no way to gain some ressources.

Yep, this is what happens.

Regards Falk

Reply to
Falk Brunner

"rickman" schrieb im Newsbeitrag news: snipped-for-privacy@yahoo.com...

guess

Because its the Xilinx homemade synthesis tool. Maybe it is trying to avoid routing congestions in a very early stage ??

Not really. Since we have to use the 100k part anyway, its not urgent. But I would like to know for future designs. I will contact our FAE in the next days and post the result here. Stay tuned folks.

Exactly my point.

Regards Falk

Reply to
Falk Brunner

These LUT route-thrus are inserted during the packing phase of the mapper which is why they are listed in the map report. The packer will normally only use a LUT to reach the FF data input if the corresponding BX/BY pin is already being used for some other purpose.

Bret

Reply to
Bret Wade

Falk,

You can do one thing, take a post-map verilog simulation file and pattern search for LUT instances with only one input ... these will the ones which are configured as route-thru

Now, in the FPGA editor, you can search the component names for those LUTs.

I had done somehting similar few months back, i found most instances when the LUT is used as route-thru to feed the dedicated XOR gate. the otehr input of XOR gate coming from BY/BX signal. What could be the reason for hte same !? ... my guess is some timing improvemnets.

Though i have not yet seen myself the LUT route-thru mode used to feed the flip - flop but i think it is possible to do so, while using both Set and Reset signal in the Flip-flop. eg.FDSR instance of xilinx primitives.

the issue with this is, how the tool at mapping stage estimate whether the preceeding logic to the flip flop be accomodated in the LUT or the LUT be configured in route-thru mode.

probably some data like number of route-thru LUTs post-map and post-pnr can shed more light to it?

--Varun.

Reply to
Varun Jindal

Falk,

You can do one thing, take a post-map verilog simulation file and pattern search for LUT instances with only one input ... these will the ones which are configured as route-thru

Now, in the FPGA editor, you can search the component names for those LUTs.

I had done somehting similar few months back, i found most instances when the LUT is used as route-thru to feed the dedicated XOR gate. the otehr input of XOR gate coming from BY/BX signal. What could be the reason for hte same !? ... my guess is some timing improvemnets.

Though i have not yet seen myself the LUT route-thru mode used to feed the flip - flop but i think it is possible to do so, while using both Set and Reset signal in the Flip-flop. eg.FDSR instance of xilinx primitives.

the issue with this is, how the tool at mapping stage estimate whether the preceeding logic to the flip flop be accomodated in the LUT or the LUT be configured in route-thru mode.

probably some data like number of route-thru LUTs post-map and post-pnr can shed more light to it?

--Varun.

Reply to
Varun Jindal

Hmmm... it is odd that they would bother to do this, but if you are correct, it doesn't "cost" any extra LUTs then. Certainly they would not be using the LUT as a route-thru if it were being fed by any other LUTs. If the BX/BY input were being fed by a LUT, I still expect timing on most paths could be improved by moving some of the other signals to the route-thru LUT. If both inputs are being fed from registers, then no savings would be seen by using the LUT instead of making it a route-thru. But is it really very likely that there are 300 of these in a 1000 LUT design?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.