Hardware to test (FPGA-based) prototype?

[Alex Rast]

I have an FPGA-based prototype for a PCI product in development. Since the
intended product application will involve very high speed data transfers,
we have designed all the I/O and internal busses in the FPGA to work on
synchronous protocols. Now, however, I'm running into a real stumbling
block.

The problem is in testing the board. What I need to do is to be able to
generate some test data on a PC, and send it to the FPGA, simulating data
flow through the system under test. Similarly, the PC needs to be able to
receive test data from the FPGA. Because of the design of the board, I need
to use a synchronous, hardware-based protocol and interface to transfer the
data.

However, there doesn't seem to be much hardware out there that will enable
me to do this, at least not at reasonable cost. All I need to do is dump
bitstreams in either direction, synchronously, but I have met with little
success. We made an abortive effort to use LabView together with their DIO-
32HS, which seemed promising and (supposedly) offered a high-speed
synchronous protocol, but when we tried to use it, the protocol didn't
work, we couldn't make it work, and apparently nobody at National
Instruments had tried using that protocol and gotten it to work. Indeed, I
saw others posting on the Labview NG, running into the same problems! So
that's not an option.

So, what would be the easiest way to create a test interface that lets us
transfer data using a synchronous protocol at reasonable speeds (at least
10 MHz) between a PC and a device under test? Our prototype board has no
shortage of high-speed, MICTOR connectors that we can use to interface to.
We're willing to spend some dollars to do it, but if it starts escalating
into the thousands of dollars just to get a simple test interface, I think
that such a price is disproportionate relative to what we need to achieve.
So I think a fair budget limit is around $2000. Any suggestions?

 

[Hans-Bernhard Broeker]

[...]

Because of the design of the board, I need
to use a synchronous, hardware-based protocol and interface to transfer the
data.

"A ... protocol" meaning exactly _what_? I'm quite sure you don't
just need some random protocol. You need a piece of hardware and
software that generates and read _exactly_ that protocol your device
under test uses. Regarding which you completely forgot to tell your
readers what that protocol actually is. From what you wrote, it might
well be some completely non-standard homegrown thing. If so, you're
obviously on your own --- oughtta have thought of that aspect, before
you designed that protocol into your hardware. Now you're stuck with
what you have.

Odds are you'll have to build your test harness yourself, in this
case. Software alone won't do (not at 10Mhz on an ordinary PC...),
and a test pulse generator inside the budget limit you gave probably
won't be flexible enough for your needs.

do is dump bitstreams in either direction, synchronously,

.... synchronous to what?

What you would need is essentially the opposite thing to a logic
analyzer or storage scope: a fully programmable logic signal
generator. Where a LA or storage scope has programmable triggers and
logs its results to an internal buffer for later retrieval, you need a
device that has programmable output triggering to output signals
stored in an internal buffer.

To build one yourself, you'll probably need an FPGA board about equally
complicated as the one you're testing.

 

[Nial Stewart]

So, what would be the easiest way to create a test interface that lets us

transfer data using a synchronous protocol at reasonable speeds (at least
10 MHz) between a PC and a device under test? Our prototype board has no
shortage of high-speed, MICTOR connectors that we can use to interface to.
We're willing to spend some dollars to do it, but if it starts escalating
into the thousands of dollars just to get a simple test interface, I think
that such a price is disproportionate relative to what we need to achieve.
So I think a fair budget limit is around $2000. Any suggestions?

Alex,

It sounds like you'd be best using another of your boards as a test
source as Hal suggested.

If you want to use completely independant hardware to verify the
operation of your board you could try using one of my
Cyclone based PCI evaluation boards. See the Hardware
page of my web site below.


Nial Stewart

 

[CBFalconer]

[...]

Because of the design of the board, I need
to use a synchronous, hardware-based protocol and interface to transfer the
data.

"A ... protocol" meaning exactly _what_? I'm quite sure you don't
just need some random protocol. You need a piece of hardware and
software that generates and read _exactly_ that protocol your device
under test uses. Regarding which you completely forgot to tell your
readers what that protocol actually is. From what you wrote, it might
well be some completely non-standard homegrown thing. If so, you're
obviously on your own --- oughtta have thought of that aspect, before
you designed that protocol into your hardware. Now you're stuck with
what you have.

Odds are you'll have to build your test harness yourself, in this
case. Software alone won't do (not at 10Mhz on an ordinary PC...),
and a test pulse generator inside the budget limit you gave probably
won't be flexible enough for your needs.

do is dump bitstreams in either direction, synchronously,

... synchronous to what?

Moral: Don't design hardware without first thinking about testing
it. Or at least enough of it I learned that the hard way a
long time ago, by building a marvelous device that we could never
replicate. Each phase had been driven by a test jig, which was
replaced by the next part of the real device. The final had no
jigs, and no way to prod it.

However I don't think it is quite as bad as you say. Nearly, but
not quite. He will need some sort of hardware fifo, with dual
ports, and a way of loading it from a pc. He probably also needs
the synchronous interface module to unload the fifo, which may be
another of his systems.

He could start with something that continuously unloads one simple
pattern.

 

[Rene Tschaggelar]

