| lekernel | this is from a xilinx appnote: http://pastebin.com/PALtwn3B | 14:14 |
|---|---|---|
| lekernel | yes, "assign mdatain = datain;" would work just as well | 14:15 |
| lekernel | (the same appnote uses "=" for interblock communcation and "<=#1" in many synchronous assignments ...) | 14:15 |
| davidc___ | lekernel: some people do the rediculous <=#1 so it looks pretty on their waveform viewers | 14:17 |
| davidc___ | (or because they don't know how nonblocking assignments work) | 14:17 |
| lekernel | judging from the general quality of this appnote, I'd rather believe the latter theory | 14:18 |
| lekernel | from the same talented author, this 4-bit counter is also worth seeing: http://pastebin.com/AvKiEkNZ | 14:19 |
| davidc___ | ps lekernel - the current SyncFIFO impl definitely won't map to BRAMs in an s6 | 14:21 |
| davidc___ | or at least won't in the situations I've tried | 14:21 |
| wpwrak | that's why gigabyte-sized memories were invented. so that we can count to 32 bits and some day even beyond. | 14:22 |
| lekernel | davidc___, ok, feel free to send a patch. I haven't used sync FIFOs so large that this would become a problem. | 14:23 |
| lekernel | davidc___, and you know that Xst only attempts to use BRAM beyond a certain memory size, right? | 14:24 |
| davidc___ | lekernel: 4kbyte fifo :) | 14:24 |
| davidc___ | lekernel: It maps to BRAM fine as an asyncfifo, or with that interlock patch from before | 14:25 |
| davidc___ | lekernel: I'll add a bypass path (for latency=1) and resubmit | 14:25 |
| lekernel | ok. but we can't increase FIFO latency, one needs to be radical about performance when targeting slowtan6 | 14:25 |
| davidc___ | yeah, a bypass will do the trick.. and pfft.. S6's are so much faster than S3s... its like living in a dream world | 14:28 |
| davidc___ | I haven't had to resort to laying out manually LOC'ed LUTS/PRIMS once yet this design! | 14:28 |
| lekernel | they're horribly sluggish compared to what nvidia does | 14:28 |
| lekernel | period :) | 14:28 |
| davidc___ | lekernel: er compared to nvidia GPU ASICs? :) | 14:29 |
| lekernel | even the s6 hard blocks are slow... look at the SERDES | 14:29 |
| lekernel | nvidia GPU can use DRAM at 5Gbps/pin | 14:29 |
| GitHub26 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/n_IvVg | 14:59 |
| GitHub26 | milkymist-ng/master ea05031 Sebastien Bourdeauducq: add DVI output | 14:59 |
| lekernel | yay, digital video out through the DVI port works now | 15:15 |
| lekernel | I can't believe this board doesn't seem to need any green wire | 15:15 |
| GitHub54 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/K5KAbw | 15:17 |
| GitHub54 | milkymist-ng/master 1672c4a Sebastien Bourdeauducq: framebuffer/dvi: minor fixes | 15:17 |
| davidc___ | lekernel: don't jix it ;) | 15:23 |
| davidc___ | lekernel: Also, I think the SyncFifo could be 0-cycle-latency if you wanted | 15:24 |
| davidc___ | lekernel: if that'd help performance | 15:24 |
| davidc___ | (right now it's one - sync write to SDRAM, ASYNC read) | 15:24 |
| davidc___ | when level == 0 you can just connect din to dout and cross-connect writable/re readable/we | 15:25 |
| davidc___ | (dunno whether the comb logic that uses the FIFOs is safe with that though) | 15:25 |
| lekernel | it would functionally work, but not meet timing | 15:27 |
| davidc___ | Yup; definitely stretches out the timing path. | 15:28 |
| lekernel_ | it would functionally work, but not meet timing | 15:29 |
| lekernel_ | in fact, the only reason why I have inserted the FIFOs in the SDRAM controller is to break long timing paths | 15:29 |
| davidc___ | lekernel_: gotcha. Any bypass would bring those paths back again, so it pretty much _has_ to be an async-read | 15:33 |
| davidc___ | (IE, no brams). | 15:34 |
| davidc___ | Would a tuning parameter for the SyncFIFO be ok? | 15:34 |
| lekernel_ | no, you can register after the bypass | 15:34 |
| lekernel_ | you only need a mux in the output | 15:34 |
| lekernel_ | and all that mux's inputs can be outputs of registers | 15:34 |
| lekernel_ | directly | 15:34 |
| lekernel_ | in case there are still difficulties meeting timing with that mux, a tuning parameter would be welcome indeed | 15:35 |
| lekernel_ | but if timing works, then KISS | 15:35 |
| lekernel_ | and YAGNI | 15:36 |
| --- Thu Sep 19 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!