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
No respect of external pins (xilinx)
Started by ●January 15, 2005
Reply by ●January 15, 20052005-01-15
Gr�gory Mermoud wrote:> 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�goryHi 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
Reply by ●January 15, 20052005-01-15
> > 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, > BretYou're great. Preciseness, conciseness. All what I love. :) Thx
Reply by ●January 15, 20052005-01-15
> > 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, > BretI 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 by ●January 15, 20052005-01-15
> 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, > BretAnother 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 by ●January 16, 20052005-01-16
Gr�gory Mermoud wrote:> >> >> 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 ?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 by ●January 16, 20052005-01-16
> 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? > > BretAn 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 by ●January 17, 20052005-01-17
Gr�gory Mermoud wrote:> >> 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�goryHi 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 by ●January 17, 20052005-01-17
> Gr�gory Mermoud wrote: > >> >>> 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 > > > > > 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 >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 by ●January 17, 20052005-01-17
