hckrnws

I just used the Raspberry-PI V to bring up the PCIe interface on a Lattice Certus-Pro NX "Versa" board, it's very convenient.

What's cool is that the Raspberry-PI V is just fast enough to run modern desktop software, including (ack!) Microsoft Teams. I was able to give a live demo of my FPGA design by sharing the desktop during a conference call.

My only complaint is, of course, lack of SoC documentation from Broadcom.

Say what you will about Intel, but they do provide full chip documentation if you go through their NDA process. With it, I made a very nice FPGA PCIe environment on Xeon Ivy Bridge: it let me save all of the PCI config registers, then reconfigure the FPGA, then reprogram them and have the chip show up on the bus without having to reboot the server or re-enumerate. The trick is to temporarily set the root complex bit to disable PCIe error detection during the reconfiguration process.

(Was using Altera Stratix-IIgx at the time).

There is possibly another way to this, but haven't tried it:

https://stackoverflow.com/questions/32334870/how-to-do-a-tru...

But even aside from that, with the documentation you have access to a lot of error reporting which is extremely useful during PCIe bring-up.

Ah, that's a fancy trick! I remember many a time making Linux real angry with my PCIe fiddling. I believe in the end we got Partial Reconfiguration set up, where the PCIe portion of the device would not be reprogrammed but we could reload the rest. It was definitely a trade off though in terms of layout planning and space reservation.

For what it's worth: if you have a FT2232H adapter hanging around (and if you don't, you should consider getting one), those adapters can easily be flashed to be compatible with Vivado:

https://docs.amd.com/r/en-US/ug908-vivado-programming-debugg...

At work we always have 20-30x FT2232H on stock.

They are super useful - they speak GPIO, I2C, SPI, parallel FIFO, etc.

And their pyFTDI Python lib is great.

Just be careful as the counterfeit FTDI chips can have bad internal regulators etc. (Usually those small Red UART and GPIO breakout hobby PCB.)

Usually better to use the vendor supplied JTAG tools, or build your own with known good silicon. Recovering FPGA hardware is always a mixed bag of what IP and documentation is available to bring up the board. Looks like nice silicon though. =3

Not all FTDI series are faked. Only the most popular FT232 as far as I know.

Same for ST. Only the STM32F103 is a well known bad actor in the market.

> Only the most popular FT232 as far as I know.

Specifically, the FT232RL - a simple USB-to-serial chip. (And many of the clones are actually quite high quality.) As far as I'm aware, the FT2232H - a more complex USB to various-serial-and-parallel-protocols chip - hasn't had a counterfeiting problem, although I believe WCH has made some compatible parts.

In my experience the f103 clones fix silicon bugs and some even have improved peripherals (like i2c)

Problem is that they still using the ST HAL which is not aware of the fixes in the background.

90% of the standard stuff will work. But as soon as you dig into the exotic modes bad things will happen.

Also beware that FTDI has bricked swathes of gear that (often inadvertently) used counterfeit chips, via driver updates. So if you buy gear that uses an FTDI chip then if you’re unlucky want it turns out to be counterfeit, your thing might get bricked. :/

Importantly not just counterfeit chips but also completely legal clone chips. For context, for a long time Windows did not have a driver for the CDC serial communication class out of the box. But FTDI had made good Windows drivers, and their interface was easy to clone. So for a time there was a market for making 3rd-party chips implementing FTDI's interface and copying their USB id to be recognized by their driver[0]. Of course some unscrupulous sellers would inevitably try to pass those of as genuine FTDI chips. FTDI was probably not happy with either of them, with the clone chips manufacturer piggybacking of their hard work. But they could only do anything about the counterfeits, so they kinda ignored the existence of legal clones and in all their public communication only talked about taking steps to shut down counterfeit chips (most likely well knowing that their were also destroying chips of legitimate competitors).

[0] Clearly allowed at least in the US under the decision in Sega v. Accolade

Many Chip VID:PID listed in

> lsusb

or

C:\> Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^USB' } | Format-List

are considered copyrighted IP in North America. Many of the paid device codes are often not like other Communication Device Class drivers or free generic HID devices listed in the USB standard.

Early next year Windows 11 will be locking out unsigned drivers from the OS. Good for keeping the kernel more consistent, but could be bad for hobby hardware drivers.

Personally, I think it is ludicrous, but for 83% of users they have no other option than pay $6.32 for a $$0.43 chip. =3

Good, FR. Then you can send it back to who you bought it from. All vendors should do this.

The issue is (as I understand it) that some early supply chain distributors either unwittingly bought shipments of counterfeit parts, or otherwise ended up stocking them as genuine. Then legitimate hardware manufacturers used them. And let's be upfront here, any part using FTDI USB interfaces is low volume hardware that's either indie or, like, niche scientific gear. These are not chips you use when you have a 20-person hardware procurement department with the time to do a deep dive into every shipment of every component. These are chips you use when you're used to serial ports and have had USB foisted upon you and just want to sell the thing you built.

