MiSTer FPGA Forum

there should be automated wrapper construction for the usual de10nano intel cyclone-v fpga cores,
to fit other similar cyclone-v containing evaluation boards, like arrow sockit and de10standard.

simply this would be a wrapper for each fpga soc platform, sockit and de10standard, so the normal
pins and interfaces are re-routed to the appropriate devices, nothing more, a mostly the core output will be similar.

this is because the exact details of the fpga socs differ, namely:

de10nano kit: Intel Cyclone V SE 5CSEBA6U23I7 device (110K LEs)
arrow sockit: Cyclone V SX SoC—5CSXFC6D6F31C6N (110K LEs)

at least in the sockit the cores can be routed to use the dedicated onboard DDR3 1GB ram.
yes the latency will be approximately same in nanoseconds, 10-20ns for both SDR and DDR3.

this way there would not be any extra work to port the cores directly to similar and new, more powerful fpga socs.

This falls under the heading of “easier said than done”.
But I think most people won’t be able to appreciate all of the myriad ways in which this is difficult until they roll up their sleeves and see for themselves, so I recommend that you take a close look at how you might approach it in detail, and how to overcome some of those hurdles.

I agree that this would be a nice thing, and ultimately a way to migrate to other architectures in future, but it’s a substantially larger task than I would be willing to undertake (speaking for myself), plus necessary compromises ending in a second framework to support.

nope its easy, no need to make it harder than it is, and also, no making of servants because of pride reasons, thanks

whats the diffculty, you literally just take the original fpga wiring, and fit the correct wires. have fun, because I know you want to do it

and my purpose is to someone, anyone, or even me, just a reminder that this can and should be done, just saying to do reminder.

edit: even more close look, two cyclone v chips have very similar inputs and outputs, so this should be a nice easy exercise, before anything other considerable different fpga boards. all fpga code, vhdl, should be portable in general, tho.

I do also have the arrow sockit system, so I will actually attempt to check out the wrap core port system.
Again, this should be the way to do it, as a strong suggestion.

also upgrading to a newer same base architecture fpga from intel should not pose issues.
something like Arria or maybe Stratix series, or even higher power version from the Cyclone v family of fpga socs, in the future.

Arria 10 sockit from terasic looks like the next level.

I actually suggest that there is a vhdl direct patcher to convert the underlying de10nano design to any other platform, through the wrapper.

goofyseeker3 wrote: ↑Sat Jul 23, 2022 7:28 pm nope its easy, no need to make it harder than it is, and also, no making of servants because of pride reasons, thanks
whats the diffculty, you literally just take the original fpga wiring, and fit the correct wires.

Hey, be my guest if it's so easy. If you can do this, you're a lot more advanced than I am at this.
Literally, I'm not saying not to. Don't take this as a negative comment. You will learn a lot.

goofyseeker3 wrote: ↑Sat Jul 23, 2022 7:28 pm have fun, because I know you want to do it

Haha ! that's my line !

dshadoff wrote: ↑Sat Jul 23, 2022 8:36 pm You will learn a lot.

Did I tell you that I'm a semiconductor university master.

Crack on then pal

Hackshed_Carl wrote: ↑Sat Jul 23, 2022 9:40 pm Crack on then pal

I'm on it, dev environment set up

whats the deal with the template not being for the quartus prime lite 21 version.

edit: I would suggest to update to HLS on Quartus Prime 21.1 (high level language synthesis) to accelerate and make the development/support simpler. Again, the only thing you do after the compilation, you wire the outputs to proper places, like I suggested.

just leaving this here: pcie slot expansion to the fpga-side, so that any gpu stuff can be run directly on the gpu, any api, or even use HPS side software apis, vulkan, opengl, on the linux, or some emulated/adapted direct3d, 9/11/12

I'm pretty sure PCIe is clocked way, way too fast to be implemented in FPGA.

only if the fpga (Cyclone V SE) had transceivers, or hard PCIe controllers.

the SX version of Cyclone V has PCIe controllers included, 1 or 2, the sockit version.
from the Cyclone V Overview manual: "The PCIe Gen2 x4 support is PCIe-compatible."

Just a suggestion how the gpu hardware emulation issue should be handled.

also just leaving this here: java virtual machine core