Question about FPGA

[Anonymous No.5940141]

I was wondering if it would be possible to make a fpga card that plugs into your PCI-e slot?

[Anonymous No.5940146]

>>5940141
absolutely.
https://www.bittware.com/fpga/xilinx/boards/..
i'm honestly surprised FPGAs aren't integrated into CPUs these days.

[Anonymous No.5940154]

>>5940141
It would be pretty cool if it had some kind of mame integration.

[Anonymous No.5940159]

>>5940146
These boards are beautiful. Dedicated emulation boards...
I wonder how they compare to the one in this picture

[Anonymous No.5940170]

>>5940159
The main difference is probably that there are people setting this emulation board up as a turn-key kit. Once someone wants to get creative on their own devices, they have to know how to make everything work from scratch.

[Anonymous No.5940274]

>>5940170
Can't you do that on a x86 Linux/Windows machine?

[Anonymous No.5940280]

>>5940274
Emulation without fpga?
Yes easily.

With using some fpga you bought somewhere?
Dunno???

[Anonymous No.5940294]

>>5940280
No, I mean using the FPGA PCI-e card as some sort of emulation accelerator.
Run an emulator on a desktop PC that makes use of the FPGA card to do the work.

[Anonymous No.5940296]

>>5940294
That's the question. FPGA's are programmed to simulate circuits. There may or may not be some universal driver or language that you can throw at just any FPGA. Or maybe you need to have special instructions for the exact FPGA you decide to use.

[Anonymous No.5940321]

>>5940296
but it can be done, right?
it just seems like such an obvious idea, there must be a reason as to why it isn't being implemented

[Anonymous No.5940331]

>>5940321
I guess so. There's just things you have to account for. There might be a question of performance vs cost. The dedicated board is made for the exact arcade function. A pcie board that exists today, might have been made for something on an enterprise scale.

[Anonymous No.5940380]

>>5940321
programming a hardware description language (HDL) can almost look like a C program (for Verilog it tries to look like C). any software program can be hardware accelerated. the hardest part is tracking down the specs for hardware you want to emulate on FPGA

[Anonymous No.5940386]

>>5940380
I see. I'm a complete layman on the subject, but as I understand, there are products out there that allow you to use a FPGA chip to emulate several different machines. The early amiga computers, atari st, SNES, Genesis, old british home computers, etc

https://www.youtube.com/watch?v=e5yPbzD-W-I

[Anonymous No.5940390]

>>5940386
I have an FPGA dev kit. You can allocate a CPU core to my ancient Cyclone IV and still have 95% of the logic units unused. Computer hardware is fairly simple to understand once you get the basics down.

If you want to learn about digital circuits and how to build a computer from the logic gate up, watch Chris Terman's excellent MIT 6.004 lectures
https://www.youtube.com/watch?v=CvfifZsmpQ4

[Anonymous No.5940395]

>>5940141
Apple is doing it on the new Mac Pro to speed up video encoding

[Anonymous No.5940396]

>>5940321
FPGAs are used as gaming hardware to avoid operating system overhead that normal emulators deal with. If you put a FPGA in a computer the overhead would return and then its no better than using a regular emulator. Classic games are very lag sensitive so the less PC hardware bogging things down the better.

[Anonymous No.5940404]

>>5940396
but you still need an operating system, no?
The MiSTer page says it runs linux to take care of the IO and file systems
https://github.com/MiSTer-devel/Main_MiSTer/wiki

"Linux on ARM provides support for many I/O devices and file systems."

[Anonymous No.5940417]

>>5940404
The Linux system does control inputs currently and does add some slight overhead to the input. There continues to be development of direct FPGA to serial port adapters which will remove that entirely where controllers will only interface with the FPGA itself and not the Linux end. I'm not sure any of those are out yet or not.

Games do run at their correct speed on MiSTer even if there is slight delay on input.

[Anonymous No.5940423]

>>5940404
>but you still need an operating system, no?
if it's a PCI card, of course. but FPGAs don't need operating systems.

[Anonymous No.5940427]

>>5940423
how do you load in games then?

[Anonymous No.5940435]

