sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<cr1901_modern>
larsc: Well, at least YOU offered a solution, even if it's a bad one ;)
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
<sb0>
cr1901_modern, I reckon you cannot disable that warning because Clifford doesn't want to encourage simulation/synthesis mismatches
<sb0>
ironically, Migen uses them to patch up a simulation/synthesis mismatch that exists in Verilog in the first place
<sb0>
maybe tell him that
<cr1901_modern>
sb0: Can you elaborate (afk)? All I've ever seen those directives do in Migen is disable/enable dummy registers that are otherwise unused.
<sb0>
yes. the reason those dummy registers exist is to fix a simulation/synthesis mismatch.
<sb0>
they are useful in simulation to get all the always @* blocks to run once at startup
<sb0>
and useless in synthesis. if there wasn't the "translate off" you'd get warnings about unconnected registers ...
rohitksingh_work has joined #m-labs
fengling has quit [Quit: WeeChat 1.4]
fengling has joined #m-labs
sb0 has quit [Quit: Leaving]
FelixVi has quit [Remote host closed the connection]
fengling has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 244 seconds]
rohitksingh_work has joined #m-labs
fengling has joined #m-labs
rohitksingh_work has quit [Quit: Leaving.]
mumptai has quit [Remote host closed the connection]
FabM has joined #m-labs
rohitksingh_work has joined #m-labs
<sb0>
ooh, i found a bunch of evil python hacks that would enable things like this
<sb0>
no more operator precedence mess, no more .eq() and If()
<sb0>
and the idea behind "ports" is you can either pass the io signals as parameters when instantiating, or the default sizes are created - in the end you automatically get them as attributes
fengling has quit [Ping timeout: 240 seconds]
<whitequark>
sb0: I think that's even worse than .eq() and If()
<whitequark>
well, for one, how do you unquote?
<sb0>
what is unquote?
<whitequark>
unquote, splice, etc
<whitequark>
you are suggesting a quasiquotation mechanism
<whitequark>
i.e. you are describing data structures using python code as notation
<whitequark>
unquotation would mean inserting dynamic values into this chunk from some outer context.
<sb0>
eval()
<whitequark>
uh, no.
<sb0>
why not?
<whitequark>
assuming I understand how the system would like when it's done, the question is "why yes?"
<sb0>
so I can do things like "record.raw_bits().next = value"
<sb0>
the translator passes the call to record.raw_bits() to eval()
<whitequark>
you're replacing a DSL that poorly approximates the concepts of migen with regular Python code, with a DSL that poorly approximates the concepts of migen with magical python code
<sb0>
no, with this hack it's just a syntax change
<whitequark>
yes. i am talking about syntax here.
<whitequark>
there is nothing magical about If() and eq(). how they work is immediately obvious to anyone who's touched Python
<sb0>
yes, but they don't look nice
<whitequark>
and that's not true with your hack. I don't see how that is a fair exchange for marginally less boilerplate
<sb0>
and there are so many syntax options: self.sync += statement, self.sync += [statement], self.sync += [statement1, statement2]
<sb0>
with indentation issues
<whitequark>
that's not a reason to invent your special snowflake language
<sb0>
special snowflake?
<whitequark>
if you *are* going to invent one, then make it actually map one to one to migen's concepts
<whitequark>
yes.
<whitequark>
it hijacks syntax of python to do something completely unrelated.
<sb0>
it's not that completely unrelated: myhdl has a complete hdl based on the python syntax.
<sb0>
and the only valid statements inside the hacked context managers are those that map directly to migen
<whitequark>
i know. and didn't you correctly complain in migen's documentation that myhdl makes it hard to programmatically generate logic ?
<sb0>
yes, which is solved by the context manager hacks
<whitequark>
"solved"
<sb0>
yeah? give me one thing that will break in a particularly nasty way
<whitequark>
that's your only criterion?
<whitequark>
not introduce particularly nasty failures? everything else doesn't matter?
<sb0>
ok, give me an example of a nasty failure
<whitequark>
yes. Python syntax is used to write something else than Python.
<sb0>
and?
<sb0>
myhdl already does exactly that, and it doesn't work that badly
<whitequark>
so, how do you unquote? eval() is not the answer to this
<whitequark>
I'm not asking about implementation, I'm asking about language design
<whitequark>
inside the quoted context, how exactly do I insert arbitrary Python logic?
<whitequark>
how do I capture a quoted signal in an unquoted variable? how do I write a loop? etc.
<sb0>
yes. in general the logic is outside.
<whitequark>
so this is the same rigid method as myhdl uses
<whitequark>
here's the specifics on your nasty failure. once you discover that you need logic inside a quoted snippet, you have no choice but to artificially break it up
<sb0>
not quite. myhdl is really restrictive.
<sb0>
how is that different than needing logic in the middle of a self.sync += ...?
<whitequark>
are you carrying locals over from the callee scope?
<sb0>
did you mean the caller? yes
<whitequark>
and allow arbitrary function calls?
<sb0>
not exactly sure what you mean by "arbitrary", but things like "x.next = some_function()" would be allowed, yes
<sb0>
and yes, there is a problem with handling the return value of some_function(). especially if it's an expression that involves signals.
<sb0>
but this code pattern is rare
<sb0>
the solution would be to keep the current overloads of operators, so that some_function() can return the expression (same mechanism as now)
<sb0>
it's ugly, yes. and it doesn't handle "and" and "or", which cannot be overloaded
<sb0>
or, since that situation is rare, just use the current _Operator directly in some_function()...
<sb0>
the operator overloading (and especially ==) is kinda nasty as well, especially when dicts and sets are involved
<whitequark>
you could handle the return value by calling the context manager directly on a lambda
<sb0>
well, the context manager doesn't execute the code inside it
<sb0>
it just translates it
<whitequark>
exactly
fengling has joined #m-labs
sb0 has quit [Quit: Leaving]
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 252 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
tmbinc__ has joined #m-labs
sb0 has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<cr1901_modern>
whitequark: yes. Python syntax is used to write something else than Python. Could you elaborate? What's different about Migen as it is now? Wouldn't all the overloaded operators that Migen currently uses count as "using Python syntax to write something else than Python"?
<whitequark>
no.
<whitequark>
.eq() means calling a function. = means assignment
<whitequark>
with the context manager hack, = means adding an element to an array.
rohitksingh has joined #m-labs
fengling has joined #m-labs
<cr1901_modern>
Ahhh I see I think. In http://hastebin.com/maqoferoya.py, self.o = ~self.o maps to "add this statement to the end of the internal array of synchronous statements". Is this correct?
<whitequark>
yes
fengling has quit [Ping timeout: 240 seconds]
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined #m-labs
rohitksingh1 has quit [Ping timeout: 276 seconds]
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh1 has joined #m-labs
rohitksingh has joined #m-labs
<sb0>
whitequark, one case where the hacked context managers do not work is this:
<sb0>
I suppose that those can just build the migen ast manually
fengling has joined #m-labs
<whitequark>
yes. this is a good example of what i was talking about.
<whitequark>
you could just keep the existing interface.
fengling has quit [Ping timeout: 240 seconds]
<GitHub27>
[migen] sbourdeauducq created experimental (+2 new commits): https://git.io/v6fl3
<GitHub27>
migen/experimental 175448c Sebastien Bourdeauducq: fhdl/verilog: make sure ios is a set
<GitHub27>
migen/experimental fc1fb7e Sebastien Bourdeauducq: add experimental module2 API
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh1 has quit [Ping timeout: 260 seconds]
<cr1901_modern>
sb0: Are there any plans to deprecate the Module API in the future? I kinda echo whitequark's concerns now that I understand what they're talking about.
<sb0>
well obviously we still need a way to do round-robin arbiters and the like.
<cr1901_modern>
I think I'll stick with the curr API until further notice. I'm not a stickler for syntactic sugar. In fact, it tends to confuse me more than anything
<sb0>
also there will be no eval() or arbitrary function calls; otherwise, there are nasty corner cases if someone does function(signal_a and signal_b)
<sb0>
function calls will have to be decorated and some of their arguments pre-translated
<cr1901_modern>
What's nasty about "signal_a and signal_b"?
<sb0>
and/or cannot be overloaded and will convert to bool
<cr1901_modern>
I've always used "&" in place of "and"... are they different?
<sb0>
yes
<cr1901_modern>
I can't think of any place where I've used "and"/"or" in a migen statement, tbh. I've always used &/|.
<GitHub20>
[migen] sbourdeauducq pushed 2 new commits to experimental: https://git.io/v6fBb
<GitHub20>
migen/experimental 9964693 Sebastien Bourdeauducq: module2: function call and if support
<GitHub20>
migen/experimental 462005f Sebastien Bourdeauducq: import module2 with *
<GitHub174>
[migen] sbourdeauducq pushed 1 new commit to experimental: https://git.io/v6fRY
<GitHub174>
migen/experimental 8b64f86 Sebastien Bourdeauducq: fhdl/verilog: call get_ports() to get default ios
<cr1901_modern>
Hrm, reading "and" is logical-and and "&" is bitwise-and. They'll be equivalent when one-bit signals are tested, but in all other cases when does logical-and make sense in the context of HDL?
<sb0>
python is hardwired to convert operands of and/or to bool.
rohitksingh has quit [Ping timeout: 250 seconds]
fengling has joined #m-labs
rohitksingh has joined #m-labs
<cr1901_modern>
sb0: Is that what you want? All one-bit signals are bools internally in the Module2, integers otherwise?
fengling has quit [Ping timeout: 240 seconds]
<sb0>
?
sb0 has quit [Ping timeout: 265 seconds]
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 258 seconds]
mumptai has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
rohitksingh1 has quit [Quit: Leaving.]
<cr1901_modern>
sb0: Rephrased: Why did you replace (or seemingly replace) "&" with "and" and "|" with "or" in the new Module2 class?
<GitHub18>
artiq/master 4077613 Kelly Stevens: doc: re-formatting a directory path in lda driver comments so it will display correctly in the sphinx documentation
<GitHub76>
[artiq] jordens pushed 1 new commit to release-1: https://git.io/v6Jkd
<GitHub76>
artiq/release-1 d571113 Kelly Stevens: doc: re-formatting a directory path in lda driver comments so it will display correctly in the sphinx documentation