Signal forwarding between FPGAs

Hello

Very easy question, but I just wanna make sure that I have done it the 
correct way so that I dont have to look in this simple stuff for errors :)

Basically I have two FPGAs (Control & Target FPGAs) and I wanna foward 
data between them for receiving and sending single bits. My VHDL code 
for the Control FPGA looks as follows:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;

entity ForwardBits is
             port(
		a_control  : in std_logic;
                 b_control  : out std_logic;
  		a_target   : out std_logic;
                 b_target   : in std_logic
             );
end ForwardBits;

architecture Behavior of ForwardBits is

begin

		a_target <= a_control;
		b_control<= b_target;

end architecture Behavior;

And the other thing I have to do is mapping the signals to PINs of the 
Control FPGA which looks as follows:

NET "b_control" LOC = "M25";
NET "a_control" LOC = "M26";
NET "a_target" LOC = "U2";
NET "b_target" LOC = "V5";

Basically, the only erros could be done with the Pin mapping but that 
should be fine.

Else if I should have missed something I would be thankful for letting 
me know

Cheers

On Jun 25, 10:07=A0pm, Heinrich <Heinr...@myweb.com> wrote:

> Else if I should have missed something I would be thankful for letting
> me know

How about timing / synchronization of the data?

Is a clock being forwarded from one FPGA to the other, to which the
data is sychronized?
If not, how do you expect the receiving FPGA to know when each data
bit is valid?

If you want to treat the interface as asynchronous, you need an
additional strobe from the tx which changes when a bit is valid, and
some logic at the receiver side to sync to the receiver's internal
clock to mitigate metastability issues.

-Tom

Heinrich schrieb:
> Hello
> 
> Very easy question, but I just wanna make sure that I have done it the 
> correct way so that I dont have to look in this simple stuff for errors :)
> 
> Basically I have two FPGAs (Control & Target FPGAs) and I wanna foward 
> data between them for receiving and sending single bits. My VHDL code 
> for the Control FPGA looks as follows:
> 
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.std_logic_arith.all;
> 
> entity ForwardBits is
>             port(
>         a_control  : in std_logic;
>                 b_control  : out std_logic;
>          a_target   : out std_logic;
>                 b_target   : in std_logic
>             );
> end ForwardBits;
> 
> architecture Behavior of ForwardBits is
> 
> begin
> 
>         a_target <= a_control;
>         b_control<= b_target;
> 
> end architecture Behavior;
> 
> And the other thing I have to do is mapping the signals to PINs of the 
> Control FPGA which looks as follows:
> 
> NET "b_control" LOC = "M25";
> NET "a_control" LOC = "M26";
> NET "a_target" LOC = "U2";
> NET "b_target" LOC = "V5";
> 
> Basically, the only erros could be done with the Pin mapping but that 
> should be fine.
> 
> Else if I should have missed something I would be thankful for letting 
> me know
> 
> Cheers
> 
Hi Heinrich.
Everything looks fine, so far. But I'm still wondering what you are 
about to do with that code?

First thing: You have two FPGAs.
So, how many IOs (regarding the above example) are in use on each FPGA?
Two or four?

If it is four, and you are connecting the signals as shown in your 
example architecture inside one of your FPGAs you are creating a 
two-wire loop. This makes barely any sense, unless you just want to 
sense the presence or status of the other FPGA.

Or do you intend to have two signals on each fpga like this:

fpga1                        fpga2
--------                  ------------
        |                  |
   a_out|----------------->| a_in
        |                  |
   b_in |<-----------------| b_out
        |                  |
--------                  ------------


In this case you need two UCF files. One for each FPGA.
And there's no special code needed to access the ports.

example_fpga1:

control_something:process(b_in)
   begin
     ...
   end process;

a_out <= some_control_signal_for_target;

example_fpga1:

target_something:process(a_in)
   begin
     ...
   end process;

b_out <= some_target_signal_for_control;

_________________

So which one is the idea you have in mind?

Have a nice synthesis
   Eilert

Thanks for your answer

 > Or do you intend to have two signals on each fpga like this:
 >
 > fpga1                        fpga2
 > --------                  ------------
 >        |                  |
 >   a_out|----------------->| a_in
 >        |                  |
 >   b_in |<-----------------| b_out
 >        |                  |
 > --------                  ------------

