No respect of external pins (xilinx)

Grégory Mermoud

unread,

Jan 15, 2005, 11:25:27 AM1/15/05

to

Hi all!

I encounter a strange problem. I wrote a macro and tried to use it in a
design. The problem is, the xilinx tools modify the external pins of my
macro. Indeed, my macro is build of LUTs and then, I want to use partial
reconfiguration to change their equations. The problem is that the tools
modify the entries of these LUTs and my equations are not ok any more.

Someone has ever experienced such a problem ? Does it exist any option
for tools to force them to respect the external pins ?

Grégory

Bret Wade

unread,

Jan 15, 2005, 1:59:54 PM1/15/05

to

Hi Gregory,

The change in the equation is due to pin swapping. You can prevent the
pin swapping by using the LOCK_PINS constraint.

I am assuming that your macro is an RPM macro. If it were a hard macro,
I wouldn't expect the pin swapping to have occurred in the first place.
But your use of the term "external pins" does imply a hard macro.

More details about the LOCK_PINS constraint:
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=15845

Regards,
Bret

Grégory Mermoud

unread,

Jan 15, 2005, 6:16:46 PM1/15/05

to

>
> Hi Gregory,
>
> The change in the equation is due to pin swapping. You can prevent the
> pin swapping by using the LOCK_PINS constraint.
>
> I am assuming that your macro is an RPM macro. If it were a hard macro,
> I wouldn't expect the pin swapping to have occurred in the first place.
> But your use of the term "external pins" does imply a hard macro.
>
> More details about the LOCK_PINS constraint:
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=15845
>
>
> Regards,
> Bret

You're great. Preciseness, conciseness. All what I love. :) Thx

Grégory Mermoud

unread,

Jan 15, 2005, 6:52:02 PM1/15/05

to

>
> Hi Gregory,
>
> The change in the equation is due to pin swapping. You can prevent the
> pin swapping by using the LOCK_PINS constraint.
>
> I am assuming that your macro is an RPM macro. If it were a hard macro,
> I wouldn't expect the pin swapping to have occurred in the first place.
> But your use of the term "external pins" does imply a hard macro.
>
> More details about the LOCK_PINS constraint:
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=15845
>
>
> Regards,
> Bret

I does not work. I do not understand why. In fact, what is the
fundamental difference between an RPM macro and a hard macro ? Should
the LOCK_PINS constraint not work by using one of them ?

Grégory Mermoud

unread,

Jan 15, 2005, 7:23:33 PM1/15/05

to

> The change in the equation is due to pin swapping. You can prevent the
> pin swapping by using the LOCK_PINS constraint.
>
> I am assuming that your macro is an RPM macro. If it were a hard macro,
> I wouldn't expect the pin swapping to have occurred in the first place.
> But your use of the term "external pins" does imply a hard macro.
>
> More details about the LOCK_PINS constraint:
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=15845
>
>
> Regards,
> Bret

Another question in the same field : does it exist any way to insert a
macro while keeping exactly the same routing than the one proposed by
the macro ?

Grégory

Bret Wade

unread,

Jan 15, 2005, 11:44:23 PM1/15/05

to

An RPM macro is defined in the logical design using RLOC constraints or
indirectly, the flooprplanner. A hard macro is defined in the physical
design using FPGA Editor and exists in the logical design only as a
black box. Which are you using?

Bret

Grégory Mermoud

unread,

Jan 16, 2005, 5:09:21 AM1/16/05

to

> An RPM macro is defined in the logical design using RLOC constraints or
> indirectly, the flooprplanner. A hard macro is defined in the physical
> design using FPGA Editor and exists in the logical design only as a
> black box. Which are you using?
>
> Bret

An RPM macro, but I'm not sure. I wrote a macro by using FPGA editor and
defined a reference component. I save it (.nmc) and call it in a VHDL
design as a usual component. This component is a black box for the
sythesis tool (Leonardo) of course, since it has no VHDL code describing
the macro. On the other hand, the ngdbuild have such a description
through the .nmc. Then, I set *LOC* constraints (and not RLOC) for this
component. Hmm... After explaining you what I did, it seems that I am
using hard macros :)

Anyway, I just want to prevent their external pins to swap.

