ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 5th
<_whitenotifier-f> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-f> [YoWASP/yosys] whitequark f9d312a - Update dependencies.
peepsalot has quit [Ping timeout: 246 seconds]
peepsalot has joined #nmigen
<_whitenotifier-f> [YoWASP/nextpnr] whitequark created branch release
<_whitenotifier-f> [nmigen] programmerjake opened issue #502: assignment not respecting RHS signedness -
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel_ has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
hitomi2509 has joined #nmigen
Chips4Makers has quit [*.net *.split]
Qyriad has quit [*.net *.split]
Qyriad has joined #nmigen
Chips4Makers has joined #nmigen
chipmuenk has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
electronic_eel_ is now known as electronic_eel
chipmuenk has quit [Remote host closed the connection]
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
chipmuenk has joined #nmigen
samlittlewood_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter has joined #nmigen
samlittlewood has quit [Ping timeout: 240 seconds]
samlittlewood_ is now known as samlittlewood
Asu has joined #nmigen
Qyriad has quit [*.net *.split]
smkz has quit [*.net *.split]
gravejac has quit [*.net *.split]
tucanae47_ has quit [*.net *.split]
Qyriad has joined #nmigen
tucanae47_ has joined #nmigen
smkz has joined #nmigen
gravejac has joined #nmigen
<lkcl> tpw_rules, oo nice. m.submodules["obj_{}".format(i)] is a lot nicer than using setattr.
<lkcl> DaKnig: lol, i keep doing that too :)
carlomaragno has joined #nmigen
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<DaKnig> how can I debug my DUT interactively?
<DaKnig> I have a function I attached to the simulation
<DaKnig> but it seems like it does not read the signals correctly
<DaKnig> (as the signals it reads are different from what I get in the vcd)
<lkcl> DaKnig: in theory it's possible with pdb
<lkcl> however i tend to simply drop in some "x = yield" statements
<DaKnig> `breakpoint()` and then `yield`?
<lkcl> followed by print ("x", x)
<lkcl> yes that would do it
<DaKnig> I literally have this `x = yield` but it does not show me the right answer
<DaKnig> which is what I am trying to debug lol
<lkcl> but remember that "interactive" would not write the vcd file correctly (it might be buffered)
<lkcl> this is pysim, right?
<DaKnig> yes
<lkcl> you got some code online?
<DaKnig> my code has some device that produces VGA signal so I made a VGA testbench
<DaKnig> that would use pygame to display the frame
<DaKnig> it worked! but hten it did not.
<DaKnig> it has synchronization and all that
<DaKnig> for some reason it outputs just 0s (black) while both the real life results and the vcd agree that this is not the case
<lkcl> DaKnig: unless you can show the code i can only "guess" the problem
<DaKnig> I could post it online but you'd need to install pygame and all that
<DaKnig> its multiple files
<lkcl> >>> import pygame
<lkcl> pygame 1.9.6
<DaKnig> is there a way to send a "view" link to a private github repo?
<DaKnig> I cant make it public for *reasons* but I can share it here if thats possible
<lkcl> no there isn't and i apologise i would not be interested to review private code
<lkcl> not unless you're prepared to contract me to help you at commercial rates
<DaKnig> this code would be open soure in 2 weeks
<lkcl> if you're working on libre-licensed code i'll gladly help you out
<DaKnig> its my own code, I did not copy anything from anybody else
<DaKnig> I just cant open the github repo
<DaKnig> my code is licensed under GPL3
<lkcl> apologies: you could decide not to do that.
<DaKnig> ok I can make it open for a day
<DaKnig> I gues
<DaKnig> s
<lkcl> anyone looking at the archives of this conversation, wanting to learn about the problem that you encountered
<lkcl> would you make it "open" to them too?
<DaKnig> I would send the link here!
<DaKnig> so sure!
<DaKnig> in a week or two I will open it completely
<lkcl> and they have to ask you
<lkcl> great - then i'm happy to assist you (without a commercial contract) in two weeks time.
<DaKnig> GPL3 means you or anybody can fork the thing at any time, which is ok by me, but it does not mean I have to host the code myself or make it visible for everybody except those who I give said software to (and allow them to redistribute this for free with the same license)
<DaKnig> I'd have to check a few things before I open the repo. I will say here if I can make it public now.
<DaKnig> ok it's good I think
<DaKnig> ... for some reason its not updated
<Stary> afaik it should work immediately
<Stary> does it still show private in the ui?
<lkcl> DaKnig: that's a 404
<DaKnig> this should work
<lkcl> yep that works
<lkcl> ok where's the... which line?
<DaKnig> btw, I completely understand and support your view of open source principles. no hard feelings here. thanks a lot for your time.
<lkcl> line 85 i'm guessing
<DaKnig> VGA_testbench is the file yes
<DaKnig> yes line 85
<DaKnig> if you run the code it produces a .vcd and should display the VGA signal to the screen
<lkcl> 1 sec
<DaKnig> to synchronize this one uses vsync so it just skips the first frame
<DaKnig> ah crap I forgot that you might be running it from the terminal/directly... add a breakpoint at the end to prevent it from exiting
<lkcl> are you getting this?
<DaKnig> I use emacs which has a pytohn debugger builtin and it stops the thing when it finishes
<lkcl> TypeError: Received unsupported command 1 from process '
<DaKnig> ... I dont get this
<DaKnig> ... right. I knowthe issue.
<DaKnig> I think I fixed it and the fix is gone now
<lkcl> you can't yield a signal that's already been yielded
<lkcl> you're overwriting the vsync signal with the *result* from the simulation *of* the vsync signal
<DaKnig> yeah right...
<DaKnig> I have fixed it locally lemme upload that
<lkcl> i'm not getting anything displayed btw. does it need to run for a long time before results appear?
<lkcl> i may not have left it long enough for vsync to fire (checking the vcd)
<DaKnig> it ignores the first frame
<DaKnig> I updated the version on github, though I should test another version that fixes *that* version. one sec, this wold be up.
<lkcl> arrrgh how the hell do you _stop_ pdb running?
<DaKnig> done
<lkcl> it's irrititating me like no end :)
<DaKnig> when pdb is running , press C-c to get back into pdb, then C-d to signify EOF
<DaKnig> that works for me
<lkcl> ok :)
<DaKnig> I uploaded the correct version online finally
<lkcl> yay. ok.
<DaKnig> so, the vcd shows that r/g/b change all the time. but the display doesnt show this
<DaKnig> ... are you familiar with pygame? I am 90% sure I use it correctly here
<DaKnig> but maybe I am not
<lkcl> DaKnig: it's been a while since i used it
<lkcl> let's see... eliminate pygame by setting x = 0xfffff...
<DaKnig> yeah it works
<lkcl> interestingly i am still seeing black screen
<lkcl> s[h][v] = 0xffffff
<DaKnig> are you sure? one pixel is easy to miss
<DaKnig> ah you have to update the screen
<DaKnig> pygame.display.update()
<DaKnig> just type this into pdb
<lkcl> hmmm.... still running through "counter is NNN scanlines" - nothing happening
<DaKnig> my code updates the screen only when it finishes drawing since updating takes a long time
<lkcl> ah then i'd recommend making the display area a *lot* smaller
<DaKnig> or just not waiting for vsync and accepting partially broken images :)
<lkcl> like... 240x180
<lkcl> yeah :)
<DaKnig> notice line 63
<DaKnig> I have a comment for this
<DaKnig> this and 75 should make it run faster
<lkcl> nope, getting really bored.. ah
<DaKnig> did poking it manually work when you used `update`?
<lkcl> missing a break
<lkcl> 1 sec
<lkcl> okaaay drawing (hurrah) all white
<DaKnig> so the code is not wrong about *that*
<lkcl> still investigating
<lkcl> ah got it
<lkcl> it's just not bright enough
<lkcl> correction is off i think
<DaKnig> aaaaAAAAAAARRRGH no!
<DaKnig> :(
<DaKnig> thanks a lot
<lkcl> correction = 1
<lkcl> s[h][v] = x << 4
<lkcl> and i get an image
<lkcl> correction should be... mmm... probably.... something like...
<lkcl> correction = (8-len( # makes colours shift up to 8-bit
<lkcl> so if the colours are 4 bit, you end up with a 4-bit correction
<lkcl> then do s[h][v] = x << correction
<DaKnig> thanks
<lkcl> :)
<lkcl> i'd also recommend making your life a lot easier by testing with much smaller display specs ;)
<lkcl> 180x120 or 240x180
<lkcl> or even smaller than that, just to get started
<DaKnig> I cant test with smaller displays as this output goes to HDMI and that cant accept lower than 640x480
<DaKnig> (unless you really wanna do something involved like line duplicaton etc)
<lkcl> you can always "test" at the smaller resolution then up it for HDMI later
<lkcl> it would save debugging time
<DaKnig> the thing is the test worked before, but I guess I found that out earlier and this didnt get saved for whatever reason
<lkcl> doh :)
<DaKnig> I remember finding this exact problem myself
<lkcl> lol funny
<lkcl> i'm forgetting things as well
<DaKnig> thanks a lot!
<DaKnig> I really appreciate you wasting your time for this crap
<DaKnig> the thing is the DUT in this case works ... but not the testbench. testing the testbench is harder than testing the DUT in some cases
<lkcl> haha yeah. formal proofs do my head in. we're treating them as unit tests, but... dang
alexhw has quit [Quit: No Ping reply in 180 seconds.]
vup has quit [Remote host closed the connection]
alexhw has joined #nmigen
vup has joined #nmigen
<FL4SHK> It looks like I'm going to be the first person to make a full line associative registers ecosystem
<FL4SHK> I *believe* I'm the only person working on such a thing
<FL4SHK> I'm doing all the hardware in nMigen
<FL4SHK> and I think the Binutils port is going to be pretty easy to make
lawrie has joined #nmigen
<FL4SHK> though I'm building a precursor machine before I build the LARs PC
<FL4SHK> the precursor machine will go ahead and not have floats
<FL4SHK> ...though I might change my mind on that!
lawrie has quit [Remote host closed the connection]
<lkcl> "associative" registers? you mean content-addressable?
<lkcl> or do you mean like L1 cache "set associative"?
<DaKnig> LARs
<DaKnig> Line Associative Registers
<DaKnig> its a weird architecture
<DaKnig> each "Line" is associated with some memory, so essentially you operate on cache lines
<lkcl> ooOooo
<FL4SHK> lkcl: I said "line associative registers"
<FL4SHK> I didn't say "associative registers"
<DaKnig> but I am sure FL4SHK will scold me again for not giving an exactly accurate explanation
<FL4SHK> no, your barebones explanation is basically correct from what I can tell
<lkcl> FL4SHK: the significance didn't sink in as i've not heard/used the term before.
<FL4SHK> I've built a processor like this before
<FL4SHK> fair enough lkcl
lawrie has joined #nmigen
<FL4SHK> It's not gone far yet
<FL4SHK> I aim to change this
<lkcl> ohhh i remember now, yes, we discussed this... mmmm 5 months back?
<FL4SHK> something like that?
<FL4SHK> Perhaps so!
<FL4SHK> I've built a LARs processor that only used LARs on the data side
<FL4SHK> LARs really aren't that weird, honestly
lawrie has quit [Remote host closed the connection]
<DaKnig> not at all :)
<FL4SHK> it just moves some of the stuff that implementers do in a CPU into the instruction set
<FL4SHK> people already make caches associative
<FL4SHK> you encode cache line numbers into instructions instead of register numbers
<FL4SHK> which scalar index of a LAR that you use is just base on the low bits of the address you loaded into the LAR
<FL4SHK> the model doesn't feel much different to program in assembly
lawrie has joined #nmigen
<FL4SHK> you are basically working with chunks of memory
<FL4SHK> I'm going to make a GCC backend where GCC thinks it's dealing with a memory-to-memory architecture
<FL4SHK> the only registers it'll need to know about are fp and sp
<lkcl> nice!
emeb has joined #nmigen
<DaKnig> @FL4SHK would this mean its a memory to memory architecture, with cache?
<FL4SHK> I'd argue that is is just similar to a memory to memory architecture
<DaKnig> you encode the addresses you operate on into instructions...
<FL4SHK> not the entire address
lawrie has quit [Remote host closed the connection]
<FL4SHK> you have loads and stores
hitomi2509 has quit [Quit: Nettalk6 -]
<FL4SHK> they move data into LARs
<FL4SHK> and change the LAR's address
<FL4SHK> so what you don't do is encode full addresses into instructions
<FL4SHK> you instead encode cache line numbers
<FL4SHK> those *aren't* addresses
<DaKnig> I see
<FL4SHK> it's much like working with a memory to memory architecture
jeanthom has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
<DaKnig> could it be that nmigen confused two signals with the same name?
<DaKnig> in the vcd writer I passed it along other things `` as a port. this signal is declared as having a width of 4.
<DaKnig> the vcd shows another signal named `blue` that has width of 9
<DaKnig> I have a different `color` I defined in a loop that used in a helper loop that also has a field named `blue`
<DaKnig> ... will make an issue
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 260 seconds]
<DaKnig> making a minimal working version is pretty difficult
<whitequa1k> nmigen doesn't internally use signal names for... well, anything
<whitequa1k> what might have happened though is that the VCD name assignment is confusing
whitequa1k is now known as whitequark
<DaKnig> I see
samlittlewood has quit [Quit: samlittlewood]
samlittlewood has joined #nmigen
Asu has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
emeb_mac has joined #nmigen