<d1b2>
<ld;cd> You can override it similar to how the versa-5g overrides the part number
<d1b2>
<edbordin> hmm maybe that irc logger just truncates long lines to keep it tidy then
<d1b2>
<ld;cd> Probably
<d1b2>
<ld;cd> I don't own a desktop and have a horribly unstable connection about half the time, so I tent to stray away from irc
<d1b2>
<ld;cd> When I have to use it I open it up in a tmux session on a remote box
<d1b2>
<edbordin> yeah I also haven't got a good persistent client set up for it so tend to not bother
<awygle>
ah ok, have to set it in the platform then
hitomi2503 has joined #nmigen
jeanthom has joined #nmigen
jock-tanner has joined #nmigen
chipmuenk has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
Asu has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
<_whitenotifier-f>
[nmigen-soc] jfng opened pull request #19: periph: add a PeripheralInfo class for metadata. - https://git.io/JJvQM
<_whitenotifier-f>
[nmigen-soc] codecov[bot] commented on pull request #19: periph: add a PeripheralInfo class for metadata. - https://git.io/JJvQy
jock-tanner has quit [Remote host closed the connection]
proteus-guy has quit [Ping timeout: 246 seconds]
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
<_whitenotifier-f>
[nmigen-soc] Fatsie commented on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJvpe
<d1b2>
<286Tech> I'm porting the uart example of the icebreaker-migen-examples repository, and I need to be able to toggle the reset of my DUT in a process. But how do I do that?
<d1b2>
<286Tech> In the migen example, this is done like this: yield dut.cd_sys.rst.eq(1)
<d1b2>
<286Tech> But in nmigen I cannot seem to find any domain specific signals in the dut. I thought that maybe I could do yield dut.d.sync.rst.eq(1).
<Degi>
286Tech: You can get the reset with ResetSignal("domain_name")
<d1b2>
<286Tech> Cool!
<d1b2>
<286Tech> I assume something similar exists for the clock signal (ClockSignal("domain_name"))?
<Degi>
Yes
<d1b2>
<286Tech> Nice
<d1b2>
<286Tech> Thanks!
<d1b2>
<286Tech> Can I only access it inside the module (or a class that derives from Elaboratable)?
<Degi>
I think it needs to derive from elaboratable...
<d1b2>
<286Tech> Because then I would have to extract it and pass it to the simulation process, instead of accessing the reset signal inside the simulation process.
<Degi>
I'm not sure actually, try it out...
<vup>
you do not need to derive from Elaboratable for anything other than to get UnusedElaboratable warnings
<whitequark>
edbordin: irc has a line length limit
<whitequark>
the irc logger does not truncate anything, the irc server does
<whitequark>
so any code you paste inline will be gone on irc side and unreadable in any case. use paste.debian.net or something
<d1b2>
<286Tech> I just create a new ClockDomain in main called "sync" and pass it to the simulation process, and then toggle its rst signal, but it doesn't happen.
<_whitenotifier-f>
[nmigen-soc] jfng opened issue #20: Handling resource name collisions inside a MemoryMap - https://git.io/JJvh1
<d1b2>
<286Tech> I don't see any relationship between my newly created ClockDomain, and the DUT except that both synchronous clock domains are called "sync".
<d1b2>
<286Tech> So something feels off to me.
<d1b2>
<286Tech> I don't see an easy way of asking for the "sync" clock domain of my DUT, so that I can access their clock and reset signals.
<d1b2>
<286Tech> I tried @Degi 's suggestion of using ResetSignal() inside my DUT (self.rst = ResetSignal() inside the init function), but then I get an error that the ResetSignal object has no attribute 'reset'.
Asu has left #nmigen ["Konversation terminated!"]
<whitequark>
286Tech: a ResetSignal() works similarly to, well, a signal
<whitequark>
wait
<whitequark>
what do you want to use the reset attribute of a ResetSignal for?
<d1b2>
<286Tech> I don't?
<d1b2>
<286Tech> I just want to toggle the reset in a simulation process.
<vup>
pysim wants to use it if you try to do a yield ResetSignal().eq(0|1)
<whitequark>
oh
<d1b2>
<286Tech> Aha
<whitequark>
ok that seems like a bug
<whitequark>
can you file an issue?
<d1b2>
<286Tech> I could, but am I using it correctly though?
<d1b2>
<286Tech> Boiled down to the basics: 1. class bla(Elaboratable): def __init__(self): self.rst = ResetSignal() 2. in simulation function: yield dut.rst.eq(1)
<d1b2>
<286Tech> Is that correct?
<d1b2>
<286Tech> Then I can create a simple and small example for the issue.
<vup>
you don't even need to do `self.rst = ResetSignal()` for the bug to occur, you can just write `yield ResetSignal().eq(...)` and get the same bug
<d1b2>
<286Tech> Oh you can do that?
<d1b2>
<286Tech> Probably because the default name is "sync", so it will get the rst signal of the "sync" domain.
<vup>
Well I don't know if you are supposed to be able to do that, but nothing prevents you from doing it currently
<whitequark>
286Tech: yes, that should in fact work
<d1b2>
<286Tech> In the simple example I get a slightly different error about having no 'name' attribute, whereas in the gist above it complains about the 'reset' attribute.
jordigw has joined #nmigen
jordi_ has quit [Remote host closed the connection]
<vup>
if you run without the `with sim.write_vcd(...):` you get the 'reset' attribute one
<d1b2>
<286Tech> Changing the traces from dut.rst to dut.a also gives the 'reset' attribute one.
jfng has quit [Quit: killed]
nurelin has quit [Quit: killed]
emily has quit [Quit: killed]
nurelin has joined #nmigen
proteus-guy has joined #nmigen
jfng has joined #nmigen
emily has joined #nmigen
hell__ has quit [Ping timeout: 260 seconds]
Th3Fanbus has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
Th3Fanbus is now known as hell__
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 240 seconds]
chipmuenk1 is now known as chipmuenk
hellsenberg has joined #nmigen
hell__ has quit [Quit: CPU has triple-faulted.]
hellsenberg is now known as hell__
jeanthom has joined #nmigen
hell__ has quit [Ping timeout: 240 seconds]
<_whitenotifier-f>
[nmigen-soc] whitequark commented on issue #20: Handling resource name collisions inside a MemoryMap - https://git.io/JJfY9
<_whitenotifier-f>
[nmigen-soc] whitequark commented on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJfY7
<_whitenotifier-f>
[nmigen-soc] whitequark edited a comment on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJfY7
jeanthom has quit [Ping timeout: 264 seconds]
<_whitenotifier-f>
[nmigen-soc] whitequark commented on pull request #19: periph: add a PeripheralInfo class for metadata. - https://git.io/JJfOk
<awygle>
whitequark: i notice we have a discord bridge now, can we put it in the topic?
hitomi2503 has quit [Quit: Nettalk6 - www.ntalk.de]
<_whitenotifier-f>
[GitHub] Half measures are as bad as nothing at all.
<_whitenotifier-f>
[nmigen-soc] Fatsie commented on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJfsz
<_whitenotifier-f>
[nmigen-soc] Fatsie edited a comment on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJfsz
<_whitenotifier-f>
[nmigen-soc] whitequark commented on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJfsK
<_whitenotifier-f>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+2/-2/±4] https://git.io/JJfGi
<_whitenotifier-f>
[YoWASP/nextpnr] whitequark efab2f8 - Export public functions to invoke the tools without a subprocess.
hellsenberg has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 240 seconds]
<awygle>
whitequark: where should i look to figure out why my clock constraint is being set to 12 MHz even though the default_clk_freq is 62 MHz?
<daveshah>
I will have a nextpnr fix in 10 mins anyway
<Stary>
i think freq should be in hz not mhz - i have platform.add_clock_constraint(clk_out, self.freq_out * 1e6) for my pll output
<whitequark>
yes 70e6, sorry
<cr1901_modern>
whitequark: Yea, we talked about how to handle clocks like OSC*H* last year for tinyfpga_ax, but for... reasons I imagine you understand, that fell by the wayside. At this point, I don't remember much of the details.
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined #nmigen
<daveshah>
awygle: nextpnr fix pushed
<d1b2>
<286Tech> @esden I've ported the migen uart example to nmigen and tested it successfully on the icebreaker. I created a pull request for it 🙂
<d1b2>
<ld;cd> Wow, not gonna lie, I had no idea the ecp5 had an internal oscillator
<daveshah>
Pretty much all FPGAs have one
<daveshah>
They are needed for configuration, so might as well be made user accessible too
<cr1901_modern>
is ice40's user accessible?
<cr1901_modern>
(hx parts)
<daveshah>
No, not publicly
<daveshah>
idk if there is some kind of test access, but I doubt it
<daveshah>
It's one of the few exceptions, possibly along with some of the Intel parts
<cr1901_modern>
well ice40 doesn't have a jtag port either
<cr1901_modern>
or dist ram
<cr1901_modern>
so... :P
<d1b2>
<ld;cd> Ah, I guess that makes sense
<daveshah>
Worth being aware that in some cases, particularly Xilinx, the tolerance is so high (something like 50%) that it rarely that useful other than for startup
<daveshah>
or other minimal always on stuff
<daveshah>
I think it is 15% for ECP5
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<d1b2>
<esden> @286Tech I will take a look. Thank you. I need to test your other tristate example. I was slightly confused by the implementation, so I need to try it out before I merge it. 🙂
<cr1901_modern>
esden: Yea, I should've delegated to you before merging, sorry
<d1b2>
<286Tech> Both examples are just straight ports of the migen example repository, so it shouldn't be any more complicated 😛
<awygle>
dang, i wish every time i took a nap all my problems were solved when i woke up
<awygle>
thanks daveshah
<awygle>
whitequark: can i program without building?
<awygle>
i tried do_build=False and do_program=True but that didn't work
<whitequark>
awygle: you can call platform.toolchain_program directly
<whitequark>
there's no do_build=False, do_program=True flow because inevitably it will result in someone accidentally using it and losing a few hours to "why is my design outdated"
<awygle>
sure
<whitequark>
at least when you call toolchain_program directly it is obvious what happens
<awygle>
thanks
<agg>
whitequark: a while ago I made this InstanceWrapper class to make using platform primitives easier, basically it knows what ports it can have, and makes them accessible as object attributes, but if you don't use a port it doesn't instantiate it (for example to prevent WCLKE appearing in a BRAM), and can have required pins (error if not used) and default pins (always provided with default value); I wonder if
<agg>
it might be useful to have in nmigen itself?
<agg>
basically it allows me to fully define something like SB_MAC16 or SB_PLL40_PAD_2F once with all available parameters and ports, and then in my actual/user code only use the ports and attributes I want
<whitequark>
agg: yes, and in fact we'll *need* to have something like that for #6
<agg>
makes sense
<anuejn>
agg: i would suggest to have an implementation that allows for some type inference by the tooling
<anuejn>
e.g. by making less excessive use of __getattr__ at the cost of having less nice looking code in the subclasses
<agg>
as in, developer tooling wouldn't be able to work out what attributes are available because they're done via getattr?
<agg>
they're always going to be dynamically generated; what sort of thing might tooling support?
<whitequark>
it would probably use the same annotations as #243
<awygle>
daveshah: that fix did work, thank you :)
<daveshah>
Great, thanks for testing!
<anuejn>
agg: something along the lines of self.lock = self.port("LOCK", 1) would work better for IDEs
<agg>
shame that it's very different to all the normal elaboratables i make that have instance attributes as signals though
<agg>
maybe you could support both...
jeanthom has joined #nmigen
<awygle>
cr1901_modern: do you have a good windows x-forwarding suggestion?