FPGA to PHY/MAC chip

buddylee9898 <andrewludwig1@n_o_s_p_a_m.gmail.com> wrote:

(snip)

> 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? 

UDP isn't so hard to do without a processor.  If you put a static ARP
entry on another host, then you don't need to do ARP inside your box.

As someone else mentioned, you only need to exchange the source
and destination addresses (and ports) to reply to a request.

Last I knew, it was even possible to ignore the checksum for UDP.
It used to be that Sun did that with NFS to speed it up, and,
for a single LAN, to trust the ethernet CRC to catch errors.

The UDP header is so simple that I don't see any reason to use
RAW ethernet.  (Well, if you are only sending between FPGA based
boxes, and never any other host, then maybe.)

-- glen

On Jan 10, 10: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.
>
> 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
> 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
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

From what you describe here and in other places in this thread you
have several options.

1. Use a PicoBlaze and write a bit of assembly code for it to receive
the commands. The PicoBlaze is small, about 100 slices and one block
ram. Your data rates a low enough for it to deal with.  You could just
work at the Ethernet frame level, but UDP/IP is easily within the
range of the PicoBlaze if you do not have to deal with reassembling
fragmented packets. You say else where that you control the network,
so you don't need to deal with ARP if you don't want to. Just set up
static ARP table entries on the computers that need to communicate
with your design.  This is what I would recommend based on what you
have written here.  I have used the PicoBlaze to build a custom
offload engine that diverted a custom protocol wrapped in UDP/IP on
Gigabit Ethernet, and the PicoBlaze worked fine for that.

2.  You could write VHDL state machines to deal with this if you want
to.  Its not hard, especially since you control the network, and can
specify your own format.   You could use UDP/IP, disallow fragmenting
and IP options, and then all the MAC/IP addresses and port numbers
would be at fixed offsets from the start of the frame.  Just start a
counter at the start of the frame, and match expected values at
certain counts (ie protocol and destination address fields) and use
the port number as a register address if you wish.    Use static ARP
table entries again, and you don't have to deal with that issue in the
FPGA.  UDP check sums can just be set to zero if you do not want to
deal with them.

I have used both methods, and if a PicoBlaze will do the job for you,
I would use it.  It is easier and quicker to make changes with it, and
something always changes.

If you need high throughput or low latency, that is when I would
recommend HDL code.  I did a demo to show how low of latency we could
achieve in modifying a packet on the fly. The VHDL code filters out
ICMP Echo request messages (ie a ping), and sends them back to the
source as ICMP Echo reply messages.  It needed 10 clock cycles to
reorder addresses, and a few more for the interface to/from the MAC.
The packet was being sent out while it was still coming in.

 Regards,

John McCaskill
www.FasterTechnology.com
A Xilinx Authorized Training Provider, and Xilinx Alliance Partner

On Jan 10, 10:32=A0am, "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?

OK, fine.  You will still need a protocol.  You could use something
line NetBUI, to avoid IP, but that seems like a lot of work to move
backwards.

>  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
>

I said it was possible.  I did not say that it would be easy, or that
I would do it that way.

FWIW, I have done a full TCP/IP stack in RTL.  At the data rates
you're talking about, that makes no sense to do.

There are complete TCP/IP solutions in a chip - I think you want that
rather than a SPI-PHY.  (Something like the WIZnet WIZ810MJ)

RK.

On Jan 10, 12:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
>
> UDP isn't so hard to do without a processor. =A0If you put a static ARP
> entry on another host, then you don't need to do ARP inside your box.
>
> -- glen

You still need IP for UDP.

On Jan 10, 2:46=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
> On Jan 10, 12:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> wrote:
>
>
>
> > UDP isn't so hard to do without a processor. =A0If you put a static ARP
> > entry on another host, then you don't need to do ARP inside your box.
>
> > -- glen
>
> You still need IP for UDP.

