<shapr>
Hail_Spacecake: what's your favorite Haskell trick?
seldridge has joined #yosys
promach has quit [Quit: WeeChat 2.3-dev]
_whitelogger has joined #yosys
seldridge has quit [Ping timeout: 260 seconds]
s1dev has joined #yosys
mazzoo has quit [Ping timeout: 260 seconds]
s1dev has quit [Ping timeout: 260 seconds]
<jit10>
hello, i am using nextpnr-ice40 with blinky example using SB_RGBA_DRV for up5k and i get "ERROR: no timing info for port 'RGB0' of cell type 'SB_RGBA_DRV" .
gnufan has joined #yosys
<Hail_Spacecake>
shapr: good question
<Hail_Spacecake>
algebraic data types I guess?
<daveshah>
jit10: oops, forgot to finish implementing that. Will sort when I next have a moment
gnufan has left #yosys [#yosys]
gnufan has joined #yosys
<jit10>
daveshah: thanks
<jit10>
i have no idea how it all works, do you have any pointers to learn more about it?
dxld has quit [Quit: Bye]
dxld has joined #yosys
develonepi3 has quit [Remote host closed the connection]
develonepi3 has joined #yosys
seldridge has joined #yosys
cemerick has joined #yosys
seldridge has quit [Ping timeout: 244 seconds]
cemerick has quit [Ping timeout: 240 seconds]
seldridge has joined #yosys
maikmerten has joined #yosys
<mattvenn_>
could I get some input on a double buffer vga drawing system I want to build
<mattvenn_>
vga module will continuously be reading one of the pixel buffers from the hyperram
<mattvenn_>
when vga module is not producing a signal (edges and bottom), busy signal will be low
<mattvenn_>
this vga busy signal is used as a clock enable for the draw module
<mattvenn_>
and for mux on addr lines
<mattvenn_>
(realised don't need data as vga will only read and draw will only write)
<mattvenn_>
but I think this system will have timing problems because the hyperram will take around 40 clocks to read/write values
<mattvenn_>
so it could easily be interrupted in the middle of a write by the vga module
<mattvenn_>
which will screw up the transfer
<mattvenn_>
I could make the busy signal so it only goes low at the bottom of the screen, where there is a big block of uninterrupted time
<mattvenn_>
and reassert X clock cycles before next screen starts drawing
<mattvenn_>
but wondered what is the usual way of approaching this?
<mattvenn_>
thanks for any tips/pointers
emeb has joined #yosys
fouric has joined #yosys
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
fouric has quit [Quit: WeeChat 2.2]
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
develonepi3 has quit [Remote host closed the connection]
<ZipCPU>
mattvenn_: How big of a screen area?
<ZipCPU>
... and what's the pixel clock frequency?
AlexDaniel has joined #yosys
<ZipCPU>
The last video project I worked on died at the bandwidth to the memory. It was a 1080p60 design that both received HDMI and transmitted HDMI. My goal had been to place the image in DDR3 SDRAM, read it from DDR3 SDRAM, and operate on it in the middle.
<ZipCPU>
The bandwidth/speed numbers just didn't support any thing like that.
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfie_ has joined #yosys
mjoldfie_ has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
develonepi3 has joined #yosys
seldridge has quit [Ping timeout: 248 seconds]
<mattvenn_>
ZipCPU: probably 640x480 for now, though ideally parameterised
<mattvenn_>
pixel clock is about 30mhz
<mattvenn_>
hyperram can operate at 100mhz, but I'd probably try to run it at the same pixel clock
<mattvenn_>
and buffer a line at a time to block ram
<ZipCPU>
If hyperram operates at 100mhz, how many pixels per second is that?
<mattvenn_>
ponders
<daveshah>
Depends on your bit depth
<ZipCPU>
You are very quickly going to run out of memory bandwidth
<daveshah>
50Mpix/s at 16bpp
<daveshah>
33Mpix/s at 24bpp
<mattvenn_>
my vga adapter is only 6bit, so I'd probably do 1 byte per pixel
<ZipCPU>
daveshah: Let's stick to 8bpp
<daveshah>
But might be able to double with ddr mode
<ZipCPU>
Let's assume the hyperram operates as fast as possible
<mattvenn_>
also hyperram has overheads for random addressing, but burst mode is faster
<ZipCPU>
We'll take mattvenn_'s number of 100MHz, although I think it can go faster
<daveshah>
Up to 333MByte/s in theory
<daveshah>
Significant overhead for random access, little for line or frame access
<ZipCPU>
mattvenn_: What FPGA?
seldridge has joined #yosys
<mattvenn_>
ice h40 8k
* ZipCPU
doubts that the 8k is up to 333MB/s
<ZipCPU>
Let's stick with 100MB/s
<sorear>
How wide is the bus?
<ZipCPU>
8'bits
<daveshah>
OTOH if your clock is 100MHz than 200MT/s ddr can come pretty much for free
<daveshah>
Can use the PLL to get the 90deg phase aligned clock too
<ZipCPU>
So, 100MHz, 200MB/s, right?
<daveshah>
Believe so
<ZipCPU>
So, let's go with 200MB/s, pixel rate is about 25 MB/s now
<ZipCPU>
That's starting to look doable.
<mattvenn_>
for me this is really an experiment in double buffering
<mattvenn_>
so I'm not that worried even 1bpp
<ZipCPU>
Did you see my experiment with scrolling double buffers?
<ZipCPU>
Or rather, one buffer that was 2x as wide as it needed to be so it could support the appearance of scrolling?
<ZipCPU>
Performs a spectral raster, rotating from right to left across the screen in real time.
<mattvenn_>
any thoughts on how to manage ram access between vga reading and draw modules drawing?
<ZipCPU>
For me, everything is WB. So, as soon as there's a line free in the video buffer, the WB access begins, and doesn't end until a whole line has been read.
<ZipCPU>
During that time, the memory controller stalls the bus
<ZipCPU>
During the read that is--no more than one master can get access to any device.
<ZipCPU>
Ooohh ... how are you going to keep the two sync'd? So that the data on one (nearly/roughly) matches the data on the other?
<ZipCPU>
Big changes to the buffer would need to be made twice.
<mattvenn_>
what do you mean "as soon as there's a line free in the video buffer
<ZipCPU>
The video buffer (block RAM, in the VGA controller) contains room for a couple of video lines. As soon as a new frame is declared, it fills the buffer with as many whole lines as it can.
<ZipCPU>
As soon as there's room for another line of pixels, the controller reads another line of pixel memory into its buffer.
<ZipCPU>
You might find the VGA simulator there to be *VERY* useful as you develop.
<mattvenn_>
so that process can't be stalled
<mattvenn_>
and always has to have precedence
<mattvenn_>
so how to sync that with some other process that wants to 'draw' into the ram?
<ZipCPU>
The code in the vgasim repo issues a "sync" as soon as the last pixel is drawn to the screen
<ZipCPU>
"sync"? A VGA interrupt might be a better term for it. A single impulse for the rest of the design.
<mattvenn_>
last pixel of the last line?
<ZipCPU>
Yes.
<mattvenn_>
so then some other proces can get clock enabled and start drawing in ram
<mattvenn_>
but how do you make sure that stops in time for the vga to start accessing the ram again
<mattvenn_>
just work out the timing requirements and ensure it ends in time?
<ZipCPU>
I don't. I've been lucky so far.
<mattvenn_>
or is there some kind of often used mechanism for making it work
<ZipCPU>
Basically, my arbitration for random accesses releases the bus at the end of every access
<ZipCPU>
For pipelined access, it releases it as soon as the pipelined access is over.
<ZipCPU>
That usually leaves plenty of room to be interrupted.
<mattvenn_>
but you have a chance of missing the first line of the new screen draw perhaps?
<ZipCPU>
Not really. I start reading the new frame (IIRC) as soon as the last pixel is done. I've therefore got the whole veritical blanking time to fill my buffer
<ZipCPU>
*vertical
<mattvenn_>
ok I think I get it
<ZipCPU>
Feel free to run the demo in vgasim and look at the trace
<mattvenn_>
your bram buffer is already filled for the next frame before any other process can start accessing the ram
<ZipCPU>
.... although, nothing writes to the screen in that trace. The fftdemo uses almost the same code, but the FFT gets written to the screen in that one.
<mattvenn_>
then as soon as a line is free in the bram buffer, the vga gets priority on the WB
<ZipCPU>
Well, not quite ... bus accesses are uninterruptible, I'm not sure I used the priority arbiter, and the other writer may slow down the buffer getting filled in the first place.
<mattvenn_>
ok, probably best if I just look at your trace
<ZipCPU>
The FIFO in the writer's signal path was a fun twist.
<ZipCPU>
That way, whatever is writing to screen memory can keep going--even if the memory is busy.
<mattvenn_>
ok, thanks Dan and Dave!
<ZipCPU>
;)
seldridge has quit [Ping timeout: 272 seconds]
Alistair_ has joined #yosys
me` has joined #yosys
me` has quit [Excess Flood]
swick[m] has quit [*.net *.split]
jfng[m] has quit [*.net *.split]
forrestv has quit [*.net *.split]
jhol has quit [*.net *.split]
me` has joined #yosys
xa0 has quit [*.net *.split]
andi- has quit [*.net *.split]
Alistair has quit [*.net *.split]
xa0 has joined #yosys
forrestv has joined #yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
andi- has joined #yosys
Alistair_ has quit [Ping timeout: 260 seconds]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
Alistair has joined #yosys
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
xa0 has quit [Excess Flood]
xa0 has joined #yosys
Hail_Spacecake has quit [Changing host]
Hail_Spacecake has joined #yosys
fouric has joined #yosys
[X-Scale] has joined #yosys
X-Scale has quit [Ping timeout: 272 seconds]
[X-Scale] is now known as X-Scale
maikmerten has quit [Remote host closed the connection]
develonepi3 has quit [Remote host closed the connection]
develonepi3 has joined #yosys
AlexDaniel has quit [Read error: Connection reset by peer]