About fpga board

[rickman]

On 8/5/2015 3:45 PM, glen herrmannsfeldt wrote:

Often the useful hardware implementation of an algorithm is
completely different from the usual software implementations.
It is unusual for tools to figure that out.

That is pretty obvious if you give it a bit of thought. A CPU running
software is a *HUGE* finite state machine (FSM) with the memory
containing the majority of the state along with the fewer registers in
the CPU. The memory contents are all accessed through a very large
multiplexer and operations on this FSM are time multiplexed and
controlled by a program stored in memory.

In an FPGA or ASIC the logic can all be designed in parallel with the
much less happening sequentially. The design could be done in the same
way with the very large multiplexers. The program can be done with
logic rather than a stored program, but the access to the large FSM
still requires a lot of multiplexers. So while it is possible to
duplicate the actual CPU in an FPGA, it is seldom the best way to
utilize an FPGA. The same problem can be implemented with a lot fewer
gates by tailoring the algorithm to take advantage of the parallel
nature of the FPGA and only implementing the specific data paths
required by the problem. The generic CPU gains efficiency by the
repetition of the regular arrays in memory which can be made both small
and cheap but only with a sequential algorithm.

--

Rick

 

[rickman]

On 8/5/2015 5:22 PM, glen herrmannsfeldt wrote:

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
Often the useful hardware implementation of an algorithm is
completely different from the usual software implementations.
It is unusual for tools to figure that out.

That is pretty obvious if you give it a bit of thought. A CPU running
software is a *HUGE* finite state machine (FSM) with the memory
containing the majority of the state along with the fewer registers in
the CPU. The memory contents are all accessed through a very large
multiplexer and operations on this FSM are time multiplexed and
controlled by a program stored in memory.

In one of these newsgroups, a year or two ago, I called
microprocessors the biggest waste of transistors, for this reason.

These days, billions of transistors to funnel data through a
(small number) of thousand transistor ALUs, and back out again.

A very efficient use of the ALU while wasting so many elements in the
memory mux. In reality the comparison is cost vs. the application
needs. Often the things that need to be done can be done sequentially,
even when they appear to be done in parallel. So while an FPGA may more
fully utilize the transistor count, it often wastes the performance
capabilities of those transistors while a CPU more fully exploits them.

With systolic arrays, it is often not hard to chain together a
large number of arithmetic blocks, each operating every clock cycle.

In an FPGA or ASIC the logic can all be designed in parallel with the
much less happening sequentially. The design could be done in the same
way with the very large multiplexers. The program can be done with
logic rather than a stored program, but the access to the large FSM
still requires a lot of multiplexers. So while it is possible to
duplicate the actual CPU in an FPGA, it is seldom the best way to
utilize an FPGA. The same problem can be implemented with a lot fewer
gates by tailoring the algorithm to take advantage of the parallel
nature of the FPGA and only implementing the specific data paths
required by the problem. The generic CPU gains efficiency by the
repetition of the regular arrays in memory which can be made both small
and cheap but only with a sequential algorithm.

There is the assumption that some things can be done in parallel,
but yes.

Perhaps "parallel" is not the best term. In hardware they would be
called concurrent. That doesn't mean the output of one isn't the input
of another. It just means the two operations are working at the same
time on separate hardware whether or not they are actually doing
anything useful all the time.

There are many ways to compare solutions to computing needs. Many like
the familiarity of CPUs (every problem looks like a nail) while others
like the flexibility of FPGAs (Swiss army knife).

--

Rick

 

[rickman]

On 8/5/2015 7:50 PM, glen herrmannsfeldt wrote:

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
In one of these newsgroups, a year or two ago, I called
microprocessors the biggest waste of transistors, for this reason.

These days, billions of transistors to funnel data through a
(small number) of thousand transistor ALUs, and back out again.

A very efficient use of the ALU while wasting so many elements in the
memory mux. In reality the comparison is cost vs. the application
needs. Often the things that need to be done can be done sequentially,
even when they appear to be done in parallel. So while an FPGA may more
fully utilize the transistor count, it often wastes the performance
capabilities of those transistors while a CPU more fully exploits them.

Yes. I was thinking about using either a microprocessor or FPGA
to build a digital clock. In either case, a large fraction of the
time there is nothing to do. (That is, relative to the switch rate.)

