IRC logs for #openrisc Saturday, 2014-04-19

--- Log opened Sat Apr 19 00:00:11 2014
stekernLimb: so are all the clocks correctly discoverd now? does it do any constrains on the jtag clock?04:48
stekern...and welcome to the world of FPGA development, if you have timing critical paths somewhere, it will work sometimes and completely unrelated changes might throw it off04:50
blueCmdstekern: do you know what's the difference between (mpfr_const_catalan) (x, MPFR_RNDN); and mpfr_const_catalan (x, MPFR_RNDN); ?10:51
blueCmdI'm wondering if there is any difference in macro expansion10:54
blueCmdyes, seems to be to not match #define mpfr_const_catalan(a,b)10:58
stekernah, yes, now I understand what you asked, about the paranthesis10:58
stekernI thought you expected me to have some knowledge about mpfr_const_catalan =)10:59
blueCmdhah, nah11:00
blueCmdI have this:11:01
blueCmdint main () calls a function in named mpfr_const_catalan with a pointer to a destination var11:01
blueCmdmpfr_const_catalan calls mpfr_cache with the same pointer11:02
blueCmdor rather
blueCmdmain -> mpfr_const_catalan -> mpfr_cache11:04
stekernok, and where/what fails in that chain?11:04
blueCmdbetween mpfr_const_catalan and mpfr_cache the pointer gets mushed11:04
* blueCmd ison a train, high latency11:05
blueCmdalso, low battery so I'm dumping state and out-sourcing some thinking to the channel11:05
* stekern is in a summerhouse in the stockholm archipelago11:06
blueCmdanyway, mpfr_ functions are in a shared library - this does seem to work if I turn of TLS for the library11:06
blueCmdI'm going to dump the assembly for the functions and look what it is doing11:07
blueCmdit _does_ work if I call mpfr_cache directly from main11:07
blueCmd__gmpfr_cache_const_catalan is a TLS variable11:07
stekernhmm, could it be some plt calling that screws it up then?11:08
stekernagain, the or1ksim traces really helps in those kind of cases ;)11:10
blueCmdyep. I'm not running it in or1ksim though11:10
stekerncould you?11:11
stekernI mean, is it reproducable there?11:11
blueCmdI haven't tried11:12
stekernit seems like you've got it pretty well narrowed down though, just excamining the asm dumps of the functions might be enough11:12
blueCmdstekern: remind me, where is the first argument stored for the function in the standard calling convention?11:17
blueCmdr4? r5?11:17
-!- Netsplit *.net <-> *.split quits: _franck_, sfa12:14
stekernblueCmd: r315:49
Limbstekern: it doesn't have any constraints on the jtag clock.. but then again the jtag clock isn't even a real 'pin' per say since its a tap to the internal jtag interface16:07
stekernLimb: no, but it's still a clock net, and you are hooking up custom logic that is clocked with that clock16:24
stekernconstraints aren't just about external pins16:26
Limbstekern: OK. So if openOCD is driving it at 100 KHz, should i set a constraint for that wire to be 100 MHz?16:27
Limb100Mhz/100 Khz16:27
stekernyou might need to explicitly tell ISE that the CDC between the jtag clock and the wb clock is properly handled and so forth too16:28
Limbstekern: CDC?19:50
olofkLimb: Clock Domain Crossing20:39
olofkIf you have multiple clocks in a design you must be very careful with data that is crossing between those domains20:39
olofkI can't understand what the hell is the problem with my wb_ram component20:42
blueCmdstekern: the functions assembly (my laptop died 2 seconds before I could paste it to you earlier today)20:52
blueCmdsurely it looks like the __tls_get_addr (GD resolve) call messes up r3 (which is the dest pointer)20:53
* blueCmd playes with emit_clobber22:05
Limbstekern, olofk: getting this error trying to add that timing constraint:
--- Log closed Sun Apr 20 00:00:13 2014

Generated by 2.15.2 by Marius Gedminas - find it at!