>>5940427
You have to buy an SDRAM card for the MiSTer for most of the cores. That SDRAM is directly interfaced to the FPGA and avoids the ARM I/O.

[Anonymous No.5940437]

>>5940427
I could have a PCB manufactured that's populated with
>a FPGA
>a SD card slot (for roms) or a cartridge slot
>a usb port (for controllers)
>a digital to analog converter (DAC) for video
>another DAC for audio
>a few jacks to hook up the A/V
>and a power supply

[Anonymous No.5940439]

>>5940435
so there would be no benefit?

[Anonymous No.5940445]

>>5940439
Not sure what you mean. MiSTer is cheaper than buying a decent computer for emulation and in many cases is more accurate and less laggy.

[Anonymous No.5940447]

>>5940146
It's on intels roadmap actually

[Anonymous No.5940456]

>>5940445
I'm not sure if I conveyed my idea properly.
What I'm thinking of is a dedicated emulation FPGA PCI-E card that you plug in your desktop computer.
What that provide any benefits when compared to software emulation?

[Anonymous No.5940458]

>>5940456
I would doubt it since you have operating system overhead added to that FPGA setup. At that point just use a regular emulator.

[Anonymous No.5940459]

>>5940458
Not even accuracy-wise?

[Anonymous No.5940462]

>>5940456
FPGA can cycle-accurate emulate a console with custom circuitry. CPU likely runs a time-sharing OS that runs a program that roughly emulates what console hardware does, with all the memory management being handled by a hierarchy of software and hardware optimized for general purpose computing, and not any particular task.

[Anonymous No.5940467]

>>5940462
this is really confusing

[Anonymous No.5940469]

>>5940141
Yes it would be. And I think it is only a matter of time before this sort of thing becomes popular. And profitable. If I had the resources to go forward with a project about I would freakin' do it right now.

[Anonymous No.5940470]

>>5940459
Depends on the emulator being used. Some are pretty good at what they do. Some FPGA cores may be poorly programmed as well.

I would not want to stick a MiSTer or similar onto a PCI-E board in any case.

[Anonymous No.5940474]

>>5940470
Why not? Would it be that bad?
how does the MiSTer amiga core compare to fsuae and winuae?

[Anonymous No.5940475]

Imagine this
>PCI-E add-in card
>on-board FPGA for system(s) of your choice
>hardware and software integration to do everything you can currently do with emulators such as scaling, shaders, USB controllers, recording save states, etc
>combine it with USB cart reader if you're an ethics fag

"Why not just use an emulator"? You ask. Because this IS an emulator. Fuck off with your "FPGA is not emulation" bullshit. Look up what the word emulate means in the diction. This is the next evolution of serious enthusiast-tier emulation.

[Anonymous No.5940480]

>>5940141
>muh fpga magic
zoom

[Anonymous No.5940482]

>>5940474
There would just be no benefit to an FPGA being in a computer with all the processes it has to run in addition to whatever you want to play.

I don't play anything Amiga. The place to go for information on MiSTer is atari-forum.com.

[Anonymous No.5940486]

>>5940482
No commercial computer can do cycle-accurate software emulation of even an SNES. Having hardware that can would be beneficial.

[Anonymous No.5940487]

>>5940486
*cycle-accurate in real time

[Anonymous No.5940489]

>>5940486
i thought bsnes was cycle accurate

[Anonymous No.5940494]

>>5940482
If the system is configured properly you can bypass most of the software layers and play on the "bare metal" with video passed through directly from the GPU. Controller lag would be the bigger issue, but there are ways around that.

[Anonymous No.5940776]

>>5940146
those bittware boards are expensive as fuck. used an XUP-VV4 on a work project, the thing was at least 30 grand. total beast though.

[Anonymous No.5940958]

FPGA engineer here. Here's some general facts that anyone interested in using them for emulation should know about before taking a stance on this.

>The clock rate of your design is determined by the depth of your critical path and the FPGA you are using; it is not uncommon to see complex FPGA designs running at 300+ MHz nowadays.

