FPGA to PHY/MAC chip

Tim Wescott <tim@seemywebsite.com> wrote:
(snip)

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".
Click to expand...
Well, the other time that "no processor" is important, is when
you approach the speed of ethernet (more likely fast or gigabit
ethernet) and can't stand the overhead.

In that case, it would be usual to have a processor handle the
slow stuff, like ARP and DHCP, and then arrange a simple state
machine to handle the high-speed data transfers.

That is, for example, how fast managed ethernet switches work.
The hardware handles the simple cases without the processor,
but the rare, more complicated, cases are done by a processor.

-- glen
 
Our industry has a rich history of telling lies to the customer. Dec's PD
series was called a Parallel Data Processor so that it could be purchase
by department heads on their budgets. If they called it a computer then i
would need CEO approval.

The whole idea of a black box equivalent is that you are free to optimis
the inside as long as it meets the spec on the pins. Your customer shoul
only spec their requirements and your job is to figure out the best way t
meet them

John Eaton


---------------------------------------
Posted through http://www.FPGARelated.com
 
On Jan 11, 9:33 pm, "jt_eaton"
<z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
Our industry has a rich history of telling lies to the customer. Dec's PDP
series was called a Parallel Data Processor so that it could be purchased
by department heads on their budgets. If they called it a computer then it
would need CEO approval.

The whole idea of a black box equivalent is that you are free to optimise
the inside as long as it meets the spec on the pins. Your customer should
only spec their requirements and your job is to figure out the best way to
meet them

John Eaton
Click to expand...
They did, one of the requirements is that there should be no software
running on a processor.

Rick
 
rickman <gnuarm@gmail.com> wrote:
(snip)

They did, one of the requirements is that there should be no software
running on a processor.
Click to expand...
It is questionable, but some might say that a state machine and
its state table is software running on a processor.

If the state table is generated from a high-level representation
of the states, then it is somewhat more obvious.

-- glen
 
In article <rJednZ9NA4SkN7HQnZ2dnUVZ_rCdnZ2d@web-ster.com>,
Tim Wescott <tim@seemywebsite.com> writes:

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".
Click to expand...
When a state machine has a lot of states, it's often much easier
to understand if you think of it as software. It depends somewhat
on the branching structure. States that jump to many other
states are harder to implement. It depends...

You can build a special purpose "processor" with not much
more than a ROM. You only need an ALU if you want to do
arithmetic. If all you want to do is wiggle wires (like
a typical state machine) they come out of the ROM.

For something like swapping fields in a packet so you can
send it back, all you need is a register you can load/store
and some way to specify the address for the packet buffer.

One disadvantage of using software to make a state machine
is that you need to write the assembler. That's a lot simpler
if you can start with one for another project.

We used to implement branches by ORing the condition being
tested into a low order address bit. That means the assembler
has to be smart enough to allocate pairs of addresses.

--
These are my opinions, not necessarily my employer's. I hate spam.
 
hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:

One disadvantage of using software to make a state machine
is that you need to write the assembler. That's a lot simpler
Click to expand...
I once wrote an microcode assembler generator. It read the mnemonics,
opcodes, arguments, bit fields from the verilog source and then
generated and ran the assembler on the fly. There were only two
hard-coded directives: org and label.

That way you only had to maintain the verilog source and the assembler
source code, but not the assembler itself.


//Petter
--
..sig removed by request.
 
On Jan 12, 2:56 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
rickman <gnu...@gmail.com> wrote:

(snip)

They did, one of the requirements is that there should be no software
running on a processor.

It is questionable, but some might say that a state machine and
its state table is software running on a processor.

If the state table is generated from a high-level representation
of the states, then it is somewhat more obvious.

-- glen
Click to expand...

That distinction is up to the customer to define, no?

One thing I never do is buck the customer... or I should say, one
thing I never do ANYMORE. I've done it before and it never works out
to my best interest.... no matter how wrong the customer might be.

Rick
 
On Jan 12, 6:33 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
In article <rJednZ9NA4SkN7HQnZ2dnUVZ_rCdn...@web-ster.com>,
 Tim Wescott <t...@seemywebsite.com> writes:

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

When a state machine has a lot of states, it's often much easier
to understand if you think of it as software.  It depends somewhat
on the branching structure.  States that jump to many other
states are harder to implement.  It depends...
Click to expand...
Branching is one of the simplest things to do. That is just a
conditional, this is the next state or that is the next state.

You can build a special purpose "processor" with not much
more than a ROM.  You only need an ALU if you want to do
arithmetic.  If all you want to do is wiggle wires (like
a typical state machine) they come out of the ROM.
Click to expand...
"Processor" may be a grand word for what I am thinking. Typically all
that is needed is a sequencer, which is just a way of addressing the
ROM including the conditional flow of a state machine. Everything
else, data flow, control circuitry, etc., is application specific and
may or may not use a general purpose ALU like structure.


For something like swapping fields in a packet so you can
send it back, all you need is a register you can load/store
and some way to specify the address for the packet buffer.

One disadvantage of using software to make a state machine
is that you need to write the assembler.  That's a lot simpler
if you can start with one for another project.
Click to expand...
My idea is to avoid all that. Your opcodes are just constants in VHDL
that are used to define the contents of the ROM. No assembler
needed.


We used to implement branches by ORing the condition being
tested into a low order address bit.  That means the assembler
has to be smart enough to allocate pairs of addresses.
Click to expand...
Simpler hardware, less simple software.

Rick
 
