ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #nmigen
FFY00 has quit [Ping timeout: 256 seconds]
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
proteus-guy has quit [Ping timeout: 256 seconds]
<whitequark> TD-Linux: should be usable
<whitequark> please file any issues as bugs
mwk has joined #nmigen
jeanthom has joined #nmigen
FFY00 has joined #nmigen
hitomi2500 has joined #nmigen
Asu has joined #nmigen
<MadHacke1> whitequark: Is there a sane way to do a switch on multiple signals at once? e.g. Cat(cycle, phase, addressing_mode)? I tried with a Cat() and a simple tuple but got errors on either the Switch or the Case for each situation.
MadHacke1 is now known as MadHacker
<MadHacker> with m.Switch(Cat(self.cycle, self.phase, self.instr_addr_mode))
<MadHacker> Oops, but yeah, that.
<whitequark> basically no
<whitequark> it might be conceivable to turn m.Switch into a pattern matching construct
<whitequark> but that would be in the medium term future
<MadHacker> Thanks; I'll come up with some situation-specific syntactic sugar for myself for now.
<MadHacker> I guess the only real problem doing it by just collapsing them all into one integer/bitmask/string is that you don't necessarily know all the widths?
<whitequark> what I want to do is to be able to compositionally add syntax to Module
<whitequark> so you could build it yourself if you wanted
<whitequark> unfortunately that's kinda really hard
<whitequark> yes.
<whitequark> in boneless I did a hack like that but it's ugly
<MadHacker> How smart is whatever comes after? i.e. if I just expand out each Case with a Cat parameter into a little set of nested switches (which basically means lots of switches with the same input will get generated), will badness ensue?
<MadHacker> with m.Switch(Cat(A,B)): with m.Case(Cat(1,0)): blah -> with m.Switch(A): with m.Case(1): with m.Switch(B): with m.Case(0): blah
<MadHacker> Obviously can't have a condition that splits across the boundary between elements with that arrangement but that doesn't matter for my scenario.
cr1901_modern has quit [Read error: Connection reset by peer]
<whitequark> that is an excellent question
<whitequark> you should try it and see
<MadHacker> Will do.
<whitequark> I would expect the main problem come from the column order selection in processes
<whitequark> but that's speculation
cr1901_modern has joined #nmigen
* zignig has managed to get a Boneless-V3 working in cxxrtl, now for an interface.
<MadHacker> Yak-shaving here; the short answer to my question about switch/case above is that the resulting verilog matches the python pretty much like-for-like, but what consequence that has in the generated output I don't know, because I'm in the middle of rebuilding yosys because SGSR isn't in 0.9 and I'm building for ECP5 and...
<MadHacker> <creates more bald yaks>
<whitequark> the ECP5+Yosys flow doesn't go through Verilog
<whitequark> but yes
<whitequark> the semantics is the same
<MadHacker> Well, I generated verilog to look at, and then didn't have a good feel for how that would affect actual FPGA output, so I was building for ECP5.
<whitequark> yeah, you're doing it right
zignig has left #nmigen [#nmigen]
<Sarayan> microusb is probably the best
<miek> i always wondered how that HDMI to garden hose adapter worked
<Sarayan> ask foone, I guess
<whitequark> it didn't
<whitequark> it's fake
<whitequark> a very well done fake
<miek> but the pinout has a water pin
<Sarayan> with foone's sex toy adapter thread, I'm getting convinced you can find adapters from anything to everything
<Sarayan> wq: that's the site where one can buy anything?
<whitequark> one of
<MadHacker> On the list of adapters I haven't come across but could probably make some use of: A PCIe to ISA bus (or other generic 8-bit bus) bridge.
<Sarayan> that's glasgow version E ;-)
<MadHacker> Ideally, in the opposite direction to the one you'd expect. I want a PCIe card on my 8-bit micro.
<MadHacker> The hardware I can build myself just fine, but I think a PCIe root complex may be a bit beyond me. :)
<whitequark> i was working on that
<whitequark> yumewatari
<whitequark> but i found that the foundations are a little bit too flakey for my taste
<MadHacker> Was tempted to go via PCI instead and use a PCI to PCIe bus bridge chip.
<whitequark> do a PCI-ISA bridge first
<MadHacker> Not sure that modern FPGAs still have PCI-compliant I/O tho.
<whitequark> tbh a PCIe root complex isn't that bad
<MadHacker> It's got that whole weird reflection mode thing for PCI signalling.
<MadHacker> that's the term, couldn't remember for a mo.
<_whitenotifier-f> [nmigen-soc] whitequark closed pull request #12: Add event management primitives -
<_whitenotifier-f> [nmigen/nmigen-soc] whitequark pushed 1 commit to master [+2/-0/±0]
<_whitenotifier-f> [nmigen/nmigen-soc] jfng 4a6a948 - event: add event management primitives.
<MadHacker> and the conclusion of my exciting Switch experiments is: yosys fixes everything afterwards so it's fine to do messy things.
<whitequark> yes that sounds about right
<MadHacker> It's honestly what I expected but I wanted to test rather than assume.
<_whitenotifier-f> [nmigen-boards] whitequark commented on pull request #64: resources: distinguish "dte"/"dce" roles of UARTResource -
shizoor has joined #nmigen
<shizoor> Hi, is there a place to check known bugs before I ask and look silly?
<shizoor> I've made a circuit for driving a VGA monitor and displaying raster bars, and if I use if statements to create the clock, it works, but if I use modulo it behaves oddly.
<tpw_rules> modulo?
<shizoor> m.d.comb += self.h_timer.eq(self.v_timer%386)
<tpw_rules> and what does "oddly" mean?
<shizoor> Ah.
<shizoor> I'll upload pics.
<whitequark> are you perhaps doing something like
<tpw_rules> that equation is probably synthesizing something close or equal to a divider, which is crazy big and slow
<whitequark> m.d.comb += self.hsync < self.h_timer ?
<tpw_rules> are you sure you're meeting timing?
<shizoor> with m.If(self.v_timer == 0 ):m.d.sync += self.h_timer.eq(0)
<shizoor> with m.Else():m.d.sync += (self.h_timer.eq(0))
<shizoor> #m.d.comb += self.h_timer.eq(self.v_timer%386) # This doesn't work
<shizoor> with m.Elif(self.h_timer < 386):m.d.sync += self.h_timer.eq(self.h_timer+1) #this does ask why.
<whitequark> er
<whitequark> ok, tpw_rules is probably right here
<whitequark> do you meet timing?
<shizoor> Do you mean does it meet VGA spec?
<whitequark> can you upload your entire project somewhere? it'd be easier that way
<shizoor> It doesn't meet spec but the second method gets me a picture. First one gets me what looks like a picture with some H sync pulses missing.
<tpw_rules> your synthesis tool should give a warning if it doesn't think your logic can run at the clock rate you're giving it
<whitequark> how are you generating h pulses exactly?
<shizoor> Sure, I'll put it on livejournal (sorry, behind China's digital iron curtain)
<whitequark> tpw_rules: it should be a hard error in nextpnr these days
<MadHacker> shizoor: Using % means you're generating a divider in the resulting logic. A divider is a big slow thing, to the point where it may not even run at the VGA pixel clock. You probably just want to subtract off 386 each time it's above that or something.
<MadHacker> Doing it with % works in software but is usually a bad idea in hardware.
<tpw_rules> yeah it is in nextpnr, but it's definitely not in quartus or ISE
<shizoor> @MadHacker That makes sense. Like it's still busy dividing when the monitor is expecting a pulse?
<MadHacker> Yep.
<tpw_rules> in quartus it's a "critical warning" which i find to be an interesting concept
<whitequark> in vivado too iirc
<shizoor> I'll upload so people can take a look at my mess anyway. :)
<shizoor> Apologies for the delay and the atrocious state of this page :
<shizoor> It's weird because it "sorts itself out" half way through the vertical scan. Other frequencies produce other odd effects like it stopping and starting. I could see how a delay might be intermittant.
<shizoor> @whitequark The sync pulses are made using "with m.If" statements referring to the h_timer or v_timer to see how far through the scan it is, same with porches. I couldn't get gtkwave to look at an entire scan. I think I know what to avoid now. This has helped a lot.
<whitequark> looking
<whitequark> okay, yes, it is what I expected
<whitequark> try replacing: m.d.comb += vgapins.h_sync.eq(0)
<whitequark> with this: m.d.sync += vgapins.h_sync.eq(0)
<whitequark> for all 4 of hsync/vsync lines
<whitequark> and see if that makes things better
<whitequark> tpw_rules: they're using nextpnr-ice40 as far as i see, so it actually shouldn't be a timing issue
<shizoor> shizoor@shizoor-VirtualBox:~/python/nmigen/actual_runnable_code/vga$ python3.8
<shizoor> ERROR: Max frequency for clock 'cd_sync_clk1_0__i': 6.20 MHz (FAIL at 12.00 MHz)
<shizoor> 0 warnings, 1 error
<shizoor> Traceback (most recent call last):
<shizoor> File "", line 244, in <module>
<shizoor> Board().build(vgasignal(), do_program=False)
<shizoor> File "/home/shizoor/.local/lib/python3.8/site-packages/nmigen/build/", line 82, in build
<shizoor> products = plan.execute_local(build_dir)
<shizoor> File "/home/shizoor/.local/lib/python3.8/site-packages/nmigen/build/", line 98, in execute_local
<shizoor> subprocess.check_call(["sh", "{}.sh".format(self.script)])
<shizoor> File "/usr/lib/python3.8/", line 364, in check_call
<shizoor> raise CalledProcessError(retcode, cmd)
<shizoor> subprocess.CalledProcessError: Command '['sh', '']' returned non-zero exit status 1.
<whitequark> ohhhh I see what happened
<shizoor> I get that when I have two things in "sync" that disagree with eachother, I think.
<whitequark> shizoor: ok so here's the missing piece of the puzzle
<whitequark> normally, nextpnr makes sure that your code runs fast enough to work at the required clock
<whitequark> but if you do something like `h_sync = h_timer % 384 > 341`, then nextpnr doesn't know what there are timing restrictions on h_sync!
<shizoor> ok.
<whitequark> here is a general advice: don't use combinatorial signals to drive FPGA pins
<shizoor> Ok.
<whitequark> or rather, don't assign combinatorial expressions to FPGA pins
<whitequark> the reason is that there is no guarantee that the combinatorial functions in an FPGA are glitchless
<whitequark> i.e. there can be some time until even something simple like a&b settles on a value after a or b change
<shizoor> Ah I see. Yes, I've been seeing some interesting psychadelia this end.
<whitequark> if you explicitly register the signal via m.d.sync then this won't happen
<whitequark> for your circuit it probably doesn't matter, but for more complex ones, it is worth looking into IO buffer registers
<whitequark> to make sure the phase of the output does not change related to FPGA clock from one PNR run to another
<shizoor> Thanks. The vgapins object I create is all combinatorial : m.d.comb += self.red0.o.eq(self.x[0])
<shizoor> m.d.comb += self.red1.o.eq(self.x[1])
<shizoor> m.d.comb += self.red2.o.eq(self.x[2])
<shizoor> etc, Change all that to sync? Would it build then?
<Lofty> Yes
<shizoor> Slowly starting to understand this. :)
<shizoor> Thanks!
<Lofty> It's a bit tricky to know what should and should not be combinational
<Lofty> If you register too much logic you might use the LUTs inefficiently
<Lofty> If you don't register enough, you fail timing
<shizoor> Now it's becomeing clearer. I've put everything in sync that drives pins. If I use modulo, ERROR: Max frequency for clock 'cd_sync_clk1_0__i': 6.45 MHz (FAIL at 12.00 MHz), if I use if statements, it builds. It runs and the picture is looking nice. Thanks!
proteus-guy has joined #nmigen
felix__ is now known as felix_
<_whitenotifier-f> [nmigen-boards] igrr commented on pull request #64: resources: distinguish "dte"/"dce" roles of UARTResource -
<mithro> whitequark: Have you seen the cool terminal based signal renderings in ?
<_whitenotifier-f> [nmigen-boards] igrr commented on pull request #64: resources: distinguish "dte"/"dce" roles of UARTResource -
<_whitenotifier-f> [nmigen-boards] igrr closed pull request #64: resources: distinguish "dte"/"dce" roles of UARTResource -
<whitequark> oooh neat
<_whitenotifier-f> [nmigen-boards] igrr synchronize pull request #65: boards: fix UART flow control pin inconsistencies -
<_whitenotifier-f> [nmigen-boards] igrr synchronize pull request #65: boards: fix UART flow control pin inconsistencies -
<_whitenotifier-f> [nmigen-boards] igrr edited pull request #65: boards: fix UART flow control pin inconsistencies -
<_whitenotifier-f> [nmigen-boards] igrr edited pull request #65: Add role to UARTResouce and fix UART flow control pin inconsistencies -
shizoor has quit [Quit: Going offline, see ya! (]
jeanthom has quit [Ping timeout: 272 seconds]
<mithro> whitequark: I wonder if you can steal them for nmigen? :-P
jeanthom has joined #nmigen
<whitequark> maybe? it's hard to scale renderings like that, they work better for docs and demos i think
hitomi2500 has quit [Quit: Nettalk6 -]
<_whitenotifier-f> [nmigen-boards] whitequark commented on pull request #65: Add role to UARTResouce and fix UART flow control pin inconsistencies -
jeanthom has quit [Ping timeout: 256 seconds]
<_whitenotifier-f> [nmigen] andresdemski opened issue #402: Consider slice as signal in Record initialization -
<_whitenotifier-f> [nmigen] andresdemski edited issue #402: Consider slice as signal in Record initialization -
<_whitenotifier-f> [nmigen] whitequark commented on issue #402: Consider slice as signal in Record initialization -
<_whitenotifier-f> [nmigen] andresdemski commented on issue #402: Consider slice as signal in Record initialization -
<_whitenotifier-f> [nmigen] whitequark commented on issue #402: Consider slice as signal in Record initialization -
jeanthom has joined #nmigen
<_whitenotifier-f> [nmigen] andresdemski commented on issue #402: Consider slice as signal in Record initialization -
<_whitenotifier-f> [nmigen] whitequark commented on issue #402: Consider slice as signal in Record initialization -
jeanthom has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
sorear has quit [Ping timeout: 246 seconds]
Asuu has joined #nmigen
sorear has joined #nmigen
Asu has quit [Ping timeout: 260 seconds]
Asuu has quit [Quit: Konversation terminated!]
lkcl has quit [Ping timeout: 244 seconds]
lkcl has joined #nmigen