Spartan® Family FPGAs

[mow2000]

I'm attempting to connect the I/O (single ended) between two Spartan 3a boards.  One board simply transmits a five-bit counter (parallel) with clock and the other board is supposed to receive the counter and send the results to my PC via ethernet. The boards are on separate power supplies.

I've seen some strange results.  It occasionally works then stops working (i.e. sends good data then sends jumbled data).  It doesn't seem to work when the two boards are grounded together.  My electrical engineering skills are pretty rusty...  It seems that I would need a common power supply to make this work.  At the very least the ground would have to be common.  But not understanding the I/O interface circuitry I can't really explain what's going on.  The Starter Platform User Guide doesn't seem to give enough info on the I/O.  I've thought about using opto-couplers...

Thanks.  Any help is appreciated.  Hope I've outlined the problem sufficiently.

Mark

[eteam00]

Useful information to add to your post:

• Data, clock frequency
• Data, clock timing waveforms (or simply post the code on the transmit end which generates the clock and data signals).
• Post your receive end code for sampling the data, and aligning the sampled data to receive FPGA's system clock.
• IOSTANDARDs specified on each end
• interconnect skew between the data and clock lines between the two FPGAs
• VCCO supplies on each end of the bus.

-- Bob Elkind

[mow2000]

thanks for the quick response:

I have boiled it down to some very simple test code.  At this point I'm just using a push button to toggle the clock/counter on the other end lighting some LEDs with the received five bits.  I've boiled down the code below.  Hopefully not too much.

* Data, clock frequency ~ 0.1 Hz (I have clock rigged to a push button - push high - push low, etc)

* Data, clock timing waveforms (or code):  I can see the clock and data on an oscilloscope and they appear correct:

always @(posedge clk) begin
    if (debouncedbuttonpress)
       begin
            clk1out <= ~clk1out;       // data clock out
            case (clk1out)
               1 : begin
                   data1 <= data1 + 1;        // increment
                    data1out <= 0;
                    end
               0 : 
                   data1out <= {0,0,data1};   // data out
            endcase
            clockCount1 <= 0;
        end
    else
            clockCount1 <= clockCount1 + 1;
end

from ucf file:

NET "TXA[0]" LOC = F20; # J2-24
NET "TXA[0]" SLEW = FAST;
NET "TXA[1]" LOC = H17; #
NET "TXA[1]" SLEW = FAST;
NET "TXA[2]" LOC = A19; #
NET "TXA[2]" SLEW = FAST;
NET "TXA[3]" LOC = F19; #
NET "TXA[3]" SLEW = FAST;
NET "TXA[4]" LOC = C18; #
NET "TXA[4]" SLEW = FAST;
NET "CLKA" LOC = B19;   #
NET "CLKA" SLEW = FAST;

* Post your receive end code for sampling the data:

// ucf is similar to above

always @(posedge CLKA) begin
   tled1 <= RCVCH1[0];
   tled2 <= RCVCH1[1];
   tled3 <= RCVCH1[2];
   tled4 <= RCVCH1[3];
   tled5 <= RCVCH1[4];
end

* IOSTANDARDs specified on each end

Hmm...  I didn't do this.  I did not specify an IOSTANDARD in the ucf for these I/O pins....

* interconnect skew between the data and clock lines between the two FPGAs

If this is relavant given above then I can try to figure this out.

* VCCO supplies on each end of the bus

both jumpered for 3.3V

[eteam00]

I was hoping your comments would describe what your code is supposed to do, but that isn't the case.

The next logical steps are:

• describe what your code does (how it works)
• the expected behaviour
• the observed (presumably faulty) behaviour

Does this make sense?

-- Bob Elkind

[mow2000]

What I was initially attempting to find out is if it's indeed possible to connect the I/O on two separate Spartan boards.  I'm guessing from your questions that it is and that you think I possibly have a code or configuration issue.  Am I reading you correctly?

My test code simply drives a clock output high and a data line high or low.  On the receiving end it sets an LED to that data line on the positive clock edge.  Usually I see the LED being driven but occasionally it is not.

Thanks for the help.

[gszakacs]

I think what Bob was getting at is that you have a system with a source-synchronous clock.

This means that you need to ensure setup and hold timing (by design) at the driving end

of the system.

I'm not sure what your code was intended to do, but it appears that it clears the data output

at the same time it drives the clock output low.  This implies zero hold time at the receiving

end if you use the falling edge or zero setup time if you use the rising edge.  Probably not

what you wanted.  This would be independent of the clock period.

If the data output from the first board is data1out and the clock output is clk1out, then I would

recommend getting rid of the line:

                   data1out <= 0;

in the  first case of the case statement.  This would allow the data to hold its current state

at one of the two clock edges.  Also note that the current state of clk1out, as used by the

case statement, is the state before the transition.  So case 1: indicates the actions to take

at the same time the clock goes low.  If you want to receive data on the rising edge of the

clock, then you should also reverse the 0: and 1: cases so the data only changes on

