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 15 of 22 — ← Prev page 1 … 13 14 [15] 16 17 … 22 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-03 23:07 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7xhacxwoua.fsf@ruckus.brouhaha.com> |
| In reply to | #14137 |
rickman <gnuarm@gmail.com> writes: > Now can you think of what you would like ***on*** the board rather > than the code you would write for inside the FPGA? Oh, I see, you want to make a something like an FPGA evaluation board, rather than products built around FPGA's. I think there are already evaluation boards from the FPGA vendors, though they never have quite the right stuff on them. Well, the gadgets that I mentioned are things I've been interested in and would possibly buy. I probably wouldn't use an evaluation board without FOSS tools, unless someone was paying me.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-01 20:06 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7xeh844biv.fsf@ruckus.brouhaha.com> |
| In reply to | #14048 |
rickman <gnuarm@gmail.com> writes: > I'm sure the vendors are very protective of their tricks and > techniques. But the hardware is wide open. They may not give you all > the gory details of what connects to what in an explicit way, How on earth can you say it's wide open, if I can't figure out what bits to send into the chip to perform a given function? Why are they more protective than CPU vendors? CPU's have manuals that specify the instruction set in enough detail that I can write a compiler and generate my own binaries to load into the CPU. With FPGA's it sounds like I have to use the vendor compiler. > I guess what I am saying is that with the current approach in > designing FPGAs you aren't missing anything except all the hard work. What if I want to write my own compiler, say to use the fpga as a reconfigurable processor? > If you ask for it and have a valid reason for wanting it I can't > imagine they wouldn't share it with you. If they were willing to share the info with me for the purposes I have in mind (maybe using Kansas Lava, a FOSS compiler for FPGA's), they would publish the info and just sell me the hardware. >>> One *big* issue I have with the current tools is that they *are* >>> licensed even though they are free (as in beer). They also may be dependent on specific cpu architectures. Maybe I want to build an embedded gadget that generates fpga code on the fly and loads it into the fpga. I can't run their Windows tools in the gadget. > Heck, I would just love to see the FPGA vendors come out with devices > in packages like MCUs so that I can use FPGAs in more MCU-like Maybe there is a technical reason why they don't do that.
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-10-01 22:38 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <9fdf926e-4fe8-4806-9f54-2056d68b037a@googlegroups.com> |
| In reply to | #14065 |
On Wednesday, October 2, 2013 6:06:16 AM UTC+3, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > I'm sure the vendors are very protective of their tricks and > > techniques. But the hardware is wide open. They may not give you all > > the gory details of what connects to what in an explicit way, > > How on earth can you say it's wide open, if I can't figure out what bits > to send into the chip to perform a given function? Why are they more > protective than CPU vendors? CPU's have manuals that specify the > instruction set in enough detail that I can write a compiler and > generate my own binaries to load into the CPU. With FPGA's it sounds > like I have to use the vendor compiler. > > > I guess what I am saying is that with the current approach in > > designing FPGAs you aren't missing anything except all the hard work. > > What if I want to write my own compiler, say to use the fpga as a > reconfigurable processor? Well you just cannot write your own tool producing the bitstream, this has been the case last 25 years or so (since xilinx do exist). Why do they play it so closed I don't know, must be about some sort of control. At which level and about exactly what I don't know, have not lost that much sleep thinking about it, really. But they certainly take no chances when it comes to control over the tools people use with their hardware. Here is an email exchange of mine from 13 years ago (when I was still naive enough to go into that but then I must have got some amusement in return, as you can see - it does not get a lot more moronic than that....): http://tgi-sci.com/misc/xiw.txt > > > If you ask for it and have a valid reason for wanting it I can't > > imagine they wouldn't share it with you. > > If they were willing to share the info with me for the purposes I have > in mind (maybe using Kansas Lava, a FOSS compiler for FPGA's), they > would publish the info and just sell me the hardware. Of course they would if they wanted to and of course they do not. I have been saying this in a number of threads also on comp.arch.fpga, anyone on that group will remember at least one of these. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-02 03:09 -0400 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l2ggs8$pgg$1@dont-email.me> |
| In reply to | #14065 |
On 10/1/2013 11:06 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> I'm sure the vendors are very protective of their tricks and >> techniques. But the hardware is wide open. They may not give you all >> the gory details of what connects to what in an explicit way, > > How on earth can you say it's wide open, if I can't figure out what bits > to send into the chip to perform a given function? The important parts of the design are there. Enough to understand how to *use* the chip. You don't need to know the bitstream file format to use it. You use the tools they give and get the work done. > Why are they more > protective than CPU vendors? CPU's have manuals that specify the > instruction set in enough detail that I can write a compiler and > generate my own binaries to load into the CPU. With FPGA's it sounds > like I have to use the vendor compiler. Yep, an MCU would be pretty useless without a very detailed description of the instruction set. But an FPGA only needs to tell you the equivalent of how to use all the bits and pieces inside. They don't need to tell you how to format the configuration stream unless you want to write your own tools. Writing your own tools does nothing for the FPGA vendor and will likely cause them problems. Why can't you see that? If they control the software they control the issues with it. Open source does nothing for them really and it could easily cause them a lot of bad press from some bad software the chip vendor then can do nothing about. >> I guess what I am saying is that with the current approach in >> designing FPGAs you aren't missing anything except all the hard work. > > What if I want to write my own compiler, say to use the fpga as a > reconfigurable processor? Like I said, you would be doing a lot of hard work for no reason. Why can't your reconfigurable processor be done in an existing HDL? Or why can't you write your own tools that then output an HDL? >> If you ask for it and have a valid reason for wanting it I can't >> imagine they wouldn't share it with you. > > If they were willing to share the info with me for the purposes I have > in mind (maybe using Kansas Lava, a FOSS compiler for FPGA's), they > would publish the info and just sell me the hardware. Yes, and they *aren't* willing to share the info. >>>> One *big* issue I have with the current tools is that they *are* >>>> licensed even though they are free (as in beer). > > They also may be dependent on specific cpu architectures. Maybe I want > to build an embedded gadget that generates fpga code on the fly and > loads it into the fpga. I can't run their Windows tools in the gadget. Hmmm... to date they haven't even been able to generate code that can be downloaded in a partial reconfiguration although what you are talking about may be an unrelated task. How exactly would that be a useful thing? What does the "embedded gadget" use as inputs and what variations would be made to the target FPGA code? I'm pretty sure all the vendors support Linux. Run a supported version of Linux on a BBB and see if you can run any CAD tools in 512 kB of RAM. It has been a long time since PCs came with only 512 kB of RAM and I expect that wouldn't even load the tools. >> Heck, I would just love to see the FPGA vendors come out with devices >> in packages like MCUs so that I can use FPGAs in more MCU-like > > Maybe there is a technical reason why they don't do that. Yes, it's called market and profit. The market at the low end has little profit unless the volumes are really big. I only know of one vendor with chips aimed at this market and they mostly use packages that are undesirable for lower volume runs, tiny 0.4 mm pitch ball grid arrays. Not my cup of tea. They want to sell to cell phones and tablets where size and power is king and one design win will sell a million chips. But then so would I... Chip they make... --- | | --- Chip I want, |||||||||||||||| ---------------- -| |- -| |- -| |- -| |- -| |- -| |- -| |- ---------------- |||||||||||||||| Well, ascii art isn't so good at this. Some of the chips they make are actually smaller than I drew and the chip I currently use is also smaller than I drew, 100 pin QFP. But the ratio may be similar. I don't want to deal with such tiny geometries and the boards I would have to build to use the tiny chips. Heck, I'd be happy with a 64 pin QFP too! The GA144 comes in a good package. 88 pin, 0.4 mm pitch QFN with one row of pins, easy to route and will work with 6/6 space and trace. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-02 00:51 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7xa9isp0tz.fsf@ruckus.brouhaha.com> |
| In reply to | #14071 |
rickman <gnuarm@gmail.com> writes: > The important parts of the design are there. Enough to understand how > to *use* the chip. You don't need to know the bitstream file format > to use it. You use the tools they give and get the work done. That's like saying a Windows PC is open because I can run Microsoft Word on it. No. I consider programming the PC (or FPGA), with my own code and my own compilers, to be part of "using" it. > Writing your own tools does nothing for the FPGA vendor and will > likely cause them problems. I wonder why CPU vendors are always trying to get people to write tools. Could it be that the FPGA vendors are just plain short-sighted? > why can't you write your own tools that then output an HDL? How do I load the generated HDL into the FPGA, in my embedded board? It doesn't run Windows and can't run the vendor tools. > Hmmm... to date they haven't even been able to generate code that can > be downloaded in a partial reconfiguration although what you are > talking about may be an unrelated task. I don't understand what you mean by that. I could see wanting to generate FPGA code on the fly, just like lots of programs generate CPU code on the fly. > What does the "embedded gadget" use as inputs and what variations > would be made to the target FPGA code? An example might be an ethernet packet filter, something like a hardware version of BPF (Berkeley Packet Filter). BPF takes filtering rules and compiles them into machine code that runs in your computer's network stack. You can change the rules on the fly and it generates new code and loads it. You could imagine having automated intrusion detection generate new rules and compile them, as it sees attacks taking shape. Now it wants to load the new code into the FPGA. It is unattended so there is nobody around to click "accept the license agreement". What is your advice? > I'm pretty sure all the vendors support Linux. Including ARM linux? I doubt that. Don't they want dongles and crap like that? Are you suggesting having a separate dongle for every chip? > The GA144 comes in a good package. 88 pin, 0.4 mm pitch QFN with one > row of pins, easy to route and will work with 6/6 space and trace. It's very hard to use that chip though, as you are well aware.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-02 03:58 -0400 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l2gjop$960$1@dont-email.me> |
| In reply to | #14073 |
On 10/2/2013 3:51 AM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> The important parts of the design are there. Enough to understand how >> to *use* the chip. You don't need to know the bitstream file format >> to use it. You use the tools they give and get the work done. > > That's like saying a Windows PC is open because I can run Microsoft Word > on it. No. I consider programming the PC (or FPGA), with my own code > and my own compilers, to be part of "using" it. Ok, I'm done with this part of the discussion. You have your ideas of what is needed and I have mine. >> Writing your own tools does nothing for the FPGA vendor and will >> likely cause them problems. > > I wonder why CPU vendors are always trying to get people to write tools. > Could it be that the FPGA vendors are just plain short-sighted? You clearly don't understand FPGAs, or more specifically the FPGA market. Until you are willing to open your mind to the idea that FPGAs aren't MCUs you won't be able to understand it. >> why can't you write your own tools that then output an HDL? > > How do I load the generated HDL into the FPGA, in my embedded board? > It doesn't run Windows and can't run the vendor tools. You seem obsessed with Windows. As I have said, the tools run under other OS. I think you vastly underestimate the horsepower required to run FPGA design tools as well. Do you really think they will run on an ARM9 effectively? >> Hmmm... to date they haven't even been able to generate code that can >> be downloaded in a partial reconfiguration although what you are >> talking about may be an unrelated task. > > I don't understand what you mean by that. I could see wanting to > generate FPGA code on the fly, just like lots of programs generate CPU > code on the fly. Yes, I can see that you don't understand. >> What does the "embedded gadget" use as inputs and what variations >> would be made to the target FPGA code? > > An example might be an ethernet packet filter, something like a hardware > version of BPF (Berkeley Packet Filter). BPF takes filtering rules and > compiles them into machine code that runs in your computer's network > stack. You can change the rules on the fly and it generates new code > and loads it. You could imagine having automated intrusion detection > generate new rules and compile them, as it sees attacks taking shape. > Now it wants to load the new code into the FPGA. It is unattended so > there is nobody around to click "accept the license agreement". What is > your advice? Design a filter that can be configured and compile that once. I don't see anything in your description that requires a design to be recompiled. I think you are also underestimating the complexity of generating and compiling code for an FPGA. It ain't an MCU. >> I'm pretty sure all the vendors support Linux. > > Including ARM linux? I doubt that. Don't they want dongles and crap > like that? Are you suggesting having a separate dongle for every chip? So run an Atom! No, the license doesn't use a dongle. I don't use batch mode myself, but I understand all the tools can be operated with a script, many people do that. >> The GA144 comes in a good package. 88 pin, 0.4 mm pitch QFN with one >> row of pins, easy to route and will work with 6/6 space and trace. > > It's very hard to use that chip though, as you are well aware. I'm only talking about the package... geeze. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-02 01:27 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7xmwmsgjs7.fsf@ruckus.brouhaha.com> |
| In reply to | #14074 |
rickman <gnuarm@gmail.com> writes: >> I wonder why CPU vendors are always trying to get people to write tools. > FPGAs aren't MCUs you won't be able to understand it. They're chips that people load bits into. "Q. Why can I run my own compilers for the x86 but not the ARM? A. The ARM is not an x86 and you won't be able to understand it". I would just say I *do* understand it: one set of PHB's is stupider than the other set. > I think you vastly underestimate the horsepower required to run FPGA > design tools as well. Do you really think they will run on an ARM9 > effectively? FPGA's have been around since the 1990's or maybe earlier. The tools ran on PC's of that era. Today's ARM's are about equivalent to those old PC's. So the tools should be able to run on today's ARM's. > Design a filter that can be configured and compile that once. The idea is you want to compile the filter directly to combinational logic so it can run at maximum speed. And the filters can be very complex and have a lot of stuff going on in parallel. It can't really be turned into fixed code with some parameters: that's why BPF generates machine code for CPU's. The idea of the FPGA version is to filter 100 gigabit DOS attacks: http://www.eweek.com/security/latest-100-gigabit-attack-is-one-of-internets-largest.html If it makes things more interesting to you, there is big money in this, if you can figure out how to make it happen.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-02 04:24 -0400 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l2gl9o$hva$1@dont-email.me> |
| In reply to | #14075 |
On 10/2/2013 4:27 AM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >>> I wonder why CPU vendors are always trying to get people to write tools. >> FPGAs aren't MCUs you won't be able to understand it. > > They're chips that people load bits into. "Q. Why can I run my own > compilers for the x86 but not the ARM? A. The ARM is not an x86 and you > won't be able to understand it". I would just say I *do* understand it: > one set of PHB's is stupider than the other set. Lol! I think the proof of the pudding is in the eating... >> I think you vastly underestimate the horsepower required to run FPGA >> design tools as well. Do you really think they will run on an ARM9 >> effectively? > > FPGA's have been around since the 1990's or maybe earlier. The tools > ran on PC's of that era. Today's ARM's are about equivalent to those > old PC's. So the tools should be able to run on today's ARM's. Yes, so you can run tools on an ARM to design the XC3000 chips with 500 LUTs. Go for it! >> Design a filter that can be configured and compile that once. > > The idea is you want to compile the filter directly to combinational > logic so it can run at maximum speed. And the filters can be very > complex and have a lot of stuff going on in parallel. It can't really > be turned into fixed code with some parameters: that's why BPF generates > machine code for CPU's. The idea of the FPGA version is to filter 100 > gigabit DOS attacks: > > http://www.eweek.com/security/latest-100-gigabit-attack-is-one-of-internets-largest.html > > If it makes things more interesting to you, there is big money in this, > if you can figure out how to make it happen. Yeah... I don't think the solution is to swim upstream against the FPGA makers. Why not try something that might actually work? If all you want to do is to implement combinational logic, you don't need the FPGA compiling tools. The LUTs are small memories. I believe they can be configured in ways that allow you to both use them as logic and to change their contents. It is the interconnect that you won't be able to mess with. So configure a network of LUTs and then reload them at will to implement your logic. Where do I get my money? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-02 01:54 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7xd2nonjcd.fsf@ruckus.brouhaha.com> |
| In reply to | #14076 |
rickman <gnuarm@gmail.com> writes: > If all you want to do is to implement combinational logic, Well, there is also some state. And maybe complex computation in some situations, though probably not for DOS filtering. > you don't need the FPGA compiling tools. The LUTs are small memories. > I believe they can be configured in ways that allow you to both use > them as logic and to change their contents. Good plan. All you need now is the bitstream format. > It is the interconnect that you won't be able to mess with. You have much more flexibility if you can program the interconnect.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-02 19:51 -0400 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l2ibkv$dr7$1@dont-email.me> |
| In reply to | #14077 |
On 10/2/2013 4:54 AM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> If all you want to do is to implement combinational logic, > > Well, there is also some state. And maybe complex computation in some > situations, though probably not for DOS filtering. > >> you don't need the FPGA compiling tools. The LUTs are small memories. >> I believe they can be configured in ways that allow you to both use >> them as logic and to change their contents. > > Good plan. All you need now is the bitstream format. Silly boy. You are so stuck in your rut. The point is you can change the contents of the LUT from the design without needing to reconfigure the device. IF you were to spend some time with the existing FPGAs and the existing tools to actually learn something about them, then perhaps you might realize that. >> It is the interconnect that you won't be able to mess with. > > You have much more flexibility if you can program the interconnect. Yes, and if pigs had wings they could fly. Do you want to solve a problem or daydream your time away? BTW, I want my money now. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-03 00:17 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7xzjqqrfga.fsf@ruckus.brouhaha.com> |
| In reply to | #14098 |
rickman <gnuarm@gmail.com> writes: > Silly boy. You are so stuck in your rut. The point is you can change > the contents of the LUT from the design without needing to reconfigure > the device. That sounds like the equivalent of a table-driven filter interpreted by a fixed software program. Native compilation gives much higher performance. You'll always be able to synthesize a smaller circuit for a single function than a universal one. And since it's smaller, you can replicate more of them across the same sized device. > Yes, and if pigs had wings they could fly. Do you want to solve a > problem or daydream your time away? I'm always interested in cool technology, but am I trying to build FPGA-based packet filters right this minute--no I'm not. If I were a manufacturer committed to shipping a particular product that needed FPGA's, I'd have no choice but to go along with the current vendor offerings. If I were a wannabe-entrepreneur casting around for product concepts without already being committed to anything in particular, I'd consider the need for closed-source software to be a significant disincentive against using a technology. So if I couldn't use FOSS FPGA tools, maybe I'd just choose to build something without FPGA's. The hardware product I'd like right now is a compact outlet strip with about 20 outlets instead of the usual 6 or 7. I'm not the guy to build it, but it doesn't exist right now, there's an obvious market for it, and making it doesn't need FPGA tools or any other closed source software. In reality, FPGA's are not like super-CPU's in terms of complexity. They're more like memory, i.e. a sea of relatively simple, replicated structures. So my current theory is that FPGA vendors tenaciously try to prevent FPGA's from turning into commodity devices like memory, which would be a natural outcome of stuff being open. They instead want to sell them as super-powerful devices more complicated than CPU's. I can understand the business motivation for that, but it seems ripe for disruption. There's sort of a similar situation with GPU's. For a long time the instruction sets for those were proprietary. But they've been opening up. So I'm holding out for the same thing happens with FPGA's.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-04 00:27 -0400 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l2lg4j$75j$1@dont-email.me> |
| In reply to | #14100 |
On 10/3/2013 3:17 AM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> Silly boy. You are so stuck in your rut. The point is you can change >> the contents of the LUT from the design without needing to reconfigure >> the device. > > That sounds like the equivalent of a table-driven filter interpreted by > a fixed software program. Native compilation gives much higher > performance. You'll always be able to synthesize a smaller circuit for > a single function than a universal one. And since it's smaller, you can > replicate more of them across the same sized device. Except for one small detail. You *can't* implement your idea. I can implement mine. >> Yes, and if pigs had wings they could fly. Do you want to solve a >> problem or daydream your time away? > > I'm always interested in cool technology, but am I trying to build > FPGA-based packet filters right this minute--no I'm not. If I were a > manufacturer committed to shipping a particular product that needed > FPGA's, I'd have no choice but to go along with the current vendor > offerings. If I were a wannabe-entrepreneur casting around for product > concepts without already being committed to anything in particular, I'd > consider the need for closed-source software to be a significant > disincentive against using a technology. So if I couldn't use FOSS FPGA > tools, maybe I'd just choose to build something without FPGA's. The > hardware product I'd like right now is a compact outlet strip with about > 20 outlets instead of the usual 6 or 7. I'm not the guy to build it, > but it doesn't exist right now, there's an obvious market for it, and > making it doesn't need FPGA tools or any other closed source software. Uh, yes, I think buiding this would require closed source tools... drills, screwdrivers, etc. I've never been supplied with plans for making *any* of those devices when I bought them. > In reality, FPGA's are not like super-CPU's in terms of complexity. > They're more like memory, i.e. a sea of relatively simple, replicated > structures. So my current theory is that FPGA vendors tenaciously try > to prevent FPGA's from turning into commodity devices like memory, which > would be a natural outcome of stuff being open. They instead want to > sell them as super-powerful devices more complicated than CPU's. I can > understand the business motivation for that, but it seems ripe for > disruption. Yes, this is the way they manage their market. But your analogy really isn't very realistic. FPGAs of the last 10 years have had a lot in them other than LUTs and FFs. I think they are reaching a critical point where over the next five or certainly 10 years they won't be able to sell the same sort of stuff the same ways because so few users will need 10,000,000 LUTs on a single chip. Instead the logic will be swimming upstream into more complex blocks like small CPUs and they will be programmed by software rather than a small LUT. This is what the GA144 is like and I think the future will be ~similar~ to this device. Maybe then they can become a commodity device. There won't be any "disruption" because there are too many patents. A new comer is severely constrained to rather old technology in many ways. Most large companies are patent trolls just like the ones everyone calls patent trolls... even the president. > There's sort of a similar situation with GPU's. For a long time the > instruction sets for those were proprietary. But they've been opening > up. So I'm holding out for the same thing happens with FPGA's. Don't hold out too long, you may be dead... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-03 23:09 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7xd2nlwor7.fsf@ruckus.brouhaha.com> |
| In reply to | #14138 |
rickman <gnuarm@gmail.com> writes: > Except for one small detail. You *can't* implement your idea. I can > implement mine. So we agree, the closed-source FPGA tool regime is preventing good ideas from being implemented. > There won't be any "disruption" because there are too many patents. Unfortunately probably true.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-04 09:30 -0400 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l2mfti$k5j$2@dont-email.me> |
| In reply to | #14142 |
On 10/4/2013 2:09 AM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> Except for one small detail. You *can't* implement your idea. I can >> implement mine. > > So we agree, the closed-source FPGA tool regime is preventing good ideas > from being implemented. Don't put words in my mouth. You can't implement your idea because the idea is to not use the tools. You can skin the real cat in other ways which you choose to ignore. >> There won't be any "disruption" because there are too many patents. > > Unfortunately probably true. So are you ready yet to learn about FPGAs and get some real work done? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-10-06 10:53 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <7x8uy6thez.fsf@ruckus.brouhaha.com> |
| In reply to | #14153 |
rickman <gnuarm@gmail.com> writes: > Don't put words in my mouth. You can't implement your idea because > the idea is to not use the tools. Yes, and the reason it's impossible to not use the Xilinx tools is because of the secret formats. Fix that, and the problem goes away. This guy makes the case for FOSS tools better than I do: http://blog.elphel.com/2013/10/fpga-is-for-freedom/ I don't claim he represents a huge part of the FPGA market, but he is making real products with them. He mentions that the no-fee version of the Xilinx tools connects to a Xilinx server and uploads your designs. I'd want to avoid using anything like that. So if I were to use Xilinx tools at all, I'd have to look into the paid versions, which sound expensive (I'd be interested to know). Here's a presentation (url from a comment on the above) about some guys trying to make FOSS tools by reverse engineering the formats: http://www.ohwr.org/attachments/821/sebastien.pdf I think that approach may get more difficult as more hard cells (ARM cores etc) find their way onto FPGA's, though. > So are you ready yet to learn about FPGAs and get some real work done? I do real work every day, and get paid for it. I hope you can say the same ;-). FPGA's are one of many outside interests that I like to be a bit informed about, but that I don't have time to get heavily involved in. The Elphel 393 camera (when it comes out, if it's affordable) might tempt me to want to program it, but it sounds like I'd have to use the paid Xilinx tools, which is a pretty significant disincentive. It's described in earlier posts on the blog linked above.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-10-09 05:12 -0400 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l336n2$s00$1@dont-email.me> |
| In reply to | #14244 |
On 10/6/2013 1:53 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> Don't put words in my mouth. You can't implement your idea because >> the idea is to not use the tools. > > Yes, and the reason it's impossible to not use the Xilinx tools is > because of the secret formats. Fix that, and the problem goes away. What problem? I don't have a problem. > This guy makes the case for FOSS tools better than I do: > > http://blog.elphel.com/2013/10/fpga-is-for-freedom/ I didn't see much of a case. It is all just his opinion with no real facts that don't relate to a Soviet Union analog. > I don't claim he represents a huge part of the FPGA market, but he is > making real products with them. > > He mentions that the no-fee version of the Xilinx tools connects to a > Xilinx server and uploads your designs. I'd want to avoid using > anything like that. So if I were to use Xilinx tools at all, I'd have > to look into the paid versions, which sound expensive (I'd be interested > to know). That is an extreme exaggeration. The tools work just as well disconnected from the internet. From the Xilinx web page on this... Can I use WebPACK software on a machine that is not connected to the internet? Yes. WebTalk does not prevent design compilation on a machine that is not connected to the internet. So you can simply disconnect from the Internet when you run the Xilinx tool. Personally I find this level of snooping to be insane from a business perspective. I'm sure there are any number of users who will strongly object to it. Great reason to never use another Xilinx part again regardless of FOSS. > Here's a presentation (url from a comment on the above) about some guys > trying to make FOSS tools by reverse engineering the formats: > > http://www.ohwr.org/attachments/821/sebastien.pdf > > I think that approach may get more difficult as more hard cells (ARM > cores etc) find their way onto FPGA's, though. I don't really care. They are trying to solve a problem I don't have. >> So are you ready yet to learn about FPGAs and get some real work done? > > I do real work every day, and get paid for it. Obviously not with FPGAs. > I hope you can say the > same ;-). FPGA's are one of many outside interests that I like to be a > bit informed about, but that I don't have time to get heavily involved > in. > > The Elphel 393 camera (when it comes out, if it's affordable) might > tempt me to want to program it, but it sounds like I'd have to use the > paid Xilinx tools, which is a pretty significant disincentive. It's > described in earlier posts on the blog linked above. No, it should be supported by the free tools. He said that in the blog. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-10-09 02:24 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <8c115635-690a-4639-aea0-c1b9846ecb93@googlegroups.com> |
| In reply to | #14307 |
On Wednesday, October 9, 2013 12:12:34 PM UTC+3, rickman wrote: > On 10/6/2013 1:53 PM, Paul Rubin wrote: > > rickman<gnuarm@gmail.com> writes: > >> Don't put words in my mouth. You can't implement your idea because > >> the idea is to not use the tools. > > > > Yes, and the reason it's impossible to not use the Xilinx tools is > > because of the secret formats. Fix that, and the problem goes away. > > What problem? I don't have a problem. > Other people do have a problem with that, though. > > > He mentions that the no-fee version of the Xilinx tools connects to a > > Xilinx server and uploads your designs. I'd want to avoid using > > anything like that. So if I were to use Xilinx tools at all, I'd have > > to look into the paid versions, which sound expensive (I'd be interested > > to know). > > That is an extreme exaggeration. The tools work just as well > disconnected from the internet. I remember quite well a thread from some 5 or 10 years ago on comp.arch.fpga based on people having caught the xilinx tools do as alleged. > From the Xilinx web page on this... > > Can I use WebPACK software on a machine that is not connected to the > internet? > > Yes. WebTalk does not prevent design compilation on a machine that is > not connected to the internet. Nor does it store the details for subsequent transfer over the net? Ah, but you don't know that. Me again asking silly questions. Dimiter
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2013-10-09 12:05 +0000 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <l33gpu$5qa$4@dont-email.me> |
| In reply to | #14309 |
On 2013-10-09, dp <dp@tgi-sci.com> wrote: > On Wednesday, October 9, 2013 12:12:34 PM UTC+3, rickman wrote: >> On 10/6/2013 1:53 PM, Paul Rubin wrote: >> > He mentions that the no-fee version of the Xilinx tools connects to a >> > Xilinx server and uploads your designs. I'd want to avoid using >> > anything like that. So if I were to use Xilinx tools at all, I'd have >> > to look into the paid versions, which sound expensive (I'd be interested >> > to know). >> >> That is an extreme exaggeration. The tools work just as well >> disconnected from the internet. > > I remember quite well a thread from some 5 or 10 years ago on > comp.arch.fpga based on people having caught the xilinx tools > do as alleged. > _Assuming_ this is a accurate description of the situation, then that's just _totally_ killed my interest in Xilinx. What I don't understand is why people tolerate this. Is it because it's not made clear to them what's going on, or is it simply because they have no choice ? Could you imagine the outrage if it turned out that, say, Microchip's free toolchains uploaded a user's project to Microchip and that the only way you could work around it was to use their tools while disconnected from the Internet ? If Microchip did something that daft, it would kill the use of their tools stone dead. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | dp <dp@tgi-sci.com> |
|---|---|
| Date | 2013-10-09 08:06 -0700 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <d6171098-57bb-4f12-9a1d-5789356a1499@googlegroups.com> |
| In reply to | #14313 |
On Wednesday, October 9, 2013 3:05:19 PM UTC+3, Simon Clubley wrote: > On 2013-10-09, dp <dp@tgi-sci.com> wrote: > > On Wednesday, October 9, 2013 12:12:34 PM UTC+3, rickman wrote: > >> On 10/6/2013 1:53 PM, Paul Rubin wrote: > >> > He mentions that the no-fee version of the Xilinx tools connects to a > >> > Xilinx server and uploads your designs. I'd want to avoid using > >> > anything like that. So if I were to use Xilinx tools at all, I'd have > >> > to look into the paid versions, which sound expensive (I'd be interested > >> > to know). > >> > >> That is an extreme exaggeration. The tools work just as well > >> disconnected from the internet. > > > > I remember quite well a thread from some 5 or 10 years ago on > > comp.arch.fpga based on people having caught the xilinx tools > > do as alleged. > > > > _Assuming_ this is a accurate description of the situation, then that's > just _totally_ killed my interest in Xilinx. > My memory on that is vague, what I remember is that xilinx had been denying the issue first, then claimed the data were "immaterial" or something in that line and eventually I think deleted the caught feedback thing. Even if todays tools work on a non-netowrked PC (where "work" may turn out to be more than "compile" - which is what they state) this still means the added cost of a dedicated PC. Then copying to/from that PC should never be done under any form if one wants to guarantee the data won't go out, no flash sticks, nothing. So much about the "free". > What I don't understand is why people tolerate this. Is it because it's > not made clear to them what's going on, or is it simply because they have > no choice ? No idea, I suppose most of them just don't care. I have no issue with much of my designs going out either, not so long ago I did use a xilinx (ABEL) tool to program a CPLD; the jedec file is even available on the net (not directly but as a file on an installable DPS disk image). But there *are* things I would not let into public domain, e.g. the spectrometry DSP conversion algorithms. And an FPGA being large enough can contain some of the things I would not leave out. Then while I did compromise with ABEL once - for a simple 128 cell CPLD - I am still completely independent on other software in my design process, that is if all wintel etc. machines disappear I can still go on as usual. Minor headaches because of that yes, I do use a PC as a .pdf reader and as a browser, but nothing major. I might still use an fpga on their terms, e.g. there is just *no* display controller to be had on the market and there are FPGA-s which could do it easily, having DDRAM interface etc.; but there are applications where I might opt to use one only if I were sure I could use my own tools (nothing pressing at the moment though). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-10-04 10:01 +0100 |
| Subject | Re: Open source FPGA toolchain ?, was: Re: Small, fast, resource-rich processor |
| Message-ID | <2uv3u.13539$eW3.895@fx23.am4> |
| In reply to | #14138 |
On 04/10/13 05:27, rickman wrote: > FPGAs of the last 10 years have had a lot in them other than LUTs and FFs. I think they are reaching a > critical point where over the next five or certainly 10 years they won't be able to sell the same sort of stuff the same ways because so few users will need 10,000,000 LUTs on a single chip. Instead > the logic will be swimming upstream into more complex blocks like small CPUs and they will be programmed by software rather than a small LUT. Isn't that what is already happening with, for example, the Zynq devices? Dual core ARMs, memory interfaces, all sorts of i/o interfaces from 1000Mb/s ethernet to I2C, plus small amounts of everything you find in high-end FPGAs (SERDES, block RAM, DSP slices etc). > This is what the GA144 is like and I think the future > will be ~similar~ to this device. Maybe then they can become a commodity device. I'd rather bet on the XMOS devices to "cross the chasm". Their programming model is more familiar and they have financial backing, and you can buy their boards and chips from digikey.
[toc] | [prev] | [next] | [standalone]
Page 15 of 22 — ← Prev page 1 … 13 14 [15] 16 17 … 22 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web