FPGA to PHY/MAC chip

Hello everyone, I have recently begun a project in which I would like to
add an Ethernet interface to my spartan-3e FPGA allowing it to receive
commands from one of two computers on a local network. Currently, I am
using the Digilent Basys 2 starter board along with the pmod Ethernet NIC
offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
interface. 

My question relates to the needed coding on the FPGA. I have been searching
around and found that many people use Microblaze to simulate a
microprocessor on the FPGA, however I am largely unfamiliar with this and
was wondering if there was a way to use straight VHDL to simply receive
data from the PHY/MAC chip? From my understanding my device will not need
to use IP since I have no need to send data over the internet so I could
technically treat the PHY/MAC chip as a memory register that I would read
and write to, correct? Thank you in advance. 

-Andrew

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 01/10/2011 08:19 AM, buddylee9898 wrote:
> Hello everyone, I have recently begun a project in which I would like to
> add an Ethernet interface to my spartan-3e FPGA allowing it to receive
> commands from one of two computers on a local network. Currently, I am
> using the Digilent Basys 2 starter board along with the pmod Ethernet NIC
> offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
> interface.
>
> My question relates to the needed coding on the FPGA. I have been searching
> around and found that many people use Microblaze to simulate a
> microprocessor on the FPGA, however I am largely unfamiliar with this and
> was wondering if there was a way to use straight VHDL to simply receive
> data from the PHY/MAC chip? From my understanding my device will not need
> to use IP since I have no need to send data over the internet so I could
> technically treat the PHY/MAC chip as a memory register that I would read
> and write to, correct? Thank you in advance.

How much parsing will you need to do of the information from the 
PHY/MAC?  If you just need to do some setup, then read from one memory 
location over and over (which means that you'd be using low-level 
Ethernet in some exceedingly simple fashion) then -- maybe.

I'm not an  FPGA whiz, but I've done a bit of work in them.  Both times 
the problem said "processor", but the customer said "no processor".  You 
end up with these gawdaful state machines that grow without bound, have 
lots of synthesis gotchas (at least when I do them), and as a 
consequence are maintenance nightmares.  At least when I do them I end 
up with more lines of HDL than I would of assembly code to do it on a 
processor.  Perhaps a better man than I could make these work and be 
maintainable -- but perhaps a better man than I could just convince the 
customer that yes, a processor is really what's needed.

Were it me I would hesitate to make the mistake _again_, and I'd figure 
that the up-front work of figuring out how to shove a processor in there 
is going to be less than the subsequent work of maintaining a 
processor-less nightmare of my own creation.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

On Jan 10, 8:19=A0am, "buddylee9898"
<andrewludwig1@n_o_s_p_a_m.gmail.com> wrote:
> Hello everyone, I have recently begun a project in which I would like to
> add an Ethernet interface to my spartan-3e FPGA allowing it to receive
> commands from one of two computers on a local network. Currently, I am
> using the Digilent Basys 2 starter board along with the pmod Ethernet NIC
> offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
> interface.
>

Oh boy.

> My question relates to the needed coding on the FPGA. I have been searchi=
ng
> around and found that many people use Microblaze to simulate a
> microprocessor on the FPGA, however I am largely unfamiliar with this and

The MicroBlaze does not -simulate- a uProc.  It *is* a uProc.  You
might want to start with a basic tutorial (Google is your friend)

> was wondering if there was a way to use straight VHDL to simply receive
> data from the PHY/MAC chip?

Yes, yes there is.

> From my understanding my device will not need
> to use IP since I have no need to send data over the internet so I could
> technically treat the PHY/MAC chip as a memory register that I would read
> and write to, correct?

Not correct.  Not even close.

You mentioned a "local network" above - you will need to support
whatever protocol that network uses.

The PmodNIC uses a MicroChip ENC28J60 - I suggest going to the
MicroChip web site and learning all you can about that chip.

> Thank you in advance.
>
> -Andrew
>

