Hello, what cause these red spaces being in the le...
# general
a
Hello, what cause these red spaces being in the left, upper and bottom corner but not in the right one? and is it normal for IO pins to not be consecutive for same 32bit inputs? also it will be very helpful if there is any information about what should I look for in the design gui other than openlane docs since I've already looked them.
m
if you turn off the wires, what do you see for cell placement?
a
ah, I don't really know how to turn off the wires to see cell placement, which boxes should I turn off?
m
Click the left check box in
a
image.png
m
if you expand instances and deselect the physical instances that should hide the fill cells and make it clear
a
thank you so much for detailed instructions
m
it looks like the instances are closer on the right side. I would guess there is more fanout from those pins pulling the instances towards them
glad to help
a
hey @Matt Liberty, sorry for disturbing again, do you have any idea why these input pins don't connect to processor? I'm pretty sure that I'm using them properly in rtl
v
can you share the netlist
a
I am not sure which file should I share but here is the netlist from results/routing
v
i just want to trace
iomem_rdata
port connection.
a
it is created in the netlist but never used
v
same thing reflecting in layout. Pin created and not connected to anywhere
a
what may cause it to happen?
v
it is considered floating nets. Following found in google
Copy code
If the signal is completely hanging without connecting to anything else, we can remove it.
    If it is completely undriven but is used for loading something else, like a flop, the RTL needs to be revisited and the logic has to be fixed. Any piece of logic cannot have an undriven input.
    If it is a bus, which is partially driven and the bits that are not driven are inconsequential, as in, if they are not expected to drive anything else downstream, then it can be potentially waived off after review. The preference would still be to remove those bits that are not driven and are not used to load anything.
    As a matter of practice, we do not use multi driven nets in design. It can also lead of unnecessary verification holes that can potentially cause a short.
    As others have pointed out, unused nets and flops can get optimised in synthesis tools, but the right practice is to remove them in the RTL itself.
a
thank you so much, I will check it out
also these signals are reported unannotated in almost every reports, is it related to our problem?
m
I don't see any connect to iomem_rdata in your .v
a
yeah me neither but I'm using it in verilog files before synthesis,
m
possibly that logic is unused and therefore removed during optimization
a
it is impossible to be unused since I'm running riscv tests and vivado synthesis and everything works just fine, I can't really understand what is happening