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

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 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
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Jan 11, 9:33=A0pm, "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 PD=
P
> 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 i=
t
> 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 t=
o
> meet them
>
> John Eaton

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.

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

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

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=A0am, 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


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=A0am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> In article <rJednZ9NA4SkN7HQnZ2dnUVZ_rCdn...@web-ster.com>,
> =A0Tim 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. =A0It depends somewhat
> on the branching structure. =A0States that jump to many other
> states are harder to implement. =A0It depends...

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. =A0You only need an ALU if you want to do
> arithmetic. =A0If all you want to do is wiggle wires (like
> a typical state machine) they come out of the ROM.

"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. =A0That's a lot simpler
> if you can start with one for another project.

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. =A0That means the assembler
> has to be smart enough to allocate pairs of addresses.

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

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

Rick