<cr1901_modern>
mithro: self.clock_domains.cd_my_cd = ClockDomain(), then route ClockSignal("sys") to self.cd_my_cd.clk, and your reset logic to self.cd_my_cd.rst
<mithro>
cr1901_modern: If I just want to reset a single module rather than everything in a clock domain?
<cr1901_modern>
mithro: Yes. A clock domain is both a clock _and_ a reset signal
<cr1901_modern>
in your case you just want to duplicate the reset signal and leave the other logic alone
<mithro>
cr1901_modern: I want to reset a single module, not the whole clock domain
<key2>
can't with a ResetInserter ?
<cr1901_modern>
Oh yes, that too
<mithro>
How do I get the reset signal from ResetInserter?
<cr1901_modern>
It's a decorator... the signal should be available from self.rst
<cr1901_modern>
I _think_
<cr1901_modern>
CEInsterter is similar, but it adds a self.ce signal
<whitequark>
yes
<whitequark>
ResetInserter()(m) in migen adds a m.rst signal
<whitequark>
or cd_rst where cd is the clock domain name, if you use multiple domains
<key2>
. reset
<key2>
ha whitequark woke up :)
<mithro>
With the simulator, if I do "yield" it advances the clock by one - self.sync += self.o_data.eq(self.i_data) then self.o_data should equal self.i_data after the yield?
<whitequark>
yes
<cr1901_modern>
yield self.i_data.eq(1) will schedule an update for idata
<cr1901_modern>
technically you can do yield self.o_data.eq(1) as well, using your example above, but it'll conflict with your sync statement. Don't remember how the simulator handles it
<whitequark>
that's not how it works at all.
<whitequark>
if self.i_data is driven comb, trying to set it will do nothing in migen sim
<whitequark>
it will be silently ignored
<whitequark>
and setting self.o_data will, indeed, schedule an update for it
<cr1901_modern>
I have no idea if self.i_data is driven comb, all I have the the context of a single statement
<mithro>
self.i_data = Signal()
<cr1901_modern>
That looks like you get do "yield self.i_data.eq(1)" just fine?
<attie>
that was my first attempt, but with make -j that re-ran the rule for every target
<attie>
> But here's what will really bake your noodle: f you reverse the order in which the output files are listed as prerequisites of all, suddenly the files are generated only once, because those algorithms are very sensitive to the order in which dependencies are declared.
<attie>
maybe I just haven't found the right order for the rules yet?
<attie>
oh hm maybe the subfolders are interfering
rohitksingh has quit [Ping timeout: 250 seconds]
<whitequark>
wtf
<attie>
ok, it seems to work now
<attie>
had to twiddle it oddly to find a common stem, but at least didn't have to resort to matching the . from the extension like one stackoverflow answer suggested
<attie>
thanks!
<attie>
was getting quite fed up with discovering, 2h later, that only half of the syntheses was launched.
<cr1901_modern>
oh it's one of those FPGAs I can't afford, like a Virtex?
<attie>
it's a ku060, not quite as big
<attie>
join a university, and people will send you this stuff for free ^_^"
<cr1901_modern>
When I was in uni, cyclone ii was still a respectable fpga
<cr1901_modern>
now cyclone iv isn't even supported in quartus anymore?
<attie>
dunno, I last touched quartus in undergraduate, aside from three weeks last year
rohitksingh has joined #m-labs
<attie>
after checking release dates, we probably did use cyclone II at the time.
AceChen has quit [Remote host closed the connection]
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
lkcl has quit [Ping timeout: 250 seconds]
lkcl has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
_whitelogger has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 272 seconds]
<_whitenotifier-6>
[m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fhUZh
<_whitenotifier-6>
[m-labs/nmigen] whitequark d47c1f8 - back.rtlil: use one $meminit cell, not one per word.
<GitHub198>
[smoltcp] 1uka opened pull request #268: implement BPF sockets to be used as RawSocketDesc on BSD-like OSes (master...bsd-rawsocks) https://github.com/m-labs/smoltcp/pull/268
X-Scale has quit [Read error: Connection reset by peer]
<GitHub188>
[smoltcp] dlrobertson commented on pull request #268 8cfac71: Currently it is possible that this `cfg` is met, but the `cfg` for the `bpf` is not met. E.g. `target_os = "netbsd"`.... https://github.com/m-labs/smoltcp/pull/268#discussion_r243839379
<GitHub189>
[smoltcp] 1uka commented on pull request #268 8cfac71: Yeah on macOS there are a total of 256 BPF devices, but I usually only try the first 100, because sometimes it might be a bad idea to open another one if 100 are already busy. But, I will change this to go up to `/dev/bpf255` if that is what you want. https://github.com/m-labs/smoltcp/pull/268#discussion_r243860581
<GitHub58>
[smoltcp] 1uka commented on pull request #268 8cfac71: You are right. I usually write C and I am not yet used to rust's syntax sugar tricks. I wrapped the `unsafe` block in a function that returns `io::Result`, you can tell me what you think about it. https://github.com/m-labs/smoltcp/pull/268#discussion_r243860582
<kbeckmann>
(noob question) When testing a simple FSM in migen using run_simulation(), the vcd output seems to create some huge state registers that don't match the verilog output at all - getting a 96 bit next_state and 80 bit state register that contain huge values even though I only have 2 states. Does this sound familiar, I'm probably doing something stupid here?
mauz555 has joined #m-labs
<acathla>
kbeckmann, display them as ASCII and you'll have their name =)
<kbeckmann>
oh wow.. thanks :D
<kbeckmann>
that's really useful!
<acathla>
My pleasure, I feel less noob now :)
<kbeckmann>
When writing tests in migen, is there a good way of testing which state you are currently in? Having some trouble accessing the state register.. Asserting on normal signals work fine.
mauz555 has quit []
<kbeckmann>
maybe it doesn't make sense to test the state machine, but rather the outputs it changes..