electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
_whitelogger has joined #nmigen
FL4SHK has quit [Ping timeout: 256 seconds]
FL4SHK has joined #nmigen
FL4SHK has quit [Ping timeout: 265 seconds]
FL4SHK has joined #nmigen
hitomi2508 has joined #nmigen
alanvgreen has quit [Quit: Connection closed for inactivity]
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined #nmigen
<d1b2>
<Suryo> @Kate Temkin @edbordin @agg#0000 Hi! Yesterday, I reached out because I needed some help with understanding how to use the io pins on Orange Crab (and even in general). It took me to understand what the Connector class was actually doing. For some reason, I initially thought that it was to initialize just gpio connectors – it didn't strike me that it could also include the internal connectors in an FPGA. Once I understood that, it made a lot more sense
<d1b2>
to me. I looked at the Orange Crab board definition and saw that the gpio pins are actually not turned into Resources, and so I used the add_resource method and got it to work!! I'm really grateful that you gave me pointers and examples. I guess the fun in not having extensive documentation is having to figure this stuff out on our own.
<d1b2>
<edbordin> glad you're making progress 🙂
<d1b2>
<edbordin> also definitely listen to Kate's advice over mine as she actually knows what she's doing with nmigen 😛
<d1b2>
<Suryo> I'll keep that in mind but your observations were also very helpful.
<d1b2>
<Suryo> I should probably make some notes on how to navigate through nmigen's codebase since I've already done it and I don't want to forget it.
<d1b2>
<edbordin> I find this browser extension really handy on github for navigating code https://about.sourcegraph.com/
jeanthom has quit [Ping timeout: 272 seconds]
m4ssi has joined #nmigen
m4ssi has quit [Ping timeout: 260 seconds]
m4ssi has joined #nmigen
jeanthom has joined #nmigen
chipmuenk has joined #nmigen
pdp7 has quit [Excess Flood]
jeanthom has quit [Ping timeout: 260 seconds]
pdp7 has joined #nmigen
jeanthom has joined #nmigen
m4ssi has quit [Ping timeout: 246 seconds]
<d1b2>
<Suryo> Thanks a lot, @edbordin I'll check it out today!!
m4ssi has joined #nmigen
jeanthom has quit [Ping timeout: 258 seconds]
jeanthom has joined #nmigen
d0nker5 has joined #nmigen
ademski has joined #nmigen
jeanthom has quit [Quit: Leaving]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
Asu has joined #nmigen
hitomi2508 has quit [Quit: Nettalk6 - www.ntalk.de]
jeanthom has joined #nmigen
m4ssi has quit [Quit: Leaving]
jjeanthom has joined #nmigen
jeanthom has quit [Read error: Connection reset by peer]
emeb has joined #nmigen
jjeanthom has quit [Ping timeout: 258 seconds]
ademski has quit [Read error: Connection reset by peer]
chipmuenk has quit [Quit: chipmuenk]
emeb_mac has joined #nmigen
<d1b2>
<EmilJ> vup: hi, can I bug you with some higher level questions about the cores in nmigen-gateware?
<vup>
sure
<d1b2>
<EmilJ> so in hdmi_test.py in experiments, there's hdmi_plugin = platform.request("hdmi", "north"). How come this is a "plugin"? Isn't this asking for the abstract "Resource"?
<d1b2>
<EmilJ> also, is axi_writer_test.py functional and could I tear it down and frankenstein it into an HDMI capture card?
<vup>
this is just terminology coming from its connection to the axiom cameras, those have two plugin module slots that various things can be plugged into. hdmi_test.py can be used on those when you attach a "hdmi plugin" so thats why its called that
<vup>
axi_writer_test.py is functional
<vup>
if you wanto to turn it into a HDMI capture card, the biggest problem is probably getting the data somewhere after writing it to the RAM
<d1b2>
<EmilJ> well, I'll be happy once I get an interface with valid video data accessible from the Linux kernel
<vup>
also you would need to write a HDMI receiver core, thats a bit tricky as you probably need to do link training (1080p60 has a pixel clock of about 1.5GHz, which is above the specs for the normal zynq ios)
<d1b2>
<EmilJ> wait heck you don't have a HDMI Rx core
<vup>
also HDMI is CML, so you probably need some external termination
<d1b2>
<EmilJ> I guess that is why this FPGA board has a designated "HDMI sink" port
<vup>
oh, which board do you use?
<vup>
didn't get to the HDMI Rx core yet, although you can probably try to use litevideo, that has one
<d1b2>
<EmilJ> Pynq Z2
<d1b2>
<EmilJ> I don't need high resolutions, I'm just using a "computer comms interfaces" class that includes linux kernel driver stuff as an excuse to finally do some nmigen
<d1b2>
<EmilJ> > Using Migen I wonder if it'll Just Work if I use nmigen.compat
<d1b2>
<EmilJ> (LiteVideo is Migen)
<vup>
using litevideo + nmigen.compat is what our tx core started with
<vup>
I think some small fixes were required, but most of it was fine I think
<d1b2>
<EmilJ> I am... not going to wage that war I think, limited time allocation and whatnot. I'll just turn this into a demoscene card
<vup>
:)
<vup>
We were actually also working on doing HDMI capture using a ft60x, however are currently mostly busy with other stuff unfortunately
<d1b2>
<EmilJ> hm, I see in camera.py AxiBufferWriter(ring_buffer, hispi.output) and that's like, an "axi writer" as in "thing that writes to axi" but you don't give it an axi slave
<d1b2>
<EmilJ> so it's just writing to the ring buffer and expecting some other thing to be reading from the ring buffer/
<d1b2>
<EmilJ> ?
Asu has quit [Quit: Konversation terminated!]
DaKnig has quit [Ping timeout: 272 seconds]
<d1b2>
<EmilJ> oh, looking at the source, no, it gets an axi slave from PS7 if not explicitly specified. Neat. Well, neat for somebody with a 7-series, since the axi core is not hardware-agnostic because of it :D
<d1b2>
<EmilJ> I'm really getting lost now. Camera.py has one ring buffer, which I now guess is written to from camera data, and read by the HDMI interface as well as the AXI slave port of the PS7?
<d1b2>
<EmilJ> vup: help
<vup>
ok, so the RingBufferAddressStorage is not a complete ringbuffer by itself, it merely provides base addresses to buffers in the RAM
<d1b2>
<EmilJ> wait what does that mean
<d1b2>
<EmilJ> it maps PL RAM buffers to AXI-accessible addressed storage?
<vup>
no
<vup>
when I say RAM here I mean the ddr RAM connected to the zynq
<vup>
(the one that can also be used by the arm cores)
<d1b2>
<EmilJ> well I better should know that some addresses in there are occupied by the PL
<d1b2>
<EmilJ> better yet, my Kernel should know that it's not the only player there, right?
<d1b2>
<EmilJ> Is that... solved or solvable in the default Xilinx bootables?
<vup>
yep, so RingBufferAddressStorage takes a `base_address=0x0f80_0000`
<vup>
(or any address you want)
<vup>
and in u-boot using `fdt rsvmem add 0xf800000 0x08000000` this is reserved so the kernel doesn't use it
<d1b2>
<EmilJ> oh cool
<d1b2>
<EmilJ> and the module pipes in and out the DDR RAM buffer with AXI?
<vup>
so the general idea of camera.py is, that frames coming from the image sensor (received by the hispi receiver) are written into a ringbuffer in the RAM by the axi writer (the base addresses are specified by RingBufferAddressStorage) and then read out to display them using HDMI by the HDMIBufferReader
<vup>
yep
DaKnig has joined #nmigen
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
<d1b2>
<EmilJ> I see. Looking at the architectural overview in zynq 7000 overview, there's a "programmable logic to memory interconnect" routing AXI
<d1b2>
<EmilJ> how is that configured?
<d1b2>
<EmilJ> registers from PS?
<vup>
yes
<vup>
there one can configure some things that mainly help with performance iirc
<vup>
like priority for specific ports, fifo sizes etc.
<vup>
(Appendix B has all the register details, the axi_hp and the ddrc region are probably the most interesting
<vup>
and the qos301 part)
<d1b2>
<EmilJ> I wonder if I could just... delete the camera bits, and even though it's not available for memory allocation by the kernel, write to the DDR ring buffer from a kernel module
<vup>
you can
<vup>
you could also do it from userspace by mmap'ing /dev/mem
<vup>
the main problem when writing (or reading) the ringbuffer from the PS side is synchronisation with the PL side wrt what buffer to use when
<d1b2>
<EmilJ> > there one can configure some things that mainly help with performance iirc
<d1b2>
<EmilJ> can I get away without writing custom code for these registers though?
<d1b2>
<EmilJ> As in, if I use a clean bootable Linux image, and load the bitstream synthesized from camera.py, do I find the video buffers at the DDR addresses?
<vup>
yes
<vup>
you might need them for performance reasons (1080p60 HDMI gets glitchy if you do a lot of stuff on the linux side with the default settings)
<d1b2>
<EmilJ> Well, thanks for the support, I think I could be able to get this setup working in a reasonable timeframe. You'll probably get support for another board of me playing about in the codebase
<d1b2>
<EmilJ> About general nmigen: I know docs are a much requested feature but is there a place for crowdsourced descriptions, guides and stuff to accumulate? Something like a collaborative editing scratchpad document which might figure out the structure for a readthedocs or github wiki style documentation
<d1b2>
<EmilJ> A lot of tips and wisdoms gets burried in the chatlog
jjeanthom has joined #nmigen
jjeanthom has quit [Remote host closed the connection]
jjeanthom has joined #nmigen
jjeanthom has quit [Ping timeout: 260 seconds]
jjeanthom has joined #nmigen
<tpw_rules>
i can spew random tips on my camera system i did with an altera HPS if it might be helpful
jjeanthom has quit [Ping timeout: 240 seconds]
emeb has quit [Quit: Leaving.]
<vup>
@EmilJ adding a new board sounds good. As for a place to collect stuff around nmigen: Maybe a community driven github repo or even a simple codimd document could be a start?