>FPGA's on the market vary a huge amount in terms of available resources. Modern FPGA's have ~100K - 500K LUT's on them, ~5 - 25 Mb of on-chip memory (BRAM), and ~500 - 1500 DSP's. Just as a point of reference, a DDR4 memory interface module from Xilinx takes up about 10K LUT's and 100 KB of BRAM.

>In FPGA's, LUT's are the main resource of interest. LUT's are "look-up tables" that can be assigned arbitrary M-bit outputs for a given N-bit input. LUT's allow for FPGA's to be reconfigurable, and are analagous to singular logic gates in ASIC designs.

>FPGA vendors usually include ASIC modules on the same chip to handle common functions. Xilinx for example sells FPGA's that contain ARM CPU's built-in, and it is possible to memory map registers from your FPGA to the CPU's address space. Additionally, the FPGA can generate interrupts that the CPU can react to.

>5 Mb of on-chip memory may not sound like much, but consider the fact that all of it can potentially be read every clock cycle depending on how your design utilizes it. Assuming that 25% of the memory gets read every clock cycle, that's 1.25 Mb * 300,000,000 Hz = 375 Tb/s = 46.875 TB/s, an absolutely absurd amount of throughput. In practice though, that throughput will be shared amongst 1000's of different pipeline stages doing internal calculations for different modules, so it is not like you'll have a singular module with such an ungodly throughput from input to output.

[Anonymous No.5940959]

>>5940958
>In general, FPGA designs excel at high-throughput activities. It is critical to understand every pipeline stage of every module placed in an FPGA is running simultaneously. It is not like software where only the function on the top of the stack is being executed. Consider that if you use 100 DSP's to make 100 modules that can add / multiply 2 16-bit numbers at 300 MHz, you are generating adder outputs at 60 GB/s (with a latency of maybe ~1-3 clock cycles).

>The fact that every module is running at once allows for FPGA designs to achieve extremely low latencies in response to a given value changing. While a CPU may get tied up in handling one or more interrupts, 100's of FPGA modules can potentially be waiting to respond to an event at the same time. By the time the CPU starts handling a 2nd interrupt, the FPGA could have handled all 100 of those comparable events. Additionally, while polling is very common in software, it is very uncommonly needed in FPGA's.

>You can have asynchrounous clock domains in an FPGA design, and their output data can be resynchronized with asynchrounous FIFO's. This is something that can only be crudely approximated in software with time-sharing techniques, a fact often underappreciated. Basically, if you need certain values to be produced at some weird rate like 77.89 MHz and some other values to be produced at another weird rate like 121.45 MHz, you can do that.

>In software, a program could be issuing millions of instructions to load registers in preparation for performing other instructions. In FPGA's, this behavior does not exist. Every register in an FPGA design has its input tied to the output of some other register being passed through a chain of LUT's/DSP's/etc. I.e., every register is implicitly loaded all the time without executing instructions to do so. Think circuit diagram, not a sequential list. This fact alone allows an FPGA design to potentially drop power consumption by 10x for the same design in software.

[Anonymous No.5940960]

>>5940959
>The fact LUT's are used in FPGA's causes signal routes to be longer compared to the equivalent ASIC design. Ergo, the configurability via LUT's in FPGA's has the penalty of longer crtical paths. This reduces the max clock rate of the design. So an FPGA design can lose to a software design in long serial processes. This is why a great deal of FPGA designs communicate to on-chip/off-chip ASIC's (like the previously mentioned ARM CPU's).

>Another motivation for communicating to a CPU is that certain things are a huge pain-in-the-ass to implement on FPGA's. VHDL / SystemVerilog are very spartan compared to something like C, so having a CPU available in the design is good for the engineers' sanity.

>To access larger amounts of memory in an FPGA design, it requires adding a controller for an external memory chip. It is possible to have multiple memory controllers in a single FPGA design, with the main limitations being the available IO pins, the number of available LUT's, and the cost of the external memory chips themselves. However, just because a memory controller is in the FPGA design does not mean every module can read/write to it care-free. For one, inefficiently wiring 100's of modules directly to a memory interface will cost tons in LUT's for signal routing. Besides that, there are limits to how many addresses a given memory interface can read/write at once, and you don't want read/write collisions happening all over the place. So often what will happen is that some sort of memory-manager module will be implemented / placed before the memory interface(s), and a hierarchy of modules passing information to one another will be implemented to get data to the memory-manager-whatever. Point is, yes you can access GB's of memory in an FPGA design, but the wide-majority of modules in your design will not be reading directly out of that memory.