On Mon, 10 Jan 2011 10:19:23 -0600, buddylee9898 wrote:

> Hello everyone, I have recently begun a project in which I would like to
> add an Ethernet interface to my spartan-3e FPGA allowing it to receive
> commands from one of two computers on a local network. Currently, I am
> using the Digilent Basys 2 starter board along with the pmod Ethernet
> NIC offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
> interface.
> 
> My question relates to the needed coding on the FPGA. I have been
> searching around and found that many people use Microblaze to simulate a
> microprocessor on the FPGA, however I am largely unfamiliar with this
> and was wondering if there was a way to use straight VHDL to simply
> receive data from the PHY/MAC chip? From my understanding my device will
> not need to use IP since I have no need to send data over the internet
> so I could technically treat the PHY/MAC chip as a memory register that
> I would read and write to, correct? Thank you in advance.

A simple alternative could be a Lantronix Xport. 

http://www.lantronix.com/device-networking/embedded-device-servers/
xport.html

It allows a single TCP/IP connection through a serial interface. They're 
not cheap, but easy to use. 

On Jan 10, 8:38=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
>
> I'm not an =A0FPGA whiz, but I've done a bit of work in them. =A0Both tim=
es
> the problem said "processor", but the customer said "no processor". =A0Yo=
u
> end up with these gawdaful state machines that grow without bound, have
> lots of synthesis gotchas (at least when I do them), and as a
> consequence are maintenance nightmares. =A0At least when I do them I end
> up with more lines of HDL than I would of assembly code to do it on a
> processor. =A0Perhaps a better man than I could make these work and be
> maintainable -- but perhaps a better man than I could just convince the
> customer that yes, a processor is really what's needed.
>
> Were it me I would hesitate to make the mistake _again_, and I'd figure
> that the up-front work of figuring out how to shove a processor in there
> is going to be less than the subsequent work of maintaining a
> processor-less nightmare of my own creation.
>
> --
>
> Tim Wescott
> Wescott Design Serviceshttp://www.wescottdesign.com
>

The picoBlaze started out as a state machine as you describe.

From a certain abstraction, a state machine is a processor, so the "no
processor" rule is broken.  And besides, if the customer can't tell
that you used a uBlaze/pico-Blaze/NIOS/etc, why tell them?

I remember digging into a JTAG translation box done with a S3
expecting to be impressed with clever RTL only to find a uBlaze and a
couple-hundred lines of "C".  No way one could tell without inspecting
the source code.

RK

PS - it's spelled godawful.  :)

> How much parsing will you need to do of the information from the 
> PHY/MAC?  If you just need to do some setup, then read from one memory 
> location over and over (which means that you'd be using low-level 
> Ethernet in some exceedingly simple fashion) then -- maybe.

Essentially, the whole idea of the port is to be sending a constant stream
of sensor data onto the network at about 8Mbps, and to receive commands to
change which sensor the data will be coming from, so the sending of data is
fairly constant while the receiving is not.

> You mentioned a "local network" above - you will need to support
> whatever protocol that network uses.

Yes I will be using a local network which will contain a switch  and two
computers which will have custom software which should not have to use IP
addressing, no? But I would like to get back to the point where d_s_klein
said yes there is a way to receive straight data. I have read the data
sheet for the ENC28J60, as well as data sheets for a few other chips I was
considering, and in reading about them it seems fairly straightforward in
that you are simply writing data to the chip (write command plus the packet
data addresses, etc) and reading in a very similar way. Now I have tried to
implement a state machine in order to have this working but without luck so
far. Is this a silly way to try this where there is no way to avoid using
the picoblaze, or is this feasible to some degree?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Mon, 10 Jan 2011 12:32:00 -0600, buddylee9898 wrote:

