FPGA to PHY/MAC chip

[buddylee9898]

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

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

-Andrew



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

 

[Tim Wescott]

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

 

[Arlet Ottens]

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.

 

[d_s_klein]

On Jan 10, 8:19 am, "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 searching
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

 

[d_s_klein]

On Jan 10, 8:38 am, Tim Wescott <t...@seemywebsite.com> wrote:

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

 

[buddylee9898]

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 strea
of sensor data onto the network at about 8Mbps, and to receive commands t
change which sensor the data will be coming from, so the sending of data i
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 tw
computers which will have custom software which should not have to use I
addressing, no? But I would like to get back to the point where d_s_klei
said yes there is a way to receive straight data. I have read the dat
sheet for the ENC28J60, as well as data sheets for a few other chips I wa
considering, and in reading about them it seems fairly straightforward i
that you are simply writing data to the chip (write command plus the packe
data addresses, etc) and reading in a very similar way. Now I have tried t
implement a state machine in order to have this working but without luck s
far. Is this a silly way to try this where there is no way to avoid usin
the picoblaze, or is this feasible to some degree?

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

 

[Arlet Ottens]

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.

 

[rickman]

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

 

[rickman]

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?

Rick

 

[Tim Wescott]

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

 

[glen herrmannsfeldt]

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

 

[John McCaskill]

On Jan 10, 10:19 am, "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 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 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

 

[d_s_klein]

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

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

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.

 

[d_s_klein]

On Jan 10, 12:32 pm, 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.

-- glen

You still need IP for UDP.

 

[John McCaskill]

On Jan 10, 2:46 pm, d_s_klein <d_s_kl...@yahoo.com> wrote:

On Jan 10, 12:32 pm, 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.

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

 

[rickman]

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

 

[Hal Murray]

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.

 

[Giuseppe Marullo]

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

 

[RCIngham]

[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, wher
the client already does DO-254 compliant design, but does not have th
infrastructure for DO-178 (despite DO-254 being derived from DO-178 in th
writing...). So, *lots* of expense to them from adding "software".

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



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

 

[Tim Wescott]

On 01/11/2011 01:52 AM, RCIngham wrote:

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