XST ff merging - how do I "preserve" flip flops

A

Allan Herriman

Guest
Hi,
I'm trying to code this structure in Verilog. There are two flip
flops (c and d) that are identical. XST 6.1.3 wants to merge them
together. I want to stop it from doing that.

e .---. c
+-----|D Q|-----
| +-|>C |
a .---. b | | | |
----|D Q|-----+ | '---'
+--|>C | | |
| | | | |
| '---' | f | .---. d
| +-----|D Q|-----
clk-+----------------+-|>C |
| |
'---'

created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de


I am giving the -equivalent_register_removal YES option to XST (it's
needed elsewhere in the design) so I have to use attributes to stop
XST from merging these particular ffs, since I don't wish to
instantiate unisim components.

When I use the keep attribute on all of c, d, e and f, XST still
merges the ffs, and comes back with this warning:

WARNING:Xst:638 - in unit foo Conflict on KEEP property on signal e
and f f signal will be lost.

[ Warning 638 isn't in the Xilinx documentation or the answers
database. ]

Here's the Verilog:

module foo
(
input wire clk,
input wire a,
output reg c,
output reg d
);

reg b;

wire e = b;
wire f = b;

// synthesis attribute keep of c is "true"
// synthesis attribute keep of d is "true"
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"

always @(posedge clk)
begin
b <= a;
c <= e;
d <= f;
end

endmodule


I have a working solution: add BUFs as follows:

BUF buf_e (.I(b), .O(e));
BUF buf_f (.I(b), .O(f));

This produces the correct result after synthesis, but I wish to avoid
using unisim components, because (1) they slow my simulation (even BUF
contains a specify block!), (2) they aren't portable, and (3) I
shouldn't have to.


Questions:
- What am I doing wrong? ("Expecting too much from XST" is not an
acceptable answer.)
- How can I write the Verilog such that I get the correct result after
synthesis without needing to instantiate unisim components?

Hint to Xilinx: a "preserve" attribute would be really handy. The
other synthesis vendors have it. Why doesn't XST?

Thanks,
Allan.
 
On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

[snip]
I have a working solution: add BUFs as follows:

BUF buf_e (.I(b), .O(e));
BUF buf_f (.I(b), .O(f));
Note: if I use buf (Verilog primitive) instead of BUF (Xilinx unisim
component) it will merge the flip flops. Presumably bufs get stripped
out fairly early during synthesis.

Regards,
Allan.
 
Try:

// synthesis attribute equivalent_register_removal of c is "no"
// synthesis attribute equivalent_register_removal of d is "no"

and see if that does what you want it to.

-- Brian



Allan Herriman wrote:

On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman
allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

[snip]

I have a working solution: add BUFs as follows:

BUF buf_e (.I(b), .O(e));
BUF buf_f (.I(b), .O(f));


Note: if I use buf (Verilog primitive) instead of BUF (Xilinx unisim
component) it will merge the flip flops. Presumably bufs get stripped
out fairly early during synthesis.

Regards,
Allan.
 
Why you need follow 2 attribute?
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"
e and f are not flip-flop.

Remove them should be OK

"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> Đ´ČëÓĘźţ
news:16s640hupdiocn3a94shc4oid0cdrdu4p8@4ax.com...
Hi,
I'm trying to code this structure in Verilog. There are two flip
flops (c and d) that are identical. XST 6.1.3 wants to merge them
together. I want to stop it from doing that.

e .---. c
+-----|D Q|-----
| +-|>C |
a .---. b | | | |
----|D Q|-----+ | '---'
+--|>C | | |
| | | | |
| '---' | f | .---. d
| +-----|D Q|-----
clk-+----------------+-|>C |
| |
'---'

created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de


I am giving the -equivalent_register_removal YES option to XST (it's
needed elsewhere in the design) so I have to use attributes to stop
XST from merging these particular ffs, since I don't wish to
instantiate unisim components.

When I use the keep attribute on all of c, d, e and f, XST still
merges the ffs, and comes back with this warning:

WARNING:Xst:638 - in unit foo Conflict on KEEP property on signal e
and f f signal will be lost.

[ Warning 638 isn't in the Xilinx documentation or the answers
database. ]

Here's the Verilog:

module foo
(
input wire clk,
input wire a,
output reg c,
output reg d
);