Sending it back only punishes the OEM you bought the weird niche thing off, and they likely had no indication that the chips they paid genuine prices for were counterfeit. If they try to get a refund from Alibaba or DigiKey or whoever, they'll politely be told to fuck off, if they get a response at all.

I totally understand why FTDI chose to take this path, but I also think it was a poor choice overall and I now avoid FTDI products (which back in the day I happily used, before all this) just in case I get caught up in the BS.

Penalizing FTDI for the OEM's negligence in not properly securing their supply chain? That's absurd. It is 100% the responsibility of the OEM to vet their suppliers to ensure that they know what's going into their product.

Cisco use these chips inside their switches, they are all over the place. I still think this is good, I buy them from RS, any authorised distributor will not tell you to 'fuck off', if they do please forward it to FTDI. If you're buying off Alibaba or eBay then that's on you. Sorry.

I _do_ happen to have one laying around from another project, weirdly enough. I've never done FPGA work though, when you say it's compatible with Vivado, what does that mean in practice? I can configure an AMD FPGA, or something more?

Vivado, along with expensive adaptors, supports some JTAG dongles that are just FT2232 with an EEPROM that contains USB descriptors that Vivado recognizes and treats as a (some low cost onboard adaptor for Digilent boards, IIRC) supported adapter. https://gist.github.com/rikka0w0/24b58b54473227502fa0334bbe7...

If you like FT2232, you’ll love the Tigard board that takes a FT2232H and adds level shifters and is basically as tricked out as you can make a FTDI adapter. https://github.com/tigard-tools/tigard

Vivado offers some embedded debugging and logic analyzer infrastructure, which allows you to tap into signals within the design and monitor them from the PC. (For instance, the Memory Interface Generator will report its initialisation status to the PC and if something failed it will tell you what). This is done over JTAG, and Vivado will only support that when using a select few JTAG dongles.

If you're happy to create your own debugging infrastructure (which isn't that hard - almost all FPGAs have at least two dedicated IR scancodes specifically for user applications) then you can use any JTAG dongle supported by OpenOCD.

I think they mean it can be flashed into a programer/jtag interface compatible with vivado. If you want to get started with fpga, may I recommend 1bitsquared.com 's products

Reminds me how Alibaba innovated in database space with a cluster of FPGAs doing LSM compaction with custom MySQL storage engine - https://dl.acm.org/doi/pdf/10.1145/3299869.3314041

Basically they achieved massive improvements in throughput and latencies vs RocksDB, for some operations even an order of magnitude.

They even offered this as a service, but eventually pulled out. Not sure if they are still using it, but I was surprised that pretty much nobody else, as far as I am aware, is using any hardware acceleration for repetitive database workloads.

AWS was using in house hardware query acceleration in redshift a few years back https://aws.amazon.com/blogs/aws/new-aqua-advanced-query-acc.... I dont know how much attention its getting (or performance its bringing) since AWS started focusing more in P&L the past year or two.

If you are interested in FPGA PCIe or PCI cards there are also a lot of Gidel boards available second hand. ProcSpark/ProcStar etc. The official software is proprietary and they often contain multiple FPGA devices so there is again an exercise working out the pinouts etc if you want to simply use them with Quartus. I got one with a massive Stratix IV on.

A Kintel UltraScale+ is quite a prize though, really nice write up.

The top-level Verilog module and Vivado .xdc file (contains pin mappings, timing constraints, etc) from Gidel for the HawkEye 20G-48. [0] No SDK from Gidel though.

My back burner project for them is to create a PCIe TLP sniffer/MiTM/device emulator by hooking up two together via 10 GbE for relaying TLPs with one of the remaining 10 GbE connection going to a host PC for the sniffed/injected TLPs. The Aria 10 FPGA PCIe hard IP allows for either root or endpoint mode so I “just” need to draw the rest of the owl, avoiding any Quartus IP modules that would make the setup non-transparent.

I’m not sure what using a 10 Gbit link for PCIe will be like with faster devices but fail0verflow got away with TLP proxying with 115200 baud UART. [1]

[0]: https://www.ebay.com/itm/335904285904 [1]: https://fail0verflow.com/media/33c3-slides/#/11

Is anyone aware of any examples of FPGAs used to implement neural nets or other connectionist architectures?

What's exciting about FPGAs is that they make "custom" chips affordable for colleges and even individuals... At this point in time, with the AI world fixated on LLMs, it seems that there's an opportunity for small groups/individuals to use FPGAs to experiment with more animal-like ground-up approaches to intelligence.

Certainly, we use networks on FPGA at FNAL for inference on LHC/CMS high energy physics results. There are also cases involving microsecond control of dynamical systems. https://fastmachinelearning.org/hls4ml/ https://indico.cern.ch/event/797510/contributions/3313676/at... https://cdrdv2-public.intel.com/833277/deploying-tinyml-fpga... https://ml4physicalsciences.github.io/2019/files/NeurIPS_ML4...

> Is anyone aware of any examples of FPGAs used to implement neural nets or other connectionist architectures?

Do you mean as a specialized processor for high speed inference, or as if the neural net including weights was directly synthesized into the FPGA architecture?

