trharoldsen
commented
5 years ago Is this design routed or just placed? If routed, the added LUTs are likely due to the way we handle slice routethroughs.
Have you tried this design with Vivado 2016.2 which is currently the officially supported version for RapidSmith?
As for the error, this is likely an issue due to the order of the placement constraints. Would it be alright to forward the .tcp/placement.xdc and .rscp/placement.rsc files?
On 1/12/19 12:16 PM, mthoonen wrote:
I am trying to modify an AES algorithm in RapidSmith2, but even when I'm not changing anything the design is not implementable in Vivado 2017.2 anymore. It throws the following error during route_design:
[Place 30-642] Placement Validity Check : Instance aesDec/t_STATE_RAM0_reg_0_3_0_5/RAMA of type RAMD32 is not Placeable. Reason: for bel A6LUT The slice contains LUT-RAMs but none of them occupy the DLUT. A DLUT RAM is needed to provide write address signals to the rest of the RAM, for bel B6LUT The slice contains LUT-RAMs but none of them occupy the DLUT. A DLUT RAM is needed to provide write address signals to the rest of the RAM, for bel C6LUT The slice contains LUT-RAMs but none of them occupy the DLUT. A DLUT RAM is needed to provide write address signals to the rest of the RAM, for bel D6LUT Conflicting nets for SLICE_X30Y149.D6LUT.A2 Two net names are: aesDec/i_RAM_ADDR_RD0[1] and aesDec/i_RAM_ADDR_WR0[1], for bel A5LUT The slice contains LUT-RAMs but none of them occupy the DLUT. A DLUT RAM is needed to provide write address signals to the rest of the RAM, for bel B5LUT The slice contains LUT-RAMs but none of them occupy the DLUT. A DLUT RAM is needed to provide write address signals to the rest of the RAM, for bel C5LUT The slice contains LUT-RAMs but none of them occupy the DLUT. A DLUT RAM is needed to provide write address signals to the rest of the RAM, for bel D5LUT Conflicting nets for SLICE_X30Y149.D5LUT.A2 Two net names are: aesDec/i_RAM_ADDR_RD0[1] and aesDec/i_RAM_ADDR_WR0[1]
and 23 similar errors. The program I run in RapidSmith is the following: package maartent.netlistcreator;
import java.io.IOException;
import edu.byu.ece.rapidSmith.design.subsite.CellDesign; import edu.byu.ece.rapidSmith.design.subsite.CellLibrary; import edu.byu.ece.rapidSmith.device.Device; import edu.byu.ece.rapidSmith.interfaces.vivado.VivadoCheckpoint; import edu.byu.ece.rapidSmith.interfaces.vivado.VivadoInterface;
public class QuickImportExport {
|private static CellDesign design; private static Device device; private static CellLibrary libCells; public static void main(String[] args) throws IOException { VivadoCheckpoint vcp = VivadoInterface.loadRSCP(args[0]); QuickImportExport.design = vcp.getDesign(); QuickImportExport.device = vcp.getDevice(); QuickImportExport.libCells = vcp.getLibCells(); String outFileName = args[0].substring(0, args[0].length() - 4) + "tcp"; VivadoInterface.writeTCP(outFileName, design, device, libCells); System.out.println("Done!"); } |
}
(essentially a slightly simplified ImportExportExample)
The device I'm targeting is the zedboard, with FPGA part number XC7Z020-CLG-484-1. The design is implementable when building directly from VHDL and XDC files in Vivado but not after writing an RSCP and running the program above. One thing I noticed is that the amount of LUTs grows with about 80 LUTs more after exporting and importing. Any idea what might cause the error? If linking the VHDL and XDC helps I could do that, what would be the best way to do that?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/byuccl/RapidSmith2/issues/364, or mute the thread https://github.com/notifications/unsubscribe-auth/AMdCws365YzZX_NmHl6C2niInXuUDGRzks5vChhsgaJpZM4Z8wGh.
mthoonen
DallonTG
nelsobe
I am trying to modify an AES algorithm in RapidSmith2, but even when I'm not changing anything the design is not implementable in Vivado 2017.2 anymore. It throws the following error during route_design:
and 23 similar errors. The program I run in RapidSmith is the following: package maartent.netlistcreator;
(essentially a slightly simplified ImportExportExample)
The device I'm targeting is the zedboard, with FPGA part number XC7Z020-CLG-484-1. The design is implementable when building directly from VHDL and XDC files in Vivado but not after writing an RSCP and running the program above. One thing I noticed is that the amount of LUTs grows with about 80 LUTs more after exporting and importing. Any idea what might cause the error? If linking the VHDL and XDC helps I could do that, what would be the best way to do that?