Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13464 > unrolled thread
| Started by | Tim Wescott <tim@seemywebsite.really> |
|---|---|
| First post | 2013-09-11 11:11 -0500 |
| Last post | 2013-09-11 22:19 -0400 |
| Articles | 20 on this page of 428 — 35 participants |
Back to article view | Back to comp.arch.embedded
Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-11 11:11 -0500
Re: Small, fast, resource-rich processor Rich Webb <webb.ra@example.net> - 2013-09-11 12:45 -0400
Re: Small, fast, resource-rich processor Frank Miles <fpm@u.washington.edu> - 2013-09-11 16:59 +0000
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 10:08 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-11 12:27 -0500
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 11:23 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 11:32 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-11 11:30 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-11 18:26 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-11 13:37 -0500
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-11 21:51 +0200
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 16:46 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-12 14:00 +0200
Re: Small, fast, resource-rich processor Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-09-14 10:24 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 02:38 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 01:52 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 12:33 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-15 13:02 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 14:33 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 12:09 -0700
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-15 22:12 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:32 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-16 09:17 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-16 10:21 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 13:53 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:31 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 04:46 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-17 10:46 -0700
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-17 22:30 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-17 22:43 -0700
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-18 14:35 +0000
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-18 18:41 +0300
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 09:12 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 07:57 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 22:22 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-20 05:44 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-20 00:05 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-20 14:18 +0000
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-20 16:24 +0300
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 08:31 +0100
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-20 12:43 -0500
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 20:29 +0100
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-20 21:39 +0000
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-20 15:27 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 23:52 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-20 18:52 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-20 19:38 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-24 01:20 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-24 01:22 -0700
Re: Small, fast, resource-rich processor Robert Wessel <robertwessel2@yahoo.com> - 2013-09-24 03:33 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-24 21:17 -0400
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 10:56 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-22 20:08 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 12:21 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 00:12 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 16:50 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 09:12 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-23 06:49 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-23 16:31 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-24 01:13 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-24 02:15 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-24 15:56 -0700
Re: Small, fast, resource-rich processor Robert Wessel <robertwessel2@yahoo.com> - 2013-09-23 00:46 -0500
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-22 23:18 -0700
Re: Small, fast, resource-rich processor Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-23 09:00 +0200
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-23 00:18 -0700
Re: Small, fast, resource-rich processor Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-23 09:27 +0200
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-23 06:56 -0700
Re: Small, fast, resource-rich processor Robert Wessel <robertwessel2@yahoo.com> - 2013-09-23 10:50 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 13:04 -0700
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-20 15:41 +0300
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-20 14:33 +0000
Re: Small, fast, resource-rich processor upsidedown@downunder.com - 2013-09-20 15:55 +0300
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-20 08:42 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-23 09:06 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 12:07 -0700
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-29 22:15 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-01 00:33 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-10-01 10:25 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 10:26 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-03 19:07 +0000
Re: Small, fast, resource-rich processor Scott Hemphill <hemphill@hemphills.net> - 2013-10-03 19:17 -0400
Re: Small, fast, resource-rich processor Scott Hemphill <hemphill@hemphills.net> - 2013-10-03 21:00 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-18 11:29 -0500
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-18 10:20 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 21:53 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 09:48 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 09:38 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 11:24 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 10:53 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 13:12 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 15:31 +0100
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 15:44 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 22:53 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 08:37 +0100
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 17:48 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-01 00:37 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-01 09:14 +0100
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-22 21:31 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 00:19 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-23 09:23 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-23 09:00 +0100
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-23 11:31 +0200
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 13:02 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-28 22:54 +0100
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-28 22:33 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-28 22:29 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-29 10:01 +0100
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-29 23:02 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 10:36 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-30 14:09 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 01:27 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-01 05:46 +0000
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-10-01 09:19 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 03:28 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-10-01 10:13 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 12:39 -0400
Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-01 16:56 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-01 18:59 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 17:25 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 18:37 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 19:29 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 19:31 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) robert bristow-johnson <rbj@audioimagination.com> - 2013-10-01 16:36 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 20:51 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-01 21:08 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-02 09:08 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Mel Wilson <mwilson@the-wire.com> - 2013-10-02 09:36 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-02 17:16 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) upsidedown@downunder.com - 2013-10-03 10:15 +0300
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-03 02:32 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-10-03 15:45 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Paul Rubin <no.email@nospam.invalid> - 2013-10-03 09:06 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 17:18 +0100
Re: Small, fast, resource-rich processor (die evil thread, die!!!) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-10-03 16:51 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Paul Rubin <no.email@nospam.invalid> - 2013-10-03 10:11 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:52 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-03 09:35 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-03 03:26 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-03 13:27 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-03 12:55 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) David Brown <david@westcontrol.removethisbit.com> - 2013-10-04 16:59 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-02 01:02 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-10-03 16:28 +0200
Re: Small, fast, resource-rich processor (die evil thread, die!!!) dp <dp@tgi-sci.com> - 2013-10-03 08:03 -0700
Re: Small, fast, resource-rich processor (die evil thread, die!!!) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-03 19:15 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-03 15:50 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Tim Wescott <tim@seemywebsite.really> - 2013-10-03 15:27 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Randy Yates <yates@digitalsignallabs.com> - 2013-10-03 16:37 -0400
Re: Small, fast, resource-rich processor (die evil thread, die!!!) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-03 21:51 +0000
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Robert Wessel <robertwessel2@yahoo.com> - 2013-10-04 00:02 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) Tim Wescott <tim@seemywebsite.really> - 2013-10-02 00:12 -0500
Re: Small, fast, resource-rich processor (die evil thread, die!!!) robert bristow-johnson <rbj@audioimagination.com> - 2013-10-03 10:24 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-10-02 00:13 -0500
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-02 06:51 +0000
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:55 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:58 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 03:12 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 09:49 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 12:04 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 12:51 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-10-02 15:18 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 19:46 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-10-01 23:09 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:53 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 01:45 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 04:34 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 02:17 -0700
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-19 16:49 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 17:05 +0000
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-19 13:08 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 20:22 +0000
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-19 14:42 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-20 00:34 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 22:15 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-20 08:43 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-19 22:16 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-19 12:28 -0500
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-19 15:08 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 12:52 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-18 10:23 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 08:03 +0000
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-19 12:53 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 21:31 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 04:18 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 02:02 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 16:47 +0000
Re: Small, fast, resource-rich processor j.m.granville@gmail.com - 2013-09-24 19:54 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-25 19:12 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-25 11:50 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 01:26 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 09:11 +0100
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-26 02:12 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 13:46 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-26 09:55 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 18:44 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-26 12:31 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-26 23:09 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 08:45 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 07:44 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:58 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 09:45 +0100
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 16:50 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 07:31 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:30 -0500
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-17 21:11 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 13:11 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-17 11:42 +0200
Re: Small, fast, resource-rich processor Al Clark <aclark@danvillesignal.com> - 2013-09-17 14:06 +0000
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-17 16:44 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:43 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 13:22 -0400
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-18 17:17 +0200
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-18 16:46 +0100
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 09:16 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 14:13 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-18 20:00 +0100
Re: Small, fast, resource-rich processor Les Cargill <lcargill99@comcast.com> - 2013-09-18 19:56 -0500
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-19 09:56 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 14:01 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 12:35 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-18 23:28 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-18 16:39 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 17:26 -0700
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-18 17:56 -0700
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-22 17:53 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-23 01:00 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-23 00:15 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-23 11:31 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-23 21:15 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-23 22:41 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-24 02:57 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-23 18:42 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-23 21:16 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-23 20:31 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-24 12:01 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:14 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 00:53 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 09:58 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-18 16:43 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:21 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-19 00:54 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 08:25 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 09:03 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-26 06:47 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 09:46 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-26 10:06 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-26 13:45 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-26 23:54 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-29 08:31 -0400
Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-29 23:37 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 01:16 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-29 22:31 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 10:06 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:12 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-30 09:24 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 01:33 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-30 22:48 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 03:04 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-01 00:27 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 03:32 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-30 11:37 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 13:40 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:43 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-30 17:07 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:38 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-30 18:57 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-30 12:36 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor jhallen@TheWorld.com (Joseph H Allen) - 2013-09-30 20:15 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-09-30 20:38 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 02:55 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-01 11:50 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 12:53 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-01 17:34 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 17:31 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-02 12:15 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 12:19 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-03 11:55 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 01:04 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:19 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 23:07 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-01 20:06 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-01 22:38 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 03:09 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-02 00:51 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 03:58 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-02 01:27 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 04:24 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-02 01:54 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 19:51 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 00:17 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:27 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 23:09 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:30 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-06 10:53 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-09 05:12 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-09 02:24 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2013-10-09 12:05 +0000
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-09 08:06 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-04 10:01 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:38 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-04 15:25 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 10:35 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:43 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:29 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-04 01:04 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:40 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 10:21 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-02 19:54 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:48 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 00:21 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:55 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-03 04:45 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 13:02 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-03 07:19 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 00:02 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-04 00:55 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-04 09:45 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 10:06 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-02 02:24 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 10:57 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-02 04:31 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-02 15:45 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-10-02 08:29 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-10-03 00:47 -0700
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 09:59 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-03 10:09 +0100
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-10-01 01:51 -0400
Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 10:44 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-27 01:10 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-29 08:36 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-29 22:06 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-30 11:47 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-30 09:14 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-19 01:27 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-19 03:49 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:40 -0400
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 14:53 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:22 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 15:12 -0700
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 14:58 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-15 18:19 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:48 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-16 17:17 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 18:41 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:22 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 15:40 -0400
Re: Small, fast, resource-rich processor Torfinn Ingolfsen <tingo@home.no> - 2013-09-17 18:44 +0200
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:31 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:44 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:46 -0500
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 09:21 +0000
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-19 12:26 -0500
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 20:17 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 08:25 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 14:16 -0400
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-18 12:39 -0700
Re: Small, fast, resource-rich processor langwadt@fonz.dk - 2013-09-18 15:18 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 09:49 +0000
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:35 +0000
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 13:11 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:26 -0400
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 16:36 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:49 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 05:30 -0400
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-19 10:00 +0000
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-16 16:51 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 14:54 -0400
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-16 19:06 +0000
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-16 15:22 -0400
Re: Small, fast, resource-rich processor Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-09-17 09:40 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-17 11:48 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 15:50 -0400
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-17 21:03 +0000
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-17 17:05 -0400
Re: Small, fast, resource-rich processor gtwrek@sonic.net (Mark Curry) - 2013-09-17 21:16 +0000
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-17 16:38 -0700
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-17 21:33 -0400
Re: Small, fast, resource-rich processor Anssi Saari <as@sci.fi> - 2013-09-18 10:48 +0300
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-15 10:39 -0500
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 12:39 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-15 12:58 -0500
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-15 11:33 -0700
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-15 14:40 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-15 14:25 -0500
Re: Small, fast, resource-rich processor Paul Rubin <no.email@nospam.invalid> - 2013-09-15 13:35 -0700
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 12:40 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-15 14:57 -0500
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-15 13:44 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 01:46 -0700
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-16 10:26 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 02:44 -0700
Re: Small, fast, resource-rich processor Mel Wilson <mwilson@the-wire.com> - 2013-09-16 09:01 -0400
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 12:18 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-16 10:06 -0500
Re: Small, fast, resource-rich processor robert bristow-johnson <rbj@audioimagination.com> - 2013-09-16 10:34 -0700
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 12:09 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-16 17:31 -0500
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-16 12:00 -0700
Re: Small, fast, resource-rich processor glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-09-17 07:59 +0000
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-17 10:13 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 05:56 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-17 11:37 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-17 16:00 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-17 21:30 +0100
Re: Small, fast, resource-rich processor rickman <gnuarm@gmail.com> - 2013-09-18 12:46 -0400
Re: Small, fast, resource-rich processor Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-18 18:00 +0100
Re: Small, fast, resource-rich processor Don Y <this@isnotme.com> - 2013-09-11 12:10 -0700
Re: Small, fast, resource-rich processor Vladimir Vassilevsky <nospam@nowhere.com> - 2013-09-11 14:30 -0500
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 15:39 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 15:46 -0400
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 20:39 -0400
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-11 20:03 -0500
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-12 14:09 +0200
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-12 07:11 -0700
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-12 16:34 +0200
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-12 10:42 -0400
Re: Small, fast, resource-rich processor dp <dp@tgi-sci.com> - 2013-09-12 12:48 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-12 16:14 -0500
Re: Small, fast, resource-rich processor Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-09-12 21:39 +0200
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-12 23:41 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-12 16:08 -0500
Re: Small, fast, resource-rich processor David Brown <david.brown@removethis.hesbynett.no> - 2013-09-13 01:00 +0200
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.really> - 2013-09-12 23:03 -0500
Re: Small, fast, resource-rich processor David Brown <david@westcontrol.removethisbit.com> - 2013-09-13 08:47 +0200
Re: Small, fast, resource-rich processor Dave Nadler <drn@nadler.com> - 2013-09-11 15:40 -0700
Re: Small, fast, resource-rich processor Tim Wescott <tim@seemywebsite.please> - 2013-09-11 20:05 -0500
Re: Small, fast, resource-rich processor Randy Yates <yates@digitalsignallabs.com> - 2013-09-11 22:19 -0400
Page 11 of 22 — ← Prev page 1 … 9 10 [11] 12 13 … 22 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-19 03:58 -0400 |
| Message-ID | <l1earc$j9h$1@dont-email.me> |
| In reply to | #13725 |
On 9/19/2013 3:44 AM, glen herrmannsfeldt wrote: > > CPUs are an amazingly inefficient way to use logic, but often a > worthwhile tradeoff. I agree that CPUs are very inefficient logic. > If you are doing a lot of 16 bit adds, your 1 billion transistor > chip might do a few 16 bit adds per clock cycle. But a 16 bit adder > only takes thousands of transistors to build. I'm a little confused. Are you talking about FPGAs or CPUs? Intel CPUs are the biggest, most complex logic chips I've ever heard of. Surely this is the inefficiency you are talking about no? Implementing a KF on an Intel CPU is an ***enormous*** waste of transistors. ;^) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-19 09:45 +0100 |
| Message-ID | <YQy_t.106056$99.50191@fx24.am4> |
| In reply to | #13730 |
On 19/09/13 08:58, rickman wrote: > On 9/19/2013 3:44 AM, glen herrmannsfeldt wrote: >> >> CPUs are an amazingly inefficient way to use logic, but often a >> worthwhile tradeoff. > > I agree that CPUs are very inefficient logic. So, of course are FPGAs. And operational amplifiers. And discrete logic. And cellular automata. And... All technologies have their strengths and weaknesses. All projects have their objectives and constraints. The /only/ important point is to avoid choosing a technology that has unacceptable disadvantages in a given context. In most cases there is more than one way to skin the cat, and it doesn't really matter which is chosen.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-19 16:50 +0000 |
| Message-ID | <l1fa01$48r$2@speranza.aioe.org> |
| In reply to | #13730 |
In comp.dsp rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> CPUs are an amazingly inefficient way to use logic, but often a >> worthwhile tradeoff. > I agree that CPUs are very inefficient logic. >> If you are doing a lot of 16 bit adds, your 1 billion transistor >> chip might do a few 16 bit adds per clock cycle. But a 16 bit adder >> only takes thousands of transistors to build. > I'm a little confused. Are you talking about FPGAs or CPUs? Intel CPUs > are the biggest, most complex logic chips I've ever heard of. Surely > this is the inefficiency you are talking about no? Implementing a KF on > an Intel CPU is an ***enormous*** waste of transistors. ;^) Yes, I believe that they are in the billion transistor range, if you include the on-chip cache. I thought KF at least does some multiply, but there are algorithms that don't even do that. -- glen
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-19 07:31 +0000 |
| Message-ID | <l1e993$r0$1@speranza.aioe.org> |
| In reply to | #13659 |
In comp.dsp rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> When an existing processor is fast enough, that is probably the >> best choice. When a small number (cluster) is fast enough, that might >> also be the best choice. >> When you need to be 1000's of times faster, and the algorithm does >> a lot of fixed point addition, maybe some multiplication, you can do >> much better in a medium sized FPGA. >> For floating point algorithms, you might be able to use fixed point >> a little wider instead. >> A systolic array can be a very efficient way to process a large >> amount of data if the dependency is right. > These are all your opinions. I find it interesting that you use a > multiplier of 1000 for your cut over point. So at 100 you would use 100 > CPUs rather than an FPGA? (snip) I suppose with two data points, 1 and 1000, knowing that the dividing line is somewhere in between, maybe closer to 1, maybe to 1000. The geometric mean of 1 and 1000 is about 30, so maybe about there. But okay, there is a lot of NRE to be done for the FPGA design. A small cluster might be a good choice for a smaller number of processors. One could also build a special board with a bunch of your favorite CPU chip for a single board cluster. > That is a rhetorical question... Oops. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.really> |
|---|---|
| Date | 2013-09-17 11:30 -0500 |
| Message-ID | <Sf2dnVBaJpYyHqXPnZ2dnUVZ5sydnZ2d@giganews.com> |
| In reply to | #13654 |
On Tue, 17 Sep 2013 07:31:52 +0000, glen herrmannsfeldt wrote: << snip >> > > Over the years, there have been many tries at boards for general purpose > hardware acceleration that interface to another system. > Most have not been very successful commercially. As well as I know it, > mostly it is the problem of getting data into and out of the FPGA that > makes it hard, and reduces the usefulness of the solution. :) For an example of a solution that was ruled by data transfer: One of the projects that I worked on that involved some serious DSP vs. FPGA tradeoffs in the early design step was for video processing. We needed to do a correction to a pixel value that basically involved px_cor = f(px_raw, px_sur, a, b, c); where px_sur was the eight nearest-neighbors of a given pixel, and a, b, and c were each unique to a pixel. The function was rather simple, but in addition to a write the algorithm required either 12 fetches per pixel if you were bone-headed about it, or buffering three lines of video on- chip and four fetches per pixel. Even when we leveraged the DDR RAM burst mode transfers to the max, with the available memory at the time we still needed two memory buses to get the data into and out of the processor that was doing the actual work. We ended up using FPGAs instead of DSPs not because of the limitations on core execution speeds, but because we couldn't find a DSP chip with a wide and fast enough memory interface that was cheaper than an FPGA talking to a pair (or perhaps three: I can't remember) sets of DDR chips. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | gtwrek@sonic.net (Mark Curry) |
|---|---|
| Date | 2013-09-17 21:11 +0000 |
| Message-ID | <l1agib$528$2@dont-email.me> |
| In reply to | #13668 |
In article <Sf2dnVBaJpYyHqXPnZ2dnUVZ5sydnZ2d@giganews.com>, Tim Wescott <tim@seemywebsite.really> wrote: >On Tue, 17 Sep 2013 07:31:52 +0000, glen herrmannsfeldt wrote: > ><< snip >> >> >> Over the years, there have been many tries at boards for general purpose >> hardware acceleration that interface to another system. >> Most have not been very successful commercially. As well as I know it, >> mostly it is the problem of getting data into and out of the FPGA that >> makes it hard, and reduces the usefulness of the solution. > >:) > >For an example of a solution that was ruled by data transfer: > >One of the projects that I worked on that involved some serious DSP vs. >FPGA tradeoffs in the early design step was for video processing. We >needed to do a correction to a pixel value that basically involved > >px_cor = f(px_raw, px_sur, a, b, c); > >where px_sur was the eight nearest-neighbors of a given pixel, and a, b, >and c were each unique to a pixel. The function was rather simple, but >in addition to a write the algorithm required either 12 fetches per pixel >if you were bone-headed about it, or buffering three lines of video on- >chip and four fetches per pixel. > >Even when we leveraged the DDR RAM burst mode transfers to the max, with >the available memory at the time we still needed two memory buses to get >the data into and out of the processor that was doing the actual work. > >We ended up using FPGAs instead of DSPs not because of the limitations on >core execution speeds, but because we couldn't find a DSP chip with a >wide and fast enough memory interface that was cheaper than an FPGA >talking to a pair (or perhaps three: I can't remember) sets of DDR chips. That's almost always the case (at least with video it is). The kernel of some algorithm is fairly easy (both design, and documentation, and modeling). The algorithm can be done in hw, or sw, or xxx (even Matlab!, heh). All the blood, sweat and tears are spent in getting all data to the kernel, and then back out in a timely, ordered fashion... Regards, Mark
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-18 13:11 -0400 |
| Message-ID | <l1cmse$g6t$1@dont-email.me> |
| In reply to | #13682 |
On 9/17/2013 5:11 PM, Mark Curry wrote: > In article<Sf2dnVBaJpYyHqXPnZ2dnUVZ5sydnZ2d@giganews.com>, > Tim Wescott<tim@seemywebsite.really> wrote: >> >> We ended up using FPGAs instead of DSPs not because of the limitations on >> core execution speeds, but because we couldn't find a DSP chip with a >> wide and fast enough memory interface that was cheaper than an FPGA >> talking to a pair (or perhaps three: I can't remember) sets of DDR chips. > > That's almost always the case (at least with video it is). > The kernel of some algorithm is fairly easy (both design, and > documentation, and modeling). The algorithm can be done in hw, > or sw, or xxx (even Matlab!, heh). > > All the blood, sweat and tears are spent in getting all data to the > kernel, and then back out in a timely, ordered fashion... I learned that a long time ago working on an array processor, the ST-100. It had two rack cabinets of circuitry, one was full of conventional TTL/ECL and the other was three boards of ECL custom gate arrays (the bulk was for the cooling). Two of the three boards were the "compute head", all the logic for doing the floating point math - two adders, two multipliers and a square root/divide circuit. The third board was the SMP, Storage Move Processor. It was responsible for keeping the cache memory filled with data the compute head needed to operate on and tucking away the results into main memory. At the time I was very impressed with the fact that the SMP was a full 50% of the size of the actual ALUs. It made me realize the importance of data movement and how that actually defined the capabilities of a DSP machine. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-17 11:42 +0200 |
| Message-ID | <s4SdnVOiBKaPuaXPnZ2dnUVZ7qydnZ2d@lyse.net> |
| In reply to | #13639 |
On 16/09/13 19:53, rickman wrote: > On 9/16/2013 3:17 AM, David Brown wrote: >> On 15/09/13 22:32, rickman wrote: >>> On 9/15/2013 4:12 PM, David Brown wrote: >>>> >>>> He is simply disputing the idea that anything could be implemented in >>>> software more easily than in an FPGA. I know FPGA's can be useful >>>> devices, and I know that experts can write code for them faster and >>>> more >>>> efficiently than many non-experts would imagine, but I for one am >>>> getting fed up with this "FPGA are the best at everything - the >>>> fastest, >>>> cheapest, quickest development, lowest power, most efficient, longest >>>> living, best development tools, etc., etc." nonsense. >>> >>> I never said anything of the sort. Please stop with the nonsense >>> yourself. >> >> Re-read your posts of the past few days, in this thread and the "AREF >> bypass capacitance" thread. Fair enough, you haven't explicitly claimed >> that FPGA's are the best solution in all ways for all problems - I >> exaggerated. But you have made still a range of absurd claims about how >> good they are in many circumstances, despite evidence to the contrary. > > This is a more reasonable conversation, but you still make unsupported > claims. What did I say that was "absurd"? > > >> FPGAs have their uses - there are things you can do with them that would >> be near-impossible, and very expensive, to do in any other way. And >> there is an overlap of problems that can be solved by either >> processors/microcontrollers or FPGAs. But face facts - there are lots >> of problems that are more efficiently done in software, and that means a >> microcontroller or processor (or soft processor /if/ you already need an >> FPGA for other things). > > Again, I have never said anything to the contrary. My point is that the > line between the taks more usefully done on an FPGA and tasks done more > usefully on an MCU is not where most people (at least in this thread) > think it is. There is a *lot* of prejudice and bias about FPGAs and the > effort required to use them. This mess started when I questioned the > use of the word "nightmare" used to describe the FPGA development > process. I don't think you are trying to support that claim are you? > No, you are trying to make the point that it's not the opposite because > you seem to feel I am saying FPGAs make everything easy. I'm not saying > that and that is obvious if you read what I actually write. > My point - and I am not alone here in thinking this, based on other peoples posts - is that you have been making a lot of posts recently recommending FPGAs as a better/cheaper/faster/lower-power/easier solution to all sorts of problems that really are not FPGA problems at all. People are looking for screwdrivers, pliers, or spanners and you are insisting that your hammer is the best tool for all jobs. I /know/ you are not /actually/ saying this, and I /know/ you don't believe this - I've read enough of your posts over the years to know you are a "right tool for the job" person. You don't always agree with others about what that right tool is, since you are biased towards the tools you know best - just like the rest of us. However, you should be aware that this is the impression you are giving. Everybody - you, me, and everyone else - has a tendency to exaggerate and over-sell their opinions at times, and I think that has come across in these two threads. It is unfortunate that this impression of over-selling is shadowing the actual information and ideas you are trying to get across. I hope you see this as constructive criticism here - at least, that is what I am trying to do. I would just like to see things going back to technical discussions - or informative and interesting off-topic discussions. If you don't agree with me here, then fair enough. I understand your point that FPGAs have a bad reputation for complexity, and that this is not justified (or at least, not /always/ justified!). And I agree with it to a fair extent - there are more things that can be done sensibly with FPGAs than many people think. But I think it works the other way too - there are many things that FPGA fans think are a good idea in FPGAs that are actually better implemented in other ways. > >> You will be a better advocate of FPGAs if you are realistic about them - >> at the moment, you are scaring off the fence-sitters. > > Again, you are making a claim about my position without any support. > What did I say that was unrealistic? > > >>>> Please, Rick, we /know/ FPGAs are useful devices. But give it a >>>> rest? No >>>> sane person - not even a Xilinx or Altera salesman - would claim that >>>> implementing a Kalman filter is not orders of magnitude harder in an >>>> FPGA than in software on a processor with good double precision >>>> floating >>>> point support. The X and A salesmen will tell you that this is why they >>>> put hard ARM cores in their chips - so you can do the PWM, encoders, >>>> etc., in FPGA, and the complex maths in the cpu. >>> >>> If you don't want to have a rational conversation, please don't reply. >>> >>> If you want to explain why a Kalman filter is so hard in an FPGA, please >>> do. I'm sure it is not hard to show what part of the algorithm is FPGA >>> unfriendly. >>> >> >> I haven't implemented a Kalman filter myself, though I trust Tim's >> judgement here. But you don't need any experience to look at the >> Wikipedia page (or any other webpage or book) and see that this is a >> complex algorithm, and is best done step by step. > > Why does that make it hard in an FPGA? > FPGAs are really good at doing things in parallel, and less good at doing things serially. Processors are really good at doing things serially, and less good at doing them in parallel. This is a fundamental difference between the two types of computation. Obviously you /can/ do things in serial in an FPGA (and you can at least simulate parallelism in a cpu), an inherently serial algorithm with lots of branches, choices, loops, etc., is most naturally implemented in a serial processor. Add to that the desire for double-precision floating point. Yes, an FPGA /can/ do these calculations - but it is much easier to do it in software. In software, you write "double a, b, c, d; a = b * c + d;" and that's it done - in an FPGA, you design and debug double-precision floating point addition and multiplication blocks. > >> What you seem to be missing entirely here is that no one is saying >> Kalman filters cannot be implemented on FPGAs - we are saying it is >> vastly more difficult to do so. It takes a lot of work to learn to >> understand these things, and to test and debug the code step by step. >> It is orders of magnitude easier with software that is easy to start and >> stop, debug, view data, print out logs of data, feed with test data, run >> on a PC rather than the target, etc. (And if you think to mention FPGA >> "simulation" - or even "co-simulation" - don't bother, for reasons that >> are obvious to everyone else. If you want to talk about MyHDL or Lava, >> I'll be happy to hear your new ideas.) > > Yes, they say it is *MUCH* harder to do in an FPGA... without *any* > supporting evidence. Your bias is pretty clear from this paragraph > alone. You list in detail the software process and then negate without > ***any*** evidence the utility of HDL simulation. In fact, you decry it > specifically stating that you don't need to provide any evidence because > it is "obvious"!!! That is *exactly* the sort of bias I am addressing. > > Have you done FPGA work? I haven't done much - but I have done enough to be entirely confident in claiming that implementing a Kalman filter in an FPGA would be /much/ harder and more time consuming for an FPGA expert than implementing the same thing in software would be for a software expert (given equal knowledge of the maths, etc.). I have done enough FPGA work to know that it is certainly /possible/ in an FPGA - and that with a good enough FPGA developer it would not be as bad as many might think. I think that tools such as MyHDL could make it more tractable than traditional Verilog or VHDL. Possibly the most efficient way would be to write the code in C, get it all working nicely, then use something like Altera's tools for converting C into FPGA hardware. But that leaves you with the question of why you should bother with the FPGA step at all. > > >> When you have a good, working Kalman implementation in software, and you >> need to run it 100 times faster with little regard for hardware costs - > /then/ it is time to break out the FPGA and transfer it over. > > More bias... this assumes that the *only* utility of an FPGA is to make > things run very fast and that FPGA hardware costs are much higher than > CPU hardware costs. Really? I have FPGA boards that sell for under > $50. I believe the hardware cost the OP talked about was a SBC of some > sort which is not likely to be under $50. > You could make a processor card for a great deal less than $50 that will do the job - the OP is looking at SBC solutions as a way of minimising development costs, not for minimising unit costs. I know that FPGA's have many uses other than making things run fast - but in this case, I don't see any potential benefits for calculating Kalman filters other than possibly high speed (for a given price, board space, power, etc.). Can /you/ give any other potential benefits? You can take it as a given that a microcontroller will be cheaper if unit costs are important, since the whole thing could be re-implemented in fixed point and run in an ARM for a couple of dollars. > >>> As to the ARM cores, they are very recent if you look around. So it was >>> never done until the ARM cores came out? >> >> Yes, people implemented Kalman filters in FPGAs before there were hard >> ARM cores - there were other hard cpu cores before that (PowerPC, and >> older weaker ARMs) as well as a multitude of soft cpu cores. And as I >> say, it /is/ possible to implement Kalman in "pure" fpga. People >> implement these things for a doctoral thesis - while in the pure >> software world, people knock them up in a couple of days using software >> downloaded from the net. /That/ is the difference. > > And yet, no one can tell me what aspect of a Kalman filter makes it so > hard to implement in an FPGA... > I tried to do so - but you said I had no evidence for the points I made. You have no evidence for any counter-arguments, so I guess you either believe what people are telling you (and what you can see from web searches on Kalman on FPGAs and in software), or you can disagree, or you can try and implement them in software and FPGAs for comparison.
[toc] | [prev] | [next] | [standalone]
| From | Al Clark <aclark@danvillesignal.com> |
|---|---|
| Date | 2013-09-17 14:06 +0000 |
| Message-ID | <XnsA23E5C9689F15aclarkdanvillesignal@69.16.179.20> |
| In reply to | #13662 |
I realize that I am jumping in very late to this conversation. It was so long, I couldn't find the original post. As I gather, the requirement is for a double precision floating point application and a battleground has erupted over FPGA versus DSP processor. We make boards with both FPGAs and SHARC DSPs. In fact, I am working on one now. From my perspective, FPGAs can do very fast processing but are usually much more difficult to program. Maybe if you are very skilled in Verilog or VHDL, your experience might be different. Our boards have been DSP/FPGA combos where the FPGA is usually configured to do a few simple operations very fast. For example, the front end of a software defined radio. The DSP tends to do baseboand processing and all the housekeeping. FPGAs almost always consume a lot more power than processors when performing the same task. This matters in some applications. I don't know why this application needs double precision floating point. SHARCs normally operate with 32 bit IEEE floating point, but there is also a 40 bit mode, where the mantissa is 32 bits instead of 24. Perhaps this would meet the requirement. If this is the case, there are several solutions available, most less expensive than FPGAs and much easier to program. You can also do fixed point in double precision with a SHARC. Floating point emulation is always possible with fixed point processors but generally not efficient enough to make sense. Al Clark www.danvillesignal.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-17 16:44 +0200 |
| Message-ID | <e9-dnfdiPfAj96XPnZ2dnUVZ8l-dnZ2d@lyse.net> |
| In reply to | #13665 |
On 17/09/13 16:06, Al Clark wrote: > I realize that I am jumping in very late to this conversation. > It was so long, I couldn't find the original post. > > As I gather, the requirement is for a double precision floating > point application and a battleground has erupted over FPGA > versus DSP processor. > > We make boards with both FPGAs and SHARC DSPs. In fact, I am > working on one now. > > From my perspective, FPGAs can do very fast processing but are > usually much more difficult to program. Maybe if you are very > skilled in Verilog or VHDL, your experience might be different. That's the usual experience, as far as I have ever heard - at least until you are pushing the limits of what you can do with the DSP. Usually a DSP is significantly more difficult to work with than a microcontroller, which is what the OP (and others in c.a.e) usually work with. This is because many DSP's work with weird data formats (such as the 40-bit mode mentioned), often have a C "char" that is greater than 8-bit, often need a lot of extra work to get the best throughput (such as putting different data in different memory areas to maximize pipelining), and often have outdated, expensive or simply odd tools. But of course DSP's are typically faster per MHz at central DSP operations. Thus they fall somewhere between microcontrollers and FPGAs in the tradeoff of speed vs. development time. (This is, of course, a generalisation - there will be exceptions depending on the particulars of the problem, the people working on it, and the devices in question.) > Our boards have been DSP/FPGA combos where the FPGA is usually > configured to do a few simple operations very fast. For example, > the front end of a software defined radio. The DSP tends to do > baseboand processing and all the housekeeping. > > FPGAs almost always consume a lot more power than processors > when performing the same task. This matters in some > applications. > > I don't know why this application needs double precision > floating point. SHARCs normally operate with 32 bit IEEE > floating point, but there is also a 40 bit mode, where the > mantissa is 32 bits instead of 24. Perhaps this would meet the > requirement. If this is the case, there are several solutions > available, most less expensive than FPGAs and much easier to > program. You can also do fixed point in double precision with a > SHARC. Floating point emulation is always possible with fixed > point processors but generally not efficient enough to make > sense. > The application does not specifically require double precision floating point. But it requires maths that can be expressed conveniently using floating point, and that require a higher accuracy (at some points) than standard single-precision floating point provides. A floating point format between single and double precision may do the job, as would fixed point with enough bits (64-bit has been mentioned for intermediary results, but 32-bit is perhaps enough for other parts - again, these sizes come from standard C sizes rather than theoretical ideal sizes).
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.really> |
|---|---|
| Date | 2013-09-17 11:43 -0500 |
| Message-ID | <Sf2dnVNaJpYFG6XPnZ2dnUVZ5sydnZ2d@giganews.com> |
| In reply to | #13665 |
On Tue, 17 Sep 2013 14:06:08 +0000, Al Clark wrote: > I realize that I am jumping in very late to this conversation. It was so > long, I couldn't find the original post. That's OK. The original post has little to do with the FPGA vs. processor discussion. I was looking for a small SBC with fast double-precision floating point so that I could take a working Kalman filter implementation, slap it in, and have it work. > As I gather, the requirement is for a double precision floating point > application and a battleground has erupted over FPGA versus DSP > processor. > > We make boards with both FPGAs and SHARC DSPs. In fact, I am working on > one now. I almost called you, until the customer and I came up with a better solution, involving a lightly loaded PC in the same box. > From my perspective, FPGAs can do very fast processing but are usually > much more difficult to program. Maybe if you are very skilled in Verilog > or VHDL, your experience might be different. Our boards have been > DSP/FPGA combos where the FPGA is usually configured to do a few simple > operations very fast. For example, > the front end of a software defined radio. The DSP tends to do baseboand > processing and all the housekeeping. > > FPGAs almost always consume a lot more power than processors when > performing the same task. This matters in some applications. > > I don't know why this application needs double precision floating point. Not "need" so much as "wants real bad". I've simulated the Kalman filter with 64-bit fixed point, and it works just fine (which is not surprising when you think about it, because I was using double precision floating point as the underlying data type). It may even work with 48-bit. But doing so would obviate my primary goal: this is a small production volume project, for which a proven solution exists that runs just fine on a PC- class processor. The volume is small enough that we can spend a Whole Lot of Money on hardware before it's worthwhile for me to do the development work to port things over to just about anything else. > SHARCs normally operate with 32 bit IEEE floating point, but there is > also a 40 bit mode, where the mantissa is 32 bits instead of 24. Perhaps > this would meet the requirement. If this is the case, there are several > solutions available, most less expensive than FPGAs and much easier to > program. You can also do fixed point in double precision with a SHARC. > Floating point emulation is always possible with fixed point processors > but generally not efficient enough to make sense. I thought there was a double-precision floating point SHARC? That's a disappointment -- nearly any time that I choose floating point the choice is between 32-bit fixed point and double-precision floating point, because most of my control problems just don't cut it with single- precision floating point. _Sometimes_ that's not the case, but with control loops, usually if your sampling rates are getting into DSP territory then you care enough about precision that your integrator depth is getting beyond 24 bits of precision. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-17 13:22 -0400 |
| Message-ID | <l1a350$h0b$1@dont-email.me> |
| In reply to | #13662 |
On 9/17/2013 5:42 AM, David Brown wrote: > On 16/09/13 19:53, rickman wrote: >> On 9/16/2013 3:17 AM, David Brown wrote: >>> On 15/09/13 22:32, rickman wrote: >>>> On 9/15/2013 4:12 PM, David Brown wrote: >>>>> >>>>> He is simply disputing the idea that anything could be implemented in >>>>> software more easily than in an FPGA. I know FPGA's can be useful >>>>> devices, and I know that experts can write code for them faster and >>>>> more >>>>> efficiently than many non-experts would imagine, but I for one am >>>>> getting fed up with this "FPGA are the best at everything - the >>>>> fastest, >>>>> cheapest, quickest development, lowest power, most efficient, longest >>>>> living, best development tools, etc., etc." nonsense. >>>> >>>> I never said anything of the sort. Please stop with the nonsense >>>> yourself. >>> >>> Re-read your posts of the past few days, in this thread and the "AREF >>> bypass capacitance" thread. Fair enough, you haven't explicitly claimed >>> that FPGA's are the best solution in all ways for all problems - I >>> exaggerated. But you have made still a range of absurd claims about how >>> good they are in many circumstances, despite evidence to the contrary. >> >> This is a more reasonable conversation, but you still make unsupported >> claims. What did I say that was "absurd"? >> >> >>> FPGAs have their uses - there are things you can do with them that would >>> be near-impossible, and very expensive, to do in any other way. And >>> there is an overlap of problems that can be solved by either >>> processors/microcontrollers or FPGAs. But face facts - there are lots >>> of problems that are more efficiently done in software, and that means a >>> microcontroller or processor (or soft processor /if/ you already need an >>> FPGA for other things). >> >> Again, I have never said anything to the contrary. My point is that the >> line between the taks more usefully done on an FPGA and tasks done more >> usefully on an MCU is not where most people (at least in this thread) >> think it is. There is a *lot* of prejudice and bias about FPGAs and the >> effort required to use them. This mess started when I questioned the >> use of the word "nightmare" used to describe the FPGA development >> process. I don't think you are trying to support that claim are you? >> No, you are trying to make the point that it's not the opposite because >> you seem to feel I am saying FPGAs make everything easy. I'm not saying >> that and that is obvious if you read what I actually write. >> > > My point - and I am not alone here in thinking this, based on other > peoples posts - is that you have been making a lot of posts recently > recommending FPGAs as a better/cheaper/faster/lower-power/easier > solution to all sorts of problems that really are not FPGA problems at > all. People are looking for screwdrivers, pliers, or spanners and you > are insisting that your hammer is the best tool for all jobs. Guilty in your mind. That is exactly the point of contention. Which task are better in an FPGA and which are not. So far we have not actually been able to discuss the technical merits of any specific case because nearly all of the responses were emotional rather than rational. Your comments above are not an exception. Does it really matter to the facts whether I am in the majority or the minority? No. I never said "all", that is *your* word. Give a specific quote for a statement I made that says FPGAs are better for *all* jobs. > I /know/ you are not /actually/ saying this, and I /know/ you don't > believe this - I've read enough of your posts over the years to know you > are a "right tool for the job" person. You don't always agree with > others about what that right tool is, since you are biased towards the > tools you know best - just like the rest of us. > > However, you should be aware that this is the impression you are giving. > Everybody - you, me, and everyone else - has a tendency to exaggerate > and over-sell their opinions at times, and I think that has come across > in these two threads. It is unfortunate that this impression of > over-selling is shadowing the actual information and ideas you are > trying to get across. > > I hope you see this as constructive criticism here - at least, that is > what I am trying to do. I would just like to see things going back to > technical discussions - or informative and interesting off-topic > discussions. If you don't agree with me here, then fair enough. I always appreciate constructive criticism, but I can't really see it here. You are making claims about what I have said that *aren't* accurate. If you want to see a technical discussion, you need to address those who continue to make emotional statements. > I understand your point that FPGAs have a bad reputation for complexity, > and that this is not justified (or at least, not /always/ justified!). > And I agree with it to a fair extent - there are more things that can be > done sensibly with FPGAs than many people think. But I think it works > the other way too - there are many things that FPGA fans think are a > good idea in FPGAs that are actually better implemented in other ways. Do you have examples? Otherwise this is just opinion and you are part of the problem you discuss in the previous paragraph. >>> You will be a better advocate of FPGAs if you are realistic about them - >>> at the moment, you are scaring off the fence-sitters. >> >> Again, you are making a claim about my position without any support. >> What did I say that was unrealistic? >> >> >>>>> Please, Rick, we /know/ FPGAs are useful devices. But give it a >>>>> rest? No >>>>> sane person - not even a Xilinx or Altera salesman - would claim that >>>>> implementing a Kalman filter is not orders of magnitude harder in an >>>>> FPGA than in software on a processor with good double precision >>>>> floating >>>>> point support. The X and A salesmen will tell you that this is why they >>>>> put hard ARM cores in their chips - so you can do the PWM, encoders, >>>>> etc., in FPGA, and the complex maths in the cpu. >>>> >>>> If you don't want to have a rational conversation, please don't reply. >>>> >>>> If you want to explain why a Kalman filter is so hard in an FPGA, please >>>> do. I'm sure it is not hard to show what part of the algorithm is FPGA >>>> unfriendly. >>>> >>> >>> I haven't implemented a Kalman filter myself, though I trust Tim's >>> judgement here. But you don't need any experience to look at the >>> Wikipedia page (or any other webpage or book) and see that this is a >>> complex algorithm, and is best done step by step. >> >> Why does that make it hard in an FPGA? >> > > FPGAs are really good at doing things in parallel, and less good at > doing things serially. I get tired of people making *unsupported* claims. This is a good example. What about an FPGA makes it "less good" at doing serial operations? Hmm? Or maybe I misunderstand what the comparison point is for the "less good" claim. Perhaps you mean FPGAs are less good at serial computations than FPGAs are at parallel computations. Even that I can't really see. FPGAs are agnostic about the method, they do serial or parallel equally well. > Processors are really good at doing things > serially, and less good at doing them in parallel. Other than multicore processors, they don't do things in parallel at *all*! Processors always execute code sequentially. > This is a > fundamental difference between the two types of computation. Obviously > you /can/ do things in serial in an FPGA (and you can at least simulate > parallelism in a cpu), an inherently serial algorithm with lots of > branches, choices, loops, etc., is most naturally implemented in a > serial processor. Can you explain "natural"? That sounds like a bias. I can't measure "natural" in any way I know of. > Add to that the desire for double-precision floating point. Yes, an > FPGA /can/ do these calculations - but it is much easier to do it in > software. In software, you write "double a, b, c, d; a = b * c + d;" > and that's it done - in an FPGA, you design and debug double-precision > floating point addition and multiplication blocks. It is easier to do in software only if someone has done it for you or you are using a processor where DP FP is done in hardware. Once you construct your basic DP FP algorithm in an HDL you never need to think about it again in an FPGA. So no, I don't agree that it is "hard" in an FPGA. Again, an FPGA is data type agnostic. >>> What you seem to be missing entirely here is that no one is saying >>> Kalman filters cannot be implemented on FPGAs - we are saying it is >>> vastly more difficult to do so. It takes a lot of work to learn to >>> understand these things, and to test and debug the code step by step. >>> It is orders of magnitude easier with software that is easy to start and >>> stop, debug, view data, print out logs of data, feed with test data, run >>> on a PC rather than the target, etc. (And if you think to mention FPGA >>> "simulation" - or even "co-simulation" - don't bother, for reasons that >>> are obvious to everyone else. If you want to talk about MyHDL or Lava, >>> I'll be happy to hear your new ideas.) >> >> Yes, they say it is *MUCH* harder to do in an FPGA... without *any* >> supporting evidence. Your bias is pretty clear from this paragraph >> alone. You list in detail the software process and then negate without >> ***any*** evidence the utility of HDL simulation. In fact, you decry it >> specifically stating that you don't need to provide any evidence because >> it is "obvious"!!! That is *exactly* the sort of bias I am addressing. >> >> Have you done FPGA work? > > I haven't done much - but I have done enough to be entirely confident in > claiming that implementing a Kalman filter in an FPGA would be /much/ > harder and more time consuming for an FPGA expert than implementing the > same thing in software would be for a software expert (given equal > knowledge of the maths, etc.). Good, then please explain what aspect of the filter is hard to do in an FPGA... > I have done enough FPGA work to know that it is certainly /possible/ in > an FPGA - and that with a good enough FPGA developer it would not be as > bad as many might think. I think that tools such as MyHDL could make it > more tractable than traditional Verilog or VHDL. Possibly the most > efficient way would be to write the code in C, get it all working > nicely, then use something like Altera's tools for converting C into > FPGA hardware. But that leaves you with the question of why you should > bother with the FPGA step at all. Or why bother with the C step at all? Why is it hard to code a KF in an HDL? I keep repeating the question and no one ever answers it. Claims are made repeatedly, but with *NO* supporting evidence, just more opinion. >>> When you have a good, working Kalman implementation in software, and you >>> need to run it 100 times faster with little regard for hardware costs - >> /then/ it is time to break out the FPGA and transfer it over. >> >> More bias... this assumes that the *only* utility of an FPGA is to make >> things run very fast and that FPGA hardware costs are much higher than >> CPU hardware costs. Really? I have FPGA boards that sell for under >> $50. I believe the hardware cost the OP talked about was a SBC of some >> sort which is not likely to be under $50. >> > > You could make a processor card for a great deal less than $50 that will > do the job - the OP is looking at SBC solutions as a way of minimising > development costs, not for minimising unit costs. Really? The OP said he implemented the algorithm on a standard MCU, the type you can put on a <$50 PCB and it ran *way* too slow. What processor card would you use? > I know that FPGA's have many uses other than making things run fast - > but in this case, I don't see any potential benefits for calculating > Kalman filters other than possibly high speed (for a given price, board > space, power, etc.). Can /you/ give any other potential benefits? You > can take it as a given that a microcontroller will be cheaper if unit > costs are important, since the whole thing could be re-implemented in > fixed point and run in an ARM for a couple of dollars. You have drifted off target. The original issue was the statement that using FPGAs is a "nightmare". Where did I ever say an FPGA is a better solution for this KF than using a GP CPU? Again, the OP has said that an ARM processor he used was way too slow. You can get faster ones, but they *aren't* "a couple of dollars". >>>> As to the ARM cores, they are very recent if you look around. So it was >>>> never done until the ARM cores came out? >>> >>> Yes, people implemented Kalman filters in FPGAs before there were hard >>> ARM cores - there were other hard cpu cores before that (PowerPC, and >>> older weaker ARMs) as well as a multitude of soft cpu cores. And as I >>> say, it /is/ possible to implement Kalman in "pure" fpga. People >>> implement these things for a doctoral thesis - while in the pure >>> software world, people knock them up in a couple of days using software >>> downloaded from the net. /That/ is the difference. >> >> And yet, no one can tell me what aspect of a Kalman filter makes it so >> hard to implement in an FPGA... >> > > I tried to do so - but you said I had no evidence for the points I made. > You have no evidence for any counter-arguments, so I guess you either > believe what people are telling you (and what you can see from web > searches on Kalman on FPGAs and in software), or you can disagree, or > you can try and implement them in software and FPGAs for comparison. So someone makes a claim that I disagree with, "FPGAs are a nightmare to use". I ask him why they are a nightmare and you say his statement stands unless I can prove otherwise.... interesting. Your points are equally unsupported that it is hard to implement a KF in an FPGA. I just want you to tell me what part of a KF is *hard* to implement on an FPGA, that's all. Just show me the logic that is hard to do in an FPGA... That should be easy, right? My evidence is that I can design any hardware in an FPGA that exists in any other digital device. So clearly an FPGA can do anything other devices can do unless you bump up against some limitation such as memory size or power dissipation, etc. I don't know of anything about FPGAs that are inherently *hard* to use. But I guess I can't prove the absence of a fault. Is there some reason you can't discuss the facts rather than just opinions? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-18 17:17 +0200 |
| Message-ID | <b4OdndeM1YO4WaTPnZ2dnUVZ7sednZ2d@lyse.net> |
| In reply to | #13674 |
On 17/09/13 19:22, rickman wrote: > On 9/17/2013 5:42 AM, David Brown wrote: >> On 16/09/13 19:53, rickman wrote: >>> On 9/16/2013 3:17 AM, David Brown wrote: >>>> On 15/09/13 22:32, rickman wrote: >>>>> On 9/15/2013 4:12 PM, David Brown wrote: >>>>>> >>>>>> He is simply disputing the idea that anything could be implemented in >>>>>> software more easily than in an FPGA. I know FPGA's can be useful >>>>>> devices, and I know that experts can write code for them faster and >>>>>> more >>>>>> efficiently than many non-experts would imagine, but I for one am >>>>>> getting fed up with this "FPGA are the best at everything - the >>>>>> fastest, >>>>>> cheapest, quickest development, lowest power, most efficient, longest >>>>>> living, best development tools, etc., etc." nonsense. >>>>> >>>>> I never said anything of the sort. Please stop with the nonsense >>>>> yourself. >>>> >>>> Re-read your posts of the past few days, in this thread and the "AREF >>>> bypass capacitance" thread. Fair enough, you haven't explicitly >>>> claimed >>>> that FPGA's are the best solution in all ways for all problems - I >>>> exaggerated. But you have made still a range of absurd claims about >>>> how >>>> good they are in many circumstances, despite evidence to the contrary. >>> >>> This is a more reasonable conversation, but you still make unsupported >>> claims. What did I say that was "absurd"? >>> >>> >>>> FPGAs have their uses - there are things you can do with them that >>>> would >>>> be near-impossible, and very expensive, to do in any other way. And >>>> there is an overlap of problems that can be solved by either >>>> processors/microcontrollers or FPGAs. But face facts - there are lots >>>> of problems that are more efficiently done in software, and that >>>> means a >>>> microcontroller or processor (or soft processor /if/ you already >>>> need an >>>> FPGA for other things). >>> >>> Again, I have never said anything to the contrary. My point is that the >>> line between the taks more usefully done on an FPGA and tasks done more >>> usefully on an MCU is not where most people (at least in this thread) >>> think it is. There is a *lot* of prejudice and bias about FPGAs and the >>> effort required to use them. This mess started when I questioned the >>> use of the word "nightmare" used to describe the FPGA development >>> process. I don't think you are trying to support that claim are you? >>> No, you are trying to make the point that it's not the opposite because >>> you seem to feel I am saying FPGAs make everything easy. I'm not saying >>> that and that is obvious if you read what I actually write. >>> >> >> My point - and I am not alone here in thinking this, based on other >> peoples posts - is that you have been making a lot of posts recently >> recommending FPGAs as a better/cheaper/faster/lower-power/easier >> solution to all sorts of problems that really are not FPGA problems at >> all. People are looking for screwdrivers, pliers, or spanners and you >> are insisting that your hammer is the best tool for all jobs. > > Guilty in your mind. That is exactly the point of contention. Which > task are better in an FPGA and which are not. So far we have not > actually been able to discuss the technical merits of any specific case > because nearly all of the responses were emotional rather than rational. > Your comments above are not an exception. > > Does it really matter to the facts whether I am in the majority or the > minority? No. I never said "all", that is *your* word. Give a > specific quote for a statement I made that says FPGAs are better for > *all* jobs. If you can't see the issue with your recent posts and your attitude in them, then there is little more I can say here. Communication is more than the sum of the words you write, and the impression you give is from between the lines and general points more than anything specific. Yes, you are "guilty" in /my/ mind, and this is /my/ opinion - not the exact words you wrote. That's the point - this is the opinion I have formed from reading your posts. If I, and at least some others here, were not human then perhaps we would have have seen nothing but the technical points you made. From your posts in the recent threads, I am left with the impression that you are a "all I've got is an FPGA hammer" evangelist - and I know that is not true, and I know that is not the impression you are trying to give. But it is the impression you /are/ giving - and I thought you should be told. But now I will try my best to be a /little/ more technical. > >> I /know/ you are not /actually/ saying this, and I /know/ you don't >> believe this - I've read enough of your posts over the years to know you >> are a "right tool for the job" person. You don't always agree with >> others about what that right tool is, since you are biased towards the >> tools you know best - just like the rest of us. >> >> However, you should be aware that this is the impression you are giving. >> Everybody - you, me, and everyone else - has a tendency to exaggerate >> and over-sell their opinions at times, and I think that has come across >> in these two threads. It is unfortunate that this impression of >> over-selling is shadowing the actual information and ideas you are >> trying to get across. >> >> I hope you see this as constructive criticism here - at least, that is >> what I am trying to do. I would just like to see things going back to >> technical discussions - or informative and interesting off-topic >> discussions. If you don't agree with me here, then fair enough. > > I always appreciate constructive criticism, but I can't really see it > here. You are making claims about what I have said that *aren't* > accurate. If you want to see a technical discussion, you need to > address those who continue to make emotional statements. > > >> I understand your point that FPGAs have a bad reputation for complexity, >> and that this is not justified (or at least, not /always/ justified!). >> And I agree with it to a fair extent - there are more things that can be >> done sensibly with FPGAs than many people think. But I think it works >> the other way too - there are many things that FPGA fans think are a >> good idea in FPGAs that are actually better implemented in other ways. > > Do you have examples? Otherwise this is just opinion and you are part > of the problem you discuss in the previous paragraph. > Yes, this is /opinion/ - this is perfectly obvious from my wording. It is a summation of countless years in embedded development - mostly microcontroller-based, but a little FPGA (and CPLD before that), and summation of talking to and listening to developers of all sorts. What do you want me to do - dig through comp.arch.embedded archives looking for examples of over-enthusiastic FPGA proponents? Show you my own mistakes, when I have started looking at FPGA solutions only to find cheaper and better alternatives? Or perhaps you think that while everyone else is biased and promotes their favourite technology over others, but FPGA fans are all precise and rational and would never consider suggesting one unless it were clearly the best idea? Opinions are /good/. We need to be clear about what are opinions and what are facts, and we need to understand our own biases and those of others. But with that in mind, "opinion" is formed from our direct and indirect experiences. Your customers do not come to you because can develop for FPGAs - they come to you for your experience. They come for your /opinion/. Obviously when we are asked for a professional opinion, we do more research and more justification than in a Usenet post. If you want hard evidence and justification for my claims about Kalman being much harder to do on an FPGA than in software, then I could certainly give you it - if you are willing to pay for my time. I could give you anything from bullet points, through web research, and up to full implementations in software and FPGA with the hours it took and the costs involved. But unless you are paying, Usenet opinion is all you get. > >>>> You will be a better advocate of FPGAs if you are realistic about >>>> them - >>>> at the moment, you are scaring off the fence-sitters. >>> >>> Again, you are making a claim about my position without any support. >>> What did I say that was unrealistic? >>> >>> >>>>>> Please, Rick, we /know/ FPGAs are useful devices. But give it a >>>>>> rest? No >>>>>> sane person - not even a Xilinx or Altera salesman - would claim that >>>>>> implementing a Kalman filter is not orders of magnitude harder in an >>>>>> FPGA than in software on a processor with good double precision >>>>>> floating >>>>>> point support. The X and A salesmen will tell you that this is why >>>>>> they >>>>>> put hard ARM cores in their chips - so you can do the PWM, encoders, >>>>>> etc., in FPGA, and the complex maths in the cpu. >>>>> >>>>> If you don't want to have a rational conversation, please don't reply. >>>>> >>>>> If you want to explain why a Kalman filter is so hard in an FPGA, >>>>> please >>>>> do. I'm sure it is not hard to show what part of the algorithm is >>>>> FPGA >>>>> unfriendly. >>>>> >>>> >>>> I haven't implemented a Kalman filter myself, though I trust Tim's >>>> judgement here. But you don't need any experience to look at the >>>> Wikipedia page (or any other webpage or book) and see that this is a >>>> complex algorithm, and is best done step by step. >>> >>> Why does that make it hard in an FPGA? >>> >> >> FPGAs are really good at doing things in parallel, and less good at >> doing things serially. > > I get tired of people making *unsupported* claims. This is a good > example. What about an FPGA makes it "less good" at doing serial > operations? Hmm? Or maybe I misunderstand what the comparison point is > for the "less good" claim. Perhaps you mean FPGAs are less good at > serial computations than FPGAs are at parallel computations. Even that > I can't really see. FPGAs are agnostic about the method, they do serial > or parallel equally well. > First off, are we all happy that FPGAs are really good at doing things in parallel? Secondly, are we all happy that processors are really at doing things serially? They step through a sequence of instructions, doing (usually) one step at a time. The point of contention is how good FPGAs are at doing things serially. When the algorithm is a series of similar steps (such as "do a MAC on this data, then a MAC on that data, etc."), FPGAs are fine - you can write a state machine that handles the steps, along with some logic for end cases. But when you have complicated branching, jumping, subroutines, etc., in your algorithm, then FPGA logic is hard. It is hard to implement, as you have to re-organise the algorithm into a form that the FPGA languages can handle. And all the time you are faced with balances - do you dedicate resources such as DSP blocks to particular tasks, or do you multiplex them across a range of uses? When you need to hold a number of 64-bit variables, do you use logic cells for these? If your algorithm needs a dozen such variables, you quickly lose a a percent or two of your total logic elements here. Or do you put them in a memory block - saving space, but requiring complex logic to address them? When you need complex sequential work, do you write it all out, using all the combinational and sequential logic, spending your resource-limited LUTs on multiplexers, counters, decoders, etc.? Do you implement some sort of state machine interpreter with the steps held in a ROM table? And how do you test and debug all this? An FPGA simulator is great for some things, but not this - you want to be able to single-step the system, read out whatever variables you want, put breakpoints in the code, print out values to a file, etc. When you want to change the code, the programmer changes the code and quickly re-compiles - the FPGA developer needs a much more demanding re-build (and that's assuming there is no need to do the route and place part). Once you get beyond a certain basic level of complexity, sequential work is best done with a sequential processor. > >> Processors are really good at doing things >> serially, and less good at doing them in parallel. > > Other than multicore processors, they don't do things in parallel at > *all*! Processors always execute code sequentially. > "parallel" is just a matter of perception. If a processor does one thing every microsecond, then it does a thousand things every millisecond - just as if it did those thousand things in parallel once per millisecond. You will notice that your PC is quite happy running multiple programs "in parallel" even if it only has one CPU. > >> This is a >> fundamental difference between the two types of computation. Obviously >> you /can/ do things in serial in an FPGA (and you can at least simulate >> parallelism in a cpu), an inherently serial algorithm with lots of >> branches, choices, loops, etc., is most naturally implemented in a >> serial processor. > > Can you explain "natural"? That sounds like a bias. I can't measure > "natural" in any way I know of. > Try /thinking/ rather than /measuring/. FPGAs are Turing complete. So are cellular automata - but they are pretty hopeless for anything other than the type of simulation that is a "natural fit" for that type of computer. The same applies to FPGAs. > >> Add to that the desire for double-precision floating point. Yes, an >> FPGA /can/ do these calculations - but it is much easier to do it in >> software. In software, you write "double a, b, c, d; a = b * c + d;" >> and that's it done - in an FPGA, you design and debug double-precision >> floating point addition and multiplication blocks. > > It is easier to do in software only if someone has done it for you or > you are using a processor where DP FP is done in hardware. Once you > construct your basic DP FP algorithm in an HDL you never need to think > about it again in an FPGA. So no, I don't agree that it is "hard" in an > FPGA. Again, an FPGA is data type agnostic. On processors that have appropriate hardware support, it is easy to do the double precision floating point because the hardware supports it - it is a single line of C code, or a few assembly instructions. On processors that don't have the support, it is /also/ easy to do because it is part of the basic toolchain for the chip (a compliant C compiler /must/ provide it). On an FPGA, you either have to write the FP stuff yourself - taking a great deal of time and effort - or you have to use third-party blocks that are often expensive to buy, and take a lot of resources. A quick check of some IP blocks on Altera's site suggests that double precision floating point takes of the order of 2000 LE's - that is a /massive/ amount when you are using sanely priced devices. It means that you can pretty much forget about structures using dedicated FP blocks for each operation in an algorithm like KF - there simply aren't enough resources on a device. So you have piles of code (and work, testing, debugging, logic resources, etc.) to funnel everything through a few FP blocks. Alternatively, with a big enough FPGA and enough development time, you could probably write optimised FP blocks of different kinds for different parts of the system, and get it all squeezed in. Tell me again how Kalman on an FPGA is /not/ massively harder to implement than doing it in software? > > >>>> What you seem to be missing entirely here is that no one is saying >>>> Kalman filters cannot be implemented on FPGAs - we are saying it is >>>> vastly more difficult to do so. It takes a lot of work to learn to >>>> understand these things, and to test and debug the code step by step. >>>> It is orders of magnitude easier with software that is easy to start >>>> and >>>> stop, debug, view data, print out logs of data, feed with test data, >>>> run >>>> on a PC rather than the target, etc. (And if you think to mention FPGA >>>> "simulation" - or even "co-simulation" - don't bother, for reasons that >>>> are obvious to everyone else. If you want to talk about MyHDL or Lava, >>>> I'll be happy to hear your new ideas.) >>> >>> Yes, they say it is *MUCH* harder to do in an FPGA... without *any* >>> supporting evidence. Your bias is pretty clear from this paragraph >>> alone. You list in detail the software process and then negate without >>> ***any*** evidence the utility of HDL simulation. In fact, you decry it >>> specifically stating that you don't need to provide any evidence because >>> it is "obvious"!!! That is *exactly* the sort of bias I am addressing. >>> >>> Have you done FPGA work? >> >> I haven't done much - but I have done enough to be entirely confident in >> claiming that implementing a Kalman filter in an FPGA would be /much/ >> harder and more time consuming for an FPGA expert than implementing the >> same thing in software would be for a software expert (given equal >> knowledge of the maths, etc.). > > Good, then please explain what aspect of the filter is hard to do in an > FPGA... > See above. > >> I have done enough FPGA work to know that it is certainly /possible/ in >> an FPGA - and that with a good enough FPGA developer it would not be as >> bad as many might think. I think that tools such as MyHDL could make it >> more tractable than traditional Verilog or VHDL. Possibly the most >> efficient way would be to write the code in C, get it all working >> nicely, then use something like Altera's tools for converting C into >> FPGA hardware. But that leaves you with the question of why you should >> bother with the FPGA step at all. > > Or why bother with the C step at all? Why is it hard to code a KF in an > HDL? I keep repeating the question and no one ever answers it. Claims > are made repeatedly, but with *NO* supporting evidence, just more opinion. > See above. Note also that I think most people here agree that it would be significantly to implement KF in an FPGA than in software (even if they might not use the word "nightmare"). Thus it is /you/ who is making the extraordinary claim here, and it is /you/ who need to provide evidence suggesting it is not hard. > >>>> When you have a good, working Kalman implementation in software, and >>>> you >>>> need to run it 100 times faster with little regard for hardware costs - >>> /then/ it is time to break out the FPGA and transfer it over. >>> >>> More bias... this assumes that the *only* utility of an FPGA is to make >>> things run very fast and that FPGA hardware costs are much higher than >>> CPU hardware costs. Really? I have FPGA boards that sell for under >>> $50. I believe the hardware cost the OP talked about was a SBC of some >>> sort which is not likely to be under $50. >>> >> >> You could make a processor card for a great deal less than $50 that will >> do the job - the OP is looking at SBC solutions as a way of minimising >> development costs, not for minimising unit costs. > > Really? The OP said he implemented the algorithm on a standard MCU, the > type you can put on a <$50 PCB and it ran *way* too slow. What > processor card would you use? > In the OP's situation when he only needs a small number of systems, I would probably do as he did and use a big processor (like an SBC) for speed of development. If I wanted to have minimal costs, I would re-implement it with fixed point (which is a minor change, once the algorithm is working, and easy to test and debug) and use a Cortex-M4 for two or three dollars. > >> I know that FPGA's have many uses other than making things run fast - >> but in this case, I don't see any potential benefits for calculating >> Kalman filters other than possibly high speed (for a given price, board >> space, power, etc.). Can /you/ give any other potential benefits? You >> can take it as a given that a microcontroller will be cheaper if unit >> costs are important, since the whole thing could be re-implemented in >> fixed point and run in an ARM for a couple of dollars. > > You have drifted off target. The original issue was the statement that > using FPGAs is a "nightmare". Where did I ever say an FPGA is a better > solution for this KF than using a GP CPU? > > Again, the OP has said that an ARM processor he used was way too slow. > You can get faster ones, but they *aren't* "a couple of dollars". > There are chips that are certainly fast enough for under about $10, even if you stick to DP FP. > >>>>> As to the ARM cores, they are very recent if you look around. So >>>>> it was >>>>> never done until the ARM cores came out? >>>> >>>> Yes, people implemented Kalman filters in FPGAs before there were hard >>>> ARM cores - there were other hard cpu cores before that (PowerPC, and >>>> older weaker ARMs) as well as a multitude of soft cpu cores. And as I >>>> say, it /is/ possible to implement Kalman in "pure" fpga. People >>>> implement these things for a doctoral thesis - while in the pure >>>> software world, people knock them up in a couple of days using software >>>> downloaded from the net. /That/ is the difference. >>> >>> And yet, no one can tell me what aspect of a Kalman filter makes it so >>> hard to implement in an FPGA... >>> >> >> I tried to do so - but you said I had no evidence for the points I made. >> You have no evidence for any counter-arguments, so I guess you either >> believe what people are telling you (and what you can see from web >> searches on Kalman on FPGAs and in software), or you can disagree, or >> you can try and implement them in software and FPGAs for comparison. > > So someone makes a claim that I disagree with, "FPGAs are a nightmare to > use". I ask him why they are a nightmare and you say his statement > stands unless I can prove otherwise.... interesting. > > Your points are equally unsupported that it is hard to implement a KF in > an FPGA. I just want you to tell me what part of a KF is *hard* to > implement on an FPGA, that's all. Just show me the logic that is hard > to do in an FPGA... That should be easy, right? > > My evidence is that I can design any hardware in an FPGA that exists in > any other digital device. So clearly an FPGA can do anything other > devices can do unless you bump up against some limitation such as memory > size or power dissipation, etc. I don't know of anything about FPGAs > that are inherently *hard* to use. But I guess I can't prove the > absence of a fault. > > Is there some reason you can't discuss the facts rather than just opinions? >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-18 16:46 +0100 |
| Message-ID | <RVj_t.107576$6P7.73840@fx26.am4> |
| In reply to | #13691 |
On 18/09/13 16:17, David Brown wrote:
> On 17/09/13 19:22, rickman wrote:
>> Does it really matter to the facts whether I am in the majority or the
>> minority? No. I never said "all", that is *your* word. Give a
>> specific quote for a statement I made that says FPGAs are better for
>> *all* jobs.
>
> If you can't see the issue with your recent posts and your attitude in
> them, then there is little more I can say here. Communication is more
> than the sum of the words you write, and the impression you give is from
> between the lines and general points more than anything specific. Yes,
> you are "guilty" in /my/ mind, and this is /my/ opinion - not the exact
> words you wrote. That's the point - this is the opinion I have formed
> from reading your posts. If I, and at least some others here, were not
> human then perhaps we would have have seen nothing but the technical
> points you made. From your posts in the recent threads, I am left with
> the impression that you are a "all I've got is an FPGA hammer"
> evangelist - and I know that is not true, and I know that is not the
> impression you are trying to give. But it is the impression you /are/
> giving - and I thought you should be told.
I would like to second the above sentiments, with regret.
Why regret? Because Mr Rickman appears to have some useful
expertise and has gone out of his way to be helpful (by
posting here).
The impression I form is that
- Mr Rickman has considerable expertise with FPGAs
and so finds developing solutions using FPGAs easy.
Fair enough.
- Mr Rickman has less expertise outside that area, and
so finds them more difficult - or more difficult to
understand for topics of which he has no experience.
Fair enough.
- Mr Rickman castigates those with less expertise in
FPGAs for thinking they are more difficult to use
And therein lies a certain degree of irony.
> Once you get beyond a certain basic level of complexity, sequential work
> is best done with a sequential processor.
A variant of Amdahl's Law :)
>> Other than multicore processors, they don't do things in parallel at
>> *all*! Processors always execute code sequentially.
Not true for modern processors - where there can be many
independent processors in a single chip.
Anyway, the parallelism argument is not a good argument
for FPGAs. Parallelism can be bought by the application
of $.
*Latency*, however, can be much lower and more predictable
in FPGAs, and can't be bought with $.
In the networking fraternity there's an aphorism:
"bandwidth is determined by dollars, latency is
determined by physics". Same's true at this level too :)
> On processors that have appropriate hardware support, it is easy to do
> the double precision floating point because the hardware supports it -
> it is a single line of C code, or a few assembly instructions. On
> processors that don't have the support, it is /also/ easy to do because
> it is part of the basic toolchain for the chip (a compliant C compiler
> /must/ provide it).
With DSP algorithms, better edge-of-envelope performance
can sometimes be obtained by "clipping" fixed point values
when they go out of range. (It always amazes me how much
clipping some types of spread spectrum systems can tolerate
without loss of performance. Sometimes it feels like the
front-ends only need one or two bits!)
How is fixed-point "clipping" specified within a C program
or library? (Bog-standard C allows silent overflows, of
course)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-18 09:16 -0700 |
| Message-ID | <7xy56unm02.fsf@ruckus.brouhaha.com> |
| In reply to | #13694 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > With DSP algorithms, better edge-of-envelope performance > can sometimes be obtained by "clipping" fixed point values I think in the case of the Kalman filter, this would be either unworkable or highly suspicious. If the KF were being used for anything important, some serious mathematical justification would be warranted before going ahead with such an approach. > How is fixed-point "clipping" specified within a C program > or library? You'd use intrinsics for saturating arithmetic if your CPU supported it. For example, the XMM instructions on the x86, or comparable multimedia instructions on the fancy ARM's.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-18 14:13 -0400 |
| Message-ID | <l1cqg1$74t$1@dont-email.me> |
| In reply to | #13694 |
On 9/18/2013 11:46 AM, Tom Gardner wrote: > > Why regret? Because Mr Rickman appears to have some useful > expertise and has gone out of his way to be helpful (by > posting here). > > The impression I form is that > - Mr Rickman has considerable expertise with FPGAs > and so finds developing solutions using FPGAs easy. > Fair enough. > - Mr Rickman has less expertise outside that area, and > so finds them more difficult - or more difficult to > understand for topics of which he has no experience. > Fair enough. Not really fair. I have experience with MCUs and even PC programming. I will admit I am not current in the technology however as I have gone over to the "dark" side... I program in Forth now. I don't find software very hard to understand and I don't find it *difficult* at all. > - Mr Rickman castigates those with less expertise in > FPGAs for thinking they are more difficult to use > And therein lies a certain degree of irony. Hmmm... castigate sounds like a loaded word... I am simply disputing the point stated that implementing a Kalman Filter with an FPGA would be "a nightmare". I maintain that FPGAs are largely as easy to use as MCUs and CPUs, but that they are less well understood and appreciated by those who are making the statements about how hard they are to use. Is that what you mean by "castigate? >> Once you get beyond a certain basic level of complexity, sequential work >> is best done with a sequential processor. > > A variant of Amdahl's Law :) > > >>> Other than multicore processors, they don't do things in parallel at >>> *all*! Processors always execute code sequentially. > > Not true for modern processors - where there can be many > independent processors in a single chip. I've already excepted the multi-core chips elsewhere. > Anyway, the parallelism argument is not a good argument > for FPGAs. Parallelism can be bought by the application > of $. > > *Latency*, however, can be much lower and more predictable > in FPGAs, and can't be bought with $. > > In the networking fraternity there's an aphorism: > "bandwidth is determined by dollars, latency is > determined by physics". Same's true at this level too :) I am not trying to debate the issue of what is the best way to solve problem X. I am simply trying to get people to understand that FPGAs are not a "nightmare" to use. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-18 20:00 +0100 |
| Message-ID | <hLm_t.59870$ei6.1026@fx08.am4> |
| In reply to | #13705 |
On 18/09/13 19:13, rickman wrote:
> On 9/18/2013 11:46 AM, Tom Gardner wrote:
>>
>> Why regret? Because Mr Rickman appears to have some useful
>> expertise and has gone out of his way to be helpful (by
>> posting here).
>>
>> The impression I form is that
>> - Mr Rickman has considerable expertise with FPGAs
>> and so finds developing solutions using FPGAs easy.
>> Fair enough.
>> - Mr Rickman has less expertise outside that area, and
>> so finds them more difficult - or more difficult to
>> understand for topics of which he has no experience.
>> Fair enough.
>
> Not really fair. I have experience with MCUs and even PC programming. I will admit I am not current in the technology however as I have gone over to the "dark" side... I program in Forth now. I
> don't find software very hard to understand and I don't find it *difficult* at all.
I'm sure that's true for some classes of software,
and equally sure not for others such as application
frameworks (J2EE/JAIN etc), distributed caches,
enterprise service busses, map-reduce frameworks,
ACID and non-ACID databases, software transactional
memory, CORBA, webservices, REST, AJAX and so on.
Mind you, many of the people that program the "beans"
etc in those environments have vanishing little concept
even of what a compiler emits.
I'm sure it would be more successful teaching "low-level"
people like us about enterprise stuff than vice versa.
>> - Mr Rickman castigates those with less expertise in
>> FPGAs for thinking they are more difficult to use
>> And therein lies a certain degree of irony.
>
> Hmmm... castigate sounds like a loaded word... I am simply disputing the point stated that implementing a Kalman Filter with an FPGA would be "a nightmare". I maintain that FPGAs are largely as easy
> to use as MCUs and CPUs, but that they are less well understood and appreciated by those who are making the statements about how hard they are to use.
Your statements have been interpreted by many in your
audience as being far wider ranging and black-and-white
than that.
Having seen the problems "average" s/w bodies have with
basic concepts such as state machines ("they're something
to do with parsing languages, aren't they?"), I believe
most software people will have more problems with casting
their problems into FPGAs than hardware people casting
them into software.
> I am not trying to debate the issue of what is the best way to solve problem X. I am simply trying to get people to understand that FPGAs are not a "nightmare" to use.
That's a fair objective, but you have (IMNSHO) over-egged your
argument.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2013-09-18 19:56 -0500 |
| Message-ID | <l1dhsu$cq7$1@dont-email.me> |
| In reply to | #13707 |
Tom Gardner wrote:
> On 18/09/13 19:13, rickman wrote:
>> On 9/18/2013 11:46 AM, Tom Gardner wrote:
>>>
>>> Why regret? Because Mr Rickman appears to have some useful
>>> expertise and has gone out of his way to be helpful (by
>>> posting here).
>>>
>>> The impression I form is that
>>> - Mr Rickman has considerable expertise with FPGAs
>>> and so finds developing solutions using FPGAs easy.
>>> Fair enough.
>>> - Mr Rickman has less expertise outside that area, and
>>> so finds them more difficult - or more difficult to
>>> understand for topics of which he has no experience.
>>> Fair enough.
>>
>> Not really fair. I have experience with MCUs and even PC programming.
>> I will admit I am not current in the technology however as I have gone
>> over to the "dark" side... I program in Forth now. I
>> don't find software very hard to understand and I don't find it
>> *difficult* at all.
>
> I'm sure that's true for some classes of software,
> and equally sure not for others such as application
> frameworks (J2EE/JAIN etc), distributed caches,
> enterprise service busses, map-reduce frameworks,
> ACID and non-ACID databases, software transactional
> memory, CORBA, webservices, REST, AJAX and so on.
>
> Mind you, many of the people that program the "beans"
> etc in those environments have vanishing little concept
> even of what a compiler emits.
>
> I'm sure it would be more successful teaching "low-level"
> people like us about enterprise stuff than vice versa.
>
"enterprise stuff" is lots and lots and lots of disparately
operated cruft. Each morning in the class I took, we watched
while the instructor updated *everything*. Frequently, this broke
things. there was no apparent packaging to cohere
layers beyond marked releases of packages. *Everything( was a
beta.
After lunch, we'd pick up where we left off...
It's amazing it works at all. And when pressed about
the transaction rate on a box store level desktop,
I was shocked to learn that they expect no more than a hundred
transactions per second.
>
>>> - Mr Rickman castigates those with less expertise in
>>> FPGAs for thinking they are more difficult to use
>>> And therein lies a certain degree of irony.
>>
>> Hmmm... castigate sounds like a loaded word... I am simply disputing
>> the point stated that implementing a Kalman Filter with an FPGA would
>> be "a nightmare". I maintain that FPGAs are largely as easy
>> to use as MCUs and CPUs, but that they are less well understood and
>> appreciated by those who are making the statements about how hard they
>> are to use.
>
> Your statements have been interpreted by many in your
> audience as being far wider ranging and black-and-white
> than that.
>
> Having seen the problems "average" s/w bodies have with
> basic concepts such as state machines ("they're something
> to do with parsing languages, aren't they?"), I believe
> most software people will have more problems with casting
> their problems into FPGAs than hardware people casting
> them into software.
>
I dunno. They are all different. It's gotten so that the word
"problem" means different things in different shops
doing what appears to be the same thing.
>
>> I am not trying to debate the issue of what is the best way to solve
>> problem X. I am simply trying to get people to understand that FPGAs
>> are not a "nightmare" to use.
>
> That's a fair objective, but you have (IMNSHO) over-egged your
> argument.
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-19 09:56 +0100 |
| Message-ID | <7%y_t.85473$rR5.54088@fx27.am4> |
| In reply to | #13716 |
On 19/09/13 01:56, Les Cargill wrote: > Tom Gardner wrote: >> On 18/09/13 19:13, rickman wrote: >>> On 9/18/2013 11:46 AM, Tom Gardner wrote: >>>> >>>> Why regret? Because Mr Rickman appears to have some useful >>>> expertise and has gone out of his way to be helpful (by >>>> posting here). >>>> >>>> The impression I form is that >>>> - Mr Rickman has considerable expertise with FPGAs >>>> and so finds developing solutions using FPGAs easy. >>>> Fair enough. >>>> - Mr Rickman has less expertise outside that area, and >>>> so finds them more difficult - or more difficult to >>>> understand for topics of which he has no experience. >>>> Fair enough. >>> >>> Not really fair. I have experience with MCUs and even PC programming. >>> I will admit I am not current in the technology however as I have gone >>> over to the "dark" side... I program in Forth now. I >>> don't find software very hard to understand and I don't find it >>> *difficult* at all. >> >> I'm sure that's true for some classes of software, >> and equally sure not for others such as application >> frameworks (J2EE/JAIN etc), distributed caches, >> enterprise service busses, map-reduce frameworks, >> ACID and non-ACID databases, software transactional >> memory, CORBA, webservices, REST, AJAX and so on. >> >> Mind you, many of the people that program the "beans" >> etc in those environments have vanishing little concept >> even of what a compiler emits. >> >> I'm sure it would be more successful teaching "low-level" >> people like us about enterprise stuff than vice versa. >> > > "enterprise stuff" is lots and lots and lots of disparately > operated cruft. Unlike hardware? :) > Each morning in the class I took, we watched > while the instructor updated *everything*. Frequently, this broke > things. there was no apparent packaging to cohere > layers beyond marked releases of packages. *Everything( was a > beta. There is actually method in that madness: it is better acknowledge that re-integration will always break things and to have mentalities and processes to deal with that reality. Little breaks -> little repairs. The alternative is to have infrequent massive integrations with consequent massive problems and huge repairs. > After lunch, we'd pick up where we left off... There's a balance to be struck, depending on the objectives. If the objective was to teach, then it looks like they struck the wrong balance! > It's amazing it works at all. And when pressed about > the transaction rate on a box store level desktop, > I was shocked to learn that they expect no more than a hundred > transactions per second. In fairness, scalability and reliability requirements do take a toll! If everything can be done in one box the transaction rate can rise impressively. Replace "box" with "chip", and an analogous point can be made in the hardware/embedded arena! What always amused me was the layering of synchronous comms protocols on asynchronous comms protocols on synchronous comms protocols on asynchronous comms protocols on synchronous comms protocols on asynchronous comms protocols on... You get the drift :)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-18 14:01 -0400 |
| Message-ID | <l1cppd$2q9$1@dont-email.me> |
| In reply to | #13691 |
On 9/18/2013 11:17 AM, David Brown wrote: > On 17/09/13 19:22, rickman wrote: >> On 9/17/2013 5:42 AM, David Brown wrote: >>> >>> FPGAs are really good at doing things in parallel, and less good at >>> doing things serially. >> >> I get tired of people making *unsupported* claims. This is a good >> example. What about an FPGA makes it "less good" at doing serial >> operations? Hmm? Or maybe I misunderstand what the comparison point is >> for the "less good" claim. Perhaps you mean FPGAs are less good at >> serial computations than FPGAs are at parallel computations. Even that >> I can't really see. FPGAs are agnostic about the method, they do serial >> or parallel equally well. >> > > First off, are we all happy that FPGAs are really good at doing things > in parallel? > > Secondly, are we all happy that processors are really at doing things > serially? They step through a sequence of instructions, doing (usually) > one step at a time. > > The point of contention is how good FPGAs are at doing things serially. > > When the algorithm is a series of similar steps (such as "do a MAC on > this data, then a MAC on that data, etc."), FPGAs are fine - you can > write a state machine that handles the steps, along with some logic for > end cases. > > But when you have complicated branching, jumping, subroutines, etc., in > your algorithm, then FPGA logic is hard. It is hard to implement, as > you have to re-organise the algorithm into a form that the FPGA > languages can handle. Ok, a *factual* statement that can be discussed, even if it is unsupported. You make a claim that you have to reorganize the algorithm to suit HDLs. What aspect of HLLs is missing from HDL? They include conditionals, looping, branching, etc. Why is it hard to implement any aspect of an algorithm in an HDL? > And all the time you are faced with balances - do > you dedicate resources such as DSP blocks to particular tasks, or do you > multiplex them across a range of uses? When you need to hold a number > of 64-bit variables, do you use logic cells for these? If your > algorithm needs a dozen such variables, you quickly lose a a percent or > two of your total logic elements here. Or do you put them in a memory > block - saving space, but requiring complex logic to address them? When > you need complex sequential work, do you write it all out, using all the > combinational and sequential logic, spending your resource-limited LUTs > on multiplexers, counters, decoders, etc.? Do you implement some sort > of state machine interpreter with the steps held in a ROM table? Why is this significantly different from software? The fact that there are multiple types of resources? Software has the same issues. Do you put the 64 bit variables on the stack dynamically or allocate static memory? Software can be implemented in many, many ways as well and that is where experience comes in. Many people have lots of experience with software and are comfortable with these trade offs. So comfortable that they don't even see them as issues... such as in your case apparently. > And how do you test and debug all this? An FPGA simulator is great for > some things, but not this - you want to be able to single-step the > system, read out whatever variables you want, put breakpoints in the > code, print out values to a file, etc. When you want to change the > code, the programmer changes the code and quickly re-compiles - the FPGA > developer needs a much more demanding re-build (and that's assuming > there is no need to do the route and place part). Why can't you single step the system in a simulator? Actually, it is better if you don't. If you had more familiarity with the simulators used for HDL design you would realize that they work very much like software debuggers but with a significant advantage (at least to me) of in addition to all the standard information displays of memory, signals, etc., being very visual, showing graphs of the signals changing over time. I can run a simulation and go forwards and backwards in time to see what caused a given result. Single stepping is great, but it is hard to go back to an earlier time. > Once you get beyond a certain basic level of complexity, sequential work > is best done with a sequential processor. ...no comment... >>> Processors are really good at doing things >>> serially, and less good at doing them in parallel. >> >> Other than multicore processors, they don't do things in parallel at >> *all*! Processors always execute code sequentially. >> > > "parallel" is just a matter of perception. If a processor does one > thing every microsecond, then it does a thousand things every > millisecond - just as if it did those thousand things in parallel once > per millisecond. You will notice that your PC is quite happy running > multiple programs "in parallel" even if it only has one CPU. It is not a mater of perception when you are writing the software. Implementing virtual parallelism on a sequential processor requires a lot of additional work somewhere, buy someone. Much of it may have been done for you, but if your app needs to use that parallelism, you need to address that in ways which are unique to this situation. When things are *actually* run in parallel this all goes away. >>> This is a >>> fundamental difference between the two types of computation. Obviously >>> you /can/ do things in serial in an FPGA (and you can at least simulate >>> parallelism in a cpu), an inherently serial algorithm with lots of >>> branches, choices, loops, etc., is most naturally implemented in a >>> serial processor. >> >> Can you explain "natural"? That sounds like a bias. I can't measure >> "natural" in any way I know of. >> > > Try /thinking/ rather than /measuring/. The point is that "natural" has no meaning, in food or in this discussion, unless you give it one. I'm asking for the meaning you intended. > FPGAs are Turing complete. So are cellular automata - but they are > pretty hopeless for anything other than the type of simulation that is a > "natural fit" for that type of computer. The same applies to FPGAs. This statement is accurate and has no bias. But it says nothing about what the "natural fit" is for FPGAs. >>> Add to that the desire for double-precision floating point. Yes, an >>> FPGA /can/ do these calculations - but it is much easier to do it in >>> software. In software, you write "double a, b, c, d; a = b * c + d;" >>> and that's it done - in an FPGA, you design and debug double-precision >>> floating point addition and multiplication blocks. >> >> It is easier to do in software only if someone has done it for you or >> you are using a processor where DP FP is done in hardware. Once you >> construct your basic DP FP algorithm in an HDL you never need to think >> about it again in an FPGA. So no, I don't agree that it is "hard" in an >> FPGA. Again, an FPGA is data type agnostic. > > On processors that have appropriate hardware support, it is easy to do > the double precision floating point because the hardware supports it - > it is a single line of C code, or a few assembly instructions. On > processors that don't have the support, it is /also/ easy to do because > it is part of the basic toolchain for the chip (a compliant C compiler > /must/ provide it). Yes, I believe that is what I wrote above, but in more detail. > On an FPGA, you either have to write the FP stuff yourself - taking a > great deal of time and effort - or you have to use third-party blocks > that are often expensive to buy, and take a lot of resources. A quick > check of some IP blocks on Altera's site suggests that double precision > floating point takes of the order of 2000 LE's - that is a /massive/ > amount when you are using sanely priced devices. Unless you use the dedicated multipliers as they are intended. > It means that you can > pretty much forget about structures using dedicated FP blocks for each > operation in an algorithm like KF - there simply aren't enough resources > on a device. So you have piles of code (and work, testing, debugging, > logic resources, etc.) to funnel everything through a few FP blocks. > Alternatively, with a big enough FPGA and enough development time, you > could probably write optimised FP blocks of different kinds for > different parts of the system, and get it all squeezed in. > > Tell me again how Kalman on an FPGA is /not/ massively harder to > implement than doing it in software? I don't see what is difficult and you have not explained it. You are trying to make a point that FPGAs are poor at decision making, which is not true. You have tried to make a point that FPGAs are poor at floating point, which is not true. >>>> Have you done FPGA work? >>> >>> I haven't done much - but I have done enough to be entirely confident in >>> claiming that implementing a Kalman filter in an FPGA would be /much/ >>> harder and more time consuming for an FPGA expert than implementing the >>> same thing in software would be for a software expert (given equal >>> knowledge of the maths, etc.). >> >> Good, then please explain what aspect of the filter is hard to do in an >> FPGA... >> > > See above. Ok, I think this sums it up. You have done just enough FPGA work to appreciate that it is not the same as coding in an HLL, but clearly you have not become proficient in it. More importantly, I think you are a bit stuck in the sequential code mindset. This might not be a problem using FPGAs, but it is nice if you open up a little more and see the full capabilities. I once gave some free advice to a software guy who had been tasked by his company with porting a design to an FPGA. I forget the details but he wanted to start out with a "hello world" program. A number of us advised him that this was not so simple a task in an FPGA, but he motored on and proved us wrong. With just a little coaching he was able to complete his task an I was not able to turn it into a consulting gig. He was rather grateful for my support and convinced his employer to send me a $500 check. So clearly if you are open to what can be done with an FPGA, they aren't so hard to use after all. >>> I have done enough FPGA work to know that it is certainly /possible/ in >>> an FPGA - and that with a good enough FPGA developer it would not be as >>> bad as many might think. I think that tools such as MyHDL could make it >>> more tractable than traditional Verilog or VHDL. Possibly the most >>> efficient way would be to write the code in C, get it all working >>> nicely, then use something like Altera's tools for converting C into >>> FPGA hardware. But that leaves you with the question of why you should >>> bother with the FPGA step at all. >> >> Or why bother with the C step at all? Why is it hard to code a KF in an >> HDL? I keep repeating the question and no one ever answers it. Claims >> are made repeatedly, but with *NO* supporting evidence, just more opinion. >> > > See above. > > Note also that I think most people here agree that it would be > significantly to implement KF in an FPGA than in software (even if they > might not use the word "nightmare"). Thus it is /you/ who is making the > extraordinary claim here, and it is /you/ who need to provide evidence > suggesting it is not hard. Ok, I won't dispute that for many users, FPGA design is harder than software. My statement was that calling it a "nightmare" is inaccurate. I have provided plenty of evidence and you have as well. You said that FPGAs are Turing complete. HDLs are as well. They are also very facile (if you don't mind strong typing in the case of VHDL) and the debug tools are excellent. What more do you want? >>>>> When you have a good, working Kalman implementation in software, and >>>>> you >>>>> need to run it 100 times faster with little regard for hardware costs - >>>> /then/ it is time to break out the FPGA and transfer it over. >>>> >>>> More bias... this assumes that the *only* utility of an FPGA is to make >>>> things run very fast and that FPGA hardware costs are much higher than >>>> CPU hardware costs. Really? I have FPGA boards that sell for under >>>> $50. I believe the hardware cost the OP talked about was a SBC of some >>>> sort which is not likely to be under $50. >>>> >>> >>> You could make a processor card for a great deal less than $50 that will >>> do the job - the OP is looking at SBC solutions as a way of minimising >>> development costs, not for minimising unit costs. >> >> Really? The OP said he implemented the algorithm on a standard MCU, the >> type you can put on a<$50 PCB and it ran *way* too slow. What >> processor card would you use? >> > > In the OP's situation when he only needs a small number of systems, I > would probably do as he did and use a big processor (like an SBC) for > speed of development. If I wanted to have minimal costs, I would > re-implement it with fixed point (which is a minor change, once the > algorithm is working, and easy to test and debug) and use a Cortex-M4 > for two or three dollars. The OP tested the algorithm on an ARM and said it wasn't fast enough. I seriously doubt that you would be able to run it adequately on a $3 ARM since that would be the low, slow end of ARM devices. I'm pretty sure you would have a hard time getting hardware floating point on a $3 device much less double precision. BTW, by the time you add all the support circuity and put it on a board, that $3 chip will have a retail cost of $50 or close to it. >>> I know that FPGA's have many uses other than making things run fast - >>> but in this case, I don't see any potential benefits for calculating >>> Kalman filters other than possibly high speed (for a given price, board >>> space, power, etc.). Can /you/ give any other potential benefits? You >>> can take it as a given that a microcontroller will be cheaper if unit >>> costs are important, since the whole thing could be re-implemented in >>> fixed point and run in an ARM for a couple of dollars. >> >> You have drifted off target. The original issue was the statement that >> using FPGAs is a "nightmare". Where did I ever say an FPGA is a better >> solution for this KF than using a GP CPU? >> >> Again, the OP has said that an ARM processor he used was way too slow. >> You can get faster ones, but they *aren't* "a couple of dollars". >> > > There are chips that are certainly fast enough for under about $10, even > if you stick to DP FP. How long is a piece of sting? We can't really say what the OP's algorithm will run on specifically, can we? Although he did say something about wanting 1 MFLOPS IIRC. You might be able to run that on a $35 raspberry Pi. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 11 of 22 — ← Prev page 1 … 9 10 [11] 12 13 … 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web