LAVA Forums Buy cool LAVA gear Forums RSS Feed

Welcome Guest ( Log In | Register )

> Related links

Visit our LabVIEW Wiki LabVIEW Embedded Portal


Tags
(This content has not been tagged yet)
 
Reply to this topic Start new topic
> FPGA DATA Transmission corruption, Labview fpga and Realtime
wallyabcd
post May 19 2005, 04:48 PM
Post #1


Active
*

Member
Posts: 21
Joined: 27-August 04
Member No.: 633
LV:8.0
Switzerland Cameroon United States


Hello Fellows;

I am having a few problems and I am wondering if anyone has encountered similiar things or knows why...
I have a setup with a 7831R FPGA board and 8145 RT board. Basically one portion of the program gets
data from the fpga and sends it to the realtime board using interrupts and synchronous variable...
On the realtime system, the data is received and put into a realtime fifo for processing elsewhere.

I have about 3 types of data packages that are sent from the fpga. One consist of 48 elements, another of 128
and one of 16384. All of then are unsigned 32bits numbers.
The first and the last one appear to come through without a problem even at high speed.
The moment try sending the package of 128 units of unsigned 32bits numbers, a very high peak noise is introduced
into all the other data streams. I have even wired constants to all data streams and the same problem occurs.
Slowing down doesn't help. I put in code to check the data just before it's written to the synchronous display
and it's error free. I have recreated the fifos and memory blocks on the fpga for no avail...

The interesting thing is that if I transmit just one data stream at a time, things work fine. The moment I start
alternating, the problem returns.

Sending the data using interrupt only for notification, regular display and binary handshaking works fine but it's slow.

My suspicions are perhaps I am exceeding the rate at which a synchronous display can be written and read ?
Any one knows ???

Walters
SpinX Technologies

--------------------
Man, know thyself...


Tags
(This content has not been tagged yet)
Go to the top of the page
+Quote Post
Ad
post May 19 2005, 04:48 PM
Post #















Tags
(This content has not been tagged yet)
Go to the top of the page
Quote Post
PitchNancy
post May 25 2005, 06:50 AM
Post #2


4 more posts to go!


Member
Posts: 6
Joined: 18-February 05
Member No.: 1636
LV:7.1.1
France


The communication rate with interruption probably not exeed 1 Mo / s, it's very slow... What's your data sampling rate ?

This post has been edited by PitchNancy: May 25 2005, 06:51 AM


Tags
(This content has not been tagged yet)
Go to the top of the page
+Quote Post
wallyabcd
post May 25 2005, 10:20 AM
Post #3


Active
*

Member
Posts: 21
Joined: 27-August 04
Member No.: 633
LV:8.0
Switzerland Cameroon United States


The whole thing is event driven. For example it the infra laser fires up, the 2 photo multipliers fire up and generate 16834 samples or for each segment that a motor goes through generates timing pulses...

Even slowing down this events to rediculous slow speed didn't make a difference; or putting delays in
between transmitting each U32 number via synchronous variable...
I am also reading about 2 dozen indicators off the FPGA frontpanel
Which suggest that if the problem is bandwidth it must happen just momentarily...
The corruption is consistent and always at the same place...

My thinking though is that for the 7831R, using a synchronous display must definitely put a constrain on
the speed and or bandwidth effectively reducing both or one or the other...

Wally


QUOTE (PitchNancy @ May 25 2005, 06:50 AM)
The communication rate with interruption probably not exeed 1 Mo / s,  it's very slow...  What's your data sampling rate ?
*

--------------------
Man, know thyself...


Tags
(This content has not been tagged yet)
Go to the top of the page
+Quote Post
wallyabcd
post Feb 3 2006, 01:13 PM
Post #4


Active
*

Member
Posts: 21
Joined: 27-August 04
Member No.: 633
LV:8.0
Switzerland Cameroon United States


Well,

This problem was solved by breaking the communication routine into two. It became clear that the
communication channel whatever the cause could not sustain the data trasfer rate in due in part
to the larged number ofront panel objects to be read from the fpga.
The sepration allowed the silencing of certain parts when needed. This was an interim solution
while waiting for DMA transfer which are here now in LV8.0

Wally


QUOTE (wallyabcd @ May 25 2005, 10:20 AM) *
The whole thing is event driven. For example it the infra laser fires up, the 2 photo multipliers fire up and generate 16834 samples or for each segment that a motor goes through generates timing pulses...

Even slowing down this events to rediculous slow speed didn't make a difference; or putting delays in
between transmitting each U32 number via synchronous variable...
I am also reading about 2 dozen indicators off the FPGA frontpanel
Which suggest that if the problem is bandwidth it must happen just momentarily...
The corruption is consistent and always at the same place...

My thinking though is that for the 7831R, using a synchronous display must definitely put a constrain on
the speed and or bandwidth effectively reducing both or one or the other...

Wally

--------------------
Man, know thyself...


Tags
(This content has not been tagged yet)
Go to the top of the page
+Quote Post

Reply to this topicStart new topic

 




Time is now: 1st December 2008 - 09:22 PM