From: Jason Thibodeau on
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
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
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
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
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 ?