Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #57698 > unrolled thread
| Started by | JUERGEN <epldfpga@aol.com> |
|---|---|
| First post | 2017-04-21 00:49 -0700 |
| Last post | 2017-04-26 01:38 -0400 |
| Articles | 20 on this page of 195 — 20 participants |
Back to article view | Back to comp.lang.forth
Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-21 00:49 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-21 01:17 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-21 01:47 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-21 18:55 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-04-22 19:48 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-22 14:50 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 00:23 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-23 11:13 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 16:14 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-23 19:34 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 21:52 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-23 21:59 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 02:20 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 04:04 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 13:40 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 14:41 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 18:22 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:28 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 18:44 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 19:34 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 16:41 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 20:36 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 04:44 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 12:41 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 10:03 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 12:20 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 14:12 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 15:13 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 16:59 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 14:35 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 17:19 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:36 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-25 01:26 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 11:21 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 09:50 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 12:37 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:11 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 13:51 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 15:14 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:15 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 11:34 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 11:38 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 11:39 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:00 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 15:15 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 12:27 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 16:04 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 13:36 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:03 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 12:42 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 12:55 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 15:16 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 14:22 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 15:51 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 13:27 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 13:19 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 11:38 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 13:59 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 12:36 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:49 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:29 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 16:30 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 15:57 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:11 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 14:12 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:38 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 16:41 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 15:11 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 17:32 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-26 03:33 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 11:33 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-26 14:05 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 17:24 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-26 14:51 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 18:29 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-26 16:18 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 21:07 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-27 01:52 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 02:10 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-27 02:22 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:10 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:25 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:08 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 16:14 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 16:17 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:46 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-27 14:07 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 17:58 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-26 20:34 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 01:07 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-27 21:21 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-28 08:54 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-28 10:46 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-27 10:46 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-27 12:05 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:50 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-28 11:23 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-27 11:43 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:57 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:21 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:58 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-28 07:53 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-28 22:31 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 20:14 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-30 16:08 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-29 13:48 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-29 10:45 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-27 15:49 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-29 00:27 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 20:28 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-29 14:15 +0000
Stack processor address regs . was Ting's EP32 32 Bit Processor Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-05-01 13:45 +0100
Re: Stack processor address regs . was Ting's EP32 32 Bit Processor anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 13:15 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started jim.brakefield@ieee.org - 2017-04-28 18:20 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Coos Haak <htrofhc@gmail.com> - 2017-04-29 13:00 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 11:47 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Coos Haak <htrofhc@gmail.com> - 2017-04-29 15:02 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started jim.brakefield@ieee.org - 2017-04-30 18:32 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-26 20:40 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 01:21 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-26 21:14 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-27 02:17 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 05:05 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-27 13:35 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 05:42 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 14:00 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 06:04 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 15:31 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 12:26 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Julian Fondren <julian.fondren@gmail.com> - 2017-04-29 08:04 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-27 10:30 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 12:32 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-28 12:01 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-26 21:34 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 01:26 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-27 21:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 02:50 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started pahihu <pahihu@gmail.com> - 2017-04-28 00:23 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-28 07:46 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-28 02:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 05:35 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Walter Banks <walter@bytecraft.com> - 2017-04-28 14:55 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 13:58 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-26 04:11 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-25 19:54 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:32 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-25 23:25 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:40 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-23 14:27 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 20:35 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-23 19:09 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-04-25 15:33 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Walter Banks <walter@bytecraft.com> - 2017-04-25 13:20 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:00 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Walter Banks <walter@bytecraft.com> - 2017-04-26 14:27 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 13:58 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-25 20:15 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 15:07 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-25 21:37 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-26 14:28 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 12:17 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-04-26 18:48 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-26 21:15 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-25 18:39 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 00:25 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-26 09:58 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 17:43 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 13:10 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 16:42 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 16:06 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 14:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:52 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 00:18 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-22 13:28 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-23 05:06 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-23 06:38 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-23 11:24 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-23 12:17 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-23 23:43 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 04:16 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-24 06:18 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 14:28 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 17:00 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:10 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 17:43 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 16:40 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 21:16 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 09:42 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 12:22 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 14:28 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:03 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 15:39 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 20:44 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 22:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 01:38 -0400
Page 1 of 10 [1] 2 3 … 10 Next page →
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2017-04-21 00:49 -0700 |
| Subject | Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started |
| Message-ID | <d9685ded-dac2-4646-8549-e56eb0d921d4@googlegroups.com> |
see https://www.amazon.com/dp/B071D3XMPS and https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is running eForth on my desk in a low cost Lattice DevBoard and there has been an ASIC implementation in the past already as google told me
[toc] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-21 01:17 -0700 |
| Message-ID | <87k26ecgyf.fsf@nightsong.com> |
| In reply to | #57698 |
JUERGEN <epldfpga@aol.com> writes: > see https://www.amazon.com/dp/B071D3XMPS and > https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is > running eForth on my desk in a low cost Lattice DevBoard and there has > been an ASIC implementation in the past already as google told me Nice, a real ASIC?! I hadn't heard that before. Is there more info around? Btw you can now get the BBC MicroBit at adafruit.com for about $16 USD iirc. Sparkfun.com advertises them too, but they're not in stock there yet.
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2017-04-21 01:47 -0700 |
| Message-ID | <391e0813-13d6-43c5-8316-d2393d2b01c3@googlegroups.com> |
| In reply to | #57700 |
On Friday, April 21, 2017 at 9:17:48 AM UTC+1, Paul Rubin wrote: > JUERGEN <epldfpga@aol.com> writes: > > see https://www.amazon.com/dp/B071D3XMPS and > > https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is > > running eForth on my desk in a low cost Lattice DevBoard and there has > > been an ASIC implementation in the past already as google told me > > Nice, a real ASIC?! I hadn't heard that before. Is there more info > around? > > Btw you can now get the BBC MicroBit at adafruit.com for about $16 USD > iirc. Sparkfun.com advertises them too, but they're not in stock there > yet. The link to one article I found regarding EP32 is on the project page further up and if you google EP 32 RISC Core you find more. Regarding Microbit, we did a Project Page for the Mecrisp installation at https://wiki.forth-ev.de/doku.php/en:projects:microbit:start and an interesting eBook and print about MicroBit (not Forth) but complementing well, you can find at https://www.amazon.co.uk/BBC-Micro-Tests-Tricks-Secrets/dp/1541200721/ref=asap_bc?ie=UTF8 I am working on Burkhard to tackle Forth as well ...
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-21 18:55 -0400 |
| Message-ID | <ode2ej$80l$1@dont-email.me> |
| In reply to | #57698 |
On 4/21/2017 3:49 AM, JUERGEN wrote: > see https://www.amazon.com/dp/B071D3XMPS and https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is running eForth on my desk in a low cost Lattice DevBoard and there has been an ASIC implementation in the past already as google told me Does this processor have any particular purpose or advantage over other stack processors? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Clive Arthur <cliveta@nowaytoday.co.uk> |
|---|---|
| Date | 2017-04-22 19:48 +0100 |
| Message-ID | <odg8br$akh$1@dont-email.me> |
| In reply to | #57756 |
On 21/04/2017 23:55, rickman wrote:
> On 4/21/2017 3:49 AM, JUERGEN wrote:
>> see https://www.amazon.com/dp/B071D3XMPS and
>> https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is
>> running eForth on my desk in a low cost Lattice DevBoard and there has
>> been an ASIC implementation in the past already as google told me
>
> Does this processor have any particular purpose or advantage over other
> stack processors?
>
It seems it's small, but with a limited instruction set, so some simple
Forth words may take several clock cycles. For example, OR is made with
com pushr com popr and com, which I guess would be
: or
not >r not r> and not
;
Looks a bit tedious, but maybe if you're pushed for space and speed
isn't everything...
Cheers
--
Clive
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-22 14:50 -0500 |
| Message-ID | <odgc12$m92$1@dont-email.me> |
| In reply to | #57837 |
On 4/22/2017 1:48 PM, Clive Arthur wrote: > On 21/04/2017 23:55, rickman wrote: >> On 4/21/2017 3:49 AM, JUERGEN wrote: >>> see https://www.amazon.com/dp/B071D3XMPS and >>> https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is >>> running eForth on my desk in a low cost Lattice DevBoard and there has >>> been an ASIC implementation in the past already as google told me >> >> Does this processor have any particular purpose or advantage over other >> stack processors? >> > It seems it's small, but with a limited instruction set, so some simple > Forth words may take several clock cycles. For example, OR is made with > com pushr com popr and com, which I guess would be > > : or > not >r not r> and not > ; > > Looks a bit tedious, but maybe if you're pushed for space and speed > isn't everything... > > Cheers The designer chose to use 5 bits for the instructions but he made provisions for 6 bits but of course changes are needed to be made to implement that, it would allow for 64 primitives instead of 32. Still the most often used words are primitives that execute in one clock, the "or" happens to be one of instructions left out because the limit with 5 bits. I intend to make the instruction word 6 bits and add extra primitives, there is plenty of space in the FPGA left, All the available RAM is not being used either and that is another change I intend to make when I finish my current software project. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-23 00:23 -0400 |
| Message-ID | <odha1o$4e1$1@dont-email.me> |
| In reply to | #57842 |
On 4/22/2017 3:50 PM, Cecil Bayona wrote: > On 4/22/2017 1:48 PM, Clive Arthur wrote: >> On 21/04/2017 23:55, rickman wrote: >>> On 4/21/2017 3:49 AM, JUERGEN wrote: >>>> see https://www.amazon.com/dp/B071D3XMPS and >>>> https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is >>>> running eForth on my desk in a low cost Lattice DevBoard and there has >>>> been an ASIC implementation in the past already as google told me >>> >>> Does this processor have any particular purpose or advantage over other >>> stack processors? >>> >> It seems it's small, but with a limited instruction set, so some >> simple Forth words may take several clock cycles. For example, OR is >> made with com pushr com popr and com, which I guess would be >> >> : or >> not >r not r> and not >> ; >> >> Looks a bit tedious, but maybe if you're pushed for space and speed >> isn't everything... >> >> Cheers > The designer chose to use 5 bits for the instructions but he made > provisions for 6 bits but of course changes are needed to be made to > implement that, it would allow for 64 primitives instead of 32. Still > the most often used words are primitives that execute in one clock, the > "or" happens to be one of instructions left out because the limit with 5 > bits. > > I intend to make the instruction word 6 bits and add extra primitives, > there is plenty of space in the FPGA left, All the available RAM is not > being used either and that is another change I intend to make when I > finish my current software project. I don't think there is a lot of value in extending the instruction set. If you look at Koopman's information on instruction set utilization you will find a small number of instructions will do a good job of optimizing Forth implementations. Things like using AND to implement OR will have very little impact on most programs just because the instruction is used so infrequently. Usually instruction sets are extended because the designer has a emotional objection to leaving an instruction out. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-23 11:13 -0500 |
| Message-ID | <odijm0$d1d$1@dont-email.me> |
| In reply to | #57885 |
On 4/22/2017 11:23 PM, rickman wrote: > On 4/22/2017 3:50 PM, Cecil Bayona wrote: >> On 4/22/2017 1:48 PM, Clive Arthur wrote: >>> On 21/04/2017 23:55, rickman wrote: >>>> On 4/21/2017 3:49 AM, JUERGEN wrote: >>>>> see https://www.amazon.com/dp/B071D3XMPS and >>>>> https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is >>>>> running eForth on my desk in a low cost Lattice DevBoard and there has >>>>> been an ASIC implementation in the past already as google told me >>>> >>>> Does this processor have any particular purpose or advantage over other >>>> stack processors? >>>> >>> It seems it's small, but with a limited instruction set, so some >>> simple Forth words may take several clock cycles. For example, OR is >>> made with com pushr com popr and com, which I guess would be >>> >>> : or >>> not >r not r> and not >>> ; >>> >>> Looks a bit tedious, but maybe if you're pushed for space and speed >>> isn't everything... >>> >>> Cheers >> The designer chose to use 5 bits for the instructions but he made >> provisions for 6 bits but of course changes are needed to be made to >> implement that, it would allow for 64 primitives instead of 32. Still >> the most often used words are primitives that execute in one clock, the >> "or" happens to be one of instructions left out because the limit with 5 >> bits. >> >> I intend to make the instruction word 6 bits and add extra primitives, >> there is plenty of space in the FPGA left, All the available RAM is not >> being used either and that is another change I intend to make when I >> finish my current software project. > > I don't think there is a lot of value in extending the instruction set. > If you look at Koopman's information on instruction set utilization you > will find a small number of instructions will do a good job of > optimizing Forth implementations. Things like using AND to implement OR > will have very little impact on most programs just because the > instruction is used so infrequently. > > Usually instruction sets are extended because the designer has a > emotional objection to leaving an instruction out. > Reducing instructions just to achieve a certain limit is not right also for the device use as a general purpose CPU. This device skips some of the instructions selected by Koopman and Ting in favor of other instructions that are specialized. In this case the instruction set does not have all the instructions desired by the author of the book that includes the "or" instruction in the minimum set of instructions. Although he discusses that processor at length he did not design it, it was done at NASA and they might have a different set of requirements such as fitting in a small ASIC device, also they added multiply and divide primitives, which could be very useful in a CPU in a spacecraft. Actually that is useful everywhere but not often included. The design is such so that possibly two on them can fit on a Brevia FPGA, maybe as things get dicey as the FPGA starts getting close to full. On my Brevia FPGA one CPU used 28% of the logic so two of them is quite possible, but RAM will be rather limited. This CPU works well as is, my purpose in expanding the device may not agree with ours, mine is to use it as a learning project, rather than start from scratch with no experience. I would add new instructions to the existing device such as a "or" instruction and a small amount of other instructions and features. Features that I think about are adding an additional stack, adding a Index register, and count register for handling block moves or searches. Not because it needs the extra hardware but because I want to learn how to do it. The J1 CPU is a much simpler CPU so I'm not decided if to experiment with the ep32 or the J1. The J1 CPU has one bit in its instruction format left undefined it might come in handy to add extra features. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-23 16:14 -0400 |
| Message-ID | <odj1os$ns$1@dont-email.me> |
| In reply to | #57911 |
On 4/23/2017 12:13 PM, Cecil Bayona wrote: > On 4/22/2017 11:23 PM, rickman wrote: >> On 4/22/2017 3:50 PM, Cecil Bayona wrote: >>> On 4/22/2017 1:48 PM, Clive Arthur wrote: >>>> On 21/04/2017 23:55, rickman wrote: >>>>> On 4/21/2017 3:49 AM, JUERGEN wrote: >>>>>> see https://www.amazon.com/dp/B071D3XMPS and >>>>>> https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is >>>>>> running eForth on my desk in a low cost Lattice DevBoard and there >>>>>> has >>>>>> been an ASIC implementation in the past already as google told me >>>>> >>>>> Does this processor have any particular purpose or advantage over >>>>> other >>>>> stack processors? >>>>> >>>> It seems it's small, but with a limited instruction set, so some >>>> simple Forth words may take several clock cycles. For example, OR is >>>> made with com pushr com popr and com, which I guess would be >>>> >>>> : or >>>> not >r not r> and not >>>> ; >>>> >>>> Looks a bit tedious, but maybe if you're pushed for space and speed >>>> isn't everything... >>>> >>>> Cheers >>> The designer chose to use 5 bits for the instructions but he made >>> provisions for 6 bits but of course changes are needed to be made to >>> implement that, it would allow for 64 primitives instead of 32. Still >>> the most often used words are primitives that execute in one clock, the >>> "or" happens to be one of instructions left out because the limit with 5 >>> bits. >>> >>> I intend to make the instruction word 6 bits and add extra primitives, >>> there is plenty of space in the FPGA left, All the available RAM is not >>> being used either and that is another change I intend to make when I >>> finish my current software project. >> >> I don't think there is a lot of value in extending the instruction >> set. If you look at Koopman's information on instruction set >> utilization you will find a small number of instructions will do a >> good job of optimizing Forth implementations. Things like using AND >> to implement OR will have very little impact on most programs just >> because the instruction is used so infrequently. >> >> Usually instruction sets are extended because the designer has a >> emotional objection to leaving an instruction out. >> > Reducing instructions just to achieve a certain limit is not right also > for the device use as a general purpose CPU. This device skips some of > the instructions selected by Koopman and Ting in favor of other > instructions that are specialized. I'm not clear on your use of Ting as an instruction set reference. What reference are you citing exactly? My understanding is that this CPU design was originally by Ting, but maybe I got that wrong. I assume you are referring to Koopman's book, "Stack Computers the new wave"? > In this case the instruction set does not have all the instructions > desired by the author of the book that includes the "or" instruction in > the minimum set of instructions. Although he discusses that processor at > length he did not design it, it was done at NASA and they might have a > different set of requirements such as fitting in a small ASIC device, > also they added multiply and divide primitives, which could be very > useful in a CPU in a spacecraft. Actually that is useful everywhere but > not often included. I don't see a "minimum" set of instructions in Koopman's book. He lists a lengthy glossary of Forth words which are not the same as CPU instructions and an instruction frequency list of Forth words which does not have the OR word listed with even a 2% frequency in any cases. > The design is such so that possibly two on them can fit on a Brevia > FPGA, maybe as things get dicey as the FPGA starts getting close to > full. On my Brevia FPGA one CPU used 28% of the logic so two of them is > quite possible, but RAM will be rather limited. > > This CPU works well as is, my purpose in expanding the device may not > agree with ours, mine is to use it as a learning project, rather than > start from scratch with no experience. I would add new instructions to > the existing device such as a "or" instruction and a small amount of > other instructions and features. Features that I think about are adding > an additional stack, adding a Index register, and count register for > handling block moves or searches. Not because it needs the extra > hardware but because I want to learn how to do it. > > The J1 CPU is a much simpler CPU so I'm not decided if to experiment > with the ep32 or the J1. The J1 CPU has one bit in its instruction > format left undefined it might come in handy to add extra features. There is no reason why you are limited to any given instruction size in an FPGA. In fact, I believe the Brevia uses an FPGA with memory that is a multiple of 9 bits wide. So a 16 bit instruction word leaves 2 memory bits unused. Unfortunately the iCE40 line of FPGAs only have 8 bit wide block memory. If I could count on having that 9th bit in all FPGAs I would hard code it in myself. One tip that many CPU designs ignore, if you look at the complexity of the decoding circuit, instructions that use multiple clock cycles increase greatly that complexity. A 5 or 6 bit instruction with no timing data is very easy to decode. Add multiple clock cycles and you add counter bits that increase greatly the decoding logic. This both consumes resources and adds timing delays. So a CPU design that is totally single clock cycle is highly desirable. That has been one of the more difficult goals to meet in my designs because it impacts many things such as the handling of interrupts and memory access. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-23 19:34 -0500 |
| Message-ID | <odjh0m$eid$1@dont-email.me> |
| In reply to | #57919 |
On 4/23/2017 3:14 PM, rickman wrote: > On 4/23/2017 12:13 PM, Cecil Bayona wrote: >> On 4/22/2017 11:23 PM, rickman wrote: > > I'm not clear on your use of Ting as an instruction set reference. What > reference are you citing exactly? My understanding is that this CPU > design was originally by Ting, but maybe I got that wrong. > I read recently an article by a University that the name escapes me at the time that they worked at implementing the ep32 design in an ASIC, and that original design was done by two NASA engineers. The literature from Ting does not claim he invented the design but he offered an implementation of it for the Lattice Brevia. The University article mentions Ting as someone who had implemented the design in FPGA and had written software for it. On the various literature by Ting on eForth he list a minimal set of primitives to be used in implementing eForth after consideration on his work and the work of Charles Moore, and Koopman to about 25 to 35 will be enough to implement eForth, but that is the minimal set, in some of his works he uses between 60 and 100 primitives depending on the desired results. For example in his esp8266 eForth he uses 67 primitives to make it more efficient. Personal I think 35 are too ffew primitives to make for an efficient design, it will work but it's not optimal, more like 45 to 60 so that all the often used works are single clock primitives. > I assume you are referring to Koopman's book, "Stack Computers the new > wave"? > > >> In this case the instruction set does not have all the instructions >> desired by the author of the book that includes the "or" instruction in >> the minimum set of instructions. Although he discusses that processor at >> length he did not design it, it was done at NASA and they might have a >> different set of requirements such as fitting in a small ASIC device, >> also they added multiply and divide primitives, which could be very >> useful in a CPU in a spacecraft. Actually that is useful everywhere but >> not often included. > > I don't see a "minimum" set of instructions in Koopman's book. He lists > a lengthy glossary of Forth words which are not the same as CPU > instructions and an instruction frequency list of Forth words which does > not have the OR word listed with even a 2% frequency in any cases. > > > > There is no reason why you are limited to any given instruction size in > an FPGA. In fact, I believe the Brevia uses an FPGA with memory that is > a multiple of 9 bits wide. So a 16 bit instruction word leaves 2 memory > bits unused. Unfortunately the iCE40 line of FPGAs only have 8 bit wide > block memory. If I could count on having that 9th bit in all FPGAs I > would hard code it in myself. In the epxx designs the memory is used in multiple of 8 bits so on the Brevia the 9th bit is not used. Taking to ep16 design to 18 bits would be a nice improvement wit added primitives and a larger addressing range, 18 bit stacks and registers would extend the dynamic range of data values four fold a nice improvement. That would limit the design to FPGAs with 9 bit memory blocks for which there are plenty available. > > One tip that many CPU designs ignore, if you look at the complexity of > the decoding circuit, instructions that use multiple clock cycles > increase greatly that complexity. A 5 or 6 bit instruction with no > timing data is very easy to decode. Add multiple clock cycles and you > add counter bits that increase greatly the decoding logic. This both > consumes resources and adds timing delays. So a CPU design that is > totally single clock cycle is highly desirable. That has been one of > the more difficult goals to meet in my designs because it impacts many > things such as the handling of interrupts and memory access. > The J1 is a nice design in that regard in that it has a ton of instructions some of them are actually multiple instructions in one work at no extra cost that run in one clock, some implementations with extra features use 140 lines of Verilog -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-23 21:52 -0400 |
| Message-ID | <odjljl$hio$1@dont-email.me> |
| In reply to | #57934 |
On 4/23/2017 8:34 PM, Cecil Bayona wrote: > On 4/23/2017 3:14 PM, rickman wrote: >> On 4/23/2017 12:13 PM, Cecil Bayona wrote: >>> On 4/22/2017 11:23 PM, rickman wrote: > >> >> I'm not clear on your use of Ting as an instruction set reference. >> What reference are you citing exactly? My understanding is that this >> CPU design was originally by Ting, but maybe I got that wrong. >> > > I read recently an article by a University that the name escapes me at > the time that they worked at implementing the ep32 design in an ASIC, > and that original design was done by two NASA engineers. The literature > from Ting does not claim he invented the design but he offered an > implementation of it for the Lattice Brevia. The University article > mentions Ting as someone who had implemented the design in FPGA and had > written software for it. > > On the various literature by Ting on eForth he list a minimal set of > primitives to be used in implementing eForth after consideration on his > work and the work of Charles Moore, and Koopman to about 25 to 35 will > be enough to implement eForth, but that is the minimal set, in some of > his works he uses between 60 and 100 primitives depending on the desired > results. For example in his esp8266 eForth he uses 67 primitives to make > it more efficient. > > Personal I think 35 are too ffew primitives to make for an efficient > design, it will work but it's not optimal, more like 45 to 60 so that > all the often used works are single clock primitives. I don't know what you think makes for an "efficient" design and that is really what is important in determining an instruction set for a CPU. Personally I think making the implementation simpler is more useful than including more Forth primitives in the instruction set. But that is the point, how to weight the two aspects. >> I assume you are referring to Koopman's book, "Stack Computers the new >> wave"? >> >> >>> In this case the instruction set does not have all the instructions >>> desired by the author of the book that includes the "or" instruction in >>> the minimum set of instructions. Although he discusses that processor at >>> length he did not design it, it was done at NASA and they might have a >>> different set of requirements such as fitting in a small ASIC device, >>> also they added multiply and divide primitives, which could be very >>> useful in a CPU in a spacecraft. Actually that is useful everywhere but >>> not often included. >> >> I don't see a "minimum" set of instructions in Koopman's book. He >> lists a lengthy glossary of Forth words which are not the same as CPU >> instructions and an instruction frequency list of Forth words which >> does not have the OR word listed with even a 2% frequency in any cases. >> >> >> >> There is no reason why you are limited to any given instruction size >> in an FPGA. In fact, I believe the Brevia uses an FPGA with memory >> that is a multiple of 9 bits wide. So a 16 bit instruction word >> leaves 2 memory bits unused. Unfortunately the iCE40 line of FPGAs >> only have 8 bit wide block memory. If I could count on having that >> 9th bit in all FPGAs I would hard code it in myself. > > In the epxx designs the memory is used in multiple of 8 bits so on the > Brevia the 9th bit is not used. Taking to ep16 design to 18 bits would > be a nice improvement wit added primitives and a larger addressing > range, 18 bit stacks and registers would extend the dynamic range of > data values four fold a nice improvement. That would limit the design to > FPGAs with 9 bit memory blocks for which there are plenty available. In an FPGA design you have the freedom to set the various details of a design. While the EP32 is an 8 bit data oriented design, other designs can make more efficient use of the FPGA resources. >> One tip that many CPU designs ignore, if you look at the complexity of >> the decoding circuit, instructions that use multiple clock cycles >> increase greatly that complexity. A 5 or 6 bit instruction with no >> timing data is very easy to decode. Add multiple clock cycles and you >> add counter bits that increase greatly the decoding logic. This both >> consumes resources and adds timing delays. So a CPU design that is >> totally single clock cycle is highly desirable. That has been one of >> the more difficult goals to meet in my designs because it impacts many >> things such as the handling of interrupts and memory access. >> > The J1 is a nice design in that regard in that it has a ton of > instructions some of them are actually multiple instructions in one work > at no extra cost that run in one clock, some implementations with extra > features use 140 lines of Verilog All processors have multiple functional units. How these units are used in instructions and how they map to Forth instructions vary. I like to try to keep the multiple functional units busy when possible, but that requires a less encoded instruction format using more memory for each instruction. The trick is to make it pay by getting more done in each instruction. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-23 21:59 -0500 |
| Message-ID | <odjpg9$qlo$1@dont-email.me> |
| In reply to | #57940 |
On 4/23/2017 8:52 PM, rickman wrote: > On 4/23/2017 8:34 PM, Cecil Bayona wrote: > > I don't know what you think makes for an "efficient" design and that is > really what is important in determining an instruction set for a CPU. > Personally I think making the implementation simpler is more useful than > including more Forth primitives in the instruction set. But that is the > point, how to weight the two aspects. > > Some of these CPUs have very limited amount of RAM, part of being efficient is not having to do multiple instructions to do something simple, yes it cost more logic, but the device cost the same even if you use little logic in it, so it might be worthwhile to add multi-instructions to one primitive when possible, the ep32 uses 28% of the LUTS on a Brevia 2, but if it used 50% but saved on RAM usage you end up ahead. > In an FPGA design you have the freedom to set the various details of a > design. While the EP32 is an 8 bit data oriented design, other designs > can make more efficient use of the FPGA resources. > > A change to use the full width of the memory blocks might be worthwhile, it will need more LUTS but there are plenty not in use, 36 bits gives you pretty good size integers. On the ep16 18 bits is a nice improvement, not only bigger integers but also a bigger address range, although I don't think that is an issue, but one thing to note is the Brevia 2 has 512KB of 10 ns memory available on the outside which is quite a bit. >>> One tip that many CPU designs ignore, if you look at the complexity of >>> the decoding circuit, instructions that use multiple clock cycles >>> increase greatly that complexity. A 5 or 6 bit instruction with no >>> timing data is very easy to decode. Add multiple clock cycles and you >>> add counter bits that increase greatly the decoding logic. This both >>> consumes resources and adds timing delays. So a CPU design that is >>> totally single clock cycle is highly desirable. That has been one of >>> the more difficult goals to meet in my designs because it impacts many >>> things such as the handling of interrupts and memory access. >>> >> The J1 is a nice design in that regard in that it has a ton of >> instructions some of them are actually multiple instructions in one work >> at no extra cost that run in one clock, some implementations with extra >> features use 140 lines of Verilog > > All processors have multiple functional units. How these units are used > in instructions and how they map to Forth instructions vary. I like to > try to keep the multiple functional units busy when possible, but that > requires a less encoded instruction format using more memory for each > instruction. The trick is to make it pay by getting more done in each > instruction. > The horizontal decoding of the instruction on the J1 makes it possible to execute multiple instructions in one clock but it uses 16 bits to the instruction with one of those 16 bits being unused (room for expansion here). Even the ep32 has room for more simultaneous execution but one need the full 6 bits to implement more primitives that combine multiple actions. I was going to start learning VHDL but looking at some FPGA implementations I see that Verilog has simpler code although I gather that VHDL helps prevent a lot of dumb mistakes. So after I finish my current software project enough to start being useful I will try the J1 in Verilog and see how that works out. Eventually an 18 bit J1 might be and interesting modification. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 02:20 -0400 |
| Message-ID | <odk59e$l2d$1@dont-email.me> |
| In reply to | #57947 |
On 4/23/2017 10:59 PM, Cecil Bayona wrote: > On 4/23/2017 8:52 PM, rickman wrote: >> On 4/23/2017 8:34 PM, Cecil Bayona wrote: >> >> I don't know what you think makes for an "efficient" design and that >> is really what is important in determining an instruction set for a >> CPU. Personally I think making the implementation simpler is more >> useful than including more Forth primitives in the instruction set. >> But that is the point, how to weight the two aspects. >> >> > > Some of these CPUs have very limited amount of RAM, part of being > efficient is not having to do multiple instructions to do something > simple, yes it cost more logic, but the device cost the same even if you > use little logic in it, so it might be worthwhile to add > multi-instructions to one primitive when possible, the ep32 uses 28% of > the LUTS on a Brevia 2, but if it used 50% but saved on RAM usage you > end up ahead. You have a very limited view of the world. LUT counts are not the only important thing in a design. Using more bits to allow multiple instructions in one opcode uses more memory for each opcode. Whether it uses more memory overall depends on how good a job is done providing useful opcodes and how often instructions can be paralleled and how well the tools encode such parallel instructions. I had looked at providing three independent fields in an instruction to allow all three execution units in my CPU to run totally in parallel. But this could only be useful part of the time. The three units are the data stack unit (with the data path logic), the return stack unit (with the memory addressing and loop counting logic) and the instruction fetch unit (which handles all instruction addressing, jumps, calls, interrupts, etc). These units can only be usefully used in parallel when they can operate in parallel when operating independently. The instruction fetch unit typically just fetches the next instruction or it can do jumps, calls and returns, but not when the return stack unit is doing anything else. The return stack unit can do looping control or address memory, but not when it is being accessed by the data unit. You get the idea. In the end getting parallelism to be useful was hard and getting the tools to generate useful code would have been beyond my current skills other than manually using assembly language. As a way to improve the throughput this might be worthwhile. I don't see this as especially useful for reducing code size and in fact likely would use more memory for program storage. >> In an FPGA design you have the freedom to set the various details of a >> design. While the EP32 is an 8 bit data oriented design, other >> designs can make more efficient use of the FPGA resources. >> >> > A change to use the full width of the memory blocks might be worthwhile, > it will need more LUTS but there are plenty not in use, 36 bits gives > you pretty good size integers. On the ep16 18 bits is a nice > improvement, not only bigger integers but also a bigger address range, > although I don't think that is an issue, but one thing to note is the > Brevia 2 has 512KB of 10 ns memory available on the outside which is > quite a bit. You seem to think LUT usage is paramount. I've never found a CPU design to be overly demanding on the LUT count. More important to me is getting it to run fast, usually so it will run with the existing system clock rather than running at a slower clock. The throughput of a small CPU is often not a problem although that depends entirely on the task at hand. My point is if you really are counting on the speed being X, then if it falls a bit short you are hosed. I much prefer to have lots of excess speed so it is never an issue. Speed is a PITA to deal with if you are squeezed. External memory is never required for my CPU designs other than as interfaces to the system. If you need more than a few kB for program storage you are going to spend a lot of time writing code. I don't have that much time usually. While I find it useful to utilize memory fully when selecting instruction widths, I don't limit my data or address size. If I need 19 bit addresses I use 19 bit addresses. My CPU design is pretty much N bits. The only complication is addressing bytes. For data paths that are multiples of 8 or 9 bits I use 8 or 9 bit bytes. I haven't needed anything else as yet. >>>> One tip that many CPU designs ignore, if you look at the complexity of >>>> the decoding circuit, instructions that use multiple clock cycles >>>> increase greatly that complexity. A 5 or 6 bit instruction with no >>>> timing data is very easy to decode. Add multiple clock cycles and you >>>> add counter bits that increase greatly the decoding logic. This both >>>> consumes resources and adds timing delays. So a CPU design that is >>>> totally single clock cycle is highly desirable. That has been one of >>>> the more difficult goals to meet in my designs because it impacts many >>>> things such as the handling of interrupts and memory access. >>>> >>> The J1 is a nice design in that regard in that it has a ton of >>> instructions some of them are actually multiple instructions in one work >>> at no extra cost that run in one clock, some implementations with extra >>> features use 140 lines of Verilog >> >> All processors have multiple functional units. How these units are >> used in instructions and how they map to Forth instructions vary. I >> like to try to keep the multiple functional units busy when possible, >> but that requires a less encoded instruction format using more memory >> for each instruction. The trick is to make it pay by getting more >> done in each instruction. >> > > The horizontal decoding of the instruction on the J1 makes it possible > to execute multiple instructions in one clock but it uses 16 bits to the > instruction with one of those 16 bits being unused (room for expansion > here). Even the ep32 has room for more simultaneous execution but one > need the full 6 bits to implement more primitives that combine multiple > actions. The J1 has very limited support for multiple "instructions" in a single opcode. Meanwhile it is using a full 16 bits for each instruction. It does manage to have higher code density than the Xilinx MicroBlaze CPU. > I was going to start learning VHDL but looking at some FPGA > implementations I see that Verilog has simpler code although I gather > that VHDL helps prevent a lot of dumb mistakes. So after I finish my > current software project enough to start being useful I will try the J1 > in Verilog and see how that works out. Eventually an 18 bit J1 might be > and interesting modification. I have used Verilog but do not call myself a Verilog programmer. I don't know that VHDL strong typing is such a boon to error catching. I think it is a big PITA when learning, but once you get the hang of explicit type indication and conversions (and a few other things VHDL forces you to do) I believe it is more the mindset that helps to prevent errors. I don't know this isn't possible in Verilog as well. The main difference is in the test bench facility I think. VHDL lets you write very good test benches while I've been told you need to use System Verilog to more easily write good test benches in Verilog. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-24 04:04 -0700 |
| Message-ID | <56ba05b5-f6b5-46fe-9163-e12c249c02e4@googlegroups.com> |
| In reply to | #57963 |
> You seem to think LUT usage is paramount. I've never found a CPU design > to be overly demanding on the LUT count. You seem to estimate this based on Lattice chips. Leading architecture now represented by Xilinx and Altera FPGAs, and LUT is combined with 2 flip-flops. Since LUT has 6 inputs, but data is usually wider, several LUTs are required before result may be stored into flip-flop. For CPU designs LUTs are consumed more agressively than flip-flops. Dedicated resources (RAM, multipliers) are other side of project and should npt be directly compared with LUTs. Coefficient of LUT+FF pair is calculated separately by FPGA CAD and it is not so high (30% or so) for CPU designs. More flip-flops required for heavily pipelined designs, such as DSP and network processing. > More important to me is > getting it to run fast, usually so it will run with the existing system > clock rather than running at a slower clock. The throughput of a small > CPU is often not a problem although that depends entirely on the task at > hand. My point is if you really are counting on the speed being X, then > if it falls a bit short you are hosed. I much prefer to have lots of > excess speed so it is never an issue. Speed is a PITA to deal with if > you are squeezed. Speed != performance. Having CPU in the datapath means a bottleneck. With FPGA you can implement parallel processing by independent datapaths, based on DSP and/or logic cells, and it is extremely faster than read-calculate-write data by CPU. > > I was going to start learning VHDL but looking at some FPGA > > implementations I see that Verilog has simpler code although I gather > > that VHDL helps prevent a lot of dumb mistakes. So after I finish my > > current software project enough to start being useful I will try the J1 > > in Verilog and see how that works out. Eventually an 18 bit J1 might be > > and interesting modification. > > I have used Verilog but do not call myself a Verilog programmer. I > don't know that VHDL strong typing is such a boon to error catching. I > think it is a big PITA when learning, but once you get the hang of > explicit type indication and conversions (and a few other things VHDL > forces you to do) I believe it is more the mindset that helps to prevent > errors. I don't know this isn't possible in Verilog as well. > > The main difference is in the test bench facility I think. VHDL lets > you write very good test benches while I've been told you need to use > System Verilog to more easily write good test benches in Verilog. Self-driven system testbench is dramatically better approach. In general, you need just download memory image and provide clk stimulus. Thanks to Forth - VHDL/Verilog model of memory can be exported very easily directly from cross-compiler. After this you can observe all signals, generated by CPU running this program.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 13:40 -0400 |
| Message-ID | <odld3s$pta$1@dont-email.me> |
| In reply to | #57984 |
On 4/24/2017 7:04 AM, Ilya Tarasov wrote: >> You seem to think LUT usage is paramount. I've never found a CPU >> design to be overly demanding on the LUT count. > > You seem to estimate this based on Lattice chips. Leading > architecture now represented by Xilinx and Altera FPGAs, and LUT is > combined with 2 flip-flops. Since LUT has 6 inputs, but data is > usually wider, several LUTs are required before result may be stored > into flip-flop. For CPU designs LUTs are consumed more agressively > than flip-flops. I have no idea what you are talking about. I've said nothing about a size of LUT or how they are bungled with FFs. > Dedicated resources (RAM, multipliers) are other side of project and > should npt be directly compared with LUTs. Coefficient of LUT+FF pair > is calculated separately by FPGA CAD and it is not so high (30% or > so) for CPU designs. More flip-flops required for heavily pipelined > designs, such as DSP and network processing. Yes, this is all obvious. >> More important to me is getting it to run fast, usually so it will >> run with the existing system clock rather than running at a slower >> clock. The throughput of a small CPU is often not a problem >> although that depends entirely on the task at hand. My point is if >> you really are counting on the speed being X, then if it falls a >> bit short you are hosed. I much prefer to have lots of excess >> speed so it is never an issue. Speed is a PITA to deal with if you >> are squeezed. > > Speed != performance. Having CPU in the datapath means a bottleneck. > With FPGA you can implement parallel processing by independent > datapaths, based on DSP and/or logic cells, and it is extremely > faster than read-calculate-write data by CPU. > >>> I was going to start learning VHDL but looking at some FPGA >>> implementations I see that Verilog has simpler code although I >>> gather that VHDL helps prevent a lot of dumb mistakes. So after I >>> finish my current software project enough to start being useful I >>> will try the J1 in Verilog and see how that works out. Eventually >>> an 18 bit J1 might be and interesting modification. >> >> I have used Verilog but do not call myself a Verilog programmer. I >> don't know that VHDL strong typing is such a boon to error >> catching. I think it is a big PITA when learning, but once you get >> the hang of explicit type indication and conversions (and a few >> other things VHDL forces you to do) I believe it is more the >> mindset that helps to prevent errors. I don't know this isn't >> possible in Verilog as well. >> >> The main difference is in the test bench facility I think. VHDL >> lets you write very good test benches while I've been told you need >> to use System Verilog to more easily write good test benches in >> Verilog. > > Self-driven system testbench is dramatically better approach. In > general, you need just download memory image and provide clk > stimulus. Thanks to Forth - VHDL/Verilog model of memory can be > exported very easily directly from cross-compiler. After this you can > observe all signals, generated by CPU running this program. Ting took the "functional" simulation approach and ran his 8080 design with a Forth program. I wanted to illustrate the use of test benches on his design and constructed a simple test with just 10 instructions or fewer. I found a bug in his 8080 implementation that wasn't caught in his functional test because it wasn't constructed to thoroughly test the CPU. Testing is not just running the design. Tests have to be constructed to test a design rather than just running it. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-24 14:41 -0700 |
| Message-ID | <5b8bbd35-0427-49ab-94aa-a10494bd47ae@googlegroups.com> |
| In reply to | #58011 |
понедельник, 24 апреля 2017 г., 20:40:11 UTC+3 пользователь rickman написал: > On 4/24/2017 7:04 AM, Ilya Tarasov wrote: > >> You seem to think LUT usage is paramount. I've never found a CPU > >> design to be overly demanding on the LUT count. > > > > You seem to estimate this based on Lattice chips. Leading > > architecture now represented by Xilinx and Altera FPGAs, and LUT is > > combined with 2 flip-flops. Since LUT has 6 inputs, but data is > > usually wider, several LUTs are required before result may be stored > > into flip-flop. For CPU designs LUTs are consumed more agressively > > than flip-flops. > > I have no idea what you are talking about. I've said nothing about a > size of LUT or how they are bungled with FFs. Nothing good. This probably means you have no detailed understanding of FPGA architecture. > > Dedicated resources (RAM, multipliers) are other side of project and > > should npt be directly compared with LUTs. Coefficient of LUT+FF pair > > is calculated separately by FPGA CAD and it is not so high (30% or > > so) for CPU designs. More flip-flops required for heavily pipelined > > designs, such as DSP and network processing. > > Yes, this is all obvious. Really? In this kind you should have your own observation about resources required for different types of designs. > > Self-driven system testbench is dramatically better approach. In > > general, you need just download memory image and provide clk > > stimulus. Thanks to Forth - VHDL/Verilog model of memory can be > > exported very easily directly from cross-compiler. After this you can > > observe all signals, generated by CPU running this program. > > Ting took the "functional" simulation approach and ran his 8080 design > with a Forth program. I wanted to illustrate the use of test benches on > his design and constructed a simple test with just 10 instructions or > fewer. I found a bug in his 8080 implementation that wasn't caught in > his functional test because it wasn't constructed to thoroughly test the > CPU. > > Testing is not just running the design. Tests have to be constructed to > test a design rather than just running it. You missing the point completely. Construct tests whenever you want, but when I construct tests, I don't need to edit a single line in VHDL or Verilog. All tests are just programs in Forth (or Assembler), compiles by Forth cross-compiler and runs automatically by single self-driven testbench. All stimulus are comes from cross-compiler, and don't needed to be coded in VHDL.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 18:22 -0400 |
| Message-ID | <odltks$nat$1@dont-email.me> |
| In reply to | #58024 |
On 4/24/2017 5:41 PM, Ilya Tarasov wrote: > понедельник, 24 апреля 2017 г., 20:40:11 UTC+3 пользователь rickman написал: >> On 4/24/2017 7:04 AM, Ilya Tarasov wrote: >>>> You seem to think LUT usage is paramount. I've never found a CPU >>>> design to be overly demanding on the LUT count. >>> >>> You seem to estimate this based on Lattice chips. Leading >>> architecture now represented by Xilinx and Altera FPGAs, and LUT is >>> combined with 2 flip-flops. Since LUT has 6 inputs, but data is >>> usually wider, several LUTs are required before result may be stored >>> into flip-flop. For CPU designs LUTs are consumed more agressively >>> than flip-flops. >> >> I have no idea what you are talking about. I've said nothing about a >> size of LUT or how they are bungled with FFs. > > Nothing good. This probably means you have no detailed understanding of FPGA > architecture. > >>> Dedicated resources (RAM, multipliers) are other side of project and >>> should npt be directly compared with LUTs. Coefficient of LUT+FF pair >>> is calculated separately by FPGA CAD and it is not so high (30% or >>> so) for CPU designs. More flip-flops required for heavily pipelined >>> designs, such as DSP and network processing. >> >> Yes, this is all obvious. > > Really? In this kind you should have your own observation about resources required for different types of designs. > >>> Self-driven system testbench is dramatically better approach. In >>> general, you need just download memory image and provide clk >>> stimulus. Thanks to Forth - VHDL/Verilog model of memory can be >>> exported very easily directly from cross-compiler. After this you can >>> observe all signals, generated by CPU running this program. >> >> Ting took the "functional" simulation approach and ran his 8080 design >> with a Forth program. I wanted to illustrate the use of test benches on >> his design and constructed a simple test with just 10 instructions or >> fewer. I found a bug in his 8080 implementation that wasn't caught in >> his functional test because it wasn't constructed to thoroughly test the >> CPU. >> >> Testing is not just running the design. Tests have to be constructed to >> test a design rather than just running it. > > You missing the point completely. Construct tests whenever you want, but when I construct tests, I don't need to edit a single line in VHDL or Verilog. All tests are just programs in Forth (or Assembler), compiles by Forth cross-compiler and runs automatically by single self-driven testbench. All stimulus are comes from cross-compiler, and don't needed to be coded in VHDL. There must be a large language barrier. I said nothing about editing your HDL code. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-24 15:28 -0700 |
| Message-ID | <edd7cd8e-4745-4760-84a0-8a0ac7e3498e@googlegroups.com> |
| In reply to | #58031 |
вторник, 25 апреля 2017 г., 1:22:20 UTC+3 пользователь rickman написал: > On 4/24/2017 5:41 PM, Ilya Tarasov wrote: > > понедельник, 24 апреля 2017 г., 20:40:11 UTC+3 пользователь rickman написал: > >> On 4/24/2017 7:04 AM, Ilya Tarasov wrote: > >>>> You seem to think LUT usage is paramount. I've never found a CPU > >>>> design to be overly demanding on the LUT count. > >>> > >>> You seem to estimate this based on Lattice chips. Leading > >>> architecture now represented by Xilinx and Altera FPGAs, and LUT is > >>> combined with 2 flip-flops. Since LUT has 6 inputs, but data is > >>> usually wider, several LUTs are required before result may be stored > >>> into flip-flop. For CPU designs LUTs are consumed more agressively > >>> than flip-flops. > >> > >> I have no idea what you are talking about. I've said nothing about a > >> size of LUT or how they are bungled with FFs. > > > > Nothing good. This probably means you have no detailed understanding of FPGA > > architecture. > > > >>> Dedicated resources (RAM, multipliers) are other side of project and > >>> should npt be directly compared with LUTs. Coefficient of LUT+FF pair > >>> is calculated separately by FPGA CAD and it is not so high (30% or > >>> so) for CPU designs. More flip-flops required for heavily pipelined > >>> designs, such as DSP and network processing. > >> > >> Yes, this is all obvious. > > > > Really? In this kind you should have your own observation about resources required for different types of designs. > > > >>> Self-driven system testbench is dramatically better approach. In > >>> general, you need just download memory image and provide clk > >>> stimulus. Thanks to Forth - VHDL/Verilog model of memory can be > >>> exported very easily directly from cross-compiler. After this you can > >>> observe all signals, generated by CPU running this program. > >> > >> Ting took the "functional" simulation approach and ran his 8080 design > >> with a Forth program. I wanted to illustrate the use of test benches on > >> his design and constructed a simple test with just 10 instructions or > >> fewer. I found a bug in his 8080 implementation that wasn't caught in > >> his functional test because it wasn't constructed to thoroughly test the > >> CPU. > >> > >> Testing is not just running the design. Tests have to be constructed to > >> test a design rather than just running it. > > > > You missing the point completely. Construct tests whenever you want, but when I construct tests, I don't need to edit a single line in VHDL or Verilog. All tests are just programs in Forth (or Assembler), compiles by Forth cross-compiler and runs automatically by single self-driven testbench. All stimulus are comes from cross-compiler, and don't needed to be coded in VHDL. > > There must be a large language barrier. I said nothing about editing > your HDL code. Did you ever understood what I'm talking about? Tell me about testbenches and write an example how do you plan to test CPU with VHDL or Verilog.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 18:44 -0400 |
| Message-ID | <odluut$rcr$1@dont-email.me> |
| In reply to | #58032 |
On 4/24/2017 6:28 PM, Ilya Tarasov wrote: > вторник, 25 апреля 2017 г., 1:22:20 UTC+3 пользователь rickman написал: >> On 4/24/2017 5:41 PM, Ilya Tarasov wrote: >>> понедельник, 24 апреля 2017 г., 20:40:11 UTC+3 пользователь rickman написал: >>>> On 4/24/2017 7:04 AM, Ilya Tarasov wrote: >>>>>> You seem to think LUT usage is paramount. I've never found a CPU >>>>>> design to be overly demanding on the LUT count. >>>>> >>>>> You seem to estimate this based on Lattice chips. Leading >>>>> architecture now represented by Xilinx and Altera FPGAs, and LUT is >>>>> combined with 2 flip-flops. Since LUT has 6 inputs, but data is >>>>> usually wider, several LUTs are required before result may be stored >>>>> into flip-flop. For CPU designs LUTs are consumed more agressively >>>>> than flip-flops. >>>> >>>> I have no idea what you are talking about. I've said nothing about a >>>> size of LUT or how they are bungled with FFs. >>> >>> Nothing good. This probably means you have no detailed understanding of FPGA >>> architecture. >>> >>>>> Dedicated resources (RAM, multipliers) are other side of project and >>>>> should npt be directly compared with LUTs. Coefficient of LUT+FF pair >>>>> is calculated separately by FPGA CAD and it is not so high (30% or >>>>> so) for CPU designs. More flip-flops required for heavily pipelined >>>>> designs, such as DSP and network processing. >>>> >>>> Yes, this is all obvious. >>> >>> Really? In this kind you should have your own observation about resources required for different types of designs. >>> >>>>> Self-driven system testbench is dramatically better approach. In >>>>> general, you need just download memory image and provide clk >>>>> stimulus. Thanks to Forth - VHDL/Verilog model of memory can be >>>>> exported very easily directly from cross-compiler. After this you can >>>>> observe all signals, generated by CPU running this program. >>>> >>>> Ting took the "functional" simulation approach and ran his 8080 design >>>> with a Forth program. I wanted to illustrate the use of test benches on >>>> his design and constructed a simple test with just 10 instructions or >>>> fewer. I found a bug in his 8080 implementation that wasn't caught in >>>> his functional test because it wasn't constructed to thoroughly test the >>>> CPU. >>>> >>>> Testing is not just running the design. Tests have to be constructed to >>>> test a design rather than just running it. >>> >>> You missing the point completely. Construct tests whenever you want, but when I construct tests, I don't need to edit a single line in VHDL or Verilog. All tests are just programs in Forth (or Assembler), compiles by Forth cross-compiler and runs automatically by single self-driven testbench. All stimulus are comes from cross-compiler, and don't needed to be coded in VHDL. >> >> There must be a large language barrier. I said nothing about editing >> your HDL code. > > Did you ever understood what I'm talking about? Tell me about testbenches and write an example how do you plan to test CPU with VHDL or Verilog. Provide me with the code for the interfaces. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 19:34 -0400 |
| Message-ID | <odm1rm$3mg$1@dont-email.me> |
| In reply to | #58035 |
On 4/24/2017 6:44 PM, rickman wrote: > On 4/24/2017 6:28 PM, Ilya Tarasov wrote: >> >> Did you ever understood what I'm talking about? Tell me about >> testbenches and write an example how do you plan to test CPU with VHDL >> or Verilog. > > Provide me with the code for the interfaces. Or you can view the SVFIG monthly meeting a few months ago where Ting presented his 8080 model and read my pages on testing it via a test bench. I expect I would do something like that for nearly any processor. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web