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 21 of 22 — ← Prev page 1 … 19 20 [21] 22 Next page →
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-17 10:13 +0100 |
| Message-ID | <Q2VZt.101418$Mw4.9829@fx15.am4> |
| In reply to | #13598 |
On 15/09/13 18:58, Tim Wescott wrote:
> Every single time I've seen an algorithm implemented on an FPGA -- and by
> some pretty damned smart FPGA people I might add -- it's taken about ten
> times more calendar time and engineering effort to get it going than to
> do the same damned thing with software.
Partially agree. It mainly depends on the algorithm and the
contraints, particularly speed and parallelism. Horses for courses.
> When they were done, every time
> a change was necessary it took ten times longer to implement the change
> than if the algorithm were implemented in software.
Disagree. Software can be extraordinarily resistant
to change, particularly if it is pushing limits or no one
person understands it all.
Think of programming an FPGA as being similar to large-scale
enterprise software: there's a lot going on invisibly "under
the hood" that the developer simply has to take on trust.
For FPGAs it is things like the design tools, place and route,
timing and clock distribution.
For enterprise software it is things like the software
frameworks (e.g. J2EE etc), individual components (e.g. beans)
being correctly "wired up", distributed caches (hardware and
software), ACID properties.
Changing an enterprise framework is equivalent to changing
an FPGA family: you do it as often as you change house.
I won't bother to draw the analogy with hard real-time software
since this groups is probably aware of its characteristics.
> I've done a bit of FPGA work myself, too. While I can't claim to be an
> expert, what I've done backs up my impression that making things work on
> an FPGA requires a higher level of attention to more necessary details
> than assembly language programming does.
Disagree. They are equivalent.
> So as far as I'm concerned, FPGAs are there for when there's not a
> suitable processor that's fast enough to haul the freight.
Agree strongly. Here "fast" means any of
- latency
- parallelism
- raw number crunching
> My point about PCs having processors instead of FPGAs, is that if FPGAs
> were so easy and handy to use, that's what we'd be using. But we don't
> -- we use processors, unless we have to.
Agree strongly. Embedded micros were initially marketed and
sold as "programmable logic", but they later outgrew their boots.
The tradition continues; have a look at the XMOS processors
(available from Digikey for a few bucks) that provide *hard*
realtime timing guarantees and DSP performance even though
they are programmed in C.
http://www.xmos.com/en/products/why/determinism
They are encroaching into the FPGA design space.
Anyone that can't accept "horses for courses" is a mere fanatic:
"A fanatic is one who can't change his mind and won't
change the subject."
Winston Churchill
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-17 05:56 -0400 |
| Message-ID | <l19932$lo5$1@dont-email.me> |
| In reply to | #13660 |
On 9/17/2013 5:13 AM, Tom Gardner wrote: > On 15/09/13 18:58, Tim Wescott wrote: >> I've done a bit of FPGA work myself, too. While I can't claim to be an >> expert, what I've done backs up my impression that making things work on >> an FPGA requires a higher level of attention to more necessary details >> than assembly language programming does. > > Disagree. They are equivalent. I don't agree at all. You can program an FPGA in an HDL with a high level of abstraction. Like using an HLL at a high level of abstraction you may not get the best efficiency, but it will run your code just fine. Or you can design with an HDL at a lower level trying to control the implementation for efficiency or speed. That is when HDL programming can be more time consuming... but that is due to the optimizations which applies to *any* design methodology. >> So as far as I'm concerned, FPGAs are there for when there's not a >> suitable processor that's fast enough to haul the freight. > > Agree strongly. Here "fast" means any of > - latency > - parallelism > - raw number crunching I don't agree at all. Here is an FPGA that was used because it was the best fit to the job. Actually it was a speed issue, but nothing like you are referring to. An MCU was excluded because there were none which could provide the flexibility to implement the appropriate interfaces, one was 30 MHz, similar to SPI. http://arius.com/images/IRIGB_board_1-0.png The calculations were actually very slow even by MCU standards. An 8 kHz sample rate at the ADC, detection of the amplitude envelope, rate reduced to 1 kHz, bit width detected and down sampled to 100 Hz. Hardly overwhelming to even an 8051. The FPGA also allowed for design upgrades for later work with none of the limitations of MCUs. >> My point about PCs having processors instead of FPGAs, is that if FPGAs >> were so easy and handy to use, that's what we'd be using. But we don't >> -- we use processors, unless we have to. > > Agree strongly. Embedded micros were initially marketed and > sold as "programmable logic", but they later outgrew their boots. > > The tradition continues; have a look at the XMOS processors > (available from Digikey for a few bucks) that provide *hard* > realtime timing guarantees and DSP performance even though > they are programmed in C. > http://www.xmos.com/en/products/why/determinism > > They are encroaching into the FPGA design space. I think the XMOS devices are a tempest in a teapot. Can you give examples of how they have "encroached"? I would bet they don't have even 1% the market size of FPGAs. > Anyone that can't accept "horses for courses" is a mere fanatic: > "A fanatic is one who can't change his mind and won't > change the subject." > Winston Churchill Who has disagreed with "horses for courses"? This discussion started talking about FPGAs being a "nightmare" to work with and only suitable for the rare situation where they were absolutely required. My point is that most people are working under impressions formed more than 10 years ago. FPGAs have changed since the 90's. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-17 11:37 +0100 |
| Message-ID | <RhWZt.67790$fc3.15476@fx21.am4> |
| In reply to | #13663 |
On 17/09/13 10:56, rickman wrote: > On 9/17/2013 5:13 AM, Tom Gardner wrote: >> On 15/09/13 18:58, Tim Wescott wrote: >>> I've done a bit of FPGA work myself, too. While I can't claim to be an >>> expert, what I've done backs up my impression that making things work on >>> an FPGA requires a higher level of attention to more necessary details >>> than assembly language programming does. >> >> Disagree. They are equivalent. > > I don't agree at all. You can program an FPGA in an HDL with a high level of abstraction. Like using an HLL at a high level of abstraction you may not get the best efficiency, but it will run your > code just fine. Or you can design with an HDL at a lower level trying to control the implementation for efficiency or speed. That is when HDL programming can be more time consuming... but that is > due to the optimizations which applies to *any* design methodology. You haven't read/understood the point to which I was replying. >>> So as far as I'm concerned, FPGAs are there for when there's not a >>> suitable processor that's fast enough to haul the freight. >> >> Agree strongly. Here "fast" means any of >> - latency >> - parallelism >> - raw number crunching > > I don't agree at all. Here is an FPGA that was used because it was the best fit to the job. Actually it was a speed issue, but nothing like you are referring to. An MCU was excluded because there > were none which could provide the flexibility to implement the appropriate interfaces, one was 30 MHz, similar to SPI. > > http://arius.com/images/IRIGB_board_1-0.png > > The calculations were actually very slow even by MCU standards. An 8 kHz sample rate at the ADC, detection of the amplitude envelope, rate reduced to 1 kHz, bit width detected and down sampled to 100 > Hz. Hardly overwhelming to even an 8051. > > The FPGA also allowed for design upgrades for later work with none of the limitations of MCUs. You haven't read/understood the point to which I was replying. I'm sure there are correct and valid anecdotes that support any position. You can use a hammer to put in a screw, and professionals frequently do so, except for the last quarter turn :) >>> My point about PCs having processors instead of FPGAs, is that if FPGAs >>> were so easy and handy to use, that's what we'd be using. But we don't >>> -- we use processors, unless we have to. >> >> Agree strongly. Embedded micros were initially marketed and >> sold as "programmable logic", but they later outgrew their boots. >> >> The tradition continues; have a look at the XMOS processors >> (available from Digikey for a few bucks) that provide *hard* >> realtime timing guarantees and DSP performance even though >> they are programmed in C. >> http://www.xmos.com/en/products/why/determinism >> >> They are encroaching into the FPGA design space. > > I think the XMOS devices are a tempest in a teapot. Can you give examples of how they have "encroached"? I would bet they don't have even 1% the market size of FPGAs. I don't think you understand what "encroaching" does and doesn't imply. Market size is irrelevant to the point being made. As for examples, read their website. >> Anyone that can't accept "horses for courses" is a mere fanatic: >> "A fanatic is one who can't change his mind and won't >> change the subject." >> Winston Churchill > > Who has disagreed with "horses for courses"? This discussion started talking about FPGAs being a "nightmare" to work with and only suitable for the rare situation where they were absolutely required. The conversation has veered in several directions. Do you feel the comment is specifically relevant to you alone? > My point is that most people are working under impressions formed more than 10 years ago. FPGAs have changed since the 90's. No argument there. But so have MCUs. In general can I suggest you read a little more slowly, and take a coffee break before replying.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-17 16:00 -0400 |
| Message-ID | <l1acdh$dap$1@dont-email.me> |
| In reply to | #13664 |
On 9/17/2013 6:37 AM, Tom Gardner wrote: > On 17/09/13 10:56, rickman wrote: >> On 9/17/2013 5:13 AM, Tom Gardner wrote: >>> On 15/09/13 18:58, Tim Wescott wrote: >>>> I've done a bit of FPGA work myself, too. While I can't claim to be an >>>> expert, what I've done backs up my impression that making things >>>> work on >>>> an FPGA requires a higher level of attention to more necessary details >>>> than assembly language programming does. >>> >>> Disagree. They are equivalent. >> >> I don't agree at all. You can program an FPGA in an HDL with a high >> level of abstraction. Like using an HLL at a high level of abstraction >> you may not get the best efficiency, but it will run your >> code just fine. Or you can design with an HDL at a lower level trying >> to control the implementation for efficiency or speed. That is when >> HDL programming can be more time consuming... but that is >> due to the optimizations which applies to *any* design methodology. > > You haven't read/understood the point to which I was replying. I read what you wrote and I acknowledge that I may not fully understand it. You used terms like, "large-scale enterprise software" which I am not familiar with. What is that supposed to mean? "For FPGAs it is things like the design tools, place and route, timing and clock distribution. " What does that mean? What is "it"? BTW, the part you responded to I was only replying to your words I quoted. I thought you were saying HDL coding is equivalent to assembly language coding. Is that not correct? >>>> So as far as I'm concerned, FPGAs are there for when there's not a >>>> suitable processor that's fast enough to haul the freight. >>> >>> Agree strongly. Here "fast" means any of >>> - latency >>> - parallelism >>> - raw number crunching >> >> I don't agree at all. Here is an FPGA that was used because it was the >> best fit to the job. Actually it was a speed issue, but nothing like >> you are referring to. An MCU was excluded because there >> were none which could provide the flexibility to implement the >> appropriate interfaces, one was 30 MHz, similar to SPI. >> >> http://arius.com/images/IRIGB_board_1-0.png >> >> The calculations were actually very slow even by MCU standards. An 8 >> kHz sample rate at the ADC, detection of the amplitude envelope, rate >> reduced to 1 kHz, bit width detected and down sampled to 100 >> Hz. Hardly overwhelming to even an 8051. >> >> The FPGA also allowed for design upgrades for later work with none of >> the limitations of MCUs. > > You haven't read/understood the point to which I was replying. > > I'm sure there are correct and valid anecdotes that support any > position. You can use a hammer to put in a screw, and professionals > frequently do so, except for the last quarter turn :) > > >>>> My point about PCs having processors instead of FPGAs, is that if FPGAs >>>> were so easy and handy to use, that's what we'd be using. But we don't >>>> -- we use processors, unless we have to. >>> >>> Agree strongly. Embedded micros were initially marketed and >>> sold as "programmable logic", but they later outgrew their boots. >>> >>> The tradition continues; have a look at the XMOS processors >>> (available from Digikey for a few bucks) that provide *hard* >>> realtime timing guarantees and DSP performance even though >>> they are programmed in C. >>> http://www.xmos.com/en/products/why/determinism >>> >>> They are encroaching into the FPGA design space. >> >> I think the XMOS devices are a tempest in a teapot. Can you give >> examples of how they have "encroached"? I would bet they don't have >> even 1% the market size of FPGAs. > > I don't think you understand what "encroaching" > does and doesn't imply. Market size is irrelevant > to the point being made. As for examples, read > their website. Please explain. >>> Anyone that can't accept "horses for courses" is a mere fanatic: >>> "A fanatic is one who can't change his mind and won't >>> change the subject." >>> Winston Churchill >> >> Who has disagreed with "horses for courses"? This discussion started >> talking about FPGAs being a "nightmare" to work with and only suitable >> for the rare situation where they were absolutely required. > > The conversation has veered in several directions. > > Do you feel the comment is specifically relevant to you alone? > > >> My point is that most people are working under impressions formed more >> than 10 years ago. FPGAs have changed since the 90's. > > No argument there. But so have MCUs. I would be interested in hearing how MCU development has changed. Care to elaborate? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-17 21:30 +0100 |
| Message-ID | <RZ2_t.88940$wR4.11820@fx30.am4> |
| In reply to | #13678 |
On 17/09/13 21:00, rickman wrote: > On 9/17/2013 6:37 AM, Tom Gardner wrote: >> On 17/09/13 10:56, rickman wrote: >>> On 9/17/2013 5:13 AM, Tom Gardner wrote: >>>> On 15/09/13 18:58, Tim Wescott wrote: >>>>> I've done a bit of FPGA work myself, too. While I can't claim to be an >>>>> expert, what I've done backs up my impression that making things >>>>> work on >>>>> an FPGA requires a higher level of attention to more necessary details >>>>> than assembly language programming does. >>>> >>>> Disagree. They are equivalent. >>> >>> I don't agree at all. You can program an FPGA in an HDL with a high >>> level of abstraction. Like using an HLL at a high level of abstraction >>> you may not get the best efficiency, but it will run your >>> code just fine. Or you can design with an HDL at a lower level trying >>> to control the implementation for efficiency or speed. That is when >>> HDL programming can be more time consuming... but that is >>> due to the optimizations which applies to *any* design methodology. >> >> You haven't read/understood the point to which I was replying. > > I read what you wrote and I acknowledge that I may not fully understand it. You used terms like, "large-scale enterprise software" which I am not familiar with. What is that supposed to mean? That's because you snipped it from my message. Hint: read the paragraph beginning "For enterprise software..." Another example of you needing to read more slowly? > "For FPGAs it is things like the design tools, place and route, > timing and clock distribution. " What does that mean? What is "it"? Read the context before that paragraph. Another example of you needing to read more slowly? > BTW, the part you responded to I was only replying to your words I quoted. I thought you were saying HDL coding is equivalent to assembly language coding. Is that not correct? No. That's why I quoted the context. Another example of you needing to read more slowly?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-18 12:46 -0400 |
| Message-ID | <l1clcc$648$1@dont-email.me> |
| In reply to | #13679 |
On 9/17/2013 4:30 PM, Tom Gardner wrote: > On 17/09/13 21:00, rickman wrote: >> On 9/17/2013 6:37 AM, Tom Gardner wrote: >>> On 17/09/13 10:56, rickman wrote: >>>> On 9/17/2013 5:13 AM, Tom Gardner wrote: >>>>> On 15/09/13 18:58, Tim Wescott wrote: >>>>>> I've done a bit of FPGA work myself, too. While I can't claim to >>>>>> be an >>>>>> expert, what I've done backs up my impression that making things >>>>>> work on >>>>>> an FPGA requires a higher level of attention to more necessary >>>>>> details >>>>>> than assembly language programming does. >>>>> >>>>> Disagree. They are equivalent. >>>> >>>> I don't agree at all. You can program an FPGA in an HDL with a high >>>> level of abstraction. Like using an HLL at a high level of abstraction >>>> you may not get the best efficiency, but it will run your >>>> code just fine. Or you can design with an HDL at a lower level trying >>>> to control the implementation for efficiency or speed. That is when >>>> HDL programming can be more time consuming... but that is >>>> due to the optimizations which applies to *any* design methodology. >>> >>> You haven't read/understood the point to which I was replying. >> >> I read what you wrote and I acknowledge that I may not fully >> understand it. You used terms like, "large-scale enterprise software" >> which I am not familiar with. What is that supposed to mean? > > That's because you snipped it from my message. > Hint: read the paragraph beginning "For enterprise software..." > > Another example of you needing to read more slowly? Trimming the post didn't change what I read. If you want to be rude, then please don't bother to post. I read what you wrote, all of it. I don't know what you are trying to say with "enterprise software". If you have a point to make, please make it in a different way. >> "For FPGAs it is things like the design tools, place and route, >> timing and clock distribution. " What does that mean? What is "it"? > > Read the context before that paragraph. > > Another example of you needing to read more slowly? No, just your post not being clear. "it" is used poorly here. Try writing more clearly and I won't need to read "it" so many times. >> BTW, the part you responded to I was only replying to your words I >> quoted. I thought you were saying HDL coding is equivalent to assembly >> language coding. Is that not correct? > > No. That's why I quoted the context. > > Another example of you needing to read more slowly? No, just another example of your poor use of the language. If you just want to rag on me, please don't bother. If you really want to communicate, please rewrite your post more clearly. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-18 18:00 +0100 |
| Message-ID | <P_k_t.83509$xH1.59641@fx33.am4> |
| In reply to | #13698 |
On 18/09/13 17:46, rickman wrote: > On 9/17/2013 4:30 PM, Tom Gardner wrote: >> On 17/09/13 21:00, rickman wrote: >>> On 9/17/2013 6:37 AM, Tom Gardner wrote: >>>> On 17/09/13 10:56, rickman wrote: >>>>> On 9/17/2013 5:13 AM, Tom Gardner wrote: >>> I read what you wrote and I acknowledge that I may not fully >>> understand it. You used terms like, "large-scale enterprise software" >>> which I am not familiar with. What is that supposed to mean? >> >> That's because you snipped it from my message. >> Hint: read the paragraph beginning "For enterprise software..." >> >> Another example of you needing to read more slowly? > > Trimming the post didn't change what I read. Thank you for having the honesty to confirm my suspicion. > If you really want to communicate, please rewrite your post more clearly. Communication requires that something be written and read. Not speed-read so fast that relevant parts are omitted.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-09-11 12:10 -0700 |
| Message-ID | <l0qf73$h9o$1@speranza.aioe.org> |
| In reply to | #13464 |
Hi Tim,
On 9/11/2013 9:11 AM, Tim Wescott wrote:
> I'm working on a project that needs to have a pretty hefty amount of
> digital signal processing done in more or less real time ("soft" real
> time, if you must split hairs).
Consider a "real" DSP? Or, do you have a fair amount of
"conventional" coding that might make such a choice "tedious"?
> For a variety of reasons I think this algorithm would work best on a
> small single-board computer (my customer disagrees -- but getting it shoe-
> horned into the chips I was considering is going to take WORK, and I
> think it'll be cheaper for them to go with more expensive hardware).
Quantities? Target cost? Power? Environmental?
> So I'm looking for suggestions. I mostly build custom boards or I make
> algorithms for other people's hardware -- I've never specified a single-
> board computer that's gone into production.
>
> I was thinking PC-104, but I've never actually used a PC-104 computer,
> and I have no idea, beyond trade-show displays, how the market has
> evolved.
<frown> PC-104 tends to carry some higher costs than roll-your-own
(assuming the right quantities, of course). I.e., do you really need
the "expandability" that PC-104 brings to the table? Will you be buying
daughter cards -- or, rolling your own to add interfaces not present
on the first board?
> So, here's what I think I need. Anyone who wants to look through this
> and point me to the current crop of solutions for all this is welcome to
> do so -- I'll be grateful.
>
> Small: PC-104 form factor, or some other solution that's less than about
> 20 square inches of board and less than an inch tall.
>
> Fast: Something that supports native dual-precision floating point, and
> has a clock rate of 500MHz or better. This algorithm runs about 5x
> faster than real time as a Linux application on a Dell Dimension 8300.
> That's a 2.8GHz Pentium 4, so if it's running alone it should do more
> with less.
>
> Resource-rich: The algorithm runs, albeit way slow, on a STM32F407, using
> less than 128kB of memory. So at least that much memory plus whatever is
> necessary for any OS (see below).
Is it realistic to trade memory for performance? (unroll loops,
table lookups, etc.) Is that 128KB TEXT+DATA, TEXT, DATA, etc.?
Any requirement for persistent memory?
> Ports: Comes with serial ports. I don't need Ethernet or that stuff.
> Depending on the processor (see below), having a JTAG debug port would be
> nice.
>
> Extensible: I need something onto which I can easily slap an ADC board,
> or something that talks USB, and suggestions for matching ADC modules
> that talk USB. My preference is something that has an easy parallel I/O
> implementation, an SPI controller that I can hook to an ADC, and/or some
> generic general-purpose I/O pins that I can bit-bang.
Your ADC has a low bandwidth?
> Long legs: I need something that'll be on the market for at least five
> years, preferably a decade. Better yet would be something that comes
> from some sort of a standard (that's not on it's last legs) so that if
> today's choice goes out of production tomorrow, we can choose another
> that's form-fit-function compatible.
This, IMO, is where you will spend most of your selection effort
(esp if you aren't rolling your own). There are a *lot* of
"no-name" offerings that will fit your bill. But, no real guarantees
that any of these people will be producing the same (or compatible)
product *3* years from now.
Here, PC104 may help. Vendors *seem* like they try to keep their
products around a bit longer than most -- perhaps acknowledging
the fact that their devices are used in applications where the
customer (i.e., you) wouldn't want to upgrade "every year", etc.
Presumably, your code base is portable (not written in ASM) so
your main concern is mechanical and hardware features?
> Processor: My preference is for ARM or Intel, but I'm open to anything
> for which there's a good port of the gnu tools.
x86 is big in the PC104 world. Think "PC" :>
> OS: Depends somewhat on how the "extensible" happens. If I have to talk
> to an ADC using USB, then I want the board to be running Linux (or
> Windows in a pinch). Otherwise, I'm happy with putting my own little RTOS
> on there.
... because you don't have a USB stack?
> Thanks in advance.
Why not a hybrid approach? Design something that handles
<some-specific-aspect-of-your-problem> and *buy* something
that handles the rest? (the trick, of course, is finding
an efficient means of communicating between the two; if you
are passing gobs of data back AND forth, this will be a loser!)
I.e., think of it like designing a "smart peripheral" instead
of designing a "system".
[toc] | [prev] | [next] | [standalone]
| From | Vladimir Vassilevsky <nospam@nowhere.com> |
|---|---|
| Date | 2013-09-11 14:30 -0500 |
| Message-ID | <KMudnWN9WZBNWa3PnZ2dnUVZ5qOdnZ2d@giganews.com> |
| In reply to | #13464 |
Consider TMS64xx SOMs made by LogicPD and others. VLV
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-11 15:39 -0400 |
| Message-ID | <87ob7z6tbs.fsf@digitalsignallabs.com> |
| In reply to | #13477 |
Vladimir Vassilevsky <nospam@nowhere.com> writes: > Consider TMS64xx SOMs made by LogicPD and others. E.g., Orsys. There are some FPGA daughtercards you can use with them as well. Not PC-104. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-11 15:46 -0400 |
| Message-ID | <87ioy76t00.fsf@digitalsignallabs.com> |
| In reply to | #13478 |
Randy Yates <yates@digitalsignallabs.com> writes: > Vladimir Vassilevsky <nospam@nowhere.com> writes: > >> Consider TMS64xx SOMs made by LogicPD and others. > > E.g., Orsys. There are some FPGA daughtercards you can use with them as > well. Not PC-104. Correction: The Orsys is just a board, not a SOM (although not sure where you'd draw the line). -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-11 20:39 -0400 |
| Message-ID | <87r4cu50vj.fsf@digitalsignallabs.com> |
| In reply to | #13479 |
Randy Yates <yates@digitalsignallabs.com> writes: > Randy Yates <yates@digitalsignallabs.com> writes: > >> Vladimir Vassilevsky <nospam@nowhere.com> writes: >> >>> Consider TMS64xx SOMs made by LogicPD and others. >> >> E.g., Orsys. There are some FPGA daughtercards you can use with them as >> well. Not PC-104. > > Correction: The Orsys is just a board, not a SOM (although not sure > where you'd draw the line). Also, nevermind! The 67x doesn't do double precision FP in hardware either. Tim, are you sure you need doubles? That seems to limiting your choices. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.please> |
|---|---|
| Date | 2013-09-11 20:03 -0500 |
| Message-ID | <2aednep6xOBQj6zPnZ2dnUVZ_hCdnZ2d@giganews.com> |
| In reply to | #13486 |
On Wed, 11 Sep 2013 20:39:44 -0400, Randy Yates wrote: > Randy Yates <yates@digitalsignallabs.com> writes: > >> Randy Yates <yates@digitalsignallabs.com> writes: >> >>> Vladimir Vassilevsky <nospam@nowhere.com> writes: >>> >>>> Consider TMS64xx SOMs made by LogicPD and others. >>> >>> E.g., Orsys. There are some FPGA daughtercards you can use with them >>> as well. Not PC-104. >> >> Correction: The Orsys is just a board, not a SOM (although not sure >> where you'd draw the line). > > Also, nevermind! The 67x doesn't do double precision FP in hardware > either. > > Tim, are you sure you need doubles? That seems to limiting your choices. Yes. Or at least I either need doubles or 64-bit fixed-point. There's a Kalman filter buried in there that's both using most of the clock ticks and requires double precision. But the problem seems to have solved itself. The customer had originally asked for a custom board doing "demodulation" sitting next to a SBC PC doing graphics. Today, I convinced them that a custom DLL running on the SBC PC that does graphics would work. So they may have to make sure to get a fast-enough PC (and I'll have to write code to run under Windows -- ick). But the algorithm has a fast-enough home, without us having to do a bunch of unnecessary work. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-12 14:09 +0200 |
| Message-ID | <_emdnSDRP85nM6zPnZ2dnUVZ7tednZ2d@lyse.net> |
| In reply to | #13487 |
On 12/09/13 03:03, Tim Wescott wrote: > On Wed, 11 Sep 2013 20:39:44 -0400, Randy Yates wrote: > >> Randy Yates <yates@digitalsignallabs.com> writes: >> >>> Randy Yates <yates@digitalsignallabs.com> writes: >>> >>>> Vladimir Vassilevsky <nospam@nowhere.com> writes: >>>> >>>>> Consider TMS64xx SOMs made by LogicPD and others. >>>> >>>> E.g., Orsys. There are some FPGA daughtercards you can use with them >>>> as well. Not PC-104. >>> >>> Correction: The Orsys is just a board, not a SOM (although not sure >>> where you'd draw the line). >> >> Also, nevermind! The 67x doesn't do double precision FP in hardware >> either. >> >> Tim, are you sure you need doubles? That seems to limiting your choices. > > Yes. Or at least I either need doubles or 64-bit fixed-point. There's a > Kalman filter buried in there that's both using most of the clock ticks > and requires double precision. gcc for ARM has direct support for "long long fract", which is 1.63 fixed point (exact sizes vary according to target - stupidly there is no equivalent of <stdint.h> for fixed point in C). Dropping the requirement of floating point doubles will make life much easier. > > But the problem seems to have solved itself. The customer had originally > asked for a custom board doing "demodulation" sitting next to a SBC PC > doing graphics. > > Today, I convinced them that a custom DLL running on the SBC PC that does > graphics would work. So they may have to make sure to get a fast-enough > PC (and I'll have to write code to run under Windows -- ick). But the > algorithm has a fast-enough home, without us having to do a bunch of > unnecessary work. >
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-09-12 07:11 -0700 |
| Message-ID | <d17f5eaf-f417-4447-b177-29cf0e8fd35c@googlegroups.com> |
| In reply to | #13492 |
On Thursday, September 12, 2013 3:09:30 PM UTC+3, David Brown wrote: > On 12/09/13 03:03, Tim Wescott wrote: > > ... > Dropping the requirement of floating point doubles will make life much > easier. > The requirement comes probably because he will be DSP-ing. Because of the accumulate part of MAC, 32 bits is just not enough - and 32 bits FP (24 bits before information begins to get lost) is even worse. On the coldfire parts I have used there was a MAC accumulator though - did not use it but it was wider than the normal 32 bit registers. TI-s DSPs which I am familiar with (54xx) have 48 bit accumulators for their 16*16 MAC. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-09-12 16:34 +0200 |
| Message-ID | <0f2dnXCJMuprTazPnZ2dnUVZ7r6dnZ2d@lyse.net> |
| In reply to | #13497 |
On 12/09/13 16:11, dp wrote: > On Thursday, September 12, 2013 3:09:30 PM UTC+3, David Brown wrote: >> On 12/09/13 03:03, Tim Wescott wrote: >> >> ... >> Dropping the requirement of floating point doubles will make life much >> easier. >> > > The requirement comes probably because he will be DSP-ing. > Because of the accumulate part of MAC, 32 bits is just not > enough - and 32 bits FP (24 bits before information > begins to get lost) is even worse. > > On the coldfire parts I have used there was a MAC accumulator > though - did not use it but it was wider than the normal 32 bit > registers. TI-s DSPs which I am familiar with (54xx) have 48 bit > accumulators for their 16*16 MAC. > Yes, I know why he wants accurate values. But the simple matter is that hardware double-precision floating point is only available on a few relatively expensive microcontrollers and DSPs, while single-precision hardware floating point is quite common (such as on larger Cortex-M4 devices, and lots of MPC chips), and for many microcontrollers there is direct compiler support for 64-bit fixed point arithmetic. So if you can use 32-bit floating point, or alternatively use fixed point arithmetic, then the choice of microcontroller is far wider and far cheaper. Of course, you can always do the double precision floating point stuff in software - that's fine if the processor is fast enough.
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-12 10:42 -0400 |
| Message-ID | <87li322jal.fsf@digitalsignallabs.com> |
| In reply to | #13497 |
dp <dp@tgi-sci.com> writes: > On Thursday, September 12, 2013 3:09:30 PM UTC+3, David Brown wrote: >> On 12/09/13 03:03, Tim Wescott wrote: >> >> ... >> Dropping the requirement of floating point doubles will make life much >> easier. >> > > The requirement comes probably because he will be DSP-ing. > Because of the accumulate part of MAC, 32 bits is just not > enough - and 32 bits FP (24 bits before information > begins to get lost) is even worse. Dimiter, This is not really accurate. A typical DSP signal path will be 16 bits, or perhaps 24 bits for processors that work like the old Motorola 56K. So even though the accumulators are large, you ultimately have to quantize back to 16 or 24 bits. The reason for the large accumulators is so you don't overflow (or saturate) the integer accumulation, i.e., to afford a temporarily large dynamic range. Doing the operation in floating point (even single-precision FP) provides the necessary dynamic range. However, it is true that the intermediate multiply-accumulate in a fixed-point machine is performed to several more bits' of precision, so the resulting 24 bits (e.g.) is more accurate than the 24 bits resulting from the equivalent operation in single-precision FP. > On the coldfire parts I have used there was a MAC accumulator > though - did not use it but it was wider than the normal 32 bit > registers. TI-s DSPs which I am familiar with (54xx) have 48 bit > accumulators for their 16*16 MAC. Actually the TI TMS320C54x DSPs have 40-bit accumulators, 32 bits for the 16x16 multiply plus 8 "guard bits" for the accumulation. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-09-12 12:48 -0700 |
| Message-ID | <e5023cb3-f22e-4a98-8423-d65cff55f208@googlegroups.com> |
| In reply to | #13500 |
On Thursday, September 12, 2013 5:42:26 PM UTC+3, Randy Yates wrote: > dp <dp@tgi-sci.com> writes: > > > > On Thursday, September 12, 2013 3:09:30 PM UTC+3, David Brown wrote: > >> On 12/09/13 03:03, Tim Wescott wrote: > >> > >> ... > >> Dropping the requirement of floating point doubles will make life much > >> easier. > >> > > > > The requirement comes probably because he will be DSP-ing. > > Because of the accumulate part of MAC, 32 bits is just not > > enough - and 32 bits FP (24 bits before information > > begins to get lost) is even worse. > > > This is not really accurate. A typical DSP signal path will > be 16 bits, or perhaps 24 bits for processors that work like > the old Motorola 56K. So even though the accumulators are > large, you ultimately have to quantize back to 16 or 24 bits. > > The reason for the large accumulators is so you don't overflow (or > saturate) the integer accumulation, i.e., to afford a temporarily large > dynamic range. Which is exactly what I said. > Doing the operation in floating point (even > single-precision FP) provides the necessary dynamic range. No, single precision FP is nowhere near sufficient for an accumulator. Just 24 bits of mantissa. This is why on normal processors you do need either dual precision FP or some specifically built accumulator. > ... TI-s DSPs which I am familiar with (54xx) have 48 bit > > accumulators for their 16*16 MAC. > > Actually the TI TMS320C54x DSPs have 40-bit accumulators, 32 bits for > the 16x16 multiply plus 8 "guard bits" for the accumulation. Well it's been over 10 years since I did that this with a 5420 ( http://tgi-sci.com/tgi/hstb.htm )so I may have forgotten. Which is somewhat strange, I spent almost 3 months writing the assembler & debugger I used for the 5420 afterwards so I would expect my memory to have served better.... :-). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.really> |
|---|---|
| Date | 2013-09-12 16:14 -0500 |
| Message-ID | <mMKdnbkf8dxas6_PnZ2dnUVZ5jydnZ2d@giganews.com> |
| In reply to | #13500 |
On Thu, 12 Sep 2013 10:42:26 -0400, Randy Yates wrote: > dp <dp@tgi-sci.com> writes: > >> On Thursday, September 12, 2013 3:09:30 PM UTC+3, David Brown wrote: >>> On 12/09/13 03:03, Tim Wescott wrote: >>> >>> ... >>> Dropping the requirement of floating point doubles will make life much >>> easier. >>> >>> >> The requirement comes probably because he will be DSP-ing. >> Because of the accumulate part of MAC, 32 bits is just not enough - and >> 32 bits FP (24 bits before information begins to get lost) is even >> worse. > > Dimiter, > > This is not really accurate. A typical DSP signal path will be 16 bits, > or perhaps 24 bits for processors that work like the old Motorola 56K. > So even though the accumulators are large, you ultimately have to > quantize back to 16 or 24 bits. Your typical DSP path, maybe. If you're doing IIR filtering with 16-bit input data you'd better use plenty-o-bits, and you'd better make sure that your "plenty" is plenty enough. I usually go by n = log_2(sample rate / filter bandwidth) as a guide for the minimum number of bits to add to the input data width for 1st-order filters, at least twice that for resonant 2nd-order filters. I'm often doing control systems work where, between the required precision, the sampling rate, and the required integrator gain (low), even 24 bits is inadequate -- in that case I either use 32 bits (which _is_ adequate for nearly all control systems work) or double-precision floating point. In this case, because of the Kalman filter, one could probably flog the hell out of it and get it to fit into 32-bit fixed point data, or easily use 64-bit fixed point. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2013-09-12 21:39 +0200 |
| Message-ID | <b9ejiqFqcf7U1@mid.dfncis.de> |
| In reply to | #13492 |
On 12.09.2013 14:09, David Brown wrote: > gcc for ARM has direct support for "long long fract", which is 1.63 > fixed point (exact sizes vary according to target - stupidly there is no > equivalent of <stdint.h> for fixed point in C). Why would there be such a thing? After all, there are no fractional integers in the language to begin with, so what use could a header documenting their non-existing properties be? Fixed-point integer types exist in C only as non-standard extensions, like the proposed "Extensions for the programming language C to support embedded processors". It's up to the implementors of such extensions how they publish their properties. The above-mentioned proposal has <stdfix.h>, other approaches will have their own, similar headers.
[toc] | [prev] | [next] | [standalone]
Page 21 of 22 — ← Prev page 1 … 19 20 [21] 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web