the falling edge of clk1out.  That gives you plenty of setup and hold time at the receiver,

at least until your clock goes well over 100 MHz.

You are correct in that the grounds should be connected between the two boards.  If you

have a voltmeter handy, you could check whether the supplies are isolated by metering

voltage between the two board grounds when they are not connected to eachother

and both powered up.  If you see a constant DC voltage, then you could have problems

trying to tie the grounds and may need isolators.

HTH,

Gabor

[gszakacs]

I just noticed another thing:

                  data1out <= {0,0,data1};   // data out

Those unsized zeroes are interpreted as 32 bits each.  So the right-hand side

of the assignment would be 64 bits plus the width of data1.  If you meant it

to be only two bits wider, then you should use 1'b0 for each "0" or combine them

like {2'b0,data1}, or just write data1out <= data1; and get the default zero-extension

required by the Verilog LRM (unless data1 is signed).

-- Gabor

[mow2000]

I hadn't considered setup time.  My thought was that the clock and data would transition together (for example clock high and data[0] high).  The receiver would see a posedge and a data[0] high and read that as a '1' bit.  I didn't realize I needed a setup time.

Setting data1out <= 0 was actually a hack to try to fix the problem.

Oddly enough it is coded to receive data on the rising edge of the clock.  It doesn't seem like it should but I have verified it on the scope.  That's why the 1 case comes before the 0 case.  Originally it was 0 then 1 but the data was changing on the negative edge of the clock - so I reversed the numbers.  Something must be getting inverted somewhere...

The code I pasted is some simplified test code.  What I'm attempting to do is read a clocked five bit data line.  On each positive transition of the clock I will read the five bits and stuff them into a FIFO.  The contents of that FIFO are then sent out as an ethernet packet.  I have it completely coded and it occasionally works.  I guess the lack of setup time could explain the problem.

[eteam00]

What I was initially attempting to find out is if it's indeed possible to connect the I/O on two separate Spartan boards.  I'm guessing from your questions that it is and that you think I possibly have a code or configuration issue.  Am I reading you correctly?

Yes.

I tried to understand what you were trying to do by looking at your code, because you didn't provide an explanation.  And I could not make sense of your code.

What is debugging?

• Behaviour debugging is comparing what your design is intended to do against what it does, and developing reasons (possible causes) for any differences.

• Implementation debugging is comparing what your design is intended to do against a line-by-line understanding of what your code actually does.

For a snippet of code as small as your example, debugging should be pretty quick and simple, if only you have a clear idea of how our code is supposed to work.  In 4 posts to this thread, you still have not adequately described how your design is intended to work, which helps explains why you cannot (yet) debug it.

You will be making coding errors throughout your life.  If Gabor or someone else points out a coding error of yours, we will have saved you an hour or two of head-scratching -- perhaps.  But if you learn how to debug your own code and your own designs, you will probably live longer and can afford to marry your childhood sweetheart and raise a huge family of kids.

From the New Users Forum README post:

A useful and complete description of the design demonstrates that you understand your design and the problem.  Often, taking the time to describe your design will help you to organise your thoughts and your understanding -- and this will help lead you to the source of your problem.

Another part of the debugging by comparison approach is that your code is missing comments which explain to you how your design  implementation is intended to function.

So I figured that if you placed yourself in my position -- reviewing your own code -- it would lead you to the steps required to debug your own design.

These steps start with two items to compare:

• What is the intended function (of the behaviour or of the section of code)
• What is actually happening (in terms of observed behaviour or a line-by-line uderstanding of the code)

If you can learn to debug your own code, you don't need me or Gabor to do it.  And this is my point.  Your employer will thank me, your childhood sweetheart will thank me, and your large family of kids will thank me.  Yes?

-- Bob Elkind

[eteam00]

The code I pasted is some simplified test code.  What I'm attempting to do is read a clocked five bit data line.  On each positive transition of the clock I will read the five bits and stuff them into a FIFO.  The contents of that FIFO are then sent out as an ethernet packet.  I have it completely coded and it occasionally works.  I guess the lack of setup time could explain the problem.

Let me help with some pseudo code...

Transmit side first:

On each positive transition of the clock I will read the five bits and stuff them into a FIFO.

Start:  set output clock LOW

        wait for <button press>

        update output data

        insert delay here for additional SETUP time

        set output clock HIGH

        insert delay here for additional HOLD time

        loop to Start

Receive side:

On each positive transition of the clock I will read the five bits and stuff them into a FIFO.

On positive edge of input clock, write input data into FIFO

or

Start: wait for rising edge of input clock

       write input data to FIFO (or packet assembly code)

       loop to Start

Voila!

Next question:  how does your code do this (or not do this)?

With an 'outline' like this, each line (or sequence of lines) of code should match to a single line of pseudo code.  Comments in your code help you to relate the implementation (actual code text) to the design (the pseudo code).  And this helps you to

• organise your design and your implementation
• understand your design and your implementation
• compare your design to your implementation (an important debugging approach)

-- Bob Elkind