FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #nmigen
ianloic_ has joined #nmigen
_florent__ has joined #nmigen
ktemkin_ has joined #nmigen
whitequark has quit [*.net *.split]
Sarayan has quit [*.net *.split]
ianloic has quit [*.net *.split]
_florent_ has quit [*.net *.split]
ktemkin has quit [*.net *.split]
ianloic_ is now known as ianloic
ktemkin_ is now known as ktemkin
_florent__ is now known as _florent_
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
jfng has quit [Ping timeout: 260 seconds]
emily has quit [Ping timeout: 260 seconds]
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
emily has joined #nmigen
jfng has joined #nmigen
Sarayan has joined #nmigen
Guest30583 has joined #nmigen
thinknok has joined #nmigen
Asu has joined #nmigen
thinknok has quit [Ping timeout: 256 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
thinknok has joined #nmigen
whitequark has joined #nmigen
thinknok has quit [Ping timeout: 240 seconds]
jfng has quit [Ping timeout: 240 seconds]
emily has quit [Ping timeout: 252 seconds]
<kbeckmann>
this is perhaps a generic HDL-question, but what is the proper way to do a gearbox in nmigen? I want to generate/calculate pixels at a lower clock rate, let's say 8 times slower than the pixel clock, but consume them in the pixel clock domain.
<kbeckmann>
it would be nice to be able to use a Memory() with a wider write port in my case, but that doesn't seem to be possible currently or maybe I'm just missing something :)
<kbeckmann>
oh, i'm just stupid. the fifo module seems to handle just this. sorry for the noise.
<whitequark>
wait, it does?
<whitequark>
that would be news to me
<kbeckmann>
urgh, i'm just a bit confused. you're right, it doesn't. i got confused about the 'width' in din vs dout
<whitequark>
awygle was talking about adding gearbox FIFOs at one point
<whitequark>
so the thing is that right now yosys can't do asymmetric memories
<whitequark>
but even if you don't synthesize via yosys, it can't *represent* those
<whitequark>
and neither can nmigen
<whitequark>
that's the bad news
<kbeckmann>
if i'm ok with having it stored in registers, how should i go about it?
<kbeckmann>
or i guess FFs is the correct term here
<whitequark>
oh, i'm not talking solely about BRAMs
<whitequark>
this also applies to LUTRAMs and FFRAMs
<kbeckmann>
oh.. okay
<whitequark>
the good news is that this limitation (unlike some other issues yosys has around memories) is not fundamental
<whitequark>
and you're not really losing much because of it
<whitequark>
let me think about the way this would work out with the current state of nmigen...
<whitequark>
can you tell me more about your use case?
emily has joined #nmigen
<kbeckmann>
i'm generating a DVI-D signal with a pixel clock of 150MHz with the ECP5. I'd like to be able to use longer logic chains to generate the pixels, so i can meet timing.
<whitequark>
do you care about latency?
<kbeckmann>
not really
<kbeckmann>
i can just add latency to the sync signals
<kbeckmann>
and in this case i don't really care about being economic with LUTs, it's ok if it's expensive.
<whitequark>
do you generate multiple pixels per cycle in the slow domain? i assume you do otherwise i don't know how this can work
<kbeckmann>
yeah that is the idea
<whitequark>
ok
<whitequark>
so you make a FIFO wide enough for 4 pixels, and you stuff 4 pixels at once there (just using 4 as an example)
<whitequark>
in the slow domain
<kbeckmann>
ah, and then read once every 4th clock in the pixel clock domain?
<whitequark>
then in the fast domain, you read once per 4 cycles, and use a 4:1 mux switching like 0,1,2,3 to output pixels
<whitequark>
yep
<kbeckmann>
cool, thank you!
<whitequark>
this is a few lines of code and shouldn't cost you anything much in terms of logic
<kbeckmann>
nice
<whitequark>
you might want to use asyncfifobuffered to improve the timings in the fast domain
<whitequark>
but probably check it with the actual code
<kbeckmann>
okay, thanks! will try it out now.
<whitequark>
i'm not sure if ecp5 has clock-to-out delay as high as xilinx does
<whitequark>
for BRAMs that is
<daveshah>
Higher
<whitequark>
ok then you *definitely* want to use AsyncFIFOBuffered.
<daveshah>
although it is 3x less for 5G parts at 1.2V
<whitequark>
or the clock-to-out delay + mux logic delay can very well eat your 7 ns budget
<daveshah>
For -6, clock-to-out along is almost 6ns
<daveshah>
*alone
<kbeckmann>
i'm on a -8 with 1.2V (but i'd like this to work on 1.1V too :) )
<whitequark>
daveshah: a long time ago i had no idea why migen even had asyncfifobuffered
<whitequark>
but this really drives the point in heh
<awygle>
Yeah the unbuffered FIFOs are near useless with ecp5
<awygle>
whitequark: the last time we talked about this we discussed a polyfill for asymmetric memories
<awygle>
which basically did what you're describing
<awygle>
iirc
<awygle>
also I am taking a mulligan on yesterday, it doesn't count :-P
<whitequark>
mulligan?
<awygle>
it's a term originally from golf I think where if you fuck up your shot badly enough you're just like "didn't count, hitting it again" (I think you also get a +1 to your score)
<awygle>
also applies to magic the gathering
<awygle>
yesterday I achieved zero (0) things, despite saying to you that I would achieve one (1) thing
<awygle>
this is a tongue in cheek apology which acknowledges that I had no actual commitment-commitment but I still feel somewhat bad despite having what I believe were good reasons for not working on nmigen yesterday
<whitequark>
awygle: i have zero expectations (especially during a fucking pandemic *and* civil unrest) and i didn't even remember that you owed me anything
<whitequark>
this applies until the end of this year at least, take note
<awygle>
I figured you'd be understanding, and I also felt the need to acknowledge it
<whitequark>
right ok
jfng has joined #nmigen
thinknok has joined #nmigen
thinknok has quit [Remote host closed the connection]