INST "rule_macro" LOCK_PINS;
INST "rule_macro/MUXa" LOCK_PINS;
INST "rule_macro/MUXA2" LOCK_PINS;

Is not it the right way to constraint that ? Assume that rule_macro is
the macro and MUXa is a slice using only LUTs. Maybe I must write :

INST "rule_macro/MUXA2/F" LOCK_PINS;

in order to really contstraint the LUT itself.

Thank you very much in advance for your help!

Grégory

Bret Wade

unread,

Jan 17, 2005, 2:00:02 AM1/17/05

to

Hi Grégory,

It is a hard macro then. The LOCK_PINS constraint needs to be applied to
the LUT logic in the logical design, and this isn't possible with a hard
macro. I suspect that it would work to recreate the macro using logic
that had been mapped with the LOCK_PINS constraint already applied to
the LUT logic.

If that's too much work (I don't know how large the macro is) then
another option would be to use xdl to covert the .nmc file to a text
format, insert the constraint and then use xdl to convert back to a .nmc
file. The following string needs to be added to the "cfg" field for the
slice in question:

_INST_PROP::LOCK_PINS:

Both of these work arounds are purely theorectical at this point. I've
never tried either. Before doing this, I suggest that you spend some
time to confirm that pin-swapping really is the problem. Are LUT
equations different when the mapped .ncd and par'd .ncd are examined in
FPGA Editor? As I mentioned before, I'm surprised to hear that par is
swapping hard macro pins.

Regards,
Bret

Sample xdl slice configuration with locked pins:
inst "t23111_1_i/Q_c" "SLICE" , placed R71C1 SLICE_X1Y51 ,
cfg "CYSELF::#OFF CYSELG::#OFF COUTUSED::#OFF YUSED::0 XUSED::0
F5USED::#OFF YBMUX::#OFF CYINIT::#OFF DYMUX::#OFF
DXMUX::#OFF
F:t23111_1_i/Q:#LUT:D=((~A1*(A2*A3))+(A1*(A2+~A3)))
REVUSED::#OFF FXMUX::F SYNC_ATTR::#OFF SRFFMUX::#OFF
FFY_SR_ATTR::#OFF FFX::#OFF FFY::#OFF FFX_SR_ATTR::#OFF
G_ATTR::#OFF DIG_MUX::#OFF CY0G::#OFF GYMUX::G FXUSED::#OFF
DIF_MUX::#OFF SLICEWE0USED::#OFF F_ATTR::#OFF CY0F::#OFF
DIGUSED::#OFF SHIFTOUTUSED::#OFF BYOUTUSED::#OFF
FFX_INIT_ATTR::#OFF FFY_INIT_ATTR::#OFF
G:t7835_86_i/t56_1_i:#LUT:D=(A1+(A2+A3)) XBMUX::#OFF
BYINVOUTUSED::#OFF SLICEWE2USED::#OFF SLICEWE1USED::#OFF
WF1USED::#OFF WF2USED::#OFF WF3USED::#OFF WF4USED::#OFF
WG1USED::#OFF WG2USED::#OFF WG3USED::#OFF WG4USED::#OFF
YBUSED::#OFF BXOUTUSED::#OFF BYINV::#OFF BXINV::#OFF
CEINV::#OFF CLKINV::#OFF SRINV::#OFF SOPOUTUSED::#OFF
SOPEXTSEL::#OFF _INST_PROP::LOCK_PINS:"
;

Grégory Mermoud

unread,

Jan 17, 2005, 2:48:04 AM1/17/05

to

The equations effectively change. I am quite sure that par is swapping
hard macro pins since my external pins are precisely defined in my macro
and then are not the same in the final design! Your solution proposal
seems to me quite nice. I will try it as soon as I have some time.

Thank you very much for your great help,

Grégory

Grégory Mermoud

unread,

Jan 17, 2005, 3:06:18 AM1/17/05

to

It works. That's fine. Thank you a lot guy.

Bret Wade

unread,

Jan 17, 2005, 9:54:05 AM1/17/05

to

Grégory Mermoud wrote:
> It works. That's fine. Thank you a lot guy.

Nice to hear that. Which suggestion did you use?

Bret

Grégory Mermoud

unread,

Jan 17, 2005, 11:10:09 AM1/17/05

to

I edit my macro by using xdl !