Neither use case would be as powerful as other options. FPGAs don’t provide infinite leeway for implementing completely custom logic. They have a finite number of blocks that can be reconfigured in certain ways as synthesized by the software. This architecture isn’t a good fit for the large LLMs we think about which need a lot of high bandwidth memory access. You can connect an FPGA to high speed memory, but the current crop of GPUs are going to be much better at the job.

Have a look into differentiable logic gate networks

https://arxiv.org/abs/2404.10076

Why the downvotes? My understanding ai is not a use for fpgas because models require a lot of ram (preferably fast ram) and fpga themselves don’t have a lot of it. An fpga will have pins you can attach fast ram, but then board layout and layering traces becomes very non trivial. Hence gfx cards (and a lot of them) are more suited.

FPGA certainly not ideal for an experimental AI architecture, but if data is just flowing thru it (sensory input in, motor control out) then I don't see RAM as an issue. Could be an interesting option for experimenting on a mobile robot.

FPGA will never be as fast as an ASIC. NV data center chips cant do graphics anymore, just compute.

Sure - not as fast or flexible, but relatively cheap and reprogrammable - good for experimentation, maybe for building a real-world proof-of-concept of a learning architecture ?

Funny you say that, if you look at the git repo for the blog there are a bunch of asic screenshots currently being committed.

Lots still available on eBay https://www.ebay.com/itm/167626831054

I guess there aren't any GPIO's wired up to headers or such? Any suggestions on a project for it that's a good fit?

That’s really nice! Cheap hardware was gone during covid years completely. And now beautiful Kintex for 200$ again. I was super interested in these when I was younger. 2x SFP with PCIe reminds me on NetFPGA project. This card is perfect for it!!

>The board also came with a travel case

But why? Are these boards frequently removed and physically moved around in data centers?

Or was that an eBay seller thing to protect it?

> But why?

To bring them to the field, because they’re _field_ programable gate array

/s

That’s why the trowel, I suppose.

Lol, nice one.

"""

dmesg log :

[ 0.388790] pci 0000:00:00.0: [14e4:2712] type 01 class 0x060400

[ 0.388817] pci 0000:00:00.0: PME# supported from D0 D3hot

[ 0.389752] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring

[ 0.495733] brcm-pcie 1000110000.pcie: link up, 5.0 GT/s PCIe x1 (!SSC)

[ 0.495759] pci 0000:01:00.0: [dabc:1017] type 00 class 0x020000

...

Since most people might not be intimately as familiar with PCIe terminology, allow me to quickly document what is going on here.

0000:00:00.0: is the identifier ...

[14e4:2712]: is the device’s [vendor id:device id], these vendor id identifiers are assigned by the PCI standard body to hardware vendors. Vendors are then free to define there own vendor id’s.

The full list of official vendor id’s and released device id can be found : https://admin.pci-ids.ucw.cz/read/PC/14e4 or in the linux kernel code...

"""

Wouldn't it be really nice if dmesg had more info about devices?

Agreed, it would be so nice. But I can also understand they might want to keep dmesg as learn as possible.

Serious competence porn. I love it.

Cool stuff.

Reminds me of recycling used Mining- or LED-Controllers as they can be bought on Ali and have quite capable FPGAs.

What's special about this?

These chips usually cost $1k-$2k when bought new individually from the manufacturer

Yeah Xilinx’s pricing curve is incredibly steep. Probably makes sense since they’re used in things like defence (radar, electronic warfare) so they can sell them in low quantities for huge prices and people will still buy them.

But with decent volume they get pretty cheap - for example there are video converters they have FPGAs in them that you can buy for less than you can buy the FPGA part in single qty - which means the manufacturer of the device is getting the FPGA for 5-10% of list price.

Wanted to buy a GOWIN FPGA recently, like on Sipeed's dev boards. Mouser wanted $37 for it, more than twice what the whole devkit costs.

Meanwhile the list price from the manufacturer is $3, but it's completely impossible to order anything as an individual. Not sure why they designed a hobbyist beginner-friendly dev board around a part from a company that makes all their products impossible to buy...

So people are going to desolder the chip? This doesn't seem very hobbyist-doable. Are there people out there who build products based on scrapped FPGAs from ebay?

Are we talking about physical products or cloud services?

There’s zero cloud service in the article, only physical boards decommissioned by a hyperscaler. Asking about cloud services tells me you only read the title.

I read the title and was confused why the article did not match it.

Cloud should have been title-cased (they make this mistake almost every time in the article), they bought an FPGA decommissioned by Alibaba Cloud, the subsidiary.

Not only that, but you can develop for this particular model with the no-cost Vivado license.

just received a kv260 board, i thought vivado is free to use?

Vivado has free and paid tiers. The free tiers ("WebPack") support their a myriad of their smaller devices (which includes the Kria boards). The larger devices (Virtex, etc.), however, are generally only supported by the paid versions of Vivado.

It's inconvenient for hobbyists, sure, but for enterprise uses the cost of Vivado for a team is largely inconsequential (which I suspect is why they get away with this).

You can typically get a free license for some boards, especially evaluation boards.

Everything is free if you continually renew your trial every 30 days.