FPGARelated.com
Forums

FPGA to PHY/MAC chip

Started by buddylee9898 January 10, 2011
On Jan 13, 7:12=A0am, rickman <gnu...@gmail.com> wrote:
> On Jan 12, 7:08=A0pm, 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. =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. =A0The PC is > only 12 bits or so. =A0Admittedly, 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. 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.
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=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Jan 13, 7:12=A0am, rickman <gnu...@gmail.com> wrote: > > > On Jan 12, 7:08=A0pm, 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 addres=
s
> > > >space and program size. =A0If you end up going that route, will it b=
e
> > > > 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, i=
t
> > > 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. =A0The PC is > > only 12 bits or so. =A0Admittedly, 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.
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