[Anonymous No.5940961]

>>5940960
>The previous point leads to one of the major differences between writing software and hardware designs. In hardware, your module will often not be reading out of your main address space, and will instead issue requests for data from its neighbors in the module hierarchy. For modern software, you almost never have to manually consider which address space you are working with. This is another reason why working with hardware can be a huge pain in the ass. (Things like AXI interfaces are very helpful though).

>Compiling hardware designs (AKA "synthesis" and "implementation") can take hours to perform. While loading a compiled bitstream onto an FPGA can be done in seconds, making that bitstream is a real chore. This is why simulators are highly valuable when designing hardware.

> As a very unfortunate circumstance of computer history, almost all parts of a modern FPGA development tool-chain are proprietary and expensive as fuck. Project IceStorm for synthesis and Verilator / Icarus Verilog for simulation are notable exceptions. IIRC, IceStorm only works with some very basic FPGA's, though.

>There were rumors that Intel was going to push FPGA's as a standard component in their CPU's due to their acquisition of Altera in 2015. However, nothing seems to be occurring on that front. If this were to happen, that would be a massive game-changer for FPGA's.

[Anonymous No.5940962]

>>5940961
If you were to ask me if FPGA's are useful for emulation, I'd say yes. But, the emulator would probably have to have a non-trivial portion of it running on a CPU/GPU. The best way to go about developing something like this would be splitting out parts that are potentially-FPGA-bound into separate blocks, but implementing them all in software first. The software implementation can later be used to verify an FPGA module, and allow the software to be run in the event of missing FPGA acceleration.

One thing to consider is that for modern consoles, their hardware has become more comparable to desktop PC hardware. You no longer have weird chips producing weird data at their own weird rates in a way that can't be done on a PC. So if FPGA's are only useful for simulating older hardware, maybe the window of oppurtunity has already passed. Sure, CPU's may be inefficient at the emulation, but if it is 1000x faster anyway, who cares? Who knows, maybe there's werid hardware quirks that still aren't simulated correctly. I think your desired level of accuracy also matters; absolute perfection might require an FPGA.

[Anonymous No.5940984]

>>5940958
Alright, my calculation is really stupid here. I was thinking of distributed LUTRAM when I wrote this, but the total size I used was for BRAM. With LUTRAM, you can have basically arbitrary read/write port sizes. With BRAM, the size of the read/write port are fixed. If you have 150 BRAM tiles with 72 bit wide RW ports, it's 405 GB/s, not 46.875 TB/s.

[Anonymous No.5941014]

>>5940958
>LARPer summarizing some retarded quora shitskin shitposter here.
FTFY

[Anonymous No.5941067]

>>5940962
>I think your desired level of accuracy also matters; absolute perfection might require an FPGA
This! This has been giving me a headache for the longest time.

The idea of recreating old hardware is exhilarating! I would so want some of my old hardware in my current rig.
Give me a FGPA Soundblaster 16 or Voodoo Graphics card any day.
Or a Mega Drive on a card like that old Amstrad Mega PC.

But then I think of the cost and the work involved in that and compare it to the software emulation solution already available and I just cannot justify using an FGPA for any of it.

Who really needs perfection except speedrunners? Whether a game has 3 frames of input delay like the original hardware or 5 frames in an emulator hardly matters in practice. Parry in Street Fighter 3 has a 10 frame window and is considered hard to do consistently. Going down to an 8 frame window in emulation doesn't break anything. Anybody who can do an input within 10 frames can adapt to 8 frames.

All that being said, I still really want my voodoo back.
Goddamnit!

[Anonymous No.5941216]

>>5940146
>i'm honestly surprised FPGAs aren't integrated into CPUs these days.
Because they're crazy expensive

[Anonymous No.5941420]