If you control the network and don't allow fragmented packets and
don't use any of the IP options, there is very little that you need to
do for IP.  If you are receiving, just check the appropriate fields to
see if the packet is what you are looking for. Ignore the checksum if
you wish.

If you are sending data, it can still be simple.  When replying, if
you just swap the source and destination address, you do not need to
adjust the checksum. If originating data of constant length, build a
static header in advance if you can. Then you just need to stick it on
front of the data to send.  The IP checksum is only for the header.

Regards,

John McCaskill

On Jan 10, 3:04 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> 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 Serviceshttp://www.wescottdesign.com
>
> Do you need to implement control loops in software?
> "Applied Control Theory for Embedded Systems" was written for you.
> See details athttp://www.wescottdesign.com/actfes/actfes.html

Yup, that was my point.  It would have the same functionality, but if
you can implement it in VHDL rather than adding the complexity of a
separate tool to compile the code, it would be a lot simpler.  My
processor design was a zero operand machine which allowed the
instructions to all be VHDL constants that I could use to define the
contents of the memory array.  Other than instructions, the only other
info in the memory was constants like data and addresses.

The only real issue I had with this processor was the way constants
were built up. The instructions are 9 bits to match the width of FPGA
memory and a constant just has the msb a zero.  The first 8 bit
constant is sign extended in the register and subsequent constant
instructions cause each 8 bits to be shifted into the register from
the right.  The issue is that the size of a constant is not known
until it is evaluated.  If it is used for a jump and the size is not
as expected, it can cause its own value to change.  When multiple
jumps affect one another, it can be very complex to figure out
systematically.  Otherwise, the processor is small, quick and the code
easy to write.

The next time I need a processor, I will return to working on this
design.

Rick

In article <e63ce504-f7cb-480c-87a1-ba8e45b121d4@p7g2000prb.googlegroups.com>,
 d_s_klein <d_s_klein@yahoo.com> writes:
>On Jan 10, 12:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
>wrote:
>>
>> UDP isn't so hard to do without a processor. If you put a static ARP
>> entry on another host, then you don't need to do ARP inside your box.

>You still need IP for UDP.

Not really if you are just responding to packets from the other
system.  You don't need ARP or routing.  You just swap a few fields
and send it back where it came from.

Responding to ARP probes might be helpful.  But then you have
to know your IP address as well as your MAC address.

It would be interesting to see how many lines of code
in some abstract simple machine it takes to respond to
a UDP packet that says roughly: What's the voltage on
pin 3.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.

 >On 1/11/2011 7:06 AM, Hal Murray
 > It would be interesting to see how many lines of code
 > in some abstract simple machine it takes to respond to
 > a UDP packet that says roughly: What's the voltage on
 > pin 3.

Quick & dirty UDP style:

http://www.fpga4fun.com/10BASE-T.html

Oviously a real product needs ARP and at least DHCP but...

[big snip]
>
>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
>

I can think of a sensible reason for the "no-processor" requirement, where
the client already does DO-254 compliant design, but does not have the
infrastructure for DO-178 (despite DO-254 being derived from DO-178 in the
writing...). So, *lots* of expense to them from adding "software".

As to the OP's problem, the solution rather depends on whether they are
going to make <10, ~1000, or >1E6 of them.

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

On 01/11/2011 01:52 AM, RCIngham wrote:
> [big snip]
>>
>> 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
>>
>
> I can think of a sensible reason for the "no-processor" requirement, where
> the client already does DO-254 compliant design, but does not have the
> infrastructure for DO-178 (despite DO-254 being derived from DO-178 in the
> writing...). So, *lots* of expense to them from adding "software".
>
> As to the OP's problem, the solution rather depends on whether they are
> going to make<10, ~1000, or>1E6 of them.

That makes sense.  By and large the "no processor" thing ends up being a 
semantic argument, but when you start applying large amounts of 
semantics (like DO-178) to a project, it makes sense.

Maybe Rickman's "VHDL only" processor starts to make sense, if you can 
just call it a "state machine".

-- 

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