EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: MVME3100 FPU Support on RTEMS 4.10.2
From: Matt Rippa <[email protected]>
To: Talk EPICS Tech <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Mon, 11 Jun 2018 11:06:17 -1000
Hi all,

Many of you already know this, but it was new information to me. I did
more research on the MVME2502 (e500v2) and thought some may benefit.
I've learned this does not support subnormal (or denormal) numbers. That
may impact your application, either in performance or worse (as I understand),
unexpected zero values. Listing [2] section 10.4.2.2 describes the issue.


Below is more information on the product line from Artesyn.

-Matt

-----

The traditional IEEE754 Double Precision Floating Point unit can be found in the following boards:
  • MVME55006E-0161R/ MVME55006E-0163R which uses the NXP MCP7457
  • MVME61006E-0161R/ MVME61006E-0163R which also uses the NXP MCP7457
  • MVME7100-0171-2GF/ MVME7100-0173-2GF which uses the NXP MCP8641D
  • MVME8110-01S/ MVME8110-01E which uses the NXP P5020.

The MVME2502 has a double precision floating point but it changed with the QorIQ processor cores based on the NXP E500V2 processing cores which are not the IEEE754 format.  The MVME2502 may be fine for your application, but you may want to research the specific NXP pages that cover the processors to see what is appropriate for you.


On Thu, Jun 7, 2018 at 6:15 PM, Matt Rippa <[email protected]> wrote:
Hi Andrew,

Thanks for the info. When I heard RTEMS 5, I was still thinking EPICS 3.14.x.
So thanks for clarifying. I have a better sense of how much work this is. It still
occurs to me that an mvme2500 RTEMS 4.10 option is possible. Sebastian, if
you see a way forward there, we would be interested. 

I mentioned before that the 2500 is our best path. So now I guess that's debatable.
That's based on price point and a suitable cpu for our applications. Browsing the RTEMS BSP list, I see
 the the 5500 as an option. Has anyone used this board on RTEMS with EPICS?
The 5500 is still offered and manufactured by Artesyn and the price is around $4500.

-Matt

On Thu, Jun 7, 2018 at 11:52 AM, Andrew Johnson <[email protected]> wrote:
Hi Matt,

On 06/07/2018 03:20 PM, Matt Rippa wrote:
> The 2500 path looks like our best choice. We can still use the
> 6100/beatnik and 2700 boards in the mean time.

While I agree tentatively about your choosing the 2500, you do need to
be aware that Heinz's EPICS support for RTEMS 5 is aimed at EPICS 7 (it
hasn't been merged yet), and the switch from RTEMS 4.10 to 5.x is not a
minor change from our perspective.

The Kernel APIs that our libCom/osi routines call had to be changed from
the old RTEMS-native interfaces to the Posix ones of RTEMS-5, so there's
quite a difference. We had to make changes to the EPICS build system for
it to be possible to have two implementations of the same OS-dependent
routines for the two different kernel APIs under the same OS_CLASS
(since where possible the RTEMS-5 build should use our standard Posix
implementations). We didn't want to introduce a new RTEMS5 OS_CLASS
since that would break existing EPICS support modules which should
otherwise still work (providing they only call our OSI APIs).

It is also not possible to mix RTEMS versions in the same installation
of EPICS Base, since EPICS RTEMS builds rely on Makefile configurations
and rules from RTEMS' own build system. The RTEMS path and version must
be set in the base/configure/os/CONFIG_SITE.Common.RTEMS file and cannot
be overridden in a target-specific CONFIG file (because by the time
those files get read in we've already read in a lot of RTEMS build
configuration data).

Sorry, just want you to know...

- Andrew

--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon



--




--


Replies:
Re: MVME3100 FPU Support on RTEMS 4.10.2 Sebastian Huber
References:
MVME3100 FPU Support on RTEMS 4.10.2 Matt Rippa
Re: MVME3100 FPU Support on RTEMS 4.10.2 Michael Davidsaver
Re: MVME3100 FPU Support on RTEMS 4.10.2 Heinz Junkes
Re: MVME3100 FPU Support on RTEMS 4.10.2 Gedare Bloom
Re: MVME3100 FPU Support on RTEMS 4.10.2 Joel Sherrill
Re: MVME3100 FPU Support on RTEMS 4.10.2 Matt Rippa
Re: MVME3100 FPU Support on RTEMS 4.10.2 Andrew Johnson
Re: MVME3100 FPU Support on RTEMS 4.10.2 Matt Rippa

Navigate by Date:
Prev: Re: SNMP device support Priller, John
Next: Re: Re: SNMP device support 吴煊
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: MVME3100 FPU Support on RTEMS 4.10.2 Matt Rippa
Next: Re: MVME3100 FPU Support on RTEMS 4.10.2 Sebastian Huber
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 12 Jun 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·