No respect of external pins (xilinx)

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

Reply to
Grégory Mermoud
Loading thread data ...

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:

formatting link

Regards, Bret

Reply to
Bret Wade

formatting link

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

Reply to
Grégory Mermoud

formatting link

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 ?

Reply to
Grégory Mermoud

formatting link

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

Reply to
Grégory Mermoud

formatting link

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

Reply to
Bret Wade

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

Reply to
Grégory Mermoud

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:" ;

Reply to
Bret Wade

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

Reply to
Grégory Mermoud

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

Reply to
Grégory Mermoud

Nice to hear that. Which suggestion did you use?

Bret

Reply to
Bret Wade

I edit my macro by using xdl !

Reply to
Grégory Mermoud

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.