From: Jason Thibodeau on 29 Mar 2010 15:36 On 03/29/2010 02:38 PM, Ed McGettigan wrote: > On Mar 29, 10:15 am, Jason Thibodeau<jason.p.thibod...(a)gmail.com> > wrote: >> On 03/29/2010 01:03 PM, Muzaffer Kal wrote: >> >> >> >> >> >>> On Mon, 29 Mar 2010 09:40:40 -0700 (PDT), Jason Thibodeau >>> <jbloud...(a)gmail.com> wrote: >> >>>> On Mar 29, 4:37 am, Matthieu Michon<prenom....(a)gmail.com> wrote: >>>>> On Sun, 28 Mar 2010 21:29:31 -0400 >> >>>>> Jason Thibodeau<jason.p.thibod...(a)gmail.com> wrote: >> >>>>> (...) >> >>>>>> I should have mentioned that I have tried all the iterations of keep >>>>>> that I could think of, the gates are still being optimized out. I tried >>>>>> both placing the keep attribute in the code, and using the xcf file, >>>>>> neither have worked. I think part of the problem is I don't know hte >>>>>> exact name of the nets being optimized out, since XST doesn't tell me >>>>>> this information in the reports. >> >>>>> Altough it is not universal, I use the "S" (save net flag) attribute for keeping signals from being optimized (typically for displaying them in Chipscope). >> >>>>> The "S" attribute is described in the Constraint Guide (cgd.pdf). >> >>>>> -- >>>>> Matthieu Michon<prenom....(a)gmail.com> >> >>>> I'm having problems with my main machine, so I'm posting this from >>>> google groups, I'm the OP. >> >>>> I have some gates defined in a verilog file like this: >> >>>> AND2X1 Gate1 (.A(net1) , .B(net2), .Y(net3)); >>>> INVX1 gate2 (.A(net3) , .B(net4)); >> >>>> etc.. >> >>>> The entities, AND2X1 and INVX1 are defined in a library, so they >>>> synthesize just fine. >> >>>> The final gate I have: >>>> OR2X1 gate15 (.A(bla bla), .B(...), .Y(...)); >> >>>> This gate, gate15 shows up in manual place and route, but the others >>>> connected to it do not. Why is that? >> >>>> I'll look into the 'S' flag, thanks. >> >>> My first take would be to simulate the design. If it does what you >>> need in simulation, then you might investigate if your design is >>> minimal in its specification. The synthesis is pretty accurate in what >>> it thinks the unnecessary parts of logic are so I'd check the design >>> very carefully before trying to keep gates which are really not >>> necessary for logic (as you seem to be mentioning mostly logic and not >>> buffers, inverters which might look unnecessaary but might be needed.) >> >> I know the design intimately, and I know for a fact the gates it is >> optimizing out are necessary for proper operation. I'm trying to figure >> out WHY this is happening. >> >> FWIW, this is not just a problem with Xilinx's optimization. Synopsys >> does the same thing during synthesis, but I can tell it to not optimize. >> The branches it is optimizing have a VERY (<.000001%) low probability of >> activation, but I need the gates to remain, anyway. >> >> -- >> Jason Thibodeau- Hide quoted text - >> >> - Show quoted text - > > The 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. -- Jason Thibodeau
From: Patrick Maupin on 29 Mar 2010 17:20 On Mar 29, 2:36 pm, Jason Thibodeau <jason.p.thibod...(a)gmail.com> wrote: > 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 have no idea why you would want to do this, but I would build the design as discrete units. At the top, you can stitch them together using xilinx's "black box" stuff, and then the synthesizer won't be smart enough to optimize things out. Also, doing it this way makes it easy to constrain placement. HOWEVER, the map has gotten a lot smarter lately, so you'll probably need to set some options on that to keep it from resynthesizing the chip when it sees the full picture. Regards, Pat
From: Jason Thibodeau on 29 Mar 2010 17:29 On 03/29/2010 05:20 PM, Patrick Maupin wrote: > On Mar 29, 2:36 pm, Jason Thibodeau<jason.p.thibod...(a)gmail.com> > wrote: >> 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 have no idea why you would want to do this, but I would build the > design as discrete units. At the top, you can stitch them together > using xilinx's "black box" stuff, and then the synthesizer won't be > smart enough to optimize things out. Also, doing it this way makes it > easy to constrain placement. > > HOWEVER, the map has gotten a lot smarter lately, so you'll probably > need to set some options on that to keep it from resynthesizing the > chip when it sees the full picture. > > Regards, > Pat Unfortunately, the gates that are being optimized out, are being inserted into an existing design file. They are, however, instances of a predefined entity. I cannot move them to be parts of a "black box". -- Jason Thibodeau
From: Patrick Maupin on 29 Mar 2010 22:19 On Mar 29, 4:29 pm, Jason Thibodeau <jason.p.thibod...(a)gmail.com> wrote: > Unfortunately, the gates that are being optimized out, are being > inserted into an existing design file. They are, however, instances of a > predefined entity. I cannot move them to be parts of a "black box". OK, from what I've seen: 1) You claim the gates are an "integral part of the design", but that TWO different synthesizers remove them. 2) You claim that for some unreported reason they HAVE to be placed at a certain place on the chip (and we haven't even gotten to how routing will affect the timing on that...) 3) You claim that you can't change the design; yet you simultaneously have to change the design. 4) You are apparently reluctant to explain enough about the design to let others independently judge the veracity of claims 1-3. I don't know whether you are building one of these weird neural nets where some genetic trial and error algorithm has found a design that does something strange and wonderful, or what. It sounds like an interesting puzzle; unfortunately most of the give and take around here is on puzzles that have solutions that are useful to multiple people, especially where two different people giving answers can learn a bit from each other. I'm beginning to suspect that you are the only person on the planet with this particular problem, and since I can't see its relevance to my life, and I tried (and also read a bunch of answers where others have tried), I only have one answer left for you: FPGA Editor. And I'm sure you have a reason why that won't work, and although I shouldn't care, I would like to see this reason. It's like watching one of those slow motion train-wrecks... Regards, Pat
From: Muzaffer Kal on 30 Mar 2010 03:16 On Mon, 29 Mar 2010 13:15:11 -0400, Jason Thibodeau <jason.p.thibodeau(a)gmail.com> wrote: >I know the design intimately, and I know for a fact the gates it is >optimizing out are necessary for proper operation. I'm trying to figure >out WHY this is happening. > >FWIW, this is not just a problem with Xilinx's optimization. Synopsys >does the same thing during synthesis, but I can tell it to not optimize. >The branches it is optimizing have a VERY (<.000001%) low probability of >activation, but I need the gates to remain, anyway. For logic synthesis probability of activity doesn't matter. If the logic cone includes the path, it will be kept. Maybe your gates are being merged in a LUT instead of being kept as individual gates which XST maybe more inclined than Synopsys is (DC is usually more obsequious as ASIC developers are more insistent on what they want to keep). One thing you can check is to compare the behavior of the post map netlist vs your input structural netlist. If they're the same XST is restructuring your code. It is extremely unlikely that they are different but if so open a case with Xilinx. One final thing you can try is to replace each gate with LUTs and equivalent INIT statements which are protected with an abundence of keep, no_prune etc. You should be able to protect every single gate with this method. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: USB 3.0 implementation on FPGA Next: where is VHDL-POSIX ? |