f4pga-arch-defs
f4pga-arch-defs copied to clipboard
WIP - utils/vlog: More tests from timing tutorial.
-
Adding "Figure 43 - XXX Single Port RAM", fixes #630 .
-
Adding "Figure 44" - Synchronous Single Port RAM, fixes #631 .
-
Adding "Figure 45" - Asynchronous Single Port RAM, fixes #632 .
-
Adding "Figure 46" - Synchronous Dual port RAM with independent clocks, fixes #629 .
-
Adding Single Port ROM.
Signed-off-by: Tim 'mithro' Ansell [email protected]
FYI - @acomodi + @kgugala
@kgugala - Unsure if I will have time to continue to work on this, it is just a rebase of stuff I found from a long while back. Do you want to take a look at it and see if you can get it working?
Hmm, it looks like the red CI is a conda failure. I'll force another run
@kgugala How is this pull request going?
I fixed golde model for single port ram, and cmake deps for the rest of the tests.
the remaining tests fail on implicit FFs (#652)
@kgugala Could you look at finishing of this pull request and getting it merged?
@mithro I addressed most of the issues that were keeping CI red. Right now the dsp_conditional
fails with:
# Load Timing Constraints took 0.00 seconds (max_rss 8.7 MiB, delta_rss +0.0 MiB)
Error 1:
Type: Packing
File: /tmp/really-really-really-really-really-really-really-really-really-really-really-really-really-long-path/conda/conda-bld/vtr_1557246610590/work/vpr/src/pack/cluster.cpp
Line: 1984
Message: Can not find any logic block that can implement molecule.
Atom dsp_combinational (dsp_combinational)
It looks like the test does not synthesize correct verilog file. This is the eblif we get in the dsp_in_registered
test:
.model top
.inputs a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15 b16 b17 b18 b19 b20 b21 b22 b23 b24 b25 b26 b27 b28 b29 b30 b31 m
.outputs out0 out1 out2 out3 out4 out5 out6 out7 out8 out9 out10 out11 out12 out13 out14 out15 out16 out17 out18 out19 out20 out21 out22 out23 out24 out25 out26 out27 out28 out29 out30 out31 out32 out33 out34 out35 out36 out37 out38 out39 out40 out41 out42 out43 out44 out45 out46 out47 out48 out49 out50 out51 out52 out53 out54 out55 out56 out57 out58 out59 out60 out61 out62 out63
.subckt dsp_combinational a[0]=a0 a[1]=a1 a[2]=a2 a[3]=a3 a[4]=a4 a[5]=a5 a[6]=a6 a[7]=a7 a[8]=a8 a[9]=a9 a[10]=a10 a[11]=a11 a[12]=a12 a[13]=a13 a[14]=a14 a[15]=a15 a[16]=a16 a[17]=a17 a[18]=a18 a[19]=a19 a[20]=a20 a[21]=a21 a[22]=a22 a[23]=a23 a[24]=a24 a[25]=a25 a[26]=a26 a[27]=a27 a[28]=a28 a[29]=a29 a[30]=a30 a[31]=a31 b[0]=b0 b[1]=b1 b[2]=b2 b[3]=b3 b[4]=b4 b[5]=b5 b[6]=b6 b[7]=b7 b[8]=b8 b[9]=b9 b[10]=b10 b[11]=b11 b[12]=b12 b[13]=b13 b[14]=b14 b[15]=b15 b[16]=b16 b[17]=b17 b[18]=b18 b[19]=b19 b[20]=b20 b[21]=b21 b[22]=b22 b[23]=b23 b[24]=b24 b[25]=b25 b[26]=b26 b[27]=b27 b[28]=b28 b[29]=b29 b[30]=b30 b[31]=b31 m=m out[0]=out0 out[1]=out1 out[2]=out2 out[3]=out3 out[4]=out4 out[5]=out5 out[6]=out6 out[7]=out7 out[8]=out8 out[9]=out9 out[10]=out10 out[11]=out11 out[12]=out12 out[13]=out13 out[14]=out14 out[15]=out15 out[16]=out16 out[17]=out17 out[18]=out18 out[19]=out19 out[20]=out20 out[21]=out21 out[22]=out22 out[23]=out23 out[24]=out24 out[25]=out25 out[26]=out26 out[27]=out27 out[28]=out28 out[29]=out29 out[30]=out30 out[31]=out31 out[32]=out32 out[33]=out33 out[34]=out34 out[35]=out35 out[36]=out36 out[37]=out37 out[38]=out38 out[39]=out39 out[40]=out40 out[41]=out41 out[42]=out42 out[43]=out43 out[44]=out44 out[45]=out45 out[46]=out46 out[47]=out47 out[48]=out48 out[49]=out49 out[50]=out50 out[51]=out51 out[52]=out52 out[53]=out53 out[54]=out54 out[55]=out55 out[56]=out56 out[57]=out57 out[58]=out58 out[59]=out59 out[60]=out60 out[61]=out61 out[62]=out62 out[63]=out63
.cname dsp_combinational
.end
which is actually an eblif of the dsp_combinational
module (there is no clk input, nor any $dff module). This design is not implementable in the test architecture generated for this design, where dsp_combinational
tile cannot be connected directly to input buf.
also in case of multiple_instance
(this test actually passes) we get this eblif:
.model top
.inputs a b cin
.outputs cout sum
.subckt adder a=a b=b cin=cin cout=cout sum=sum
.cname adder
.end
which is not a correct eblif of the top multiple instance module (which instantiates 64 full adders), but rather a single full adder. Since in this arch we have 64 full adders, we can implement this design using only one of it.
Is this a cmake problem? We feed yosys with autoinferred verilog include, instead of the top level file?
Oh. I see the eblifs in the tests are generated with vpr_pbtype_to_eblif.py
so the vpr_pbtype_to_eblif
looks for leafs only https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/utils/vpr_pbtype_to_eblif.py#L83
and generates the eblif from that one.
The find_leaf
function returns only leaf pb_types (the ones having eblif tag defined) https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/utils/lib/pb_type.py#L22
So we never generate eblif from the top level.
GitHub
FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. - SymbiFlow/symbiflow-arch-defs
GitHub
FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. - SymbiFlow/symbiflow-arch-defs
@kgugala The eblif issue might already be found in https://github.com/SymbiFlow/symbiflow-arch-defs/pull/703
It looks like we can handle the cases where the top module is not a blackbox with Yosys - we can generate the test blif from verilog. I did some intial tests on that and it looks promising.
Now it looks like the test arch.xml file is incorrect. e.g. in the multiple_instance
case the device layout is generated in a way that it defines only 3 IBUFS (for only one adder), while the design which is suppose to be packed into this arch has 192 inputs (64 adders, 3 inputs each). VPR fails with:
Message: Failed to find device which satisifies resource requirements required: IBUF: 192, OBUF: 128, TILE: 64 (available IBUF: 3, OBUF: 2, TILE: 1)