reg b;

wire e = b;
wire f = b;

// synthesis attribute keep of c is "true"
// synthesis attribute keep of d is "true"
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"

always @(posedge clk)
begin
b <= a;
c <= e;
d <= f;
end

endmodule


I have a working solution: add BUFs as follows:

BUF buf_e (.I(b), .O(e));
BUF buf_f (.I(b), .O(f));

This produces the correct result after synthesis, but I wish to avoid
using unisim components, because (1) they slow my simulation (even BUF
contains a specify block!), (2) they aren't portable, and (3) I
shouldn't have to.


Questions:
- What am I doing wrong? ("Expecting too much from XST" is not an
acceptable answer.)
- How can I write the Verilog such that I get the correct result after
synthesis without needing to instantiate unisim components?

Hint to Xilinx: a "preserve" attribute would be really handy. The
other synthesis vendors have it. Why doesn't XST?

Thanks,
Allan.
 
On Tue, 2 Mar 2004 13:34:26 +0800, "Peng Cong" <pc_dragon@sohu.com>
wrote:

Why you need follow 2 attribute?
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"
e and f are not flip-flop.

Remove them should be OK
Remove them and watch XST merge the two flip flops. (I know; I tried
it.)

I suggest you read the XST documentation.

Regards,
Allan.
 
Synplify used to do that too, and before that, syn_preserve didn't work
at all. splitting the input to the flip-flops and putting syn_keeps on
them saves the day. For some reason the tools have an easier go at it by
keeping signals rather than attempting to preserve registers. Don't know
why.

Allan Herriman wrote:

On Tue, 2 Mar 2004 13:34:26 +0800, "Peng Cong" <pc_dragon@sohu.com
wrote:

Why you need follow 2 attribute?
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"
e and f are not flip-flop.

Remove them should be OK

Remove them and watch XST merge the two flip flops. (I know; I tried
it.)

I suggest you read the XST documentation.

Regards,
Allan.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
 
On Thu, 04 Mar 2004 12:01:26 +1100, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

On Tue, 2 Mar 2004 13:34:26 +0800, "Peng Cong" <pc_dragon@sohu.com
wrote:

Why you need follow 2 attribute?
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"
e and f are not flip-flop.

Remove them should be OK

Remove them and watch XST merge the two flip flops. (I know; I tried
it.)

I suggest you read the XST documentation.
To clarify, a preserve attribute on the output of the flip flops would
stop them from being merged. XST does not support such an attribute,
hence the ugly workaround using keep attributes on the inputs of the
flip flops.

I need to use attributes to do a few things:
1. Placement
2. Preventing flip flops from being merged
3. Preventing flip flops from being replicated
4. Preventing buffers from being inserted into high-fanout logic

#1 isn't too bad, but the others are needlessly difficult in XST.

Regards,
Allan.
 
On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

[snip]

I didn't see Brian's post on my server, but google found it.

// synthesis attribute equivalent_register_removal of c is "no"
// synthesis attribute equivalent_register_removal of d is "no"


Silly me. I was looking for constraints in the constraints guide, and
this one isn't listed there.

Thanks,
Allan.
 
On Thu, 04 Mar 2004 21:31:18 +1100, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman
allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

[snip]

I didn't see Brian's post on my server, but google found it.

// synthesis attribute equivalent_register_removal of c is "no"
// synthesis attribute equivalent_register_removal of d is "no"


Silly me. I was looking for constraints in the constraints guide, and
this one isn't listed there.
Hang on, it *is* there. I don't understand how I missed it.

Oh well.

Allan.
 
If the attribute setting does not work, or you don't want to turn off global
removal of duplicates for the whole design, and you happen to have a spare
I/O. Make sure the I/O is in a known state say pulled-up. Ensure the pin is
defined as input or bi-directional. Use the input(bi) as a enable signal
into your register choosing the "enabled" state to be the one you use and is
always true. Don't do the same to copy register. They are now different and
the synthesiser wouldn't remove the duplicate. Very crude approach but
usually works.

You can do a similar thing by having one reg with a reset and one reg
without reset but you need to ensure that this does not cause you other
issues. There many variations you use I will leave to find the most
suitable.

John Adair
Enterpoint Ltd.
http://www.enterpoint.co.uk

This message is the personal opinion of the sender and not that necessarily
that of Enterpoint Ltd.. Readers should make their own evaluation of the
facts. No responsibility for error or inaccuracy is accepted.


"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:16s640hupdiocn3a94shc4oid0cdrdu4p8@4ax.com...
Hi,
I'm trying to code this structure in Verilog. There are two flip
flops (c and d) that are identical. XST 6.1.3 wants to merge them
together. I want to stop it from doing that.

e .---. c
+-----|D Q|-----
| +-|>C |
a .---. b | | | |
----|D Q|-----+ | '---'
+--|>C | | |
| | | | |
| '---' | f | .---. d
| +-----|D Q|-----
clk-+----------------+-|>C |
| |
'---'

created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de


I am giving the -equivalent_register_removal YES option to XST (it's
needed elsewhere in the design) so I have to use attributes to stop
XST from merging these particular ffs, since I don't wish to
instantiate unisim components.

When I use the keep attribute on all of c, d, e and f, XST still
merges the ffs, and comes back with this warning:

WARNING:Xst:638 - in unit foo Conflict on KEEP property on signal e
and f f signal will be lost.

[ Warning 638 isn't in the Xilinx documentation or the answers
database. ]

Here's the Verilog:

module foo
(
input wire clk,
input wire a,
output reg c,
output reg d
);

reg b;

wire e = b;
wire f = b;

// synthesis attribute keep of c is "true"
// synthesis attribute keep of d is "true"
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"

always @(posedge clk)
begin
b <= a;
c <= e;
d <= f;
end

endmodule


I have a working solution: add BUFs as follows:

BUF buf_e (.I(b), .O(e));
BUF buf_f (.I(b), .O(f));

This produces the correct result after synthesis, but I wish to avoid
using unisim components, because (1) they slow my simulation (even BUF
contains a specify block!), (2) they aren't portable, and (3) I
shouldn't have to.


Questions:
- What am I doing wrong? ("Expecting too much from XST" is not an
acceptable answer.)
- How can I write the Verilog such that I get the correct result after
synthesis without needing to instantiate unisim components?

Hint to Xilinx: a "preserve" attribute would be really handy. The
other synthesis vendors have it. Why doesn't XST?

Thanks,
Allan.
 
Allan,

We were having a little trouble with our server's posting ability so it
might not be your fault. The sad part is I have written several
responses to people over the past few months but no one could see them
unless you look at our server (it showed up on our server but not the
outside world so I thought they were getting out). I think all is fixed
now and if you are reading this, then hopefully the problem is corrected
and should not cause confusion going forward. Sorry about that.

BTW, that attribute is in the 6.1i Constraints Guide on page 333 but
looks like you might have found it now.

-- Brian


Allan Herriman wrote:
On Thu, 04 Mar 2004 21:31:18 +1100, Allan Herriman
allan.herriman.hates.spam@ctam.com.au.invalid> wrote:


On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman
allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

[snip]

I didn't see Brian's post on my server, but google found it.

// synthesis attribute equivalent_register_removal of c is "no"
// synthesis attribute equivalent_register_removal of d is "no"


Silly me. I was looking for constraints in the constraints guide, and
this one isn't listed there.


Hang on, it *is* there. I don't understand how I missed it.

Oh well.

Allan.
 
On Thu, 04 Mar 2004 09:24:37 -0700, Brian Philofsky
<brian.philofsky@no_xilinx_spam.com> wrote:

Allan,

We were having a little trouble with our server's posting ability so it
might not be your fault. The sad part is I have written several
responses to people over the past few months but no one could see them
unless you look at our server (it showed up on our server but not the
outside world so I thought they were getting out). I think all is fixed
now and if you are reading this, then hopefully the problem is corrected
and should not cause confusion going forward. Sorry about that.

BTW, that attribute is in the 6.1i Constraints Guide on page 333 but
looks like you might have found it now.
Hi Brian,

Reading you loud and clear.

I think I was misled by a statement on page 254 of the XST User Guide
that said "You must use the KEEP constraint instead of
SIGNAL_PRESERVE" (which is wrong), and didn't mention
equivalent_register_removal at all.

Regards,
Allan.
 

Welcome to EDABoard.com

Sponsor

Back
Top