ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting August 3rd
jeanthom has quit [Ping timeout: 265 seconds]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] pushed 1 commit to update-deps [+0/-0/±1]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] 2ccb0f2 - Update upstream code
<_whitenotifier-b> [yosys] github-actions[bot] created branch update-deps -
<_whitenotifier-b> [yosys] github-actions[bot] opened pull request #11: Auto-update -
<_whitenotifier-b> [YoWASP/nextpnr] github-actions[bot] pushed 1 commit to update-deps [+0/-0/±2]
<_whitenotifier-b> [YoWASP/nextpnr] github-actions[bot] 4e0e63e - Update upstream code
<_whitenotifier-b> [nextpnr] github-actions[bot] opened pull request #6: Auto-update -
<_whitenotifier-b> [nextpnr] github-actions[bot] created branch update-deps -
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
_whitelogger has joined #nmigen
proteus-guy has joined #nmigen
jaseg has quit [Ping timeout: 244 seconds]
jaseg has joined #nmigen
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
levi has quit [Quit: Connection closed for inactivity]
levi has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
<ianloic> I'm confused by how `Connector`s work. I'm playing with an OrangeCrab r0.2 and it has a Connector defined for the io pins but I can't work out how to assign to them from my top
<ianloic> I can't `platform.request` the pins on them obviously
<d1b2> <emeb> I don't think they do anything.
<d1b2> <emeb> If you want to use I/O pins you just need to make a custom platform definition
<d1b2> <emeb> I saw some discussion from a while ago that seemed to suggest some sort of inheritance was possible, but it was easy to just copy the platform out of the nmigen-boards and extend it.
<ianloic> aha, let me try that thanks emeb
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #nmigen
<ianloic> that seems to "work" in that things build but it doesn't actually work in terms of actually blinking my LED
<d1b2> <emeb> weird
proteus-guy has quit [Ping timeout: 256 seconds]
<ianloic> I found a reasonable example here: but still not great joy.
<d1b2> <TiltMeSenpai> oh wait I've done that thing
<d1b2> <TiltMeSenpai> give me a second
<d1b2> <TiltMeSenpai> platform = OrangeCrabR0_2Platform() platform.add_resources([ Resource("sync_out", 0, Pins("1", conn=("io", 0), dir="o"), Attrs(IO_TYPE="LVCMOS33")) ]), do_program=True)
<d1b2> <TiltMeSenpai> you need to platform.add_resources before you call
<d1b2> <TiltMeSenpai> then you can call platform.request in your code
<ianloic> hrm I like that approach but it's still not blinking my LED
<ianloic> WTAF
<d1b2> <TiltMeSenpai> that's uhh
<d1b2> <TiltMeSenpai> probably not promising
<d1b2> <TiltMeSenpai> does the LED blink when your bootloader is running?
<d1b2> <TiltMeSenpai> wait that might not make sense, ignore me
<ianloic> So I'm trying to wire up an external LED. The internal LED is fine
<ianloic> mostly to start wiring up other things
<d1b2> <TiltMeSenpai> do you have a resistor in series with the LED
<ianloic> and the orangecrab verilog examples work fine
<d1b2> <TiltMeSenpai> and does the LED light when you apply 3.3v directly to it
<d1b2> <TiltMeSenpai> aka, is the led not lighting up bc it ded
<ianloic> Yeah I've repeatedly connected it between 3.3v & gnd and back to the pin
<d1b2> <TiltMeSenpai> step 2 would be checking if the voltage at the pin behaves as expected
<ianloic> it works as expected when I use verilog
<ianloic> but what am I, a farmer?
<d1b2> <TiltMeSenpai> oh, ok, so there's definitely something up with nmigen
<ianloic> or my relationship with nmigen
<d1b2> <TiltMeSenpai> uhh is something up with the logic driving the LED?
<d1b2> <emeb> maybe post your code somewhere?
<d1b2> <TiltMeSenpai> "is there something up with the logic driving the LED" that's not a broad target at all lmao
<d1b2> <TiltMeSenpai> yeah posting your code somewhere would help if possible
<ianloic> I'm really just messing about with the orangecrab examples right now
<d1b2> <TiltMeSenpai> so when you build with nmigen, it creates a build folder, if you look in there, there should be a "top.lpf" file
<d1b2> <TiltMeSenpai> do the contents look similar to your .pcf file (names are likely different, do they mention the same sites with the same attributes)
<ianloic> oh interesting:
<ianloic> LOCATE COMP "extra_led_0__io" SITE "N17";
<ianloic> IOBUF PORT "extra_led_0__io" IO_TYPE=LVCMOS33;
<ianloic> aha! it blinks!
<ianloic> it's alive when I put it in the right place!
<d1b2> <emeb> what did you change?
<ianloic> But thank you for helping me work out how to track down what it's actually changing
<ianloic> So I was trying to use L4 but then when I switched to TiltMeSenpai's connector based example it was mapping elsewhere
<d1b2> <TiltMeSenpai> ah, it looks like L4 is IO_A0
<d1b2> <TiltMeSenpai> I think that might be digital output to the A0 pin?
<ianloic> yeah
<ianloic> My laptop's running out of juice and so am I. Thanks for the help!
<d1b2> <TiltMeSenpai> if you replace the "0" on 37 with "a0" it should be equivalent to your verilog
<d1b2> <TiltMeSenpai> np, glad you got it working!
<d1b2> <emeb> thanks for this discussion - I tried some of this stuff and I think I understand it better now.
jeanthom has joined #nmigen
<DaKnig> verilator claims that `8'h??:` overlaps with `8'h0`, and both are generated in the same case statement
<Lofty> DaKnig: are you trying to run Verilator on the output Verilog?
<DaKnig> yes
<Lofty> I wouldn't bother, really :P
<DaKnig> I found a verilator testbench that could help me debug my thing
<DaKnig> I mean , in this case making a testbench myself would be harder and slower
<Lofty> I mean, there's also cxxsim
<DaKnig> all I am trying to do is to debug my non working VGA/HDMI converter
<Lofty> But in general I trust the Yosys output Verilog, even if it is highly weird
<DaKnig> that verilator tb shows the hdmi image on the screen
<DaKnig> or at least it should
<DaKnig> but build fails because of the warnings
<DaKnig> to make a tb I'd have to make an hdmi decoder which should be as complex if not more than the HDMI encoder
<DaKnig> and how would I test that, when my encoder doesnt work
<daveshah> If it's just a warning, presumably you can stop it breaking the build somehow
<daveshah> removing -Werror or whatever
<DaKnig> there is no -Werror
<DaKnig> that's the first thing I checked :)
jeanthom has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
<kbeckmann> DaKnig: i did that with cxxsim in nmigen, generate a dvid/hdmi signal from vga and decode and render it on the screen with SDL. it was quite helpful for debugging. it is probably not correct, but it works and can decode my encoded signal :). if you are interested i have the code here
<kbeckmann> it takes a few seconds per frame so it isn't that fast. but should be enough to verify the encoding.
<DaKnig> kbechmann cool! does it have a VGA signal generator?
<DaKnig> wait you said "dvid", I have proper HDMI with a NULL packet (otherwise my monitor wont accept it), would it break your thing?
<DaKnig> how would I start with using that testbench?
<kbeckmann> ah, it is mainly supporting dvid so it does not handle data islands at all. it will get very confused :). was going to implement that but haven't had the energy to do so.
<DaKnig> would it at least ignore data islands?
<DaKnig> the one I m sending does literally nothing.
<kbeckmann> the problem is that the island itself should be encoded in that other format that i forgot the name of, i.e. not 8b10b or 2b10b
<kbeckmann> and i don't handle that at all
<kbeckmann> but now you are giving me motivation to improve on that :p. i had a nasty hack before that ignored the data islands but removed it because it was just too ugly.
<DaKnig> "if data preamble at the middle of blank time: ignore it"
<kbeckmann> yeah that was basically it
<DaKnig> if it would mess up your thing I guess I'll stick to teh verilator testbench I found
proteus-guy has joined #nmigen
<kbeckmann> sure. i might end up improving it and making it easier to reuse in the future.
<DaKnig> just to confirm I understand it correctly: this `m.d.sync += [reg.eq(reg[1:]), reg[-1].eq(X)] ` is equivalent to `m.d.sync += [Cat(reg[:-1]).eq(reg[1:]) , reg[-1].eq(X)]` right?
<DaKnig> with reg of type Signal(whatever)
<lkcl> DaKnig: gimme a sec to cut/paste that so it doesn't line-wrap :)
chipmuenk has joined #nmigen
<lkcl> ok i identified the two bits that are actually different, there.
<lkcl> and it's Cat(something).eq(...) <===> something.eq(...)
<lkcl> or just
<lkcl> is "Cat(something)" equivalent to "something" and the answer to that is - should be - yes.
<lkcl> except they're not quite the same... 1 sec
<lkcl> taking away that Cat() because a Cat() with one argument *is* the argument
<lkcl> you are asking:
<lkcl> is "reg[:-1]" equal to "reg" and the answer's no
<lkcl> >>> l = [1,2,3]
<lkcl> >>> l
<lkcl> [1, 2, 3]
<lkcl> >>> l[:-1]
<lkcl> [1, 2]
<lkcl> if you had in the first one:
<lkcl> reg[:-1]).eq(reg[1:])
<lkcl> then yes they would be equivalent
<lkcl> this is really neat and compact (VHDL):
<lkcl> stat_reg <= (2 => terminated,
<lkcl> others => '0')
<lkcl> 0 => stopping,
<lkcl> 1 => self.core_stopped_i,
* lkcl wonders if the same level of compactness can be achieved in nmigen
<lkcl> it expands to a (rather large, cumbersome) with m.Switch()... / case statement
<lkcl> which more than doubles the number of lines used
<lkcl> m.Dict()?
<lkcl> m.Table()?
<lkcl> m.Dict() would be nice as it naturally would feel right to take the same arguments as python dict
* lkcl face-palm - that VHDL fragment compacts to Cat(stopping, core_stopped_i, terminated) doh
<lkcl> still, the idea of m.Dict() is kinda nice.
* lkcl wonders if there's anything equivalent in nmigen already
emeb has joined #nmigen
<DaKnig> yeah coming from vhdl and not having this is sad :(
<DaKnig> the nice thing is that there you could explicitly type which indexes get what value
<DaKnig> lkcl: the question was about if writing to that last member twice is the same as ignoring it the first time and then assigning it once
<agg> DaKnig: I use reg.eq(Cat(reg[1:], X))
<agg> Writing twice is fine, second write will be the one that happens, but for this common use case putting the cat on the right seems clearest and is shortest
<lkcl> DaKnig: yes, if you more than one assignment to the same "thing" in any given program, the very last one takes precedence
<lkcl> unfortunately the example you gave had "bugs" in it which made it unclear what you were asking :)
<agg> What bugs were in their example?
<lkcl> removing the Cat (because as a 1-arg it's redundant), the example becomes:
<lkcl> ... *click*, yes.
<lkcl> got it - waa that's really unclear!
<lkcl> the first line is one that has an "overwrite", the second one doesn't.
<lkcl> DaKnig: i'd definitely do it as "m.d.sync += reg.eq(Cat(reg[1:], X))"
<lkcl> that's a single line that is quite clear that it's a shift register pattern
* lkcl wonders if there's a clearer/better way to do that
<DaKnig> lkcl: I just took it from my code, where the Cat does make a difference. sorry
<DaKnig> i do it in separate lines because the actual expressions are huge
<lkcl> a *one* argument Cat() makes a difference? that's very strange, i wonder why?
<DaKnig> its not a Signal :)
<lkcl> DaKnig: ah :)
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
chipmuenk has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
samlittlewood_ has joined #nmigen
samlittlewood has quit [Ping timeout: 256 seconds]
samlittlewood_ is now known as samlittlewood
Asu has quit [Ping timeout: 240 seconds]
<_whitenotifier-b> [nextpnr] whitequark closed pull request #6: Auto-update -
<_whitenotifier-b> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±2]
<_whitenotifier-b> [YoWASP/nextpnr] github-actions[bot] a390d11 - Update upstream code
<_whitenotifier-b> [nextpnr] whitequark deleted branch update-deps -
<_whitenotifier-b> [YoWASP/nextpnr] whitequark deleted branch update-deps
<_whitenotifier-b> [yosys] whitequark deleted branch update-deps -
<_whitenotifier-b> [yosys] whitequark closed pull request #11: Auto-update -
<_whitenotifier-b> [YoWASP/yosys] whitequark deleted branch update-deps
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] 7fc68da - Update upstream code
_whitelogger has joined #nmigen