<awygle>
the mention of that framing thread has re-activated the part of my brain that insists there's a way to have no or very low added latency with no or very low worst-case expansion
<awygle>
afaict there isn't, but i keep inventing increasingly convoluted LFSR schemes for some reason
<cr1901_modern>
Do any nmigen boards support programming the bitstream to config RAM via JTAG without going to flash?
<whitequark>
awygle: ha, yeah, same problem here
<awygle>
oh great now i'm convincing myself that if _both_ of us think there should be something then there probably is, thanks wq :p
<whitequark>
heyyy :p
<d1b2>
<Banana Phone> Hey can I ask a really simple question. I'm having trouble figuring it out on my own
<d1b2>
<Banana Phone> Don't laugh at me please
<awygle>
sure :) we're here to help not mock
<d1b2>
<Banana Phone> How do I use connectors from nmigen-boards
<d1b2>
<Banana Phone> I'm trying to adapt the orangepi example to drive LEDs on the io pins
<awygle>
so as i understand it (and i genuinely hope wq chimes in because i don't feel super confident on this), Connector is basically a way to late-bind resources/pins. so you add resources to your platform after constructing it, and specify the pins in terms of the connector. this isn't a _great_ example but it shows the general idea: https://github.com/nmigen/nmigen/blob/5b01499901d45400c58fba184c3ba6702d012858/tests/test_build_res.py#L172
<d1b2>
<Banana Phone> I'm really new to fpgas so I'm kind of at that point where I don't even know what to search to get the information I need or what information I need haha
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #nmigen
<whitequark>
awygle is completely correct in his description of connectors
<awygle>
eeeyyyy how bout that
<whitequark>
as for not knowing where to find the information: please don't be hard on yourself, connectors are pretty poorly documented at the moment
<whitequark>
I'll make sure to improve that
<d1b2>
<Banana Phone> Thanks!
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
<_whitenotifier-f>
[nmigen-boards] cr1901 opened pull request #111: Arty S7 OpenOCD Support - https://git.io/JUlb0
<TD-Linux>
I have a core that depends on reset to start up but need to define my own clock domain so it's not reset-less and ResetSignal() is accessible
<TD-Linux>
the actual solution here is probably just to fix the core to not need it
<whitequark>
hang on
<whitequark>
what's the actual problem? can you solve it with ResetInserter?
<TD-Linux>
it's the opposite. I need to power-on reset a verilog module and need to read the reset
<TD-Linux>
nmigen.hdl.cd.DomainError: Signal (rst sync) refers to reset of reset-less domain 'sync'
<whitequark>
hm
<whitequark>
ah I see
jeanthom has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
jeanthom has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk1 has joined #nmigen
chipmuenk1 is now known as chipmuenk
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 244 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 244 seconds]
Lord_Nightmare has quit [Ping timeout: 246 seconds]
emeb has joined #nmigen
Lord_Nightmare has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
Lord_Nightmare has quit [Ping timeout: 258 seconds]
<_whitenotifier-f>
[nmigen-boards] cr1901 commented on pull request #111: Arty S7 OpenOCD Support - https://git.io/JU884
<tpw_rules>
if i'm dumping verilog, why are some things that are only assigned from always @* blocks of type reg?
<tpw_rules>
sometimes they are both output and reg. it seems i need to force a specific one to be a reg so that quartus will infer BRAM
<tpw_rules>
well, maybe that second bit is not true
<tpw_rules>
but i'm having trouble getting quartus to infer BRAM for no explainable reason
jeanthom has joined #nmigen
<cr1901_modern>
I thought nmigen generated vendor primitives for BRAM (b/c the vendor tools have disjoint subsets of Verilog where they will infer a BRAM)
<awygle>
i've written this word_select wrong three times
<awygle>
why does my brain rebel at simple math
<tpw_rules>
cr1901_modern: the unfortunate problem is that the generated verilog needs to work with both ISE and quartus
emeb_mac has joined #nmigen
<cr1901_modern>
Hrm... that's one possible disadvantage compared to omigen (can't supply a vendor neutral Verilog library with other code)
<tpw_rules>
it doesn't seem to be a local problem
<tpw_rules>
like the shape of the ram interface looks like what they show in the manual
<cr1901_modern>
I think as a workaround, you can create a Verilog top-level module with compiler defines to gate ISE and Quartus, and provide Verilog for both vendors as part of your package?
<tpw_rules>
this is the only little thing in this huge deal and it just happened. i'm hoping there's another tweak i can make
chipmuenk has quit [Quit: chipmuenk]
<tpw_rules>
like here is the generated verilog for something in another module relatively far from the memory that passes the data to the rest of the system: always @* begin o_cyc_rd_insn = 18'h00000; casez ({ cyc_wr, cyc_rd }) 2'b?1: o_cyc_rd_insn = i_prg_data; endcase end
<tpw_rules>
that case gives timing problems so i change it to: always @* begin o_cyc_rd_insn = i_prg_data; casez ({ cyc_wr, cyc_rd }) 2'b?1: o_cyc_rd_insn = i_prg_data; endcase end
<tpw_rules>
but now the memory does not infer because apparently of asynchronous read ports
<tpw_rules>
oh hm, it was apparently getting unhappy because o_cyc_rd_insn eventually fed back into the read address of that memory
<whitequark>
tpw_rules: the reg/wire distinction in verilog has *nothing* to do with wires or registers. it is purely syntactic
<whitequark>
wires can be assigned with `assign`. regs can be assigned in `always` blocks
<whitequark>
a `reg` can end up as a wire, a flip-flop, or a latch, depending on how you structure the `always` block
<whitequark>
for extra fun, `wire x = y;` (which is a shortcut for `wire x; assign x = y;`) is almost but not completely identical in behavior to `reg x; always @* x = y;`
* Lofty
also pets awygle's cat
<whitequark>
if `y` is a constant, say 0, then the latter will never execute and `x` will have an undefined value, as if it was never assigned at all
<whitequark>
SystemVerilog fixes that problem. `reg x; always_comb x = y;` works regardless of whether `y` is a constant.
<whitequark>
not content with having a construct that lacks footguns, it exchanges it for another: `reg x, y, z; always_comb begin y = x; z = y; end` works the way you'd expect, but `always_comb begin z = y; y = x; end` introduces a sim/synth mismatch.
<Lofty>
It wouldn't be a standardised HDL if it was sanely designed, right? /s
<whitequark>
Lofty: I mean, VHDL avoids that last problem with two-phase eval/commit
<Lofty>
True, yeah
<whitequark>
SV has to schedule tasks right when you're doing the assignment, which leads to bizarre things like "implicit sensitivity lists" which do not include any variable syntactically on LHS to make sure you don't end up with a feedback loop that assigns a reg the same value ad infinitum
<whitequark>
meanwhile VHDL can just be sensitive to every variable on RHS indiscriminately