#qi-hardware IRC log for Thursday, 2012-12-20

kristianpaulviric: ah xterm beuty are colours ;-)00:47
kristianpaulmay be thats why i never got used to it 00:47
wpwrakviric: (color xterm) yeah, that's evil. particularly when someone uses yellow for problem reports. my xterms are black on beige ("moccasin") so anything yellow is almost invisible01:39
wolfspraulI finished work on the blinking_led (in fpgatools), awaiting confirmation from xiangfu...07:02
wolfspraulnext step is a counter which can be programmed over jtag07:02
wolfspraulgoal: 2 weeks :-)07:03
wolfspraulalso I need to work on support for the ftg256 package (as opposed to the only supported tqg144 right now)07:03
wolfspraulafter the counter: j1 soc to blink led...07:03
wpwrakso currently have a blinking led, but no counter ?07:15
wolfspraulawaiting confirmation, but yes, it's a blinking led driven from a static counter07:24
wolfspraulcounts up, clocked from an external clock, and the highest bit of the counter is the on/off wire07:24
wolfspraulwhereas the next counter will have start/stop/frequency registers that can be programmed over jtag07:25
wolfspraulin lines of verilog, the and gate was 1 line, the static counter 3 or 4, and the new one now maybe 10007:25
wolfspraulwith jtag and registers etc.07:25
wolfspraulwill be interesting to see how fpgatools holds up 07:26
wolfspraulthis is the final blinking_led.c btw https://github.com/Wolfgang-Spraul/fpgatools/blob/master/blinking_led.c07:26
wolfspraulmaybe I do need some smarter high-level functions for the new jtag counter, or else the .c would grow to thousands of lines dealing with each wire (bit) separately...07:27
wpwrak(awaiting confirmation) you mean you don't have a board but just test it on paper, knuth-style ? :-)07:30
wpwrakthe next counter sounds pretty fancy :)07:31
Fallenouwow indeed the c file seems pretty big for what it actually does, the entire M1 soc would take a lot of lines :p07:34
Fallenoucongratz anyway !!07:34
wpwrakdoes "(A6+~A6)*(A5)" mean, in C parlance, "(A6 | ~A6) & A5" ? i.e., just A5 ?07:34
wpwrakFallenou: i think with a little preprocessor, you could condense this a lot. there's plenty of redundancy in there07:36
Fallenoulooks cool anyway to be able to tweak fpa bitstream with so low level07:36
wpwrakalso, the way how things are references (by coordinates) is somewhat user-unfriendly. of course, it probably makes sense at the level at which the tools operate07:37
wpwrakfor an API meant for human users, you'd probably have an "object" for those things at (55, 13), etc., then operate on properties of that object.07:39
wpwrakthe object would be a pointer to a struct. since these objects correspond to physical circuits (i.e., LUTs and such; not abstract things like routes), they could be statically allocated, depending on the chip used07:41
wpwrakof course, there's the question whether creating such a "friendly" API would even make sense, considering that it would still be uncomfortably low for human users07:42
wpwraka bit like, in programming terms: the bitstream is machine language in hex codes, wolfgang's api is an assembler that translates mnemonics but doesn't have any symbols07:44
wpwrakthe hypothetical "nice" API would be a regular assembler. but then, most people what to program in C or something even more distant from the bare metal07:45
wpwrakhmm, i see  logic_cfg.a2d[LUT_A].lut5 = "0";07:50
wpwrakand then  logic_cfg.a2d[LUT_C].lut5 = 0;07:51
wpwraktypo or just confusing non-use of NULL ?07:51
xiangfuwolfspraul: wpwrak : I tested the blinking led config bits file (gernerate by fpgatools (../blinking_led | ../fp2bit - blinking.bit). it works just fine on my slx9-qfp144 board.07:56
wpwrakactually, i just realize that the mayans were right after all. wolfgang just started the apocalypse for closed fpga synthesis :-)07:56
wpwrakwhee, time for the champagne !!07:57
wpwrakwolfspraul: congratulations !07:57
wpwrakxiangfu: (qfp) so no nasty BGAs anymore ? that should help to make that board more accessible07:59
xiangfusince the fpgatools only support qfp144. 08:02
xiangfuwpwrak: I am still working on ftg256. add spi flash and a bluetooth-serial modular.08:02
wpwrakxiangfu: did you find a BT module with sufficiently open documentation ?08:34
xiangfuwpwrak: no. 08:43
xiangfuthis one: http://www.wavesen.com/probig.asp?id=1708:43
xiangfuthere are only 4 AT commands for this modular. (test, modify serial bandwidth, modify bluetooth name and password)08:44
xiangfudatasheet is here: (only chinese: http://www.wavesen.com/mysys/db_picture/news3/20121119115841101.pdf)08:46
wpwrakeven the coin for the size comparison is chinese ;-)08:52
xiangfuI have tested with rfcomm command with my laptop.08:52
xiangfuit's like, laptop usb-serial <---> serial-bluetooth-modular <---> laptop rfcomm command through bluetooth. it's a circle08:53
wpwrakheh :) well, the serial interface seems to be sufficiently documented to tbe usable.08:54
wpwrakthat's already something08:54
wolfspraulyes, all feedback is correct, all acknowledged :-)10:16
wolfspraulhigher-level structs and functions10:17
wolfspraulqfp144 and ftg256 both have different pros and cons10:17
wolfspraulqfp144 has a 0.5mm pitch, that's actually quite tough for diy boards10:17
rohsure.. but at the prices fusionpcb from seed costs... who cares.10:18
wolfspraulyes lut5="0" and lut5=0 are two different things. ="0" means that the lut5 is in use, and pulled low (gnd)10:18
rohatleast one can 'easily' solder such stuff10:18
wolfspraullut5=0 means the lut5 is not in use, at that point I am probably overwriting a structure from before and 'resetting' the lut5 to 'not in use'10:18
wolfspraul(A6+~A6) is just a convention to say that A6 is not in use - it is pulled high and the lut functions as a two-lut system (two times 5 instead of one-time 6)10:19
wolfspraulxiangfu: thanks for testing!10:19
wolfspraulI shall continue with the jtag counter then :-)10:19
wolfspraulit took me 3 months to go from the AND gate to a simple clocked led blinker, let's hope it gets faster now10:20
wolfspraulfor the higher level stuff, I will take a look at llvm backends10:21
wolfspraulthat will give me some guidance (hopefully) how to design the higher-level functions10:21
wolfspraulhttp://llvm.org/docs/WritingAnLLVMBackend.html10:22
Fallenoureally good news, big congratulations wolfspraul :)10:23
wolfspraulthanks10:24
wolfspraulbut it's still far from practically usable, I have to say10:25
wolfspraulwe will see10:25
wolfspraulI start to realize how much work the synthesis is actually doing :-)10:25
wolfspraulwith the AND gate, that wasn't so obvious yet, but for sure by the time I play with the J1 soc, it will be pretty obvious...10:26
lindi-wpwrak: I have worked with llvm stuff for the last two years, I might be able to help you in some questions14:40
lindi-wolfspraul: sorry, meant you14:40
wolfspraulthanks14:41
wolfspraulnot sure I know the questions now14:41
whitequarkwolfspraul: I also have some experience with LLVM and might be able to help16:29
wpwrakwolfspraul: (=0 vs. ="0") why not use NULL instead of =0 ? otherwise, it's extremely confusing and will mislead people18:04
lekerneliirc the C standard also allows NULL to be non-zero. haven't heard of an actual platform twisted enough to do that, though.18:06
lekerneland yes: http://c-faq.com/null/ptrtest.html18:08
lekernelsome people have too much time on their hands18:08
whitequarkthat's why C++11 defines nullptr type18:09
wpwrak(too much time) why ? it's a legitimate concern18:24
lekernelwhy would a hardware or OS developer need a non-zero NULL pointer?18:47
lekernelI also have a feeling that a lot of software we use today would break if compiled for a platform where NULL != 0 :)18:49
whitequarklekernel: in fact llvm assumes it's 0, which basically means that all software, if compiled with clang18:52
whitequarknot sure about gcc.18:52
whitequarkafaik yes, optimizer likes this fact18:55
wpwraklekernel: your application wouldn't normally see that NULL is internally not all zero bits. similar to 0.0 not necessarily being all zero.19:09
viriclekernel: '0', evaluated as a pointer, may not have an integer representation of all bits zero19:17
viricso '(int) ((void *) 0)' may be different than '(int) 0'. :)19:17
viricNULL simply is translated as '((void *) 0)'19:18
viricA good compiler, where a null pointer is 0xffff, will not have "#define NULL 0xffff"19:18
wpwrakviric: are you sure about the cast ? for consistency, it may still yield 0.19:18
viricIt will have "#define NULL ((void *) 0)"19:19
wpwrak(i'm too lazy to look up what the standard has to say about it, though :)19:19
viricumh I also can't cite much. But if '0' is evaluated as a pointer, it evaluates as the *null pointer*, regardless of it being zero or not.19:19
wpwrakwhere you would notice are things like memset or unions used for type conversion19:19
viricbut then, how to write the memory address zero? I don't know. :)19:20
wpwrakyes, (type *) 0 is always a "null pointer"19:20
wpwrakeasy: C doesn't define hardware addresses :)19:21
viricyes, that sounds right.19:21
wpwrakso you'd use some architecture-specific hack19:21
viricyes19:21
virichttp://c-faq.com/null/nullor0.html19:22
wpwrak#define NUL is asking for trouble ;-)19:23
wpwrakof course, so are people who speak of a "NULL (sic) character"19:24
viricyes19:24
viricYou can define NIL too19:24
viricor NIHIL19:24
viric:)19:24
viricor all of them19:24
viric#define ZERO     that also rocks19:25
viricif (NULL == ZERO) {... }19:25
wpwrakNIL may upset LISP programmers :)19:25
wpwrakargh ;-)19:25
viricso, who needs macros? noone19:26
wpwrakactually, wolfgang, a CLEAR(x) macro for  memset(&(x), 0, sizeof(x))  may be handy in your fpgatools examples19:26
wpwraknaw, macros are cool19:26
wolfspraulnice idea - done19:32
wolfspraulthanks!19:32
Action: wpwrak wonder why NXP always have to use such anal pin names. PIO0_1 instead of P0_1 for pin 1 on port 0, CT32B0_MAT2 instead of something like T0M2 for the 2nd match output of timer 0, ...19:44
wpwrakhehe, XC6SLX9-CSG324 (in kicad-libs/components/xc6slx9-csg324.lib) ... how that's a HUGE beast ;-)21:01
qi-bot[commit] Werner Almesberger: components/HIERARCHY: add XC6SLX9-CSG324 (master) http://qi-hw.com/p/kicad-libs/e10d1e921:31
qi-bot[commit] Werner Almesberger: components/lpc1100-qfn33.lib: NXP LPC11xx series in HVQFN33 package (master) http://qi-hw.com/p/kicad-libs/ecba9a321:31
whitequarkwpwrak: to avoid collisions in global namespace?22:11
wpwrakwhitequark: hmm, with names like "R" or "AD1". the "R" even collides internally.22:17
wpwrak(i.e., there are several non-equivalent pins where one of the names is "R")22:17
wpwrak(one of the names) as in R/PIO1_2/AD3/CT32B1_MAT1 or R/PIO0_11/AD0/CT32B0_MAT322:19
wpwrakwhat the "R" means is that this pin could have an additional function that is "reserved". the concept of indicating this in the pin names alone is somewhat mind-boggling.22:27
wpwrakand of course, the immediately visible problem with things like PIO0_1 is that you have two visually very similar characters (O and 0) right next to each other.22:29
whitequarkugh. yes.22:51
qi-bot[commit] Werner Almesberger: components/lpc1100-qfn33.lib: remove dubious "R" (reserved) pin function (master) http://qi-hw.com/p/kicad-libs/1f0d15c22:52
wpwrakrestored at least a bit of sanity :)22:52
--- Fri Dec 21 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!