Open gzyangcs opened 11 months ago
I think this is a tooling problem. As far as I can tell, the ASSERT_KNOWN macro is defined correctly, with two required arguments and two optional ones that can come after.
I'm afraid I don't know the "Presto HDLC" tool: is it something that OpenTitan explicitly supports?
@rswarbrick yes, i blieve the macro is fine too. The "Presto HDLC" is running by DC to compile source file. I had suspend error is come from DC. So i running DC by script and it shows everything is fine. So, do i need to reinstall DC?
If I understand you correctly, that's an IT question about how you install your synthesis tool. I'm afraid this probably isn't the right place to ask :-)
@msfschaffner - do you know the minimum version of DC required to synthesize? This is using O-2018.06-SP1 which is quite old.
@vogelpi - do you know if anyone has tried synth on just the AES using the DC flow? I am wondering if the icarus flist (/home/work/test/opentitan/scratch/master/aes-syn-dc/default/syn-icarus/lowrisc_ip_aes_1.0.scr
) will work correctly when using DC, as I would expect these asserts to be ifdef'd/compiled out for synthesis/elab.
@cdgori , I am aware that @ballifatih has been experimenting with the AES S-Box and DC quite recently but I don't know whether he used the in-tree synthesis flow or something custom. I am aware that also someone else from the community tried to synthesize AES with DC recently and faced some issues. But there, I don't have any visibility into the used tool version or flow.
I would also expect these asserts to get removed for synthesis/elab. This is a very good point Chris. In this particular case here, synthesis fails in prim_arbiter_fixed.sv
but AES doesn't use this primitive, nor does any of the dependencies. At least we don't compile the file in the Yosys setup which is able to generate a functionally correct netlist (see hw/ip/aes/pre_syn/syn_yosys.sh
).
I used the other synthesis script for AES S-box:
./util/dvsim/dvsim.py hw/ip/aes/syn/aes_syn_cfg.hjson
. I also get some errors now when I try with the other aes_gtech_syn_cfg.hjson
script. I do not know what is the difference between the two synthesis scripts though.
Since I was able to get a netlist consisting of library cells with aes_syn_cfg.hjson
, that was enough for me back then.
Description
Hello sir, i want to inject some faults into AES with tool synfi which needs netlist, so i tried to synthsis IP AES with tool dc, the command is below:
opentitan/hw/ip/aes/syn$ dvsim ./aes_gtech_syn_cfg.hjson --purge --local
then, errors encountered! The build.log shows that error happens at command
analyze -vcs "-sverilog +define+${DEFINE} -f ${SV_FLIST}" > "${REPDIR}/analyze.rpt"
When i check analyze.rpt, it notes me that
"Error: ../src/lowrisc_prim_arbiter_0/rtl/prim_arbiter_fixed.sv:141: The number of parameters for the 'ASSERT_KNOWN' macro doesn't match its definition. (VER-927)"
.The problem is i did not chage any RTL & hjson, and i did't found problems when check the define ASSERT_KNOWN.
The ASSERT_KNOWN defined at
prim_assert_standard_macros.svh
isThe ASSERT_KNOWN called at
prim_arbiter_fixed.sv:141
isBut, it is fine if change
ASSERT_KNOWN(ValidKnown_A, valid_o)
toASSERT_KNOWN(ValidKnown_A, valid_o, clk_i, !rst_ni)
.And, the same error when i synthesis other IPs like lc_ctrl. So what can i do next?
Your help would be greatly appreciated.
Enviroment
OS: Ubuntu 20.04.1 LTS Kernel: Linux 5.8.0-38-generic Architecture: x86-64 Opentitan: lastest
Logs
The build.log is below:
And the analyze.rpt show below: