Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Problems synthesizing AES code

Status
Not open for further replies.

Sunayana Chakradhar

Member level 5
Joined
Oct 24, 2014
Messages
85
Helped
2
Reputation
4
Reaction score
2
Trophy points
8
Activity points
742
Hello All,

I am trying to synthesize AES encryption algorithm in vivado which was uploaded on open cores as shown in the link below

https://opencores.org/project,aes-128_pipelined_encryption

When I synthesize it, i get the following errors

[Place 30-415] IO Placement failed due to overutilization. This design contains 258 I/O ports
while the target device: 7z020 package: clg400, contains only 255 available user I/O. The target device has 255 usable I/O pins of which 0 are already occupied by user-locked I/Os.
To rectify this issue:
1. Ensure you are targeting the correct device and package. Select a larger device or different package if necessary.
2. Check the top-level ports of the design to ensure the correct number of ports are specified.
3. Consider design changes to reduce the number of I/Os necessary.

[Place 30-68] Instance clk_IBUF_BUFG_inst (BUFG) is not placed

[Place 30-99] Placer failed with error: 'IO Clock Placer failed'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.

Can someone tell me how to rectify these errors?
 

Without going into the design details (AES encryption details)...

What can be done is already mentioned in simple English #1 to #3.

If you cannot use a larger device (#1) then go to #3.
I am assuming you have specified the correct no. of top-level ports (#2), else re-check.
If #1 is not feasible then #3 is your only option. Reduce the encrypt key size and data.

I see in the module Top_PipelinedCipher,
parameter DATA_W = 128, //data width
parameter KEY_L = 128, //key length
So use 64bits or 96bits or some other value as per your project requirements. I will not look into the RTL details, but the fact that the data & key are parameterized suggests that changes might be easily done at the top-level.
 
Last edited:

Even when you have compiled it, what do you intend to do with it?
This core is not intended as a top level design, it's an IP block for you to put into your design.

You could easily write a top level wrapper around the core to make it fit and not completly remove all the logic. If you were using Quartus you could use virtual pins to avoid IO limitations, but as it's xilinx you get no such option.
 
This core is not intended as a top level design, it's an IP block for you to put into your design.

You could easily write a top level wrapper around the core to make it fit and not completly remove all the logic.

Correct! If implemented as a non top-level module then this is no problem.
Probably the OP has such an intention, and is currently analyzing the implementation ability of the free core. Might have inadvertently used it as a top-module.
 

Even when you have compiled it, what do you intend to do with it?
This core is not intended as a top level design, it's an IP block for you to put into your design.

You could easily write a top level wrapper around the core to make it fit and not completly remove all the logic. If you were using Quartus you could use virtual pins to avoid IO limitations, but as it's xilinx you get no such option.

Tell the synthesis tool to not insert I/O, Vivado allows you to make dcp files with no I/O, but as I recall that will require you disable logic removal during place and route (inflating the resource utilization).

The other option is to add a shift register for all inputs and all outputs that don't go to pins and tie the SDO/SDI pins of the shift register to pins, compile that to get a resource estimation and to see if it will meet your clock frequency constraints. That way you'll restrict the number of pins used to clock, reset, in_sdo, in_sdi, out_sdo, out_sdi, out_en (used to select between the output of the UUT and the shifting data). The whole idea here is to have a non-functional design for resource estimation.

If you need to test the design add Vivado debug cores to the design to drive the I/Os of the UUT with the VIOs and capture outputs with ILAs.
 

Hello ads-ee, i have to connect this AES IP core to AXI module and make an internal IP out of it with no I/O's going external of the FPGA. All the I/O's of the AES IP core have to be converted into internal nets. How am i supposed to do it? Do you have any example or document which explains this procedure?
 

Put the AES IP core and the AXI module in a new top-level and then it is ready to be used as an internal IP. Defining the input and outputs ports of the new top-level module and port-mapping them to the AES IP core and the AXI module is all you need to do.
 

All the I/O's of the AES IP core have to be converted into internal nets. How am i supposed to do it?
Huh? It's a IP core it shouldn't have any IO primitives in it. You should be able to instantiate it in a top-level module and create signals/wires to connect to it and your other AXI module(s).

If you need tutorials on instantiating modules in other modules, then you really need to learn the language basics before tackling a project like this.
 

this type of thing can even be done with the graphical interface in vivado. I don't understand what is the struggle here.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top