FPGA I/O Issues.

S

Santosh

Guest
Hi,
I have got Spartan 3E starter board, now what I am trying to do is
get some data from external circuit. As suggested in this group I got
the FX2 Breadboard from Digilent Inc. I have made an AVR(AtMega 16)
based system which is capable of measuring temperature and relative
humidity. Now I ain't got any ideas to send the measured
data(temperature and humidity) to the FPGA board. I think voltage
level conversion is must, and except that are there any clock issues I
should take care of? Any suggestions/ideas are really appreciated.

San.
 
On Oct 23, 9:24 am, Santosh <santos...@gmail.com> wrote:
Hi,
    I have got Spartan 3E starter board, now what I am trying to do is
get some data from external circuit. As suggested in this group I got
the FX2 Breadboard from Digilent Inc. I have made an AVR(AtMega 16)
based system which is capable of measuring temperature and relative
humidity. Now I ain't got any ideas to send the measured
data(temperature and humidity) to the FPGA board. I think voltage
level conversion is must, and except that are there any clock issues I
should take care of? Any suggestions/ideas are really appreciated.

San.
Click to expand...
What sort of external interfaces does your AtMega system have? Since
I assume that you don't need the data to update really fast for this
sort
of application, I would choose the interface with the fewest wires
if there are more than one to choose from. I think something like I2C
would be perfect for this application - just two signal wires and a
protocol that's easy to use. SPI or MicroWire are even easier
from a protocol standpoint and have only a couple more wires.
Any of these protocols can be run slow enough that you can
oversample the signals with an internal clock in the FPGA.
Then you don't need to be as concerned about signal integrity
on your "clock" lines, which would be sampled, too. Otherwise
no matter how slow the interface (including 100 MHz I2C)
if you try to use the clock line directly as a clock you can
have headaches.

Regards,
Gabor
 
What sort of external interfaces does your AtMega system have?  Since
I assume that you don't need the data to update really fast for this
sort
of application, I would choose the interface with the fewest wires
if there are more than one to choose from.  I think something like I2C
would be perfect for this application - just two signal wires and a
protocol that's easy to use.  SPI or MicroWire are even easier
from a protocol standpoint and have only a couple more wires.
Any of these protocols can be run slow enough that you can
oversample the signals with an internal clock in the FPGA.
Then you don't need to be as concerned about signal integrity
on your "clock" lines, which would be sampled, too.  Otherwise
no matter how slow the interface (including 100 MHz I2C)
if you try to use the clock line directly as a clock you can
have headaches.

Regards,
Gabor
Click to expand...


Hey,
I may be wrong but doesn't the AtMega output data on its clock
speed, which is run by external X-tal and FPGA runs at 50 Mhz. And due
to non-matching clocks, ain't there any conflicts. And I didn't get
the term oversampling, : P

San.
 
On Oct 24, 7:50 am, Santosh <santos...@gmail.com> wrote:
What sort of external interfaces does your AtMega system have?  Since
I assume that you don't need the data to update really fast for this
sort
of application, I would choose the interface with the fewest wires
if there are more than one to choose from.  I think something like I2C
would be perfect for this application - just two signal wires and a
protocol that's easy to use.  SPI or MicroWire are even easier
from a protocol standpoint and have only a couple more wires.
Any of these protocols can be run slow enough that you can
oversample the signals with an internal clock in the FPGA.
Then you don't need to be as concerned about signal integrity
on your "clock" lines, which would be sampled, too.  Otherwise
no matter how slow the interface (including 100 MHz I2C)
if you try to use the clock line directly as a clock you can
have headaches.

Regards,
Gabor

Hey,
      I may be wrong but doesn't the AtMega output data on its clock
speed, which is run by external X-tal and FPGA runs at 50 Mhz. And due
to non-matching clocks, ain't there any conflicts. And I didn't get
the term oversampling, : P

San.
Click to expand...
Do you know the terms SPI or EIA-232? Or ain't you got to that point
in your class yet?

Rick
 
<>
Do you know the terms SPI or EIA-232?  Or ain't you got to that point
in your class yet?

Rick
Click to expand...
I know SPI, but ain't done it. But I haven't heard of EIA-232 yet, is
it like the RS-232 : P
 
On Oct 24, 1:37 pm, Santosh <santos...@gmail.com> wrote:
Do you know the terms SPI or EIA-232?  Or ain't you got to that point
in your class yet?

Rick

I know SPI, but ain't done it. But I haven't heard of EIA-232 yet, is
it like the RS-232 : P
Click to expand...
So what class is this for?
 
On Oct 24, 11:35 pm, rickman <gnu...@gmail.com> wrote:
On Oct 24, 1:37 pm, Santosh <santos...@gmail.com> wrote:



Do you know the terms SPI or EIA-232?  Or ain't you got to that point
in your class yet?

Rick

I know SPI, but ain't done it. But I haven't heard of EIA-232 yet, is
it like the RS-232 : P

So what class is this for?
Click to expand...
By class you mean academic?
I m just FPGA enthusiast .
 
On Oct 26, 9:22 am, Santosh <santos...@gmail.com> wrote:
On Oct 24, 11:35 pm, rickman <gnu...@gmail.com> wrote:

On Oct 24, 1:37 pm, Santosh <santos...@gmail.com> wrote:



Do you know the terms SPI or EIA-232?  Or ain't you got to that point
in your class yet?

Rick

I know SPI, but ain't done it. But I haven't heard of EIA-232 yet, is
it like the RS-232 : P

So what class is this for?

By class you mean academic?
I m just FPGA enthusiast .
Click to expand...
Good luck...
 
On Oct 24, 2:50 pm, Santosh <santos...@gmail.com> wrote:
What sort of external interfaces does your AtMega system have?  Since
I assume that you don't need the data to update really fast for this
sort
of application, I would choose the interface with the fewest wires
if there are more than one to choose from.  I think something like I2C
would be perfect for this application - just two signal wires and a
protocol that's easy to use.  SPI or MicroWire are even easier
from a protocol standpoint and have only a couple more wires.
Any of these protocols can be run slow enough that you can
oversample the signals with an internal clock in the FPGA.
Then you don't need to be as concerned about signal integrity
on your "clock" lines, which would be sampled, too.  Otherwise
no matter how slow the interface (including 100 MHz I2C)
if you try to use the clock line directly as a clock you can
have headaches.

Regards,
Gabor

Hey,
      I may be wrong but doesn't the AtMega output data on its clock
speed, which is run by external X-tal and FPGA runs at 50 Mhz. And due
to non-matching clocks, ain't there any conflicts. And I didn't get
the term oversampling, : P

San.
Click to expand...
You can generate a clock with atmega. It doesn't need to be fast nor
have %50 duty cycle in your application since the speed you need is
very low.
As rickman said, look for SPI protocol. It is very easy to implement,
both in fpga and atmega. There is a good tutorial in fpga4fun.com
about SPI.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top