What's Your Favorite Processor on an FPGA?

Microsoft

RSTS mapped code pages to be execute-only (apps couldn't write to code space) and data/stack pages were non-executable. Stack overflow and buffer overrun exploits were prevented by hardware. Both Intel and Microsoft were out of the mainstream of computing, which is why we have such a mess today.

om

ly.

b16

ures

U. It

ter

A pins and

tandard

ansparent

shared

ithout

ools.

at one point it did crash alot, but I haven't had many problems with it for the past few years

-Lasse

Microsoft

I've had Win2K run over nine months, between power failures that lasted longer than the UPS batteries. DEC had more control over the computers, and a tiny fraction of the number running Windows or Linux.

If DEC was so damned good, why were they unable to survive? Their IBM 'clone' (Rainbow 100) was very overpriced, not compatible, and did a very quick death spiral. Admit it. It was a dinosaur company with a very tiny customer base.

Microsoft

Intel & Microsoft are the mainstream today, and DEC is in the scrapyard of computing history.

You've just described PCI Express.

- Industry standard fast serial interface.

- AC-coupled CML (rather than LVDS, but still differential).

- scalable bandwidth:

- 2.5, 5.0, 8.0 Gbps per lane.

- 1, 2, 4, 8 or 16 lanes.

- allows single access as well as bursts.

- multi-master (allows DMA).

- Fabric can be point-to-point (e.g. CPU-FPGA) or can use switches for larger networks.

- in-band interrupts (saves pins).

- Peripherals (typically) just appear as chunks of memory in the CPU address space.

- Widely supported by operating systems.

- Supports hot plug.

- Many FPGAs have hard cores for PCIe.

- Supported by ARM SoCs (but not the very cheapest ones).

- compatible with loads of off the shelf chips and cards.

- Easy to use (although that might be an "eye of the beholder" type of thing).

I wouldn't recommend PCIe for the lowest cost or lowest power products, but it's great for the stuff that I do.

Regards, Allan

No

Microsoft

Tragically so. The thing that Intel and Microsoft had in common was brutal rapaciousness. That often overcomes quality.

But Dec's PDP-11 bagat Unix, which begat Linux, then MacOS, then Android...

in

Microsoft

It was *the* minicomputer company and that changed the world.

No. PCIe is insanely complex and has horrible latency. It takes something like 2 microseconds to do an 8-bit read over gen1 4-lane PCIe. It was designed for throughput, not latency.

We've done three PCIe projects so far, and it's the opposite of "transparent and easy to use." The PCIe spec reads like the tax code and Obamacare combined.

Next up is Thunderbolt, probably worse.

I agree about it being designed for throughput, not latency. However, with a fairly simple design, we can do 32 bit non-bursting reads or writes in about 350ns over a single lane of gen 1 through 1 layer of switching. I suspect there's some problem with your implementation (unless your 2 microsecond figure was just hyperbole).

I found the spec clear. It's rather large though, and a text book serves as more friendly introduction to the subject than the spec itself.

One of my co-workers was confused by the way addresses come most significant octet first, whilst the data come least significant octet first. It makes sense on a little endian machine, once you get over the WTF.

Hot plug is the only thing that gives us headaches. PCIe Hot plug is needed when reconfiguring the FPGA while the system is running. OS support for hot plug is patchy. Partial FPGA reconfiguration is one workaround (leaving the PCIe up while reconfiguring the rest of the FPGA), although I haven't tried that in any production design yet.

Regards, Allan

Writes are relatively fast, ballpark 350 ns gen1/4lane. Reads are slow, around 2 us. That's from an x86 CPU into the PCIe hard core of an Altera FPGA, cabled PCIe. A read requires two serial packets so is over twice the time of a write.

A random read or write from an embedded CPU, to, say, a DPM in an FPGA, really should take tens of nanoseconds. We do parallel ARM-FPGA transfers with a klunky async parallel interface in 100 ns or so, but it takes a lot of pins.

From an x86 (not that we'd ever use an Intel chip in an embedded app) we haven't found any way to move more than 32 bits in a non-DMA PCIe read/write, even on a

Little-endian is evil, another legacy if Intel's clumsiness.

We are still trying to get hot plug to work, both Linux and Windows. HELP!

I thought it was faster than that. If I remember, I'll measure some in the lab tomorrow.

BTW, the write requires two packets as well.

I don't know anything about hot plug support on Windows. On Linux, however, there are two ways to do it:

- True hot plug. You need to use a switch (or root complex) that has hardware support for the hot plug signals (particularly "Presence Detect" that indicates a card is plugged in). The switch turns these into special messages that get sent back to the RC, and the OS should honour these and do the right thing. This should work on Windows too, as it's part of the standard.

- Fake hot plug. With the Linux "fakephp" driver you can fake the hot plug messages if you don't have hardware support for them. This isn't supported in all kernel versions though. Read more here:

In both cases there can be address space fragmentation that can stop the system from working. By that I mean that the OS can't predict what will be plugged in, so it can't know to reserve a contiguous chunk of address space for your FPGA. The OS may do something stupid like put your soundcard right in the middle of the space you wanted. Grrr.

Recent versions of the Linux kernel allow you to specify rules regarding address allocation to avoid the fragmentation problem, but I've never used them and I'm not a kernel hacker, so I don't know anything about that.

Regards, Allan

Does it? Writes are buffered and there is some token-quota mechanism that lets writes blast away, and there may be a "back off, Sam!" reply packet now and then if the target can't keep up. If the target is fast, like a RAM or something, that won't happen, and writes are packet limited in one direction. Probably.

Yeah, Microsoft lives to honor standards.

We're assuming that an application will crash if its memory-mapped target region (in our case, the remapped VME bus) vanishes. What we can't do so far under Linux is re-enumerate the PCI space and start things back up without rebooting. We're still working on it. We have implemented all the optocoupled sideband signals for hot plug, and training packets resume after we reconnect. We're still working on it.

in

Microsoft

The 8086 had execute privileges on the segment register level and thus comparable to PDP-11 with eight up to 8 KiB segments with different protection attributes.

With 80386 and some sort of virtual memory support, unfortunately Intel forgot to include the exe/noexe bit in each page table entry (as in VAX/VMS), but still relied on the segment register protection bits.

Murphy

in

No

Microsoft

The first Intel family member to have segment-based protection was

There is certain sense in Intel's policy: segmentation is for protection and paging for virtual mempry under it.

rote:

ve

e.

round 2

led

rite.

eally

klunky

haven't

n on a

nd

ves

he

why is it any more or less evil than big endian?

-Lasse

I have actively tried to forget that I idid some satellite image and planeratory probe image analyzing using an i286 machine with a 10 MHz clock :-)

!sdrawkcab s'ti esuaceB

--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation

Most entry level scopes consist of an FPGA running a soft processor.

and

You mean PCI express? :-)

With fakephp, you should just need to rescan that slot. With proper hot swap hardware support, it should just happen automatically. (As if anything would go wrong with that!)

When the hot plug removal event happens, the OS is meant to unload the drivers.

The drivers get reloaded after the hot plug insertion event. Possibly not the same drivers as before, if the FPGA contains something else.

Your higher level application needs to be aware that the driver can come and go with the hot plug events. You'll need some sort of mechanism to inform the application (e.g. a signal). Presumably the application is the actual cause of the FPGA reconfiguration, in which case it knows when the FPGA is there or not and doesn't need to be told.

I found that just the presence detect was needed for reliable hot plug. All the others are optional.

Regards, Allan