How do you use serial port or any other bus

[LM]

What I know there is no serial port or ethernet port in VHDL. But some
FPGAs have them and much more. How are they used.

I want to load packets of data from server/host to a FPGA and drive
things. But what is easy with controllers is not easy (or is it) with
FPGAs.

 

[David Bishop]

On 11/26/2011 6:35 PM, LM wrote:

What I know there is no serial port or ethernet port in VHDL. But some
FPGAs have them and much more. How are they used.

VHDL does not define interfaces, just a way to design them.

I want to load packets of data from server/host to a FPGA and drive
things. But what is easy with controllers is not easy (or is it) with
FPGAs.

You will have to check out the IP library that comes with the FPGA
design tools. It may have what you want.

 

[LM]

I want to load packets of data from server/host to a FPGA and drive
things. But what is easy with controllers is not easy (or is it) with
FPGAs.

You will have to check out the IP library that comes with the FPGA
design tools.   It may have what you want.
You are probably right. Its better to ask this in FPGA group. I dont

think all FPGA users design their ethernet controllers or other such
devices, but still they can be used.

 

[Rich Webb]

On Sat, 26 Nov 2011 15:35:18 -0800 (PST), LM <sala.nimi@mail.com> wrote:

What I know there is no serial port or ethernet port in VHDL. But some
FPGAs have them and much more. How are they used.

I want to load packets of data from server/host to a FPGA and drive
things. But what is easy with controllers is not easy (or is it) with
FPGAs.

A standard async serial port is just a shift register inside of a state
machine. The outer state machine reacts to the start-bit detection and
shifts from [idle] to [active]. Detect the bit states with a sample
clock near the expected middle of each bit (or use a higher speed clock
and do a majority vote, for noise mitigation). For completeness, handle
parity checking, framing errors, and break states. At the end of the
[active] bit count and stop-bit detection, return to [idle].

--
Rich Webb Norfolk, VA

 

[KJ]

On Nov 26, 6:35 pm, LM <sala.n...@mail.com> wrote:

What I know there is no serial port or ethernet port in VHDL. But some
FPGAs have them and much more. How are they used.

I want to load packets of data from server/host to a FPGA and drive
things. But what is easy with controllers is not easy (or is it) with
FPGAs.

Whether or not something is 'easy' depends on the particular skills of
the individual that asks the question as well as the capabilities of
the devices that are being considered for implementation.

There is a large gap in complexity between the two interfaces that you
mentioned (serial or ethernet). Most (or all) of either interface can
be implemented in an FPGA, sometimes it makes sense to do so, other
times it does not. Since you haven't stated your requirements, you
need to work that out yourself first. Poke around at the FPGA
supplier web sites for IP blocks that look like they might fit your
needs or may influence what you think you need. Many things will
enter into the decision of whether or not you should use an FPGA or
something else (budgets, design complexity, resource usage, etc.)

Simply stating that you want to 'load packets of data from server/host
to a FPGA and drive
things' isn't much of a functional requirement definition for anyone
to help you out much. Whether or not something is 'easy with
controllers' but maybe 'not easy' with an FPGA simply suggests that
you're more familiar with controllers but that by itself isn't much of
a constraint to try to work within (i.e. maybe you need it to be very
easy from a design perspective because you only have two weeks to
complete the hardware design).

I would suggest clarifying what you think you need from a function and
performance perspective and then work on what your constraints are and
then post that description after which you'll probably get some good
feedback from this group as well as comp.arch.fpga and probably other
groups as well. Right now there isn't much to go on so the feedback
will probably not be very useful other than to stimulate you to do
more research.

Kevin Jennings

 

[valtih1978]

Whether or not something is 'easy with
controllers' but maybe 'not easy' with an FPGA simply suggests that

you're more familiar with controllers

No. It means that controllers have a built-in rs232 controller, which
can be easily commanded to send a byte. This is one simple line of C code.

 

[Alessandro Basili]

On 11/28/2011 11:58 AM, valtih1978 wrote:

Whether or not something is 'easy with
controllers' but maybe 'not easy' with an FPGA simply suggests that
you're more familiar with controllers

No. It means that controllers have a built-in rs232 controller, which
can be easily commanded to send a byte. This is one simple line of C code.

Again "easily commanded" to send a byte is just a matter of familiarity.
I'm not aware of any function specified by the ANSI C standard that will
accommodate the communication with a controller, therefore I presume
that someone has got the time and the will to port the C library to the
specific architecture of the controller you may have referred to, as
well as the compiler, linker, assembler, archiver and possibly a
splitter to produce (EEP)ROM images as well as a debugger.

As I see it there's a lot behind the "simple line of C code" which may
as well be behind any FPGA.

"Nothing is easy for the unwilling" Thomas Fuller.

 

[valtih1978]

Again "easily commanded" to send a byte is just a matter of familiarity.

It is not, again. It is a matter of what you develop further:
controllers do have a predefined processor and UART. They are supplied
with established compiler, linker, assembler, archiver and possibly a
splitter to produce (EEP)ROM images as well as a debugger. Normally, you
will not do uC vendor's job. When you start from FPGA, you must have
synthesize an UART first.