Hello!
This is the second time I post this, since it seems the first one was not approved. Please, approve, there's no spam here.
My name is Sergey Marfin and currently I am trying to port orpsoc to VC707 Virtex-7 Xilinx board.
I have already tried and have successfully built minsoc for it, had some UART issues, but AdvDebug worked fine through a Platform Cable USB.
I am having some question regarding porting. As it seems, the Atlys Diligent board has the most common peripherals with my board.
I would like to start with just a uart, a debug interface and GPIO.
So, questions:
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).
2) How should I generate clocks? Is it a good idea to use Xilinx Clock Wizard in CoreGen?
3) Could you please outline how should I modify the DDR2 wrapper to use DDR3 MIG core interface?
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.
Thanks in advance, I have a lot more questions though.
Happy synthesizing!
System specs : Ubuntu 12.10 Linux x32, ISE+Vivado 14.3, vc707 development board

To port ORPSoC to a new board, you'll need to at least get the RTL set up right (instantiating the appropriate primitives for the technology - I'm not too familiar with Virtex 7 yet, so I can't comment on how portable the Atlys/Spartan 6 stuff will be) and then have a UCF to hook up the pins correctly (clock... I'll deal with the clock generation stuff below, and reset etc.) and of course the scripts to run it.

I'm not clear on this (Xilinx don't make it easy to understand either) but I'm not sure if the usual tools in ISE will work with XC7VX485T, or whether you'll need that new beast, Vivado. If you need Vivado, then ORPSoCv2's scripts won't work with it (it's TCL-based AFAIK).

Regarding the debug chain, I'm not sure, Stefan Kristiansson did the Atlys port and I'm not familiar with the debug arrangement on it.



Just instantiate the appropriate management macro. I presume Virtex 7s have DCMs. They're usually pretty easy to just plonk down and connect up as needed.

You'll find the RTL which manages this in the board's rtl/verilog/clkgen/clkgen.v file.



This is a pretty heavy task. Xilinx's MIG controllers vary from generation to generation. They are also usually pretty complex and don't work out of the box, so need a bit of massaging to get going. It's almost impossible to do without the board to test what works and what doesn't. So I'm afraid you're largely on your own here. The DDR2 wrapper, though, isn't that complicated, and (if it's like the one in the ML501) is just a cache and a Wishbone interface.



As I mentioned above, an overview of the board port process (if based on an existing one) is that you first get your RTL into shape by checking that you're instantiating only the appropriate tech-specific macros and have an appropriate memory controller and debug connector (simulate as much as possible), then get your I/O constraints and your scripts in order.

Julius

Julius, ISE works fine. I've been able to port minsoc, though could not get the UART to work. I was not aware that 501 project uses DDR2 as cache, why is that? I though you should use on-chip memblocks for that. Anyways, thanks for the input, I will post any results I get.

You misread what Julius wrote, the DDR2 is not used as cache,
the DDR2 wrapper has a cache (implemented as blockram).
And it has nothing to do with the processors instruction and data cache,
think of it as a "L2 cache".

Creating an ISE project from the RTL sources (or importing the .xst file from PlanAhead) can simplify the porting process.

Hello Sergey,
Did you manage to get it work on vc707? We're planning to do the same thing and it will be great to hear from you if it is really feasible.

Thanks,
Chen