Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16579 > unrolled thread
| Started by | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| First post | 2012-10-22 08:53 -0700 |
| Last post | 2012-10-23 10:52 +0000 |
| Articles | 20 on this page of 172 — 22 participants |
Back to article view | Back to comp.lang.forth
RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-22 08:53 -0700
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-22 11:21 -0500
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 09:56 -0700
Re: RTX2000 optimization Mark Wills <forthfreak@gmail.com> - 2012-10-22 12:10 -0700
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 12:55 -0700
Re: RTX2000 optimization Coos Haak <chforth@hccnet.nl> - 2012-10-22 22:02 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-22 16:50 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 21:52 -0400
Re: RTX2000 optimization Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 22:03 -0700
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-23 03:19 -0500
Re: RTX2000 optimization vandys@vsta.org - 2012-10-23 17:54 +0000
Re: RTX2000 optimization Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 08:16 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:19 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-24 06:56 -0400
Re: RTX2000 optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-24 12:26 +0000
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 15:25 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:30 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 22:10 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 16:43 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 17:55 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:44 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-27 02:17 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 23:01 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-27 22:18 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-27 19:19 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-28 04:21 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 14:36 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-29 19:06 -0400
Re: RTX2000 optimization Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-30 02:07 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-30 09:36 -0400
Re: RTX2000 optimization Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-30 08:09 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-30 19:14 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-30 18:50 -0400
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-31 07:37 -0700
Re: RTX2000 optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-31 15:27 +0000
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-31 08:59 -0700
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-31 11:18 -0500
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-31 13:49 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-31 13:43 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 12:03 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Mark Wills <forthfreak@gmail.com> - 2012-10-31 09:05 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] daveyrotten <danw8804@gmail.com> - 2012-10-31 09:06 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-10-31 09:25 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] danw8804@gmail.com - 2012-10-31 09:38 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-10-31 14:30 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-10-31 14:27 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-10-31 12:01 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-10-31 16:31 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-10-31 20:33 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-01 14:05 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-01 11:23 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-01 14:31 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-02 22:11 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 12:50 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-03 10:42 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 13:59 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-03 12:10 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 15:42 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-03 15:56 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-03 20:53 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-04 11:10 +0000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-04 22:58 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 15:29 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 14:40 +0000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-05 11:36 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-05 09:02 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-05 15:22 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-05 12:56 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 12:22 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-06 09:29 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 12:53 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-06 10:00 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-06 08:04 -1000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 13:37 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 21:06 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-05 15:29 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-06 16:28 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] rickman <gnuarm@gmail.com> - 2012-11-06 12:50 -0500
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-07 20:29 -0800
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-04 10:40 +0000
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-01 21:26 +0100
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] Paul Rubin <no.email@nospam.invalid> - 2012-11-01 13:44 -0700
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-02 04:03 -0400
Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] David Schultz <abuse@127.0.0.1> - 2012-11-04 17:17 -0600
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-11-02 12:48 -0700
Re: RTX2000 optimization "Elizabeth D. Rather" <erather@forth.com> - 2012-11-02 10:25 -1000
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-11-02 19:54 -0700
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 17:47 +0100
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-11-03 14:05 -0400
Re: RTX2000 optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 11:55 +0000
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-11-03 19:20 -0700
Re: RTX2000 optimization mhx@iae.nl (Marcel Hendrix) - 2012-11-04 16:08 +0200
Re: RTX2000 optimization mhx@iae.nl (Marcel Hendrix) - 2012-11-04 17:14 +0200
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-04 18:40 +0100
Re: RTX2000 optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 09:36 -0600
Re: RTX2000 optimization Andy Valencia <vandys@vsta.org> - 2012-11-04 23:49 +0000
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-31 12:11 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 20:08 -0400
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-11-01 10:59 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-11-01 12:12 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-11-01 12:14 -0700
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-11-02 10:51 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-11-02 11:28 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-11-01 14:58 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 14:45 +0100
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 15:04 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 21:09 +0100
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 16:59 -0400
Re: RTX2000 optimization albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-28 07:59 +0000
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 15:06 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 16:35 -0400
Re: RTX2000 optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 12:44 +0000
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:32 -0400
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-22 13:54 -0700
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 14:14 -0700
Re: RTX2000 optimization daveyrotten <danw8804@gmail.com> - 2012-10-22 14:26 -0700
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 16:00 -0700
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 21:51 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:36 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-24 08:47 -0400
Re: RTX2000 optimization Alex McDonald <blog@rivadpm.com> - 2012-10-24 06:36 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 15:33 -0400
Re: RTX2000 optimization Alex McDonald <blog@rivadpm.com> - 2012-10-25 04:54 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 17:35 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 15:27 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 19:10 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 18:34 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:03 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:56 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 18:34 +0200
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 22:27 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:27 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:17 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 19:44 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-26 19:59 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:42 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:55 -0400
Re: RTX2000 optimization Alex McDonald <blog@rivadpm.com> - 2012-10-25 04:49 -0700
addressable stack, was [Re: RTX2000 optimization] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-05 14:04 -0500
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 15:44 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-25 00:50 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 18:58 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 16:07 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 19:20 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-26 20:57 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-27 15:43 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-28 05:01 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-28 15:23 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-29 19:32 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-30 19:00 -0400
Re: RTX2000 optimization "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 01:23 -0400
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-31 14:56 -0400
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-22 19:44 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 17:47 -0400
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-23 16:00 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-23 21:07 -0400
Re: RTX2000 optimization visualforth@rocketmail.com - 2012-10-23 18:44 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 16:03 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 13:15 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 16:25 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 03:15 +0200
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-24 09:55 -0700
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 10:04 -0700
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-24 12:00 -0700
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 23:24 -0700
Re: RTX2000 optimization Brad Eckert <hwfwguy@gmail.com> - 2012-10-25 09:26 -0700
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-25 10:39 -0700
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-25 19:35 -0400
Re: RTX2000 optimization Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-26 18:26 +0200
Re: RTX2000 optimization rickman <gnuarm@gmail.com> - 2012-10-24 16:10 -0400
Re: RTX2000 optimization Paul Rubin <no.email@nospam.invalid> - 2012-10-24 13:21 -0700
Re: RTX2000 optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 10:52 +0000
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-04 11:10 +0000 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <50964c46.93375896@192.168.0.50> |
| In reply to | #17022 |
On Sat, 03 Nov 2012 20:53:30 -0400, rickman <gnuarm@gmail.com> wrote: >A 10 year old FPGA >runs my CPU at 50 MHz and today's Cortex M4 processors don't run much >faster than that, at least from Flash, maybe push 100 MHz from RAM. STM32F4xx run 168MHz from Flash and have 1Mb Flash, 192kb RAM and a shed-load of peripherals on-chip. Cheap too. Just a reference point. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-04 22:58 -0800 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <7xy5ig1qp6.fsf@ruckus.brouhaha.com> |
| In reply to | #17022 |
rickman <gnuarm@gmail.com> writes: > Unless you have some novel ideas I think yes, this is a bit > unrealistic. The NRE may be high on more current technology, but even > 90 nm would be a bit advantage over 350 nm and the costs would be > worthwhile if there is any sort of a market I would think. Bernd's paper on the b16 mentions the b16 uses 0.4 mm**2 in a TSMC 0.5 micron process (I think "nanometers" came into use around when feature sizes dropped below 0.1u). So other things being equal, that would scale to 0.2 mm**2 at 0.35u. The smallest chip you can order is 3 mm**2 which would be 15 processors, hmm, yeah, you probably do need either a bigger chip or a smaller process. Might still be feasible at a few notches up the scale. This was actually the first application I thought of for the GA144, but the GA architecture is of course completely wrong for it. > Yes, you can even connect somewhere in excess of 2.5 Gbps directly to > FPGAs. I'm not current on just how fast you can do this. Many of > them have SERDES built in, just not sure how fast they go. I'm seeing there are some astoundingly powerful FPGAs now, including some with 28 gigabit inputs, high end ARM cores as hard cells, etc. They are crazy expensive (Altera Stratix V GT). :-O. > I would think the value of bitcoins might increase because of the > increased costs. That's the hope of the participants, but remember, they're a commodity, they're not consumed, they circulate and trade on exchanges. They're hard to produce but they're not terribly scarce and their prices derive mostly from crazy speculation. >> I suspect that people who bought expensive FPGA mining rigs > Ok, so it's a bit like selling the stuff for custom PCs, not because > they are faster so much, but because they are *cool*. Also like > hotrod cars. Possibilities... But in 350 nm? Maybe, maybe not. If > the point is speed, then the really old technology won't cut it I > think. FPGAs may be faster for the $$$. Not sure. Yeah, old numbers were that ASIC's were an order of magnitude smaller and faster than FPGA's that did the same thing, i.e. by using an ASIC you get the equivalent of an FPGA that is several process nodes more advanced. I don't know if this still holds. Power consumption also matters. A bitcoin is worth maybe $10, so if it takes 100 KWH to mine one, at least here in California you're losing money by mining. > [Novix-like Forth processor] A 10 year old FPGA runs my CPU at 50 MHz > ... I wonder how fast it might run in 350 nm? The Pentium II ran at 233 mhz in 350nm, if I'm reading Wikipedia properly. Bernd mentions the b16 at 100 mhz in 0.5u. >> There is certainly a commercial market for security hardware > They don't trust nobody! Very paranoid about the backdoor thing. Who > is the market for a security chip specifically? Do you have expertise > in this? ... If it can be done on a shoestring, it can be copied on an > even smaller shoestring. I have some knowledge of the software side: I've programmed commercial units and have implemented a software workalike. As before I'm near-clueless about hardware. Besides the chip, you need tamper-reactive packaging, EM shielding, isolated power supplies, etc. But it doesn't have to be particularly miniaturized. I wouldn't worry too much about copying. The industry making these things is very conservative and if they think you're doing something that threatens them, they'd probably rather buy you out than copy you. There's a saying that if your idea is REALLY good, nobody will steal it--you will instead have to ram it down their throats ;-). I can also see some point to a relatively low cost product with less excessive anti-tamper stuff, for use in ordinary private business communications. Existing general purpose PC's are so full of backdoors and security holes that it's time for dedicated hardware to make a comeback. And IMHO the Freedom Box would be more interesting with a chip like this. I notice recently there's a kickstarter for a FOSS SOC with some 32-bit core and peripherals, even though the development chain isn't all FOSS. So maybe a chip made with all-FOSS (so it's auditable) would also be of interest.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-05 15:29 +0100 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <4378286.dMOIpiY8I0@sunwukong.fritz.box> |
| In reply to | #17055 |
Paul Rubin wrote: > The Pentium II ran at 233 mhz in 350nm, if I'm reading Wikipedia > properly. Bernd mentions the b16 at 100 mhz in 0.5u. I've some newer data for smaller processes: At 180nm (TSMC compatible logic process), the small/slow version synthesized to 250MHz (optimized for size, not on speed); I would suppose that if you synthesize and tradeoff the design for speed, it would run at 500MHz. That's "worst case process, worst case supply and worst case temperature (125°C)". And of course, that's adder in one cycle, not in two. Note that the size mentioned is without memory and without peripherals, which can be quite useful. I usually have a timer (free-running, with one to three compare registers), an SPI or UART for debugging and an I²C for the interface the customer likes. Plus registers to controll the actual stuff (analog circuit or PWM outputs for stepper motors). The "others" plus the memory dominate the total area, and I don't buy into the "the CPU does all the peripheral stuff". The CPU does what's useful, so when I have to generate PWMs, I can e.g. use the CPU+timer to generate PWM output. Chuck would probably do with CPU and a loop. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-05 14:40 +0000 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <2012Nov5.154058@mips.complang.tuwien.ac.at> |
| In reply to | #17063 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Paul Rubin wrote:
>> The Pentium II ran at 233 mhz in 350nm, if I'm reading Wikipedia
>> properly. Bernd mentions the b16 at 100 mhz in 0.5u.
>
>I've some newer data for smaller processes: At 180nm (TSMC compatible
>logic process), the small/slow version synthesized to 250MHz (optimized
>for size, not on speed); I would suppose that if you synthesize and
>tradeoff the design for speed, it would run at 500MHz. That's "worst
>case process, worst case supply and worst case temperature (125°C)".
>And of course, that's adder in one cycle, not in two.
And for comparing with Intel, I have some data at
<http://www.complang.tuwien.ac.at/anton/cpu-clocks.html>. The 0.35u
Pentium II reached 300MHz, the 180nm Pentium III 1100MHz, Pentium 4
2000MHz, and AMD Palomino 1700MHz.
The switch from micrometers to nanometers came with the 180nm
generation.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-05 11:36 -0500 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k78pu8$jff$1@dont-email.me> |
| In reply to | #17063 |
On 11/5/2012 9:29 AM, Bernd Paysan wrote: > Paul Rubin wrote: >> The Pentium II ran at 233 mhz in 350nm, if I'm reading Wikipedia >> properly. Bernd mentions the b16 at 100 mhz in 0.5u. > > I've some newer data for smaller processes: At 180nm (TSMC compatible > logic process), the small/slow version synthesized to 250MHz (optimized > for size, not on speed); I would suppose that if you synthesize and > tradeoff the design for speed, it would run at 500MHz. That's "worst > case process, worst case supply and worst case temperature (125°C)". > And of course, that's adder in one cycle, not in two. > > Note that the size mentioned is without memory and without peripherals, > which can be quite useful. I usually have a timer (free-running, with > one to three compare registers), an SPI or UART for debugging and an I²C > for the interface the customer likes. Plus registers to controll the > actual stuff (analog circuit or PWM outputs for stepper motors). The > "others" plus the memory dominate the total area, and I don't buy into > the "the CPU does all the peripheral stuff". The CPU does what's > useful, so when I have to generate PWMs, I can e.g. use the CPU+timer to > generate PWM output. Chuck would probably do with CPU and a loop. Once you get the cores to the point that they are as plentiful as on the GA144 I don't see a problem with using them for software peripherals. The problem with dedicated peripherals is that they are dedicated! MCU makers deal with this by producing a *huge* number of variations on a theme. I have even seen chips that you might think were dedicated logic and turned out to be a CPU with a special interface. I think the FTDI USB interface chips are like that, with a high speed custom CPU inside. The problem with CPU peripherals is when the peripheral software doesn't work so well. The GA144 is a great example. The "memory interface" is just a pair of 18 bit parallel ports on separate CPU cores. This won't run an SDRAM even at 50 MHz with a clock. Maybe a way can be found to run it asynchronously with a random clock from the CPU, I couldn't make it work at 50 MHz. 100 Mbps Ethernet would be quite a chore and 480 Mbps USB is likely impossible. It would be *easy* to add an SDRAM controller to a chip like the GA144 and I would never consider omitting it on any chip I build. Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-05 09:02 -0800 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <7xfw4of0ec.fsf@ruckus.brouhaha.com> |
| In reply to | #17068 |
rickman <gnuarm@gmail.com> writes: >> useful, so when I have to generate PWMs, I can e.g. use the CPU+timer to >> generate PWM output. Chuck would probably do with CPU and a loop. > Once you get the cores to the point that they are as plentiful as on > the GA144 I don't see a problem with using them for software > peripherals. Part of the GA vision is ultra low power consumption by keeping most of the cores idle most of the time, with very low leakage current. Implementing something as simple as a timer with a full speed cpu-busy loop seems to go against the purpose.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-05 15:22 -0500 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k79770$l11$1@dont-email.me> |
| In reply to | #17069 |
On 11/5/2012 12:02 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >>> useful, so when I have to generate PWMs, I can e.g. use the CPU+timer to >>> generate PWM output. Chuck would probably do with CPU and a loop. >> Once you get the cores to the point that they are as plentiful as on >> the GA144 I don't see a problem with using them for software >> peripherals. > > Part of the GA vision is ultra low power consumption by keeping most of > the cores idle most of the time, with very low leakage current. > Implementing something as simple as a timer with a full speed cpu-busy > loop seems to go against the purpose. You need to do more than scratch the surface on this. If the GA144 is idle what is it waiting for? Why does a sync processor need to spend time in a cpu-busy loop? Sync processors can go idle too. They can also shut off the clock to parts not being used (maybe not in an FPGA, but in an ASIC - no problem). A lot of what the GA144 does is very interesting, but you don't have to buy the full package to get many of the benefits. Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-05 12:56 -0800 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <7xa9uvkbv0.fsf@ruckus.brouhaha.com> |
| In reply to | #17075 |
rickman <gnuarm@gmail.com> writes: >>>> I can e.g. use the CPU+timer to generate PWM output. Chuck would >>>> probably do with CPU and a loop. ... >> Implementing something as simple as a timer with a full speed cpu-busy >> loop seems to go against the purpose. > You need to do more than scratch the surface on this. If the GA144 is > idle what is it waiting for? An external signal or i/o event telling it to wake up. > Why does a sync processor need to spend time in a cpu-busy loop? The example given was PWM. You want to bring a wire high for X microseconds, then bring it low for Y microseconds, and repeat. Do this with a timer and there is very little switching activity, so low power consumption. Do it with a software loop and the chip is much busier.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-06 12:22 -0500 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k7bh18$3rr$1@dont-email.me> |
| In reply to | #17078 |
On 11/5/2012 3:56 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >>>>> I can e.g. use the CPU+timer to generate PWM output. Chuck would >>>>> probably do with CPU and a loop. ... >>> Implementing something as simple as a timer with a full speed cpu-busy >>> loop seems to go against the purpose. >> You need to do more than scratch the surface on this. If the GA144 is >> idle what is it waiting for? > > An external signal or i/o event telling it to wake up. Why would you spin a software loop on a sync processor if there is an external signal to use instead? >> Why does a sync processor need to spend time in a cpu-busy loop? > > The example given was PWM. You want to bring a wire high for X > microseconds, then bring it low for Y microseconds, and repeat. Do this > with a timer and there is very little switching activity, so low power > consumption. Do it with a software loop and the chip is much busier. Why would you do it with a software loop when you have a timer? I'm not following. Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-06 09:29 -0800 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <7x625iabcd.fsf@ruckus.brouhaha.com> |
| In reply to | #17084 |
rickman <gnuarm@gmail.com> writes: > Why would you do it with a software loop when you have a timer? I'm > not following. In response to Bernd writing >>> when I have to generate PWMs, I can e.g. use the CPU+timer to >>> generate PWM output. Chuck would probably do with CPU and a loop. You wrote: >> Once you get the cores to the point that they are as plentiful as on >> the GA144 I don't see a problem with using them for software >> peripherals. That made it sound to me like you were suggesting using a software loop instead of a hardware timer. I responded that a hardware timer sounds better because the software loop is likely to burn more power. If that wasn't what you meant, then ok, there was a miscommunication.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-06 12:53 -0500 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k7biq9$mg0$2@dont-email.me> |
| In reply to | #17085 |
On 11/6/2012 12:29 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> Why would you do it with a software loop when you have a timer? I'm >> not following. > > In response to Bernd writing > >>>> when I have to generate PWMs, I can e.g. use the CPU+timer to >>>> generate PWM output. Chuck would probably do with CPU and a loop. > > You wrote: > >>> Once you get the cores to the point that they are as plentiful as on >>> the GA144 I don't see a problem with using them for software >>> peripherals. > > That made it sound to me like you were suggesting using a software loop > instead of a hardware timer. I responded that a hardware timer sounds > better because the software loop is likely to burn more power. If that > wasn't what you meant, then ok, there was a miscommunication. I don't follow why you would use a software loop? What's wrong with an interrupt and software counter? Only on Green Arrays devices do people use software loops to save power... ;^) Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-06 10:00 -0800 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <7xfw4md32e.fsf@ruckus.brouhaha.com> |
| In reply to | #17087 |
rickman <gnuarm@gmail.com> writes: > I don't follow why you would use a software loop? What's wrong with > an interrupt and software counter? Only on Green Arrays devices do > people use software loops to save power... ;^) The issue was "Chuck would probably do with CPU and a loop." That sounds like a GA device to me.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-06 08:04 -1000 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <v8GdnaqVnZKEzATNnZ2dnUVZ_vWdnZ2d@supernews.com> |
| In reply to | #17088 |
On 11/6/12 8:00 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I don't follow why you would use a software loop? What's wrong with >> an interrupt and software counter? Only on Green Arrays devices do >> people use software loops to save power... ;^) > > The issue was "Chuck would probably do with CPU and a loop." That > sounds like a GA device to me. > That may well be the Green Arrays approach, but when he was working on conventional hardware Chuck always used interrupts (clock, device, ...) Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-06 13:37 -0500 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k7bld0$8qi$1@dont-email.me> |
| In reply to | #17088 |
On 11/6/2012 1:00 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> I don't follow why you would use a software loop? What's wrong with >> an interrupt and software counter? Only on Green Arrays devices do >> people use software loops to save power... ;^) > > The issue was "Chuck would probably do with CPU and a loop." That > sounds like a GA device to me. Yes, that is often what Chuck does on his processors. Talk about how power efficient they are and then he uses software based timer loops which burn power terribly. Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-05 21:06 +0100 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <3034093.G7j1EB9JIx@sunwukong.fritz.box> |
| In reply to | #17068 |
rickman wrote: > Once you get the cores to the point that they are as plentiful as on > the GA144 I don't see a problem with using them for software > peripherals. If you actually could use them as software peripherals, but actually, you figure out that you can't: > 100 Mbps Ethernet would be quite a chore and 480 > Mbps USB is likely impossible. Anyways, even if you could do it, you would need a phy, the component where you control slew rate and such - this requires dedicated "analog" hardware (it's still switching digitally, but the design and simulation principles are in the analog domain). If you make that external and use a 16 bit bidirectional interface at 30MHz, it shouldn't be difficult - apart from getting the 16 bits in and out of the GA144 :-). > It would be *easy* to add an SDRAM > controller to a chip like the GA144 and I would never consider > omitting it on any chip I build. Any chip that needs significant memory to function. Anyways: Usually, I design my peripherals so that they can work together with the CPU to become "more intelligent". They may have some very simple mode where they operate autonomous, and anything more complex has to go through software. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-05 15:29 -0500 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k797jf$oi5$1@dont-email.me> |
| In reply to | #17074 |
On 11/5/2012 3:06 PM, Bernd Paysan wrote: > rickman wrote: >> Once you get the cores to the point that they are as plentiful as on >> the GA144 I don't see a problem with using them for software >> peripherals. > > If you actually could use them as software peripherals, but actually, > you figure out that you can't: Not sure what this means. There are many peripherals that work very well in software. Being able to dedicate a CPU to the peripheral task also allows a lot of stuff that is always done in software to be done by that CPU. >> 100 Mbps Ethernet would be quite a chore and 480 >> Mbps USB is likely impossible. > > Anyways, even if you could do it, you would need a phy, the component > where you control slew rate and such - this requires dedicated "analog" > hardware (it's still switching digitally, but the design and simulation > principles are in the analog domain). If you make that external and use > a 16 bit bidirectional interface at 30MHz, it shouldn't be difficult - > apart from getting the 16 bits in and out of the GA144 :-). Don't confuse the PHY and the MAC. I found 4 bit interfaces for 100 Mbps Ethernet, but I don't recall any 16 bit wide. Also why would it need to run at 30 MHz? Even at 30 MHz it is a chore doing that with a F18A. I can't say how well an undefined sync processor with unknown capabilities might do it. >> It would be *easy* to add an SDRAM >> controller to a chip like the GA144 and I would never consider >> omitting it on any chip I build. > > Any chip that needs significant memory to function. > > Anyways: Usually, I design my peripherals so that they can work together > with the CPU to become "more intelligent". They may have some very > simple mode where they operate autonomous, and anything more complex has > to go through software. But if you are using a small CPU core to build an ASIC which isn't dedicated to a single function I think it would be much more useful to have a number of CPUs. As has been pointed out, one of these small CPUs is so tiny that you can't even utilize the minimum die size adequately. But I suppose it can always just include more memory. Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-06 16:28 +0100 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <15368450.aVR1SPKrQn@sunwukong.fritz.box> |
| In reply to | #17076 |
rickman wrote: >> Anyways, even if you could do it, you would need a phy, the component >> where you control slew rate and such - this requires dedicated >> "analog" hardware (it's still switching digitally, but the design and >> simulation >> principles are in the analog domain). If you make that external and >> use a 16 bit bidirectional interface at 30MHz, it shouldn't be >> difficult - apart from getting the 16 bits in and out of the GA144 >> :-). > > Don't confuse the PHY and the MAC. I found 4 bit interfaces for 100 > Mbps Ethernet, but I don't recall any 16 bit wide. Also why would it > need to run at 30 MHz? Even at 30 MHz it is a chore doing that with a > F18A. I can't say how well an undefined sync processor with unknown > capabilities might do it. What I mentioned were USB 2 phys - they come with 16 bits at 30MHz or 8 bit at 60 MHz. Ethernet phys come at 25MHz with 4 bits (100 MBit) or at 125MHz with 8 bits (GB). > But if you are using a small CPU core to build an ASIC which isn't > dedicated to a single function I think it would be much more useful to > have a number of CPUs. As has been pointed out, one of these small > CPUs is so tiny that you can't even utilize the minimum die size > adequately. > But I suppose it can always just include more memory. And include some components you otherwise would need externally, like an LDO for internal voltage regulation. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2012-11-06 12:50 -0500 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <k7bimh$mg0$1@dont-email.me> |
| In reply to | #17082 |
On 11/6/2012 10:28 AM, Bernd Paysan wrote: > rickman wrote: >>> Anyways, even if you could do it, you would need a phy, the component >>> where you control slew rate and such - this requires dedicated >>> "analog" hardware (it's still switching digitally, but the design and >>> simulation >>> principles are in the analog domain). If you make that external and >>> use a 16 bit bidirectional interface at 30MHz, it shouldn't be >>> difficult - apart from getting the 16 bits in and out of the GA144 >>> :-). >> >> Don't confuse the PHY and the MAC. I found 4 bit interfaces for 100 >> Mbps Ethernet, but I don't recall any 16 bit wide. Also why would it >> need to run at 30 MHz? Even at 30 MHz it is a chore doing that with a >> F18A. I can't say how well an undefined sync processor with unknown >> capabilities might do it. > > What I mentioned were USB 2 phys - they come with 16 bits at 30MHz or 8 > bit at 60 MHz. Ethernet phys come at 25MHz with 4 bits (100 MBit) or at > 125MHz with 8 bits (GB). Ok, USB then. Even at 30 MHz it is hard to do anything useful. But more importantly, if you have to add a separate chip to do the interface for USB, why wouldn't you just use an MCU that *includes* the interface on the chip? That is the problem with the more complex protocols, they require too much extra stuff on the outside of the chip. Heck, I bet your USB chip won't even talk to the GA device without a level shifter... *another* extra chip with lots of pins. The Green Arrays people dismiss the idea that added external chips is any reason to not use the GA device. I was looking at using the chip in an app where it would need level shifters to drive an LCD or another where it would need level shifters for other chips. I was told that transistors are very cheap on a board, but they conveniently forget that those transistors need resistors and GA claims that resistors are evil because they use power. Well they use a lot of power when being used to level shift to 3.3 volts too!!! On the other hand, adding a flexible IO block on each pin will allow the user to select the IO capability like they do on FPGAs. I'd be willing to bet that this was a purely philosophical issue in the GA144 design and has nothing to do with marketing. In fact, I doubt the GA144 ever saw any input from "marketing". >> But if you are using a small CPU core to build an ASIC which isn't >> dedicated to a single function I think it would be much more useful to >> have a number of CPUs. As has been pointed out, one of these small >> CPUs is so tiny that you can't even utilize the minimum die size >> adequately. >> But I suppose it can always just include more memory. > > And include some components you otherwise would need externally, like an > LDO for internal voltage regulation. > I would not add an LDO internally on a general purpose chip that I am designing for low power. There is little advantage for a couple of reasons. Small LDOs are very inexpensive devices, <<$1 in many cases and available in very small footprints. So there are few designs that could take advantage of them. Secondly the process that makes effective LDOs doesn't make effective digital logic. So the LDO will use more silicon than is efficient. Lastly an LDO is anticipating the needs of the user and just won't be the right choice for many user designs. But the biggest reason for not including an LDO on the die is because at the process nodes we are talking about the internal Vdd will likely be 3.3 volts if not 5 volts! Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-11-07 20:29 -0800 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <7xd2zohg4y.fsf@ruckus.brouhaha.com> |
| In reply to | #17022 |
rickman <gnuarm@gmail.com> writes: > [Bitcoin ASIC] > Ok, so it's a bit like selling the stuff for custom PCs, not because > they are faster so much, but because they are *cool*. Also like > hotrod cars. Possibilities... But in 350 nm? Maybe, maybe not. ZOMG, looks like someone is doing it in 65nm: http://blog.zorinaq.com/?e=69 They apparently got >= $1M in VC funding. Sheesh.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-04 10:40 +0000 |
| Subject | Re: Xula-200 or Raspberry-Pi a better buy?, was [Re: RTX2000 optimization] |
| Message-ID | <5096460c$0$3196$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #17019 |
In article <7x1ugatsdb.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >rickman <gnuarm@gmail.com> writes: >> I saw someone post that a run of obsolescent technology chips can be >> done as cheaply as $2000 or what it euros? I can come up with that. > >Yes, that was me: http://cmp.imag.fr/products/ic/?p=prices > >> What ideas do you have? Anything that might make a profit? > >For 2000 euro you get 25 parts (MOSIS-like multi-project run, I guess). >That's around $100 per chip, so it's suitable only for special one-off >projects or for prototyping. To turn a profit on a hardware product >will take higher quantity fab runs that cost a lot more (you or Bernd >would know the economics much better than me). > >Some possible ideas: > <SNIP> > >* Probably not economical: an Arduino-like development board with a > Forth CPU, based on the J1. Presumably the ASIC would be much faster > and cheaper (in enough quantity) than an FPGA, it could have 10's of > cores even with an old process, etc. Sort of a revival of the Novix. In the view of crowd-funding this may the most viable of all. You just have to find a couple of dozen enthousiast (worldwide!) that are willing to risk some money that most people (in the rich world) can afford to loose. <SNIP> > >I have a few more that I might try to write up later. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web