| kristianpaul | viric: ah xterm beuty are colours ;-) | 00:47 |
|---|---|---|
| kristianpaul | may be thats why i never got used to it | 00:47 |
| wpwrak | viric: (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 invisible | 01:39 |
| wolfspraul | I finished work on the blinking_led (in fpgatools), awaiting confirmation from xiangfu... | 07:02 |
| wolfspraul | next step is a counter which can be programmed over jtag | 07:02 |
| wolfspraul | goal: 2 weeks :-) | 07:03 |
| wolfspraul | also I need to work on support for the ftg256 package (as opposed to the only supported tqg144 right now) | 07:03 |
| wolfspraul | after the counter: j1 soc to blink led... | 07:03 |
| wpwrak | so currently have a blinking led, but no counter ? | 07:15 |
| wolfspraul | awaiting confirmation, but yes, it's a blinking led driven from a static counter | 07:24 |
| wolfspraul | counts up, clocked from an external clock, and the highest bit of the counter is the on/off wire | 07:24 |
| wolfspraul | whereas the next counter will have start/stop/frequency registers that can be programmed over jtag | 07:25 |
| wolfspraul | in lines of verilog, the and gate was 1 line, the static counter 3 or 4, and the new one now maybe 100 | 07:25 |
| wolfspraul | with jtag and registers etc. | 07:25 |
| wolfspraul | will be interesting to see how fpgatools holds up | 07:26 |
| wolfspraul | this is the final blinking_led.c btw https://github.com/Wolfgang-Spraul/fpgatools/blob/master/blinking_led.c | 07:26 |
| wolfspraul | maybe 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 |
| wpwrak | the next counter sounds pretty fancy :) | 07:31 |
| Fallenou | wow indeed the c file seems pretty big for what it actually does, the entire M1 soc would take a lot of lines :p | 07:34 |
| Fallenou | congratz anyway !! | 07:34 |
| wpwrak | does "(A6+~A6)*(A5)" mean, in C parlance, "(A6 | ~A6) & A5" ? i.e., just A5 ? | 07:34 |
| wpwrak | Fallenou: i think with a little preprocessor, you could condense this a lot. there's plenty of redundancy in there | 07:36 |
| Fallenou | looks cool anyway to be able to tweak fpa bitstream with so low level | 07:36 |
| wpwrak | also, 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 operate | 07:37 |
| wpwrak | for 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 |
| wpwrak | the 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 used | 07:41 |
| wpwrak | of 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 users | 07:42 |
| wpwrak | a 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 symbols | 07:44 |
| wpwrak | the 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 metal | 07:45 |
| wpwrak | hmm, i see logic_cfg.a2d[LUT_A].lut5 = "0"; | 07:50 |
| wpwrak | and then logic_cfg.a2d[LUT_C].lut5 = 0; | 07:51 |
| wpwrak | typo or just confusing non-use of NULL ? | 07:51 |
| xiangfu | wolfspraul: 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 |
| wpwrak | actually, i just realize that the mayans were right after all. wolfgang just started the apocalypse for closed fpga synthesis :-) | 07:56 |
| wpwrak | whee, time for the champagne !! | 07:57 |
| wpwrak | wolfspraul: congratulations ! | 07:57 |
| wpwrak | xiangfu: (qfp) so no nasty BGAs anymore ? that should help to make that board more accessible | 07:59 |
| xiangfu | since the fpgatools only support qfp144. | 08:02 |
| xiangfu | wpwrak: I am still working on ftg256. add spi flash and a bluetooth-serial modular. | 08:02 |
| wpwrak | xiangfu: did you find a BT module with sufficiently open documentation ? | 08:34 |
| xiangfu | wpwrak: no. | 08:43 |
| xiangfu | this one: http://www.wavesen.com/probig.asp?id=17 | 08:43 |
| xiangfu | there are only 4 AT commands for this modular. (test, modify serial bandwidth, modify bluetooth name and password) | 08:44 |
| xiangfu | datasheet is here: (only chinese: http://www.wavesen.com/mysys/db_picture/news3/20121119115841101.pdf) | 08:46 |
| wpwrak | even the coin for the size comparison is chinese ;-) | 08:52 |
| xiangfu | I have tested with rfcomm command with my laptop. | 08:52 |
| xiangfu | it's like, laptop usb-serial <---> serial-bluetooth-modular <---> laptop rfcomm command through bluetooth. it's a circle | 08:53 |
| wpwrak | heh :) well, the serial interface seems to be sufficiently documented to tbe usable. | 08:54 |
| wpwrak | that's already something | 08:54 |
| wolfspraul | yes, all feedback is correct, all acknowledged :-) | 10:16 |
| wolfspraul | higher-level structs and functions | 10:17 |
| wolfspraul | qfp144 and ftg256 both have different pros and cons | 10:17 |
| wolfspraul | qfp144 has a 0.5mm pitch, that's actually quite tough for diy boards | 10:17 |
| roh | sure.. but at the prices fusionpcb from seed costs... who cares. | 10:18 |
| wolfspraul | yes lut5="0" and lut5=0 are two different things. ="0" means that the lut5 is in use, and pulled low (gnd) | 10:18 |
| roh | atleast one can 'easily' solder such stuff | 10:18 |
| wolfspraul | lut5=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 |
| wolfspraul | xiangfu: thanks for testing! | 10:19 |
| wolfspraul | I shall continue with the jtag counter then :-) | 10:19 |
| wolfspraul | it took me 3 months to go from the AND gate to a simple clocked led blinker, let's hope it gets faster now | 10:20 |
| wolfspraul | for the higher level stuff, I will take a look at llvm backends | 10:21 |
| wolfspraul | that will give me some guidance (hopefully) how to design the higher-level functions | 10:21 |
| wolfspraul | http://llvm.org/docs/WritingAnLLVMBackend.html | 10:22 |
| Fallenou | really good news, big congratulations wolfspraul :) | 10:23 |
| wolfspraul | thanks | 10:24 |
| wolfspraul | but it's still far from practically usable, I have to say | 10:25 |
| wolfspraul | we will see | 10:25 |
| wolfspraul | I start to realize how much work the synthesis is actually doing :-) | 10:25 |
| wolfspraul | with 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 questions | 14:40 |
| lindi- | wolfspraul: sorry, meant you | 14:40 |
| wolfspraul | thanks | 14:41 |
| wolfspraul | not sure I know the questions now | 14:41 |
| whitequark | wolfspraul: I also have some experience with LLVM and might be able to help | 16:29 |
| wpwrak | wolfspraul: (=0 vs. ="0") why not use NULL instead of =0 ? otherwise, it's extremely confusing and will mislead people | 18:04 |
| lekernel | iirc 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 |
| lekernel | and yes: http://c-faq.com/null/ptrtest.html | 18:08 |
| lekernel | some people have too much time on their hands | 18:08 |
| whitequark | that's why C++11 defines nullptr type | 18:09 |
| wpwrak | (too much time) why ? it's a legitimate concern | 18:24 |
| lekernel | why would a hardware or OS developer need a non-zero NULL pointer? | 18:47 |
| lekernel | I also have a feeling that a lot of software we use today would break if compiled for a platform where NULL != 0 :) | 18:49 |
| whitequark | lekernel: in fact llvm assumes it's 0, which basically means that all software, if compiled with clang | 18:52 |
| whitequark | not sure about gcc. | 18:52 |
| whitequark | afaik yes, optimizer likes this fact | 18:55 |
| wpwrak | lekernel: 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 |
| viric | lekernel: '0', evaluated as a pointer, may not have an integer representation of all bits zero | 19:17 |
| viric | so '(int) ((void *) 0)' may be different than '(int) 0'. :) | 19:17 |
| viric | NULL simply is translated as '((void *) 0)' | 19:18 |
| viric | A good compiler, where a null pointer is 0xffff, will not have "#define NULL 0xffff" | 19:18 |
| wpwrak | viric: are you sure about the cast ? for consistency, it may still yield 0. | 19:18 |
| viric | It 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 |
| viric | umh 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 |
| wpwrak | where you would notice are things like memset or unions used for type conversion | 19:19 |
| viric | but then, how to write the memory address zero? I don't know. :) | 19:20 |
| wpwrak | yes, (type *) 0 is always a "null pointer" | 19:20 |
| wpwrak | easy: C doesn't define hardware addresses :) | 19:21 |
| viric | yes, that sounds right. | 19:21 |
| wpwrak | so you'd use some architecture-specific hack | 19:21 |
| viric | yes | 19:21 |
| viric | http://c-faq.com/null/nullor0.html | 19:22 |
| wpwrak | #define NUL is asking for trouble ;-) | 19:23 |
| wpwrak | of course, so are people who speak of a "NULL (sic) character" | 19:24 |
| viric | yes | 19:24 |
| viric | You can define NIL too | 19:24 |
| viric | or NIHIL | 19:24 |
| viric | :) | 19:24 |
| viric | or all of them | 19:24 |
| viric | #define ZERO that also rocks | 19:25 |
| viric | if (NULL == ZERO) {... } | 19:25 |
| wpwrak | NIL may upset LISP programmers :) | 19:25 |
| wpwrak | argh ;-) | 19:25 |
| viric | so, who needs macros? noone | 19:26 |
| wpwrak | actually, wolfgang, a CLEAR(x) macro for memset(&(x), 0, sizeof(x)) may be handy in your fpgatools examples | 19:26 |
| wpwrak | naw, macros are cool | 19:26 |
| wolfspraul | nice idea - done | 19:32 |
| wolfspraul | thanks! | 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 | |
| wpwrak | hehe, 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/e10d1e9 | 21:31 |
| qi-bot | [commit] Werner Almesberger: components/lpc1100-qfn33.lib: NXP LPC11xx series in HVQFN33 package (master) http://qi-hw.com/p/kicad-libs/ecba9a3 | 21:31 |
| whitequark | wpwrak: to avoid collisions in global namespace? | 22:11 |
| wpwrak | whitequark: 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_MAT3 | 22:19 |
| wpwrak | what 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 |
| wpwrak | and 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 |
| whitequark | ugh. 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/1f0d15c | 22:52 |
| wpwrak | restored at least a bit of sanity :) | 22:52 |
| --- Fri Dec 21 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!