<tnt>
Mmm ... nextpnr inserted a pass-thru lut for a carry ... for no reason I can see. I mean that CO is connected to the I3 of a LUT (and only that).
pie___ has quit [Remote host closed the connection]
<sorear>
ice40?
<tnt>
yeah.
<tnt>
Like it placed the whole adder correctly ... except the top bit, which for some reason got placed at the completely different place
<tnt>
Actually it does that more than once.
<sorear>
sounds like something is going weird in the packing step
<tnt>
yeah ... almost like a "off by one" somewhere and it doesn't constrain the top bit and ends up having to put a pass-through lut.
<tnt>
But that 'glitch' ends up being nearly 15% of my critical path.
<sorear>
i don't fully understand this, but I believe the packing step reconstructs adders from the netlist, which are then placed as a unit
<tnt>
Interestingly in process_carries there is a small snippet of code that's commented ... and when I uncomment it, that seems to fix that issue and it now processed the entire chain at once and that bumps my f_max by 10% ...
<tnt>
Arf, but for another design it decreased it by 10% so that might just be random.
catplant has quit [Quit: WeeChat 2.2]
catplant has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
emeb has quit [Quit: Leaving.]
Bob_Dole has quit [Ping timeout: 268 seconds]
Bob_Dole has joined ##openfpga
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
Flea86 has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
f003brv has joined ##openfpga
rohitksingh_work has joined ##openfpga
futarisIRCcloud has joined ##openfpga
Bike has quit [Quit: Lost terminal]
f003brv has quit [Quit: Page closed]
ZipCPU|Laptop has joined ##openfpga
<sorear>
gain cells are neat
s_frit_ has joined ##openfpga
s_frit has quit [Ping timeout: 272 seconds]
<tnt>
gain cells ?
sgstair has quit [Disconnected by services]
sgstair has joined ##openfpga
tms_ has left ##openfpga [##openfpga]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt>
daveshah: Looking forward to the opt pass stuff :) Seems to work for me at least.
<daveshah>
thanks!
<daveshah>
I will look at the carry pass through stuff. It could be that there is a bug in there
<daveshah>
Yosys can generate some strange constructs too
<tnt>
daveshah: Well, I just uncommented some stuff that's already there and it seemsed to fix it : https://pastebin.com/uZihH8tR
<tnt>
AFAICT it doesn't consider the last LC to be "in the chain" because it has no "carry out".
<daveshah>
I think there will be a few more changes to the other chain stuff to make that work for all cases
<daveshah>
I know I commented that out for a reason
<daveshah>
Separately, the way we do carry pass through should also be improveable
<tnt>
yeah, I figured, but I couldn't firgure out why :p I had hoped you'd remember :p
GuzTech has joined ##openfpga
<tnt>
It's amazing how easy it is to notice (as a human) that a placement is "weird" ... but how to translate that into code that doesn't produce those placement is ... tricky.
<tnt>
like ... 16 bit register, all bits have the same control set, all inputs come from another 16b reg, no logic. And it's spread across like 8 tiles.
<daveshah>
It's quite possibly not suprising in that case
<daveshah>
If the outputs fan out to more than one signal in different places than the output then it will probably pull the placement stronger than the input
<daveshah>
A single reg to reg path will have a lot of budget too
<tnt>
output go to an adder so not sure about that. But it's no where in the critical path, so the placer just probably didn't care and has no reason to "make it look pretty :p". I was just browsing the placement with the floorplan tool.
<q3k>
tnt: isn't all of p&r basically an AI problem, trying to approximate what a human would do with enough time? :P
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+3/-0/±0] https://git.io/fp6vk
<_whitenotifier>
[whitequark/Glasgow] whitequark 31fd5ce - arch.boneless: new architecture (Boneless v2).
<pie_>
whitequark: does "forward current" mean it wont work under that current? lowest forward current i see for my current (pun not intended) search is 2mA
<whitequark>
i think it's the typical value for some given intensity
<pie_>
there's a very large disparity between the brightnesses of the two colors though, red has like 5 times the lumens of green
<pie_>
is it a human brightness perception thing? (could it be that big?)
<whitequark>
candela
<whitequark>
and yes
<whitequark>
you want cd not lm
rohitksingh has quit [Ping timeout: 268 seconds]
<pie_>
cd is human compensated?
<pie_>
ah wait sorry
<pie_>
this says "lv" not "lm".
<whitequark>
yes
<pie_>
"Iv (mcd) @ 20mA"
<whitequark>
lv or iv?
<whitequark>
oh
<whitequark>
intensity (visual)
<pie_>
ok thats not an L thats an I >:I
<_whitenotifier>
[whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fp6dw
<whitequark>
so that's mcd
<_whitenotifier>
[whitequark/Glasgow] marcan 911d659 - Move three refspecs 0.1mm for symmetry against other side.
<pie_>
what i find strange is the green needs the bigger voltage but its the darker one, so i probably need to have different voltages in different directions and that ruins my neato design :c