ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting November 23th
<_whitenotifier-f> [nmigen-boards] whitequark reviewed pull request #132 commit - https://git.io/JkSYE
<_whitenotifier-f> [nmigen-boards] GuzTech synchronize pull request #132: Change Resource function parameter names to reflect polarity - https://git.io/JkSqU
<_whitenotifier-f> [nmigen-boards] GuzTech synchronize pull request #132: Change Resource function parameter names to reflect polarity - https://git.io/JkSqU
<_whitenotifier-f> [nmigen-boards] GuzTech reviewed pull request #132 commit - https://git.io/JkSYF
<_whitenotifier-f> [nmigen-boards] GuzTech commented on pull request #132: Change Resource function parameter names to reflect polarity - https://git.io/JkSOv
<_whitenotifier-f> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JkSOT
<_whitenotifier-f> [YoWASP/nextpnr] whitequark fc2134f - Update dependencies.
<mithro> Yeah, I could potentially fund stuff like this...
<whitequark> once we deal with the 2020-induced backlog of issues, i would actually prefer if you found someone to do the work
<_whitenotifier-f> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JkSsO
<_whitenotifier-f> [YoWASP/yosys] whitequark 025ebc0 - Update dependencies.
emeb has quit [Quit: Leaving.]
<mithro> whitequark - I'll see what I can do....
<whitequark> it seems like a not particularly complex task... a motivated gsoc student could do it for sure
vup has quit [Remote host closed the connection]
<mithro> @whitequark I think having it published in Sphinx documentation would also be good
<whitequark> that was the original plan
<whitequark> all of the effort that goes into anntoating boards must be reflected in the docs
vup has joined #nmigen
<whitequark> i am motivated to implement any necessary sphinx extensions, provided we actually work out a good data model
<mithro> whitequark: Yeap! That is excellent.
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #nmigen
sjolsen has quit [Remote host closed the connection]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
emeb_mac has joined #nmigen
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined #nmigen
mogery has joined #nmigen
_whitelogger has joined #nmigen
samlittlewood has quit [Quit: samlittlewood]
chipmuenk has joined #nmigen
DaKnig has quit [Ping timeout: 264 seconds]
DaKnig has joined #nmigen
<mogery> hey, i'm trying to make a VGA implementation but it's not working (or at least my monitor doesn't like it). could anyone take a look? i'm trying to use the SVGA 800x600@60Hz spec, but scaled down to 10MHz from 40MHz (800x600->200x600). here's the code i've written for it: https://gist.github.com/mogery/3d5a0dc6c3e8f737ac871eaf82ec09e4
<mogery> looks fine to me in testbench/gtkwave, doesn't work IRL. i was looking at this while writing it: http://tinyvga.com/vga-timing/800x600@60Hz
<mogery> here's a gtkwave file: https://mogery.me/vga.gtkw
<Sarayan> it's all about the syncs
<Sarayan> you sure of voltages level and stuff, and whether it's sync-on-green or somewhere else?
<mogery> yeah, but they looked fine in gtkwave, and i've got no scope to test it out irl
<mogery> what's the monitor's inner resistance for sync lines?
<Sarayan> between c-sync and sync-of-green there are so many ways your monitor can be cranky
<mogery> well that's horribly dumb
<Sarayan> I'm not saying that's your problem, but it's clear there's dragons there
<mogery> yeahh
<mogery> so should i also send green when i send the sync signals?
<Sarayan> you can try
<Sarayan> and possibly c-sync too
<Sarayan> then there's negative and positive polarity
emily has quit [Quit: Bridge terminating on SIGTERM]
cesar[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[m] has quit [Quit: Bridge terminating on SIGTERM]
jfng has quit [Quit: Bridge terminating on SIGTERM]
gkelly has quit [Quit: Bridge terminating on SIGTERM]
<mogery> uhoh
mogery has quit [Read error: Connection reset by peer]
mogery has joined #nmigen
<mogery> welp, that wasn't it
<mogery> sync voltage is supposed to be, like, 3.3V TTL right?
<mogery> or, well, it's supposed to be 5V but 2V+ is high
<Sarayan> Ewww, that's analog, that's dirty
<whitequark> iirc monitor hsync/vsync are TTL
<mogery> ¯\_(ツ)_/¯
<mogery> wow
<mogery> idk if that failed spectacularly only for me
<mogery> but thats not what a shrug's supposed to look like
<whitequark> mogery: have you simulated it with the PLL?
<mogery> how would i go about doing that?
<mogery> can the sim, just like, handle altpll?
<whitequark> synthesize to verilog, stuff it into altera's tools
<mogery> ooooh
<whitequark> it is a pain, but... if you subtly misconfigured the PLL?
<mogery> yeah, that could be causing all kinds of weird shit.
<whitequark> without a scope or a simulation it would be essentially impossible to tell
<mogery> need to get quartus's GUI to actually work then instead of crashing out when i create/open a project
<whitequark> there is also a simpler solution
<whitequark> just use this mode, for which you will not need a PLL because it has 50 Hz pixel clock
<mogery> doubt my monitor would want to deal with that
<mogery> or can deal with that at all
<whitequark> really? what sort of antique do you own?
<mogery> not antique, but this monitor tends to be flaky with signals that aren't 60Hz
whitequark[m] has joined #nmigen
<whitequark> i see
<mogery> linux's non-free divers just straight up refuse to work with this monitor
<mogery> the monitor prints an error message and that's it
<mogery> no video
<whitequark> ok, well, there is a similar solution but it requires slighlty more thinking
<mogery> or, sorry, free drivers*
<Sarayan> Do you have the working modeline?
<whitequark> i see Sarayan is thinking in the right direction
<mogery> heh
<Sarayan> :-)
<mogery> mightaswell try the 72Hz one
<whitequark> you can take your 50 MHz clock, which is completely local to your FPGA, and then make any HSYNC/VSYNC timings you might want to have
<whitequark> you simply have to pick the right divisor factors
<mogery> yeah
<mogery> or i can have a counter that resets at, idk, value 5
<mogery> and then do something everytime it's value is 0
<mogery> and boom 10 MHz
<whitequark> hm
<whitequark> actually now that i look at altpll, how did you configure it?
<mogery> operation_mode normal, inclk0_input_frequency 20000, compensate_clock CLK0, clk0_divide_by 5, clk0_multiply_by 1, inclk self.clk50 (passed from main module), clk cd_sync.clk
mogeryy has joined #nmigen
<mogeryy> well that was odd
<whitequark> mogery: are you sure that these connections and parameters are sufficient?
<mogeryy> i'm fairly sure. worked for when i was tuning a buzzer's note
<whitequark> i see
mogery has quit [Ping timeout: 260 seconds]
<whitequark> can you share the file you use for synthesis?
<whitequark> actually, i have a few altera boards, which i think have vga
<whitequark> i could simply hook it up to a scope
mogeryy is now known as mogery
<mogery> yup one sec
cesar[m] has joined #nmigen
jfng has joined #nmigen
emily has joined #nmigen
gkelly has joined #nmigen
<whitequark> that's the same file
<mogery> oh right.
<mogery> thats the main file, testbuzzer and testdisplay are the other ones using PLL, but i doubt they'd interfere
<whitequark> oh right, it's not one of the usual terasic boards
<mogery> yupp
<mogery> someone apparently got VGA working on the board, so the board itself is probably not the issue
<whitequark> mkay, let me dig out some of the terasic stuff.
<mogery> sick, ty
<mogery> oh hmm. apparently 640x480@60Hz also uses a 50MHz pixel clock?
<mogery> wait. no it doesn't what
<mogery> oh.
<mogery> Warning : This code uses a 50 MHz mater clock,
<mogery> which generates a 25 MHz pixel clock,
<mogery> slightly out of spec (25.125 MHz).
<mogery> great
<mogery> whitequark: what if i added a 40MHz clock constraint?
<mogery> would that work better than a dodgy altpll instance?
<whitequark> that wouldn't change the clock frequency
<whitequark> gimme a sec, i just uploaded it
<mogery> oh
<mogery> alrighty
<whitequark> vsync: 60.3173 Hz
<whitequark> hsync: 37 kHz
<mogery> huh
<mogery> do i have my resets off?
<mogery> vsync is a bit fast
<whitequark> hm
<whitequark> the PLL generates 10.0001 MHz
<mogery> is that enough to throw it off?
<whitequark> no
<whitequark> it might even be my scope being wrong
<mogery> yeah than i have my counter resets off
samlittlewood has joined #nmigen
<whitequark> what monitor is it?
<mogery> dell p2312h
<whitequark> wait
<whitequark> are you sure your sync polarity is correct?
<mogery> sync is low-going right?
<mogery> low-active i mean
<whitequark> http://tinyvga.com/vga-timing/800x600@60Hz this says polarity: positive
<mogery> what the hell
<whitequark> going through my old vga code... i also used positive, for some random viewsonic someone threw away
<mogery> ive tried it in positive as well but it did not work
<mogery> lets try positive... again!
<mogery> ohh yup
<mogery> my reset code was wrong i think...
<mogery> lets try new reset code and other polarity
<mogery> wait a sec, am i also supposed to be turning hsync on while vsync is on?
<whitequark> no
<whitequark> those drive two different PLLs in the monitor
<mogery> alright, cool
<whitequark> or at least used to
<mogery> same thing, panel doesn't wanna turn on
<whitequark> the other thing that might be a problem is phase
<whitequark> take a look here: https://paste.debian.net/1174433/
<whitequark> oh, hm
<whitequark> nevermind, i think i misunderstood your code
<whitequark> ok, no idea
<mogery> oh dang
<mogery> there's a `max` property for signal
<mogery> that'll help a bunch
<mogery> is that inclusive or exclusive max?
<whitequark> where are you seeing `max`?
<mogery> in the debian paste you sent
<whitequark> oh sorry
<whitequark> that's migen code, not nmigen
<mogery> oh heh alright
<whitequark> for nmigen, read this section: https://nmigen.info/nmigen/latest/lang.html#shapes
<whitequark> (max was removed *specifically* because of the confusion between inclusive/exclusive...)
<mogery> oh lol
<mogery> holy shit it works
<mogery> needed to fix my counter stuff.
<whitequark> huh, what was the bug?
<mogery> 1. my counter incremented in the wrong place and generally reset wrong. 2. i actually did need to send hsync while vsync was on
<whitequark> oh sorry, i misunderstood your question re: 2
<mogery> i put my counter in the beginning and not the end, so it started at 1 and such
<whitequark> i see
<mogery> i rewrote it with mux and put the counter in the end, and it works now
<mogery> thank you for the help, i probably would've given up by now if i was alone lol
<whitequark> np, i'm glad that was time well spent
DaKnig has quit [Ping timeout: 240 seconds]
jeanthom has quit [Ping timeout: 265 seconds]
DaKnig has joined #nmigen
<_whitenotifier-f> [nmigen-boards] whitequark closed pull request #132: Change Resource function parameter names to reflect polarity - https://git.io/JkSqU
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±38] https://git.io/JkHO6
<_whitenotifier-f> [nmigen/nmigen-boards] GuzTech b40c3d6 - [breaking-change] Add `_n` suffix to argument names of pins with fixed inverters.
<_whitenotifier-f> [nmigen-boards] whitequark closed issue #129: Add `_n` suffix to names of pins with fixed inverter in resource factories - https://git.io/JkSeW
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
DaKnig has quit [Ping timeout: 240 seconds]
<mogery> hmm. the clock for the SDRAM chip on this board is driven by the pin PLL1_CLKOUT. anyone know how to configure that? (Altera Cyclone IV E6E22C8N)
<_whitenotifier-f> [nmigen-boards] GuzTech commented on pull request #104: Add OLED connector to ulx3s.py - https://git.io/JkH5m
<_whitenotifier-f> [nmigen-boards] GuzTech opened pull request #133: Add OLED connector SPIResource for ULX3S - https://git.io/JkH56
<_whitenotifier-f> [nmigen-boards] GuzTech commented on pull request #133: Add OLED connector SPIResource for ULX3S - https://git.io/JkH5X
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
DaKnig has joined #nmigen
feldim2425 has quit [Ping timeout: 260 seconds]
feldim2425 has joined #nmigen
DaKnig has quit [Ping timeout: 264 seconds]
DaKnig has joined #nmigen
DaKnig has joined #nmigen
DaKnig has quit [Ping timeout: 240 seconds]
<mogery> i think p_extclk1_divide_by / p_extclk1_multiply_by is what i'm looking for
emeb_mac has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
jeanthom has joined #nmigen
<mogery> is there a way to generate a graphical representation of my nMigen project?
<mogery> sort-of like a schematic
<jeanthom> You'll have to export your nmigen design to RTLIL then import it in Yosys to export a dot file
<jeanthom> I know lkcl does this a lot
<jeanthom> mogery, forgot to mention you
<mogery> ooh, ty ty
<asu> also quartus has a similar feature afaik but i don't know whether you can open that view without a project file (since i don't think nmigen generates one?)
<asu> in tools -> netlist viewer
DaKnig has joined #nmigen
DaKnig has joined #nmigen
mogery has quit [Read error: Connection reset by peer]
jeanthom has quit [Ping timeout: 260 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
DaKnig has quit [Ping timeout: 264 seconds]
<lsneff> What's the latest on cheap asic fabrication? I'm not planning to do anything with that, just curious/
emeb has quit [Quit: Leaving.]
GenTooMan has quit [Quit: Leaving]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]