> Yes I will be using a local network which will contain a switch  and two
> computers which will have custom software which should not have to use
> IP addressing, no? But I would like to get back to the point where
> d_s_klein said yes there is a way to receive straight data. I have read
> the data sheet for the ENC28J60, as well as data sheets for a few other
> chips I was considering, and in reading about them it seems fairly
> straightforward in that you are simply writing data to the chip (write
> command plus the packet data addresses, etc) and reading in a very
> similar way. Now I have tried to implement a state machine in order to
> have this working but without luck so far. Is this a silly way to try
> this where there is no way to avoid using the picoblaze, or is this
> feasible to some degree?

If you can handle raw ethernet frames on your PC, these are fairly easy 
to generate/receive on the FPGA. All you need is a header with src/dst 
MAC, ethertype, and a CRC32 at the end.

This can be done with a state machine. 

With a slightly more complicated state machine you can even handle IP/UDP, 
especially if you can hard wire the MAC addresses/router, or just switch 
src/dst MAC around on the reply.

You can even leave out the ENC28J60 and talk directly to a PHY. 

On Jan 10, 1:32=A0pm, "buddylee9898"
<andrewludwig1@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
> > How much parsing will you need to do of the information from the
> > PHY/MAC? =A0If you just need to do some setup, then read from one memor=
y
> > location over and over (which means that you'd be using low-level
> > Ethernet in some exceedingly simple fashion) then -- maybe.
>
> Essentially, the whole idea of the port is to be sending a constant strea=
m
> of sensor data onto the network at about 8Mbps, and to receive commands t=
o
> change which sensor the data will be coming from, so the sending of data =
is
> fairly constant while the receiving is not.
>
> > You mentioned a "local network" above - you will need to support
> > whatever protocol that network uses.
>
> Yes I will be using a local network which will contain a switch =A0and tw=
o
> computers which will have custom software which should not have to use IP
> addressing, no? But I would like to get back to the point where d_s_klein
> said yes there is a way to receive straight data. I have read the data
> sheet for the ENC28J60, as well as data sheets for a few other chips I wa=
s
> considering, and in reading about them it seems fairly straightforward in
> that you are simply writing data to the chip (write command plus the pack=
et
> data addresses, etc) and reading in a very similar way. Now I have tried =
to
> implement a state machine in order to have this working but without luck =
so
> far. Is this a silly way to try this where there is no way to avoid using
> the picoblaze, or is this feasible to some degree? =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

I can't say much about sending data over Ethernet, but be aware that
the Picoblaze is a VERY minimal processor with a very minimal address
space and program size.  If you end up going that route, will it be
any easier to write your own Picoblaze assembly code than designing
your own HDL code?  Is there any Picoblaze code available for this?  I
am pretty sure you can find code written for the MicroBlaze although
it may be large enough that you will need external memory.

Rick

On Jan 10, 11:38=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> On 01/10/2011 08:19 AM, buddylee9898 wrote:
>
> > Hello everyone, I have recently begun a project in which I would like t=
o
> > add an Ethernet interface to my spartan-3e FPGA allowing it to receive
> > commands from one of two computers on a local network. Currently, I am
> > using the Digilent Basys 2 starter board along with the pmod Ethernet N=
IC
> > offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
> > interface.
>
> > My question relates to the needed coding on the FPGA. I have been searc=
hing
> > around and found that many people use Microblaze to simulate a
> > microprocessor on the FPGA, however I am largely unfamiliar with this a=
nd
> > was wondering if there was a way to use straight VHDL to simply receive
> > data from the PHY/MAC chip? From my understanding my device will not ne=
ed
> > to use IP since I have no need to send data over the internet so I coul=
d
> > technically treat the PHY/MAC chip as a memory register that I would re=
ad
> > and write to, correct? Thank you in advance.
>
> How much parsing will you need to do of the information from the
> PHY/MAC? =A0If you just need to do some setup, then read from one memory
> location over and over (which means that you'd be using low-level
> Ethernet in some exceedingly simple fashion) then -- maybe.
>
> I'm not an =A0FPGA whiz, but I've done a bit of work in them. =A0Both tim=
es
> the problem said "processor", but the customer said "no processor". =A0Yo=
u
> end up with these gawdaful state machines that grow without bound, have
> lots of synthesis gotchas (at least when I do them), and as a
> consequence are maintenance nightmares. =A0At least when I do them I end
> up with more lines of HDL than I would of assembly code to do it on a
> processor. =A0Perhaps a better man than I could make these work and be
> maintainable -- but perhaps a better man than I could just convince the
> customer that yes, a processor is really what's needed.
>
> Were it me I would hesitate to make the mistake _again_, and I'd figure
> that the up-front work of figuring out how to shove a processor in there
> is going to be less than the subsequent work of maintaining a
> processor-less nightmare of my own creation.


