| p03sh | Hello! | 00:49 |
|---|---|---|
| p03sh | My name is Sergey Marfin and currently I am trying to port orpsoc to VC707 Virtex-7 Xilinx board. | 00:49 |
| p03sh | I have already tried and have successfully built minsoc for it, had some UART issues, but AdvDebug worked fine through a Platform Cable USB. | 00:49 |
| p03sh | I am having some question regarding porting. As it seems, the Atlys Diligent board has the most common peripherals with my board. | 00:49 |
| p03sh | I would like to start with just a uart, a debug interface and GPIO. | 00:49 |
| p03sh | So, questions: | 00:50 |
| p03sh | 1) Considering modyfing atlys sources, what files and defines should I modify. In minsoc it was the memory defines (BRAM), the BSCAN JTAG defines (which I cannot find in orpsoc), the board.h file, the ucf constraints file, and defines of target FPGA (which I cannot find as well, those are critical for compilation). | 00:50 |
| p03sh | 2) How should I generate clocks? Is it a good idea to use Xilinx Clock Wizard in CoreGen? | 00:50 |
| p03sh | 3) Could you please outline how should I modify the DDR2 wrapper to use DDR3 MIG core interface? | 00:50 |
| p03sh | 4) If it is not that difficult, could someone explain to me the general process of porting orpsoc to other boards? I have multiple, but no support for them whatsoever. | 00:50 |
| p03sh | Thanks in advance, I have a lot more questions though. | 00:50 |
| p03sh | Happy synthesizing! | 00:50 |
| p03sh | System specs : Ubuntu 12.10 Linux x32, ISE+Vivado 14.3, vc707 development board | 00:50 |
| p03sh | Anybody here? | 00:56 |
| p03sh | Hello everyone! | 01:10 |
| p03sh | ? | 01:10 |
| p03sh_ | Hello everyone! | 02:07 |
| p03sh_ | Could I have some help regarding orpsoc synthesis? | 02:07 |
| p03sh_ | Please! | 02:13 |
| stekern | p03sh_: most people here are in europe, so we are sleeping | 05:16 |
| stekern | 1) orpsoc_top.v, the files in boards/xilinx/atlys/rtl/verilog/include, boards/xilinx/atlys/syn and boards/xilinx/atlys/backend/par | 05:21 |
| stekern | 2) look at boards/xilinx/atlys/rtl/verilog/clkgen/clkgen.v | 05:22 |
| stekern | 3) no idea what the DDR3 mig interface looks like | 05:23 |
| stekern | 4) take the board port that is most similiar and modify it | 05:23 |
| stekern | ok, all tests in updated mor1kx-devenv passes, except intloop and exceptionsteptest | 09:14 |
| stekern | juliusb: or1k-shortjump caught 2 bugs ;) | 09:15 |
| stekern | one flag bug (that darn flag), and one writeback bug | 09:16 |
| stekern | hmm, looks like it's something wrong with the delay-slot detection logic | 09:36 |
| stekern | couldn't something like this work? if (padv_execute) execute_delay_slot <= (op_jr | op_jbr | op_jal); | 09:40 |
| stekern | instead of this I mean: https://github.com/juliusbaxter/mor1kx/blob/master/rtl/verilog/mor1kx_ctrl_cappuccino.v#L649 | 09:44 |
| p03sh_ | Thanks, stekern! | 10:32 |
| p03sh_ | Can I use advanced debug system with orpsoc like I did with minsoc? I think it should attach just fine | 10:33 |
| stekern | the atlys board doesn't use it "out of the box", but I've used it with alteras de0 nano board and orpsoc, so if you've got adv_debug_sys working on atlys in minsoc I don't see why that shouldn't work | 10:37 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano | 10:38 |
| stekern | that's the de0_nano board | 10:38 |
| stekern | I just took a look at or1200's pipeline layout, it's weird... | 10:42 |
| @juliusb | p03sh_: look at the documentation in ORPSoC, it explains how to do a board port I think | 11:45 |
| @juliusb | stekern: regarding calculating the execute_delay_slot signal, it's entirely possible your suggestion is good :) | 11:49 |
| @juliusb | but how are you figuring out whether we're taking the conditional branches, etc.? | 11:49 |
| stekern | hmm, does that matter? it's still an delay-slot | 11:52 |
| stekern | but that's perhaps not what the execute_delay_slot is intended to signal | 11:53 |
| @juliusb | these are all good questions | 11:53 |
| @juliusb | it's intended to say that the instruction in the execute stage is in a delay slot, ie. we're about to branch away | 11:54 |
| stekern | hmm, but that's not what SR[DSX] is supposed to show, right? | 11:59 |
| stekern | and that's connected to execute_delay_slot through ctrl_delay_slot | 11:59 |
| stekern | I mean, if an exception happens in the delay slot, it shouldn't matter if the branch was about to be taken or not | 12:00 |
| stekern | it should be re-evaluated after rfe | 12:00 |
| stekern | or have I misunderstood it? | 12:00 |
| p03sh_ | Excuse me one more time, but the ORPSoC manual says absolutely nothing about porting it to other boards. There's nothing about clock generation and work with RAM, except for outlines where the code is | 14:18 |
| p03sh_ | And furthermore, I could not find any platform-specific ram blocks used in the designs, compared to minsoc. Even the atlys example uses generic memory instead of Xilinx BRAM blocks | 14:19 |
| stekern | p03sh_: usually blockram can be inferred from generic code | 14:35 |
| stekern | i.e., there's no benefit of using BRAM macros in most cases | 14:38 |
| stekern | clockgeneration is just taking the incoming board clock and feed it through some PLLs/DCMs to generate the clocks you need | 14:39 |
| stekern | no magic there | 14:39 |
| stekern | andresjacoby: can you please fix your client/connection | 14:59 |
| p03sh_ | hm, that's not what it looks like. using hw macros seems to give at least 50% less synthesis time | 16:11 |
| p03sh_ | how can I find out if generic memory is actually mapped as bram primitives? | 16:12 |
| stekern | p03sh: I have a hard time believing that using BRAM macros instead of instantiating RAMs would decrease synthesis time by 50% | 19:58 |
| stekern | what memblocks are you even speaking about here? | 19:58 |
| stekern | and to answer your question, you can see that in the map report (the .mrp file) | 19:59 |
| @juliusb | stekern: if the synthesis tool screws up and doesn't infer the BRAMs, and instead uses thousands of FFs, the synthesis time can be ridiculous | 20:46 |
| @juliusb | that's what I've experienced anyway | 20:46 |
| @juliusb | regarding the delay-slot thing, yuo want to know if the instruction in the delay slot caused an exception (illegal insn, lsu/error) in which case, yes the RFE will need to go back to the preceeding inst (a jump/branch or something) | 20:48 |
| @juliusb | (otherwise, if an exception is raised during that branch, I think I have made it complete the delay slot instruction, then service in PIC or TT exception, and set the EPCR to the location of where we were branching to) | 20:49 |
| @juliusb | so, that's all - it's just if the guy in the delay slot is going to cause an exception, you want to know if it's a delay slot | 20:49 |
| p03sh | juliusb, exactly what happened with me on minsoc | 22:26 |
| @juliusb | with you on minsoc? | 22:35 |
| -!- Netsplit *.net <-> *.split quits: p03sh | 23:22 | |
| -!- Netsplit over, joins: p03sh | 23:30 | |
| olofk | I'm thinking of starting to document file formats and structure for orpsocv3. Any ideas for what tools to use? There seem to be more than enough to choose from | 23:41 |
| @juliusb | olofk: asciidoc? | 23:55 |
| olofk | Yeah, that could work. I just looked at python's built-in stuff, but that won't handle the configuration files | 23:55 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!