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 19 of 22 — ← Prev page 1 … 17 18 [19] 20 21 22 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-15 13:11 -0700 |
| Message-ID | <7xwqmhluai.fsf@ruckus.brouhaha.com> |
| In reply to | #13596 |
rickman <gnuarm@gmail.com> writes: >> The requirement of double precision floating point, one presumes. What >> would the FPGA approach to that be? > Do you know how floating point is calculated? The question says you > don't. Not at the hardware level in serious detail, which is why I asked how you'd do it. I do know you have to do wide arithmetic and normalization on every operation, and in a CPU, this is all done with parallel circuitry. With an FPGA (i.e. narrow fixed point DSP blocks) you'd have to do the operation in a bunch of slices and juggle the intermediate results around (possibly involving multiple LUT delays) and it sounds messy. I also haven't looked at the function of DSP blocks enough to know if it's even possible to use several of them at the same time for an operation like this, without introducing more latency. I'd be interested to know if there are canned Verilog libraries for double precision IEEE floating point and whether they can do division, trig functions, etc. Unless I'm mistaken, a current x86 can start a new double precision floating point MAC every cycle. Can you do that with an FPGA in a reasonable way?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-15 16:26 -0400 |
| Message-ID | <l1556t$1gr$1@dont-email.me> |
| In reply to | #13606 |
On 9/15/2013 4:11 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >>> The requirement of double precision floating point, one presumes. What >>> would the FPGA approach to that be? >> Do you know how floating point is calculated? The question says you >> don't. > > Not at the hardware level in serious detail, which is why I asked how > you'd do it. I do know you have to do wide arithmetic and normalization > on every operation, and in a CPU, this is all done with parallel > circuitry. With an FPGA (i.e. narrow fixed point DSP blocks) you'd have > to do the operation in a bunch of slices and juggle the intermediate > results around (possibly involving multiple LUT delays) and it sounds > messy. I also haven't looked at the function of DSP blocks enough to > know if it's even possible to use several of them at the same time for > an operation like this, without introducing more latency. I'd be > interested to know if there are canned Verilog libraries for double > precision IEEE floating point and whether they can do division, trig > functions, etc. > > Unless I'm mistaken, a current x86 can start a new double precision > floating point MAC every cycle. Can you do that with an FPGA in a > reasonable way? If I sounded rude I apologize. That was not my intent. A floating point multiply requires the unpacked mantissas to be multiplied, the exponents to be added and then adjusted to match the normalized product. So you have a small adder for the exponents with a smaller input from the normalization, a multiplier and a shifter (not a full barrel shifter). Not so bad. This is easy to pipeline, but that is irrelevant. It is easy to get a result in one clock cycle. Pipelining just speeds up the clock cycle. In addition, in an FPGA you are not so limited in how many multipliers you have. Additions are actually harder. To add you have to first adjust the exponents to match. So one addend has to be shifted an arbitrary amount... enter the multiplier to be used as a barrel shifter. The mantissas are then added (or subtracted as the case may be) and the sum normalized... again requiring a shift by an arbitrary amount... another multiplier. You can do the shifts in the LUT fabric. For one or two it isn't so many, but they are slow by comparison. If you are pipelining you will especially want to use the multipliers. The HDL has not typically supported real number synthesis in the not so recent past, but I believe this has become more widely supported. So it may be a lot easier to just code in reals and not worry about the *how* of floating point. But even if you do have to code your own FP multiplier, you do it once and use it as often as you like. Far from a nightmare. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-15 16:36 -0400 |
| Message-ID | <l155op$5d7$1@dont-email.me> |
| In reply to | #13606 |
Just for grins, if you are interested in how we did floating point before FPGAs and before the PC had floating point hardware google ST100 array processor. https://www.google.com/search?q=st100+array+processor&spell=1&sa=X&ei=kBY2UvHWBvHa4APal4DgAQ&ved=0CCkQvwUoAA I worked on that machine and that is where I learned about how to design floating point in hardware. They used 1000 gate ECL gate arrays. lol Your cell phone can likely run rings around one and that hulk used a 220 volt power source! -- Rick
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-17 07:49 +0000 |
| Message-ID | <l191id$7do$1@speranza.aioe.org> |
| In reply to | #13606 |
In comp.dsp Paul Rubin <no.email@nospam.invalid> wrote: (snip) > Not at the hardware level in serious detail, which is why I asked how > you'd do it. I do know you have to do wide arithmetic and normalization > on every operation, and in a CPU, this is all done with parallel > circuitry. With an FPGA (i.e. narrow fixed point DSP blocks) you'd have > to do the operation in a bunch of slices and juggle the intermediate > results around (possibly involving multiple LUT delays) and it sounds > messy. Usually the system will have an array of similar blocks, so you only need to design one. Once it works, the rest is easy. > I also haven't looked at the function of DSP blocks enough to > know if it's even possible to use several of them at the same time for > an operation like this, without introducing more latency. I'd be > interested to know if there are canned Verilog libraries for double > precision IEEE floating point and whether they can do division, trig > functions, etc. In the popular families, there is a flip-flop (register) on the output of each LUT. That makes pipelined arrays very easy to do. > Unless I'm mistaken, a current x86 can start a new double precision > floating point MAC every cycle. Can you do that with an FPGA in a > reasonable way? Yes, pipeline the whole thing in each step. The clock rate might be a lot less, but you might get 100 or more on each clock cycle. Maybe 1000 for simple fixed point operations. You can also array the FPGAs for even larger calculations. -- glen
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-17 05:30 -0400 |
| Message-ID | <l197gm$e6q$1@dont-email.me> |
| In reply to | #13657 |
On 9/17/2013 3:49 AM, glen herrmannsfeldt wrote: > > Yes, pipeline the whole thing in each step. The clock rate might be > a lot less, but you might get 100 or more on each clock cycle. > Maybe 1000 for simple fixed point operations. You can also array the > FPGAs for even larger calculations. People often confuse pipelining as being required for single cycle operation. That is not actually correct. Pipelining allows the clock rate to be faster. Anything in an FPGA can be done in one clock cycle... or no clock cycles at all. The logic is combinatorial, registers are optional. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-09-19 10:00 +0000 |
| Message-ID | <l1ei0g$st6$1@speranza.aioe.org> |
| In reply to | #13661 |
In comp.dsp rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> Yes, pipeline the whole thing in each step. The clock rate might be >> a lot less, but you might get 100 or more on each clock cycle. >> Maybe 1000 for simple fixed point operations. You can also array the >> FPGAs for even larger calculations. > People often confuse pipelining as being required for single cycle > operation. That is not actually correct. Pipelining allows the clock > rate to be faster. Anything in an FPGA can be done in one clock > cycle... or no clock cycles at all. The logic is combinatorial, > registers are optional. You can, but it is pipelining that gets the speed. And in most FPGAs the registers are there, used or not, so you might as well use them. But as with using a CPU, if the combinatorial logic is fast enough, then maybe there is no reason to pipeline it. -- glen
[toc] | [prev] | [next] | [standalone]
| From | gtwrek@sonic.net (Mark Curry) |
|---|---|
| Date | 2013-09-16 16:51 +0000 |
| Message-ID | <l17cue$6rs$1@dont-email.me> |
| In reply to | #13592 |
In article <7xioy2xy8u.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >rickman <gnuarm@gmail.com> writes: >>> Kalman filter >> Why is this algorithm so easy on a PC but so hard in an FPGA? > >The requirement of double precision floating point, one presumes. What >would the FPGA approach to that be? The DSP blocks in FPGA's are >usually fixed point and narrow. Xilinx DSP48s are 48 bits. Altera's accumulators are similar. That's not narrow in my book. Regards, Mark
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-16 14:54 -0400 |
| Message-ID | <l17k5o$oeb$1@dont-email.me> |
| In reply to | #13637 |
On 9/16/2013 12:51 PM, Mark Curry wrote: > In article<7xioy2xy8u.fsf@ruckus.brouhaha.com>, > Paul Rubin<no.email@nospam.invalid> wrote: >> rickman<gnuarm@gmail.com> writes: >>>> Kalman filter >>> Why is this algorithm so easy on a PC but so hard in an FPGA? >> >> The requirement of double precision floating point, one presumes. What >> would the FPGA approach to that be? The DSP blocks in FPGA's are >> usually fixed point and narrow. > > Xilinx DSP48s are 48 bits. Altera's accumulators are similar. That's not > narrow in my book. Since you seem to be familiar with these and to save me digging up a data sheet, what is the width of the inputs to the multiplier in the DSP48? Is the accumulator 48 bits or is it wider? I was helping a colleague learn VHDL and he was telling me about the Altera DSP blocks, but I don't recall the details. He did mention multiple accumulators for each multiplier which I expect helps in many apps. I just don't recall all the bit widths, inputs, product, accumulators. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | gtwrek@sonic.net (Mark Curry) |
|---|---|
| Date | 2013-09-16 19:06 +0000 |
| Message-ID | <l17ksb$o9i$1@dont-email.me> |
| In reply to | #13643 |
In article <l17k5o$oeb$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 9/16/2013 12:51 PM, Mark Curry wrote: >> In article<7xioy2xy8u.fsf@ruckus.brouhaha.com>, >> Paul Rubin<no.email@nospam.invalid> wrote: >>> rickman<gnuarm@gmail.com> writes: >>>>> Kalman filter >>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >>> >>> The requirement of double precision floating point, one presumes. What >>> would the FPGA approach to that be? The DSP blocks in FPGA's are >>> usually fixed point and narrow. >> >> Xilinx DSP48s are 48 bits. Altera's accumulators are similar. That's not >> narrow in my book. > >Since you seem to be familiar with these and to save me digging up a >data sheet, what is the width of the inputs to the multiplier in the >DSP48? Is the accumulator 48 bits or is it wider? The accumulator is 48 bits. The inputs to the accumulator are: * The accumulator itself (or an accumulator from another DSP48) * A shifted version of the accumulator (or an accumulator from another DSP48) * The output of a 25 bit x 18 bit multiply (43 bits) * A full 48 bit input from the FPGA fabric There's restrictions on which inputs can be used when (i.e. not all of the above can be used at once). There's other variations too, but the above captures the high-level. The above is for Virtex7. For previous generatations, the multiplier was only 18x18. Regards, Mark
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-16 15:22 -0400 |
| Message-ID | <l17lov$25b$1@dont-email.me> |
| In reply to | #13645 |
On 9/16/2013 3:06 PM, Mark Curry wrote: > In article<l17k5o$oeb$1@dont-email.me>, rickman<gnuarm@gmail.com> wrote: >> On 9/16/2013 12:51 PM, Mark Curry wrote: >>> In article<7xioy2xy8u.fsf@ruckus.brouhaha.com>, >>> Paul Rubin<no.email@nospam.invalid> wrote: >>>> rickman<gnuarm@gmail.com> writes: >>>>>> Kalman filter >>>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >>>> >>>> The requirement of double precision floating point, one presumes. What >>>> would the FPGA approach to that be? The DSP blocks in FPGA's are >>>> usually fixed point and narrow. >>> >>> Xilinx DSP48s are 48 bits. Altera's accumulators are similar. That's not >>> narrow in my book. >> >> Since you seem to be familiar with these and to save me digging up a >> data sheet, what is the width of the inputs to the multiplier in the >> DSP48? Is the accumulator 48 bits or is it wider? > > The accumulator is 48 bits. The inputs to the accumulator are: > * The accumulator itself (or an accumulator from another DSP48) > * A shifted version of the accumulator (or an accumulator from another DSP48) > * The output of a 25 bit x 18 bit multiply (43 bits) > * A full 48 bit input from the FPGA fabric > > There's restrictions on which inputs can be used when (i.e. not all of the > above can be used at once). There's other variations too, but the above > captures the high-level. > > The above is for Virtex7. For previous generatations, the multiplier > was only 18x18. Thanks -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@technologyhighland.invalid> |
|---|---|
| Date | 2013-09-17 09:40 -0700 |
| Message-ID | <20130917094018.5aaaf79b@rg.highlandtechnology.com> |
| In reply to | #13645 |
On Mon, 16 Sep 2013 19:06:51 +0000 (UTC) gtwrek@sonic.net (Mark Curry) wrote: > In article <l17k5o$oeb$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: > >On 9/16/2013 12:51 PM, Mark Curry wrote: > >> In article<7xioy2xy8u.fsf@ruckus.brouhaha.com>, > >> Paul Rubin<no.email@nospam.invalid> wrote: > >>> rickman<gnuarm@gmail.com> writes: > >>>>> Kalman filter > >>>> Why is this algorithm so easy on a PC but so hard in an FPGA? > >>> > >>> The requirement of double precision floating point, one presumes. What > >>> would the FPGA approach to that be? The DSP blocks in FPGA's are > >>> usually fixed point and narrow. > >> > >> Xilinx DSP48s are 48 bits. Altera's accumulators are similar. That's not > >> narrow in my book. > > > >Since you seem to be familiar with these and to save me digging up a > >data sheet, what is the width of the inputs to the multiplier in the > >DSP48? Is the accumulator 48 bits or is it wider? > > The accumulator is 48 bits. The inputs to the accumulator are: > * The accumulator itself (or an accumulator from another DSP48) > * A shifted version of the accumulator (or an accumulator from another DSP48) > * The output of a 25 bit x 18 bit multiply (43 bits) > * A full 48 bit input from the FPGA fabric > > There's restrictions on which inputs can be used when (i.e. not all of the > above can be used at once). There's other variations too, but the above > captures the high-level. > > The above is for Virtex7. For previous generatations, the multiplier > was only 18x18. > See, right there's one of the big problems trying to do serious amounts of floating point in FPGAs. Even in a V7, that's still forcing you to do 4 DSP slice cross products if you want to work in double precision. Go down to something smaller and you're up to having to use 6, with all the attendant slowdown of the followup additions, and then still manage the renormalization. So all of a sudden you're chewing through DSP blocks fast and hard. If you start timesharing them you can keep the number used managable, but the code's getting ugly and throughput is dropping. And the smallest V7 is what, 4 grand? That buys a whole lot of C writable, conventional, sequential processing. I've done (single) floats in an FPGA before in some limited capacity. It's not the end of the world, but it's a poor fit for the technology. Big fat fixed point is resource-cheaper and generally introduces fewer exciting corner cases. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.really> |
|---|---|
| Date | 2013-09-17 11:48 -0500 |
| Message-ID | <Sf2dnU1aJpZmGqXPnZ2dnUVZ5sydnZ2d@giganews.com> |
| In reply to | #13669 |
On Tue, 17 Sep 2013 09:40:18 -0700, Rob Gaddi wrote: > On Mon, 16 Sep 2013 19:06:51 +0000 (UTC) > gtwrek@sonic.net (Mark Curry) wrote: > >> In article <l17k5o$oeb$1@dont-email.me>, rickman <gnuarm@gmail.com> >> wrote: >> >On 9/16/2013 12:51 PM, Mark Curry wrote: >> >> In article<7xioy2xy8u.fsf@ruckus.brouhaha.com>, >> >> Paul Rubin<no.email@nospam.invalid> wrote: >> >>> rickman<gnuarm@gmail.com> writes: >> >>>>> Kalman filter >> >>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >> >>> >> >>> The requirement of double precision floating point, one presumes. >> >>> What would the FPGA approach to that be? The DSP blocks in FPGA's >> >>> are usually fixed point and narrow. >> >> >> >> Xilinx DSP48s are 48 bits. Altera's accumulators are similar. >> >> That's not narrow in my book. >> > >> >Since you seem to be familiar with these and to save me digging up a >> >data sheet, what is the width of the inputs to the multiplier in the >> >DSP48? Is the accumulator 48 bits or is it wider? >> >> The accumulator is 48 bits. The inputs to the accumulator are: >> * The accumulator itself (or an accumulator from another DSP48) >> * A shifted version of the accumulator (or an accumulator from >> another DSP48) >> * The output of a 25 bit x 18 bit multiply (43 bits) >> * A full 48 bit input from the FPGA fabric >> >> There's restrictions on which inputs can be used when (i.e. not all of >> the above can be used at once). There's other variations too, but the >> above captures the high-level. >> >> The above is for Virtex7. For previous generatations, the multiplier >> was only 18x18. >> >> > See, right there's one of the big problems trying to do serious amounts > of floating point in FPGAs. Even in a V7, that's still forcing you to > do 4 DSP slice cross products if you want to work in double precision. > Go down to something smaller and you're up to having to use 6, with all > the attendant slowdown of the followup additions, and then still manage > the renormalization. > > So all of a sudden you're chewing through DSP blocks fast and hard. If > you start timesharing them you can keep the number used managable, but > the code's getting ugly and throughput is dropping. And the smallest V7 > is what, 4 grand? That buys a whole lot of C writable, conventional, > sequential processing. > > I've done (single) floats in an FPGA before in some limited capacity. > It's not the end of the world, but it's a poor fit for the technology. > Big fat fixed point is resource-cheaper and generally introduces fewer > exciting corner cases. And the original request was for a suggestion for a board into which I could drop, without modification, existing, working, tested C++ code that runs on a PC... -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-17 15:50 -0400 |
| Message-ID | <l1abpq$9ug$1@dont-email.me> |
| In reply to | #13669 |
On 9/17/2013 12:40 PM, Rob Gaddi wrote: > On Mon, 16 Sep 2013 19:06:51 +0000 (UTC) > gtwrek@sonic.net (Mark Curry) wrote: > >> In article<l17k5o$oeb$1@dont-email.me>, rickman<gnuarm@gmail.com> wrote: >>> On 9/16/2013 12:51 PM, Mark Curry wrote: >>>> In article<7xioy2xy8u.fsf@ruckus.brouhaha.com>, >>>> Paul Rubin<no.email@nospam.invalid> wrote: >>>>> rickman<gnuarm@gmail.com> writes: >>>>>>> Kalman filter >>>>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >>>>> >>>>> The requirement of double precision floating point, one presumes. What >>>>> would the FPGA approach to that be? The DSP blocks in FPGA's are >>>>> usually fixed point and narrow. >>>> >>>> Xilinx DSP48s are 48 bits. Altera's accumulators are similar. That's not >>>> narrow in my book. >>> >>> Since you seem to be familiar with these and to save me digging up a >>> data sheet, what is the width of the inputs to the multiplier in the >>> DSP48? Is the accumulator 48 bits or is it wider? >> >> The accumulator is 48 bits. The inputs to the accumulator are: >> * The accumulator itself (or an accumulator from another DSP48) >> * A shifted version of the accumulator (or an accumulator from another DSP48) >> * The output of a 25 bit x 18 bit multiply (43 bits) >> * A full 48 bit input from the FPGA fabric >> >> There's restrictions on which inputs can be used when (i.e. not all of the >> above can be used at once). There's other variations too, but the above >> captures the high-level. >> >> The above is for Virtex7. For previous generatations, the multiplier >> was only 18x18. >> > > See, right there's one of the big problems trying to do serious amounts > of floating point in FPGAs. Even in a V7, that's still forcing you to > do 4 DSP slice cross products if you want to work in double precision. > Go down to something smaller and you're up to having to use 6, with all > the attendant slowdown of the followup additions, and then still manage > the renormalization. > > So all of a sudden you're chewing through DSP blocks fast and hard. If > you start timesharing them you can keep the number used managable, but > the code's getting ugly and throughput is dropping. And the smallest > V7 is what, 4 grand? That buys a whole lot of C writable, > conventional, sequential processing. Uh, give me a number. How many multipliers do you need? I'm sure I can find a device with that number of multipliers. Are you suggesting that you can't find a suitable FPGA for less than $4,000? Really? Still, this is pretty far off topic. The OP said KF development on an FPGA would be a "nightmare". Needing a lot of multiplier blocks is hardly a "nightmare". > I've done (single) floats in an FPGA before in some limited capacity. > It's not the end of the world, but it's a poor fit for the technology. > Big fat fixed point is resource-cheaper and generally introduces fewer > exciting corner cases. Actually, the OP has indicated that the problem can be solved in 64 bit fixed point or possibly even 48 bit fixed point. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | gtwrek@sonic.net (Mark Curry) |
|---|---|
| Date | 2013-09-17 21:03 +0000 |
| Message-ID | <l1ag37$528$1@dont-email.me> |
| In reply to | #13669 |
In article <20130917094018.5aaaf79b@rg.highlandtechnology.com>, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >On Mon, 16 Sep 2013 19:06:51 +0000 (UTC) >gtwrek@sonic.net (Mark Curry) wrote: > >> In article <l17k5o$oeb$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> >On 9/16/2013 12:51 PM, Mark Curry wrote: >> >> In article<7xioy2xy8u.fsf@ruckus.brouhaha.com>, >> >> Paul Rubin<no.email@nospam.invalid> wrote: >> >>> rickman<gnuarm@gmail.com> writes: >> >>>>> Kalman filter >> >>>> Why is this algorithm so easy on a PC but so hard in an FPGA? >> >>> >> >>> The requirement of double precision floating point, one presumes. What >> >>> would the FPGA approach to that be? The DSP blocks in FPGA's are >> >>> usually fixed point and narrow. >> >> >> >> Xilinx DSP48s are 48 bits. Altera's accumulators are similar. That's not >> >> narrow in my book. >> > >> >Since you seem to be familiar with these and to save me digging up a >> >data sheet, what is the width of the inputs to the multiplier in the >> >DSP48? Is the accumulator 48 bits or is it wider? >> >> The accumulator is 48 bits. The inputs to the accumulator are: >> * The accumulator itself (or an accumulator from another DSP48) >> * A shifted version of the accumulator (or an accumulator from another DSP48) >> * The output of a 25 bit x 18 bit multiply (43 bits) >> * A full 48 bit input from the FPGA fabric >> >> There's restrictions on which inputs can be used when (i.e. not all of the >> above can be used at once). There's other variations too, but the above >> captures the high-level. >> >> The above is for Virtex7. For previous generatations, the multiplier >> was only 18x18. >> > >See, right there's one of the big problems trying to do serious amounts >of floating point in FPGAs. Even in a V7, that's still forcing you to >do 4 DSP slice cross products if you want to work in double precision. >Go down to something smaller and you're up to having to use 6, with all >the attendant slowdown of the followup additions, and then still manage >the renormalization. > >So all of a sudden you're chewing through DSP blocks fast and hard. If >you start timesharing them you can keep the number used managable, but >the code's getting ugly and throughput is dropping. And the smallest >V7 is what, 4 grand? That buys a whole lot of C writable, >conventional, sequential processing. > >I've done (single) floats in an FPGA before in some limited capacity. >It's not the end of the world, but it's a poor fit for the technology. >Big fat fixed point is resource-cheaper and generally introduces fewer >exciting corner cases. I agree totally - I think. Generic floating point in FPGAs is pointless. You're better off using a custom format, designed for the problem at hand. This can be a static, fixed point (with pretty significant number of bits). This can be "a little floating point" with n bit mantissas and a few bits of exponent. But full on IEEE 754 (single or double) - that's dumb on an FPGA. There's little reason for a single wire on an FPGA to have that kind of dynamic range. Haven't followed this whole thread in detail - not saying FPGAs are the best solution for a specific problem. But discounting FPGAs because they don't "do floating point" or "don't have enough precision" is wrong. Regards, Mark
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-17 17:05 -0400 |
| Message-ID | <877gef2m6x.fsf@digitalsignallabs.com> |
| In reply to | #13680 |
gtwrek@sonic.net (Mark Curry) writes: > Generic floating point in FPGAs is pointless. Ha ha ha ha ha ha!!! -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | gtwrek@sonic.net (Mark Curry) |
|---|---|
| Date | 2013-09-17 21:16 +0000 |
| Message-ID | <l1agrb$528$3@dont-email.me> |
| In reply to | #13681 |
In article <877gef2m6x.fsf@digitalsignallabs.com>, Randy Yates <yates@digitalsignallabs.com> wrote: >gtwrek@sonic.net (Mark Curry) writes: > >> Generic floating point in FPGAs is pointless. > >Ha ha ha ha ha ha!!! I really didn't intend that pun... Totally went over my head to you replied. And then couldn't figure out why you were laughing at me :) --Mark
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-09-17 16:38 -0700 |
| Message-ID | <f50d048e-5c82-49c8-b4bb-ed49ea1abf8d@googlegroups.com> |
| In reply to | #13683 |
On Wednesday, September 18, 2013 12:16:28 AM UTC+3, Mark Curry wrote: > In article <877gef2m6x.fsf@digitalsignallabs.com>, > > Randy Yates <yates@digitalsignallabs.com> wrote: > >gtwrek@sonic.net (Mark Curry) writes: > > > >> Generic floating point in FPGAs is pointless. > > > >Ha ha ha ha ha ha!!! > > I really didn't intend that pun... Totally went over my head to > you replied. And then couldn't figure out why you were laughing > at me :) > But your point :) is something I just wanted to make, it is a valid one. For DSP-ing (doing lots of MAC) one uses floating point on processors simply because/when a 64-bit FP register is the only large enough accumulator. I see no reason why one would implement FP on an FPGA to do the MAC thing when just having a large enough accumulator should be much easier, data won't have to be converted (as they normally come from some ADC or something) to FP etc. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
[toc] | [prev] | [next] | [standalone]
| From | Randy Yates <yates@digitalsignallabs.com> |
|---|---|
| Date | 2013-09-17 21:33 -0400 |
| Message-ID | <87zjra29sc.fsf@digitalsignallabs.com> |
| In reply to | #13683 |
gtwrek@sonic.net (Mark Curry) writes: > In article <877gef2m6x.fsf@digitalsignallabs.com>, > Randy Yates <yates@digitalsignallabs.com> wrote: >>gtwrek@sonic.net (Mark Curry) writes: >> >>> Generic floating point in FPGAs is pointless. >> >>Ha ha ha ha ha ha!!! > > I really didn't intend that pun... Totally went over my head to > you replied. And then couldn't figure out why you were laughing > at me :) I'm glad you got the (er) point... -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <as@sci.fi> |
|---|---|
| Date | 2013-09-18 10:48 +0300 |
| Message-ID | <vg3ioxybmdz.fsf@coffee.modeemi.fi> |
| In reply to | #13669 |
Rob Gaddi <rgaddi@technologyhighland.invalid> writes: > See, right there's one of the big problems trying to do serious amounts > of floating point in FPGAs. Even in a V7, that's still forcing you to > do 4 DSP slice cross products if you want to work in double precision. I seem to recall Altera mentioning that their new stuff improves on that and indeed Stratix V (and also Arria V and Cyclone V) has 27x27 multipliers and a 64-bit accumulator. But is that enough for double precision floating point?
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.please> |
|---|---|
| Date | 2013-09-15 10:39 -0500 |
| Message-ID | <o7SdnVK0GY4HSajPnZ2dnUVZ_hGdnZ2d@giganews.com> |
| In reply to | #13591 |
On Sun, 15 Sep 2013 02:38:15 -0400, rickman wrote:
> On 9/11/2013 2:37 PM, Tim Wescott wrote:
>> On Wed, 11 Sep 2013 18:26:46 +0000, glen herrmannsfeldt wrote:
>>
>>> In comp.dsp Tim Wescott<tim@seemywebsite.really> 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).
>>>
>>> Just wondering, have you thought about FPGA based systolic arrays?
>>
>> This is a high-zoot,
>
> "High-zoot"??? What is that?
>
It's got lots of zoot, of course. Look up "super zoot" in the
dictionary. Maybe "zoot suit".
>
>> low production volume task. And I have things working just dandy on a
>> PC. So I'd like to take that "works dandy" and translate it -- with as
>> little effort as possible -- to something that'll work inside of a box.
>
> Then why don't you use a small PC? They come in rather small units, not
> much larger than a Wifi router. ITX may be the form factor I am
> thinking of.
At the time of writing, because I couldn't talk my customer into it.
That problem has since been solved.
>> Trying to translate this algorithm (it's a Kalman filter) into an FPGA-
>> based system would be a nightmare and a time-sink. I'm trying to avoid
>> the time sink.
>
> Lol, that funny. Hardly a nightmare and time sink is a relative thing.
> Anyone who knows what they are doing with FPGAs can most likely do the
> job rather easily. Why is this algorithm so easy on a PC but so hard in
> an FPGA?
For the same reason that PCs use processors and not FPGAs. Because there
are some algorithms that just fit better onto one thing or the other.
Look up "Extended Kalman Filter" on Wikipedia, consider that your H
matrix will change every cycle depending on the incoming data, and then
you tell me.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
Page 19 of 22 — ← Prev page 1 … 17 18 [19] 20 21 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web