Larkin should like The Unix Haters Handbook

[Tim Williams]

http://simson.net/ref/ugh.pdf

About halfway through, they talk about C and C++, too. I must say, the
similarities and pitfalls are astounding, and spot on to John's lamentations
over C and such.

Noteworthy: it's about Unix, not Linux or any of the myriad derivatives. I
wonder how some of the popular modern forks, like the popular Debian,
differ. I'm willing to bet they still inherit most of the 1MLOC+ of refuse
from the previous 30 years of development though.

Tim

 

[Nico Coesel]

Cool; I'll make time to read that soon.

We just hired our first official Software Engineer (we aren't allowed
to call him a programmer) for this Linux box we're doing.

So we got the PLX demo board (for their PCIe interface chip) and their
Linux drivers. The drivers don't work, of course. So, in time-honored
fashion, we are now recompiling both the driver *and* the Linux
kernel, together, to try to resolve the incompatibilities.

http://xkcd.com/456/

Yup. After about a man-month (which is about 250 hours in this biz)
it's mostly working. I don't often spend that sort of time on an
entire, bare-metal embedded product.

Perhaps hire someone better. At a previous employer we hired a real
Linux expert. A driver for 'our' PCI card only took him 2 or 3 days.

Lately I have been doing a lot of Linux kernel hacking myself for a
product which uses Linux on an embedded and I must say most stuff in
the Linux kernel is pretty straightforward.

 

[Nico Coesel]

They don't get much better than this guy. Trust me on that.

Nobody is perfect... Perhaps it takes a more hardware oriented guy.
The Linux guru I worked with connected the parallel port to an Agilent
MSO. He used that to debug the driver in realtime by writing state
information to the printer port. The ability to load/unload a Linux
kernel driver makes it possible to have very short turn-around times.
No need to recompile the entire kernel or reboot the machine. It just
shouldn't take that long to get a driver up and running.

But the PLX chip isn't. The "data sheet" is a 592 page PDF file.

Depends on the writers. Infineon (formely Siemens) can spend over 300
pages on what Zarlink (formerly Mitel) can explain using only 20
pages. Both describing similar chips.

 

[krw]

Because he doesn't want us to.

That's fine; titles are the cheapest thing we have.

Yep, they are in small companies (they asked me what I wanted on my
business cards). Titles are important in large companies though.
Lawyers have seen to that.

 

[Allan Herriman]

We're using this one:

http://www.plxtech.com/products/expresslane/pex8311

There's actually two chips in the package, a PCIe-to-PCI bridge, and a
PCI-to-local-bus sort of thing. We're using it to go from an embedded PC
to an FPGA on our board.

The two bridges in that package even have different core supply
voltages. I asked the local PLX rep about a better integrated solution
that used the same supply voltage throughout, and he swore that the '8311
was monolithic. I don't think he understood the question though.

Cascaded bridges hurt throughput for random accesses, as the access time
is determined by the latency (which will increase when you have two
bridges). It shouldn't matter much for streaming data though.

Regards,
Allan

 

[Allan Herriman]

At 66 MHz, doing 32-bit DMA transfers, it seems to do something like 32
transfers, rest for 8 clocks, 32 transfers, etc. So it averages about 56
MHz x 32 bits. Our ADC will do 64 Ms/s max, 16 bit data, so it's sort of
OK. We'll do a bit of FIFO in the FPGA to smooth things out.

The Gennum chip is four lanes (PLX is only one) so should scream. But it
requires a lot of the DMA logic to be in the FPGA, and they are still
promising Linux drivers some day... tempting but too risky.

This one looks even better, but I'm not sure I'd want to use it without
an English language data sheet:

http://www.avaldata.com/products/y2_technology/pci-express_bridge/
aaeb04.html
PCIe x4 lanes, 2xDMA, DDR SDRAM controller (presumably for DMA buffers),
2x I2C controllers, SPI, 8x GPIO, FPGA configuration logic, serial port,
64 bit / 133MHz local bus.

I found a product brief in English here:
http://www.daitron.com/aval_data/pdf/AVAL DATA Brief Sheet Jul23%
2008.pdf

Regards,
Allan

 

[Allan Herriman]

Oops.

These links should be more clickable now that I've turned wrap off:

http://www.avaldata.com/products/y2_technology/pci-express_bridge/aaeb04.html

http://www.daitron.com/aval_data/pdf/AVAL DATA Brief Sheet Jul23 08.pdf

Regards,
Allan

 

[Nico Coesel]

That is true, but if your module hangs, then you will need to reboot....

Yes... but that would only happen a few times. When using the parallel
port (or GPIO) debugging you can see exactly where it hangs.

What is a 'PLX' chip?

