01:34 <wpwrak> interesting ... my registers do actually seem to be present, but at weird places

01:56 <wpwrak> okay, csr.h is just nonsense. nice trap :)

03:59 <wpwrak> hmm .... If(busy[i] and sense[i] != polarity becomes if ((mmc_mmc_dat[2] != counteradc_polarity)) begin ...

03:59 <wpwrak> why oh why did it steal the "and" ?

06:09 <larsc> you can't use 'and'

06:09 <larsc> use &

06:09 <wpwrak> GAAH ! use some pins of mmc.dat[] as output and migen makes ALL of them outputs, even if others are used only as input.

06:10 <wpwrak> (and) migen is full of traps ...

06:10 <wpwrak> i now used a double If. that works :)

06:10 <larsc> also & has higher precedence than !=

06:12 <wpwrak> hence "and" :)

06:12 <larsc> we can't overload and

06:13 <wpwrak> rm -f *.py; vi syntax.y

08:10 <sb0> wpwrak, (all outputs) what should it do instead? display an error?

08:11 <sb0> or split the vector between inputs and outputs? my days are only 24h and already eaten by stupid bugs like in the hdmi stuff...

12:03 <wpwrak> sb0: yes, splitting everything into single bits would probably the best idea. it seems that, as soon as you use an aggregate - especially an array - bad things happen

12:13 <wpwrak> sb0: and bugs are just a part of life ;-)

13:50 <sb0> wpwrak, how do you implement arithmetic if you only have single bits in verilog?

13:51 <sb0> also splitting everything into single bits will produce ugly code

13:52 <sb0> the verilog should still be human readable to some extent

13:52 <sb0> so you really only want to split when 1) the signal is an IO and 2) has bits with different directions

14:17 <wpwrak> in the most general case, you'd combine the single bits into a longer vector for access/operation

14:18 <wpwrak> it should then be relatively straightforward to add a peephole "optimizer" that combines things where possible

14:19 <wpwrak> in this case, the problem comes from migen's heuristics (generation of verilog declarations) going wrong. a contributing issue is that i think you don't really try to have a full semantical representation in migen, so migen doesn't even "know" something is wrong

14:26 <sb0> no, it's really just a verilog IO problem

14:26 <sb0> multi bit Signal == hardware integer == multi-bit verilog reg/wire

14:27 <sb0> actually, instead of splitting, I think using "inout" as IO port declaration could also work

14:27 <wpwrak> btw, in my ADC, the check for termination isn't so nice. structurally, the test for termination should be in the busy.re Else branch. but i'm not sure how that would be done in migen (without making too much of a mess)

14:28 <sb0> if the synthesizer does the right thing and doesn't try to mess with tri-state IO buffers

14:28 <wpwrak> heh ;-)

14:29 <wpwrak> the thing is that in verilog, you explicitly declare what an aggregate is. so it's clear that it all is input or output

14:29 <sb0> in migen too

14:29 <sb0> Signal() is an aggregate

14:29 <wpwrak> in migen, the declaration is implicit. so it's natural to assume the usual rules apply

14:29 <sb0> no it's not

14:30 <sb0> it's only "implicit" in the sense that mibuild returns you a multi bit signal when you have vectored pins

14:30 <wpwrak> in Pyton, array elements are just like individual variables. the element doesn't "feel" it's part of an aggregate

14:30 <sb0> it's not an array element

14:31 <sb0> another solution is to make mibuild return a python list of 1-bit signals when there are vectored pins

14:31 <wpwrak> look, feel, and smell are the same :) just the failure patterns differ

14:32 <wpwrak> yes, i think the basic unit in migen should be the single bit, not the aggregate

14:32 <sb0> then you get ugly generated verilog and messy arithmetic

14:32 <sb0> just to solve an IO problem, come on

14:32 <sb0> multi bit signals are great

14:33 <wpwrak> you can have the aggregate as a "hint" (e.g., bus[2] having attributes .parent_array = bus and .array_index = 2, or whatever). then the peephole optimizer could make an educated guess and produce more readable expressions. the semantics would be identical, though

14:34 <sb0> try inout

14:38 <wpwrak> so that's when you rewire the parameter passing logic ? (Instances, etc.) i thought migen was about making things simpler :)

14:38 <sb0> ?

14:38 <wpwrak> anyway, the ADC works as it is. luckily, i eventually found a combination where the default end up right

14:38 <sb0> no, I'm just saying that verilog may not whine anymore when you have a vectored port with differing directions declared as inout

14:39 <wpwrak> and the way to declare that would be via Instance.Inout ? that's the only mention of "inout" i found in the manual

14:39 <sb0> no, the verilog "inout" keyword

14:40 <wpwrak> so i should patch top.v ?

14:40 <sb0> instead of input/output. nothing to do with instances

14:40 <sb0> yes try that first and then inout should be selected automatically when there is this problematic use of vectored signals

14:41 <sb0> bbl

14:42 <wpwrak> hackish :)