XST optimization
in [FPGA]
|
From: Alan Fitch on 30 Mar 2010 04:13 On 29/03/2010 20:36, Jason Thibodeau wrote: e raison d'�tre of HDL synthesizers is to produce an optimized >> design that matches the HDL input code. If the tools didn't do this >> then they no one would use or buy them. >> >> If the gate/net was optimized away then it wasn't needed. Either the >> input (registers and IO pads) equation cone had redundancies or there >> was a redundancy to the final output (registers or IO pads). The >> synthesizer will also move the equations around to optimize timing. A >> signal that you have coded to appear early in an multi-level logic >> cone may be pushed to later in the logic cone to improve the timing. >> >> If the synthesizer changed the logic then it would be a bug. Since >> you have said that this happens in two different tools it is very >> unlikely to be a bug. >> >> I think that you mentioned that you had OR'ed all of the outputs >> together to keep all of the logic from being trimmed. I would suggest >> instead that you register all of the outputs and then OR the registers >> outputs to keep the logic. Optimizing across the register boundaries >> is available in some synthesizers, but there is usually an option to >> enable/disable the feature. >> >> Ed McGettigan >> -- >> Xilinx Inc. >> > > The logic that is being optimized out is a simple comparator. And gates > in roughly a tree structure, with a final or gate to feed it back into > the 'main' circuit. > > The or gate was not implemented to keep the tool from trimming the > logic, rather it was necessary for proper function of the circuit. > > What I'm working on, I need to be able to place these gates into > specific portions of the chip. This is why I cannot have them optimized > or absorbed into other CLB's. > > I'm really just trying to figure out if it is possible to place an > attribute before an instantiation so it will not be trimmed. I realize > what I want may not be a standard request, but I just want to make it work. > > Thanks for all your help, everyone. > Hi Jason, I still don't really understand - but I suspect there may be a misunderstanding here. If you say the gates are "optimized out", to me that means, as Ed and others have said, that they are redundant - to put it bluntly, the tool is right and you are wrong :-; However I wonder if what you really mean is that the functionality of those gates has been merged in with other logic, and you want to keep it separate? If that is the case, then you need to put those gates in a separate component and tell the tool to preserve the hierarchy, and to keep that component using whatever magic spells are required by XST, regards Alan -- Alan Fitch Senior Consultant Doulos � Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch(a)doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.
From: Jason Thibodeau on 30 Mar 2010 08:04
On 03/30/2010 04:13 AM, Alan Fitch wrote: > On 29/03/2010 20:36, Jason Thibodeau wrote: > > e raison d'�tre of HDL synthesizers is to produce an optimized >>> design that matches the HDL input code. If the tools didn't do this >>> then they no one would use or buy them. >>> >>> If the gate/net was optimized away then it wasn't needed. Either the >>> input (registers and IO pads) equation cone had redundancies or there >>> was a redundancy to the final output (registers or IO pads). The >>> synthesizer will also move the equations around to optimize timing. A >>> signal that you have coded to appear early in an multi-level logic >>> cone may be pushed to later in the logic cone to improve the timing. >>> >>> If the synthesizer changed the logic then it would be a bug. Since >>> you have said that this happens in two different tools it is very >>> unlikely to be a bug. >>> >>> I think that you mentioned that you had OR'ed all of the outputs >>> together to keep all of the logic from being trimmed. I would suggest >>> instead that you register all of the outputs and then OR the registers >>> outputs to keep the logic. Optimizing across the register boundaries >>> is available in some synthesizers, but there is usually an option to >>> enable/disable the feature. >>> >>> Ed McGettigan >>> -- >>> Xilinx Inc. >>> >> >> The logic that is being optimized out is a simple comparator. And gates >> in roughly a tree structure, with a final or gate to feed it back into >> the 'main' circuit. >> >> The or gate was not implemented to keep the tool from trimming the >> logic, rather it was necessary for proper function of the circuit. >> >> What I'm working on, I need to be able to place these gates into >> specific portions of the chip. This is why I cannot have them optimized >> or absorbed into other CLB's. >> >> I'm really just trying to figure out if it is possible to place an >> attribute before an instantiation so it will not be trimmed. I realize >> what I want may not be a standard request, but I just want to make it >> work. >> >> Thanks for all your help, everyone. >> > > Hi Jason, > I still don't really understand - but I suspect there may be a > misunderstanding here. If you say the gates are "optimized out", to me > that means, as Ed and others have said, that they are redundant - to put > it bluntly, the tool is right and you are wrong :-; > > However I wonder if what you really mean is that the functionality of > those gates has been merged in with other logic, and you want to keep it > separate? > > If that is the case, then you need to put those gates in a separate > component and tell the tool to preserve the hierarchy, and to keep that > component using whatever magic spells are required by XST, > > regards > Alan > > Alan, I believe you have nailed the problem right on the head. I do not believe that XST is blatantly removing the gates, but I did suspect the gates are being absorbed into other LUTs. This, of course, would not change teh functionality, but would affect my ability to place and route these specific gates. I think my next plan of action is to place all these gates into a separate component, as you suggest. For the others, while you may disagree with my methods, I can guarantee this: 1. I have a benchmark which must remain in tact, except for the gates I am placing. 2. These gates are integral to my design, and their placement is more important than their existence. 3. I have revealed all I am allowed to reveal, this is why I have been so vague. Believe me, I'd love to give you all the code so you can see exactly what I am talking about, but others above me prevent this from happening. I appreciate all the help, and the ideas you have suggested. I still have a lot to learn, and you all give me great area in which to research. -- Jason Thibodeau |