A 'PLX chip' is short for a range of chips made by PLX to offer a
simple (ISA like if you want) interface to a PCI or PCI express bus.
These chips are more or less industry standard. For low and mid volume
products it makes no sense to put a PCI express or PCI core into an
FPGA.

 

[Nobody]

We just hired our first official Software Engineer (we aren't allowed
to call him a programmer) for this Linux box we're doing.

So we got the PLX demo board (for their PCIe interface chip) and their
Linux drivers. The drivers don't work, of course. So, in time-honored
fashion, we are now recompiling both the driver *and* the Linux
kernel, together, to try to resolve the incompatibilities.

Drivers are quite sensitive to the kernel version. While userspace only
cares about 2.4 versus 2.6, drivers will often care about 2.6.26 versus
2.6.27, and occasionally care about 2.6.27.9 versus 2.6.27.10 (the latter
shouldn't happen, but nobody's perfect).

 

[Nico Coesel]

Drivers are quite sensitive to the kernel version. While userspace only
cares about 2.4 versus 2.6, drivers will often care about 2.6.26 versus
2.6.27, and occasionally care about 2.6.27.9 versus 2.6.27.10 (the latter
shouldn't happen, but nobody's perfect).

There are some changes in the driver model for the Linux kernel every
now and then. A bit of a pain in the ass but unavoidable due to
technological advances. The same happens with windows.

 

[Allan Herriman]

That would just complicate life.

If we were doing volume stuff, we could go PCIe straight into the FPGA.
But the engineering and the risk would be absurd, and we'd probably come
out behind on dollars... the PLX chip is cheap, and lets us use a
cheap/slow Spartan FPGA.

Virtex6 and Spartan6T have built in PCIe end points (hard cores - let's
hope they get the bugs out before shipping). This should give higher
performance, and I'm expecting the Spartan6T ones to be cost competitive
with external bridges.

Because they are hard cores, there will be well tested application notes
and sample designs, which hopefully will reduce the risk somewhat.

The PLX turns PCIe into a relatively simple parallel memory-bus sort of
interface. We're planning to hop a short PCIe "riser" cable from the SBC
to our custom board, straight into the PLX chip. After that, it's all
slow (66 MHz) parallel stuff.

The PLX chip doesn't support configuring the FPGA (Gennum and others do)
so we'll do that off to the side, from a printer port connector.

This can also be done over USB using an FTDI chip, if you have a spare
USB port available. You can use existing driver software if you copy the
design of one of the JTAG programmers.

Regards,
Allan

 

[krw]

That would just complicate life.

If we were doing volume stuff, we could go PCIe straight into the
FPGA. But the engineering and the risk would be absurd, and we'd
probably come out behind on dollars... the PLX chip is cheap, and lets
us use a cheap/slow Spartan FPGA.

I did the same with a Virtes-E and PLX PCI bridge chip, some years
back. There were no odds in messing with PCI.

The PLX turns PCIe into a relatively simple parallel memory-bus sort
of interface. We're planning to hop a short PCIe "riser" cable from
the SBC to our custom board, straight into the PLX chip. After that,
it's all slow (66 MHz) parallel stuff.

The PLX chip doesn't support configuring the FPGA (Gennum and others
do) so we'll do that off to the side, from a printer port connector.

Have you considered using Actel? I may go that way on my next design.
Configuration is a PITA for a small design. If bleeding edge speed
isn't needed there is no reason to go for an SRAM based FPGAs.

 

[Tim Williams]

Yeah, it's all VHDL and stuff. I was quite shocked when several years ago
I had to explain the most basic analog stuff in my circuits to a guy with
a fresh M.S.E.E. The transistor-level side of things just was not there at
all. That's ok, I'll gladly do that, but what happens when us old farts
are, say, in our 80's?

Ooh ooh, I know the answer!

It means more business for me. ;-)

Tim

 

[Nico Coesel]

Consider the simplest possible computer interface, one that lets you
read the level of a single TTL input.

CAMAC: Takes one SN7438

VME: Two chips, an MSI address comparator and a 7438.

ISA: ditto, maybe less. Actually, you could do it with one gate. And a
single-line Basic program will print things like "The bit is HIGH", no
drivers required.

PCI, USB, PCIe: simply not feasible to design the hardware from
scratch (well, maybe PCI into an FPGA... maybe) and then you still
need drivers.

I guess that at some point the PCs will start to use IP internally to
connect all the peripherals. PCI express offers backwards
compatibility with PCI but under the hood PCI express behaves like a
network. Because PCI express is serial it can be extended with a cable
as well.

Anyway, in a short while USB3.0 will see the daylight. Some people
already predicted USB 3.0 will replace PCI express and SATA. We'll
propably see motherboards without expensions slots in a few years.

 

[Fred Bartoli]

Tim Williams a écrit :

Ooh ooh, I know the answer!

It means more business for me. ;-)

Tim

But you're using way too much transistors...