>>5940475
>This is the next evolution of serious enthusiast-tier emulation
What a hilarious phrase. No matter how "enthusiast" you delude yourself into thinking you're being, you're still an emulation pleb at the end of the day. Why waste all the time/money on an inferior solution instead of jumping up to real hardware + flashcart or something? How pathetic.

[Anonymous No.5941939]

>>5941420
Real hardware + flashcart doesn't allow you to use any USB controller you want without conversion, doesn't allow you to easily debug and develop games in real time, doesn't easily save and load states, doesn't do a dozen things that a PCI-E add-in card would do. They are two different use scenarios and if you can't see the difference you don't know much about the current landscape of /vr/.

[Anonymous No.5941942]

>>5940427
>>5940435
you can't use PCIe bus to upload your game roms to the FPGA card?

[Anonymous No.5941969]

>>5940141
Yes, but it will be a massive pain in the ass.

[Anonymous No.5941978]

>>5940321
FPGAs are hell to work with. Fuck xilinx and their godawful tools. Fuck vivado, fuck verilog, fuck vhdl. Thank fuck I write chisel which transpile to verilog so I avoid at least some of the bullshit

[Anonymous No.5941980]

>>5941942
You could.

[Anonymous No.5941984]

>>5940458
The FPGA only has to communicate stuff than can be stored in buffers, so the OS overhead would be neglible

[Anonymous No.5942003]

>>5941984
Also, PCIe IP cores are available, a cursory google search shows this https://github.com/enjoy-digital/litepcie

[Anonymous No.5942086]

>>5941978
>retarded rant
FPGAs are easy as fuck to work with if you have the basic skills to understand them, so clearly you're missing something here. And yet you write verilog++ instead of using the powerful design tools available. What exactly is your reasoning here?

[Anonymous No.5942098]

>>5942086
Writing logic is easy, working with tools that seg fault is not. It's pretty universally accepted that the FPGA ecosystem is a joke, only EEs think otherwise because they have never in their lives seen quality software.

[Anonymous No.5942179]

>>5941216
>Because they're crazy expensive
the only thing that makes them expensive is area, and modern CPU manufacturers aren't exactly making 1mm^2 chips, mind you

[Anonymous No.5942181]

>>5942098
>>5942086
if everything stays on FPGA, it is super easy
if you start interfacing with external logic, it becomes much harder to debug when shit goes wrong

[Anonymous No.5942303]

>>5942098
What tools are seg faulting for you? And under what conditions? It shouldn't be surprising that only people who know what their doing don't think the "ecosystem" is joke.

>>5942181
Integrating with anything always complicates things but that's the fault of those things or the person who decided it was necessary to use them. In the context of this fantasy thread you wouldn't have interface with much external logic. Were I to do it I'd make everything available on the back of the card in with period appropriate signals so need at least some buffers and DACs. But for emufags who just want muh FPGA you'd just make the stuff available on the bus and process it on the PC. And then laugh when the faggots rave about how authentic and lag free it is when it's actually worse than emulation.

[Anonymous No.5942359]

FPGA is so consumer unfriendly.

I dont understand wtf a mister is (i sort of do) but then they promote it to you like a frankenstein monster that only the savvy can put together if they have the right modules.

Why is this stuff so niche if it's so accurate? Do the sellers not like money?

[Anonymous No.5942405]

>>5942359
>FPGA is so conzoomer unfriendly.
Indeed, my young redditot
>I dont understand
What exactly do you not understand about someone saying it's cool and you then buying it? You're not Gen X. Not even close. Get your moms credit card out and give me your money
>Why?
Because there are so many other stupid things stupid people can spend their money on. And also because you're a child who doesn't understand sales, marketing, logistics, production, etc ad infinitum

[Anonymous No.5942436]

>>5942405
I'm sure you had fun typing that, I won't even try to take it away from you.

I still need a retro hdmi console equivalent to Analogue Nt's accuracy and input lag without paying for a shitty AVS or retron.

[Anonymous No.5942917]

>>5942436
And I still "need" a blowjob. Is your mom hot?

[Anonymous No.5943258]

>>5942436
Then get a MiSTER

[Anonymous No.5944590]

>>5942436
I'll take that as a no. Does she at least have dentures and will you pay for the bags?