| wpwrak | interesting ... my registers do actually seem to be present, but at weird places | 01:34 |
|---|---|---|
| wpwrak | okay, csr.h is just nonsense. nice trap :) | 01:56 |
| wpwrak | why oh why did it steal the "and" ? | 03:59 |
| 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:09 |
| 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:10 |
| wpwrak | hence "and" :) | 06:12 |
| larsc | we can't overload and | 06:12 |
| wpwrak | rm -f *.py; vi syntax.y | 06:13 |
| sb0 | wpwrak, (all outputs) what should it do instead? display an error? | 08:10 |
| 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... | 08:11 |
| 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:03 |
| wpwrak | sb0: and bugs are just a part of life ;-) | 12:13 |
| sb0 | wpwrak, how do you implement arithmetic if you only have single bits in verilog? | 13:50 |
| sb0 | also splitting everything into single bits will produce ugly code | 13:51 |
| 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 | 13:52 |
| wpwrak | in the most general case, you'd combine the single bits into a longer vector for access/operation | 14:17 |
| wpwrak | it should then be relatively straightforward to add a peephole "optimizer" that combines things where possible | 14:18 |
| 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:19 |
| sb0 | no, it's really just a verilog IO problem | 14:26 |
| sb0 | multi bit Signal == hardware integer == multi-bit verilog reg/wire | 14:26 |
| 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:27 |
| sb0 | if the synthesizer does the right thing and doesn't try to mess with tri-state IO buffers | 14:28 |
| wpwrak | heh ;-) | 14:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| sb0 | try inout | 14:34 |
| 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:38 |
| 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:39 |
| 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:40 |
| sb0 | bbl | 14:41 |
| wpwrak | hackish :) | 14:42 |
| --- Fri Apr 19 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!