Pre-built bitstream for NeTV2 with PCIe core?

[bunnie]

Hi @enjoy-digital , @cgmAether opened an issue on the Alphamax repo (https://github.com/AlphamaxMedia/netv2-fpga/issues/26) with a simple request that maybe you might have a quick resolution for.

@cgmAether is looking for any bitstream that loads onto the NeTV2 and allows it to enumerate on the PCIe bus:

I don't even care if the NetV2 successfully writes or reads from its memory, although that is preferred, as long as it completes the transactions and does not hang the PCIe Bus. I'm simply looking for a NetV2 bitstream which acts as a PCIe stub.

I don't know the details but it seems the goal is to do some characterization of EMI interference of PCIe, so a minimally functional link is all that's needed.

Do you happen to have a bitstream handy that might fit the bill? Not asking you to compile or write anything, just asking if you have an old build hanging out that might have a pre-built bitstream that could do the trick for this use case. Thanks and sorry for the bother!

[mithro]

FYI -- There is a tutorial for doing NeTV2 as a PCIe card at https://github.com/timvideos/litex-buildenv/wiki/HowTo-HDMI2PCIe-on-NeTV2

[mithro]

You can probably ask @kgugala if he has a prebuilt bitstream lying around somewhere.....

[kgugala]

@bunnie @mithro netv2-bitstreams.zip archive has bitstreams for a35t and a100t versions of netv2. Those were built from https://github.com/antmicro/netv2/tree/v4l2 (so you should be able to use those with the V4L2 drivers from the repo).

[cgmAether]

@kgugala I'm going to try and set this up today. I have the xc7a100t variant. Since I only need the PCIe stub functionality, I'm wondering how much of the getting started needs to be done. I will flash the NetV2 with the bitstream using the Raspberry Pi pins, install the V4L2 Drivers, and see if I can detect the board on the bus. I will report back if I have luck, but please let me know if there is more that I need to do besides what I've listed.

[kgugala]

if you wan't to test the pci part only you need to:

1. program the FPGA (use any method - rPi, platform cable or any other JTAG adapter)
2. force pci bus rescan
3. run lspci (if you're on Linux) - the device should enumarate as Xilinx Memory (or sth like that)

If you see the device in lspci it means it got enumerated. You don't really need to load the V4L2 driver to get the board enumerated.

[cgmAether]

I believe I've got it functioning!

[cgmAether]

We have been successful in getting some EM signals from this setup! I can write 0 or 1 to the FPGA. I am unable to write anything besides a 0 or 1. I'm assuming this is just what stub functionality is available when sending read and write commands. Am I correct in this assumption @kgugala

[kgugala]

the device exposes CSR space in the BAR mapped memory. CSR space consist of numbers of registers controlling internal functionalities of the system (like DMA, HDMI in/out, clocks etc). Depending on the register, not every bit may be writable. I assume this is why you can write only 0 or 1 there.

[cgmAether]

Is there a map of this CSR space on the github repo?

[kgugala]

LiteX generates the map during the build (and it may vary for different builds). V4L2 Linux driver includes an autogenerated header. Here https://pastebin.com/iA24dwCa you can find the generated header for the system you got in the bitstream. Host sees the memory starting at CSR_CTRL_BASE offset. So when you're writing to 0x0 in the BAR mapped space, you're actually write to 0x82000000 in the netv2 SoC space. Does that make sense?

[cgmAether]

@bunnie You can close this issue as my use case has been met.

We were recording signals from the PCIe cable while doing reads and writes to the memory over and over, but our signals looked quite cloudy. We then tried with different memory sizes with sleeps in between and the signal remained cloudy. After a while we realized that any keyboard inputs or mouse inputs caused a signal on the PCIe even when our read/write script was not running. This really confused us lol. We thought possibly it was the wireless mouse interfering, but that was not the case. Eventually we realized that anytime the screen refreshed PCIe traffic occurred. Which is obviously the point of the entire project. It captures HDMI over PCIe. Figuring that out through just the PCIe signals was quite fun. Running our memory read/write script with the terminal minimized so our debug prints don't refresh the screen removed the cloudiness from our signal and we could see distinct transmissions.

Then we decided to look at the screen refresh signals. So when we move the mouse, a screen refresh occurs and then continues periodically every 50ms or so for about 10s. Playing a youtube video causes constant screen refreshes and lots of PCIe traffic. We tried with different screen resolutions and different fps videos. Smaller resolutions resulted in weaker traffic and higher fps videos resulted in denser traffic.

Thought our results were pretty cool so I wanted to share with others. :)

[cgmAether]

@kgugala Yes that makes sense, thankyou. I will try experimenting with writing to some of these different addresses.

[bunnie]

Thanks everyone for the quick help! Looks like the case is closed, I'll close out this issue.