https://open-source-silicon.dev logo
Join Slack
Powered by
When `pdngen` complains about : "Failed to generat...
# openroad
t
When 
pdngen
complains about : "Failed to generate full power grid". Is there a way to get it to continue anyway so I can see what's wrong ? Because there it just stops and I have no clue why, so if I was seeing what it's doing maybe I could figure it out.
m
@tnt Just a guess, but what about 
"FP_PDN_CHECK_NODES": false,
t
Nope 😕
m
Anything in the pdn log files?
t
Not that I could see.
For context :
This is the overview of a run that works. then I tried instanciating two of the macros on the right, they just fit one above the other.
But when I do that I get the error above.
My current guess is that because there is no longer space for standard cell rows when I stack the two macros, it doesn't generate vertical 
met4
rails until the end of the area anymore, so there is none overlapping the macro and they don't get connected. ( the macro have 
met3
horizontal rails declared as pns and they get connected to the 
met4
vertical power rails ).
But (1) it's a theory and (2) even if it's what's happening I'm not sure how to tell PDNgen to create 
met4
vertical rails all over the area and not just where there are standard cells.
Ok, I think I confirmed it ... just no sure how to fix it ..
👍 1
p
Sylvain, what and how large is your design ?
t
This was like 800u by 300u or something.
The issue is that because I put two macro on the left side (as seen by the picture above), all the "Rows" were cut and none go to the right edge of the "die area". So all the calls to getCoreArea() only return the area on the left side and stops short of my macros, which means no 
met4
vertical straps are generated above the macro because they only cover the "CoreArea".
p
Lengt 800u en width 300u ? ROM size is ?
16bit and how many words ?
Could you extract parasitic and routing capacitance to add up simulation to determine timing parameters ?
t
The whole core is actually 
"DIE_AREA": "0 0 1030.40 225.76"
And the ROM macro are like 112.3u high, and 144.9u wide and contains 32 kbits.
p
16bit, 2K Words ?
t
It's actually 8 bits 4096 words.
Here I instanciated two of them.
p
Can you generate also 16bit wide version ?
t
Timing is WIP. Goal is to get it to < 10 ns access time, but this particular version is not there yet and this was for a retro system where it's running at like 5 MHz so it wasn't a concern.
Yes, I can create a 16 bits version. Physically it's organized as a 128 word lines of 256 bits and those 256 bits get muxed down to 8 bits, but you can remove one layer of muxing and get it to 16 bits.
p
Did you provide some techniques to reduce power [e.g. extra xor bit to invert number of 0/1’s, pre charge only #output bits, …].
Why not more words and less bits ?
t
Goal is to try and keep the macro "squarish".
p
A matter of shape [square … rectangular] ?
t
One bit is 0.35u high but a word is 1u wide ...
I do only precharge the actual bits that will be used for the outputs.
p
Anny idea about expected static/dynamic power consumption e.g. @ 10 MHz
t
So out of the 256 bit lines, only 8 will actually use current.
p
👍
t
No, power estimates are still TODO sorry. I need to finish the timing first. I did some pre-testing on how to simulate that on spice and measure it, but I haven't actually run them yet through.
p
8 bit determines current… Does “1”, “0” consumes the same current ?
t
No, 
1
will consume more ATM.
(the output buffer is an inverter, so an output 
1
means a 
0
in the cell output meaning the nfet is active and will figth the bit line pre-charge)
Well in the version above it's not even a pre-charge, it's a constant pull up of ~ 20uA IIRC so you get 160 uA worse case right there.
p
Maybe IIRC could be optimised for given maximum access time ?
Cant we go also for a pre-charge version ?
26 Views
Open in Slack
PreviousNext
Powered by