Simpler samples please

[ianhan]

Hi,
This project is really cool but I wasn't expecting the only sample design to be 100% schematic - it would be cool if you could add a sample "golden" top project that consists of an empty verilog top module that implements all of the signals.
Thanks. Thanks for making this cool piece of kit!

[mayureshw]

I am also looking for a simple sample design. Something like taking the xdma IP xci from the sample project and doing minimal things like loopback with it.

No matter what I try I end up with "!!! Unknown header type 7f" on transferring bitstream to the fpga (and doing rescan also).

I have taken a post implementation checkpoint and dumped the constraints from it just to ensure that those in early.xdc are valid. They are.

What else shall I be checking? Have spent several days in this state and am really at the end of my wits.

[RHSResearchLLC]

@mayureshw "!!! Unknown header type 7f" happens when the device was on the PCIe bus, then drops off, then comes back on. You can't reprogram the bitstream while the device is on the PCIe bus and expect it to work. I've actually never seen a rescan work, although some people claimed it works for them. For rescan to work you need bios and motherboard support and most just don't implement it.

Really the only reliable way to work on a PCIe bitstream is to have the bitstream loaded from flash at powerup, ready when the motherboard/bios enumerates it, and don't reset/reload the FGPA after. So build your design (with any ILA), create MCS, load into flash, reboot, debug.

As far as a simpler design, the example design is about as simple as it gets. Sure you can delete some the of stuff that reads I/O.

[mayureshw]

Let's say "mybitstream.bit" is my own design and "stock.bit" is a bitstream built from the sample project design.

I am using JTAG cable to program the device.

If I load, say, "mybitstream.bit" the "Unknown header type" occurs on lspci. But immediately after that if I load "stock.bit", the issue goes away. So, I think you can reprogram the device over JTAG. It is something in the design that keeps "mybitstream.bit" from working.

My Linux kernel is 6.3.13_1 and I am using Void Linux.

For simpler design, yes, that's precisely what I am doing. I have taken xdma configuration (xci file) from the sample project, with early and normal constraints, applied in proper order and verified that they got applied by taking a post-implementation checkpoint and writing out xdc.

With this I expect that lspci merely lists the device properly.

Incidentally there are two xci files for xdma, which confused me a bit:

project.srcs/sources_1/bd/Top/ip/Top_xdma_0_0/Top_xdma_0_0.xci

and

project.srcs/sources_1/bd/Top/ip/Top_xdma_0_0_1/Top_xdma_0_0.xci

Later I saw Top.bd refers to the latter, so that might be the one to pick.

Following is the difference between their properties (right side being the latter one).

> all_speeds_all_sides NO axil_master_64bit_en false | axil_master_64bit_en true axil_master_prefetchable false | axil_master_prefetchable true axilite_master_scale Megabytes | axilite_master_scale Kilobytes axilite_master_size 1 | axilite_master_size 128 > enable_pcie_debug_ports False mode_selection Basic | mode_selection Advanced pf0_base_class_menu Simple_communication_controllers | pf0_base_class_menu Device_was_built_before_Class_Code_definiti pf0_class_code 070001 | pf0_class_code 120000 pf0_class_code_base 07 | pf0_class_code_base 12 pf0_class_code_interface 01 | pf0_class_code_interface 00 pf0_device_id 7024 | pf0_device_id 7011 pf0_msix_cap_pba_bir BAR_1 | pf0_msix_cap_pba_bir BAR_3:2 pf0_msix_cap_table_bir BAR_1 | pf0_msix_cap_table_bir BAR_3:2 > pf0_pm_cap_pmesupport_d0 false > pf0_pm_cap_pmesupport_d1 false > pf0_pm_cap_pmesupport_d3hot false > pf0_pm_cap_supp_d1_state false pf0_sub_class_interface_menu 16450_compatible_serial_controller | pf0_sub_class_interface_menu All_currently_implemented_devices_ pf0_subsystem_id 0007 | pf0_subsystem_id 0 pf0_subsystem_vendor_id 10EE | pf0_subsystem_vendor_id 0 xdma_pcie_64bit_en false | xdma_pcie_64bit_en true xdma_pcie_prefetchable false | xdma_pcie_prefetchable true

[mayureshw]

One more observation that shows that the new bitstream indeed is what lspci is reporting, I can spot a few small differences between the lspci output of the factory set device and after transferring out.bin. (I expected them to be same, but somehow there are these minor differences.)

<< is factory set and >> is after transferring out.bin

2c2 < Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- --- > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- 4d3 < Latency: 0 7,8c6,7
< Region 0: Memory at 611c100000 (64-bit, prefetchable) [size=128K] < Region 2: Memory at 611c120000 (64-bit, prefetchable) [size=64K] --- > Region 0: Memory at 611c100000 (64-bit, prefetchable) [disabled] [size=128K] > Region 2: Memory at 611c120000 (64-bit, prefetchable) [disabled] [size=64K] 18,19c17,18 < RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ < MaxPayload 256 bytes, MaxReadReq 512 bytes --- > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 128 bytes, MaxReadReq 512 bytes

[mayureshw]

My apologies if the diff output in above two posts looks a little awry. When editing it looks alright and later it messes up with the formating.