<_whitenotifier-b>
[nextpnr] github-actions[bot] opened pull request #6: Auto-update - https://git.io/JJVaM
<_whitenotifier-b>
[nextpnr] github-actions[bot] created branch update-deps - https://git.io/JJY7T
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>
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 https://github.com/kbeckmann/pergola_projects/blob/master/pergola/gateware/dvid2vga.py#L205
<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>
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]