<sb0>
WARNING:PhysDesignRules:1362 - Unexpected programming for comp OSERDESE2_107
<sb0>
with TRISTATE_WIDTH. DATA_RATE_TQ set DDR expects TRISTATE_WIDTH to be set 4.
<sb0>
so, why do they have two parameters?
<sb0>
ah, it's not DATA_WIDTH == TRISTATE_WIDTH
fengling has joined #m-labs
fengling has quit [Client Quit]
<whitequark>
ImportError: No module named 'mibuild'
<whitequark>
wtf
<sb0>
so that was from ISE
<sb0>
and vivado: ERROR: [Drc 23-20] Rule violation (AVAL-69) OSERDES_DataWidth4Tri1 - Unsupported programming for OSERDESE2_123. DATA_WIDTH set greater than 4 requires TRISTATE_WIDTH to be set to 1
<GitHub196>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYV9U
<GitHub196>
artiq/new-py2llvm ef4a06a whitequark: Merge branch 'master' into new-py2llvm
* rjo
has finally debugged an extremely annoying issue were my pipistrello would only work in the presence of a human (many weeks of statistics).
<mithro>
rjo: what was the issue?
<rjo>
the very obvious (after debugging) reason: auto-suspend of the monitor that was powering the thing.
<whitequark>
ha!
<whitequark>
wait, monitor?
<rjo>
monitor with integrated usb hub.
<whitequark>
oh. that's evil.
<rjo>
yes. a nice monitor with an ir detector that turns off a minute or so after the last warm-blooded animal leaves the room.
<whitequark>
hmmm, a crash inside the x86 code generator
<rjo>
whitequark: by the way. if you are playing with the pipistrello now, give https://github.com/jordens/openocd a try. also for flashing and loading bitstreams to the fpga. should be much nicer than xc3sprog/fpgaprog and will probably be what you want to use anyway for or1k.
<mithro>
hey everyone - Has anyone thought of submitting a talk to Linux.conf.au conference here in Australia? It is kind of a misnamed conference - it should really be OpenSource.conf.au and I'd love to see talks about the m-labs related stuff
* whitequark
has considered LCA until they looked at the price
<sb0>
hmm, 9:20 flight from HK
<mithro>
whitequark: Speakers get free tickets
<whitequark>
hrm
<mithro>
sb0: yeah - Australia is sucky far away from everywhere :(
<mithro>
whitequark: You can even apply for accommodation+travel assistance
<sb0>
why does adding another PLL somewhere else in the design break ethernet? wtf.
<sb0>
for a moment, it seemed 7-series were better than slowtan6, but no, I had been lucky before and they're the same crap
<mithro>
sb0: how much do you think is the devices themselves verses the ISE/Vivado tools?
<whitequark>
hm, it explodes *only* inside llvmlite. not via lli. odd.
<whitequark>
ssert(ValueVTs.size() == 2 && "Only two-valued landingpads are supported"); well ffs
<whitequark>
have they maybe considered supporting output besides that which clang emits, eh??
<sb0>
whitequark, you want to go to LCA?
<sb0>
mithro, hard to tell
<whitequark>
sb0: sure, conf seems interesting and AU is pretty fascinating too
<sb0>
The close date for Presentations, Tutorials, Prototypes, and Miniconf proposals is midnight Sunday 2nd August.
<mithro>
Just a FYI, I'm on the paper's committee and been attending the conference for 12 years now
<whitequark>
er--haven't considered presenting I guess
<whitequark>
hmm
<sb0>
so, hires-rtio seems to work fine when plugged to the SDRAM PLL, and everything falls apart when adding another PLL for it
<sb0>
fuck xilinx, seriously
<sb0>
whitequark, and do you want to present? :)
<whitequark>
not sure. LCA is pretty large and i never presented in english before
<GitHub29>
[artiq] sbourdeauducq pushed 8 new commits to master: http://git.io/vYVNj
<sb0>
I could handle that, but sitting in the flying sardine can for 19 hours sounds painful ...
<cr1901_modern>
whitequark: Do you still need to install llvm on 12.04? I have a shell script which automates the process- it's kinda involved (and/or irritating).
<whitequark>
already done
<cr1901_modern>
You had to install GCC 4.7+, then cmake (version on 12.04 is too old), then llvm, right?
<whitequark>
yes
<cr1901_modern>
I gotta ask myself why I thought it was a good idea to write a shell script for something I only had to do once...
fengling has joined #m-labs
cr1901_modern has quit [Read error: No route to host]
cr1901_modern has joined #m-labs
<GitHub131>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYw3W
<whitequark>
lol what the fuck. what were GCC people smoking when they wrote the exception table format
<whitequark>
the list of exceptions a catch clause can catch is encoded using a finite state machine with a variable instruction length
<whitequark>
instead of, you know, a fucking array. i am guessing that would be too straightforward.
<sb0>
received my chinese oscilloscope. in a "fine toiletry" box, of course :)
<whitequark>
ha
<whitequark>
ok, so the allocas and stack pointer are where they are supposed to be at entry to the handler
<whitequark>
=> the whole affair was a success
<sb0>
shipping cost 7€ by air, took 2 days, and collecting packages takes only a few minutes
<sb0>
I wish sf-express would expand to more countries and give UPS and fedex the bankruptcy they deserve
FabM has joined #m-labs
<cr1901_modern>
2-3 business days to the US, according to their website o.0;
<whitequark>
that's not hard
<cr1901_modern>
Then what causes the delay of 2-3 weeks for my packages from China (Ebay, which is prob my first mistake)?
<whitequark>
"free ePacket shipping"
<cr1901_modern>
Yep, that would explain it. I get what I pay for in this case.
<GitHub61>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYwRV
<GitHub61>
artiq/new-py2llvm 90be44c whitequark: Add tests for non-exceptional control flow across finally.
<GitHub61>
artiq/new-py2llvm a83e7e2 whitequark: Add tests for exceptional control flow.
<whitequark>
sb0: ping
<whitequark>
a semantics question
<whitequark>
I can have the finally: clauses behave with regard to exceptions a little more like in Python (they're just catch-all clauses that implicitly re-raise), or a little more like in C++ (they are dedicated to cleanup code)
<whitequark>
the difference is
<whitequark>
in #1, if no except clause will catch the exception, you'll still get unwinding
<whitequark>
in #2, if no except clause will catch the exception, the runtime will immediately terminate
<whitequark>
since we have no heap on which to store the backtrace, in case #1 the backtrace will get fucked
<whitequark>
but in case #2 the backtrace will accurately resemble the callstack
<whitequark>
of course, in case #1 you have a chance to do something funky like returning out of finally clause, or raising another exception there
<sb0>
well, unwinding is only useful when the exception is not caught, isn't it?
<whitequark>
huh?
<whitequark>
no, unwinding always happens. in fact, twice. the first time, the unwinder asks every stack frame whether it can handle the exception in-flight
<sb0>
maybe not with DWARF and other fancy mechanisms :) but at compared to the current sjlj system, the point of adding unwinding was to get debug info on uncaught exceptions
<whitequark>
and the second time it peels off stack frames one-by-one (well, several if they don't have any try statements) and tells them to clean after themselves or handle
<whitequark>
ok, so do I understand you prefer #2?
<whitequark>
immediate termination / no finally clause execution / accurate traces?
<sb0>
no, the finally clauses should get executed like Python does
<sb0>
what about sending the elements of the backtrace over the network one by one? we don't care about speed
<whitequark>
hrm
<whitequark>
so what happens if a second exception is thrown while unwinding?
sb0 has left #m-labs ["Leaving"]
sb0 has joined #m-labs
<sb0>
what would throw such an exception?
<sb0>
oh, I see, since you are not using sjlj you need to unwind every time an exception is thrown
<sb0>
and you need to keep info on the previous frames in case nothing ends up catching the exception, and you need to send that info to the comms CPU/PC?
<whitequark>
yeah
<whitequark>
well, not quite.
<whitequark>
I can say whether something will *catch* the exception right when it is raised (phase 1)
<whitequark>
but I cannot say whether the finally clauses, which execute /as a part of unwinding/, will raise another exception or just return
<whitequark>
they execute as a part of unwinding, during phase 2, because they need access to local variables and such
<whitequark>
there is a different but related issue with rethrowing exceptions
<sb0>
what about rescanning the stack frames when you need to send the trace to the host?
<whitequark>
since "except x: ... raise" is equivalent to a finally clause that's selective and gives access to the exception
<whitequark>
ha.
<sb0>
you'd only get the last exception thrown, but that should be OK
<whitequark>
that was my original plan.
<sb0>
and what is wrong with it?
<whitequark>
if I execute finally clauses even when the exception will not be caught, by the time I need to send the backtrace to host, I don't *have* the stack frames
<whitequark>
since they've been popped off
<sb0>
ah, I see.
<sb0>
what about a static backtrace buffer of a few kilobytes?
<whitequark>
so it is either 1) not executing finally clauses for uncaught exceptions or 2) storing them somewhere
<sb0>
or dozen kilobytes
<whitequark>
that can be done.
<whitequark>
well, you don't need kilobytes, really, it's 4 bytes per entry
<sb0>
there's 1GB RAM on those boards, so it should not be an issue at all.
<whitequark>
ok. so if it's uncaught, I will force unwinding while collecting the PCs
<whitequark>
and if a finally clause bails, I'll just never get control from the unwinder back
tija has joined #m-labs
<sb0>
"The MMCM outputs are programmed to provide (for example) a 528 MHz processor clock"
<sb0>
xilinx datasheet are always so optimistic.
<whitequark>
ha
<sb0>
right now, if the design worked at all at 125MHz when using more than one of those MMCMs, that would be nice
<GitHub72>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYr3V
<GitHub72>
artiq/new-py2llvm 2939d4f whitequark: Add tests for finally clause and reraising.
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 272 seconds]
_whitelogger___ has joined #m-labs
fengling_ has joined #m-labs
_whitelogger__ has quit [Ping timeout: 240 seconds]
fengling has quit [Read error: Connection reset by peer]
<sb0>
"Signal controls the state of the input MUX, High = CLKIN1, Low = CLKIN2"
<sb0>
default 0, e.g. CLKIN2, whereas the base PLL defaults to CLKIN1
<sb0>
grrrr
<sb0>
FINALLY got that damn think to lock and produce a valid clock without screwing other parts of the design
<sb0>
*thing
<sb0>
now, locking the output phase to the input. surely, that will fail again.
<sb0>
rjo, do you know what the synthnv baud rate is? and can I connect its input to a LVCMOS 25 FPGA pin (according to Joe yes, but I have learned to double-check this sort of thing...)
<whitequark>
ok, let's write the dynamic linker
<whitequark>
hm
<whitequark>
ha, ksupport doesn't fit into 4K anymore
<whitequark>
hm, how do I flash runtime without xc3sprog?
<whitequark>
haha, I can't even get xc3sprog. sourceforge is dead
<whitequark>
got it. sure enough, it doesn't work
_whitelogger___ has joined #m-labs
<sb0>
ok, I can talk to the synthnv and get the right signal on the scope. now, the ref input...
<sb0>
whitequark, yes, flashing the runtime with xc3sprog will fail
<sb0>
whitequark, load from serial. flterm --port /dev/ttyUSBx --kernel runtime.bin
<sb0>
or figure out openocd :)
nicksydney has joined #m-labs
nicksydney_ has quit [Ping timeout: 244 seconds]
<whitequark>
hrm
<whitequark>
hrm, runtime miscompiles. I wonder why
<whitequark>
ohhh, this is a different miscompilation than before. exciting
antgreen has quit [Remote host closed the connection]
attie has quit [Remote host closed the connection]
<whitequark>
ha, neat. what makes the bug manifest is uncommenting a 4th strcmp in do_command in test_main.c
<sb0>
this is why I waited before pulling your misoc commit :-)
<whitequark>
my guess would be an extremely poor choice by the register allocator coupled with the spiller doing something it shouldn't
<whitequark>
the assembly shows that do_command got inlined into test_main and test_main spends several screens stashing... something... into stack slots
nengel has joined #m-labs
<sb0>
yay, phase locking
<GitHub146>
[artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vYo8z