| --- Log opened Mon Apr 07 00:00:54 2014 | ||
| analognoise | Hey Openrisc | 00:33 |
|---|---|---|
| Limb | Still no ISE system cores yet? | 01:10 |
| Limb | Traceback (most recent call last): | 02:00 |
| Limb | File "/usr/local/bin/fusesoc", line 14, in <module> | 02:00 |
| Limb | from fusesoc.build import BackendFactory | 02:00 |
| Limb | File "/usr/local/lib/python2.7/dist-packages/fusesoc/build/__init__.py", line 2, in <module> | 02:00 |
| Limb | from fusesoc.build.ise import Ise | 02:00 |
| Limb | ImportError: No module named ise | 02:00 |
| Limb | Getting that with the latest git pull build | 02:00 |
| stekern | Limb: by the pull request, I reckon you already figured out what was wrong ;) | 03:06 |
| Limb | Haha yep :) | 03:20 |
| Limb | stekern: Do you by chance have a example ISE project you can share? | 03:20 |
| Limb | saw olofk was saying you might yesterday | 03:21 |
| Limb | Trying to adapt one on my own.. but I also don't have a clue what I'm doing haha | 03:21 |
| stekern | Limb: yeah, I'll push my atlys project soon, it'll need some minor adjustments to olofk's ise backend, it's slightly different than mine | 03:32 |
| stekern | my work-in-progress on it is available here though: https://github.com/skristiansson/orpsoc-cores/tree/master/systems/atlys | 03:33 |
| Limb | Thats a lot of work haha | 03:36 |
| Limb | hope itll be relatively easy to port to a Nexys4 | 03:37 |
| stekern | what kind of memory does it have? | 03:38 |
| Limb | Cellular | 03:39 |
| stekern | ah, ok | 03:39 |
| Limb | That good or bad? haha | 03:39 |
| stekern | so same as the "old" nexus3 | 03:39 |
| stekern | right? | 03:39 |
| Limb | I believe so | 03:39 |
| stekern | it's probably fine, if it's the same as nexus3, you should be able to pull the memory controller wrapper for the orpsocv2 nexus3 board into your port | 03:40 |
| Limb | Is there any place that defines the bare minimum cores you need to get a processor up and running? | 03:41 |
| stekern | well, the or1200-generic and mor1kx-generic systems are pretty much that | 03:42 |
| stekern | some kind of RAM, cpu and uart is basically all you need | 03:42 |
| stekern | (of course you don't *need* to have the uart, but it's nice to get some feedback ;)) | 03:43 |
| Limb | hehe | 03:43 |
| Limb | I'm hoping it won't be too hard | 03:44 |
| Limb | Any specific difference between ork1200 and mor1kx? | 03:45 |
| stekern | Limb: or1200 is the original implementation. mor1kx is a newer implementation, that tries to correct some deficiencies in or1200 | 05:23 |
| stekern | like verilog coding practices from late 90s, and it being slow and big | 05:24 |
| stekern | and having a more modular pipeline | 05:27 |
| stekern | fun stats from github: http://osrc.dfm.io | 05:51 |
| stekern | olofk: just noticed a difference between the pull requests you've pulled in and the once I pulled in to orpsoc-cores | 06:00 |
| stekern | hint - you don't need to manually go and close the pull request that you merge | 06:01 |
| stekern | hmm, perhaps I was too quick to throw judgement there... the difference is probably because the ones I pulled in involved a merge | 06:05 |
| stekern | ...or then not | 06:07 |
| stekern | the mor1kx-generic pull did not involve a merge, but it still shows as "merged": https://github.com/openrisc/orpsoc-cores/pull/47 | 06:08 |
| olofk_ | How come I never remember to update that fucking Makefile.am? :) | 06:21 |
| olofk_ | stekern: And yes. Since I'm cherry-picking instead of merging, I thought I needed to close the requests manually | 06:24 |
| olofk_ | #47 was just me being trigger-happy though :) | 06:24 |
| olofk_ | I just can't figure out why I can't pull from orpsoc-cores anymore | 06:25 |
| stekern | hmm, ok, maybe you have to then | 06:25 |
| olofk_ | A fresh clone works, but I can't have to do that all the time | 06:25 |
| stekern | what is it saying? | 06:26 |
| stekern | (Makefile) you need to start keeping more branches around and jumping between them, that will force you to run autoreconf ;) | 06:27 |
| olofk_ | I've actually started using branches. Trouble is that I'm not installing fusesoc... despite telling everyone else to do it :( | 06:42 |
| olofk_ | (pull problem) It's getting stuck at various percents during the compressing stage (or whatever it's called) | 06:43 |
| olofk_ | stekern: Don't know if its' related, but it started after you commited stuff. Could it be some weird incompatibility between git clients, so that your client compresses in a way that my can't read (far-fetched, I know) | 06:46 |
| stekern | oh, sorry, I pushed with the --block-olofk flag ;) | 06:47 |
| stekern | does it help if you run git gc? | 06:47 |
| stekern | ... with various flags | 06:48 |
| stekern | I've got 1.8.3.2 here | 06:48 |
| stekern | is it only when you pull, or if you try to fetch too? | 06:53 |
| olofk_ | Need to try that when I get home | 07:01 |
| kiwichris | Hi, I am Chris from the RTEMS project and I am starting to look over the newlib patches for OpenRisc. Anyone about to answer questions ? I am sorry but I do not know the timezones of devs on this project. I am +10UTC. | 07:08 |
| stekern | kiwichris: I think people are awake | 07:11 |
| kiwichris | stekern, thanks | 07:12 |
| kiwichris | jeremybennett, hi | 07:14 |
| kiwichris | The RTEMS project has a proposed GSoC project and I am reviewing this patch https://raw.githubusercontent.com/heshamelmatary/or1k-rtems/master/patches/newlib-2.1.0-or1k-rtems.diff | 07:20 |
| kiwichris | The issue I see is the libgloss support has a GPL 3 license which is not great for newlib as it is typically embedded and statically linked. | 07:21 |
| stekern | mmm, jeremybennett_ is probably the man to comment on that particular issue. | 07:30 |
| jeremybennett_ | kiwichris: The libgloss was written as a teaching example, so GPL 3 is appropriate (see http://www.embecosm.com/resources/appnotes/#EAN3). If you want a libgloss for commercial deployment, you should write one from scratch. | 07:38 |
| jeremybennett_ | Of course if you are building a free and open source embedded system, then GPL 3 is just fine anyway. | 07:39 |
| kiwichris | The RTEMS license is GPL2 + runtime exception just like libgcc. | 07:40 |
| kiwichris | Newlib is typically BSD'ish | 07:40 |
| jeremybennett_ | RTEMS is a commercial project, not a teaching example. | 07:40 |
| kiwichris | RTEMS is not commercial. | 07:40 |
| kiwichris | It is an open source project | 07:41 |
| jeremybennett_ | Most newlibs, including the ones I write for paying clients are indeed BSD | 07:41 |
| kiwichris | Hmm ok. | 07:41 |
| jeremybennett_ | I think you are making the mistake that open source != commercial. Since I make my living by open source == commercial I would dispute this. | 07:41 |
| jeremybennett_ | RTEMS is most certainly commercial. People make their living deploying and using it for money. | 07:42 |
| kiwichris | I am not here for an argument about licenses. If you could refrain from these types of comments I would appreciate it. | 07:43 |
| jeremybennett_ | Hold on - you raised the subject! | 07:44 |
| kiwichris | I asked about the reason for GPL3 in the newlib. I did not need to told what RTEMS is or is not. | 07:45 |
| jeremybennett_ | OK - point taken. | 07:45 |
| kiwichris | Thanks | 07:45 |
| jeremybennett_ | You have the reason - it was written as a teaching example. | 07:45 |
| kiwichris | Thanks. | 07:46 |
| kiwichris | jeremybennett_ I will raise the issues of what you say with others and maybe we can conduct a further discussion via email | 07:47 |
| jeremybennett_ | kiwichris: Sure - we can have a discussion about licensing separately if you like. As others will tell you, I hold strong views on the subject - evidence above :) | 07:48 |
| kiwichris | An that is fine; We have a student in a GSoC project and they should not be subject to these types of issues. | 07:49 |
| stekern | jeremybennett_: to be fair, it wouldn't be completely from scratch, since a lot was based on Jakob Bowers work | 07:50 |
| jeremybennett_ | stekern: Well - yes and no. In the end we ditched all of Jakob's actual code. But it was valuable in showing us how to proceed. | 07:52 |
| kiwichris | RTEMS does not use libgloss so we could remove it; I tend to seek other paths and solution if possible first. | 07:52 |
| jeremybennett_ | Hopefully the current libgloss will be used in the same way - to show people the way to go. | 07:52 |
| jeremybennett_ | libgloss is purely a board support package. I would strongly encourage anyone to write one suited to their actual needs. | 07:53 |
| kiwichris | I need to head off; thanks for information | 07:55 |
| stekern | jeremybennett: not trying to be an ass here, but this https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/uart.c and this http://pastie.org/9000097 (from http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch) has a striking resemblance, so don't say you ditched *all* his code when you didn't. | 08:16 |
| stekern | my real point is though, you can take his patches and work upon that to get a non-gpl3 libgloss pretty easily | 08:17 |
| olofk_ | See, this is the kind of trouble we are going through just because we haven't moved all our coded to MS-pl | 08:31 |
| olofk_ | Not super impressed with objcopy right now. There has to be a way to get the verilog backend to generate 32-bit words instead of bytes | 08:32 |
| olofk_ | I could of course make my ROM use a byte array, but it feels a bit awkward | 08:33 |
| stekern | maybe it's better to do the .vmem generation in fusesoc then? | 09:19 |
| stekern | or in orpsoc-cores, with a python-script | 09:20 |
| stekern | ...or post a patch to binutils ;) | 09:22 |
| olofk_ | binutils patch would be best, but I'll probably go for something in orpsoc-cores to begin with | 10:05 |
| olofk_ | Speaking of which, I'm thinking about moving the VerilogWriter class into fusesoc and put it into a utils module. I'm about to use it in a third core now, and want to avoid too much duplication | 10:06 |
| stekern | if you'd use a byte array in the ROM, what would the awkwardness come from? would the ROM need to be byte accessible? | 10:06 |
| stekern | btw, I got my atlys port compile with your ISE backend | 10:08 |
| stekern | and I got one question, where does the bitgen options come from? | 10:08 |
| stekern | since it automagically created one | 10:08 |
| stekern | s/one/a .bit file | 10:08 |
| stekern | ok, found it in the _cmd.log: bitgen -intstyle ise -f orpsoc_top.ut orpsoc_top.ncd | 10:13 |
| stekern | ...so what startup clocks will that use? | 10:13 |
| stekern | because... the startup clock I used in the ise patch I posted wasn't all that great, I needed to powercycle the board everytime I had programmed it | 10:14 |
| olofk_ | stekern: You should be able to inject extra options by defining your own tcl_files | 11:21 |
| olofk_ | The main reason for choosing the tcl flow instead of the traditional flow was that it seems to be easier to add tcl options rather than adding command line parameters | 11:22 |
| olofk_ | Not that I have tried it though. Only used the tools directly before | 11:22 |
| olofk_ | Have to figure out where the hell these options are described | 11:24 |
| stekern | yeah, it's probably fine (although I kind of miss having an easy to read Makefile, but that's perhaps due to my tcl blindness more than anything else) | 11:24 |
| stekern | .. and I might add that those bitgen clock options confuses the hell out of me | 11:24 |
| stekern | bitgen -g StartUpClk:JtagClk -w $(DESIGN_NAME)-routed.ncd $(DESIGN_NAME).bit | 11:29 |
| stekern | is what I used to be able to reprogram | 11:29 |
| olofk_ | Try something like: project set "FPGA Start-Up Clock" "CCLK" -process "Generate Programming File" | 11:30 |
| olofk_ | s/CCLK/JTAG Clock | 11:31 |
| stekern | but from what I remember from orpsocv2, you need something else for the one that you put onto flash | 11:31 |
| olofk_ | http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/devref.pdf page ~349 | 11:31 |
| olofk_ | My first version only used xtclsh for the synthesis stage. Main reason for that was that I thought it was easier to read the TCL options than the cryptic names in the XST project file | 11:32 |
| olofk_ | Then I realized that I could just run "Generate Programming File" instead of "Syntheis" and get rid of the Makefile | 11:33 |
| olofk_ | But yeah. I got a little worried myself when I removed the makefile and let ISE handle things itself. Could go very wrong | 11:34 |
| stekern | hmm, yes this is very informative: "Cclk - Enter Cclk to synchronize to an internal clock provided in the FPGA device" | 11:37 |
| olofk_ | I think cclk is some rudimentary RC-based internal clock that is always available | 11:46 |
| olofk_ | Perhaps I should convince the Moxie guy to use FuseSoC. | 11:48 |
| stekern | moxie guy? | 11:48 |
| olofk_ | stekern: Have you been hacking on that CPU as well? :) | 11:48 |
| olofk_ | http://moxielogic.org/blog/ | 11:49 |
| olofk_ | A wishbone-compatible hobby CPU | 11:49 |
| olofk_ | I think he's the guy who added the verilog support to binutils | 11:49 |
| stekern | oh, right | 11:51 |
| olofk_ | I really wish there was a way to clone parts of a GIT repo, svn style, since everyone seems to insist on putting all their crap in the same repo | 11:57 |
| _franck_web_ | don't you think we sould have an fusesoc-cores github organization ? So we could put in some non openrisc systems in there | 12:00 |
| stekern | I don't think there's no harm in having such systems under openrisc/orpsoc-cores | 12:06 |
| stekern | s/no/any | 12:06 |
| olofk_ | I think it will be good to drop orpsoc from orpsoc-cores at some point, but it's not a big deal right now. | 12:11 |
| olofk_ | But when we do, we should probably let them mirror each other for a while. Apparently the orpsoc repo had a few users that were shocked when it was removed :) | 12:12 |
| Limb | olofk_: that's what got submodules are for :p | 12:15 |
| olofk_ | Limb: True, but it's a lot more overhead than doing it SVN style | 12:16 |
| stekern | I'm voting for coresnstuff | 12:17 |
| * Limb was never a big fan of svn | 12:17 | |
| olofk | stekern: Do you know how much of the HDMI implementation that is done outside of the FPGA on the Atlys board? | 17:51 |
| stekern | yes, none | 17:52 |
| olofk | Really..? | 17:52 |
| olofk | But at least it does SERDES, right? | 17:52 |
| stekern | except there are some texas chips on some of the hdmi outputs, but they are only there as "line stabilizer" or something like that | 17:53 |
| stekern | yes, but those are inside the fpga | 17:53 |
| olofk | Interesting. I hadn't looked at it so I just assumed that the spartan6 I/O were way too slow and you needed external transceivers | 17:53 |
| ysionneau | olofk: you can ask lekernel he did manage to get hdmi working (2 outputs at a time) on a spartan 6 | 18:08 |
| ysionneau | using the SERDES (SERDES2 ?) ioports | 18:08 |
| olofk | ysionneau: That's good to know. Thanks | 18:09 |
| ysionneau | that's basically the mixxeo project http://m-labs.hk/ | 18:11 |
| ysionneau | ah sorry it's 2 inputs and 1 output | 18:11 |
| ysionneau | not 2 outputs | 18:11 |
| -!- Netsplit *.net <-> *.split quits: LoneTech, sfa, blueCmd | 20:10 | |
| olofk | Man, these people at Xilinx are stupid | 20:22 |
| olofk | I had the exact same problem as this guy http://forums.xilinx.com/t5/Synthesis/XST-Error-418/td-p/141146 | 20:25 |
| olofk | He clearly describes the problem, and gets a boilerplate answer that some constructs aren't synthesizable and that they need to see his project files | 20:26 |
| olofk | I'm mainly annoyed because I thought I had found a nice way to create some reusable functions. Worked fine in simulations :( | 20:39 |
| olofk | Oh well. It's just the same old truth that it's possible to write good HDL code, but not good HDL code that can be used in several tools | 20:40 |
| wkoszek | olofk: Typically when people ask you to provide a project, it means they way to run it through tools in debugging mode and be able to observe what's really going on. | 20:42 |
| wkoszek | olofk: For simple stuff it's annonying, but it's basically because your bug database has a "How to reproduce" field and you must put something there. | 20:43 |
| olofk | wkoszek: Yes, I can understand that for complex problems, but most of the things I have reported over the years could be proven with very simple test cases | 20:44 |
| wkoszek | olofk: I know. It's mostly because people have lots of stuff to do and given you already have a test case for bug reproduction, they just don't want to waste time writing it.] | 20:45 |
| wkoszek | But I get what you mean. | 20:46 |
| olofk | And I get what you mean as well | 20:46 |
| olofk | I guess it comes down to the fact that neither me nor the support team wants to wrap it up in a package :) | 20:46 |
| wkoszek | Yeah. | 20:47 |
| wkoszek | It's typically big corporation bs | 20:47 |
| Limb | whats the difference between mmuart and uart16550? aka why does the mor1kx-generic have both and can I just include one? | 20:50 |
| olofk | Limb: That's a dirty hack from my side. mmuart is only used for simulations with verilator in that system | 21:14 |
| olofk | The problem I was trying to solve is that UART is unbearably slow to use in event driven sims (icarus/modelsim), so in those cases I've exchanged the real UART with a UART model | 21:16 |
| Limb | Ahh ok | 21:16 |
| olofk | And when using verilator the uart16550 core just sends data that can be read out from mmuart and be printed on the screen | 21:16 |
| Limb | OK... So I believe I almost have a working setup here. I need to provide ram though. Am I GOING to have to connect this to on board ram? or is there a core that provides dumbed down ram for me? | 21:29 |
| olofk | Limb: I've been working on exactly that the last couple of days :) | 21:30 |
| Limb | So short answer is right now, no :P | 21:31 |
| olofk | To avoid connecting the external RAM on my lx9 | 21:31 |
| olofk | Can't remember, what FPGA is it you're having? | 21:31 |
| Limb | Nexys4 | 21:31 |
| Limb | (Virtex7) | 21:31 |
| Limb | errr... Artix7 lol | 21:32 |
| Limb | been a long day | 21:32 |
| blueCmd | Limb: what are you building? (sorry, I haven't read the backlog) | 21:33 |
| Limb | blueCmd: nothing at this point. just trying to get the processor up and running. Although ultimate end goal is to create a MP3 Player for a design contest I'm in | 21:33 |
| Limb | so possibly booting linux, or coding it by hand if need be | 21:34 |
| blueCmd | Limb: let me know if you want to run Debian on it | 21:34 |
| blueCmd | I have no idea if it would work, but it could be kind of cool | 21:35 |
| olofk | Limb: Try this one https://www.dropbox.com/s/w7dnlu5sgyx5v7j/wb_ram.tar.gz | 21:35 |
| Limb | olofk: will do | 21:37 |
| Limb | is that the basic ram implementation you were working on? | 21:37 |
| olofk | Yep | 21:37 |
| Limb | Also, the nexys4 has Cellular ram that the sheets say work the same as SRAM. Would I be able to use the SDRam core to connect to it? | 21:37 |
| olofk | It's based on ram_wb, but I'm cleaning it up to make it easier to reuse | 21:38 |
| blueCmd | 5247 binary packages for Debian or1k built. Getting close to gtk2.0 building | 21:38 |
| olofk | blueCmd: Jesus. That's a lot of package | 21:40 |
| olofk | s | 21:40 |
| olofk | What's the fail rate? | 21:40 |
| blueCmd | olofk: me and mafm has been building stuff :P | 21:40 |
| blueCmd | olofk: of building? | 21:40 |
| olofk | Yes | 21:40 |
| Limb | olofk: I hate to be a pain, but how exactly do I go about adding the ram to my system? aka what goes in the top file | 21:41 |
| blueCmd | quite high, debian could be called "Dependency Cycle" | 21:41 |
| olofk | I guess running is a bit harder to determine | 21:41 |
| blueCmd | but if I get gtk2.0 I can build gcc "the debian way" :) | 21:41 |
| blueCmd | (yes, gcc depends on gtk2.0 in Debian) | 21:41 |
| blueCmd | ((for building)) | 21:41 |
| olofk | Limb: Something like this http://pastie.org/private/rgucz5uvwh54wojn58l53q | 21:42 |
| blueCmd | olofk: you should use paste.se! länge leve sverige! | 21:42 |
| olofk | blueCmd: Hearing that makes me want to keep onto gentoo | 21:42 |
| olofk | :) | 21:43 |
| blueCmd | olofk: yeah, well - you don't want to compile gcc on a 50 MHz DE0 Nano :P | 21:43 |
| olofk | blueCmd: We should just implement gcc in hardware :) | 21:45 |
| olofk | Limb: Have you gotten your interconnects worked out? | 21:45 |
| blueCmd | what we SHOULD implement is a 3D accelerator | 21:45 |
| olofk | blueCmd: When I worked at ORSoC we had some guys doing that as their master thesis | 21:45 |
| blueCmd | but as a CPU extension or something weird | 21:46 |
| Limb | olofk: was just looking at that now. Theres a ram interconnect in here, but i'm not sure what for. basing this off the mor1k-generic example ssytem | 21:46 |
| blueCmd | olofk: did they do the "card" approach? or hooked it up to the wishbone directly? | 21:46 |
| olofk | blueCmd: It's a on-chip core. They were using a digilent atlys | 21:46 |
| _franck__ | blueCmd: https://www.youtube.com/watch?v=_0b91_pnmSs | 21:47 |
| olofk | Limb: You could probably use the interconnect from mor1kx-generic without any modifications | 21:48 |
| olofk | But if you need to add some extra cores it could be good to know that it's autogenerated from a config file | 21:48 |
| Limb | olofk: we're talking wb_intercon.conf and its resulting .v and .vh files right? | 21:49 |
| blueCmd | _franck__: awesome! | 21:49 |
| olofk | Limb: Yes | 21:49 |
| blueCmd | _franck__: what happened with that? | 21:49 |
| olofk | Sounds like you're familiar with them already :) | 21:49 |
| Limb | olofk: I have these 2 devices in my slaves list: uart0 and wb_ram0 | 21:49 |
| olofk | Limb: Sounds right | 21:50 |
| _franck__ | blueCmd: they just stopped | 21:50 |
| Limb | olofk: how does the processor know to use the wishbone ram? | 21:50 |
| olofk | blueCmd: It's on opencores. Just that no one else has used it | 21:50 |
| _franck__ | there is some bare metal driver for 2D rendering (lines, fill,...) | 21:50 |
| olofk | Limb: CPU starts by reading instructions at address 0x100. Just set up your RAM to cover that area | 21:51 |
| blueCmd | might be easier to just interface PCIe-cards or older AGP cards or something | 21:51 |
| Limb | Ahhhh. I think im starting to understand now | 21:51 |
| Limb | [slave wb_ram0] offset=0 size=8388608 ;8MB | 21:52 |
| _franck__ | blueCmd: we need to have a PCIe core for that | 21:52 |
| olofk | blueCmd: There's the open graphics card guys as well. Their mailing list has been awfully quiet for a while now though | 21:52 |
| Limb | would that be correct olofk | 21:52 |
| olofk | Limb: Yes. | 21:52 |
| _franck__ | blueCmd: or we could design a board with some gddr and use the vga_lcd core we have | 21:53 |
| olofk | Yes. Doing an external GPU means having a high bandwidth of-chip connection | 21:54 |
| olofk | PCI is probably most feasible with the low-mid-end FPGAs that are supported by the free vendor tools | 21:54 |
| blueCmd | I'm just afraid of the massive amount of work writing the firmware and drivers for the OpenGL stuff | 21:55 |
| olofk | But on-chip with dedicated RAM like _franck__ said is probably doable | 21:55 |
| olofk | blueCmd: Yeah, it seems like an insane amount of work | 21:55 |
| blueCmd | but so is OpenRISC :P | 21:56 |
| _franck__ | not sure, I took a look at directfb and it's not that massive (don't know if directfb might be a good alternative) | 21:56 |
| olofk | But perhaps you can start out with a sw renderer and just move a few things in hardware | 21:56 |
| olofk | We should start with doing a kms driver | 21:56 |
| blueCmd | _franck__: for just a framebuffer - sure, but for OpenGL and hardware accelerated rendering, it will take much effort I recon | 21:56 |
| olofk | I talked to Anton who worked on orgfx and he very much wanted a kms/drm driver, but didn't have time | 21:57 |
| olofk | And I think we should skip OpenGL and go directly for eGL | 21:57 |
| Limb | olofk: What is MEM_SIZE_BITS | 21:58 |
| olofk | Limb: log2 of the memory depth | 21:59 |
| Limb | What determines the depth? the 8 MB i specified in wishbone? | 21:59 |
| olofk | The depth specified in wb_intercon.conf will only affect which addresses that are passed through to the RAM | 22:00 |
| olofk | You have limited memory resources on the FPGA, so I would start with something like 4kB | 22:00 |
| olofk | That means MEM_SIZE_BITS=12 or 13 | 22:01 |
| olofk | or 14? Hmm.. can't count right now | 22:01 |
| blueCmd | olofk: I would love to talk to someone who knows the ins and outs of the open source Radeon driver, they have done what we want I guess | 22:02 |
| Limb | log2(4096) = 12 | 22:02 |
| olofk | blueCmd: You should check out ogp if you're interested in this (http://wiki.opengraphics.org/tiki-index.php) | 22:02 |
| Limb | olofk: do I have to change the depth in the wb_ram core as well? | 22:03 |
| olofk | My feeling is that they are a bit too academic though | 22:03 |
| olofk | Limb: Don't think so | 22:03 |
| olofk | Specifying MEM_SIZE_BITS should be enough | 22:04 |
| Limb | Ok. And what should i change my offset for uart to? | 22:04 |
| Limb | offset=0x90000000 seems like it wont exist in 4 KB | 22:04 |
| olofk | Limb: No it won't. That's the address to the UART | 22:04 |
| Limb | ohhh | 22:05 |
| Limb | so leave it as is? | 22:05 |
| olofk | yep | 22:05 |
| olofk | 0x00000000-0x7fffffff are addresses that can be cached, and everything above that should never be cached | 22:05 |
| blueCmd | olofk: http://en.wikipedia.org/wiki/Gallium3D and some DRM kernel module (as you said) - might be a fun project. | 22:06 |
| olofk | blueCmd: Yep. Gallium is probably a good starting point | 22:06 |
| olofk | Especially the llvmpipe driver | 22:07 |
| Limb | wb_m2s_mem_adr <-- I'm assuming the 'mem' is the name of the slave in wishbone? | 22:08 |
| olofk | Should be | 22:08 |
| Limb | guess i should change it back to mem then. thought it had to be wb_ram0 hah | 22:09 |
| olofk | Well, you can name it whatever you want | 22:09 |
| Limb | Right. I thought it had to be named after the instance name | 22:10 |
| Limb | slowly figuring this out :) | 22:10 |
| olofk | Got to sleep now. Good luck | 22:13 |
| Limb | good night | 22:13 |
| Limb | hrmmmm | 22:22 |
| Limb | can synthesize but nothing seems to be connected | 22:22 |
| _franck__ | olofk: don't know if you see it but I updated my pull request. Good night | 22:28 |
| Limb | hrmmm | 22:33 |
| Limb | why isnt it including anything | 22:33 |
| Limb | what the heck am i missing | 22:42 |
| Limb | stekern: you're not around are you? | 22:55 |
| blueCmd | Limb: I think he's in GMT+2 so I wouldn't count on it | 22:58 |
| blueCmd | or maybe even +3 now with summer time | 22:58 |
| Limb | ah | 22:58 |
| Limb | I can get this system to synthesize... but in reality its just blank. the heirarchy in ISE looks right, but it ends up using no slices | 22:59 |
| blueCmd | do you have input/outputs in the top module? that's the only thing I can think of | 22:59 |
| blueCmd | or that it didn't understand that that is the top module | 23:00 |
| Limb | it knows its the top module | 23:00 |
| Limb | https://github.com/Limb/orpsoc-cores/tree/nexys4/systems/nexys4 if anyone can take a look and see what im missing I'd appreciate it | 23:06 |
| --- Log closed Tue Apr 08 00:00:55 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!