rhsresearchllc / nitefury-and-litefury Goto Github PK

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!

As already asked in #2, please also enable over-temperature shutdown for the LiteFury sample project. (Sample-Projects/Project-0/FPGA-A100T-2/)

Thanks
Tobias

Hiya,

I just managed to tear one of the 6-pin EZmate connectors off the small JTAG adapter boards. Details:

• didn't really use force, used to dealing with small flimsy hardware
• the connector only came off about halfway; both of the side retention pins plus 3 or 4 of the data pins
• the pads were not ripped off, it seems the solder connection itself was the weak point
• I successfully soldered it back on manually, but burned some plastic on the JTAG connector since the positioning is awkward

I checked my other adapter (I ordered 2 boards) and at first it seemed to be better, but then on that board also one of the side retention pins came off in the same way, and after this happened the connector doesn't unplug properly anymore (lifts the socket instead.) It seems that as soon as one of the side pins is gone, you're kinda f*cked and the entire thing cascade-fails.

I see 3 possible causes here:

• the solder pads or mask are too small so the solder connection is too weak
• the connectors fundamentally are badly designed (ed.: by Molex, I mean) with a very small area of force transfer
• just bad luck, either on the boards or on my use of them

I'm posting this here as a reference/warning and collection point in case other people have the same problem. I haven't tried/checked this on the actual FPGA boards since I'd rather not break them. Presumably the footprint is the same there, though maybe not the assembly procedure?

Either way it might be a good idea to double check mounting details on these connectors and maybe increase the size of the pads and solder mask opening for the mechanical/mounting pins at the side.

Cheers!

With 2022.1 on Windows and the latest version of this repo, I am getting the 3 expected critical warnings, as well as some timing violations:

These are from Inter-Clock Paths userclk2 to mmcm_clkout0 (GPIO to CodeBlinker):

I have updated to this specific version as you mentioned at #15 (comment) that the release is supported. Are you seeing this as well?

Thanks,
- Don

What is the role of the following line in normal.xdc in the sample projects? Seems kept commented. When is to be uncommented?

Is pcie_clkin_p the 'system clock' or it has some more specific role?

#create_clock -period 10.000 -name pcie_clkin [get_ports pcie_clkin_p]

I recently brought the Nitefury II board and I'm looking forward to using it. Currently it has the factory default bitstream. I installed the xdma kernel module, the board is detected and I was able to run the example to identify the board.

I currently don't have a JTAG, and it won't be arriving for about a week or so. Meanwhile I wanted to know if I can use the spi-loader on the factory default bitstream. When I run the spi-loader test it freezes after Initializing flash index 0. Any idea why this is happening?

$ ./spi-loader -a 0x240000 -f ./64KiB.bin 
Loading 65536 bytes from ./64KiB.bin[0] to flash[2359296] using /dev/xdma0_user[65536]

Initializing flash index 0...

Other questions about the flashing over PCIe using the spi-loader:

1. Which address should I write a new bitstream into?
2. Will I have to overwrite the existing bitstream everytime?

Result of lspci

