| --- Log opened Sat Sep 03 00:00:54 2016 | ||
| SMDhome1 | olofk: clear_ram was introduced due to problems w/ uninitialized ram in dhrystone, so it's required. At least for icarus | 02:16 |
|---|---|---|
| wallento | There is a bug in vivado so that it crashes only on haswell processors (at least in ubuntu): https://github.com/MyrtleSoftware/glibc-no-lock-elision | 03:59 |
| olofk | SMDhome1: Yeah, you're right. It's probably safest to use clear_ram, but for most programs it shouldn't be needed | 07:32 |
| olofk | Can you sign up for as many accounts as you like on github? | 08:11 |
| wallento | olofk: you want more likes for fusesoc? ;) | 08:14 |
| olofk | FuseSoC is a stronger brand name than I am :) | 08:17 |
| olofk | With the changes to versioning, I'm considering freezing orpsoc-cores now and move the cores I want to keep to a new repo | 08:17 |
| olofk | And that could also be a good time to first of all rename it to fusesoc-cores or something like that | 08:18 |
| olofk | And also to create a new account that contains just FuseSoC-related things. I fear I'm getting close to the 50-repo limit | 08:18 |
| olofk | wallento: I took a look at your forked FuseSoC repo btw. Would it be much work to rebase that on latest fusesoc master? | 08:21 |
| olofk | And great blog post. Good work by you, Philipp and the others | 08:21 |
| wallento | I will do this today I think | 08:24 |
| wallento | I started my personal fusesoc_cores repo too | 08:24 |
| wallento | with subfolders: boards, systems, cores | 08:24 |
| wallento | and I started using some more hierarchy in cores | 08:24 |
| wallento | with the new vlnv scheme | 08:24 |
| wallento | I will put something in the Wiki of my repo about the new system=board+core abstraction I use | 08:25 |
| olofk | I liked the idea to separate boards and systems | 08:26 |
| wallento | my current plan is (mor1kx,pulpino,lowrisc)->(arty,nexys4,kc705) | 08:27 |
| olofk | ok, I did a diff of our repos. These are the functional differences that I found | 08:28 |
| wallento | you still need the toplevel glue logic in a "system", but it shouldn't be too much of a problem for now | 08:28 |
| olofk | Vivado, DPI, verilator use sim instead of synth, xsim project mode, skip empty core directories, lists-paths, FUSESOC_CORES env var | 08:28 |
| olofk | Yes. I don't want to spend too much effort trying to make FuseSoC to clever things with top-level glue logic | 08:29 |
| olofk | Better to handle that manually or with IPXACT | 08:29 |
| wallento | yes, agree | 08:29 |
| wallento | olofk, any of those you don't want in FuseSoC at all? | 08:30 |
| olofk | Might be | 08:30 |
| olofk | The verilator sim vs. synth thing might already be too late | 08:30 |
| wallento | yes, I can double check that | 08:31 |
| olofk | since it will break backwards compatibility to change it now. | 08:31 |
| wallento | it is no pain to have synth and sim for what I would consider sim-only, right | 08:31 |
| olofk | And you know I'm not a big fan of env vars, but I might give in to pressure on that one :) | 08:32 |
| wallento | It makes it way easier for us | 08:32 |
| wallento | otherwise we would wrap the fusesoc call | 08:32 |
| wallento | also possible | 08:32 |
| olofk | Or just create a fusesoc.conf | 08:32 |
| wallento | actually we don't want to bother users to much with such things | 08:33 |
| wallento | especially if the file is always the same | 08:33 |
| wallento | or he has to change something in his home config or so | 08:33 |
| wallento | it is way easier to just put it into our env.sh | 08:33 |
| wallento | because that is something we always need | 08:34 |
| wallento | ah, I saw your issue reply, by the way: opencores mailing lists are dead now | 08:34 |
| olofk | oh | 08:34 |
| olofk | Which reply do you mean | 08:35 |
| olofk | ? | 08:35 |
| wallento | you directed someone to the new mailing list | 08:35 |
| wallento | I tried to cross post to the old | 08:36 |
| wallento | just came to my mind now | 08:36 |
| olofk | Can't you put this in your env.sh? :) echo -e "[main]\ncores_root=something" > fusesoc.conf | 08:37 |
| wallento | naaa | 08:37 |
| wallento | that would do something in the current folder | 08:38 |
| wallento | it should just be known to the environment :) | 08:38 |
| olofk | I give up | 08:38 |
| wallento | thats good | 08:38 |
| wallento | ;) | 08:38 |
| olofk | You can have your damn env var :) | 08:38 |
| wallento | otherwise I would fork it :-D | 08:38 |
| olofk | You already did!! | 08:40 |
| olofk | Maybe we should pick up the env var in config.py instead, where all the other path trickery is | 08:41 |
| wallento | yes, I can check it later. my computer is currently un-nice as I am building android in "background" | 08:42 |
| olofk | oh dear | 08:42 |
| wallento | its unbelievable this sh*t actually works on a gazillion of phones.. | 08:43 |
| olofk | :) | 08:43 |
| olofk | So from my perspective it would be easiest to first add the path stuff, then switch over xsim to project mode (if you can justify that change), add the Vivado backend and finally we can talk about how to best implement DPI | 08:44 |
| ZipCPU|Laptop | wallento: Have you made any progress with the Arty memory, or am I the only one trying to get that to work with wishbone? | 08:49 |
| olofk | ZipCPU|Laptop: I think he's using a wb to axi bridge | 08:55 |
| olofk | I know that andrzejr tried to make a wishbone wrapper to the Xilinx UI interface instead | 08:56 |
| olofk | And I think that the full open source controller that _florent_ et al has been working on has a wb interface as well | 08:56 |
| ZipCPU|Laptop | _florent_ has been working on ... a DDR3 open source controller? | 08:57 |
| olofk | ZipCPU|Laptop: Yes. I'm sure I've mentioned this before. Not sure if _florent_, mithro or someone else should get the credit for that one though | 08:57 |
| ZipCPU|Laptop | Fascinating. | 08:58 |
| olofk | It's based on migen | 08:58 |
| ZipCPU|Laptop | migen ... do you have a link for that? | 08:58 |
| olofk | https://github.com/m-labs/migen | 08:59 |
| olofk | It's a python framework to do RTL designs | 08:59 |
| ZipCPU|Laptop | Got it. | 08:59 |
| olofk | It can output verilog | 08:59 |
| ZipCPU|Laptop | What I'm now struggling with is the interface between logic and I/O. | 08:59 |
| olofk | The main usage is to build complete SoCs in that language, but it can also be used to generate stand-alone cores | 08:59 |
| ZipCPU|Laptop | Xilinx built some very nice hardware helpers ... but then declined to document any of them. | 08:59 |
| olofk | Oh yes. It's horrible | 09:00 |
| ZipCPU|Laptop | At least they made their code available ... it seems like the entire MIG generated code gets delivered in any MIG project. | 09:00 |
| olofk | yep | 09:00 |
| ZipCPU|Laptop | The differences being only the configuration. They're not even excluding parts that aren't in use--just give you everything. | 09:01 |
| olofk | But they're using some undocumented primitives, at least in the virtex-6 backend | 09:02 |
| olofk | And also, the interface towards the user differs between the FPGA families | 09:02 |
| ZipCPU|Laptop | They're doing there's on a Virtex-6? | 09:02 |
| olofk | I mean MIG | 09:03 |
| ZipCPU|Laptop | The 7-series phy is significantly different from the 6-series, or so Xilinx says ... | 09:03 |
| ZipCPU|Laptop | Oh ... got it | 09:03 |
| olofk | Sure, the phy is of course different, but they also change the user interface between EDA versions and FPGA families | 09:03 |
| wallento | ZipCPU, yes, mig and wb2axi | 09:03 |
| wallento | works okay for now | 09:03 |
| wallento | I had my months with the mig user interface in virtex5 and spartan6 already... | 09:04 |
| olofk | So a straight-forward upgrade from a MIG targeting V5 to one targeting V6 turned out to be a complete mess | 09:04 |
| ZipCPU|Laptop | "a complete mess" --- thank you for your pleasant, but accurate, description. ;) | 09:05 |
| ZipCPU|Laptop | wallento: Ever thought about pipelining the wb2axi controller? To see if you couldn't achieve a throughput of one access per clock? | 09:10 |
| wallento | yeah, of course | 09:21 |
| wallento | its just a start to ramp up | 09:21 |
| wallento | next is bursts and timing decoupling | 09:22 |
| wallento | Always looking for help of course :) | 09:24 |
| wallento | bursts are better in the other direction actually, but I think we can easily support the default fixed-size bursts | 09:24 |
| wallento | burst reads of undetermined length are the hardest, it means doing speculative reads | 09:25 |
| ZipCPU|Laptop | If you are interested in help, then I'd love to try my hand at it. I would need, however, a good reference document describing the ARM AMBA interface. Any suggestions? | 09:50 |
| ZipCPU|Laptop | My goal would be to support WB4 pipeline mode--which is what I'm using with all my work. | 09:51 |
| ZipCPU | Here it is: http://www.gstitt.ece.ufl.edu/cvourses/fall15/eel4720_5721/labs/refs/AXI4_specification.pdf | 10:32 |
| ZipCPU | s/cvources/courses/ | 10:35 |
| olofk | Unknown burst lengths in wb is a pain | 10:43 |
| olofk | The quickest solution would probably be to just add a burst length signal | 10:44 |
| olofk | But I've been thinking quite a lot about this | 10:44 |
| ZipCPU | I can handle unknown burst lengths ... | 11:29 |
| ZipCPU | The first version I built of the DDR3 controller (of the many attempts I've made) handled grabbing 32-bits of a 128-bit access without much hassle. It even handled pipelining across all 128-bits. (If you requested all four, you got all four, if you requested fewer you got fewer). My point: it's quite doable. | 11:31 |
| ZipCPU | The issue is knowing the natural data rate of the interface. | 11:31 |
| wallento | yeah, but for mapping to axi it is an issue | 12:11 |
| wallento | but as you say, it is still possible to do it | 12:11 |
| wallento | olofk, isn't bte or how its called meant for that | 12:12 |
| wallento | I remember there was something like 8 beat wrap bursts | 12:12 |
| wallento | the cache should do those | 12:12 |
| wallento | and the core can have a parameter like DEFAULT_BURST_LEN | 12:12 |
| wallento | What I am undecided about is a real good test strategy | 12:24 |
| wallento | olofk: does the wb bfm handle such wrap bursts? | 12:41 |
| wallento | already found it, it does | 12:47 |
| andrzejr | olofk, ZipCPU, wallento, I indeed tried making the WB->UI bridge but the version that works "reliably" has burst capabilities disabled. | 13:03 |
| andrzejr | I've solved some errors with bursts but afair there was still something wrong with the bridge. | 13:04 |
| andrzejr | On top of that, the DDR2 controller had some issues on its own (seeing only half of the memory etc). | 13:05 |
| ZipCPU | andrzejr: Can I see how far you got? I'm studying AXI now for this purpose ... | 13:37 |
| andrzejr | ZipCPU, https://github.com/andrzej-r/orpsoc-cores/tree/nexys4ddr/systems/nexys4ddr/nexys4ddr_ddr2_wb/rtl | 15:12 |
| andrzejr | "wire classic = wb_cyc_i & wb_stb_i & wb_cti_i == WB_CLASSIC;" in *wb_to_ui.v enables bursts | 15:14 |
| andrzejr | But if you want efficiency, you should avoid using wb bus between cpu's cache and memory in the first place. Both axi and ui busses are much better for that purpose. | 15:16 |
| ZipCPU | andrzejr: "HTTP request sent, awaiting response... 404 Not Found" | 15:22 |
| ZipCPU | Is that the right address? | 15:22 |
| andrzejr | yes, strange, works just fine here. | 15:24 |
| andrzejr | try to dig down to it starting from https://github.com/andrzej-r | 15:24 |
| ZipCPU | Under tree, I get an error. Under systems, I don't see nexys4ddr. | 15:27 |
| ZipCPU | Okay ... I might've found it ... | 15:28 |
| ZipCPU | Okay, I've got it now. Funny, cloning andrzej-r didn't get it .... | 15:29 |
| andrzejr | BTW, the controller files are in https://github.com/andrzej-r/orpsoc-cores/tree/nexys4ddr/systems/nexys4ddr/nexys4ddr_ddr2 | 15:32 |
| andrzejr | not sure if that works with the current version of fusesoc (they rely on ISE code generator/provider for producing the code) | 15:33 |
| ZipCPU|Laptop | Well ... I have somewhat of a DDR3 simulation, THAT WORKS, in Verilator in the wbddr3 project. | 15:35 |
| andrzejr | It's probably best to use Vivado for that these days. Potentially the reason for problems with the DDR controller I was seeing in the past. | 15:35 |
| ZipCPU|Laptop | The problem is it doesn't match the Xilinx interface--and wouldn't know what to do with it. | 15:35 |
| ZipCPU|Laptop | andrzejr: Did you do anything to handle out of order responses? | 15:50 |
| andrzejr | No. UI spec (supposedly) guarantees there are no out of order responses. | 15:51 |
| ZipCPU|Laptop | WB UI, or AXI UI? WB certainly makes that guarantee, does AXI? I thought MIG did not ... | 15:51 |
| andrzejr | My code does not use AXI. It's a direct bridge from WB to UI. | 15:52 |
| kc5tja | What does UI stand for in this context? | 16:45 |
| andrzejr | kc5tja, a custom bus Xilinx uses for their DDR controllers | 16:50 |
| --- Log closed Sun Sep 04 00:00:56 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!