| *** tpb has joined #timvideos | 00:00 | |
| *** CarlFK has joined #timvideos | 00:27 | |
| *** ChanServ sets mode: +v CarlFK | 00:27 | |
| *** CarlFK has quit IRC | 00:29 | |
| *** CarlFK has joined #timvideos | 00:29 | |
| *** ChanServ sets mode: +v CarlFK | 00:29 | |
| micolous | aps: I submitted it in a branch, and you have to manually select the template | 01:21 |
|---|---|---|
| *** Niharika has joined #timvideos | 03:31 | |
| cfelton | mithro: ping | 03:42 |
| mithro | cfelton: pong | 03:43 |
| mithro | I need to add a ~time operation to tpb | 03:43 |
| cfelton | hola how is your wednesday(?) | 03:43 |
| mithro | not too bad | 03:44 |
| mithro | Finally landed a patch today which was ~3 weeks worth of work | 03:44 |
| cfelton | also nice to complete a task | 03:45 |
| cfelton | "always" I meant | 03:45 |
| mithro | so, I wanted to chat about stuff we were chatting about in email, I figured IRC would have a quicker round trip time | 03:46 |
| cfelton | sounds good, let me grab a stiff drink and we can start :) | 03:47 |
| cfelton | is there a particular topic, or the whole shebang | 03:48 |
| mithro | whole shebang I guess | 03:48 |
| mithro | cfelton: I particularly wanted to chat about your hyperion project and how to make MyHDL "take off" | 03:49 |
| cfelton | me too! | 03:52 |
| mithro | I'd also like to talk a bit more about where I see the HDMI2USB stuff going and where I'd like to be this time next year | 03:52 |
| cfelton | ok, | 03:54 |
| mithro | where did you want to start? | 03:55 |
| cfelton | either or, maybe best to see what you are thinking on the direction of HDMI2USB | 03:55 |
| cfelton | that would drive what hyperion may or may not be | 03:55 |
| cfelton | it would be awhile (my guess) for hyperion to catch up to HDMI2USB | 03:56 |
| mithro | cfelton: so, buy the end of next year, I'd like to see the HDMI2USB project have strong support for the following; | 03:56 |
| mithro | * Multiple "board" support. IE Atlys, HDMI2USB Prod, Zybo, Mixeeo, possibly something from Altera etc | 03:57 |
| mithro | * Multiple "interface" support. IE USB via the FX2, USB3.0/USB2.0 via the Dashio core, Ethernet, AXI (for Zynq + Novena) | 03:58 |
| mithro | * Some type of start for fully open DisplayPort core | 03:58 |
| mithro | * Actively working on reducing all non-100% FOSS parts | 03:59 |
| mithro | * Strong CI testing, IE compile, tests, load onto real device, run on every commit | 03:59 |
| mithro | The project will kind of be mis named then - but we can figure that out later :P | 03:59 |
| cfelton | yes, names are just names | 04:00 |
| cfelton | they are all great things | 04:00 |
| cfelton | no major road blocks (i don't think) other than the normal, time, etc. | 04:01 |
| mithro | The major roadblocks are around project organisation and structure | 04:01 |
| mithro | IE Handling the complexity of the increasing number of "options" and "configurations" | 04:02 |
| cfelton | yeah, agreed, complexity / scalability grows quickly | 04:03 |
| mithro | there are also fundamental problems which HDL hasn | 04:03 |
| mithro | bah | 04:03 |
| cfelton | yes, in the current HDL flow it will be quite a bit of work | 04:03 |
| mithro | there are also fundamental problems which HDL hasn't really been dealt with yet - IE There should be some type of common shared debug bus. | 04:04 |
| mithro | in some way kinda of like "debug symbols" found in C/C++ shared libraries | 04:05 |
| cfelton | fpga debugging can be fun :) | 04:06 |
| mithro | cfelton: yes, it's *way* to hard | 04:06 |
| mithro | cfelton: you should be able to quickly query if (and how many times) a fifo has underflowed / overflowed for example | 04:07 |
| mithro | also, it would be nice to have a FOSS chipscope like thing as well | 04:08 |
| cfelton | mithro: yeah, having a basic control / status bus is straightforward, that is something that can be built in | 04:08 |
| mithro | cfelton: I didn't say it was necessarily hard :P - although I want it to be reasonable generic so modules can just say "DebugCounter(signal)" and then a magical debug counter gets all set up | 04:09 |
| cfelton | mithro: the first FX2 interface I wrote used 2 pipe, a streaming and a control/status that drove a WB bus. Send little read/write packets for standard membus r/w, can add all kind of control and status. | 04:09 |
| mithro | cfelton: I think I saw that when I went searching for MyHDL cores | 04:09 |
| mithro | cfelton: this is -> http://www.fpgaz.com/usbp/ ? | 04:10 |
| tpb | Title: USB FPGA Project (at www.fpgaz.com) | 04:10 |
| cfelton | yes | 04:10 |
| cfelton | except that site will probably die soon, I haven't touched it in years, the host code is on sourceforge and I redid the core part in myhdl and is in the mn repo | 04:11 |
| mithro | I was trying to get Ajit to design something like that - but it didn't really happen | 04:12 |
| cfelton | I could probably proto something up fairly quick, it is nice on the host to pop up a python interrepter and >> readmem(addr) | 04:13 |
| cfelton | easy way to get all those counters :) | 04:13 |
| mithro | cfelton: yeah | 04:14 |
| mithro | https://docs.google.com/a/mithis.com/document/d/1-oq0WZnooKVja8QQSS2u60MwGc0YNB3TprSNDk-SNVU/edit <-- that is how I think the HDMI2USB firmware should end up looking | 04:14 |
| tpb | Title: HDMI2USB Firmware Layout - Google Docs (at docs.google.com) | 04:14 |
| mithro | https://docs.google.com/a/mithis.com/document/d/19XB1AOZMp5Tr-nKEmX8CSuChd6O11wmKfwKc1nsk4OA/edit#heading=h.mpb5yn7853jd <-- that document talks about Debug interfaces | 04:15 |
| tpb | Title: Debug Design - Google Docs (at docs.google.com) | 04:15 |
| cfelton | mithro: what do you mean by AXI, AXI is typically an on-chip interface (streaming vs. memmap) | 04:15 |
| mithro | cfelton: The Zynq chips have a Series 7 Atrix FPGA connected to a dual core ARM processor "via AXI" (if I understand correctly) | 04:16 |
| mithro | cfelton: the Novena laptop also uses an "AXI interface" to connect the Spartan 6 core to the ARM chip in it | 04:16 |
| mithro | cfelton: I don't really know much about AXI :P | 04:16 |
| mithro | cfelton: I understood it was just kind of like a memory mapped bus definition or something similar | 04:17 |
| cfelton | mithro: yes, for a local processor that would be the connection | 04:17 |
| mithro | cfelton: so the ARM chips in those systems are most certainly running Linux, so we have to write a driver which talks to the HDMI2USB firmware via the AXI thingy (and define the interface on the HDMI2USB side) | 04:19 |
| cfelton | mithro: part of the ARM AMBA spec, AMB is the good ol memory-map and AXI is more of a streaming, higher bandwidth connection. | 04:19 |
| cfelton | mithro: yes, that could be some work, the vendors will have examples but will have them all wrapped up in there tools | 04:20 |
| mithro | cfelton: there seems to be quite a few hardcore hackers working on the Zynq chips | 04:20 |
| mithro | cfelton: so I'm not to worry about it | 04:20 |
| cfelton | mithro: cool | 04:21 |
| mithro | http://www.parallella.org/ <-- another possibly HDMI2USB target | 04:22 |
| tpb | Title: Parallella | Supercomputing for Everyone (at www.parallella.org) | 04:22 |
| cfelton | mithro: have one | 04:22 |
| mithro | cfelton: ah cool | 04:22 |
| mithro | cfelton: so, one thing I wanted to mention is that maybe you could concentrate on making MyHDL the easiest way to "bring up new FPGA dev boards" | 04:23 |
| mithro | cfelton: I mean, I'd prefer you to work on HDMI2USB stuff but it something I wanted to suggested :P | 04:24 |
| cfelton | mithro: what do you actually mean by bring-up? | 04:24 |
| cfelton | basic board exercise, generic test, you mentioned memory tests in the emails | 04:24 |
| mithro | cfelton: say, I just got this dev board (weather because I brought it, or because I just created a new one) | 04:25 |
| mithro | cfelton: the process of getting to the stage where you can do something "useful" | 04:25 |
| mithro | cfelton: start with trying to get a debug interface up | 04:26 |
| mithro | cfelton: once you get that up, start poking at peripherals | 04:27 |
| mithro | cfelton: guess it could also be called "bootstrapping" | 04:27 |
| mithro | cfelton: the advantage by being *the* tool to use to get started with a board, you'll end up with a huge range of boards being supported | 04:28 |
| mithro | some student will follow the procedure to get random dev board X working and send a patch | 04:28 |
| mithro | etc | 04:28 |
| cfelton | mithro: sounds fair and a good thing to start working on. | 04:29 |
| mithro | cfelton: it also pretty simple in terms of "cores" until you get to the bigger peripherals | 04:29 |
| mithro | I would expect the process would be something like "get LED to flash", "get LED to flash at a known rate", "get some type of UART working", "get some type of processor/debug bus/chipscope like thing connected to UART", "get USB interface working for faster UART" | 04:31 |
| mithro | I think in a lot of boards, the issue after that is getting offboard RAM working | 04:32 |
| cfelton | mithro: the first one is already complete for a bunch of boards, https://bitbucket.org/cfelton/myhdl_tools/src/e1da21ff381957b42649525ad51cb7e33001a4a2/examples/?at=default | 04:32 |
| tpb | Title: cfelton / myhdl_tools / source / examples Bitbucket (at bitbucket.org) | 04:32 |
| cfelton | mithro: adding USB on the FPGA wouldn't be too hard, pulling together the correct FW and SW takes some coordination | 04:32 |
| mithro | cfelton: 6 boards is a pretty good start - but I can probably list about 100 :P | 04:33 |
| mithro | cfelton: oh, a couple of things I also wanted to mention regarding building communities | 04:34 |
| cfelton | mithro: the offboard RAM and reasonable rates shouldn't be too difficult, but I don't want to set expectations incorrect here. It shoudn't be too bad but I don't know how much time I have each week | 04:34 |
| cfelton | mithro: adding a new board is simple, just fill in a little info and viola | 04:34 |
| mithro | cfelton: github is where the coders are - bitbucket might be better in every way but the network effect github is winning | 04:34 |
| cfelton | mithro: I have repos on both sides, and it appears to not matter one bit which one it is on but rather how much external "marketing" is done | 04:35 |
| mithro | cfelton: I find myself searching directly on github and know other people who do too | 04:36 |
| cfelton | mithro: yeah but there is so much, you get lost in the noise | 04:36 |
| mithro | cfelton: true | 04:36 |
| mithro | cfelton: btw looking at https://bitbucket.org/cfelton/myhdl_tools/src/e1da21ff381957b42649525ad51cb7e33001a4a2/myhdl_tools/boards/xilinx/_papilio.py?at=default | 04:36 |
| tpb | Title: cfelton / myhdl_tools / source / myhdl_tools / boards / xilinx / _papilio.py Bitbucket (at bitbucket.org) | 04:36 |
| mithro | pone.add_port('rx', Signal(False), 88, iostandard='LVCMOS33') | 04:37 |
| mithro | pone.add_port('tx', Signal(False), 90, iostandard='LVCMOS33', drive='4', slew='SLOW') | 04:37 |
| cfelton | mithro: I don't have a strong opinion, new projects I can start where ever, and I can mirror existing project on github, and if the github side has way more traffic can migrate over, at first I won't move my exisiting projects | 04:37 |
| mithro | Why is that not add "pone.add_device(UART(rx=Pin(88), tx=Pin(90))" or something similar? | 04:38 |
| mithro | cfelton: or does that happen elsewhere? | 04:38 |
| cfelton | mithro: no, currently you can only associate signals and pins, adding a device here is odd because it still needs to be hooked up in the design | 04:39 |
| cfelton | mithro: if you instantiate the block here you would also want to add all the options for that block, which could be a little odd. | 04:41 |
| mithro | cfelton: yeah, I guess where you do the configuration depends on the type of block | 04:42 |
| cfelton | mithro: I do like the idea, of the higher abstraction, get more done quickly, just having trouble resolving some gaps right now | 04:42 |
| mithro | cfelton: My idea of solution would be something like | 04:43 |
| cfelton | mithro: or multiple of the same but it is possible, then in the top-level you can simple for dev in pone.get_devices(): | 04:43 |
| mithro | https://www.irccloud.com/pastebin/4anfANcj | 04:45 |
| tpb | Title: Pastebin: 4anfANcj | IRCCloud (at www.irccloud.com) | 04:45 |
| mithro | but I haven't really thought it all through :P | 04:45 |
| *** aps has quit IRC | 04:46 | |
| *** hyades has quit IRC | 04:46 | |
| cfelton | mithro: I definitely like the idea of the higher abstraction, | 04:46 |
| cfelton | mithro: why platform instead of board | 04:46 |
| mithro | cfelton: dunno, maybe a "platform" could be a board plus a bunch of expansion things connected or something | 04:47 |
| mithro | IE An Atlys board with a vmodvga connected to the VHDCI... | 04:47 |
| cfelton | mithro: one of the things that scares me a little, is that there would be high compling of the automate FPGA flow and the cores, right now you the top-level ports would look a little traditional (but still could be automated) but the building of the system would look more like you outlined. | 04:48 |
| mithro | cfelton: I really think setting up a board should be something like this | 04:48 |
| cfelton | mithro: compling = coupling | 04:49 |
| *** aps has joined #timvideos | 04:51 | |
| mithro | https://www.irccloud.com/pastebin/DWokuzYv | 04:51 |
| tpb | Title: Pastebin: DWokuzYv | IRCCloud (at www.irccloud.com) | 04:51 |
| mithro | for maybe something like "DDR2SDRAM(chip=MT389923_DDR2RAM)" | 04:52 |
| mithro | s/for/or/ | 04:52 |
| mithro | for example in the Xilinx MIG generator you select the RAM chip type and it automagically sets up all the timing configurations | 04:52 |
| *** hyades has joined #timvideos | 04:53 | |
| mithro | so if someone else has a board with the same RAM chip, we should share parameters | 04:53 |
| mithro | cfelton: I get some of that stuff with migen / misoc | 04:55 |
| mithro | cfelton: but its all a bit adhoc / fluffy | 04:55 |
| cfelton | mithro: thinking | 04:55 |
| mithro | see https://github.com/mithro/migen/blob/master/mibuild/platforms/digilent_atlys.py and https://github.com/mithro/misoc/blob/master/targets/digilent_atlys.py | 04:56 |
| tpb | Title: migen/digilent_atlys.py at master · mithro/migen · GitHub (at github.com) | 04:56 |
| cfelton | mithro: I don't think it quite works but i don't have a good rebuttal at this point | 04:57 |
| mithro | cfelton: yeah - it probably has huge holes | 04:57 |
| mithro | cfelton: but a development board as a bunch of ICs soldered to it | 04:57 |
| mithro | cfelton: and those ICs are connected to pins | 04:58 |
| cfelton | mithro: example, using the base class "Spartan6" is the least interesting info, need package type (IO count), type of XCS6, etc. Although it looks clean in the short example, I don't know if it would end up being better than .... | 04:58 |
| mithro | cfelton: but I don't really care about the pins really, what I care about are the ICs the pins are connected too | 04:58 |
| cfelton | mithro: now I see why you call it platform :P | 04:58 |
| cfelton | mithro: no you don't care about IC, you care about number of resources | 04:59 |
| mithro | of course it gets a little confusing when you add expansion boards | 04:59 |
| mithro | cfelton: "number of resources"? | 04:59 |
| cfelton | mithro: is it a XC6SLX15 or a XCSLX25 the that that it is a XC6S is not that useful | 05:01 |
| mithro | cfelton: I'm talking about the non-FPGA ICs | 05:02 |
| cfelton | mithro: I understand where you are coming from but I don't like the idea of instantiate blocks when defining the IO - then these two are coupled for life. Bundling IO makes sense and you can define "platforms" with different bundles | 05:02 |
| cfelton | mithro: we must of got out of sync somewhere, I had use the base-class example ... ahh ahhh ... | 05:02 |
| mithro | cfelton: yeah - i'm totally not tied to the "class Atlys(Spartan6)" bit | 05:04 |
| mithro | cfelton: I was talking about the idea that nobody cares about pins on FPGA, they care about what the pins are connected to | 05:05 |
| cfelton | mithro: I don't like the idea of forcing a block for and external interface (ext IC) to a block when defining the pins for a board/platform, I am failing to see the logic. Flipping it, bundling IO and simpling passing the bundles (probably a horrible word but I have been up for almost 20 hours) to the blocks | 05:05 |
| cfelton | mithro: yes that we agree | 05:05 |
| mithro | cfelton: except for GPIO and expansion ports, it's pretty hard to reconfigure pins which are connected to a device soldered onto the board :P | 05:06 |
| cfelton | mithro: sure, but I can use different cores to interface with the IC, example, how many FX2 FPGA cores are there. I don't want to tie my board definition to specific cores - doesn't make sense to me | 05:07 |
| mithro | cfelton: all the FX2 "cores" fundamentally have the same interface to the FX2 IC though | 05:08 |
| mithro | actually, that is a better name for it | 05:08 |
| cfelton | mithro: I do agree, you want to capture what the IO are connect to, so having something that captures the information is good. Maybe we are violently agreeing but I jump ahead and assumed the UART was also the logic version an object that contains info on the interface/IC | 05:09 |
| mithro | the board / platform could be defining "interfaces" | 05:09 |
| cfelton | mithro: exactly! | 05:09 |
| cfelton | mithro: then when you create a system you marry the interfaces and modules through something like you example | 05:10 |
| mithro | cfelton: yeah | 05:10 |
| mithro | cfelton: I guess wishbone is an example of an internal "interface" ? | 05:10 |
| cfelton | mithro: I do like pone.add_interface(UARTIntf(Pin(), Pin())) | 05:11 |
| mithro | cfelton: really, even expansion ports are interfaces in some ways, IE "AtlysCompatibleVHDCI" or "PMOD" or ...... | 05:12 |
| cfelton | mithro: yup, but these are the ones that change, but add_interface would work like the add_port, you can override. not too bad | 05:13 |
| mithro | cfelton: If would be nice to have expansion "Interfaces" you can override a with real devices | 05:14 |
| mithro | IE | 05:14 |
| cfelton | mithro: I need to think about this some more, how I see it there would be three packages: board-n-flow, system, and application. | 05:16 |
| mithro | platform.get_interface("PMOD1").plug(Pmod8LDInterface) or something | 05:16 |
| mithro | cfelton: but that is just thoughts on how I might do something :P | 05:19 |
| cfelton | mithro: yeah, might need the concept of: connectors, banks, and interfaces, connectors, banks, and ports represent physical things while interfaces are logical and you should be able to move then around, assign an interface to a connector, bank, or ports (verbage under review :) | 05:19 |
| cfelton | mithro: I need to head to bed, I have to get up in a couple hours. This was good stuff. Lets have a couple more collabs and see where it gets us. | 05:23 |
| mithro | cfelton: okay | 05:23 |
| mithro | cfelton: have a good night | 05:23 |
| cfelton | mithro: you too | 05:23 |
| mithro | back to hitting my head against C++ | 05:24 |
| cfelton | mithro: STL rock on! | 05:24 |
| *** Niharika has quit IRC | 05:57 | |
| *** Niharika has joined #timvideos | 06:06 | |
| *** CarlFK has quit IRC | 06:48 | |
| *** Niharika has quit IRC | 06:55 | |
| *** Niharika has joined #timvideos | 07:32 | |
| *** Niharika has quit IRC | 09:20 | |
| *** Palash has joined #timvideos | 10:21 | |
| *** Palash has quit IRC | 11:35 | |
| *** Niharika has joined #timvideos | 12:38 | |
| *** CarlFK has joined #timvideos | 14:58 | |
| *** ChanServ sets mode: +v CarlFK | 14:58 | |
| *** Niharika has left #timvideos | 16:07 | |
| *** tariq786 has quit IRC | 16:16 | |
| *** tariq786 has joined #timvideos | 16:16 | |
| *** Niharika has joined #timvideos | 16:37 | |
| *** CarlFK has quit IRC | 18:04 | |
| *** tariq786 has quit IRC | 18:08 | |
| *** Niharika has quit IRC | 18:13 | |
| *** tariq786 has joined #timvideos | 18:13 | |
| *** CarlFK has joined #timvideos | 19:17 | |
| *** ChanServ sets mode: +v CarlFK | 19:17 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!