std::logic_error: [what(): unconnected pins]

[qaziullah]

While trying to run custom aes_sbox design using verica tool, I ended up getting the following error.

command run was bin/release/verica -c config/verica.json

while trying to trace the source of error, I got to this->m_config->execute() function call in the function definition of Service::execute() in Service.cpp file. i.e.

void
Service::execute()
{
    /* Execute configuration */
        std::cout<<"line debug:75"<<std::endl;
    this->m_config->execute(this->m_settings, this->m_state);
}

here is config/verica.json for the refefence. verica.json

[jrichterb]

Hi,

Unfortunately, it is hard to tell what is going wrong here without having access to the design file. Would it be possible to upload your custom aes_sbox file?

Thanks Jan

[qaziullah]

sure, here is the design file.

[qaziullah]

sorry about that, closed issue by mistake. Reopening the issue and here is the design file. aes_toffoli.verilog.pdf [it is a text file, as *.v file was not supported here so I changed the extension to .pdf for uploading the file. ] respective jason file. annotations.json

[jrichterb]

I just checked your design file and found the issue.

You are using gates that are currently not supported by VERICA. We only support DFF, AND, NAND, OR, NOR, XOR, XNOR, BUF, and NOT. Your design file contains gates like DFFR_X1 or AOI211_X1 which lead to the error message. To solve this problem, you have to restrict the design compiler by using the following instructions:

set_dont_use [get_lib_cells NangateOpenCellLibrary/HA*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/AOI*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/OAI*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/MUX*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/CLKBUF*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/OR3*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/OR4*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/OR5*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/NOR3*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/NOR4*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/NOR5*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/XNOR3*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/XNOR4*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/XNOR5*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/XOR3*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/XOR4*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/XOR5*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/AND3*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/AND4*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/AND5*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/NAND3*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/NAND4*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/NAND5*]
set_dont_use [get_lib_cells NangateOpenCellLibrary/BUF*]

You can also find more details in the README.

If anything else does not work, just let me know. Thanks!

[qaziullah]

Hi @jrichterb,

I have re-synthesized the netlist with the above restrictions but still getting the same error. new netlist is attached here for your reference. aes_toffoli.new.v.txt.

[jrichterb]

Hi,

Sorry for my late response. I just checked the netlist, and it looks like there is something damaged in your design. Many wires are just named UNCONNECTED175 which seems wrong and probably causes the issues.

[qaziullah]

Hi,

Thanks for the response, I did find some issues in the netlist. After fixing those issues, I have verified the netlist with functional Simulation. This time tool is parsing netlist and is progressing to next stages but gets stuck after SCA configuration step.

I am attaching verica.json, annotations.json and aes_toffoli.v here for the reference. aes_toffoli .v.txt annotations.json verica.json

[jrichterb]

Hi,

I have the same problem on my machine. I suspect that the uniformity test is too time-consuming for your example and will therefore not be terminating. I also changed the settings and performed a first-order d-probing test (setting uniformity to false and probing to true), which finishes in under one minute.

[qaziullah]

I think this design is probably too large, maybe that's why it is too time-consuming. Anyways, I just wanted to run Fault injection analysis (especially SIFA), so after running verica with following config SCA->false, fault-inject -> enabled, strategy -> sifa) I got this report I believe this means that the design is SIFA tolerant. Is this correct?

[jrichterb]

Hi, the results of the analysis mean that the detection signal of your design under test is independent of the secret data. However, it was recently shown, that there is may be some SIFA leakage based on the output values (see [FGS23]), which VERICA does not yet test for.

Cheers, Jan

[FGS23] Jakob Feldtkeller, Tim Güneysu, Patrick Schaumont: Quantitative Fault Injection Analysis. ASIACRYPT (4) 2023: 302-336