Yes, you can always add a "processor" even if you don't call it a
processor.  I guess the real advantage of using a processor is that
you can work in a language that suits the problem a bit better than a
state machine.  There is also the fact that much of the state is
implied in the program counter rather than having to be explicit.

I've rolled my own processor before and I can't say it saved me much
work.  I did it because I figured it was an investment, but it hasn't
been used much since.

If you had a state machine that consisted of a register which
addressed memory containing the next state info would you be able to
construct a language within VHDL that would simplify a complex state
machine design?

Rick

On 01/10/2011 11:00 AM, rickman wrote:
> On Jan 10, 11:38 am, Tim Wescott<t...@seemywebsite.com>  wrote:
>> On 01/10/2011 08:19 AM, buddylee9898 wrote:
>>
>>> Hello everyone, I have recently begun a project in which I would like to
>>> add an Ethernet interface to my spartan-3e FPGA allowing it to receive
>>> commands from one of two computers on a local network. Currently, I am
>>> using the Digilent Basys 2 starter board along with the pmod Ethernet NIC
>>> offered by Digilent. This pmod contains a PHY/MAC chip with an SPI
>>> interface.
>>
>>> My question relates to the needed coding on the FPGA. I have been searching
>>> around and found that many people use Microblaze to simulate a
>>> microprocessor on the FPGA, however I am largely unfamiliar with this and
>>> was wondering if there was a way to use straight VHDL to simply receive
>>> data from the PHY/MAC chip? From my understanding my device will not need
>>> to use IP since I have no need to send data over the internet so I could
>>> technically treat the PHY/MAC chip as a memory register that I would read
>>> and write to, correct? Thank you in advance.
>>
>> How much parsing will you need to do of the information from the
>> PHY/MAC?  If you just need to do some setup, then read from one memory
>> location over and over (which means that you'd be using low-level
>> Ethernet in some exceedingly simple fashion) then -- maybe.
>>
>> I'm not an  FPGA whiz, but I've done a bit of work in them.  Both times
>> the problem said "processor", but the customer said "no processor".  You
>> end up with these gawdaful state machines that grow without bound, have
>> lots of synthesis gotchas (at least when I do them), and as a
>> consequence are maintenance nightmares.  At least when I do them I end
>> up with more lines of HDL than I would of assembly code to do it on a
>> processor.  Perhaps a better man than I could make these work and be
>> maintainable -- but perhaps a better man than I could just convince the
>> customer that yes, a processor is really what's needed.
>>
>> Were it me I would hesitate to make the mistake _again_, and I'd figure
>> that the up-front work of figuring out how to shove a processor in there
>> is going to be less than the subsequent work of maintaining a
>> processor-less nightmare of my own creation.
>
>
> Yes, you can always add a "processor" even if you don't call it a
> processor.  I guess the real advantage of using a processor is that
> you can work in a language that suits the problem a bit better than a
> state machine.  There is also the fact that much of the state is
> implied in the program counter rather than having to be explicit.
>
> I've rolled my own processor before and I can't say it saved me much
> work.  I did it because I figured it was an investment, but it hasn't
> been used much since.
>
> If you had a state machine that consisted of a register which
> addressed memory containing the next state info would you be able to
> construct a language within VHDL that would simplify a complex state
> machine design?

Did you realize that you were basically defining a processor in that 
last paragraph?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html