Sunday, 2016-05-22

*** tpb has joined #timvideos00:00
CarlFKmithro: I have been running the latest firmware, and it seems about the same as the other versions00:30
CarlFKand.. it seems good enough to use.00:30
*** Bertl is now known as Bertl_zZ01:19
*** sb0 has joined #timvideos02:12
*** sb0 has quit IRC02:13
mithroCarlFK: On the Opsis or the Atlys?03:20
mithro_florent_: ping me when you are around03:20
mithrotumbleweed: ping?03:23
CarlFKmithro: Opsis04:57
mithroCarlFK: does the same version work on the Atlys?04:57
mithroCarlFK: can you get me the full output of "version"?04:59
tpbTitle: Ubuntu Pastebin (at
CarlFKjust a min, Ill check the Atlys05:00
mithrocr1901_modern: you wouldn't happen to be about?05:19
CarlFKmithro: Memtest failed: 532731/532736 words incorrect05:51
CarlFKBIOS> romboot ...   git describe: v0.0.0-699-gb505665-dirty05:52
tpbTitle: Ubuntu Pastebin (at
CarlFKmithro: input0:  0x0 - but something is hooked up05:59
CarlFKHDMI2USB>m 906:01
CarlFKSetting video mode to 1280x720 @60Hz06:01
CarlFKit didn't come back06:01
CarlFKmithro: I need to get to bed.  and wake up, pack and be on a flight in 8 hours06:04
CarlFKoh great.  powercycle, load ... romboot.. displays version info and doesnt'  take me to a prompt06:10
CarlFKpowercycle, load ... romboot now I am at a prompt06:10
CarlFKoh well... I have a show to do.. this is my backup :p06:10
cr1901_modernmithro: Kinda around. Just woke up lol... what's up?06:53
mithrocr1901_modern: where are you at with that counter? Have you uploaded something that I could look at?06:54
cr1901_modernSure, I can upload something for you to play with. But I haven't attached it to any HDMI devices yet.06:55
cr1901_modernall I've done thus far is generate a high freq signal on one board and feed it to another, and then check it in the MIgen BIOS06:55
cr1901_modernmithro: Proof it does work :P
mithrocr1901_modern: uploading would be good06:57
cr1901_modernmithro: Give me 10 minutes please... just realized I never actually checked whether it works in HDMI2USB (it should, but I should check). Building a core takes about 4 minutes, so that should give me time if I screwed up.07:02
cr1901_modernmithro: Want me to upload a git format-patch instead of forking HDMI2USB so you can "just apply it" and test things out?07:05
mithroA git repo on github would be good07:05
*** ssk1328 has joined #timvideos07:13
cr1901_modernThis doesn't make sense... "Unresolved clock domain: sys" Gah!07:20
mithroHi ssk132807:22
ssk1328mithro: Hi07:23
mithrossk1328: so, you had a bunch of questions07:23
mithrossk1328: I'd also like to chat about what you are working on and better ways to get started07:23
ssk1328Yeah sure07:24
ssk1328Past few days have been a bit slow07:24
ssk1328So I am trying to figure out how the firmware C code works07:24
ssk1328I started with hdmi_in07:24
mithrossk1328: so, the best way to do something like "figure out how the firmware C code works" is to have some goal you are trying to achieve07:24
mithrossk1328: Just "reading code" tends to be pretty unhelpful and easy to get distracted07:25
ssk1328Yeah so my goal was to understand where exactly the linear mixer block will fit in this07:25
ssk1328So I figured out that, hdmi_in and pattern stores the pixel value in predefined memory locations07:26
mithrossk1328: I think that might be quite a big challenge to start with, I'd recommend trying something a lot simpler07:26
ssk1328What do you recommend?07:27
mithrossk1328: Where you working on the heart beat pixel thing?07:27
ssk1328Yeah, I was but haven't been looking in that now07:27
mithrossk1328: I think having a very simple goal like doing that would be a good way to get familiar with the firmware07:28
ssk1328But then again I need to figure the some parts of the code07:29
mithrossk1328: but you can ignore a lot of the code now07:29
ssk1328Yeah, there is a lot of timing stufff that tends to go over my head07:29
mithrossk1328: what you are looking for now is code which gets triggered when an output device needs a new frame of data07:30
ssk1328I guess hdmi_out is for that job07:31
cr1901_modernmithro: When I attempt to use my code in HMDI2USB, I'm getting a weird clock domain error that didn't exist previously (despite same source, just different imports). Debugging now07:31
mithrocr1901_modern: just upload something that isn't working07:32
mithrocr1901_modern: then fix it :P07:32
ssk1328mithro: Also hdmi_out uses i2c functions to write to output hdmi device, I was confused about where exactly is this pixel data for output stored07:35
mithrossk1328: For HDMI output, the I2C isn't really used07:36
mithrossk1328: I2C is used for reading / providing configuration information07:36
ssk1328Ohh, okay07:36
mithroThis whole system could in theory work without any I2C stuff at all (but it wouldn't be Plug-n-Plug)07:37
mithrossk1328: ideally on a HDMI output, we should use I2C to read the data from the monitor and check that we are going to send it compatible data07:38
ssk1328I was actually trying to find the part of code that takes pixel data from memory say 0x01000000 for hdmi_in, and takes it to hdmi_out07:38
mithrossk1328: currently we just assume that monitor is going to work :P07:38
*** rohitksingh has joined #timvideos07:39
mithrossk1328: so, I believe (but you should check) there is a DMA hardware block which will read the data from the memory and send it to the hdmi_out core07:40
mithrossk1328: have you seen ?07:40
tpbTitle: HDMI2USB-misoc-firmware/architecture.png at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
ssk1328Yeah, a lot of times actually07:40
mithrossk1328: Do you know what a DMA engine is / does?07:41
ssk1328guessed direct memory access according to full form07:42
ssk1328Not in detailed07:42
mithroA DMA engine is basically something which read from location X and then writes it to location Y07:43
mithroNormally after reading from location X and writing to location Y it will then increment one or the other location07:44
mithrothe locations are also sometimes "internal" to the DMA engine and not exposed07:44
ssk1328Is the function of dma identical at hdmi_in and hdmi_out locations in our case07:46
mithroA generic DMA engine can frequently be used to copy memory from one location to another memory location without the CPU having to be involved07:46
mithrossk1328: I'm unsure, I know a lot more of the theory than how our system is actually implemented07:46
cr1901_modernmithro: Look at this repo for changes. Right now, I've only uploaded the code I used for testing07:47
tpbTitle: GitHub - cr1901/freq_count: Migen/MiSoC frequency counter, based on ideas from (at
ssk1328Point out if I am wrong, in our case cpu is involved in hdmi_in case for storing at appropriate locations, but not in hdmi_out and dma engine directly completes the task07:48
cr1901_modernmithro: Note that this uses the new Migen API- this is deliberate forwards compatibility :P (read: I developed this out-of-tree and I only have the new Migen API installed globally)07:49
ssk1328mithro: I just readabout dma, cpu might be involved in initiating the memory transfer, and in the actual memory transfer cpu is not involved resulting in freeing of cpu resources.07:56
mithrossk1328: no, in both the HDMI in and HDMI out case the CPU just "sets up the memory transfer"07:56
ssk1328mithro: So my question is which function in the C firmware sets up the memory transfer for HDMI_OUT07:58
cr1901_modernmithro: How to use the frequency counter (this step is independent of Migen version):
tpbTitle: freq_count/ at master · cr1901/freq_count · GitHub (at
mithrossk1328: so, what do you think you are looking for?07:59
cr1901_modernLine 36 is the part that fails when I try to put it into the HDMI2USB tree. I don't have a good reason why it shouldn't (kinda afk)08:00
cr1901_modernshould* be failing08:00
ssk1328mithro: So for the heartbeat thing I need to know, that the pixel I am copying is from which location of the image. (Because I need to change pixel values of some pixels in bottom right corer to beating red).08:04
mithrossk1328: let's start with changing any pixel and then go with trying to figure out the bottom right corner08:04
tumbleweedmithro: pong08:04
mithrotumbleweed: so, I saw a lot of mention about SDI in the debconf-video channel08:05
*** rohitksingh has quit IRC08:05
mithrotumbleweed: I'm pretty sure that SDI is the wrong solution to your problems08:06
ssk1328mithro: Yeah, lets start with that. How exactly can I do that using the C code?08:06
tumbleweedmithro: it seems to be the most convenient way to do vocto with the least number of computers (long SDI cable runs are easy)08:07
mithrotumbleweed: actually, "long SDI cable runs are easy" is going to bite you08:08
mithrotumbleweed: my biggest question is, "when the SDI cable doesn't work, what do you do?"08:08
cr1901_modernnot "if" :P?08:09
tumbleweedwhat kind of failure mode are you talking about?08:09
mithrotumbleweed: you plug in the SDI cable and things are not working08:09
tumbleweeddoesn't that eually apply to any other connection?08:09
mithrotumbleweed: well, if you were using Ethernet / Cat 5, I'm sure you have the ability to do some type of diagnostics08:10
*** rohitksingh has joined #timvideos08:11
mithrotumbleweed: also, at the last minute if you don't have enough SDI cables - can you get more quickly?08:12
tumbleweedmithro: for a physical cable, you can do similar diagnostics on coax. You just might not have the right gear at hand08:12
mithrotumbleweed: yeah, if you were a professional you'd have a "SDI cable tester" or something08:12
tumbleweedthey're easy enough to make up, too - with the right crimper08:12
tumbleweedso, yes, at that level, cat 5e is easier08:13
tumbleweedbut every camera with internet will do it differently08:13
*** Bertl_zZ is now known as Bertl08:13
tumbleweedand we haven't bought any such cameras, yet08:13
tumbleweederr with ethernet, not with internet :P08:13
mithrotumbleweed: any camera you have can be converted to a "ethernet camera" with a computer, right?08:14
*** rohitksingh1 has joined #timvideos08:14
tumbleweedyes, but then we've got to transport more gear around08:14
tumbleweedwe have cameras with SDI08:14
tumbleweedand CCC is reporting great success with SDI08:14
tumbleweedso, we're giving it a shot08:14
*** rohitksingh has quit IRC08:15
mithrotumbleweed: The CCC has a bit more access to stuff than the rest of us08:15
tumbleweedand if, given that, they selected SDI, doesn't that inspire any confidence in it being a reasonable approach?08:16
tumbleweedif long SDI cable runs are easy (and I agree, we don't know that ourselves, yet) then SDI has the advantage of ubiquitous cameras, and the possibility of only needing one computer per room08:18
tumbleweedwe have to ship our gear to every event, so the less we ship, the cheaper08:18
tumbleweed(and the less computers to go wrong, the easier)08:18
mithrotumbleweed: 30m SDI cables are a lot heavier than small computers08:19
tumbleweedright, but you can make those up on site, too08:19
tumbleweedHDMI2Ethernet would also fit our needs very well08:19
mithrotumbleweed: then you run into the problem is that you need to be reasonably sure that the cables you make don't suck :P08:19
tumbleweedand I suspect SDI cables wolud go missing from our equipment less frequently than laptops :P08:20
mithrotumbleweed: Have a chat with network guys about how much dodgy cables cause them issues :P08:20
tumbleweedright now, we're reasonably sure that all our firewire cables suck08:21
mithrotumbleweed: If you are shipping SDI cables, your cost argument doesn't really make sense. If you are making the cables onsite then you are going to need some good diagnostic tools.08:21
ssk1328mithro: So for changing any pixel, for example in the pattern.c file there is framebuffer variable which stores all the pixel values, while copying the pixel values to this variable we can make appropriate changes. Is this correct?08:22
tumbleweedI'm not convinced the diagnostic tools are required - but I also have no experience with these, yet08:22
mithrotumbleweed: I'm pretty sure that SDI cables are not an order of magnitude more reliable than Ethernet cables of similar length08:24
tumbleweedand I find ethernet cables to be pretty reliable08:25
tumbleweedif there's aproblem, it's usually immediately obvious08:25
mithrotumbleweed: so, I'm just going off experience with long Ethernet cables at conferences like LCA08:25
tumbleweedand fixed by a recrimp or two08:25
mithrotumbleweed: so, it's too late for the next debconf08:25
tumbleweedI've never needed the fancy ethernet cable testers08:26
tumbleweedjust successfully negotiating gigabit is usually a pretty good sign that the cable is fine08:26
tumbleweedand the basic continuity testers seem good enough, too08:27
mithrossk1328: I'm not sure I understand08:27
mithrotumbleweed: but my general argument is that "Ethernet is cheap, ubiquitous and well understood by everyone" verse "SDI is expensive and only understood by a small number of people"08:27
tumbleweedmithro: yep, but getting the video onto ethernet adds complexity08:28
tumbleweedI'd much prefer ethernet to SDI, but until you can plug ethernet into the camera, you can't directly compare them08:29
mithrotumbleweed: I think you guys are trading a known set of complexity for an unknown one08:30
tumbleweedwe are08:30
mithrotumbleweed: Why? You must believe the unknown one is significantly less effort than the known one?08:30
tumbleweedthere are unknowns on both sides08:31
tumbleweedyou're jsut talking about one component of the stack08:31
tumbleweedbut that defines bits of the rest of the stack, nad there are unknowns there too08:31
tumbleweedso, if you use ethernet for your long runs08:32
ssk1328mithro: So what I am trying to do is change pixel values while copying pixel data from hdmi input to output. Now if we select pattern as the source for lets say hdmi_out0, the pattern.c file is storing appropriate pixel values in framebuffer variable. So if am able to change pixel values of the variable framebuffer this can do the job. Correct? (Why I am08:32
ssk1328talking about pattern as source here instead of hdmi_in is because I figured out the framebuffer variable defined in pattern.c file)08:32
tumbleweedyou have to capture video from the camera08:32
tumbleweedthat means HDMI->SDI + blackmagic or HDMI into blackmagic or SDI into blackmagic08:33
tumbleweedor HD firewire (ick)08:33
tumbleweedor opsis, which we don't have enough of, and can't do audio08:34
mithrossk1328: okay, yes that is correct08:34
ssk1328mithro: So on the similar lines I can do the same for hdmi_in as well. Correct?08:37
mithrossk1328: so, somewhere in the code it is telling the hdmi_out to use the pattern frame buffer as the source, right?08:38
mithrossk1328: find that first08:38
ssk1328mithro: But there is not explicit framebuffer variable in hdmi_in files, so I was not sure how to do this for hdmi_in08:38
tumbleweedmithro: oh, and multiple HD streams into the mixing computer quickly gets bigger than a gigabit NIC can handle, so you either need multiple ones, or a 10gig NIC + switch in the room08:38
mithrotumbleweed: you are currently doing a blackmagic card per SDI stream?08:39
ssk1328mithro: Yeah I found that  in the main.c file.08:39
ssk1328#ifdef CSR_HDMI_OUT0_BASE08:39
tumbleweedmithro: you say currently - this is going to be the first time we've ever done it :P08:39
mithrossk1328: nope!08:40
tumbleweedbut yes, that'd be the plan08:40
mithrotumbleweed: How is that different than a Gigabit Ethernet card per stream?08:40
tumbleweedmore complexity08:40
mithrotumbleweed: SDI card == horrible complex and poorly understood   verse   gigabit ethernet card == extremely simple and well understood08:44
tumbleweedmithro: right, but you aren't advocating dropping the SDI cards08:44
tumbleweedyou're advocating moving them closer to the cameras08:44
tumbleweedwe still have to *capture* from the cameras08:44
ssk1328mithro: Going for lunch, will be back in 30 mins or so.08:44
mithrossk1328: I probably won't be around then08:45
ssk1328Later today?08:45
mithrossk1328: probably not08:45
ssk1328mithro: Okay, just point me to the right file for above. I suppose processor.c might be used for that.08:47
mithrossk1328: what does that function do?08:48
mithrotumbleweed: you can already capture from these cameras, right?08:49
tumbleweedwhat does that question mean?08:50
tumbleweedwe currently capture over firewire, into dvswitch. We want to leave all of that behind08:50
mithrotumbleweed: so currently you go "Camera ---Firewire--> dvgrab ---Ethernet---> dvswitch" right?08:51
ssk1328mithro: The function processor_update sets the source for each of the hdmi_out as per the various CSRs.08:52
tumbleweedmithro: yep08:52
tumbleweedskipping the ethernet for the camera by the mixing desk08:52
mithrotumbleweed: so, first step - replace dvgrab+dvswitch with voctomix ?08:53
mithrossk1328: that function is one line - take a look at
tpbTitle: HDMI2USB-misoc-firmware/processor.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
tumbleweedmithro: right, but you want HD, if your cameras are capable of it. And you don't want to use hdv over firewire, because hd over firewire is already too unreliable for us08:55
mithrotumbleweed: well, first you want to get video over not getting any video :)08:55
tumbleweedfirewire has that undebuggable quality you describe08:55
mithroHDMI also has that quality I describe for the moment08:56
mithroI'm actually currently working on making that less so right now08:56
ssk1328mithro: Okay I understand this. But this just sets the source for hdmi_out0.08:56
ssk1328mithro: Which part of the code copies pixel data from source to hdmi_out008:57
mithrossk1328: it sets a single variable to an int value, so next thing is to figure out where that value is used08:57
ssk1328In the processor_update function08:58
tpbTitle: HDMI2USB-misoc-firmware/processor.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
mithrossk1328: okay, follow that down09:00
ssk1328Things seem to be clearing up now.09:00
mithrossk1328: you know how to use grep, right?09:03
ssk1328Haven't used before :( I am using ctrl+f in each file to find the specific instances of a particular function or variable09:04
mithrossk1328: you should learn grep09:04
mithrossk1328: otherwise you will never find where "hdmi_out0_fi_base0_write" is defined09:05
ssk1328Sure thing.09:05
mithrogrep -R "hdmi_out0_fi_base0_write" .09:05
ssk1328Can't test that right now, I am on windows, my Ubuntu is overheating and randomly shuts down the laptop. But will surely check that out.09:08
ssk1328One more thing, why the multiplication with 2 here,
tpbTitle: HDMI2USB-misoc-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
mithrossk1328: how big is a pixel?09:09
ssk13283*8bit values = 24 bit per pixel?09:10
*** G33KatWork has quit IRC09:10
mithrossk1328: in RGB with 8bits per pixel09:11
*** G33KatWork has joined #timvideos09:12
ssk1328mithro: I guess this is different for YCbCr09:12
mithrossk1328: yeah09:13
tpbTitle: HDMI2USB-misoc-firmware/gateware/csc at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
ssk1328Okay, will figure that out.09:15
tpbTitle: HDMI2USB-misoc-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
ssk1328Any significance of number 4 here09:16
ssk1328I understand this defines we can store 4 frames of 1920*108009:16
mithrossk1328: that I'm unsure of09:17
mithrossk1328: I think because you have 3 potential outputs09:17
mithrossk1328: each output could have a frame buffer "locked" so you need one more buffer to write into09:18
mithrossk1328: but I could be totally wrong there09:18
ssk1328mithro: The 3 potential output you talk about is Y, Cb and Cr. Correct?09:19
mithrossk1328: no09:19
mithrossk1328: hdmi_out0, hdmi_out1, encoder09:19
ssk1328mithro: Okay. So the fourth one might be just an extra, for us to add more outputs09:20
ssk1328Or extra buffer for the new frame inputs arriving.09:21
mithrossk1328: you might want to look at and
tpbTitle: HDMI2USB-misoc-firmware/ at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
mithrossk1328: the second one I think09:21
mithrossk1328: as you don't want to modify a frame while it is being output09:22
mithrossk1328: and which I've actually been working on today09:22
tpbTitle: tmds_encoding/ at master · mithro/tmds_encoding · GitHub (at
ssk1328mithro: Will look into all this today.09:24
mithrossk1328: so, it looks like there might not be a trigger on the hdmi output in the C code09:26
ssk1328mithro: I guess so09:28
mithrossk1328: but there is one for the HDMI input you just saw, right?09:28
ssk1328trigger as in something which initiates the HDMI input code?09:30
mithrossk1328: you pointed me to
tpbTitle: HDMI2USB-misoc-firmware/hdmi_in0.c at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at
mithrossk1328: see the hdmi_in0_isr09:32
ssk1328mithro: Okay, so the trigger is the calling of hdmi_in0_isr function09:35
ssk1328and function later call the processor_update function which connects the output to specific input09:36
*** se6astian|away is now known as se6astian09:43
mithrossk1328: what do you mean by "trigger"?09:43
mithrossk1328: when you make a statement, make sure you have some proof to back it up :)09:43
ssk1328mithro: be back in 10mins09:45
_florent_mithro: sorry, I'm there now10:07
mithro_florent_: Couple of questions10:42
mithro_florent_: (a) Where are we at with "porting to the new migen/misoc" (and what do we actually mean by that?)10:43
mithro_florent_: (b) What state is liteDRAM in and can you help me fill in some remaining stats in my spreadsheet at
tpbTitle: lite* Supported boards & Interfaces - Google Sheets (at
mithro_florent_: (c) I have code which should generate a "hdmi bit stream" from pixel data - how should we hook that up to the simulator / use it to test the HDMI module?10:46
mithro_florent_: (d) I'm assuming that we haven't made any progress on the HDMI over GTP situation10:47
cr1901_modernmithro: I'm not florent, but... I can give some insight (a). Porting to the new migen SHOULD be as simple as changing imports. It's porting to the new MiSoC that I suspect is more difficult, b/c the way that targets are build was completely overhauled.10:52
mithrocr1901_modern: Yes, it's more complicated - _florent_ has been doing some work on it10:52
cr1901_modernThe problem is that a lot of stuff in the old migen got moved to the new misoc, so it's kinda tightly coupled :/10:52
cr1901_modernI'm happy to help _florent_ work on this in the interim if it'll expediate the process10:54
cr1901_modernexpedite* bleh10:54
mithrossk1328: any last questions before I go in search for dinner?10:56
_florent_mithro: (a) I think it was alsmost done (opsis-soc was working), I started some refactoring around others things (LiteDRAM, LiteVideo) that I have to finish, going to work on that today10:56
mithro_florent_: That doesn't include the Atlys board though, right?10:57
mithro_florent_: (nor the miniSpartan6+)?10:57
_florent_mithro: (b) LiteDRAM is working, I just want to add asynchronous and variable width ports and then use it in the HDMI2USB design (would avoid doing that for each DRAM port we use)10:58
_florent_mithro: (a) yes only opsis now, I'd like to get some help maintaining others targets if possible once opsis will be working10:58
mithro_florent_: When you say "LiteDRAM is working" - obviously you haven't tested on an Atlys recently because you destroyed yours, right?10:59
_florent_It's working on Opsis/Nexys/Arty/KC705, I don't think there will be problem with Atlys10:59
_florent_but yes, while porting to new API, we have to revalidate everything with incremental steps11:00
mithro_florent_: with liteDRAM you were mentioning adding a whole bunch more tests?11:01
_florent_yes going to do that too11:01
_florent_it just takes a bit of time :)11:02
mithro_florent_: going too, or have already?11:02
_florent_I already rewritten the DMA Generator/Checker11:02
_florent_now I need to improve it11:02
_florent_and create more complex tests11:02
_florent_(c) for HDMI in simulation, you can try hacking code here:
mithro_florent_: does it make sense to use the micron DDR models in verilator running setup and then memtest like operations?11:03
tpbTitle: litex/dut_tb.cpp at master · enjoy-digital/litex · GitHub (at
_florent_it's for vga and can be probably be adapted for HDMI11:03
mithro_florent_: this is input rather than output, but I guess I also have output code too11:04
_florent_mithro: for input yes it would be a bit similar11:05
_florent_mithro: for serial and ethernet we are doing input11:05
_florent_mithro (d): no, not yet11:06
mithro_florent_: this is kind of where I'm at with the tmds_encoding ->
tpbTitle: tmds_encoding/vga.h at master · mithro/tmds_encoding · GitHub (at
mithro_florent_: I use some Python code to generate a lookup table - means it should be pretty fast11:09
*** rohitksingh1 has quit IRC11:10
*** rohitksingh has joined #timvideos11:11
mithro_florent_: for (b) - I'd like to fill in all the red squares11:14
mithro_florent_: so, for (a) - what are our next steps?11:15
mithrossk1328: btw - Did you see ?11:16
tpbTitle: LibreCores (at
mithro_florent_: BTW Any idea how to the memory on a Zynq is connected up / how the FPGA can access it?11:17
_florent_mithro: on the Zynq you memory is connected through AXI11:28
_florent_mithro: for (b), ok I'll have a look11:28
_florent_mithro: for (a) I'm going to work on this afternoon, but I'm going to lunch, see you later11:29
*** rohitksingh has quit IRC11:41
*** rohitksingh has joined #timvideos12:13
*** CarlFK has quit IRC12:33
*** ssk1328 has quit IRC12:33
*** se6astian is now known as se6astian|away12:55
*** Bertl is now known as Bertl_oO14:14
*** rohitksingh has quit IRC14:33
*** sb0 has joined #timvideos14:47
*** rohitksingh has joined #timvideos15:37
*** rohitksingh has quit IRC16:56
*** rohitksingh has joined #timvideos17:07
*** se6astian|away is now known as se6astian17:23
*** rohitksingh has quit IRC17:27
*** rohitksingh has joined #timvideos18:03
*** rohitksingh has quit IRC18:20
*** ssk1328 has joined #timvideos18:21
*** kaalikahn has quit IRC18:37
*** tariq786 has joined #timvideos18:42
*** rohitksingh has joined #timvideos19:11
*** rohitksingh has quit IRC19:14
ssk1328mithro: Will be back with few more questions tomorrow. Haven't heard of this competition though, can I submit my gsoc designs for the competition?20:32
*** sb0 has quit IRC20:38
*** puck has joined #timvideos21:03
*** se6astian is now known as se6astian|away21:22
*** Bertl_oO is now known as Bertl_zZ23:12
*** ssk1328 has quit IRC23:23

Generated by 2.13.1 by Marius Gedminas - find it at!