I have an FPGA-based prototype for a PCI product in development. Since the
intended product application will involve very high speed data transfers,
we have designed all the I/O and internal busses in the FPGA to work on
synchronous protocols. Now, however, I'm running into a real stumbling
block.

The problem is in testing the board. What I need to do is to be able to
generate some test data on a PC, and send it to the FPGA, simulating data
flow through the system under test. Similarly, the PC needs to be able to
receive test data from the FPGA. Because of the design of the board, I need
to use a synchronous, hardware-based protocol and interface to transfer the
data.

However, there doesn't seem to be much hardware out there that will enable
me to do this, at least not at reasonable cost. All I need to do is dump
bitstreams in either direction, synchronously, but I have met with little
success. We made an abortive effort to use LabView together with their DIO-
32HS, which seemed promising and (supposedly) offered a high-speed
synchronous protocol, but when we tried to use it, the protocol didn't
work, we couldn't make it work, and apparently nobody at National
Instruments had tried using that protocol and gotten it to work. Indeed, I
saw others posting on the Labview NG, running into the same problems! So
that's not an option.

So, what would be the easiest way to create a test interface that lets us
transfer data using a synchronous protocol at reasonable speeds (at least
10 MHz) between a PC and a device under test? Our prototype board has no
shortage of high-speed, MICTOR connectors that we can use to interface to.
We're willing to spend some dollars to do it, but if it starts escalating
into the thousands of dollars just to get a simple test interface, I think
that such a price is disproportionate relative to what we need to achieve.
So I think a fair budget limit is around $2000. Any suggestions?

I had a National Intsruments HS32 board too.
Even though it appears to offer half a dozend protocols, none worked for us.
The protocols worked, but we were unable to use them to our hardware.
The support of NI was (well they tried but to no avail) lacking.
Their forums aren't that supportive and very slow.

I'd suggest to use a second of your boards.
You don't need its PCI interface, just reload some other firmware
into the FPGA to let it act as pattern generator.
If you don't happen to have a second board, you may let us know
what FPGA with what interface you wish to use.
One may have a spare board.

Rene

 

[Alex Rast]

at Fri, 16 Jan 2004 14:53:36 GMT in <[email protected]>,

In comp.arch.embedded Alex Rast <[email protected]>
wrote:

[...]

Because of the design of the board, I need
to use a synchronous, hardware-based protocol and interface to
transfer the data.

"A ... protocol" meaning exactly _what_? I'm quite sure you don't
just need some random protocol. You need a piece of hardware and
software that generates and read _exactly_ that protocol your device
under test uses.

Actually, we can pretty much indeed use any protocol, as long as it's
synchronous (i.e. uses a continuous clock signal to time transactions)
That's the nice thing about an FPGA - it's reconfigurable. I designed an
internal test port that on the one side has the interface to our bus inside
the FPGA, and on the other side has an interface to whatever test fixture
we decided to use. The external interface is interchangeable, so we can
devise it to suit a wide variety of possible protocols.

Moral: Don't design hardware without first thinking about testing
it. Or at least enough of it

We did think very long and hard about testing, and had several meetings
where we really examined the design carefully, with a view to testability.
But there's also the side of that your board needs to do what it needs to
do. There's not much good designing a highly testable board that doesn't
perform the task you're designing it for. It does seem to me that the
available testing options for high-speed, synchronous interfaces are very
few and far between. The option that people have been recommending, of
putting another identical board in our system to use as a test interface,
is one I thought about and I think, with the consensus being that this is
the best way to go, is what I'll do. Is this, then, the typical way people
test high-speed cards and interfaces? I'm quite surprised that there aren't
more testing/prototype systems available for these kinds of hardware, which
must surely be extremely common.

 

[Nico Coesel]

We did think very long and hard about testing, and had several meetings
where we really examined the design carefully, with a view to testability.
But there's also the side of that your board needs to do what it needs to
do. There's not much good designing a highly testable board that doesn't
perform the task you're designing it for. It does seem to me that the
available testing options for high-speed, synchronous interfaces are very
few and far between. The option that people have been recommending, of
putting another identical board in our system to use as a test interface,
is one I thought about and I think, with the consensus being that this is
the best way to go, is what I'll do. Is this, then, the typical way people
test high-speed cards and interfaces? I'm quite surprised that there aren't
more testing/prototype systems available for these kinds of hardware, which
must surely be extremely common.

You could try to obtain a used DAS9200 or TLA510 system with a pattern
generator board (these generate patterns based on a 50MHz clock).
These systems are for sale on Ebay every now and then.

 

[john jakson]

You could try to obtain a used DAS9200 or TLA510 system with a pattern

generator board (these generate patterns based on a 50MHz clock).
These systems are for sale on Ebay every now and then.

Or you can rent these things from companies like ElectroRent IIRC or
GE or whatever. They are not that difficult to use, we used to have a
HP PG on the network to download files into ram and that would throw
the pattern at your HW. The matching HP LA would observe the results
and get it back onto the network.

The only issue I had was the memory buffers were very small relative
to PC memory and the bus widths were too narrow, kinda dinasours by
todays std.

An FPGA just calls out to be used as an PG+LA in a box to custom spec,
but thats another project. Or just use one of the ready made boards
withs lots of IO and onboard ram.

johnjakson_usa_com