On Feb 28, 8:02=A0am, LM <sala.n...@mail.com> wrote:
>
> >The FT2232H and Ethernet are available as small modules, (one is even
> >free on the MaxhXO2 boards..) so start with those, and pull them into
> >the logic only if you really need to.
>
> This seems wise
> So speed of virtual serial port like FTchip is not limited to same way
> as physical RS232 port?

As in set by a legacy 1.8432MHz/16 Motherboard clock, no.

The FT2232H uses 120MHz and divides by 10, and a N/8 fraction
It can do 12MBd/6MBd and fractions below 6MBd, and 12MBd sustained
with largish packets ( >~ 600 bytes from memory), over the high speed
USB link. (and faster  in other modes, but serial is simple)

>
> MachXO2 has SPI and i2c ports.built in.
>
> You really need to state some numbers, 'a bit slow' is not good
> enough.
>
> =A0Specify how fast it needs to be and how much data needs to be sent
> each way, and over what distance.

About speed and data.

Lets say about 640 bytes 10-50 times per second from PC to devices.
More than this would always be better. Opposite direction is not
critical. And distance, 3 feet minimum, more is better. I can test it
with less, but it is not of much when ready.

>The FT2232H and Ethernet are available as small modules, (one is even
>free on the MaxhXO2 boards..) so start with those, and pull them into
>the logic only if you really need to.
This seems wise
So speed of virtual serial port like FTchip is not limited to same way
as physical RS232 port?

On Feb 23, 5:46=A0am, LM <sala.n...@mail.com> wrote:
> I am looking for a chip with somekind of communication port inbuilt. I
> am slowly planning a system where some data is sent from a computer to
> be processed in the chip.
>
> Processing data is probably easy, but I prefer not to make a serial
> port my self and an ethernet port is too much. But an Ethernet port
> would be very nice to have.
>
> I would like to have a reasonably priced chip with low cost evaluation
> board. And I need as many outputs I can get. Some time ago I was told
> here about LCMXO2-1200ZE-B-EVN and others. It is a good kit/chip but
> it doesn't have serial port logic built in.

MachXO2 has SPI and i2c ports.built in.

You really need to state some numbers, 'a bit slow' is not good
enough.

 Specify how fast it needs to be and how much data needs to be sent
each way, and over what distance.

 High speed serial is no slouch, you can get 12MBd Async easily, and
more with
sync protocols out of something like a FT2232H

 The FT2232H and Ethernet are available as small modules, (one is even
free on the MaxhXO2 boards..) so start with those, and pull them into
the logic only if you really need to.
-jg

On 25 helmi, 10:31, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Tim Wescott <t...@seemywebsite.com> wrote:
>
> (snip)
>
> > My understanding with Ethernet is that you can choose an unused port an=
d
> > just send out raw Ethernet packets fairly easily -- but that's based on=
 a
> > throw-away comment made by someone I trust, in an otherwise unrelated
> > conversation. =A0So it's in my bucket of "worthwhile to check" notions,=
 but
> > it certainly doesn't belong in my bucket of "count on it" ideas.
>
> Ethernet without IP doesn't have ports. There is ethertype, which
> identifies the protocol in use. (IP is X'0800') You could use an
> unused ethertype, or maybe one reserved for testing.
>
> You could also put a UDP header on it with an unused UDP port.
> It is convenient toalso do ARP, but you could put a static ARP
> entry on some other host such that packets would be send to the
> right place, and a fixed ethernet MAC address in the FPGA for the
> destination. (For one-way communication, only one of those is needed.)
>
> > Using an Ethernet soft core along with a processor soft core to handle =
a
> > stack might work -- and might even come supported by an FPGA vendor. =
=A0But
> > by the time you get that much processing power into an FPGA I always
> > start wondering if it isn't more wise to just put that much processing
> > power _next to_ the FPGA, let the FPGA do the logic, and let the
> > processor do the processing.
>
> For fast transfer, you want the FPGA logic connected to the ethernet
> device as direct as possible. Then a processor to handle the less
> time sensitive tasks like ARP and routing.
>
> -- glen

I think it is either a microcontroller with Ethernet, like Arduino, or
a Ethernet chip.

What is a good, simple to use or easy to get running Ethernet chip.
But I have to check Ethernet modules too. What I remember of them,
they are like a virtual serial port. That could also work.

