alexshendi has quit [Remote host closed the connection]
ali_as__ has joined #glasgow
ali-as has quit [Ping timeout: 252 seconds]
ali-as has joined #glasgow
ali_as__ has quit [Ping timeout: 250 seconds]
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg_ has quit [Remote host closed the connection]
redstarcomrade has joined #glasgow
jstein has joined #glasgow
Abhishek_ has joined #glasgow
redstarcomrade has quit [Quit: Connection closed for inactivity]
Shiz has quit [Quit: WeeChat 3.0]
Shiz has joined #glasgow
Abhishek_ has quit [Quit: Connection closed for inactivity]
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 268 seconds]
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
redstarcomrade has joined #glasgow
egg|anbo|egg has joined #glasgow
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
redstarcomrade has quit [Quit: Connection closed for inactivity]
redstarcomrade has joined #glasgow
<d1b2>
<Attie> thanks for pointing that out @tnt , and thanks for the patch @kbeckmann
<d1b2>
<Attie> I put an LED indicator for overflow in one of my applets (I2S), but that's probably at a different level to where you'd need it for the underlying FIFO
<d1b2>
<kbeckmann> Ah that sounds great, will have a look at it.
<d1b2>
<tnt> Heh, yeah, I wouldn't merge that ... chances are actual applet wouldn't meet timing ...
<d1b2>
<kbeckmann> While developing it was hard for me to know if my logic was bad or if I just had fifo overrun issues.
<d1b2>
<tnt> or you'd need like a "per applet" flag.
<d1b2>
<kbeckmann> Oh for sure. Please don’t merge it.
<d1b2>
<Attie> (no worries, no intention to merge it or suggest that, but handy to have "in the stash"!)
<d1b2>
<kbeckmann> Ah great. My applet violates timing with a few MHz but worked well enough for me to validate what I was testing.
<d1b2>
<kbeckmann> Meeting timing at over 48MHz seems to be quite a challenge if the applet is doing something more than just piping data.
<d1b2>
<Attie> ... the I2S applet is still a little rough around the edges - e.g: doesn't play well with higher sample size / rates, and there's no latch / timer on the overflow flag, which you might want to add
<d1b2>
<Attie> ha, good to know
<d1b2>
<kbeckmann> I am wondering what the proper way is to handle an external clock domain for writing to the fifo with. I did something that worked but I’m not sure if it’s right.
<d1b2>
<Attie> i'm probably not best suited to comment on that, but happy to take a quick look
<d1b2>
<Attie> do you have a FIFO in your applet, or are you trying to write directly to the "core" / underlying FIFO?
<d1b2>
<kbeckmann> I’m using an external pin that has a clock running at around 50MHz that I use to sample the connected bus with.
<d1b2>
<kbeckmann> Yes
<d1b2>
<kbeckmann> Sorry that yes was ambiguous. I mean the second part of your question. I write to the core fifo directly from the external clock domain.
<d1b2>
<Attie> ok
<d1b2>
<Attie> you've done the two things I was wondering about suggesting - auto_flush=False and increasing the FIFO depth
<d1b2>
<Attie> how much blanking do you have / what is the expected data rate?
<d1b2>
<kbeckmann> Around 30MB/s
<d1b2>
<Attie> (i presume you're only trying to transfer the active area?)
<d1b2>
<kbeckmann> The blanking is 96 or so pixels iirc
<d1b2>
<kbeckmann> It works and I am able to stream a mostly glitch free real time video stream.
<d1b2>
<kbeckmann> I was just curious if there is a correct way of setting up the clock domain in the build() function.
<d1b2>
<Attie> ah i see, i misunderstood - sorry
<d1b2>
<Attie> (yay, well done!)
<d1b2>
<kbeckmann> Thanks :). It was fun to write.
<d1b2>
<Attie> i bet - i'd be interested to see the "other half" too some time (whatever you're using to render the video)
<d1b2>
<Attie> re clock domain... i'm not sure , but what you've done looks sensible to me
<d1b2>
<kbeckmann> It feels like a hack to pass the cd_video variable though
<d1b2>
<kbeckmann> I got issues when I tried to setup the CD in the build function and then accessing it by name from the elaborate function. This part of nMigen is a bit difficult to understand to me.
jstein has quit [Ping timeout: 240 seconds]
<d1b2>
<Attie> i know what you mean, but I think it's necessary - you do want the FIFO to sit in the video clock domain, and therefrore you need to have the domain available when you get the FIFO
<d1b2>
<Attie> an alternative could be A) to push the iface through into the Subtarget, or B) perhaps look at peeling the CD off the FIFO, but both feel worse to me / reduce clarity + intent
<d1b2>
<Attie> (though again, I'm not perhaps most suitable to comment)
<d1b2>
<kbeckmann> Alright. I’ll keep it as it is.
<d1b2>
<kbeckmann> I started out with a nasty hack where I had a second async fifo in the applet’s elaborate function that then fed the sync fifo.
<d1b2>
<kbeckmann> So I think what I have now is probably good enough.
<d1b2>
<kbeckmann> Just had a quick look at you i2s applet and I’ll definitely bookmark it. You’re using a bunch of cool features that seem very useful. I hope we can add some more examples that showcase features like the registers and leds in a simple and straightforward way.
<d1b2>
<tnt> @kbeckmann If your clock isn't coming in to a global clock pin, things are a bit random.
<d1b2>
<tnt> The "proper" way is to have the clock come in to a global clock pin into a global buffer, then use that network to clock IO registers and capture the initial signal there. Either on rising or falling edge depending on the result of an IO timing analysis you need to do "manually". That's the only way to guarantee stable results. Anything else might depend of your PNR seed because of how things might end up placed/routed in the FPGA.
egg|anbo|egg_ has quit [Read error: Connection reset by peer]
<d1b2>
<kbeckmann> Ah I see, thanks for the info. Maybe we could highlight which pins are clock input pins in the pin out guide?
<d1b2>
<Attie> we don't have any global clock pins on the A/B ports, right? I guess the current implementation the "best" option right now?
<d1b2>
<kbeckmann> Oh ok
<d1b2>
<Attie> @K(ate) Temkin - perhaps this could be a requirement / request for the next rev?
<d1b2>
<tnt> 4 & 6 of each port are global clock IOs.
<d1b2>
<Attie> oh! ... so they are ... thanks / oops
<d1b2>
<tnt> But that brings another point ... if add ons are designed to use those for clocks, should that be part of the spec for add-ons and something maintained for future revs.
<d1b2>
<Attie> i completely mis-remembered, thinking there were only one (possibly two)
<d1b2>
<Attie> yes, i think that would be very sensible
<d1b2>
<tnt> @kbeckmann Although realistically at 50 MHz, as long as you capture on the opposite edge from the one that the data transitions at, the data valid window is probably wide enough that it'll work regardless ... (which is probably why it's working for you). So whether it's worth bothering or not ... 🤷♂️
<d1b2>
<kbeckmann> Yeah, I suppose. What I did on the Glasgow was mostly to verify some logic and an excuse to write an applet :). Learned a lot in the process.
egg|anbo|egg has quit [Remote host closed the connection]
redstarcomrade has quit [Quit: Connection closed for inactivity]
egg|anbo|egg has joined #glasgow
ali-as has quit [Remote host closed the connection]