One SBC or two?

On Jan 19, 5:32=A0pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
> On Jan 19, 2:08=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Jan 19, 1:43=A0pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
>
> > > On Jan 18, 4:53=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > > Opinions are cheap, no? =A0Here's another one. =A0Do the real time =
stuff
> > > > in an FPGA! =A0Software will always be hard to debug, especially fo=
r
> > > > real time stuff. =A0Consider what happens with a processor... using=
 a
> > > > sequential language to programm a sequential processor to emulate a
> > > > lot of separate functions happening in parallel. =A0In an FPGA,
> > > > programmed in an HDL, you get exactly that, parallel programs with
> > > > parallel execution on parallel hardware! =A0Every part can be debug=
ged
> > > > in isolation without impacting the rest.
>
> > > > I am working on a highly time critical design right now... in fact,=
 it
> > > > will be used to define time itself! =A0I would have done the entire
> > > > thing in the FPGA with only the fastest parts being done in PECL. =
=A0But
> > > > my friend who actually has the contract (I am doing the FPGA part f=
or
> > > > the initial phase) wants to use a CPU for the stuff that doesn't ha=
ve
> > > > to be in the FPGA. =A0In this case the GUI is a clock display with
> > > > buttons to set the digits, just like a clock at home. =A0There is
> > > > nothing that couldn't be done in the FPGA, but often people have th=
e
> > > > idea that an FPGA is hard to design because it is hardware. =A0In f=
act,
> > > > it is easier to design and debug because it is all in parallel and =
it
> > > > can be simulated with infinite visibility.
>
> > > > I expect that you can find an FPGA based motor control board which
> > > > will attach to whatever processor you wish to use for your GUI. =A0=
This
> > > > eliminates the risk of not having enough processor capability to me=
et
> > > > your real time requirements.
>
> > > > Rick- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > In fact I am completely open to using an FPGA where it would be
> > > appropriate. =A0In fact I would go further and say that it's very lik=
ely
> > > there will be an FPGA in the new realtime design - just a question of
> > > in what capacity. =A0Now the real question is, VHDL or Verilog? :)
>
> > As we speak, er, write, I am helping a friend with a similar issue.
> > He is a good embedded engineer and has done small PLD designs before,
> > but nothing as grand as an FPGA, if you can call FPGA design "grand".
> > He asked me to get him up and running on a project he has on a short
> > fuse. =A0I am writing the code for the first phase for him and will tur=
n
> > it over to him for the subsequent phases with a little hand holding.
> > I asked a few questions and decided it would be best if his project
> > were done in Verilog. =A0My expertise in Verilog is not as good as VHDL=
,
> > but I sincerely =A0believe that VHDL would take him much more time to
> > come up to speed on. =A0My only reservation with Verilog is that there
> > are a number of ways that you can shoot yourself in the foot without
> > even knowing it until most of your blood has drained out. =A0That can b=
e
> > a problem with a relative newbie.
>
> > As for someone who has the time to learn properly and isn't afraid of
> > some strong typing (just how much of a man are you anyway?) I still
> > prefer VHDL at this point. =A0But ask me again when I am done with this
> > project.
>
> > I am pretty certain that your work will move ahead more quickly and
> > give you a lower cost, lower power and smaller size solution using a
> > combined FPGA - CPU approach than a pure CPU approach will. =A0There ar=
e
> > a number of very low power and tiny x86 CPU boards out there. =A0If you
> > move the real time work off the CPU, the UI becomes very easy. =A0With
> > tons of parallel processing, the real time work is very easy in an
> > FPGA.
>
> > BTW, if you find you want any help with the FPGA, that is my
> > specialty. =A0If you can't find a board that does what you want, I am
> > sure I can whip something up for you pretty easily.
>
> > Rick- Hide quoted text -
>
> > - Show quoted text -
>
> Thanks again for the comments. =A0I was just having a bit of fun with
> the VHDL v. Verilog comment - I've seen some of your posts on the
> various fpga newsgroups so I knew it was a bit of a hot topic for
> you. =A0I'm already working to build up some competency in VHDL. =A0By wa=
y
> of background I think that Ada is far superior to C and C++, so
> perhaps you can understand my choice in HDL. =A0But I'm derailing my own
> thread, so I'll be quiet now.

I did think it was more of a jest than serious though.  I didn't pick
up on the personal ribbing.  LOL

If you want any pointers on VHDL or just have any questions, feel free
to contact me.  Once you get the hang of the strong typing issues and
learn when to use which type of adjustment, VHDL is not at all bad.
But you have to love typing!  It is very verbose.

Good luck with your project.

Rick

>  In an FPGA,
> programmed in an HDL, you get exactly that, parallel programs with
> parallel execution on parallel hardware!  Every part can be debugged
> in isolation without impacting the rest.


Rick, you missed out that you can also _guarantee_ responses to IO
(as long as the desing is properly constrained), it doesn't matter how
many interrupts come flooding in in the background!

And you can have whatever number of whatever type of interface you want
(within reason).

FPGAs, the best thing since sliced bread!

:-)

Nial. 

On Jan 20, 5:15=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > =A0In an FPGA,
> > programmed in an HDL, you get exactly that, parallel programs with
> > parallel execution on parallel hardware! =A0Every part can be debugged
> > in isolation without impacting the rest.
>
> Rick, you missed out that you can also _guarantee_ responses to IO
> (as long as the desing is properly constrained), it doesn't matter how
> many interrupts come flooding in in the background!
>
> And you can have whatever number of whatever type of interface you want
> (within reason).
>
> FPGAs, the best thing since sliced bread!
>
> :-)
>
> Nial.

It seems to me that an FPGA (that is, some small unused section of one
already designed in for other purposes) is an excellent method for
doing HW safety interlocks on energy-controlling outputs as well,
which is something our design has to be concerned with.

> It seems to me that an FPGA (that is, some small unused section of one
> already designed in for other purposes) is an excellent method for
> doing HW safety interlocks on energy-controlling outputs as well,
> which is something our design has to be concerned with.


Indeed, I did some work for a local company on safety interlocks for laser
eye scanning.

They had two separate FPGAs monitoring levels, timings etc and both had to
agree to allow the laser output to be on.

Both devices implemented the same logic, an extra level of security would have
been to have two developers design the safety logic.  This wasn't thought
necessary though, one of the advantages of the FPGA is that you can _prove_ the
operation of a logic module via simulation and nothing else that's going on
in the device will interfere with that.


Nial.