6
\$\begingroup\$

UART is great to transmit log data from a DUT to a PC. However, it is not fast enough. There are many newer things like USB, PCIe e.t.c that can transfer a lot more data and also use serial transfer. This brings me to the question. How can one use the SerDes to replace the UART? SerDes is just a serializer-deserializer. Usually SerDes would be used as a component of a much larger design that has more components like 8b/18b encoding e.t.c.

If one wants a really high speed but simple replacement for UART to send characters to a PC screen for log data, what methods should one go for? The SerDes exists on FPGA here.

Improve this question
\$\endgroup\$
  • 8
    \$\begingroup\$ Just implement a high speed version of UART. \$\endgroup\$ – user3528438 Jun 29 '20 at 20:46
  • 5
    \$\begingroup\$ How fast you want to go? I use standard FTDI USB serial devices at 3 Mbit/s (300 kbyte/s). If you make your own USB CDC with a MCU, you can achieve approximately 1 Mbyte/s. I suppose using an FPGA, you could implement a PCIe device that is an UART, capable of horrendous speeds. \$\endgroup\$ – Justme Jun 29 '20 at 20:49
  • 1
    \$\begingroup\$ The problem with SERDES is that you need an implementation on the PC side, too. Most "go really fast" things like SDR's have used something like a later-generation USB fifo, some may have used some variation of SATA. These schemes implicitly incorporate a SERDES function but are much more than that. \$\endgroup\$ – Chris Stratton Jun 29 '20 at 20:51
  • \$\begingroup\$ Remember that if you use SERDES you need to transmit a clock along with the data. That's another wire, and sending high speed pulses over long wires is not trivial. You probably want to use LVDS signalling. \$\endgroup\$ – Elliot Alderson Jun 29 '20 at 21:04
  • 4
    \$\begingroup\$ @Elliot Alderson, SERDES can be self synchronous which means clock is embedded within the serial bit stream and must be extracted from it using some form of PLL technique \$\endgroup\$ – Quantum0xE7 Jun 29 '20 at 22:57
8
\$\begingroup\$

You need to choose one of the high-speed interfaces that are available on the PC, and implement that in your FPGA (or by a companion chip of some sort) including any upper protocol layers that are needed to be able to exchange data with an app running on the PC.

A SERDES alone won't cut it. Now if this was a SERDES coupled to an Ethernet MAC (or MAC+PHY), which in turn could be used with an internal MCU/CPU core, that would be starting to make sense.

As for other choices, you have already mentioned USB, another possibility is the PCI-e, or the parallel PCI in the older days... On the host PC, you can talk to the USB stuff using LibUSB from the user space. Custom PCI or PCI-e hardware needs a kernel-space driver.

For really high throughput (efficient use of the bandwidth available), you will need to implement buffering / block transfers / DMA stuff. The existing PC interfaces have all that, but you'll need to support that on part of your custom device...

EDIT:

For one-off lab setups, companies that make industrial "data acquisition" interface cards for the PC, tended to also have a model for high-speed parallel digital I/O. I recall the PCI-1755 from Advantech (phased out long ago) that could do 32 bits at 20 MHz = 80 MBytes per second. The external bus was transported over cabling borrowed from SCSI. Internally on the parallel PCI bus, the board was using bus-master DMA. Nowadays, I'd take a look if National Instruments have something, and I know for a fact that Adlink have a whole family of products in that vein.

The PCI interface on a number of industrial IO boards used to be implemented using "slave bridges" by PLX (years ago acquired by Avago, now Broadcom). I remember universal chips such as PCI-9052, PCI-9030, PCI-9056 or PCI-9656 - the latter two can do BM-DMA. As PLX got assimilated, it looked like the these chips were doomed, I guess some even got phased out - and I'm quite surprised to see some of them listed and stocked by Mouser, but look at the prices :-) I believe that there used to be similar chips with a PCI-e interface, but I may be wrong. At the time when it looked like those PLX slave bridges were gone, vendors like Advantech have redesigned many of their boards to use FPGA's for a PCI interface - which made their designs more proprietary and less publically documented. On one board that used to have a PCI slave bridge chip, on a recent revision I have found a chip by Actel - which looks more like an FPGA. Actel's list of IP cores contains several interesting interface blocks, such as PCI-e.

I've also found a stand-alone SERDES transceiver by Texas Instruments, the TLK2501. I'm wondering of this would be compatible with your existing FPGA design. Couple its parallel 16bit local bus to some DMA-capable slave bridge by Broadcom (ex-PLX) and it might as well work...

Chris Stratton has mentioned SATA. That doesn't sound stupid at all. I've even found some SATA host IP core for some Xilinx FPGA that features the necessary differential driver and receiver. Sata Target chips or IP cores are difficult to find though - probably because SATA target boxes are only made by a couple large vendors: two hard drive brands, and maybe some DVD-ROM makers. A number of flash SSD target controllers have a SATA-compatible interface... The target-mode HBA chips used in SATA disk drives (spinning rust) are traditionally made by Marvell, LSI and maybe other such vendors - some are likely private chip models, where a public datasheet isn't even available...

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ I was thinking about transferring the data into another daughter board where it will be buffered and then transmitted to the PC. The thing is that, a soft core processor gets stuck because the UART data does not leave the buffer fast enough. This is where the problem lies. I guess I will have to consider Ethernet based transfer or something else via a daughter board so that the trouble of doing conversion into ASCII and then writing into STDOUT does not burden the main design. \$\endgroup\$ – Quantum0xE7 Jun 29 '20 at 23:00
  • \$\begingroup\$ @Quantum0xE7 What about sending the raw binary data on the UART and doing the "ASCII conversion" and "STDOUT writing" on the PC? \$\endgroup\$ – Bergi Jun 30 '20 at 10:34
  • \$\begingroup\$ Not fast enough, need several 10s of MB \$\endgroup\$ – Quantum0xE7 Jun 30 '20 at 13:52
5
\$\begingroup\$

SERDES is just one component of a communications device implementing a protocol. It is not a devices you can configure and drive without considerable hardware support around it.

If you are NOT using RS232, then most UART implementations are useful out to about 1-3mbps. As long as you have a good common ground and are not going too far (<5m) then a quite ordinary UART is useful here.

If you need to go beyond this speed (1-3Mbps) or drive further then you could (still using a uart) use RS422 line protocol. This is typically good out to about 10Mbps and 15m, but you need very modern MCU based UART implementations to get the higher clock speeds.

You could also consider using an Ethernet controller at 10Mbps without any magnetics. This can work well up to 2-3m. Once you move to 100Mbps and above it is very challenging to design without magnetics. Of course Ethernet IP cores and controllers are readily available out to 1Gbps.

One other suggestion is to use single wire coax media for RF communications. One technique I've used (with 6 Rx/Tx modules) is the NRF24L01+ with SMA connections (don't get the modules with the PA on them). You can connect the modules together using coax and 50 Ohm terminators that are readily available and the system works extremely well. Shockburst mode works at 2Mbps and is rock solid on coax cable. The interface is a simple SPI and the software drivers available for a large range of MCU's.

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

You essentially need an interface for which there are off the shelf implementations on both PC (as an adapter perhaps) and on your FPGA as an IP core.

If your FPGA offers a USB IP core, USB would be an obvious candidate. Otherwise, there's the option of adding a USB converter chip to your FPGA board and used whatever interface it offers: even UART can be fast enough over short distances (FTDI advertises rates up to 12Mbaud in their products), and if that's not fast enough, the next option would be SPI / Quad SPI.

Improve this answer
\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.