ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting September 14th
DaKnig has quit [Ping timeout: 272 seconds]
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
DaKnig has joined #nmigen
jjeanthom has joined #nmigen
<_whitenotifier-f> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-f> [YoWASP/nextpnr] whitequark 0ecba91 - Update dependencies.
jjeanthom has quit [Ping timeout: 260 seconds]
jjeanthom has joined #nmigen
jjeanthom has quit [Ping timeout: 260 seconds]
_whitelogger has joined #nmigen
emeb_mac has joined #nmigen
_whitelogger has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
d0nker5_ has joined #nmigen
PyroPeter_ has joined #nmigen
d0nker5 has quit [Ping timeout: 258 seconds]
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
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, 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?
<vup> ok
<vup> or set a breakpoint to pydriver_hook
<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:
<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
<vup> hmm thats a strange critical warning
Asuu has quit [Quit: Konversation terminated!]
<d1b2> <EmilJ> do you want the logs
<d1b2> <EmilJ> also timing is slackin'
Asuu has joined #nmigen
<vup> the stuff that doesn't meet timing was always the csr stuff, which should be fine, you are probably not gonna toggle those at 100MHz
<d1b2> <EmilJ> hmm. assembly code for single-cycle CSR toggles...
<vup> lol, the CSR AXI bridge doesn't even do pipelined / out of order AXI transactions, so I think at most you could do 25MHz
<d1b2> <EmilJ> just memeing at this point
<d1b2> <EmilJ> what do you think about the weird init values?
<vup> do you get those warnings with a unmodified
<d1b2> <EmilJ> no, I can't even elaborate that lol
<vup> because I dont get any with vivado 2019.2
<vup> what?
<vup> `python3 src/experiments/ -d MicroR2 -s Zynq -b`
<d1b2> <EmilJ> so seemed to rely on being moved up to src/ and my issue may be bc I did the same to
<d1b2> <EmilJ> will test
<d1b2> <EmilJ> yup
<d1b2> <EmilJ> no module named 'cores'
<vup> ah
<d1b2> <EmilJ> so if I copy to src/ and cd to src
<vup> If you run it outside of a IDE i think you need PYTHONPATH=$PYTHONPATH:$(pwd)/src
<d1b2> <EmilJ> I'm running in VSC terminal
<d1b2> <EmilJ> I see
<vup> can you upload the verilog file belonging to the log?
<d1b2> <EmilJ> yea
<d1b2> <EmilJ> dammit, bash does not translate to fish well enough for me to just copypaste that
<d1b2> <EmilJ> I love fish but broken compatibility makes me sad
<d1b2> <EmilJ> lol it won't display bc too many bytes
<vup> hmm I don't really get whats the warning is supposed to be about
<d1b2> <EmilJ> assigning conflicting bit widths, but do we even care about initial state at all here?
<vup> The thing is I don't get where the initial state is even coming from, and also I think assigning smaller thing to larger things is fine I think
<d1b2> <EmilJ> okay. It's worrying that the log is like "this repeats more so we ignore it"
<d1b2> <EmilJ> it may be occurring for each net or something
<vup> maybe, something seems off, I get those with our verilog file even on my vivado version
<d1b2> <EmilJ> Slack (VIOLATED) : -0.547ns (required time - arrival time) Source: ps7/ps7_block/instance/SAXIHP0ACLK
<d1b2> <EmilJ> this seems bad though
Asuu has quit [Ping timeout: 264 seconds]
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 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
<vup> might get glitchy output
<vup> something like this: should help
<d1b2> <EmilJ> hm, cool, thanks
<d1b2> <EmilJ> I'll rebuild with that added in tomorrow. Good night
<vup> good night!
emeb has quit [Quit: Leaving.]