Hardware to test (FPGA-based) prototype?

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? 

-- 
Alex Rast
ad.rast.7@nwnotlink.NOSPAM.com
(remove d., .7, not, and .NOSPAM to reply)

>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? 

Can you cross connect two of your boards?  Possibly running
totally different test code in the helper board.

If your board isn't quite right, you might browse through
the prototype/demo board list and see if you can find one
that looks good.  I'm thinking of PCI, FPGA, Memory, and some
connector you can get to.  Load the memory from PCI, turn the
FPGA loose to read the data out of memory and feed it to your
system.  That gives you a burst for as long as the memory
has room for your pattern.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

In comp.arch.embedded Alex Rast <ad.rast.7@nwnotlink.nospam.com> 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.  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.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

> 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

------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
Cyclone based 'Easy PCI' eval board
www.nialstewartdevelopments.co.uk

Hans-Bernhard Broeker wrote:
> 
> In comp.arch.embedded Alex Rast <ad.rast.7@nwnotlink.nospam.com> 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.  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. 

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Alex Rast wrote:
> 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
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

at Fri, 16 Jan 2004 14:53:36 GMT in <4007EF4F.16A1C673@yahoo.com>,
cbfalconer@worldnet.att.net (CBFalconer) wrote : 

>Hans-Bernhard Broeker wrote:
>> 
>> In comp.arch.embedded Alex Rast <ad.rast.7@nwnotlink.nospam.com>
>> 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. 

-- 
Alex Rast
ad.rast.7@nwnotlink.NOSPAM.com
(remove d., .7, not, and .NOSPAM to reply)

>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. 

I don't know if "typical" is the right word, but it seems like one
of the obvious advantages of using an FPGA.  (aka you can reprogram
it to do something else)

One important consideration for using your own board:  You are already
familiar with the tools and all the details of the hardware.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

ad.rast.7@nwnotlink.NOSPAM.com (Alex Rast) wrote:

>
>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.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Alex Rast wrote:
>  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. 

One reason may be that simulation is commonly used
for design verification of synchronous logic.


    -- Mike Treseler