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

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

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

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

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

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.

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.