Yes that is exactly what I am trying to do, the control FPGA
is connected to a seriell Port and I wanna forward the rx and tx
signals between the FPGAs so that I can also make use them on the target
FPGA.


 >
 > In this case you need two UCF files. One for each FPGA.
 > And there's no special code needed to access the ports.

Yes, I also have and UCF File for the Target FPGA where I map the
forwarded signals from the control FPGA.
So hopefully its fine what I have implemented :)

Cheers,

> How about timing / synchronization of the data?
> 
> Is a clock being forwarded from one FPGA to the other, to which the
> data is sychronized?
> If not, how do you expect the receiving FPGA to know when each data
> bit is valid?
> 
> If you want to treat the interface as asynchronous, you need an
> additional strobe from the tx which changes when a bit is valid, and
> some logic at the receiver side to sync to the receiver's internal
> clock to mitigate metastability issues.

The logic to handle the tx and rx bits is implemented on the target 
FPGA. So the only thing I have to do is just forward the rx bits on the
Control FPGA to the target FPGA in "real-time" and all the other stuff
is then done by a module on the target FPGA...

On Jun 26, 6:36=A0pm, Heinrich <Heinr...@myweb.com> wrote:
> The logic to handle the tx and rx bits is implemented on the target
> FPGA. So the only thing I have to do is just forward the rx bits on the
> Control FPGA to the target FPGA in "real-time" and all the other stuff
> is then done by a module on the target FPGA...

Well ok, but if you don't tell us what you've done, we can't tell you
if you've done it correctly or not!

If you've got data lines only (no clock or async handshaking), you
need clock transferred by some other method - either explicitly or in
a way that the clock can be extracted/implied from the data stream.

-T

> If you've got data lines only (no clock or async handshaking), you
> need clock transferred by some other method - either explicitly or in
> a way that the clock can be extracted/implied from the data stream.

Yes, I just need the data lines forwarded from the control to the target 
FPGA. The target FPGA has an own clock so I dont need to forward this signal

Thx,
H.

On Jun 27, 10:11=A0pm, Heinrich <Heinr...@myweb.com> wrote:
> > If you've got data lines only (no clock or async handshaking), you
> > need clock transferred by some other method - either explicitly or in
> > a way that the clock can be extracted/implied from the data stream.
>
> Yes, I just need the data lines forwarded from the control to the target
> FPGA. The target FPGA has an own clock so I dont need to forward this sig=
nal
>
> Thx,
> H.

OK, I don't want to keep saying the same thing, but are you sure the
clock on the target FPGA is synchronous (coherent) with the one on the
control FPGA?

Can you guarantee their relative phase? If you are using DCMs then you
probably can't.
If not, like I said, you need to make special efforts to cross the
clock boundary correctly.
I just want to make sure you are aware of this.

Regards

Tom

> 
> OK, I don't want to keep saying the same thing, but are you sure the
> clock on the target FPGA is synchronous (coherent) with the one on the
> control FPGA?
> 
> Can you guarantee their relative phase? If you are using DCMs then you
> probably can't.
> If not, like I said, you need to make special efforts to cross the
> clock boundary correctly.
> I just want to make sure you are aware of this.

Thanks Tom, they have both the same clock Frequency but the phase doesnt 
matter as it is just some serial databits that need to be forwarded 
between them. So in the meantime everything works as it should :)

On Jun 28, 2:08=A0am, Heinrich <Heinr...@myweb.com> wrote:
> they have both the same clock Frequency but the phase doesnt
> matter as it is just some serial databits that need to be forwarded
> between them.

So if the relative phase isn't known, how does the receiving FPGA know
#when# to read each data bit from the transmitting FPGA?
More specifically, what happens if the receiving FPGA decides to read
the value at its input pin just at the very same moment that it is
being changed by the transmitting FPGA?
(note: this is not good).

Worse than this, there are finite setup and hold time requirements on
the receiving inputs that you have to make sure are being met for data
to be read reliably - that involves knowing exactly when data is being
read (i.e. the phase of the clock on which reads are done versus the
incoming data timing).
If you can't do that, then you need to forward some other method of
saying when it is "safe" to read each bit (e.g. an async strobe). The
fact it is "only" serial doesn't matter.

-T