<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi all,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Many of you already know this, but it was new information to me. I did</div><div class="gmail_default" style="font-size:small">more research on the MVME2502 (e500v2) and thought some may benefit.</div><div class="gmail_default" style="font-size:small">I've learned this does not support subnormal (or denormal) numbers. That</div><div class="gmail_default" style="font-size:small">may impact your application, either in performance or worse (as I understand),</div><div class="gmail_default" style="font-size:small">unexpected zero values. Listing [2] section 10.4.2.2 describes the issue.</div><div class="gmail_default"><br></div><div class="gmail_default">[1] <a href="https://en.wikipedia.org/wiki/Denormal_number">https://en.wikipedia.org/wiki/Denormal_number</a><br></div><div class="gmail_default">[2] <a href="https://www.nxp.com/docs/en/reference-manual/E500CORERM.pdf">https://www.nxp.com/docs/en/reference-manual/E500CORERM.pdf</a><br></div><div class="gmail_default">[3] <a href="https://www.nxp.com/docs/en/reference-manual/e500CORERMAD.pdf">https://www.nxp.com/docs/en/reference-manual/e500CORERMAD.pdf</a><br></div><div class="gmail_default"><br></div><div class="gmail_default" style="font-size:small">Below is more information on the product line from Artesyn.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">-Matt</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default"><div class="gmail_default">-----</div><div class="gmail_default"><br></div><div class="gmail_default">The traditional IEEE754 Double Precision Floating Point unit can be found in the following boards:</div><div class="gmail_default"><ul><li>MVME55006E-0161R/ MVME55006E-0163R which uses the NXP MCP7457</li><li>MVME61006E-0161R/ MVME61006E-0163R which also uses the NXP MCP7457</li><li>MVME7100-0171-2GF/ MVME7100-0173-2GF which uses the NXP MCP8641D</li><li>MVME8110-01S/ MVME8110-01E which uses the NXP P5020.</li></ul></div><div class="gmail_default"><br></div><div class="gmail_default">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.</div></div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 7, 2018 at 6:15 PM, Matt Rippa <span dir="ltr"><<a href="mailto:mrippa@gemini.edu" target="_blank">mrippa@gemini.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Andrew,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks for the info. When I heard RTEMS 5, I was still thinking EPICS 3.14.x.</div><div class="gmail_default" style="font-size:small">So thanks for clarifying. I have a better sense of how much work this is. It still</div><div class="gmail_default" style="font-size:small">occurs to me that an mvme2500 RTEMS 4.10 option is possible. Sebastian, if</div><div class="gmail_default" style="font-size:small">you see a way forward there, we would be interested. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I mentioned before that the 2500 is our best path. So now I guess that's debatable.</div><div class="gmail_default" style="font-size:small">That's based on price point and a suitable cpu for our applications. Browsing the RTEMS BSP list, I see</div><div class="gmail_default" style="font-size:small" dir="auto"> the the 5500 as an option. Has anyone used this board on RTEMS with EPICS?</div><div class="gmail_default" style="font-size:small" dir="auto">The 5500 is still offered and manufactured by Artesyn and the price is around <span class="m_5823751567605192656money">$4500</span>.</div><span class="HOEnZb"><font color="#888888"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small" dir="auto">-Matt</div></font></span></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jun 7, 2018 at 11:52 AM, Andrew Johnson <span dir="ltr"><<a href="mailto:anj@aps.anl.gov" rel="noreferrer" target="_blank">anj@aps.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Matt,<br>
<span><br>
On 06/07/2018 03:20 PM, Matt Rippa wrote:<br>
> The 2500 path looks like our best choice. We can still use the<br>
> 6100/beatnik and 2700 boards in the mean time.<br>
<br>
</span>While I agree tentatively about your choosing the 2500, you do need to<br>
be aware that Heinz's EPICS support for RTEMS 5 is aimed at EPICS 7 (it<br>
hasn't been merged yet), and the switch from RTEMS 4.10 to 5.x is not a<br>
minor change from our perspective.<br>
<br>
The Kernel APIs that our libCom/osi routines call had to be changed from<br>
the old RTEMS-native interfaces to the Posix ones of RTEMS-5, so there's<br>
quite a difference. We had to make changes to the EPICS build system for<br>
it to be possible to have two implementations of the same OS-dependent<br>
routines for the two different kernel APIs under the same OS_CLASS<br>
(since where possible the RTEMS-5 build should use our standard Posix<br>
implementations). We didn't want to introduce a new RTEMS5 OS_CLASS<br>
since that would break existing EPICS support modules which should<br>
otherwise still work (providing they only call our OSI APIs).<br>
<br>
It is also not possible to mix RTEMS versions in the same installation<br>
of EPICS Base, since EPICS RTEMS builds rely on Makefile configurations<br>
and rules from RTEMS' own build system. The RTEMS path and version must<br>
be set in the base/configure/os/CONFIG_SITE.<wbr>Common.RTEMS file and cannot<br>
be overridden in a target-specific CONFIG file (because by the time<br>
those files get read in we've already read in a lot of RTEMS build<br>
configuration data).<br>
<br>
Sorry, just want you to know...<br>
<span class="m_5823751567605192656m_2312653211227990263HOEnZb"><font color="#888888"><br>
- Andrew<br>
<br>
-- <br>
Arguing for surveillance because you have nothing to hide is no<br>
different than making the claim, "I don't care about freedom of<br>
speech because I have nothing to say." -- Edward Snowdon<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div>-- <br><div class="m_5823751567605192656m_2312653211227990263gmail_signature" data-smartmail="gmail_signature">
<div>
<div style="font-family:Tahoma;font-size:13px"><br>
</div>
</div>
</div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">
<div>
<div style="font-family:Tahoma;font-size:13px"><br>
</div>
</div>
</div>
</div>