| --- Log opened Sat Aug 22 00:00:10 2015 | ||
| olofk | Ahh... I didn't know about this git feature. That's awesome http://git-man-page-generator.lokaltog.net/#e5ed9b67c89ed9b7c44562b11335e72b | 05:29 |
|---|---|---|
| stekern | mm, especially the --swagger-twist-submodule option is useful | 09:09 |
| olofk | stekern: Yeah, I have been looking for something like that. I just don't understand if that can be used together with --page-serve-ref. Maybe you need to do a git-photograph-tree or import with git-blow-history first | 09:46 |
| andrzejr | guys, has anyone managed to generate a Xilinx API from command line using coregen? I am trying this now and it coregen/MIG is ignoring parameters specified in input files. | 10:31 |
| andrzejr | e.g. memory interface type (uses DDR3 instead of DDR2) and occasionally FPGA device type (6-series instead of 7-series) | 10:33 |
| andrzejr | The latter problem was caused by an incorrect version number (-u parameter). But coregen still keeps generating DDR3 i/f. | 10:54 |
| andrzejr | It works, I copied the following files (for MIG): .cgp, .cgc, .xco, .prj. Command: coregen -r -b xco_file -p cgp_file. I have modified .xco and .cgc files to point at a valid .prj file. | 11:51 |
| andrzejr | coregen in batch mode does not generate the memory model (gui would present a license) but it can be downloaded separately. | 11:53 |
| andrzejr | I've pushed a "coregen" provider/generator to https://github.com/andrzej-r/fusesoc/tree/andrzej-r | 12:16 |
| olofk | I never thought of adding coregen support via a provider | 12:17 |
| olofk | But it's definitely a cool approach | 12:18 |
| andrzejr | We could do the same for wb_interconn | 12:19 |
| olofk | The main drawback I see is that we would need a separate core for every new configuration | 12:19 |
| andrzejr | Yes, we could have cores like atlys_interconn, atlys_ddr2 etc. | 12:20 |
| olofk | But I say we go for it. Better to have something working now, than something "better" that is not implemented yet | 12:20 |
| olofk | I've been talking about that damn generator API for like three years now without getting anywhere with the implementation :) | 12:22 |
| andrzejr | I think the extra core is a small price to pay for flexibility. If we wanted to merge it with other cores then we would have to combine e.g. github provider with some generator mechanism and specify the order of operations. | 12:22 |
| olofk | Yeah, and you're allowed to put all the stuff in the same directory, so we can still logically group all board-specific stuff | 12:23 |
| andrzejr | Am I? I didn't know about it. | 12:23 |
| olofk | And an extra benefit of having a separate core is that we can cram some instance-specific stuff there as well, like IP-Xact models | 12:24 |
| olofk | Yes. file:///home/olof/code/or1k/fusesoc/doc/capi.html | 12:24 |
| olofk | ohh.. that link won't work :) | 12:24 |
| olofk | ...I hope at least :) | 12:24 |
| olofk | But here https://github.com/olofk/fusesoc/blob/master/doc/capi.txt | 12:25 |
| olofk | Or generate the html docs by running make in fusesoc/doc | 12:25 |
| andrzejr | I see, that's neat. I thought cores were assumed to be in ./cores directory | 12:26 |
| olofk | It was like that initially, and the separation of systems and cores are also a remain from the initial implementation, but there's no real need for that anymore | 12:28 |
| andrzejr | how to organize the orpsoc-cores/systems/<system>/ directory? It already contains its own .core file | 12:28 |
| olofk | That's a valid point | 12:29 |
| andrzejr | Put all system-related cores in ./system/<system>-cores/? | 12:29 |
| olofk | Just put all the existing stuff in a subdir perhaps. That would also allow to put variants of Atlys-builds side by side | 12:30 |
| andrzejr | sorry, not sure if I get it | 12:31 |
| olofk | I'm ok with either. We should come up with best practices, but we can always move stuff later | 12:31 |
| andrzejr | which subdir? | 12:31 |
| andrzejr | orpsoc-cores/systems/atlys/system|cores ? | 12:31 |
| olofk | I was thinking about moving systems/atlys/* to systems/atlys/atlys_top (or similar) | 12:32 |
| olofk | gtg | 12:32 |
| andrzejr | OK, that sounds reasonable. thanks. | 12:33 |
| olofk | oh, but wait. You can just put the new coregen .core file in systems/atlys directly | 12:35 |
| olofk | Now I got to go :) | 12:36 |
| andrzejr | yes, that's how I understood your proposal: orpsoc-cores/systems/atlys/atlys_top|atlys_ddr2|atlys_interconn etc. | 12:38 |
| andrzejr | just to clarify - I am not planning to change anything in atlys (this was just an example, besides I don't have this board) | 12:39 |
| andrzejr | Also, I assume all core names still have to be unique, hence atlys_ddr2, not just ddr2 | 12:40 |
| andrzejr | olofk, a bug report (fusesoc crash when fetching vga_lcd with an empty cache): fusesoc --verbose sim --simulator=icarus atlys | 14:07 |
| andrzejr | it is triggered by --verbose option (and the feature I added a couple of weeks ago) and can be fixed by specifying cwd parameter in Launcher constructor | 14:09 |
| andrzejr | (like it is done in the coregen provider) | 14:10 |
| -!- pecastro_ is now known as pecastro | 14:11 | |
| andrzejr | I would like to propose a configuration change to orpsoc-cores: | 14:12 |
| andrzejr | Put fusesoc.conf in the orpsoc-cores directory with the following contents: | 14:13 |
| andrzejr | [main] | 14:13 |
| andrzejr | cores_root = cores | 14:13 |
| andrzejr | systems_root = systems | 14:13 |
| andrzejr | build_root = build | 14:13 |
| andrzejr | cache_root = cache | 14:13 |
| andrzejr | and add build/ and cache/ to .gitignore | 14:14 |
| andrzejr | I find the recommended fusesoc setup with a separate build directory and ~/.cache cumbersome. If someone wants that it is still possible, but IMHO the default should be just "go to the oprsoc-cores and run fusesoc" | 14:15 |
| andrzejr | olofk, pushed a bug fix to my fusesoc repo | 14:41 |
| andrzejr | olofk, there are some issues with exception handling in fusesoc. In several places you are trying to catch urllib.URLError|HTTPError, which does not exist in python2 (in fact, in python3 it is called urllib.error.URLError...) | 15:11 |
| andrzejr | I could "fix" it by replacing all except clauses with except IOError and except OSError. I am not pushing this change because you may want to handle it differently. | 15:13 |
| andrzejr | The problem occurs when e.g. subprocess fails during fetch (git, opencores, coregen) and it triggers exception handling in e.g. bin/fusesoc or fusesoc/simulator/simulator.py | 15:15 |
| olofk | So many things to answer :) | 18:58 |
| olofk | But that's good | 18:58 |
| olofk | Core names must be unique, yes | 18:58 |
| olofk | I don't agree with building stuff in orpsoc-cores. It's the main repo, yes, but there are other projects using FuseSoC that don't use orpsoc-cores at all | 19:00 |
| olofk | And most people shouldn't have to edit stuff in orpsoc-cores at all, except for fixing bugs in the existing cores there | 19:00 |
| olofk | I got a separate tree for all the cores I'm working with, so my fusesoc.conf contains 'cores_root = /path/to/my/staging/tree /path/to/orpsoc-cores' | 19:01 |
| olofk | Oh, and another small thing. systems_root is not really used anymore. | 19:02 |
| olofk | And you're right about the exception handling. I got some reports from other python2 users about the urllib stuff. I think all URLError are handled now, but HTTPError must be fixed as well to be python2-friendly | 19:04 |
| olofk | Thinking again, I guess that I could add a default fusesoc.conf to orpsoc-cores. That won't affect the current setup, but makes it trivial to also use your method | 19:07 |
| olofk | But ideally, I don't really want any code in orpsoc-cores at all. | 19:08 |
| andrzejr | olofk, yes, I meant adding a config file to orpsoc-cores, not changing fusesoc. | 20:09 |
| andrzejr | a question, how to force re-fetch of some cores? (other than deleting them from cache manually) | 20:13 |
| andrzejr | ah, I just noticed you have fixed that urllib issue after I've cloned the fusesoc repo | 20:23 |
| doomlord | would openrisc compile on a Zynq 7010 | 21:28 |
| doomlord | (an openrisc core , of some sort) | 21:28 |
| andrzejr | doomlord, I'm currently working on another 7-series device. Yes, it does work, but since there are no other designs available for this family of devices you would be on your own. | 21:35 |
| doomlord | i'm toying with the idea of getting a paarallella , it has a zynq, the more of interest the zynq can do the better | 21:36 |
| doomlord | i've not dabled with HDL's yet at all | 21:36 |
| andrzejr | by far the most difficult part is to get the ddr2 i/f working. Xilinx have redesign this par so the i/f from atlys board doesn't work. | 21:37 |
| doomlord | i've heard HDL's are flaky to use, a lot of bugs that aren't determined at compile time (more so than, say, C source), is that true? | 21:37 |
| doomlord | i mean its' very easy to write a C program that copmiles, but crashes | 21:38 |
| doomlord | supposedly its even easier to write broken HDL | 21:38 |
| andrzejr | Writing HDL is not hard but if you have never done it before you should start from something simpler. Trying to make a new board working is not a good project for start. | 21:41 |
| andrzejr | what so special about zynq? | 21:43 |
| doomlord | just the fact its on the Parallela board, which interests me for its' epiphany accelarator | 21:44 |
| doomlord | ^ epiphany manycore chip | 21:45 |
| doomlord | it uses the Zynq to interface the eiphany manycore chip to memory. the epiphany chip just exposes its' NoC eLinks to the outside world. They implement DMA channels for it. | 21:47 |
| doomlord | simple projects would be to devise various more elaborate DMA channels (gather indirect data, that sort of thing) | 21:47 |
| doomlord | the idea of an actual opensource CPU is rather interesting | 21:48 |
| andrzejr | what are the cores in that epiphany chip? | 21:48 |
| doomlord | custom , a pretty generic RISC. 64 registers, unified float/int registers | 21:49 |
| doomlord | it has no caches, just local-store, adressable on a grid | 21:49 |
| doomlord | its defining feature is the grid network-on-a-chip layout | 21:49 |
| doomlord | one of the barriers to getting decent software on it is the lack of even an i-cache | 21:50 |
| doomlord | (IMO) | 21:50 |
| doomlord | if i could design my own processor on a whim, it would have that grid & scratchpads, but i-caches at least. | 21:51 |
| andrzejr | I guess you would run the os on Zynq's ARM core and just offload some computation to epiphany, just like with a GPU. If you like to play with software that seems like a fun project, but I don't seem much connection to openrisc here. | 21:52 |
| doomlord | right there is no connection. | 21:52 |
| doomlord | just the fact there's an FPGA , whch could be used to dable with OpenRISC aswell | 21:52 |
| olofk | doomlord: Yeah, I've been meaning to implement an OpenRISC-system on my Parallella as well, but haven't started working on it | 21:57 |
| andrzejr | IMHO openrisc on Zynq doesn't make sense - you've already got a powerful CPU in there, for which you paid 4x the price of a similar FPGA without that CPU. That embedded FPGA is just for glue logic + some hardcoded DSP. | 21:57 |
| olofk | There was a guy a while ago who implemented support for building the Parallella with FuseSoC | 21:58 |
| andrzejr | looks like not everyone agrees with me :-) | 21:58 |
| doomlord | you're right it makes no sense for performance, it woudl just make sense 'to dable with an opensource processsor' | 21:58 |
| doomlord | ^ if you just happen to have a Zynq around, and no other fpga | 21:58 |
| olofk | Agree. It doesn't make sense when you have two beefy ARMs, but it could still be fun, and it could be useful if there comes another board with an Epiphany with a ARM-less FPGA | 21:59 |
| olofk | I was offered a FMC board with an Epiphany for example | 22:00 |
| doomlord | whats that | 22:00 |
| andrzejr | Actually the board itself is fairly cheap ($99), the smallest Zynq is $57 on digikey and they add this extra chip. Not bad. | 22:00 |
| olofk | FMC is a standardized connector that is used to connect peripherals with many I/O | 22:00 |
| andrzejr | (I mean parallella board) | 22:01 |
| doomlord | ok i see | 22:01 |
| olofk | Yeah. I bought the Parallella partly to play with the Zynq since that was quite new when the kickstarter project was run | 22:01 |
| olofk | And this was a cheap way to get that and the Epiphany | 22:01 |
| olofk | Oh well. Got to sleep now. Good night | 22:02 |
| stekern | even with that beefy arm cpu, openrisc on the fpga for other tasks still make sense | 22:27 |
| andrzejr | stekern, do you have any specific examples? IMHO it would make sense if it was e.g. power efficient. | 22:36 |
| andrzejr | of course if it was a hard macro that is a completely different story - I'd love to see an open CPU with an open FPGA on the same chip. | 22:37 |
| doomlord | if you cared about performance, surely the FPGA would be best directly implmenting functions, rather than running a softcore | 22:42 |
| --- Log closed Sun Aug 23 00:00:12 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!