lekernel changed the topic of #milkymist to: Mixxeo, Migen, MiSoC & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
Mistah_Darcy has joined #milkymist
Mistah_Darcy_ has quit [Ping timeout: 272 seconds]
xiangfu has joined #milkymist
antgreen has joined #milkymist
xiangfu has quit [Remote host closed the connection]
Alarm has joined #milkymist
Alarm has quit [Ping timeout: 252 seconds]
_florent_ has joined #milkymist
aeris has quit [Ping timeout: 252 seconds]
aeris has joined #milkymist
_florent_ has quit [Ping timeout: 250 seconds]
lekernel has joined #milkymist
playthatbeat has joined #milkymist
jaeckel has joined #milkymist
Mistah_Darcy_ has joined #milkymist
Mistah_Darcy has quit [Ping timeout: 260 seconds]
proppy_ has joined #milkymist
davidc___ has joined #milkymist
proppy has quit [Ping timeout: 240 seconds]
proppy_ is now known as proppy
davidc__ has quit [Ping timeout: 240 seconds]
xiangfu has joined #milkymist
Alarm has joined #milkymist
antgreen has quit [Ping timeout: 264 seconds]
kilae has joined #milkymist
<rjo>
lekernel: hey.
<rjo>
lekernel: why was the __len__ overload for Signal removed?
<rjo>
lekernel: 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.
<lekernel>
rjo, because len() won't work on integers, and integers are valid elements of the AST. thus the flen() function.
<lekernel>
it's a lesser evil than making sure that all integers are encapsulated in a special class
xiangfu has quit [Remote host closed the connection]
<larsc>
hm, fifos have an awful output delay
<davidc___>
larsc: SyncFifos?
<lekernel>
latency? or clock-to-out for timing?
<larsc>
clock-to-out
<larsc>
I already have a FF right behind the output and still can't meet the timing :/
<davidc___>
larsc: Sync or Async?
<larsc>
async
<davidc___>
larsc: hrm; that one should be fine, its just the BRAM output
<davidc___>
larsc: IE, the fifo output is literally the BRAM dout bits
<larsc>
'RAMB36_X2Y20.DOBDO5 Trcko_DOB 2.454'
<larsc>
this is what it tells me
<davidc___>
can you pastebin the whole timing output of the failing path?
<larsc>
need to rebuild the bitstream first, give me a few minutes
<rjo>
lekernel: 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.
<lekernel>
use flen() then :) it's just one extra character. and it makes it clear that len() cannot generally be used on expressions.
<rjo>
lekernel: but there are many things that can not be used on expressions. like .eq() and .reset.
<lekernel>
yes, but those are clearly Signal-specific. length is not.
<rjo>
lekernel: hmm. then lets make len() Signal-specific ;P
<lekernel>
why? it's confusing. then there will be bugs due to code using len() generally on expressions. better add one character to your code :)
<rjo>
lekernel: ok. i give up ;)
<rjo>
lekernel: 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" ;)
<lekernel>
anything besides tabs vs. spaces?
<larsc>
davidc___: I guess adding a third FF after the fifo will probably fix it
<rjo>
lekernel: and tabstop=4, and long lines, and blank lines
* rjo
knows that every serious editor can autodetect indentation style and behave accordingly ;)
<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)
<larsc>
yeay "Bitstream generation is complete."
<rjo>
anybody know of hand what the typical temperature and power supply voltage coefficient of these timings are?
<larsc>
probably the rated worst case
<davidc___>
rjo: at least for the S6, the timingan doesn't let you use anything except worst case
<lekernel>
par says:
<lekernel>
Initializing temperature to 85.000 Celsius. (default - Range: 0.000 to 85.000 Celsius)
<lekernel>
Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260 Volts)
<davidc___>
though, could just be I need to give the params to par :) (I didn't really spend more than 30sec on it)
<lekernel>
partgen can also output you the raw timing values
<lekernel>
you could try with different temperatures/voltages (if partgen has the options) and try to understand the model xilinx uses... it should be linear imo
<lekernel>
at least for the temperature - that's what I measured heating a spartan-6 with a ring oscillator in it :) didn't do voltage experiments
<ysionneau>
if you cannot add __len__ method to primitive types, maybe you can just redefine len()
<ysionneau>
seems to work
<larsc>
don't redefine standard methods
<larsc>
that will break all kind of stuff
<ysionneau>
ah, ok
<ysionneau>
bad idea then :)
<larsc>
I mean when you want to use other modules as well
<ysionneau>
too bad you cannot do something like 6.__class__.__len__ = some function
<larsc>
it's like c libraries that call exit()
<larsc>
or use signals
<larsc>
it will break as soon has you have two libraries in your project that both setup signal handlers
<lekernel>
ruby folks do that a lot, no?
<ysionneau>
ruby can change everything imo
<ysionneau>
iirc*
<ysionneau>
larsc: ok got it :)
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]]
<rjo>
i see. the timing temperature coefficient is only about 1e-3 / °C according to your paper.
Alarm has quit [Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]]
<rjo>
the 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)
<rjo>
s/can be/that can be/
sh4rm4 has quit [*.net *.split]
antgreen has joined #milkymist
<barmstrong>
is migen going to stabilize at some point?
<barmstrong>
i started writing a little "write a cpu with migen" blog thing but i'm afraid my examples are going to break
<barmstrong>
my biggest concern is that it's so, um, unpythonic that it feels like a fork from regular python
<rjo>
also, 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__?
<rjo>
lekernel: sorry ;) i'm still getting ideas...
sh4rm4 has joined #milkymist
<rjo>
barmstrong: imho migen has been very stable. at least the stuff i wrote ~9 months ago still works without change.
<rjo>
barmstrong: but maybe its time to publicly show this stability by a release ;)
<barmstrong>
ok, great
<rjo>
barmstrong: are you saying .eq() and If().Elif().Else() are un-pythonic?
<barmstrong>
rjo: I get why that stuff is necessary, but it is a little bit, yes
<rjo>
barmstrong: just suggesting. lekernel would be the one to ask.
<barmstrong>
another good example is __init__ for
<barmstrong>
Signal
<barmstrong>
the argument order is very hard to guess and sort of haphazard
<barmstrong>
a lot of those things should probably be indicated by subclasses of Signal rather than instantiation vars imo
<barmstrong>
but i'm not the maintainer, so :)
<davidc___>
barmstrong: I think this is a patches-welcome situation :)
<rjo>
barmstrong: yeah. one would want to break that Signal.__init__() api sooner rather than later.
<rjo>
lekernel: if you have time, could you explain what that variable attribute actually means or was/is used for conceptually?
<barmstrong>
i 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 it
<barmstrong>
but i would be happy to patch things
<barmstrong>
the big thing that makes Python fun to use, imo, is that you don't really have to refer to comments/docs
wpwrak has quit [Read error: No route to host]
<barmstrong>
i'll put together a patch for some of the biggest papercuts and we can hash it out :)
<barmstrong>
btw, the blog is thisoldprocessor.tumblr.com
wpwrak has joined #milkymist
<larsc>
send patches, the worst thing that can happen is that they are rejected
<barmstrong>
sgtm
<lekernel>
rjo, "variable" makes the signal behave like a VHDL variable, or a reg using blocking assignment in verilog
<lekernel>
I found out that it's not really useful when there's Python metaprogramming, and complicates things (especially because verilog blocking assignments are slightly broken)
<lekernel>
so I removed it from most places, the only remaining bit of code using it is the array lowering
<lekernel>
that should be rewritten and the variable parameter removed
<lekernel>
barmstrong, yes, send a patch
<lekernel>
or at least a clear proposal of what you would like the Signal.__init__ API to be
<barmstrong>
i think i can do a patch. i've tried once but i broke quite a lot of stuff
<barmstrong>
sorry if i came off as confrontational :)
<lekernel>
he. go ahead and confront. that's how projects make progress :)
<rjo>
also: maybe .eq() should be moved to Signal and Cat() etc should become subclasses of Signal.... but that would need to be discussed
<lekernel>
one can also use multiple inheritance
<lekernel>
and have Signal, Cat and _Slice derive from that class that implements eq()
<davidc___>
btw lekernel - FWIW, I've been using that ugly verilog generation hack for a few days now with no breakage/sim problems/synthesys impact
<rjo>
lekernel: 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.
<davidc___>
lekernel: (other than ugly verilog :))
<rjo>
lekernel: re inheritance: yes
davidc___ is now known as davidc__
<rjo>
barmstrong: nice page. i think putting your stuff into examples/ and migen/test might be higly appreciated.
<barmstrong>
thanks! i'm really excited about doing 10 or so examples
<barmstrong>
i have a mostly working brainfuck cpu for an issue or two from now :)
<lekernel>
davidc__, 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.
<rjo>
barmstrong: ha! you had written that Simulator contextmanager patch months ago!
<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)
<rjo>
barmstrong: 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!
<lekernel>
rjo, 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" value
<lekernel>
contrary to a popular myth you can mix blocking and non-blocking assignments in the same always block
<lekernel>
just in case you want to rewrite the array lowering and get rid of the variable parameter ;)
<rjo>
barmstrong: 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.
<barmstrong>
rjo: i hadn't even thought of that. good point :)
<lekernel>
barmstrong, interesting tutorial. you should post a link to it on the ML.
<barmstrong>
will do, thanks
<barmstrong>
i might try to put out one more issue first
<barmstrong>
each issue takes me like several hours to put together though, haha
<rjo>
lekernel: thx for the pointer. is the verilog emitted by migen in "this special case" where the reult is deterministic?
<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 simpler
<rjo>
lekernel: but removing variable does not make it deterministic, does it?
lekernel has quit [Ping timeout: 246 seconds]
lekernel has joined #milkymist
<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 simpler
<lekernel>
<lekernel> one case where "variable" is handy is for a LFSR that generates several bits of output per cycle
<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.
<lekernel>
removing variable makes it deterministic
<lekernel>
the order of execution of the always blocks within the same delta cycle is still not deterministic
<lekernel>
but it does not matter, as the non-blocking assignments always write values into the next delta cycle
antgreen has quit [Read error: Operation timed out]
<rjo>
lekernel: ack. that migen style solution looks like you are "unrolling" the implicit delta cycle that the blocking verilog code has.
* 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...
<barmstrong>
backwards compat is nasty :)
<barmstrong>
although i'd be curious to see who in the industry uses vanilla verilog
<lekernel>
and some people are happy to sell $5k verilog linter licenses, I guess
<rjo>
but haven't the non-HDL languages all pretty done that?
<barmstrong>
c++ still has a lot of terrible warts, i think
<rjo>
barmstrong: but its not like verilog and vhdl where afaict literally everyone trips over these "features" on a regular basis...
<barmstrong>
ah, good point
<rjo>
from 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...
<barmstrong>
i 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"
* rjo
is very happy that he refused to learn verilog/vhdl until migen became the obvious alternative.
<rjo>
lekernel: ack. i stop wanting it now because of this.
<lekernel>
otherwise it'll get called on generic expressions
<rjo>
lekernel: so back to iter. there, we would also have -- lets say -- fiter() which returns the flattened bit iterator of a Value or int. right?
<lekernel>
yes
<rjo>
lekernel: and no __iter__.
<lekernel>
exact same situation as flen
<rjo>
lekernel: ack.
<lekernel>
that slice problem is more annoying
<rjo>
lekernel: which?
<lekernel>
because there's really a big syntax difference between slice(obj, i) and obj[i]
<lekernel>
and you really want the last one
<lekernel>
which fails if obj is int
<rjo>
lekernel: the signature is slice(start, stop, step).
<lekernel>
well, yeh
<lekernel>
I mean, fslice or something like that
<lekernel>
point is - using a separate function like flen/fiter messes up the syntax a lot
<rjo>
lekernel: ic. also reversed()
<rjo>
lekernel: 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. ;)
<rjo>
lekernel: or a mixture of the two approaches ;)
<lekernel>
right now Python forbits slicing ints. making slices return bits like HDLs do wouldn't break things I guess
<lekernel>
*forbids
<barmstrong>
out of curiosity, why not just have the .Cat etc detect if you have an int and then just immediately wrap it in something else?
<barmstrong>
i guess i should check more closely if they do that already
<rjo>
barmstrong: imagine you get an expression passed to you in a __init__. what do you do with it?
<barmstrong>
ah, i see, so it's that the ast leaves can be ints
<rjo>
barmstrong: you would have to wrap it explicitly and then use python notation (ugly and verbose). or use flen/fiter...
<lekernel>
I wonder if we have any chance of getting a PEP approved for slicing ints
<lekernel>
that and replacing dict with OrderedDict by default (and same with sets)
<rjo>
lekernel: you can slice in different bases...
<rjo>
lekernel: ints that is.
<lekernel>
there are already the >> and << operators, which could also work in different bases, but they chose base 2 :)
<rjo>
lekernel: agreed. but you could allow for rational shifts and slices which would nicely and intuitively refer to the correct base.
<barmstrong>
hmm so what if you detected ints in all those __add__ etc methods and wrapped there. just trying to finish this line of thought
<lekernel>
barmstrong, if your function tries to slice an expression it gets passed as parameter, and the user gives an int there - end of story
<barmstrong>
ok, i see.
<rjo>
barmstrong: migen "stores" everything. and then on conversion figures it out.
<lekernel>
anyway, time for bed
<lekernel>
gn8
<rjo>
barmstrong: but the metaprogramming levels need to know some things earlier (during construction).
<rjo>
lekernel: cu.
<barmstrong>
this is definitely a prickly issue for anything like a DSL
lekernel has quit [Quit: Leaving]
<rjo>
barmstrong: the metaprogramming is immensely useful.
<barmstrong>
yeah, absolutely
<barmstrong>
i should go back and re-read the migen source
<barmstrong>
i had a pretty good mental model of it at one point but obviously i got rusty