#milkymist IRC log for Wednesday, 2013-09-18

lekernelthis is from a xilinx appnote: http://pastebin.com/PALtwn3B14:14
lekernelyes, "assign mdatain = datain;" would work just as well14: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 viewers14:17
davidc___(or because they don't know how nonblocking assignments work)14:17
lekerneljudging from the general quality of this appnote, I'd rather believe the latter theory14:18
lekernelfrom the same talented author, this 4-bit counter is also worth seeing: http://pastebin.com/AvKiEkNZ14:19
davidc___ps lekernel - the current SyncFIFO impl definitely won't map to BRAMs in an s614:21
davidc___or at least won't in the situations I've tried14:21
wpwrakthat's why gigabyte-sized memories were invented. so that we can count to 32 bits and some day even beyond.14:22
lekerneldavidc___, ok, feel free to send a patch. I haven't used sync FIFOs so large that this would become a problem.14:23
lekerneldavidc___, 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 before14:25
davidc___lekernel: I'll add a bypass path (for latency=1) and resubmit14:25
lekernelok. but we can't increase FIFO latency, one needs to be radical about performance when targeting slowtan614: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 world14:28
davidc___I haven't had to resort to laying out manually LOC'ed LUTS/PRIMS once yet this design!14:28
lekernelthey're horribly sluggish compared to what nvidia does14:28
lekernelperiod :)14:28
davidc___lekernel: er compared to nvidia GPU ASICs? :)14:29
lekerneleven the s6 hard blocks are slow... look at the SERDES14:29
lekernelnvidia GPU can use DRAM at 5Gbps/pin14:29
GitHub26[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/n_IvVg14:59
GitHub26milkymist-ng/master ea05031 Sebastien Bourdeauducq: add DVI output14:59
lekernelyay, digital video out through the DVI port works now15:15
lekernelI can't believe this board doesn't seem to need any green wire15:15
GitHub54[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/K5KAbw15:17
GitHub54milkymist-ng/master 1672c4a Sebastien Bourdeauducq: framebuffer/dvi: minor fixes15:17
davidc___lekernel: don't jix it ;)15:23
davidc___lekernel: Also, I think the SyncFifo could be 0-cycle-latency if you wanted15:24
davidc___lekernel: if that'd help performance15: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/we15:25
davidc___(dunno whether the comb logic that uses the FIFOs is safe with that though)15:25
lekernelit would functionally work, but not meet timing15:27
davidc___Yup; definitely stretches out the timing path.15:28
lekernel_it would functionally work, but not meet timing15:29
lekernel_in fact, the only reason why I have inserted the FIFOs in the SDRAM controller is to break long timing paths15:29
davidc___lekernel_: gotcha. Any bypass would bring those paths back again, so it pretty much _has_ to be an async-read15: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 bypass15:34
lekernel_you only need a mux in the output15:34
lekernel_and all that mux's inputs can be outputs of registers15:34
lekernel_directly15:34
lekernel_in case there are still difficulties meeting timing with that mux, a tuning parameter would be welcome indeed15:35
lekernel_but if timing works, then KISS15:35
lekernel_and YAGNI15:36
--- Thu Sep 19 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!