<azonenberg>
either its built weird, or i have a bug in my measurement device
<azonenberg>
Which is totally possible, i wrote it over the last day-ish :p
<azonenberg>
My measuring thingie is also limited to a maximum delay of 128 ns right now b/c of how i built it
<azonenberg>
so i cant measure the delay lines etc yet
<azonenberg>
also ooh this is interesting
<azonenberg>
It seems the path from LUT2 to pin 4 is 20 ps slower than to pin 5
<azonenberg>
But my raw timing data is +/- 78 ps and idk if i have enough averages for that to be statistically significant
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
[X-Scale] is now known as X-Scale
cr1901_modern has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
Zarutian has quit [Quit: Zarutian]
pie_ has joined ##openfpga
promach__ has joined ##openfpga
promach__ has quit [Quit: Leaving]
pie__ has joined ##openfpga
pie___ has joined ##openfpga
pie_ has quit [Ping timeout: 245 seconds]
pie__ has quit [Ping timeout: 246 seconds]
pie___ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
<pie_>
i just reinstalled openwrt and it still doesnt work...
<pie_>
even with ports like 80 and 443
<lain>
note some isps block those ports to prevent people from hosting stuff
<pie_>
sure but i had a dude tell me the isp doesnt block stuff
<pie_>
and they didnt block stuff a while back
<pie_>
but im just out of ideas
<pie_>
but nat hairpinning or loopback or whatever should work...
<azonenberg>
try it on another port
<azonenberg>
i would expect, of all ports, those to get blocked
<azonenberg>
the only thing blocked even more aggressively is 25
<qu1j0t3>
pie_ | sure but i had a dude tell me the isp doesnt block stuff || Don't believe 'a dude' .... verify
<reportingsjr>
My ISP blocked most of my ports one day out of the blue. Had to call and complain to get them opened back up.
<lain>
azonenberg: and .. 135 is it? or was it 139
<lain>
the samba port :P
<pie_>
i tried a few random ports too
<azonenberg>
LOL
<azonenberg>
people actually run that exposed to the net?
<pie_>
my dude is reliable
<lain>
azonenberg: these days I dunno, but ISPs blocked it back when people figured out cable customers for example were all on the same subnet and could open Network Neighborhood and literally see /the neighborhood/
<pie_>
reportingsjr, it would suck if that happened
<lain>
and there hasn't been a reason to unblock it :P
<reportingsjr>
pie_: I first noticed when IRC died and I couldn't reconnect :P
<pie_>
argh why is my networking SO f***ed up
<pie_>
i just changed the port of the service and it wont start :II
<pie_>
maybe its some <1024 crap
<lain>
:x
<lain>
<1024 requires root typically
<pie_>
i know
<pie_>
but its a service
<pie_>
so id expect it to have it handled
<pie_>
no error messages -> wonderful
<pie_>
also cant try it directly on 443 like this
<pie_>
the thing is opwnrt can change the port so its externally something else
<pie_>
but that doesnt work either
<qu1j0t3>
pie_: Unless they actually work at the ISP, how could they be?
<pie_>
they tested it for themselves, but sure that doesnt mean it would work for me
<pie_>
im certainly failing to falsify that it doesnt work
theMagnumOrange has joined ##openfpga
<pie_>
ok so im pretty sure im supposed to be able to ping my external ip, firewall is set to allow that, but i cant.
<pie_>
i am a f****** black hole
<pie_>
ok im done with this for today
<qu1j0t3>
pie_: you can't know whether your isp is passing icmp. sorry to be a cracked record.
<pie_>
looks like thyre not passing anything
<qu1j0t3>
there are some good reasons why they might not want to.)
<pie_>
even though they did not so long ago
<pie_>
im off o/
<qu1j0t3>
pie_: was it something i said!!!1!111!!
pie__ has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
specing has quit [Ping timeout: 240 seconds]
dx has quit [Ping timeout: 240 seconds]
specing has joined ##openfpga
dx has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
digshadow has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
nicdev has quit [Remote host closed the connection]
nicdev has joined ##openfpga
indy has quit [Ping timeout: 246 seconds]
indy has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
m_t has joined ##openfpga
m_w has quit [Ping timeout: 255 seconds]
cr1901_modern has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
cr1901_modern has joined ##openfpga
azonenberg_work has joined ##openfpga
Hootch has quit [Quit: Leaving]
<azonenberg_work>
Soo apparently xilinx is not publishing full CLB timing numbers, setup/hold, etc for virtex ultrascale devices o_O
<cr1901_modern>
Maybe they don't know themselves :P?
<azonenberg_work>
they made some sad excuse about how there's too many paths
<azonenberg_work>
but basically it seems like they dont want to support low level timing on paper etc
<azonenberg_work>
xilinx seems to be moving more toward high level stuff using vivado, HLS, etc
<cr1901_modern>
B/c magic!111one
<azonenberg_work>
and not supporting low level control of the device
<azonenberg_work>
meanwhile here i am doing timing characterization of silicon i dont even have a datasheet for :p
<cr1901_modern>
Reminds me of Yoshi Valley in Mario Kart 64 (if you've never played that, sorry)
<azonenberg_work>
I havent
<azonenberg_work>
never had a n64
<azonenberg_work>
pretty much always been a PC gamer
<cr1901_modern>
Um, that particular track in the game doesn't bother trying to calculate player positions, b/c the track itself has "too many paths"
<cr1901_modern>
I guess it's too taxing on the CPU, but the insn manual even says "calculating player position is impossible"
<azonenberg_work>
lol
* azonenberg_work
looks at a stratix 10 datasheet to compare
<azonenberg_work>
i'm not seeing anything for LUT timing there either
<cr1901_modern>
Have you pinged their twitter acct?
<azonenberg_work>
whose, for what?
<azonenberg_work>
it wouldnt make a difference anyway
<cr1901_modern>
Xilinx, to complain
<azonenberg_work>
theres already forum posts about it
<azonenberg_work>
and they officially said, you wont get the data
<cr1901_modern>
I guess in theory you could use your test rig to measure S/H for paths for each CLB. Automate it by building bitstreams which only use a single CLB :P
<cr1901_modern>
Then document worst case timing
<azonenberg_work>
it would be a lot harder in an fpga
<azonenberg_work>
theres much more complex routing
<azonenberg_work>
with the greenpak its a crossbar and you can measure point to point far easier
<cr1901_modern>
But you can force a particular CLB to be used IIRC. And there's prob a way to measure the approx time to reach the CLB
<cr1901_modern>
and factor that constant delay out
* cr1901_modern
doesn't know how. Hence the "prob"
<azonenberg_work>
eh
<azonenberg_work>
measuring the delay to the clb would be nontrivial
<azonenberg_work>
as it stands now, even on a greenpak
<azonenberg_work>
i'm having a hard enough time b/c i cannot distinugish routing delay from propagation delay in the block
<cr1901_modern>
You could use electrostatics/transmission line theory to predict the delay :3
<cr1901_modern>
It wouldn't be fun or worth it, but you could
<azonenberg_work>
not unless i knew a lot of properties like wire length and dielectric
<azonenberg_work>
it would be nontrivial
<cr1901_modern>
well how do you think Xilinx does it?
<cr1901_modern>
They prob pay engineers good money to do this shit b/c (almost) nobody actually LIKES solving this stuff
<azonenberg_work>
probably a combination of die probing, knowledge of the bitstream format, making single luts on characterization dies
<azonenberg_work>
indirect measurements by making things like ring oscillators
<cr1901_modern>
Well that's easier than using a field solver, yes...
<azonenberg_work>
And it doesnt require knolwedge of all these parameters
<azonenberg_work>
you need to allow for fab proecss variation anyway
<azonenberg_work>
Anyway, i'm having a hard enough time doing it for greenpak :p
<azonenberg_work>
my characterization setup as of now
<azonenberg_work>
interestingly enough the path i reworked seems to be like 150-200ps slower than the others... not sure if trace delay on the gpak devkit or if my rework is higher resistance or something
<rqou>
is that a custom jtag dongle?
<azonenberg_work>
The dongle is a digilent hs1
<azonenberg_work>
just a ftdi
<azonenberg_work>
it was just the first one that came to hand
<azonenberg_work>
i have half a dozen homemade ftdi dongles around
<azonenberg_work>
this one was just closer to the top of the pile :p
diamondman has joined ##openfpga
Zarutian has joined ##openfpga
pie__ has quit [Ping timeout: 246 seconds]
m_t has quit [Quit: Leaving]
pie_ has joined ##openfpga
<rqou>
azonenberg_work: the xilinx jed files violate the spec
<rqou>
there's no "design specification"
<lain>
xilinx violating a spec?
<lain>
is it a day that ends in 'y'?
<lain>
;)
<azonenberg_work>
Lol
<azonenberg_work>
i mean we already knew they didnt check the checksums
<azonenberg_work>
honestly i'm surprised they generate them
s0n1cB00m has joined ##openfpga
azonenberg_work has quit [Ping timeout: 246 seconds]