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

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.

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

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 st=
uff
> > > in an FPGA! =A0Software will always be hard to debug, especially for
> > > 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 debugge=
d
> > > in isolation without impacting the rest.
>
> > > I am working on a highly time critical design right now... in fact, i=
t
> > > 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. =A0=
But
> > > my friend who actually has the contract (I am doing the FPGA part for
> > > the initial phase) wants to use a CPU for the stuff that doesn't have
> > > 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 the
> > > idea that an FPGA is hard to design because it is hardware. =A0In fac=
t,
> > > 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. =A0Th=
is
> > > eliminates the risk of not having enough processor capability to meet
> > > 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 likel=
y
> > 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 turn
> 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 be
> 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 are
> 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.  I 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.  I'm already working to build up some competency in VHDL.  By way
of background I think that Ada is far superior to C and C++, so
perhaps you can understand my choice in HDL.  But I'm derailing my own
thread, so I'll be quiet now.

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 stuf=
f
> > in an FPGA! =A0Software will always be hard to debug, especially for
> > 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 debugged
> > 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. =A0Bu=
t
> > my friend who actually has the contract (I am doing the FPGA part for
> > the initial phase) wants to use a CPU for the stuff that doesn't have
> > 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 the
> > idea that an FPGA is hard to design because it is hardware. =A0In fact,
> > 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. =A0This
> > eliminates the risk of not having enough processor capability to meet
> > 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 likely
> 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.  I am writing the code for the first phase for him and will turn
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.  My expertise in Verilog is not as good as VHDL,
but I sincerely  believe that VHDL would take him much more time to
come up to speed on.  My 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.  That can be
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.  But 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.  There are
a number of very low power and tiny x86 CPU boards out there.  If you
move the real time work off the CPU, the UI becomes very easy.  With
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.  If you can't find a board that does what you want, I am
sure I can whip something up for you pretty easily.

Rick

On Jan 18, 1:58=A0pm, KK6GM <kk...@att.net> wrote:
> Now for the question. =A0What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.? =A0Both approaches (single
> SBC or dual) have come up for discussion. =A0I'd like to hear as many
> viewpoints on the question as I can get. =A0Thanks.

Like others I would favour separating into multiple processors.  This
mirrors the industrial approach with PLCs and HMIs.

Besides the advantage of being able to update the GUI relatively
easily and separately you can do the same with the control  IE you
could change the motors from HALL sense commutated BLDC to sensorless
switched reluctance with a 'simple' change of drive control.  Or you
could change the size of the motors and retain the same GUI.

It does, however, place high value on defining the network interface
well at the beginning.  Ways to get ID information and status from the
real-time components.  Control definitions that are not limited
(either defined as unitless [motor speed as percent of full speed] so
they scale with the peripheral or with units that don't saturate
easily [motor speed as rpm in some sort of floating point
representation]).  And consider adding signals out of band to the
normal communications such as stop etc...  And make sure the
definition is expandable so it can grow over time.

The other advantage of having the GUI separate is that it is a lot
easier to make it remote, or provide additional status displays.

Whether you can easily separate the various realtime co-ordinates will
depend on how closely they have to be synchronized.  The latency
requirements are stiffer for controlling a pair of motors driving an x/
y table to follow an arc then they are for a motor running a mixer and
a second running a feed screw.

Robert

Chris H wrote:

> In message <4856081d-3b13-4f6b-8014-327957d371d2@h17g2000pre.googlegroup
> s.com>, KK6GM <kk6gm@att.net> writes
>>I'd like to hear what you folks think about the following question.
>>First, some setup.  We're looking at a major upgrade of an existing
>>product.  The existing product is over a decade old and uses a 500MHz
>>x86 SBC to do a lot of realtime (motor control and other things) and
>>to run a primitive UI.  The new product would do roughly the same
>>realtime stuff, but would add a modern GUI, connection to useful
>>peripherals such as printers, and some level of internet
>>connectivity.  This may well put us into Linux or some version of
>>Windows.  Due to the excruciating entanglement of the current UI and
>>realtime, it would certainly require a major rewrite of the realtime
>>in any case.  I could tell you such stories...
>>
>>This is a high-price, low volume product, so cost of the computing HW
>>is insignificant compared to development cost and time.
>>
>>Now for the question.  What do you see as advantages and disadvantages
>>to separating the functionality onto two SBCs, one for realtime and
>>one (not necessarily the same) for GUI, etc.?  Both approaches (single
>>SBC or dual) have come up for discussion.  I'd like to hear as many
>>viewpoints on the question as I can get.  Thanks.
> 
> 
> You could use  two ARM parts. The same RTOS on both and the GUI on one.
> 
> Thus the same dev tools for both SBCs

