| sh4rm4 | "Prices for ABAX chips range from $105 to $200 in 1,000 unit quantities." http://www.bdti.com/InsideDSP/2010/03/18/Tabula | 02:09 |
|---|---|---|
| lekernel | sh4rm4, hum, that's a 2010 article. they weren't shipping by then. | 10:28 |
| lekernel | but this looks surprisingly cheap | 10:29 |
| lekernel | hehe, running at 1024*768 32bpp with only 256 pixels buffered on-chip | 17:09 |
| lekernel | the old soc required thousands for doing the same at 16bpp | 17:09 |
| lekernel | I'm sure we can do 1080p if the 140MHz DAC accepts being overclocked to 148.5 | 17:10 |
| lekernel | let me try tha | 17:10 |
| lekernel | t | 17:10 |
| lekernel | yeh, the old soc has 1024 pixels buffered for coping with half the bandwidth milkymist-ng does with a 256-deep buffer | 17:13 |
| wpwrak | the buffering is for the burstiness of the transfer from RAM ? | 17:22 |
| lekernel | yes | 17:23 |
| lekernel | and when DRAM has to deal with other requests (CPU etc.) | 17:23 |
| lekernel | milkymist-ng lets you queue several commands into the DRAM controller with dedicated slots (not just one and with arbitration like the old SoC), so it handles better the loads | 17:26 |
| lekernel | it reorders the pending requests to improve page hit rate and reduce read/write turnaround, too | 17:27 |
| wpwrak | so you're now in the < 7 us delay range | 17:27 |
| lekernel | and DRAM is run at 2x the system clock rate | 17:27 |
| wpwrak | ah no, < 2 us even | 17:28 |
| lekernel | the controller can issue both a precharge/activate and a read/write command to another bank in the same cycle | 17:28 |
| lekernel | (system cycle) | 17:28 |
| wpwrak | so this is not only higher bandwidth for linear transfers but also faster switching between banks ? | 17:29 |
| lekernel | so you can have up to 133 million DRAM commands per second on a slowtan6 that can only meet system timing at 83MHz | 17:29 |
| lekernel | yes | 17:29 |
| lekernel | later I'll want to do the same thing with a more serious FPGA and DDR3-1600 or so. it's just multiplying numbers, keeping the same arch. | 17:30 |
| wpwrak | how is stability ? have you done any long-running torture-testing yet ? | 17:31 |
| lekernel | not as much testing as the old controller... actually I want to at least try 1080p as a test before sending the bug-ridden HDMI data to DRAM | 17:32 |
| lekernel | I wrote a traffic generator for the old controller and tested it with dozens of terabytes of data, but I have not ported it | 17:33 |
| wpwrak | yeah, the old one was good. i think it never gave us any trouble. so your methodology appears to work :) | 17:40 |
| GitHub63 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/9u706Q | 18:08 |
| GitHub63 | milkymist-ng/master 8fd092c Sebastien Bourdeauducq: crg: support VGA pixel clock reprogramming | 18:08 |
| GitHub69 | [misp] sbourdeauducq pushed 1 new commit to master: http://git.io/x3U-gw | 18:09 |
| GitHub69 | misp/master 9a7c3d9 Sebastien Bourdeauducq: agg_test: 1024x768 demo | 18:09 |
| GitHub150 | [milkymist-ng] sbourdeauducq pushed 3 new commits to master: http://git.io/a97djA | 19:47 |
| GitHub150 | milkymist-ng/master b603eaf Sebastien Bourdeauducq: m1crg: allow up to 150MHz pixel clock | 19:47 |
| GitHub150 | milkymist-ng/master 4dcec32 Sebastien Bourdeauducq: top: allocate one more ASMI port to framebuffer | 19:47 |
| GitHub150 | milkymist-ng/master 854c046 Sebastien Bourdeauducq: framebuffer: process two pixels per system clock cycle | 19:47 |
| lekernel | grmbl 148.25Mhz pixel clock | 19:50 |
| lekernel | = 50*593/200 | 19:50 |
| lekernel | what a mess | 19:50 |
| lekernel | let's hope 148 works | 19:51 |
| larsc | should work | 19:51 |
| lekernel | yay, it works! | 20:43 |
| Fallenou | so you got 1080p framebuffer ? :) | 20:59 |
| --- Fri Mar 29 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!