It was some years ago I studied VHDL. So It is quite possible that I
miss heard or something, about those macro blocks. I checked also Open
Cores some time ago. They are like a big software projects, it is
difficult to know even where to start. Well that is what they are,
they are big sw projects. It is faster and easier to do this with an
other way.

Tim Wescott <tim@seemywebsite.com> wrote:

(snip)
> My understanding with Ethernet is that you can choose an unused port and 
> just send out raw Ethernet packets fairly easily -- but that's based on a 
> throw-away comment made by someone I trust, in an otherwise unrelated 
> conversation.  So it's in my bucket of "worthwhile to check" notions, but 
> it certainly doesn't belong in my bucket of "count on it" ideas.

Ethernet without IP doesn't have ports. There is ethertype, which
identifies the protocol in use. (IP is X'0800') You could use an
unused ethertype, or maybe one reserved for testing. 

You could also put a UDP header on it with an unused UDP port. 
It is convenient toalso do ARP, but you could put a static ARP
entry on some other host such that packets would be send to the
right place, and a fixed ethernet MAC address in the FPGA for the
destination. (For one-way communication, only one of those is needed.)

> Using an Ethernet soft core along with a processor soft core to handle a 
> stack might work -- and might even come supported by an FPGA vendor.  But 
> by the time you get that much processing power into an FPGA I always 
> start wondering if it isn't more wise to just put that much processing 
> power _next to_ the FPGA, let the FPGA do the logic, and let the 
> processor do the processing.

For fast transfer, you want the FPGA logic connected to the ethernet
device as direct as possible. Then a processor to handle the less
time sensitive tasks like ARP and routing.

-- glen

On Fri, 24 Feb 2012 18:40:03 +0000, glen herrmannsfeldt wrote:

> LM <sala.nimi@mail.com> wrote:
> 
> (snip, I wrote)
>>> You might be able to do UDP/IP, though. TCP is enough harder that I
>>> would have to agree. That processor could be fairly simple, and
>>> implemented in an FPGA.
> 
>> Some microprocessors have Ethernet in them. And Ethernet is certainly
>> easier to use with a microprocessor.
> 
> But what do you write to the ethernet? You need at least a TYPE (also
> called ethertype). UDP is a fairly simple header in front of the data.
> You also need ARP to make IP work, but you can fake that if needed, or
> use a simple state machine.

My understanding with Ethernet is that you can choose an unused port and 
just send out raw Ethernet packets fairly easily -- but that's based on a 
throw-away comment made by someone I trust, in an otherwise unrelated 
conversation.  So it's in my bucket of "worthwhile to check" notions, but 
it certainly doesn't belong in my bucket of "count on it" ideas.

Using an Ethernet soft core along with a processor soft core to handle a 
stack might work -- and might even come supported by an FPGA vendor.  But 
by the time you get that much processing power into an FPGA I always 
start wondering if it isn't more wise to just put that much processing 
power _next to_ the FPGA, let the FPGA do the logic, and let the 
processor do the processing.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

On Fri, 24 Feb 2012 08:54:26 -0800, LM wrote:

> On 24 helmi, 10:58, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Tim Wescott <t...@seemywebsite.com> wrote:
>>
>> (snip)
>>
>> > -- and, unless your Ethernet messaging is really low-level,
>> > boneheaded, and simplified, you're going to need a microprocessor to
>> > manage it anyway (no _way_ do you want to try to make an all-logic
>> > TCP/IP stack!). &nbsp;So you may as well get a micro that has on-board
>> > Ethernet (and serial, to boot).
>>
>> You might be able to do UDP/IP, though. TCP is enough harder that I
>> would have to agree. That processor could be fairly simple, and
>> implemented in an FPGA.
>>
>> > Why didn't I think of that?
>>
>> -- glen
> 
> Some microprocessors have Ethernet in them. And Ethernet is certainly
> easier to use with a microprocessor. But then, I plan drive each pin
> separately in a loop, and that is easier in VHDL. It is faster too. I
> may end up using a FTDI chip or some similar serial to Ethernet chip
> here with the FPGA chip. I can say that my Ethernet messaging is really
> simple, but then, that can be handled with an Ethernet to serial chip
> too.
> 
> When I studied VHDL, I heard that all larger devices have built in or
> optional logic block of common functions like Ethernet or some CPUs. And
> they are optimised so that you dont need to make them your self. One
> reason to my post is curiosity, I'd like to know what these larger
> devices are and what they cost.

