https://open-source-silicon.dev logo
Join Slack
Powered by
Lets continue in a thread
# openlane
m
Lets continue in a thread
Did you try the tristate test in multi tools?
j
No, you mean the formal test?
m
--test-tristate-z
j
running now. Doesthat use RTL or netlist?
m
Gl netlist
That test was added when we discovered openlane was silently adding buffers after the tristates
j
does it test that a) when a module is active b) the wishbone output can either be Z or driven?
m
Just that when active is low the oitputs are z
j
ya so that should be ok. Our problem is the output is z when it should be active.
(or actually, the output is not connected at all; see netlist in the original post)
2022-06-17 10:07:28,546 - project         - INFO     - tristate z test pass
m
oh dear
but going back to your netlist, it looks like logic -> ebuf -> buf, when we want logic -> ebuf
j
ya; 
wbs_dat_o[0]
does not have a driver
it's like the repeaters input and output are swapped; and even if we swap them I don't know if a buf_12 passes high-Z properly
m
no it won't
tristates need to be last
but the tristate z test should fail surely
j
ok, that confirms my suspicion
but I presume the repeater was inserted to fix some drive strength?
m
ahhh
yeah could be.
I've just not seen that before. but buffer test should fail - it did on the known bad designs before we changed the config, but that was in mpw2
image.png
j
yeah I'm also not sure about that test. What I do know is that we see in the VCD exactly what we would expect from the netlist snippet: 
wbs_dat_o[0]
has no driver. E.g. 
wbs_dat_o[1]
happens to not have this repeater and works fine.
m
I suppose as there is no driver the output could also float
right so only some outputs get it also
j
yep. We see it in like 1/100 outputs or so.
m
@jeffdi @donn could you take a look pls
d
We can yes, but likely won't get fixed today. @Jasper van Woudenberg You're comfortable enough using a workaround for now?
m
his plan is to edit the post placement netlist and then get openlane to continue from there
what's your workaround?
I don't actually know how to get openlane to start from a post placement netlist
d
That. :)
🙌 1
m
please tell us how!
d
./flow.tcl -design xxx -to placement
[edit]
./flow.tcl -design xxx -last_run
theoretically, haven't actually tested that in a while. but i think the mpw-5 toolchain doesn't have this functionality
m
dang. just as well the mpw6 toolchain installs in less than 3 minutes!
that is cool functionality
I'll have to try it
j
that's cool indeed. Right now, we're just hacking directly in flow.tcl; after run_placement we call our own script to fix up the netlist. Testing...
a
I'm guessing it was added by the resizer (during 
repair_design
). There were a couple of recent fixes in the resizer for tristate issues, but I can't tell if it will help here. Worth testing with a very recent Openlane build (`2022.06.06_01.36.41`or newer)
j
Thanks for the suggestion. I'm reluctant to upgrade to a new build system on the tapeout date 😉 What we did find is that this is caused by 'inout' ports; changing it to 'output' it succeeded.
a
Makes sense 🙂 Would be good to root cause this after the tape out date, since it might be a bug in the OpenROAD resizer.
j
yep, I'll make a proper bugreport and attach our run files
a
Great!
Open in Slack
PreviousNext
Powered by