#milkymist IRC log for Monday, 2013-12-02

rjolekernel: hey.17:56
rjolekernel: why was the __len__ overload for Signal removed?17:57
rjolekernel: ah. and that cordic_impl was no existing platform, just a hypothetical one to have ise compile the thing and see the size/speed scaling.17:58
lekernelrjo, because len() won't work on integers, and integers are valid elements of the AST. thus the flen() function.18:04
lekernelit's a lesser evil than making sure that all integers are encapsulated in a special class18:06
larschm, fifos have an awful output delay18:41
davidc___larsc: SyncFifos?18:44
lekernellatency? or clock-to-out for timing?18:44
larscI already have a FF right behind the output and still can't meet the timing :/18:47
davidc___larsc: Sync or Async?18:48
davidc___larsc: hrm; that one should be fine, its just the BRAM output18:50
davidc___larsc: IE, the fifo output is literally the BRAM dout bits18:50
larsc'RAMB36_X2Y20.DOBDO5  Trcko_DOB             2.454'18:51
larscthis is what it tells me18:51
davidc___can you pastebin the whole timing output of the failing path?18:51
larscneed to rebuild the bitstream first, give me a few minutes18:52
rjolekernel: ic. that's the usage side of things. but what about offering it anyway on Signal? for the cases where one is certain from the context that one is dealing with a Signal.18:53
lekerneluse flen() then :) it's just one extra character. and it makes it clear that len() cannot generally be used on expressions.18:55
rjolekernel: but there are many things that can not be used on expressions. like .eq() and .reset.18:57
lekernelyes, but those are clearly Signal-specific. length is not.18:57
rjolekernel: hmm. then lets make len() Signal-specific ;P19:01
larscdavidc___: http://pastebin.com/7gHseVhN19:01
larscI guess the mux is killing me19:02
lekernelwhy? it's confusing. then there will be bugs due to code using len() generally on expressions. better add one character to your code :)19:02
rjolekernel: ok. i give up ;)19:06
rjolekernel: next topic: how are the chances of getting migen/misoc pep8'ed? i hate having to switch my editor between "usual python" and "m-labs python" ;)19:07
lekernelanything besides tabs vs. spaces?19:09
larscdavidc___: I guess adding a third FF after the fifo will probably fix it19:10
rjolekernel: and tabstop=4, and long lines, and blank lines19:11
Action: rjo knows that every serious editor can autodetect indentation style and behave accordingly ;)19:11
davidc___larsc: yeah; just stick an FF right after the BRAM, or use a multiphase clock and push the FIFO output back 1/4 cycle (if you have the slack on the control signal inputs)19:23
larscyeay "Bitstream generation is complete."19:30
rjoanybody know of hand what the typical temperature and power supply voltage coefficient of these timings are?19:30
larscprobably the rated worst case19:39
davidc___rjo: at least for the S6, the timingan doesn't let you use anything except worst case19:43
lekernelpar says:19:46
lekernelInitializing temperature to 85.000 Celsius. (default - Range: 0.000 to 85.000 Celsius)19:46
lekernelInitializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260 Volts)19:46
davidc___though, could just be I need to give the params to par :) (I didn't really spend more than 30sec on it)19:47
lekernelpartgen can also output you the raw timing values19:47
lekernelyou could try with different temperatures/voltages (if partgen has the options) and try to understand the model xilinx uses... it should be linear imo19:47
lekernelat least for the temperature - that's what I measured heating a spartan-6 with a ring oscillator in it :) didn't do voltage experiments19:48
ysionneaulekernel: why not using something like that: http://pastebin.com/sdHQhbTY20:28
ysionneauif you cannot add __len__ method to primitive types, maybe you can just redefine len()20:28
ysionneauseems to work20:28
larscdon't redefine standard methods20:28
larscthat will break all kind of stuff20:28
ysionneauah, ok20:29
ysionneaubad idea then :)20:29
larscI mean when you want to use other modules as well20:29
ysionneautoo bad you cannot do something like 6.__class__.__len__ = some function20:29
larscit's like c libraries that call exit()20:30
larscor use signals20:30
larscit will break as soon has you have two libraries in your project that both setup signal handlers20:30
lekernelruby folks do that a lot, no?20:30
ysionneauruby can change everything imo20:31
ysionneaularsc: ok got it :)20:31
rjoi see. the timing temperature coefficient is only about 1e-3 / °C according to your paper.21:12
rjothe trouble i have with flen vs len is that there are two different meanings: one is "the minimum width required to hold an expression" (which is what flen does) and the other is "the maximum width can be held" (which could be len and would only ever apply to a Signal)21:15
rjos/can be/that can be/21:18
barmstrongis migen going to stabilize at some point?21:26
barmstrongi started writing a little "write a cpu with migen" blog thing but i'm afraid my examples are going to break21:26
barmstrongmy biggest concern is that it's so, um, unpythonic that it feels like a fork from regular python21:28
rjoalso, there is __getitem__, there could (and maybe should) be __iter__ and __reversed__, therefore there also should be __len__. does it make sense for an object that can __getitem__ to not be able to __len__?21:29
rjolekernel: sorry ;) i'm still getting ideas...21:29
rjobarmstrong: imho migen has been very stable. at least the stuff i wrote ~9 months ago still works without change.21:30
rjobarmstrong: but maybe its time to publicly show this stability by a release ;)21:31
barmstrongok, great21:31
rjobarmstrong: are you saying .eq() and If().Elif().Else() are un-pythonic?21:31
barmstrongrjo: I get why that stuff is necessary, but it is a little bit, yes21:32
rjobarmstrong: just suggesting. lekernel would be the one to ask.21:32
barmstronganother good example is __init__ for21:33
barmstrongthe argument order is very hard to guess and sort of haphazard21:33
barmstronga lot of those things should probably be indicated by subclasses of Signal rather than instantiation vars imo21:34
barmstrongbut i'm not the maintainer, so :)21:34
davidc___barmstrong: I think this is a patches-welcome situation :)21:34
rjobarmstrong: yeah. one would want to break that Signal.__init__() api sooner rather than later.21:35
rjolekernel: if you have time, could you explain what that variable attribute actually means or was/is used for conceptually?21:35
barmstrongi don't want to come in and just start changing stuff, especially if it breaks the api, but i do python for a day job so i'm rather opinionated about it21:35
barmstrongbut i would be happy to patch things21:36
barmstrongthe big thing that makes Python fun to use, imo, is that you don't really have to refer to comments/docs21:36
barmstrongi'll put together a patch for some of the biggest papercuts and we can hash it out :)21:37
barmstrongbtw, the blog is thisoldprocessor.tumblr.com21:37
larscsend patches, the worst thing that can happen is that they are rejected21:38
lekernelrjo, "variable" makes the signal behave like a VHDL variable, or a reg using blocking assignment in verilog21:39
lekernelI found out that it's not really useful when there's Python metaprogramming, and complicates things (especially because verilog blocking assignments are slightly broken)21:40
lekernelso I removed it from most places, the only remaining bit of code using it is the array lowering21:40
lekernelthat should be rewritten and the variable parameter removed21:40
lekernelbarmstrong, yes, send a patch21:41
lekernelor at least a clear proposal of what you would like the Signal.__init__ API to be21:41
barmstrongi think i can do a patch. i've tried once but i broke quite a lot of stuff21:42
barmstrongsorry if i came off as confrontational :)21:44
lekernelhe. go ahead and confront. that's how projects make progress :)21:44
rjoalso: maybe .eq() should be moved to Signal and Cat() etc should become subclasses of Signal.... but that would need to be discussed21:45
lekernelone can also use multiple inheritance21:46
lekerneland have Signal, Cat and _Slice derive from that class that implements eq()21:46
davidc___btw lekernel - FWIW, I've been using that ugly verilog generation hack for a few days now with no breakage/sim problems/synthesys impact21:47
rjolekernel: since i learned migen before really understanding verilog/vhdl i don't know what "variable" is ;) but your explanation makes me want to not want to know.21:47
davidc___lekernel: (other than ugly verilog :))21:47
rjolekernel: re inheritance: yes21:48
rjobarmstrong: nice page. i think putting your stuff into examples/ and migen/test might be higly appreciated.21:49
barmstrongthanks! i'm really excited about doing 10 or so examples21:49
barmstrongi have a mostly working brainfuck cpu for an issue or two from now :)21:49
lekerneldavidc__, unreadable verilog output is a serious problem: there are plenty of cases when you want to look at it during debugging. and I'm not sure that duplicating lots of if/case like that won't break some synthesizer optimizations.21:50
rjobarmstrong: ha! you had written that Simulator contextmanager patch months ago!21:51
davidc__lekernel: yeah; I know its suboptimal. In my case; I need the hack because I can't run my testsuite without it (pretty much every integration testcase hangs iverilog)21:51
rjobarmstrong: and also your unittests look good. i am not perfectly happy with what i wrote in migen/test/support.py. feel free to improve upon it!21:53
lekernelrjo, http://www.sigasi.com/content/vhdls-crown-jewel but you can do the exact same thing in Verilog as you do in VHDL by terminating your always blocks with a non-blocking assignment carrying the "variable" value21:54
lekernelcontrary to a popular myth you can mix blocking and non-blocking assignments in the same always block21:54
lekerneljust in case you want to rewrite the array lowering and get rid of the variable parameter ;)21:55
rjobarmstrong: and by merging your unittests and examples you can easily ensure that they will mature with the migen api ;) those who break the api will have to fix your unittests and examples.21:55
barmstrongrjo: i hadn't even thought of that. good point :)22:02
lekernelbarmstrong, interesting tutorial. you should post a link to it on the ML.22:02
barmstrongwill do, thanks22:02
barmstrongi might try to put out one more issue first22:03
barmstrongeach issue takes me like several hours to put together though, haha22:03
rjolekernel: thx for the pointer. is the verilog emitted by migen in "this special case" where the reult is deterministic?22:05
lekernelno, the user had to do it manually - I thought about having constructs that would enforce that special case, but decided that removing variable altogether was eventually simpler22:06
rjolekernel: but removing variable does not make it deterministic, does it?22:08
lekernel<lekernel> no, the user had to do it manually - I thought about having constructs that would enforce that special case, but decided that removing variable altogether was eventually simpler22:12
lekernel<lekernel> one case where "variable" is handy is for a LFSR that generates several bits of output per cycle22:12
lekernel<lekernel> but you can just do the same with metaprogramming: https://github.com/m-labs/misoc/blob/master/misoclib/memtest/__init__.py#L922:12
lekernel<lekernel> I didn't find a significant difference in the synthesized output22:12
lekernel<lekernel> verilog variable equivalent: https://github.com/m-labs/milkymist/blob/master/cores/memtest/rtl/memtest_prng64.v22:12
lekernel<lekernel> and yes, not an example of the "special case". I wrote that code before I figured it out. Verilog has lots of tricks.22:12
lekernelremoving variable makes it deterministic22:12
lekernelthe order of execution of the always blocks within the same delta cycle is still not deterministic22:13
lekernelbut it does not matter, as the non-blocking assignments always write values into the next delta cycle22:13
rjolekernel: ack. that migen style solution looks like you are "unrolling" the implicit delta cycle that the blocking verilog code has.22:30
Action: rjo thinks it's hard to understand why verilog and vhdl did not rid themselves of their dangerous, unwanted and buggy features decades ago by reducing the valid constructs...22:33
barmstrongbackwards compat is nasty :)22:35
barmstrongalthough i'd be curious to see who in the industry uses vanilla verilog22:35
lekerneland some people are happy to sell $5k verilog linter licenses, I guess22:36
rjobut haven't the non-HDL languages all pretty done that?22:36
barmstrongc++ still has a lot of terrible warts, i think22:36
rjobarmstrong: but its not like verilog and vhdl where afaict literally everyone trips over these "features" on a regular basis...22:37
barmstrongah, good point22:38
rjofrom what i have seen writing verilog/vhdl is like herding cats. you constantly have to keep track of the pitfalls and you never get used to them...22:39
barmstrongi remember the first semester in school where we had to learn vhdl. there are so many times that the TA will just tell "because that's how it is"22:40
Action: rjo is very happy that he refused to learn verilog/vhdl until migen became the obvious alternative.22:40
larsclekernel: what's with that 5k$ linter?22:43
lekernelhttp://www.eetimes.com/document.asp?doc_id=1150960 "The nLint product is priced at $5,000 for a year's subscription."22:45
lekernelthat was 2004, but it doesn't seem the situation has changed much since then22:46
larscwoha "Instead of saying I don't understand this code, the tool will point out that a comment or bracket is likely missing," rocket science!!22:48
barmstrongtoo bad there's nothing like pylint22:48
lekernellarsc, yes, and the synopsys error reports can be even worse than xst's22:49
lekernel(synopsys for asic. synplicity is ok.)22:50
rjolekernel: lemme float a few ideas: what about flattening iterables passed to Cat()? that would get rid of ugly Cat(*(stuff)).22:50
rjolekernel: also Signal().__iter__ would make https://github.com/m-labs/misoc/blob/master/misoclib/memtest/__init__.py#L16 a bit more compact.22:51
lekernelthat's ok; there's already a flat_iteration function in tools you can use22:51
rjolekernel: yep.22:51
rjoha. and then i can finally do len(list(Signal())) ;)22:52
lekernelwhy not Value.__iter__? and then it would not work for ints22:53
lekernel...so you'd need a iter_bits() generator instead :-)22:54
rjolekernel: ack.22:54
rjolekernel: serious?22:55
rjolekernel: ah. you mean an iter_bits() for ints?22:55
lekernelan iter_bits() for any expression, and a fortiori ints22:56
lekernelfor i in range(flen(expr)): yield expr[i]22:56
lekernelthough the slice would break again for ints. meh.22:57
rjolekernel: so you would be ok with iter_bits() + Value.__iter__? or only iter_bits()?22:57
rjolekernel: i would like the former.22:57
rjoand actually having Signal.__len__ would remove a lot of the special casing in flen() and nicely separate the logic for Signal and int.22:59
lekernelwhy do you want to separate the logic for Signal and int?23:00
lekernelthey are both valid AST nodes23:00
lekernelso you want the same API for both23:00
rjoi do want flen() to provide the same for both but move the Signal logic in flen (actually value_bits_sign()) to Signal where it imho belongs.23:02
rjobut in general one would want fiter() and flen() to behave analogously.23:02
rjolekernel: what does the f in flen stand for?23:03
lekernelif hasattr(obj, "get_value_bits_sign"): return obj.get_value_bits_sign() else: if isinstance(obj, int) ... else: raise TypeError23:03
lekernelyes, fhdl23:03
rjolekernel: yes. or "try: return len(obj); except Stuff: if isinstance(obj, int) ...."23:04
rjolekernel: i see. next problem.23:04
lekernelno, I really don't want len()23:05
rjolekernel: len([Signal(), Signal(a)]) != flen([Signal...])23:05
rjolekernel: ack. i stop wanting it now because of this.23:05
lekernelotherwise it'll get called on generic expressions23:05
rjolekernel: so back to iter. there, we would also have -- lets say -- fiter() which returns the flattened bit iterator of a Value or int. right?23:07
rjolekernel: and no __iter__.23:07
lekernelexact same situation as flen23:07
rjolekernel: ack.23:08
lekernelthat slice problem is more annoying23:08
rjolekernel: which?23:08
lekernelbecause there's really a big syntax difference between slice(obj, i) and obj[i]23:08
lekerneland you really want the last one23:09
lekernelwhich fails if obj is int23:09
rjolekernel: the signature is slice(start, stop, step).23:09
lekernelwell, yeh23:09
lekernelI mean, fslice or something like that23:09
lekernelpoint is - using a separate function like flen/fiter messes up the syntax a lot23:10
rjolekernel: ic. also reversed()23:10
rjolekernel: well. you can decide whether ints and values should be as similar as possible (and have fiter, flen, flsice, freversed) or accept that they are different and offer the python notation for the cases where you absolutely know that you are dealing with a Value. ;)23:12
rjolekernel: or a mixture of the two approaches ;)23:13
lekernelright now Python forbits slicing ints. making slices return bits like HDLs do wouldn't break things I guess23:13
barmstrongout of curiosity, why not just have the .Cat etc detect if you have an int and then just immediately wrap it in something else?23:14
barmstrongi guess i should check more closely if they do that already23:14
rjobarmstrong: imagine you get an expression passed to you in a __init__. what do you do with it?23:14
barmstrongah, i see, so it's that the ast leaves can be ints23:15
rjobarmstrong: you would have to wrap it explicitly and then use python notation (ugly and verbose). or use flen/fiter...23:15
lekernelI wonder if we have any chance of getting a PEP approved for slicing ints23:16
lekernelthat and replacing dict with OrderedDict by default (and same with sets)23:16
rjolekernel: you can slice in different bases...23:16
rjolekernel: ints that is.23:16
lekernelthere are already the >> and << operators, which could also work in different bases, but they chose base 2 :)23:17
rjolekernel: agreed. but you could allow for rational shifts and slices which would nicely and intuitively refer to the correct base.23:18
barmstronghmm so what if you detected ints in all those __add__ etc methods and wrapped there. just trying to finish this line of thought23:19
lekernelbarmstrong, if your function tries to slice an expression it gets passed as parameter, and the user gives an int there - end of story23:19
barmstrongok, i see.23:20
rjobarmstrong: migen "stores" everything. and then on conversion figures it out.23:20
lekernelanyway, time for bed23:21
rjobarmstrong: but the metaprogramming levels need to know some things earlier (during construction).23:21
rjolekernel: cu.23:21
barmstrongthis is definitely a prickly issue for anything like a DSL23:21
rjobarmstrong: the metaprogramming is immensely useful.23:23
barmstrongyeah, absolutely23:23
barmstrongi should go back and re-read the migen source23:26
barmstrongi had a pretty good mental model of it at one point but obviously i got rusty23:26
--- Tue Dec 3 201300:00

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