Nope.  There's scads of intellectual property ("soft core logic") that 
implements that sort of thing, and there's a few FPGAs that have 
processor cores embedded in them.  But it's certainly not universal, and 
while I don't know for sure what the market shares are, I'd guess that 
90% of the FPGAs that ship do so without dedicated processors, PCI, or 
other such hardware.

So - "built in", no.  But "don't have to build it yourself" -- yes, sort 
of, but you often need to be pretty sharp and knowledgeable to get a 
chunk of IP working correctly with all the rest of your stuff on chip.

(I think there's even an ARM core that's designed to work on FPGAs these 
days).

> I once read that ATA ports are old simplified ISA ports in disguise,
> programming them may anyway be hard when Windows and PCIe try their best
> to stop you.

PATA is a stripped-down ISA port.  I'm really not up on what SATA is.  I 
wouldn't expect that PCI is going to "get in the way", because by 
definition the PCI bus won't be active when you're doing ATA accesses.  

You can count on having to have someone on your team who knows Windows 
drivers if you want to use one -- but that's a software problem.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

LM <sala.nimi@mail.com> wrote:

(snip, I wrote)
>> You might be able to do UDP/IP, though. TCP is enough harder that
>> I would have to agree. That processor could be fairly simple, and
>> implemented in an FPGA.

> Some microprocessors have Ethernet in them. And Ethernet is 
> certainly easier to use with a microprocessor. 

But what do you write to the ethernet? You need at least a TYPE
(also called ethertype). UDP is a fairly simple header in front of
the data. You also need ARP to make IP work, but you can fake that
if needed, or use a simple state machine.


> But then, I plan drive each pin
> separately in a loop, and that is easier in VHDL. It is faster too. I
> may end up using a FTDI chip or some similar serial to Ethernet chip
> here with the FPGA chip. I can say that my Ethernet messaging is
> really simple, but then, that can be handled with an Ethernet to
> serial chip too.

Usually it isn't so bad to have a processor (soft in the FPGA) do
the harder parts like ARP, and otherwise directly write UDP to
the ethernet chip.

-- glen

On 24 helmi, 10:58, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Tim Wescott <t...@seemywebsite.com> wrote:
>
> (snip)
>
> > -- and, unless your Ethernet messaging is really low-level, boneheaded,
> > and simplified, you're going to need a microprocessor to manage it anyw=
ay
> > (no _way_ do you want to try to make an all-logic TCP/IP stack!). =A0So=
 you
> > may as well get a micro that has on-board Ethernet (and serial, to boot=
).
>
> You might be able to do UDP/IP, though. TCP is enough harder that
> I would have to agree. That processor could be fairly simple, and
> implemented in an FPGA.
>
> > Why didn't I think of that?
>
> -- glen

Some microprocessors have Ethernet in them. And Ethernet is certainly
easier to use with a microprocessor. But then, I plan drive each pin
separately in a loop, and that is easier in VHDL. It is faster too. I
may end up using a FTDI chip or some similar serial to Ethernet chip
here with the FPGA chip. I can say that my Ethernet messaging is
really simple, but then, that can be handled with an Ethernet to
serial chip too.

When I studied VHDL, I heard that all larger devices have built in or
optional logic block of common functions like Ethernet or some CPUs.
And they are optimised so that you dont need to make them your self.
One reason to my post is curiosity, I'd like to know what these larger
devices are and what they cost.

I once read that ATA ports are old simplified ISA ports in disguise,
programming them may anyway be hard when Windows and PCIe try their
best to stop you.

This is interesting
Leif

Tim Wescott <tim@seemywebsite.com> wrote:

(snip)

> -- and, unless your Ethernet messaging is really low-level, boneheaded, 
> and simplified, you're going to need a microprocessor to manage it anyway 
> (no _way_ do you want to try to make an all-logic TCP/IP stack!).  So you 
> may as well get a micro that has on-board Ethernet (and serial, to boot).

You might be able to do UDP/IP, though. TCP is enough harder that
I would have to agree. That processor could be fairly simple, and
implemented in an FPGA.

> Why didn't I think of that?

-- glen