<awygle>
whitequark: what I'm actually most interested in is (in no particular order) nmigen-stdio, FIRRTL backend (and Yosys front-end), and simulator improvements
<awygle>
But I also want to reduce the number of issues that are open, and on certain days I find "number go down" extremely motivating
<awygle>
So I have no problem with also working on the CDC stuff
<awygle>
Not to mention that I am much more qualified for CDC stuff than for two of the three of those other things :-P
Degi has quit [Ping timeout: 250 seconds]
Degi_ is now known as Degi
Vinalon has quit [Read error: Connection reset by peer]
Vinalon_ has joined #nmigen
_whitelogger has joined #nmigen
<awygle>
whitequark: speaking of simulator improvements, should `if (yield signal.eq(1))` be a warning/error in pysim? is that even possible?
<whitequark>
awygle: oh I see!
<whitequark>
re sim warning: we can detect that i think
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
felix_ has quit [Ping timeout: 260 seconds]
felix_ has joined #nmigen
<awygle>
Seems like a fairly easy fuck up to make (source: I made it)
<whitequark>
it didn't occur to me that this would be a problem but it sure can be
<whitequark>
def __bool__(self):
<whitequark>
raise TypeError("Attempted to convert nMigen value to boolean")
<whitequark>
s/value/statement/
<whitequark>
add to Statement, write tests, done
<awygle>
Copy, wilco
thinknok has joined #nmigen
Asu has joined #nmigen
Vinalon_ has quit [Ping timeout: 260 seconds]
_whitelogger has joined #nmigen
Bernhard2 has joined #nmigen
<Bernhard2>
Hello everyone. I have a little question about Nmigen:
<Bernhard2>
input = [Signal (16)] * (n + 1) # Generates an empty List with zeros
<ktemkin>
Bernhard2: what's your question?
<ktemkin>
[also, that code -probably- doesn't do what the author intended; since that creates a single Signal(16) and then effectively adds it to the relevant list (n+1) times]
<ktemkin>
an equivalent that _does_ create `count`> unique signals would be [Signal(16) for _ in range(count)]
<Bernhard2>
I try to create a list of Signals(16) wich rotates with every "yield" in my testbench(dut). After each rotation the first Signal in this list sould be replaced with a new value.
<Bernhard2>
ktemkin -> [Signal(16) for _ in range(count)] true this was allready wrong from my side :(
<ktemkin>
to answer the literal question: you can treat the problem more or less like any other python program
<ktemkin>
but I am curious what you're trying to do :)
<Bernhard2>
I try to build an Filter with Nmigen, because I can export this code directly into .vcd files which can be analyzed with software like gtkwave.
<Bernhard2>
For my input function as well as for my output function I need a list of Signals, which rotates with every yield
<Bernhard2>
At least this is my actual idea how it could work :)
<vup>
whitequark: re #6 I understand, its also more of a long term interest for me
<vup>
re log coloring, what would be the main reason to not include it with nmigen? cross platform problems and the difficulty of finding colors that work for everyone?
<vup>
having a colored log helps me quite a bit to notice that something is potentially going wrong, but maybe I also have the wrong workflow and should just be grepping the log for warning, etc
<vup>
Bernhard2: how do you want to use your signals? If you only need one Signal in each step, maybe a fifo, that feeds the output to the input could work?
<Bernhard2>
Mhm i need all Signals in this list parallel. Therefore I created a list of Adder and a List of Multiplier to. But actually i am too stupid to make this thing rotating. :(
<vup>
well python lists are not nmigen primitives, so it doesn't really work the way you want to use it I think.
<vup>
Bernhard2: I am not exactly sure want you want to achieve, but maybe a combination of Array and manipulation of the indices used to access the Array could work for you?
<vup>
(What I mean is, instead of rotating the list / array, you can increment (wrappingly) the indices used to access the list / array by one and get the same effect)
<MadHacker>
You can use a case to switch between. with Switch(inputThing): for i in range(16): with Case(i): m.d.sync += [output.eq(myArray[i]]
<ktemkin>
unless I'm misreading, that's what Array is for
<ktemkin>
if you want a collection that can be indexed by a -signal-, Array will give you what you want
<MadHacker>
You are almost certainly right; I was just off-the-top-of-my-head-ing a suggestion.
<MadHacker>
You've more experience than me, you'll know better.
<ktemkin>
e.g. `collection = Array(Signal(16) for _ in range(16))` then allows you to do `output.eq(collection[another_signal])`
<MadHacker>
That sounds like what Bernhard2's after to me.
<ktemkin>
(I still don't exactly grasp what they're trying to do)
<MadHacker>
It sounded like they wanted access to all the bits of the array and then to shift it around ala barrel shifter for filtering, so want to be able to assign the whole thing to itself-shifted?
<MadHacker>
But I'm sure they can speak for themselves.
<MadHacker>
Bernhard2: ?
<ktemkin>
it sounded to me like the inputs they wanted were test simuli, rather than anything in the hardware, in which case one can just manage the array using normal python and then loop to yield to the appropriate signals
<ktemkin>
but this is the kind of context I'm missing :)
<MadHacker>
That'd make sense too. Aye.
<ktemkin>
s/array/list, there, but yeah
<MadHacker>
Oh well. Maybe we've offered some useful suggestions. Also, thanks for pointing out that an Array does what I was trying to do with the Switch.
<MadHacker>
'tis tidier.
<Bernhard2>
I try to discribe my Idea a bit better: Signal A goes into the List/Array // Clock One: Signal A is multiplied bei b0 = Output + Signal A is transfered into the List/Array position 2 + Signal B is transfered into the first position of the List/Array // Clock Two: Signal B is multiplied by a0 +Signal A is multilpied by a1 + B*b0 + A*b1 = Output
<key2>
I actually wrote a polyphase FIR (wiht complex I/q) a while back
<key2>
for sample rate conversion
<Bernhard2>
Awesome, thank you so much. That will push me with this project :)
peteut has joined #nmigen
Vinalon_ has joined #nmigen
<Sarayan>
Is Robert Baruch someone here?
thinknok has quit [Ping timeout: 272 seconds]
<awygle>
Not AFAIK
chipmuenk has joined #nmigen
cyberclown has quit [Remote host closed the connection]
<Sarayan>
damn, too bad
cyberclown has joined #nmigen
____ has joined #nmigen
<whitequark>
vup: re vivado log coloring: yes, it complicates the build process considerably and adds code to nmigen that isn't really nmigen's responsibility
<whitequark>
I propose that you write a wrapper for the `vivado` tool that does this, and use the overrides feature to make nmigen use it
<whitequark>
if the wrapper is cross-platform, simple and reliable, and there is overwhelming interest in using it for all Vivado builds, we can see how to integrate it
<emily>
"wrapper for vivado that makes it behave like a normal unix tool and not a rampaging monkey while adding convenience features" sounds like the kind of thing that'd be a nice value-add for nmigen
<emily>
if it were, say, written in python so it could reliably be bundled with build directories
<emily>
(but not in-scope for nmigen itself, ofc)
<emily>
might simplify some of the build system contortions
<whitequark>
emily: but if the wrapper is optional, it would imply supporting two interfaces for vivado in nmigen instead of one...
<whitequark>
branched in the shell script no less
<emily>
hence I didn't say anything about optional
<vup>
whitequark: sounds good
<whitequark>
I don't think it can be made non-optional without breaking remote builds
<emily>
I meant that "decorating output" by itself might not be compelling but it if came bundled with "make vivado behave more normally" then it'd allow nmigen to reduce complexity
<whitequark>
hmm
<emily>
sure it can: "if it were, say, written in python so it could reliably be bundled with build directories"
<emily>
would require some packaging work, admittedly
<whitequark>
we don't currently require python on the build machine at all
<emily>
oh right
<emily>
i remember trying to convince you you should
<emily>
then you could drop all the awful batch nonsense too
<vup>
emily: what do you mean by by making it behave like a normal unix tool? That it messes with LD_LIBRARY_PATH?
<whitequark>
mhh
<whitequark>
i still think that would create more problems than it'll solve
<whitequark>
ansible does something like it, and i think they had to spend a very significant amount of effort to make it work well
<emily>
vup: like, the whole NMIGEN_ENV_Vivado is because vivado is horrible and you need to set up a billion environment variables incl. LD_PRELOAD or whatever
<emily>
admittedly a lot of that will be site-specific i guess, but i feel like you could at least go some way to making it be a bit more normal
<emily>
a lot of the build logic is kind of gross because the proprietary toolchains are gross
<vup>
hmm I the way nmigen does it with NMIGEN_ENV_Vivado is working quite well for me, doing all the stuff their scripts are doing ourselves doesn't seem like that good of an idea
<vup>
I feel like just moving the logic is kind of the same as using for example edalize, which wq (for good reasons) didn't really like
<whitequark>
emily: is that really true for vivado?
<emily>
it probably moreso applies to the older toolchains yeah
<whitequark>
their script sets up one env variable, XILINX_VIVADO
<whitequark>
and PATH
<emily>
I'm thankfully too cool to have ever actually run vivado... for now
<whitequark>
yeah, it's more for ISE, Lattice stuff, and so o
Sarayan has quit [Quit: reboot, brb]
cyberclown has quit [Remote host closed the connection]
cyberclown has joined #nmigen
Bernhard2 has quit [Remote host closed the connection]