sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
_whitelogger has joined #m-labs
rohitksingh_work has joined #m-labs
sb0 has quit [Quit: leaving]
sb0 has joined #m-labs
<sb0> rjo: whitequark: do you know what is going on with SSL+IPv6 on https://buildbot.m-labs.hk and https://nixbld.m-labs.hk ?
<whitequark> I don't have IPv6
m4ssi has joined #m-labs
<sb0> seems what is happening is nginx is using the same certificate for all vhosts when connecting via ipv6 for some reason
<whitequark> ah, i think i know why
<whitequark> no, i don't.
<sb0> whitequark: it's using nginx on nixbld now, in case you were looking at the old debian settings
<whitequark> I was looking at /etc/nginx on lab.m-labs.hk
<sb0> okay, that's not used anymore
<whitequark> ah
_whitelogger has joined #m-labs
<rjo> no idea
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
sb0 has quit [Remote host closed the connection]
sb0 has joined #m-labs
<sb0> found the problem... it was me being dumb
<sb0> the DNS record contained the v6 address for the old machine, and that machine also had some bits of nginx settings that made it answer (but incorrectly)
<sb0> i still had in mind the NAT model of IPv4 so I didn't think of that
<sb0> things should work after the dns updates...
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 246 seconds]
cr1901_modern has quit [Ping timeout: 246 seconds]
cr1901_modern has joined #m-labs
cedric has quit [Ping timeout: 255 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<_whitenotifier-1> [nmigen] anuejn commented on issue #54: Hirarchy of submodules is not obvious from verilog - https://git.io/fjkNq
<_whitenotifier-1> [nmigen] whitequark commented on issue #54: Hirarchy of submodules is not obvious from verilog - https://git.io/fjkNG
sb0 has quit [Remote host closed the connection]
<_whitenotifier-1> [nmigen] anuejn commented on issue #53: Creating signals named like verilog keywords produces invalid verilog - https://git.io/fjkNo
<_whitenotifier-1> [nmigen] anuejn closed issue #53: Creating signals named like verilog keywords produces invalid verilog - https://git.io/fjkXQ
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
sb0 has joined #m-labs
mb-mlabs has joined #m-labs
<mb-mlabs> test
<sb0> test ok
mb-mlabs has quit [Remote host closed the connection]
matterbridge-ml has joined #m-labs
<matterbridge-ml> test 2
<sb0> xxx
<_whitenotifier-1> [nmigen] mithro opened issue #55: Should nMigen check Yosys version? - https://git.io/fjkxp
matterbridge-ml has quit [Remote host closed the connection]
matterbridge-ml has joined #m-labs
<matterbridge-ml> [mattermost] <sb10q> more testing
<sb0> great
<_whitenotifier-1> [nmigen] whitequark commented on issue #55: Should nMigen check Yosys version? - https://git.io/fjkxj
sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
<sb0> bot test
sb0 has quit [Quit: leaving]
rohitksingh has joined #m-labs
m4ssi has quit [Remote host closed the connection]
mumptai has joined #m-labs
rohitksingh has quit [Remote host closed the connection]
ZirconiumX has joined #m-labs
<ZirconiumX> Are "newbie experience reports with Migen" okay here? I've been struggling with it quite a bit as a newbie.
<whitequark> yeah
<ZirconiumX> So, the documentation seems a bit lacking to me; using https://m-labs.hk/migen/manual/ as a reference, there doesn't appear to be any discussion of some of the things in migen.genlib, such as the divider
<matterbridge-ml> [mattermost] <jbqubit> jbqubit joined the team.
<ZirconiumX> I also ran my (pretty basic) ALU under verilator's lint mode and it complained a lot; should I ignore those, are they a bug in Migen or in my code?
balrog has quit [Ping timeout: 245 seconds]
cedric has quit [Ping timeout: 246 seconds]
cedric has joined #m-labs
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has quit [Ping timeout: 246 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
balrog has joined #m-labs
<lkcl> ZirconiumX: are you familiar with python?
<lkcl> (welcome btw)
<ZirconiumX> Yeah, I am
<ZirconiumX> And thank you
<ZirconiumX> I'm not familiar with hardware dev though :P
<lkcl> ok cool, so you're used to doing unit tests
<ZirconiumX> Writing some up right now :P
<lkcl> i wasn't either. or, i am... however only at the gate level.
<lkcl> this was back iiin... 1980/1990 :)
<lkcl> my advice: start *really* small.
mumptai has quit [Quit: Verlassend]
<ZirconiumX> I'm trying to simulate 74 series chips
<lkcl> cool!
<ZirconiumX> The design I'm trying to build from them is a little more involved, though
<lkcl> well, split them into modules (have a look at e.g. PriorityEncoder as a template)
<lkcl> aand... where is it... one of the examples...
balrog has quit [Ping timeout: 245 seconds]
<lkcl> you're using nmigen or migen?
<ZirconiumX> `from migen import *`
<ZirconiumX> (I don't know)
<lkcl> migen.
<lkcl> btw... please... don't use "import *".
<ZirconiumX> I'm lazy, more or less
<ZirconiumX> Besides, almost all of the examples use it
<lkcl> do read that article, and others.
<lkcl> i know. that doesn't make it a good idea.
<lkcl> long story
<lkcl> ok so take a look at migen/examples/graycounter.py
<lkcl> hang on, no, not that one :)
<lkcl> it doesn't put a module *in* a module, it just imports one
<lkcl> 1 sec
<lkcl> let me find something...
<lkcl> instance.py example too complex for a starter...
<lkcl> ah! got one. two_dividers.py
<lkcl> you see how it creates a module, creates two Divider() instances
<lkcl> then adds them as submodules?
<ZirconiumX> Yeah?
<lkcl> adding the submodules is *critical*. if you don't do that, the inputs and outputs to the submodules don't get connected up, at the "top" level
<lkcl> i've made that mistake... :)
<lkcl> adding to m.submodules is the migen conceptual equivalent of python import
<lkcl> sort-of :)
<lkcl> or, kinda a python class instance
<lkcl> the weirdness is that you have to *manually* connect the inputs and outputs of the module, to signals in the place where it's to be used
<lkcl> module instance, sorry.
<ZirconiumX> https://gist.github.com/ZirconiumX/dd73ec8336901ec7163afaddf0f0ac63 <-- this is currently broken, I know
<lkcl> ZirconiumX: too much at once
<lkcl> recommend starting with just the one, e.g. IC74153
balrog has joined #m-labs
<ZirconiumX> But to test something like that, I would essentially have to reimplement the chip
<ZirconiumX> Or otherwise use the truth table from the specification sheet
<lkcl> the simulation side, yes.
<lkcl> preeeciselyyy, yes.
<lkcl> that's exactly what you need to do... as *python*
<lkcl> then the simulation has something to compare against.
<lkcl> the best most awesome example i ever saw of this was from cocotb
<lkcl> it grabbed a random verilog library for JPEG decoding off the internet
<lkcl> did an import from python-imaging
<lkcl> passed the input data to python-imaging *and* to the verilog simulation, and the output was the same
<lkcl> i was so impressed :)
<ZirconiumX> Okay, fair.
<lkcl> so yes, you absolutely have to make a "pythonic" implementation of whatever-it-is-being-tested
<lkcl> or... actually, i've seen examples which use python to run a unix pipe out to a separate c program
<lkcl> 1 sec...
<ZirconiumX> Is it best to instantiate a new migen module for each test?
<lkcl> a separate python module? mmm that's up to you
<lkcl> if you're used to nosetests
<lkcl> then you'll know that it's good practice to derive from python unittest and use class-based tests
<lkcl> basically, start really _really_ small
<ZirconiumX> Okay.
<lkcl> oh, and i also suggest, in each call to run_simulation, add the argument which gets it to generate gtkwave output
<lkcl> and run gtkwave on it.
<lkcl> it's fascinating, and also tells you what the hell's going on :)
<ZirconiumX> If a truth table contains don't cares, should I test it with all possible values to check they make no difference, or just handwave it?
<lkcl> you're used to python, you should do ok
<ZirconiumX> I'm no professional, but I've used it a fair bit
<lkcl> hmmm, i've not done dontcares before, i believe it might actually be possible to output "x"s
<lkcl> you'll have to ask someone else, or grep the source code, try looking in "specials"
<lkcl> personally, i'd run them anyway, just to make sure that all possible combinations are tested.
<lkcl> for code-coverage reasons
<lkcl> looking at the gtkwave output from run_simulation is really essential, btw.
<lkcl> it gives you a clue as a 2D plot over time, as to what's going on.
<lkcl> i wish standard python program debuggers had the same capability to do that!
<lkcl> showing the inputs/outputs vs time on a graph, as each line of code executed?? would be *really* handy
<lkcl> and that's what you've got, with gtkwave.
<lkcl> so if you forgot to add a "yield" to generate a new clock pulse, it'll show up immediately
<lkcl> suggest doing that as individual additions, by name
<lkcl> otherwise, the names will be anonymous
<lkcl> and you'll have a hard time identifying things in the auto-generated verilog output
<lkcl> ok i leave it with you :)
<ZirconiumX> PropTest for Migen when? :P
<lkcl> yeah there you go
<lkcl> just use it!
uberardy_ has quit [Quit: quit]
<ZirconiumX> So, I'm staring at GTKWave, and it's not at all helpful, lkcl
uberardy has joined #m-labs
<ZirconiumX> Everything is just flat
<ZirconiumX> And I don't get that with the gray counter example, so it must be in my code
<ZirconiumX> ...I didn't `yield` before looking at the result
balrog has quit [Ping timeout: 250 seconds]
balrog has joined #m-labs
futarisIRCcloud has joined #m-labs
balrog has quit [Ping timeout: 246 seconds]
forrestv has quit [Ping timeout: 258 seconds]