electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
d0nker5 has joined #nmigen
d0nker5_ has quit [Ping timeout: 256 seconds]
DaKnig has quit [Ping timeout: 256 seconds]
DaKnig has joined #nmigen
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined #nmigen
DaKnig has quit [Ping timeout: 240 seconds]
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
DaKnig has joined #nmigen
Asu has joined #nmigen
jjeanthom has joined #nmigen
<d1b2>
<EmilJ> vup: wait, I don't need an AxiBufferWriter if I don't need the writing axi to be one accessible to the PL, right? But without it, it seems like it's not giving me a register holding the current buffer index
<vup>
right
<vup>
currently the address management is controlled by the writing side
<vup>
well the register is there
<vup>
but you need to replicate the ringbuffer logic done by the AxiBufferWriter
jjeanthom has quit [Ping timeout: 240 seconds]
jjeanthom has joined #nmigen
d0nker5 has quit [Quit: leaving]
d0nker5 has joined #nmigen
<Lofty>
sorear: remember the FPGA I made a while back and then kinda left?
<sorear>
ish
<Lofty>
Decided to write a blog series about another one, based on what I learned from the first
<Lofty>
(hey, it's written in nMigen, it's moderately on-topic)
emeb has joined #nmigen
d0nker5 has quit [Read error: Connection reset by peer]
<agg>
i often find i can either write things like "if(en): m.d.sync += a.eq(a + 1); else: m.d.sync += a.eq(0)" or I could write "m.d.sync += a.eq(Mux(en, a+1, 0))", as far as I can tell it always compiles to the same number of gates and wires, is it always just a style choice / is there an obvious preference?
<agg>
(in that particular example the Mux seems clearest but sometimes there's a couple of signals being controlled or sometimes I don't have anything in the Else block, nevertheless it can often be written in fewer lines using Mux, not really sure which conveys intent more clearly either)
<whitequark>
agg: makes no difference
<agg>
thanks
emeb_mac has joined #nmigen
<FL4SHK>
Just got my integer divider algorithm implementation in Python done
<FL4SHK>
it's basically just radix 8 long division
<FL4SHK>
but I search for the next quotient digit with binary search
<FL4SHK>
turns out that the way I've done this has a very low LUT delay
<FL4SHK>
maybe 5 LUTs?
<FL4SHK>
I could increase the LUT delay by about 2 LUTs to get radix 64 long division implemented
<FL4SHK>
going to now write it up in nMigen
<d1b2>
<EmilJ> vup: I am trying to debug camera.py, and at the end of AxiBufferWriter elaboration, self.current_buffer.address is still not set
<d1b2>
<EmilJ> also if anybody thinks I'm spamming a general nmigen room with my specific questions, we can move this elsewhere
jjeanthom has quit [Ping timeout: 258 seconds]
<vup>
@EmilJ: there is no self.current_buffer.address, you probably mean self.current_buffer.current_write_buffer? That is set by the AddressGenerator
<d1b2>
<EmilJ> hm, no, there's self.current_buffer = ringbuffer.current_write_buffer
<d1b2>
<EmilJ> anyway, it means that even when the AxiBufferWriter and its Address Generator are elaborated, ring_buffer.current_write_buffer.address is None
<d1b2>
<EmilJ> which I assume is where the memory would appear which when equivalently incremented from software would make the read buffer emit video on HDMI
<vup>
where are you getting the current_write_buffer.address from?
<vup>
ring_buffer.current_write_buffer is just a Signal it has no address attribute...
<d1b2>
<EmilJ> the debugger
<d1b2>
<EmilJ> :D
<vup>
oh
<vup>
i see
<d1b2>
<EmilJ> well the debugger and the code are my only way of making sense of the code
<vup>
it has a address attribute, but that is the address it will get mapped to on the axi bus
<d1b2>
<EmilJ> bc of this, I estimate that things being named weird things has like doubled the time it took me to get this far
<vup>
but that is set in a rather magic way :)
<d1b2>
<EmilJ> I'm fine with abstracting away mapping on the axis themselves, but how do I find where do I write to from code?
<d1b2>
<EmilJ> oh neat. Ddoesn't ZynqSocPlatform inheriting from SocPlatform already do this?
<vup>
do what?
<d1b2>
<EmilJ> append the pydriver hook
<d1b2>
<EmilJ> or should I create a new hook?
<vup>
yep that
<vup>
the pydriver hook was meant as an example on how to get the address information in a hook
<d1b2>
<EmilJ> I see, okay. I assume if I do a text output hook, or like, a C header outpout hook, I still won't find my current buffer register because I don't have a buffer writer in my HDL, right
<vup>
@EmilJ: right, you need to add it to a module somewhere
<vup>
a simple `self.current_write_buffer = ring_buffer.current_write_buffer` in the Top elaborate however is enough
<d1b2>
<EmilJ> oh!
<d1b2>
<EmilJ> wonderful
<vup>
the memorymap is hierarchical so that will put it in the hierarchy under `top` if you want it somewhere else you need to just move that statement to another module
<d1b2>
<EmilJ> Would that make a functional difference? What module makes all/some top-level registers accessible to the processor?
<vup>
no functional difference, all registers are accessible to the processor. You can however use the hierarchy to make nicer wrappers: https://paste.niemo.de/ebufegomew.py
<vup>
so you get `print(Top().buffer_writer.address_generator.current_buffer)` or `Top().buffer_writer.address_generator.current_buffer += 1`
<d1b2>
<EmilJ> 25k lines of emitted verilog, 1896 lines of Vivado logs, 251 warnings
<d1b2>
<EmilJ> lots of resources are unconnected, but that seems ok. Some OSERDES complaints about something about the HDMI...
<d1b2>
<EmilJ> what worries me is this critical warning in netlist: Incorrect value '12'b011110000000' specified for property 'init'. Expecting type 'binary' with possible values of '1'b0,1'b1'.
<d1b2>
<EmilJ> it happens in things like assign \$45 = + hsync_start;
Asuu has joined #nmigen
Asu has quit [Ping timeout: 260 seconds]
<d1b2>
<EmilJ> looking at timing, I guess my clock domains are totally wrong. Time to figure out what the heck DomainRenamer actually does
tucanae47_ has quit [Read error: Connection reset by peer]
Qyriad has quit [Read error: Connection reset by peer]
tucanae47_ has joined #nmigen
Qyriad has joined #nmigen
<vup>
true, there should probably be a atleast a small fifo between the axi reader and the hdmi output
<vup>
a small SyncStreamFifo should do the trick
<d1b2>
<EmilJ> as in, the AxiBufferReader in axi cores instantiated from HdmiBufferReader in my thing (as well as camera.py) should have a FIFO to meet timings more easily?
<vup>
currently the HdmiBufferReader connects the output stream of the AxiBufferReader directly to the HDMI encoder
<vup>
putting a SyncStreamFifo between the output stream of the AxiBufferReader and the HDMI encoder should do the trick
<d1b2>
<EmilJ> okay, do you think the design will work as it is though? Let me push the script