You say that the product is high value, low volume. In which case the 
software development costs will be lessened if you adopt a sensible 
architecture with multiple processors. You didn't state how many 
actuators/motors are attached to the system but I tend to favour one 
processor per actuator keeping the individual systems very simple. Usually 
smaller less expensive processors can be used. A suitable network to connect 
them along with some interlocking will usually keep the various systems in 
sync and safe.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

KK6GM schrieb:
> I'd like to hear what you folks think about the following question.
> First, some setup.  We're looking at a major upgrade of an existing
> product.  The existing product is over a decade old and uses a 500MHz
> x86 SBC to do a lot of realtime (motor control and other things) and
> to run a primitive UI.  The new product would do roughly the same
> realtime stuff, but would add a modern GUI, connection to useful
> peripherals such as printers, and some level of internet
> connectivity.  This may well put us into Linux or some version of
> Windows.  Due to the excruciating entanglement of the current UI and
> realtime, it would certainly require a major rewrite of the realtime
> in any case.  I could tell you such stories...
>
> This is a high-price, low volume product, so cost of the computing HW
> is insignificant compared to development cost and time.
>
> Now for the question.  What do you see as advantages and disadvantages
> to separating the functionality onto two SBCs, one for realtime and
> one (not necessarily the same) for GUI, etc.?  Both approaches (single
> SBC or dual) have come up for discussion.  I'd like to hear as many
> viewpoints on the question as I can get.  Thanks.

Since modern SBCs are likely to be multi-core processors I would try to 
get away with on SBC and dedicate one core to the GUI part and one core 
to the real-time processing. But maybe there are some folks here around 
that have more experience with these kind of designs than me...

Greetz,
Sebastian

On Jan 19, 10:43=A0am, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
> On Jan 18, 4:53=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
>
>
> > On Jan 18, 1:58 pm, KK6GM <kk...@att.net> wrote:
>
> > > I'd like to hear what you folks think about the following question.
> > > First, some setup. =A0We're looking at a major upgrade of an existing
> > > product. =A0The existing product is over a decade old and uses a 500M=
Hz
> > > x86 SBC to do a lot of realtime (motor control and other things) and
> > > to run a primitive UI. =A0The new product would do roughly the same
> > > realtime stuff, but would add a modern GUI, connection to useful
> > > peripherals such as printers, and some level of internet
> > > connectivity. =A0This may well put us into Linux or some version of
> > > Windows. =A0Due to the excruciating entanglement of the current UI an=
d
> > > realtime, it would certainly require a major rewrite of the realtime
> > > in any case. =A0I could tell you such stories...
>
> > > This is a high-price, low volume product, so cost of the computing HW
> > > is insignificant compared to development cost and time.
>
> > > Now for the question. =A0What do you see as advantages and disadvanta=
ges
> > > to separating the functionality onto two SBCs, one for realtime and
> > > one (not necessarily the same) for GUI, etc.? =A0Both approaches (sin=
gle
> > > SBC or dual) have come up for discussion. =A0I'd like to hear as many
> > > viewpoints on the question as I can get. =A0Thanks.
>
> > Opinions are cheap, no? =A0Here's another one. =A0Do the real time stuf=
f
> > in an FPGA! =A0Software will always be hard to debug, especially for
> > 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 debugged
> > 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. =A0Bu=
t
> > my friend who actually has the contract (I am doing the FPGA part for
> > the initial phase) wants to use a CPU for the stuff that doesn't have
> > 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 the
> > idea that an FPGA is hard to design because it is hardware. =A0In fact,
> > 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. =A0This
> > eliminates the risk of not having enough processor capability to meet
> > 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 likely
> 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? :)- Hide =
quoted text -
>
> - Show quoted text -
Hmmm, my "in fact" key seems to be stuck in the down state...