Does the clock need to do anything special? Why a custom clock?

There are many ways to compare solutions to computing needs. Many like
the familiarity of CPUs (every problem looks like a nail) while others
like the flexibility of FPGAs (Swiss army knife).

Interesting way to say it.

Sometimes it is hard to find a reasonable analogy. This one is as good
as any I guess. Analogies have lots of compression, only so much
fidelity. How's that for a metaphor?

--

Rick

 

I tried to convert it but i face many difficulties:
with small code i done it without problem, but with more complexity code i found a lot of errors

 

I tried to convert it but i face many difficulties:
with small code i done it without problem, but with more complexity code i found a lot of errors

 

I have this feature "HDL
Coder" but as what i said i found a lot of errors and tired from tying without got any result.

 

[Thomas Stanka]

Am Sonntag, 9. August 2015 19:39:57 UTC+2 schrieb abdrh...@gmail.com:

I have this feature "HDL
Coder" but as what i said i found a lot of errors and tired from tying without got any result.

I know how to read and detected that there is a library containing books, what can I do to transplantate a human heart within 2 months?

The only reasonable answer is to spend your time finding an expert to do this task.
Two month is an extrem small time to bring an unspecified project from Matlab to FPGA. Depending on the constraints, even a group of experts might have trouble with this task. Ofc if you design is "Hello World"-Style, we can help you teaching yourself to do this within 2 months, but as you already wrote you lack fundamental prerequisites and detected your problem is more complex than a simple example.

regards

Thomas

 

I understood what you said , I need long time to learn it, but yes i said that i will learn it in two month, by that i mean i want to do this task within two month, but as what i understand from discussion it is also difficult, also the problem i cant send shot screen to this group, to allow you to know what i am doing and what is the problem i faced, i am here because i need help to do this task, it is clear that who are in this group have good knowledge in fpga board, anyone feel he can help me please make me know that by sending email on

abdrhblushi@gmail.com

With regards

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
> On 8/11/2015 10:42 AM, Thomas Stanka wrote:

(snip)

Two month is an extrem small time to bring an unspecified
project from Matlab to FPGA. Depending on the constraints,
even a group of experts might have trouble with this task.
Ofc if you design is "Hello World"-Style, we can help you
teaching yourself to do this within 2 months, but as you
already wrote you lack fundamental prerequisites and detected
your problem is more complex than a simple example.

I think the difficulty of coding HDL is a bit overstated. I think
anyone with familiarity with coding in general can port a
matlab program to an FPGA in two months.

Some people who are good at writing sequential software have
a hard time thinking in terms of hardware and writing HDL.

There are many things that can be written in Matlab that are
easy to write in HDL, and many that are hard.

Some might not be hard, but are hard if you want them to run fast,
which is often the reason for a hardware implementation.

-- glen

 

[rickman]

On 8/11/2015 10:42 AM, Thomas Stanka wrote:

Am Sonntag, 9. August 2015 19:39:57 UTC+2 schrieb abdrh...@gmail.com:
I have this feature "HDL
Coder" but as what i said i found a lot of errors and tired from tying without got any result.

I know how to read and detected that there is a library containing books, what can I do to transplantate a human heart within 2 months?

The only reasonable answer is to spend your time finding an expert to do this task.
Two month is an extrem small time to bring an unspecified project from Matlab to FPGA. Depending on the constraints, even a group of experts might have trouble with this task. Ofc if you design is "Hello World"-Style, we can help you teaching yourself to do this within 2 months, but as you already wrote you lack fundamental prerequisites and detected your problem is more complex than a simple example.

I think the difficulty of coding HDL is a bit overstated. I think
anyone with familiarity with coding in general can port a matlab program
to an FPGA in two months.

--

Rick

 

[Thomas Stanka]

Am Samstag, 15. August 2015 04:46:05 UTC+2 schrieb rickman:

I think the difficulty of coding HDL is a bit overstated. I think
anyone with familiarity with coding in general can port a matlab program
to an FPGA in two months.

That clearly depends on difficulty of design, which none of us can tell.
Converting something well structured or very small projects will often take less than 2 months. But matlab from people knowing nothing about digital design tend to be in the other complexity class.

I saw FPGA designs for which 2 months were not enough to bring ready verified RTL (written by experienced designer) to functioning bitstream because of hard constraints.

regards,

Thomas