rickman <gnuarm@gmail.com> wrote:

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
Click to expand...
That depends on the type of FPGA. If you have large blockrams you can
write a decent piece of code. Altough the instruction set is small, it
is quite effective. If you create some hardware accellerators for
common tasks like calculating the CRC, multiplying, etc it can be
extremely powerful!

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Jan 12, 7:08 pm, n...@puntnl.niks (Nico Coesel) wrote:
rickman <gnu...@gmail.com> wrote:
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

That depends on the type of FPGA. If you have large blockrams you can
write a decent piece of code. Altough the instruction set is small, it
is quite effective. If you create some hardware accellerators for
common tasks like calculating the CRC, multiplying, etc it can be
extremely powerful!
Click to expand...
Unless it has been updated since I looked at it, the constraint on
memory size was not the FPGA, but the architecture itself. The PC is
only 12 bits or so. Admittedly, 4K is a decent hunk of assembly code
to write by hand, but the question is how much code does it take to
implement IP, etc.

Rick
 
On Jan 13, 7:12 am, rickman <gnu...@gmail.com> wrote:
On Jan 12, 7:08 pm, n...@puntnl.niks (Nico Coesel) wrote:



rickman <gnu...@gmail.com> wrote:
Click to expand...
<snip>

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

That depends on the type of FPGA. If you have large blockrams you can
write a decent piece of code. Altough the instruction set is small, it
is quite effective. If you create some hardware accellerators for
common tasks like calculating the CRC, multiplying, etc it can be
extremely powerful!

Unless it has been updated since I looked at it, the constraint on
memory size was not the FPGA, but the architecture itself.  The PC is
only 12 bits or so.  Admittedly, 4K is a decent hunk of assembly code
to write by hand, but the question is how much code does it take to
implement IP, etc.

Rick
Click to expand...
The amount of memory available for the PicoBlaze depends on which
version you are using. There are multiple versions targeted at the
different Spartan and Virtex generations.

I took at some of my code for a PicoBlaze that is part of an offload
engine for receiving a custom protocol wrapped in UDP/IP. It was
about 1000 lines, about 350 of that was constants and comments. There
was minor hardware support to put the headers where the PicoBlaze
could read them, in addition to sending the entire packet to a FIFO.
A fair amount of the code was for setting up DMA engines, and other
stuff.

As long as you don't support reassembling fragmented IP packets, or
the IP options field, the entire Ethernet/IP/UDP stack is very simple
to deal with, and well within reach of a PicoBlaze or a state machine.

Regards,

John McCaskill
www.FasterTechnology.com
 
rickman <gnuarm@gmail.com> wrote:

On Jan 12, 7:08=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
rickman <gnu...@gmail.com> wrote:
On Jan 10, 1:32=3DA0pm, "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? =3DA0If you just need to do some setup, then read from one =
memor=3D
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 st=
rea=3D
m
of sensor data onto the network at about 8Mbps, and to receive command=
s t=3D
o
change which sensor the data will be coming from, so the sending of da=
ta =3D
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 =3DA0a=
nd tw=3D
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_kl=
ein
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=3D
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 p=
ack=3D
et
data addresses, etc) and reading in a very similar way. Now I have tri=
ed =3D
to
implement a state machine in order to have this working but without lu=
ck =3D
so
far. Is this a silly way to try this where there is no way to avoid us=
ing
the picoblaze, or is this feasible to some degree? =3DA0 =3DA0 =3DA0 =
=3DA0

--------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0
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. =A0If you end up going that route, will it be

That depends on the type of FPGA. If you have large blockrams you can
write a decent piece of code. Altough the instruction set is small, it
is quite effective. If you create some hardware accellerators for
common tasks like calculating the CRC, multiplying, etc it can be
extremely powerful!

Unless it has been updated since I looked at it, the constraint on
memory size was not the FPGA, but the architecture itself. The PC is
only 12 bits or so. Admittedly, 4K is a decent hunk of assembly code
to write by hand, but the question is how much code does it take to
implement IP, etc.
Click to expand...
If you stay away from tcp/ip it is very feasible to implement the UDP
and ARP parts of the IP protocol.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Jan 13, 9:58 am, John McCaskill <jhmccask...@gmail.com> wrote:
On Jan 13, 7:12 am, rickman <gnu...@gmail.com> wrote:

On Jan 12, 7:08 pm, n...@puntnl.niks (Nico Coesel) wrote:

rickman <gnu...@gmail.com> wrote:

snip





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

That depends on the type of FPGA. If you have large blockrams you can
write a decent piece of code. Altough the instruction set is small, it
is quite effective. If you create some hardware accellerators for
common tasks like calculating the CRC, multiplying, etc it can be
extremely powerful!

Unless it has been updated since I looked at it, the constraint on
memory size was not the FPGA, but the architecture itself.  The PC is
only 12 bits or so.  Admittedly, 4K is a decent hunk of assembly code
to write by hand, but the question is how much code does it take to
implement IP, etc.

Rick

The amount of memory available for the PicoBlaze depends on which
version you are using. There are multiple versions targeted at the
different Spartan and Virtex generations.
Click to expand...
So what is the most memory available for the Picoblaze. When I looked
at using the Picoblaze, one of the things I didn't like was that it
was all instantiated logic. There were no parameters to tweek and any
changes to the architecture would require a new assembler. That's why
I rolled my own. It was a little bigger, but I thought it was much
better and ran fairly fast, over 50 MHz. I don't recall how fast the
Picoblaze is. I seem to recall that the instruction set is rather
stunted and the processor has relatively few registers. But then I
haven't looked at it in years. It would be nice if they had a short
document that explained the basic architectural features without a lot
of noise.

Rick
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top