Hi Mike,
For the JTAG you should be able to set the technology to virtexup (65). In the latest version of the GPL library, this technology value is overloaded with different names (virtexup, kintexup, ultrascalep) for increased clarity. The virtexup setting connects the AHBJTAG to the TAP of the Ultrascale+ device.
For the pad issue, can you check the Vivado project file and make sure the file lib/techmap/unisim/pads_unisim.vhd is included. That’s the file where unisim_outpad is implemented.
Best regards,
Martin
Martin (@ronnback),
In the xconfig tool I don’t see an option for virtexup. Xilinx-KintexUltra is the only option available that includes “Utrascale” in the name. Would I have to manually edit the config.vhd file to set the technology to virtexup (65)?
For the pad issue, yes I do see pads_unisim.vhd included. In fact, in the elaborated design (under RTL analysis) in Vivado, I can see the OBUF Xilinx primitive instantiated (I’ll try and attach a screen shot).
But for some reason, during synth/P&R, the unisim_outpad becomes a blackbox. I’m getting a bunch of these warnings:
WARNING: [Constraints 18-548] Could not create ‘slew’ constraint because invalid SLEW value ‘0’ specified. ‘slew’ is ignored by Vivado but preserved for implementation tool. [./grlib-gpl-2021.2-b4267/designs/leon3mp/leon3mp.vhd:686]
But I haven’t figured out why Vivado doesn’t like the default SLEW parameter for the unisim_outpad module. The default values for the parameters should be selecting the “ttl” option, and the slew=0 should instantiate the OBUF.
entity unisim_outpad is
generic (level : integer := 0; slew : integer := 0;
voltage : integer := 0; strength : integer := 12);
port (pad : out std_ulogic; i : in std_ulogic);
end ;
…
ttl0 : if level = ttl generate
slow0 : if slew = 0 generate
op : OBUF generic map (drive => strength, IOSTANDARD => “LVTTL”)
port map (O => pad, I => i);
I don’t understand why Vivado is having issues with this.
Thanks,
Mike
Hi Mike,
Sorry for the radio silence. I’m not sure what’s happening here either. Did you get this working? Could you post your instantiation of the pad.
Best regards,
Martin
Hi Martin (@ronnback),
The only way I could get this working was to completely remove the ‘can_tx_pad’ instantiation. Luckily our design will not need the CAN interface. However, this seems more related to the OBUF primitive, so it’s possible I could run into this issue again in the future if we use OBUFs in our design.
Going back to your earlier suggestion, how would I select the ‘virtexup’ (65) option for the technology? Would I manually edit the ‘config.vhd’ file, after it’s generated by xconfig?
Thanks,
Mike
Hi Mike,
Yes, you could edit the config.vhd file. xconfig is typically used for initial configuration of a design and when you are satisfied, you can leave the configuration tool out of the loop.
/Martin
Hi Martin,
Yes, editing the config.vhd file to remove the ‘can_tx_pad’ instantiation is a fine workaround for now. But it doesn’t get to the root cause of what was causing the error. I’m concerned I may run into similar issues in the future, if I have to add an OBUF primitive.
Regarding your earlier suggestion, how would I select the ‘virtexup’ (65) option for the technology? Would I manually edit the ‘config.vhd’ file, after it’s generated by xconfig?
Thanks,
Mike