07:00.0 Processing accelerators: Xilinx Corporation 7-Series FPGA Hard PCIe block (AXI/debug)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 39
	IOMMU group: 26
	Region 0: Memory at e2100000 (64-bit, prefetchable) [size=128K]
	Region 2: Memory at e2120000 (64-bit, prefetchable) [size=64K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [60] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x4, ASPM L0s, Exit Latency L0s unlimited
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s (ok), Width x1 (downgraded)
			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Range B, TimeoutDis- NROPrPrP- LTR-
			 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS- TPHComp- ExtTPHComp-
			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled,
			 AtomicOpsCtl: ReqEn-
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
			 EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
			 Retimer- 2Retimers- CrosslinkRes: unsupported
	Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
	Kernel driver in use: xdma
	Kernel modules: xdma

Result of test-general

$ python test-general.py -v 2 -i NITE
Found product ID b'NITE' version 2
Temp C=55.0
VCCInt=1.02
vccaux=1.80
Checkout passed

Other info

OS: AlmaLinux 9.3 (Shamrock Pampas Cat) x86_64 
Kernel: 5.14.0-362.8.1.el9_3.x86_64 

Hello,

I am trying to connect DF52-20P.
The right part is DF52-20P-0.8C.
I used the cable (DF52-2832PF157).
The cable is quite expensive and it has an individual cable for 20 pins.
Do you have any other solution for the DF52-20P connection?
Thank you,

Hi all, I'm on Windows 10 using a freshly-installed Vivado 2022.2.

I'm failling on the bitstream generation step of the sample project, with the following error:

There's also a ton of warnings about 'set_property' expects atleast one object, which look like this:

In the picture above, I noticed that the "Ports" drop-down menu doesn't have anything relating to PCIe, other than pci_reset, and pcie_clkreq_I - is that expected? Shouldn't I be seeing the PCIe lane signals in the top-level Ports listing?

Another thing of note: I did get a dialogue asking me to migrate from Vivado 2022.1 (which I did), and when opening the Top.bd block design file, I got a prompt that 9 IP blocks needed updating. Updating them went through almost without a hitch apart from one warning:

Anyway, I'm still fiddling with the project, but I'm posting here in the hopes that maybe someone can catch something that I can't see?

On nitefury device, using xdma ip I have created a loopback design, where PCIe in loops back to PCIe out via AXI loopback.

Observed speeds seem to vary greatly depending on the block size of the transfer, but using MaxPayload size mentioned in xdma up of 4K bytes, it is still way below the theoretical speed of Gen 2 link.

C2H=/dev/xdma0_c2h_0
H2C=/dev/xdma0_h2c_0 
SRC=/dev/zero
SINK=/dev/null
COUNT=1000000
BS=<see below>

dd bs=$BS count=$COUNT if=$C2H of=$SINK &
dd bs=$BS count=$COUNT if=$SRC of=$H2C
wait

For a script like above I get the following outputs

BS = 4096 68.5 MB/s
BS = 512 9.2 MB/s
BS=8 147 kB/s

Seek this brief information about the IP configuration choice axilite_master_en = true in the sample project.

Exactly what functionality depends on this choice? Trying to figure out if it is alright to turn this off in my design?

The LVDS lines on the DF52 connector interface to pins that are not clock capable (none of the pins are MRCC/SRCC). I could see DQS lanes though in the two banks. Is there a way I can use the DF52 lanes to interface a high speed multichannel ADC?
It's a 65MSPS ADC in serial LVDS mode and outputs a data_clock, frame_clock, and data. I need to use ISERDES2 primitives to deserialise the data into 12-bit samples.

How many layers is the board and are the gerbers available please..

Hi,

any plans to create an updated version with USB4/USB-C connector?

Hi there..

1. can an Acorn CLE 215+ / Nitefury be flashed through PCIe without JTAG cable?
2. is it mandatory to use a JTAG cable to flash/program?
3. Is there a guide to flashing via PCIe?
4. Can I design in tools like Vivado and then flash / program via PCIe?

That massive heatsink will not fit in my thinkpad. On the other hand it has a steel case that it would rest against, and you merged the poweroff on overheat patch.

Hi, Is it possible to buy the nitefury without the cooling glued on ? I would like to use custom cooling solution.

In xdma ip I have set the following property:

xdma_rnum_chnl = 2

This creates the additional bunch of h2c ports in the design. It creates additional ports related to MSI.

Just in case if that is causing any issue following property disables the formation of MSI ports.

pf0_msi_enabled = false

However, in either case, the xdma driver fails to recognize the device, with this design.

Has anyone successfully used multiple DMA channels and which specific properties of the IP were required to be configured for the same?

Please, as awesome as this product is, being powerful and high bandwidth for such a low price, is there a way to make the fan quieter?

Hi, I am using NITEFURY 2(Artix-7 xc7a200tfbg484-2) and created the design with XDMA IP. I am programming the board through JTAG only.

1. I loaded the bin file provided by RHSResearchLLC(https://github.com/RHSResearchLLC/NiteFury-and-LiteFury/tree/master/Sample-Projects/Project-0/FPGA/Nitefury-II/mcs) through JTAG it worked. Device was detecting in pcie.
2. Then i generate the bitfile and loaded it thorough JTAG. lspci -vvv -s 01:00.0 displays "Unknown Header Type 7F". I tried this command echo 1 > /sys/bus/pci/rescan also, but still lspci -vvv -s 01:00.0 displays "Unknown Header Type 7F"
3. Again i loaded their original bin file. It worked. Device was detecting in pcie bus.
4. Then i created the binfile (using my bitfile) by following (write_cfgmem -format bin -size 16 -interface SPIx4 -force -loadbit "up 0 ./project.runs/impl_1/Top_wrapper.bit" -file "../mcs/out.bin") and loaded it to board through JTAG. Again lspci -vvv -s 01:00.0 displays "Unknown Header Type 7F". I tried this command echo 1 > /sys/bus/pci/rescan also, but still lspci -vvv -s 01:00.0 displays "Unknown Header Type 7F"

I am using the same XDMA IP configuration as provided in sample project,.

These are the questions I have,

1. Is the binfile packaging I am doing (write_cfgmem -format bin -size 16 -interface SPIx4 -force -loadbit "up 0 ./project.runs/impl_1/Top_wrapper.bit" -file "../mcs/out.bin") is correct ?
   

2. Not sure why loading bitfile via JTAG also doesnt work ? Is there any linux command I need to run to re-enumerate the PCI device ?

Hi,

I'm running the NiteFury on a RockPi4 (ARM). I had to recompile everything but after that step the kernel module loaded and everything seemed fine. When I ran run_tests.sh the whole machine locked up. Lights are still blinking on the NiteFury but the machine is non responsive. What may cause this?

lspci -vv

01:00.0 Serial controller: Xilinx Corporation Device 7024 (prog-if 01 [16450])
Subsystem: Xilinx Corporation Device 0007
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 234
Region 0: Memory at fa000000 (32-bit, non-prefetchable) [disabled] [size=1M]
Region 1: Memory at fa100000 (32-bit, non-prefetchable) [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [60] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s, Exit Latency L0s unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range B, TimeoutDis-, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00

sudo ./load_driver.sh

Loading xdma driver...
The Kernel module installed correctly and the xmda devices were recognized.
DONE

dmesg

[ 7641.378840] xdma: loading out-of-tree module taints kernel.
[ 7641.382338] xdma:xdma_mod_init: Xilinx XDMA Reference Driver xdma v2017.1.47
[ 7641.382351] xdma:xdma_mod_init: desc_blen_max: 0xfffffff/268435455, sgdma_timeout: 10 sec.
[ 7641.383695] xdma:xdma_device_open: xdma device 0000:01:00.0, 0xffffffc0ed638800.
[ 7641.383731] xdma 0000:01:00.0: enabling device (0000 -> 0002)
[ 7641.383757] xdma:pci_check_extended_tag: 0xffffffc0ed638800 EXT_TAG disabled.
[ 7641.383765] xdma:pci_check_extended_tag: pdev 0xffffffc0ed638800, xdev 0xffffffc0e8568000, config bar UNKNOWN.
[ 7641.383931] xdma:map_single_bar: BAR0 at 0xfa000000 mapped at 0xffffff800e400000, length=1048576(/1048576)
[ 7641.383969] xdma:map_single_bar: BAR1 at 0xfa100000 mapped at 0xffffff800bf80000, length=65536(/65536)
[ 7641.383980] xdma:map_bars: config bar 1, pos 1.
[ 7641.383987] xdma:identify_bars: 2 BARs: config 1, user 0, bypass -1.
[ 7641.384198] xdma:probe_one: 0000:01:00.0 xdma0, pdev 0xffffffc0ed638800, xdev 0xffffffc0dd202000, 0xffffffc0e8568000, usr 16, ch 1,1.
[ 7641.409170] xdma:cdev_xvc_init: xcdev 0xffffffc0dd203b88, bar 0, offset 0x40000.

sudo ./run_test.sh

Info: Number of enabled h2c channels = 1
Info: Number of enabled c2h channels = 1
Info: The PCIe DMA core is memory mapped.
Info: Running PCIe DMA memory mapped write read test
transfer size: 1024
transfer count: 1
Info: Writing to h2c channel 0 at address offset 0.
Info: Wait for current transactions to complete.

After this the system becomes unresponsive.

I have a NiteFury decvice. I do not have a JTAG cable. So do not want to land into a situation where NiteFury is `bricked'.

Is there any way to leave the factory design untouched or any way to recover it if overwritten (without a JTAG cable)?

I have another board - Digilent Arty - where I transfer bitstream to the device over a Microusb cable. I think it doesn't flash the device as I can always reboot to the factory set design. Can I use NiteFury in this way to always restore it into factory reset state?

Is it possible to take the heat sink off and put it in a case like this one DOCKCASE and have it work via USB ?

Hi, is there any difference between NiteFury-II and NiteFury-I (NiteFury with Integrated Heatsink from crowd supply)?

I have seen that it only has 512MB DDR3 on board, right?
Are there other changes?

Thank you very much.

I have a certain design with a 64-bit data path. It works well for PCIe speed of 2.5 GT/s and AXI clock of 125 MHz.

I'd think, it should work for PCIe speed of 5 GT/s and AXI clock of 250 MHz, keeping data width as 64 but somehow it is not working.

I haven't yet tried, though may be 5 GT/s, 128-bit data path and 125 MHz might work, but that requires a lot of changes in the design. So wondering if there is any configurable parameter that I may have missed in above design.

Probably a stupid question, but I can't figure out where to find the right value to put for the "board version" parameter that is required for the furytest.sh script.

In the test-general.py its referred to as the board_vrsn parameter. I added a line to print out the pvrsn read back from the board, and it appears to be assigned to 2 - Where is this configured from the Vivado side of things?

I have a fresh (i.e. with factory settings) NiteFury device in NUC 13 running Void Linux.

I just want to know if the device is at least physically set properly and to some extent recognized by the OS. Do the following indicators help? Is there something else (say in dmesg) that can be checked?

Is Vivado HW manager likely to recognize it (over PCIe)?

# dmidecode
Handle 0x001A, DMI type 9, 17 bytes
System Slot Information
        Designation: M2_A
        Type: x4 PCI Express 3 x4
        Current Usage: In Use
        Length: Long
        ID: 0
        Characteristics:
                3.3 V is provided
                Opening is shared
                PME signal is supported
        Bus Address: 0000:00:1d.0

# lspci -vvv
01:00.0 Processing accelerators: Xilinx Corporation 7-Series FPGA Hard PCIe block (AXI/debug)
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 255
        IOMMU group: 15
        Region 0: Memory at 611c100000 (64-bit, prefetchable) [disabled] [size=128K]
        Region 2: Memory at 611c120000 (64-bit, prefetchable) [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [60] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 75W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s, Exit Latency L0s unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s, Width x4
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range B, TimeoutDis- NROPrPrP- LTR-
                         10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS- TPHComp- ExtTPHComp-
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled,
                         AtomicOpsCtl: ReqEn-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
                         EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: unsupported
        Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00

Hi,

I am trying to configure the LiteFury with an FT232R connected to the JTAG port of the FPGA. I chose a 3.3V configuration and wiring the FT232R based on the following schematic: http://vak.ru/doku.php/proj/bitbang/bitbang-jtag and the JTAG port pinout from the Litefury datasheet.

I installed and built the xvcd and it successfully detects the FT232 device similar as I already did for a PicoEVB built-in FT232 device. However, when I connect through Vivado on a remote machine, it tells me that it doesn't detect any Xilinx device within the port (given by xvcd).

I would like to ask if you have an example for FT232R wiring to the JTAG port, or in the case, suggest a device to program the Litefury. I connected the Litefury to the PCIe port for NVMM in a Xavier NX, where I am also connecting the FTDI device.

I also want to highlight that I connected the Litefury to the FTDI through the JTAG port without connecting the whole module to the Xavier and a red lights blinked periodically.

Thanks in advance

Hey there,

I don't know if you've experienced this yet, but I had no problems flashing the board over JTAG prior to the issue happening now. I have the same setup, same programmer, same cord, etc. and the only thing that's changed is that I upgraded my motherboard/cpu on my main desktop which is doing the programming.

It appears that the device is resetting mid-programming. After a series of reboots and power cycles I did get it to program a few times, although now it's back to doing this and I haven't been able to get a successful reprogram.

Openocd is running in an ubuntu server 22.04 VM under VMWare workstation with the USB being passed through to the guest.

There's a lot of things that could be going wrong here, but hoping maybe someone has seen this before and figured out what was going on. It could just be I need to replace the cable or something to that effect.

Output from openocd:

Tue Feb 21 05:35:15 PM UTC 2023
Open On-Chip Debugger 0.12.0-rc1
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 1000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x13636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x1)
Writing BSCAN_SPI bitstream...
Info : JTAG tap: xc7.tap tap/device found: 0x13636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x1)
Info : Found flash device 'sp s25fl256s' (ID 0x190201)
Warn : 4-byte addresses needed, might need extra command to enable
Programming PCIe Chainloader bitstream to SPI...
Info : sector 0 took 1770 ms
Info : sector 1 took 1722 ms
Info : sector 2 took 112 ms
Info : sector 3 took 106 ms
Info : sector 4 took 108 ms
Info : sector 5 took 112 ms
Info : sector 6 took 106 ms
Info : sector 7 took 117 ms
Info : sector 8 took 107 ms
Info : sector 9 took 102 ms
Info : sector 10 took 111 ms
Info : sector 11 took 104 ms
Info : sector 12 took 105 ms
Info : sector 13 took 106 ms
Info : sector 14 took 107 ms
Info : sector 15 took 117 ms
Info : sector 16 took 116 ms
Info : sector 17 took 108 ms
Info : sector 18 took 110 ms
Info : sector 19 took 109 ms
Info : sector 20 took 107 ms
Info : sector 21 took 115 ms
Info : sector 22 took 106 ms
Info : sector 23 took 113 ms
Info : sector 24 took 110 ms
Info : sector 25 took 103 ms
Info : sector 26 took 111 ms
Info : sector 27 took 104 ms
Info : sector 28 took 113 ms
Info : sector 29 took 120 ms
Info : sector 30 took 105 ms
Info : sector 31 took 111 ms
Info : sector 32 took 111 ms
Info : sector 33 took 111 ms
Info : sector 34 took 107 ms
Info : sector 35 took 117 ms
Info : sector 36 took 117 ms
Info : sector 37 took 113 ms
Info : sector 38 took 110 ms
Info : sector 39 took 111 ms
Info : sector 40 took 106 ms
Info : sector 41 took 109 ms
Info : sector 42 took 111 ms
Info : sector 43 took 106 ms
Info : sector 44 took 104 ms
Info : sector 45 took 102 ms
Info : sector 46 took 104 ms
Info : sector 47 took 130 ms
Info : sector 48 took 114 ms
Info : sector 49 took 117 ms
Warn : Haven't made progress in mpsse_flush() for 2003ms.
Warn : Haven't made progress in mpsse_flush() for 4005ms.
Warn : Haven't made progress in mpsse_flush() for 8006ms.
Warn : Haven't made progress in mpsse_flush() for 16011ms.
Warn : Haven't made progress in mpsse_flush() for 32022ms.
Warn : Haven't made progress in mpsse_flush() for 64042ms.
Warn : Haven't made progress in mpsse_flush() for 128085ms.

The configuration file:

reset_config none

source [find interface/ftdi/digilent_jtag_hs3.cfg]
source [find cpld/xilinx-xc7.cfg]
source [find cpld/jtagspi.cfg]

adapter speed 1000

proc fpga_program {} {
        global _CHIPNAME
        xc7_program $_CHIPNAME.tap
}

init
echo "Writing BSCAN_SPI bitstream..."
jtagspi_init 0 bscan_spi_xc7a200t.bit
echo "Programming PCIe Chainloader bitstream to SPI..."
jtagspi_program pcie-chainloader-project0.bin 0x0
echo "Resetting device..."
fpga_program
echo "Done."
shutdown

And openocd version:

Open On-Chip Debugger 0.12.0-rc1
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

Can this board only be powered over the M2 slot?

Hello,

Can you give more detailed information on what connector types are used for the pico (6 pins) to JTAG (14 pins, 2x7) adapter?
My JTAG cable does not fit the JTAG socket. I need to replace it.
Thank you

The sample project build produces the following bitstream file:

NiteFury-and-LiteFury/Sample-Projects/Project-0/FPGA/Nitefury-II/project/project.runs/impl_1/Top_wrapper.bit

Then I am transferring this to the hardware over JTAG using Tcl command: program_hw_devices.

This leads to lspci showing: "Unknown header type 7f"

"echo 1 > /sys/bus/pci/rescan" doesn't help here.

Invoking load_driver afresh leads to

Error: The Kernel module installed correctly, but no devices were recognized.
FAILED

What exactly is the issue here - is .bit file supposed to work? Is it an issue with re-scanning not happening properly? Or something else?

What part of the sample project would be sufficient for the OS detect the device?

Would configuring xdma ip and adding the xdc constraints be enough (including taking care of "early" constraints)? Or what you do with AXI and AXI-Lite ports matters to merely being detected by the OS?

My attempt is recorded here. Please share inputs and experience if anyone has tried this:

https://support.xilinx.com/s/question/0D54U00007auyteSAA/streaming-mode-loopback-using-xdma-ip-on-artix-7series-device

IS4346TR16512BL is my best guess. Any chance we could get an updated BOM?

Hi ,

Can i plug NiteFury or LiteFury as a one sided board to Nvidia Jetson Orin Board using the m.2 connector ?

Thanks , Nimrod

It might be a good idea to enable over-temperature shutdown for Project-0:

# XDC Constraint
set_property BITSTREAM.CONFIG.OVERTEMPPOWERDOWN ENABLE [current_design]

Which I think is the same as: Edit Device Properties > Configuration > Enable over-termperature shutdown = ENABLE

Here is the snippet of error:-
"
#0
Sent in 1386.4996433258057 milliseconds (774.4263254366286 MBPS)
Traceback (most recent call last):
File "dma-test-2.py", line 82, in
main()
File "dma-test-2.py", line 69, in main
mem_test_random()
File "dma-test-2.py", line 41, in mem_test_random
rx_data.append(os.pread(fd_c2h, TRANSFER_SIZE, page * TRANSFER_SIZE))
OSError: [Errno 512] Unknown error 512
"
i think this a driver problem,
as i have also tested dma-test.py using earlier drivers from AR65444, c2h hangs in limbo while using this drivers,

Need help to install the FPGA card on Ubuntu20.02. I follow the FiresimRHS Research Nitefury II XDMA-based Getting Started Guide guide to try to set up the NiteFury card through XDMA. Everything went on very well until the last step in 5. Install your FPGA(s). When I used lspci -vvv -d 10ee:903f , I got nothing output. In Vivado hardware device manager, I have programed the mcs file into the card's flash through JTAG correctly and then cold boot the system. But the lspci seems not to recognize the card.

Hey!

I got the Litefury model and during designing my VHDL code I remebered the constrains file.

AFAIK, the constraints are used to set the physical constraints of the FPGA.
However, can I just drop them into ANY project?

Or do I have to refactor some properties in there?

In my case, I did not take a look onto the default projects.

TLDR: Are the constraints files (early/normal.xdc) project-dependent, a "must-have" in every project or not necessary at all when going to generate and flash the bitstream onto the FPGA?

Thanks!

I'm having some trouble with my NiteFury card and top-of-master XDMA. It works when plugged into a PCIe switch card: https://www.amazon.com/gp/product/B08L8J3MBT/ with some occasional reliability issues. But when plugged into the mother board with a M.2 adapter, the driver doesn't work.

4b:00.0 Serial controller: Xilinx Corporation Device 7024 (prog-if 01 [16450])
	Subsystem: Xilinx Corporation Device 0007
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 193
	Region 0: Memory at d0300000 (32-bit, non-prefetchable) [virtual] [size=1M]
	Region 1: Memory at d0400000 (32-bit, non-prefetchable) [virtual] [size=64K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [60] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x4, ASPM L0s, Exit Latency L0s unlimited
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s (ok), Width x4 (ok)
			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Range B, TimeoutDis-, NROPrPrP-, LTR-
			 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt-, EETLPPrefix-
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS-, TPHComp-, ExtTPHComp-
			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
			 AtomicOpsCtl: ReqEn-
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00

# echo "1" > /sys/bus/pci/devices/0000\:4b\:00.0/remove
# echo "1" > /sys/bus/pci/rescan 
[Feb15 12:40] pci 0000:4b:00.0: Removing from iommu group 62
[Feb15 12:41] pcieport 0000:04:08.0: bridge window [mem 0x00100000-0x000fffff] to [bus 05] add_size 200000 add_align 100000
[  +0.000004] pcieport 0000:03:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 04-05] add_size 200000 add_align 100000
[  +0.000012] pcieport 0000:03:00.0: BAR 14: no space for [mem size 0x00300000]
[  +0.000001] pcieport 0000:03:00.0: BAR 14: failed to assign [mem size 0x00300000]
[  +0.000002] pcieport 0000:03:00.0: BAR 14: no space for [mem size 0x00100000]
[  +0.000001] pcieport 0000:03:00.0: BAR 14: failed to assign [mem size 0x00100000]
[  +0.000001] pcieport 0000:04:08.0: BAR 14: no space for [mem size 0x00200000]
[  +0.000001] pcieport 0000:04:08.0: BAR 14: failed to assign [mem size 0x00200000]
[  +0.000002] pcieport 0000:04:08.0: BAR 14: no space for [mem size 0x00200000]
[  +0.000001] pcieport 0000:04:08.0: BAR 14: failed to assign [mem size 0x00200000]
[  +0.018879] pci 0000:4b:00.0: [10ee:7024] type 00 class 0x070001
[  +0.000023] pci 0000:4b:00.0: reg 0x10: [mem 0xd0300000-0xd03fffff]
[  +0.000010] pci 0000:4b:00.0: reg 0x14: [mem 0xd0400000-0xd040ffff]
[  +0.000105] pci 0000:4b:00.0: PME# supported from D0 D1 D2 D3hot
[  +0.000627] pci 0000:4b:00.0: Adding to iommu group 62
[  +0.000115] pci 0000:4b:00.0: BAR 0: assigned [mem 0xd0300000-0xd03fffff]
[  +0.000004] pci 0000:4b:00.0: BAR 1: assigned [mem 0xd0400000-0xd040ffff]
[Feb15 12:44] xdma:xdma_mod_init: Xilinx XDMA Reference Driver xdma v2020.1.8
[  +0.000002] xdma:xdma_mod_init: desc_blen_max: 0xfffffff/268435455, timeout: h2c 10 c2h 10 sec.
[  +0.000071] xdma:xdma_device_open: xdma device 0000:4b:00.0, 0x0000000045520a28.
[  +0.000001] xdma:alloc_dev_instance: xdev = 0x0000000030361898
[  +0.000003] xdma:xdev_list_add: dev 0000:4b:00.0, xdev 0x0000000030361898, xdma idx 0.
[  +0.000130] xdma:request_regions: pci_request_regions()
[  +0.000005] xdma:map_single_bar: BAR0: 1048576 bytes to be mapped.
[  +0.000025] xdma:map_single_bar: BAR0 at 0xd0300000 mapped at 0x00000000519eaa09, length=1048576(/1048576)
[  +0.000004] xdma:is_config_bar: BAR 0 is NOT the XDMA config BAR: 0xffffffff, 0xffffffff.
[  +0.000001] xdma:map_single_bar: BAR1: 65536 bytes to be mapped.
[  +0.000010] xdma:map_single_bar: BAR1 at 0xd0400000 mapped at 0x0000000071b088e5, length=65536(/65536)
[  +0.000002] xdma:is_config_bar: BAR 1 is NOT the XDMA config BAR: 0xffffffff, 0xffffffff.
[  +0.000001] xdma:map_bars: Failed to detect XDMA config BAR
[  +0.000034] pcieport 0000:40:01.3: DPC: containment event, status:0x1f01 source:0x0000
[  +0.000002] pcieport 0000:40:01.3: DPC: unmasked uncorrectable error detected
[  +0.025532] xdma:probe_one: pdev 0x0000000045520a28, err -22.
[  +0.000003] xdma:xpdev_free: xpdev 0x00000000b9ed515b, destroy_interfaces, xdev 0x0000000000000000.
[  +0.000001] xdma:xpdev_free: xpdev 0x00000000b9ed515b, xdev 0x0000000000000000 xdma_device_close.
[  +0.000001] xdma:xdma_device_close: pdev 0x0000000045520a28, xdev 0x0000000000000000.
[  +0.000006] xdma: probe of 0000:4b:00.0 failed with error -22
[  +0.135983] pcieport 0000:40:01.3: AER: Device recovery failed

I thought, maybe the debugger is holding it in reset. So I built the sample project in 2018.3, which went as expected, then I remove the pcie device, flash the FPGA and add it back. The result is exactly the same.

Hi,
Is it possible to have a PCB design of this project, similar to the Kicad project of PicoEVB?

Thanks

Just wanted to post for others who might be looking, pretty successful with the following devices (taking note of #19 when you want to make changes).

• Fine on m.2 nvme adapter / vanilla xilinx xdma drivers
• Fine on a standard thundebolt nvme enclosure (but note that this might be motherboard dependent, only one of my two thunderbolt ports will work on my motherboard )

litefury2021mcs.zip
Some of you out there may have built the sample in this GIT under Vivado 2020.2 which has been the latest version for past 6 months and then tested it to find that the XDMA driver/module refused to load properly, specifically it loaded but could not find the needed Config BAR and therefore did not create any device nodes and was useless.

I recently wrote RHS Research about this to find that XDMA under Vivado 2020.2 was a known issue. Indeed upon doing a bit of research it appears that the Vivado 2020.2 XDMA IP supplied by Xilinx (RHS research has nothing to do with this) is simply broken at least for all 7 series devices with includes the xc7a100t used on the Lite Fury.

The XDMA IP seems fine up through Vivado 2020.1 and I did indeed create and build an operational project using XDMA for the Lite Fury under 2019.2 that I happened to have on my system. However the provided sample in this GIT is for 2020.1 and refused to build properly under the older 2019.2.

To date it appears that Xilinx has not fixed the XDMA IP for Vivado 2020.2 although they seem to acknowledge back in March in the Xilinx way that there is a problem!

However Vivado 2021.1 was just released so I installed it (Ubuntu 20.04 is officially supported) and attempted to build the sample under it.

The build mostly went fine. Make sure you upgrade the IP and allow Vivado to use the new directory structure it will ask about these when open your clone of this GIT project. The only real issue I had is upon initial build it had 15 critical warnings this was because it was very confused about the GTP transceiver placement for PCIe that is specialized for the Lite/Nite Fury!

This is a complex issue that mostly involves the order it processes two different constraint files. If it is processing in the intended order you should end up with 3 critical warnings and the GTP mapping should be X0Y7 on pipe_lane[3], X0Y6 on pipe_lane[0], X0Y5 on pipe_lane[2], and X0Y4 on pipe_lane[1]. The critical warnings should indicate the above mapping, read these carefully.

Anyway upon initial build it was using the constraints in wrong order resulting in 15 critical warnings. I found (at least in my case) that if you edit the XDMA IP in block diagram (I changed the PCI ID from 0x7011 to 0x7012) and save block design. Then rebuild the XDMA IP and then the whole project (takes a while) and I ended up with the proper 3 critical warnings and the proper GTP mapping. However I will critically (to Xilinx) warn that I am not sure if this trick is consistent or why it works!

Anyway upon successful build I put the MCS file into flash on a Lite Fury power cycled the victim computer and tested with “Xilinx XDMA Reference Driver xdma v2020.1.8” which as of July 7th is the latest XDMA driver from Xilinx. At least the key DMA transfers to the Lite Fury RAM seemed to work fine. I did not test the other peripherals in the sample project build but will next week and report if there are issues.

I have attached the mcs file I built with Vivado 2021.1 for Lite Fury once programmed AND power cycled lspci should show Lite Fury as 10EE:7012.

Not an issue, just wanted to share that NiteFury & LiteFury work on a VisionFive 2! The XDMA driver worked nearly out of the box with the Ubuntu 23.10 image (had to make a few changes for kernel 6.5, xdma only supports 6.1 at the moment). Board only has a gen. 2 x1 connection to the M.2 connector though.

(I made some changes to use the Acorn CLE-215+ since it's a NiteFury-II with the -3 rather than the -2 speedgrade part. Also added a 1 MiB block ram to the AXI DMA fabric so that I could see how fast I could get DMA to go)

I can see the picture on the home page of this git repo.

But as you fix the device in an M Key slot, the pads where the wires are shown as placed face downward to the motherboard and there is hardly any gap to pull them out from such position. If someone can show a picture of how this is fixed that will be of great help.

From the files found in the repository I am guessing only Linux is supported, is this correct ?

I see IOSTANDARD property for sys_clk_clk_p and _n in normal.xdc

What are the PACKAGE_PIN and create_clock constraints needed on these ports?

The comment in the xdc suggests, MIG might be setting those. But I am not using MIG in my design.

###############################################################################
# DDR
###############################################################################
# Note: Most of the pins are set in the constraints file created by MIG
set_property IOSTANDARD LVDS_25 [get_ports sys_clk_clk_p]
set_property IOSTANDARD LVDS_25 [get_ports sys_clk_clk_n]

I have ordered Nitefurry, but yet to order a suitable SBC / PC with M.2 M key slot.

Considering Intel NUC-13 i7. It has a M.2 M key slot, but not sure about whether it will accommodate the height, considering the heat sink.

Please suggest alternative SBCs otherwise.

Readme of this repository shows XC7A200T-2FBG484E, but Vivado rejects this as invalid partname when creating bitstream. (I am using all tcl scripts, no UI.)

In the following xdc file in this repository I found partname XC7A200T-FBG484
Sample-Projects/Project-0/FPGA/Nitefury-II/project/project.srcs/sources_1/bd/Top/ip/Top_mig_7series_0_0/Top_mig_7series_0_0/example_design/par/example_top.xdc

This is accepted by Vivado, but a simple design to just switch on or off an LED is transferred to the expected effect on LED doesn't happen.

In my Vivado installation I find following partnames with string fbg484

xc7a200tfbg484-1
xc7a200tfbg484-2
xc7a200tfbg484-2L
xc7a200tfbg484-3
xc7a200tifbg484-1L
xc7a200tlfbg484-2L

get_property PART [current_hw_device]
shows xc7a200t

This partname is accepted, but still I am unable to get any indication on the LEDs.

In my design I have just set '1' on LED_A1 through LED_A4 and LED_M2. I have used constraint files copied from this directory: Sample-Projects/Project-0/FPGA/Nitefury-II/project/project.srcs/constrs_1/imports/constraints

Some of the sample projects in this repo show: xc7a200tfbg484-2. With that also, I don't seem to get the LEDs lit.

My Vivado version is: v2022.2

Basically Vivado in Windows works fine. The problem is using Vivado in Linux. The PCIe pins are miss-placed. Vivado reports an error in synthesis: [Project 1-236] Implementation specific constraints were found while reading constraint file [ …/constraints/early.xdc]. These constraints will be ignored for synthesis but will be used in implementation. Impacted constraints are listed in the file [.Xil/Top_wrapper_propImpl.xdc].
To fix this problem, I rebuild the build script in Linux to resets the LCO property on the PCIe cell and add the correct LCO. A couple of points, the synthesis needs to be opened to make the change. But you can’t close it. Closing it will lose the change or reset the synthesis. Close the design after implementation (see attached) .

I'm using the Vivado 2022.1 Any idea?

VH

build_mod.zip