Re:The second operating system hiding in every mobile phone
by gngeal on Wednesday November 13, 2013 @07:50AM
(#6724846)
In practice such a hard realtime guarantee can only be met by a devices like an FPGA.
There have always been fully deterministic CPUs around for that purpose. The simpler the system, the better; just hook a Forth chip to a memory without caches and you're set.
Re:The second operating system hiding in every mobile phone
by doelie_ on Wednesday November 13, 2013 @10:40AM
(#6725858)
Do you have any experience with Forth chips?
I've been looking for an excuse to play with the GreenArray devices.
Re:The second operating system hiding in every mobile phone
by gngeal on Wednesday November 13, 2013 @10:56AM
(#6725985)
No, but I don't see any flaw in that design. Indeed, it seems like the case of Hoare's "obviously no deficiencies" in a system design.
I believe that the GreenArrays people, setting aside the $450 dev board, also had some notes on making cheap breadboards with their chips or something like that. I don't have a link handy, though. ;/
Re:The second operating system hiding in every mobile phone
by ballard on Wednesday November 13, 2013 @03:34PM
(#6728266)
Could try calling their sales folks and see if a rep will just sample it.
Re:The second operating system hiding in every mobile phone
by informatimago on Wednesday November 13, 2013 @06:29AM
(#6724516)
You can code bugs and security failures into a FPGA as well as in software.
Re:The second operating system hiding in every mobile phone
by klez on Wednesday November 13, 2013 @07:50AM
(#6724843)
Yes, but you depend less on bugs caused by levels of abstraction below your code, such as runtimes, OSes etc.
Re:The second operating system hiding in every mobile phone
by bri3d on Wednesday November 13, 2013 @03:46PM
(#6728356)
Between writing and formally verifying HDL, logic synthesis (often using third-party or vendor-provided blocks or soft IP, mind you), behavioral and logic simulation (software!), layout, MDP, and building test harnesses that actually test the final hardware, I would actually trust a lower-level language compiled using a well-known compiler and running on a small RTOS on a proven CPU more than I'd trust a new design synthesized into FPGA or especially ASIC form.
Real issue here is why such codes don't exist for for this particular problem.