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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-24 16:41 -0700 |
| Message-ID | <d54685b9-49f7-4e03-ae23-3d79d41a6d04@googlegroups.com> |
| In reply to | #58035 |
вторник, 25 апреля 2017 г., 1:44:45 UTC+3 пользователь rickman написал:
> 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.
You don't need interface. With properly approach you need only this:
-- Clock process definitions
clk_process :process
begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
end process;
-- Stimulus process
stim_proc: process
begin
reset <= '1';
wait for clk_period;
reset <= '0';
wait;
end process;
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 20:36 -0400 |
| Message-ID | <odm5gt$cgs$2@dont-email.me> |
| In reply to | #58038 |
On 4/24/2017 7:41 PM, Ilya Tarasov wrote: > вторник, 25 апреля 2017 г., 1:44:45 UTC+3 пользователь rickman написал: >> 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. > > You don't need interface. With properly approach you need only this: > > -- Clock process definitions > clk_process :process > begin > clk <= '0'; > wait for clk_period/2; > clk <= '1'; > wait for clk_period/2; > end process; > > > -- Stimulus process > stim_proc: process > begin > reset <= '1'; > wait for clk_period; > reset <= '0'; > > wait; > end process; Great! So I don't really need to even simulate it. I know exactly what this code will do. Thanks a lot! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-25 04:44 -0700 |
| Message-ID | <802dc866-8799-41e7-869b-ae4ed945f8ec@googlegroups.com> |
| In reply to | #58039 |
вторник, 25 апреля 2017 г., 3:36:45 UTC+3 пользователь rickman написал: > > You don't need interface. With properly approach you need only this: > > > > -- Clock process definitions > > clk_process :process > > begin > > clk <= '0'; > > wait for clk_period/2; > > clk <= '1'; > > wait for clk_period/2; > > end process; > > > > > > -- Stimulus process > > stim_proc: process > > begin > > reset <= '1'; > > wait for clk_period; > > reset <= '0'; > > > > wait; > > end process; > > Great! So I don't really need to even simulate it. I know exactly what > this code will do. Thanks a lot! And here is a result of simulation :) http://fforum.winglion.ru/viewtopic.php?f=3&t=3124 Your global mistake you are rely in unit-tests rather than higher level test style. You will know absolutely nothing about whole CPU after running test for register, ALU, system bus etc. Even if unit tests passed ok, connected units may fail because of different interface or cycles mismatching. All these problem may be revealed at integration level testing, then stimulus are applied to connected units, not to every unit one by one. The next step is system level test. If you are so smart, please explain me what is it.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-25 12:41 -0400 |
| Message-ID | <odnu1t$aa9$1@dont-email.me> |
| In reply to | #58087 |
On 4/25/2017 7:44 AM, Ilya Tarasov wrote: > вторник, 25 апреля 2017 г., 3:36:45 UTC+3 пользователь rickman написал: >>> You don't need interface. With properly approach you need only this: >>> >>> -- Clock process definitions >>> clk_process :process >>> begin >>> clk <= '0'; >>> wait for clk_period/2; >>> clk <= '1'; >>> wait for clk_period/2; >>> end process; >>> >>> >>> -- Stimulus process >>> stim_proc: process >>> begin >>> reset <= '1'; >>> wait for clk_period; >>> reset <= '0'; >>> >>> wait; >>> end process; >> >> Great! So I don't really need to even simulate it. I know exactly what >> this code will do. Thanks a lot! > > And here is a result of simulation :) > http://fforum.winglion.ru/viewtopic.php?f=3&t=3124 Simulation of what? I've only seen a reset line and a clock. The rest of that is undefined behavior to me. Besides, looking at waveforms is not a very productive method of test. > Your global mistake you are rely in unit-tests rather than higher level test style. "Higher level test style" is a euphemism for functional test which is not the best way to verify that something meets a spec. But since I don't have a spec I can't verify a design meets it. > You will know absolutely nothing about whole CPU after running test for register, ALU, system bus etc. Even if unit tests passed ok, connected units may fail because of different interface or cycles mismatching. All these problem may be revealed at integration level testing, then stimulus are applied to connected units, not to every unit one by one. The next step is system level test. If you are so smart, please explain me what is it. You are making assumptions for what testing I would do. We call that a straw man argument. You propose what I would do, then attack it. When you decide to stop playing the one-upmanship game I'll be happy to talk to you. I'm not here for a pissing contest. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-25 10:03 -0700 |
| Message-ID | <10333e67-bd04-4695-8e8e-ad6b18e6e88d@googlegroups.com> |
| In reply to | #58098 |
вторник, 25 апреля 2017 г., 19:41:34 UTC+3 пользователь rickman написал: > On 4/25/2017 7:44 AM, Ilya Tarasov wrote: > > вторник, 25 апреля 2017 г., 3:36:45 UTC+3 пользователь rickman написал: > >>> You don't need interface. With properly approach you need only this: > >>> > >>> -- Clock process definitions > >>> clk_process :process > >>> begin > >>> clk <= '0'; > >>> wait for clk_period/2; > >>> clk <= '1'; > >>> wait for clk_period/2; > >>> end process; > >>> > >>> > >>> -- Stimulus process > >>> stim_proc: process > >>> begin > >>> reset <= '1'; > >>> wait for clk_period; > >>> reset <= '0'; > >>> > >>> wait; > >>> end process; > >> > >> Great! So I don't really need to even simulate it. I know exactly what > >> this code will do. Thanks a lot! > > > > And here is a result of simulation :) > > http://fforum.winglion.ru/viewtopic.php?f=3&t=3124 > > Simulation of what? I've only seen a reset line and a clock. The rest > of that is undefined behavior to me. Besides, looking at waveforms is > not a very productive method of test. Yes, I see you still can't understand an idea I clearly describe above. All functionality provides by program code generated by cross-compiler. When this image of program added to memory model, providing clock signal will start to issue commands one by one. In this case I don't need to type commands and data in VHDL testbench, I just need to fill memory by my program and provide clock model. All CPU signals will be produced automatically. I'm very glad you find an idea about waveforms. Take a look on assert operator in VHDL and think what else can be provided by Forth cross-compiler. You can search by keywords 'golden output' etc. This should point you to right way. > > Your global mistake you are rely in unit-tests rather than higher level test style. > > "Higher level test style" is a euphemism for functional test which is > not the best way to verify that something meets a spec. But since I > don't have a spec I can't verify a design meets it. I have a program in Forth and test it on PC. Now I know a result. When I copy this text to Forth-CPU IDE, build memory image and copy it to the simulation folder. After several cycles I want to see exactly the same result in the simulator - at the top of stack, for example. What specs? > > You will know absolutely nothing about whole CPU after running test for register, ALU, system bus etc. Even if unit tests passed ok, connected units may fail because of different interface or cycles mismatching. All these problem may be revealed at integration level testing, then stimulus are applied to connected units, not to every unit one by one. The next step is system level test. If you are so smart, please explain me what is it. > > You are making assumptions for what testing I would do. We call that a > straw man argument. You propose what I would do, then attack it. When > you decide to stop playing the one-upmanship game I'll be happy to talk > to you. I'm not here for a pissing contest. It is your answer, not mine. I suggest to use simple test with automatic stimulus generation, based on Forth-generated data. If you don't understand it, the only possible way for you is to write separate testbenches. This is simple and I don't need to know every line of your code.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-24 12:20 -0500 |
| Message-ID | <odlbvu$m89$1@dont-email.me> |
| In reply to | #57963 |
On 4/24/2017 1:20 AM, rickman wrote: > On 4/23/2017 10:59 PM, Cecil Bayona wrote: >> On 4/23/2017 8:52 PM, rickman wrote: >> 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. Maybe because LUTS and RAM is all that is inside the FPGA, so one must utilize them well. A more complex design requires more LUTs in order to have speed by parallelism, wider CPU words require more LUTS of which there is a finite number, use the FPGA too densely and then you start getting timing issues unless you manually place everything for optimum speed not an easy task for a beginner. My knowledge is based on what I have read, not what I have done so I have to rely on what the experts say. I also have a limited budget so buying huge FPGA Development system is out, so I use small cheap devices such as the Brevia2 that gives me a lot of features for low dollars but with finite resources. When I say RAM I'm talking about program RAM, some of these designs do not have much Program RAM the ep32 and the J1 are examples of that. I intend to write complex software for them not hand assemble of a couple of operations and that is why I'm working first on a Forth compiler that is easily adaptable to create code for various machines because otherwise on any customized CPU there is no software available from anyone else and a CPU is useless without Development Software. Try to encourage me instead of discouraging me, and once the compiler is finished I might make a special version for your CPU. > > 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. > Not necessarily depends on your instruction encoding, the J1 uses horizontal encoding, more features and parallel operations means more program RAM, the ep32 is not horizontal, it uses 6 bits to an instruction except for a few cases, within those 6 bits there are many unused opcodes, so adding opcodes does not increase Program Ram usage but decreases it because an optimizing compiler can take advantage of those extra instructions to cut down the program size. There are many options and there isn't just one way to do it. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 14:12 -0400 |
| Message-ID | <odlevm$1af$1@dont-email.me> |
| In reply to | #58010 |
On 4/24/2017 1:20 PM, Cecil Bayona wrote: > On 4/24/2017 1:20 AM, rickman wrote: >> On 4/23/2017 10:59 PM, Cecil Bayona wrote: >>> On 4/23/2017 8:52 PM, rickman wrote: > >>> 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. > > Maybe because LUTS and RAM is all that is inside the FPGA, so one must > utilize them well. A more complex design requires more LUTs in order to > have speed by parallelism, wider CPU words require more LUTS of which > there is a finite number, use the FPGA too densely and then you start > getting timing issues unless you manually place everything for optimum > speed not an easy task for a beginner. You seem to be repeating the same thought, that LUT count is paramount. There are many aspects to a good design and LUT usage is just one. Everything in life is finite including time. Timing issues are more likely caused by the logic requiring too many layers than a crowded part. But timing is a design goal and you only need to meet your requirement. Hand placement doesn't automatically improve timing. Placement is a hugely complex task. If the structure is very (with the emphasis on *very*) simple, hand placement can optimize timing. Otherwise you will find moving one thing to improve timing can make three things worse. > My knowledge is based on what I have read, not what I have done so I > have to rely on what the experts say. I also have a limited budget so > buying huge FPGA Development system is out, so I use small cheap devices > such as the Brevia2 that gives me a lot of features for low dollars but > with finite resources. The LFXP2-5E in the Brevia 2 board has 5000 LUTs. If you get anywhere near using all of them you are likely not getting an efficient synthesis. My 16/18 bit stack processor was only a few hundred LUTs. Don't worry about things you don't need to worry about. > When I say RAM I'm talking about program RAM, some of these designs do > not have much Program RAM the ep32 and the J1 are examples of that. I > intend to write complex software for them not hand assemble of a couple > of operations and that is why I'm working first on a Forth compiler that > is easily adaptable to create code for various machines because > otherwise on any customized CPU there is no software available from > anyone else and a CPU is useless without Development Software. > > Try to encourage me instead of discouraging me, and once the compiler is > finished I might make a special version for your CPU. Sorry if I sound like I am trying to discourage you. I'm just trying to help you not waste time in ineffective areas. Certainly I could use help with compiling. I basically wrote an assembler which was idiot simple as the opcodes were mapped 1 to 1 to the mnemonics for the most part. The only instructions with variable fields were the literal and the jump/call. Oddly enough the jump/call gave me trouble. It uses PC relative addressing and when jumping backwards across the instruction there was a variable length of instructions to build the address. The value to be compiled would affect the starting address and so the value needing to be compiled. In the end I found if I just calculated the address twice it would work. But I was never happy with that. A new approach I would be interested in exploring combines a register oriented instruction set with a stack design by using register numbers to operate on values not at the top of the stack. Combined with a variable number of items for push/pop and it can eliminate most stack juggling operations. I suppose some would view this as "combining" multiple instructions. I don't have a clue as to mapping this to a Forth model. >> 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. >> > > Not necessarily depends on your instruction encoding, the J1 uses > horizontal encoding, more features and parallel operations means more > program RAM, the ep32 is not horizontal, it uses 6 bits to an > instruction except for a few cases, within those 6 bits there are many > unused opcodes, so adding opcodes does not increase Program Ram usage > but decreases it because an optimizing compiler can take advantage of > those extra instructions to cut down the program size. That's because the extra bit has already been allocated and the space used. *How much* can the program size be reduced by using extra opcodes? The point is fancy features don't get used so often and so provide small gains to program size or speed. That's why Koopman's book is useful. I don't remember who, but I think someone has published a list of Forth idioms that can be used to optimize code. But they often require multiple operations and so can't be done in a single clock cycle. Single cycle operation of all instructions is a primary objective in my designs. Multi-cycle operation complicates the CPU in many ways making it less efficient by most measures. > There are many options and there isn't just one way to do it. Nope, there isn't just one way. But trends are trends and it is very enlightening to explore a variety of spaces without digging in any too deep. Learn the trends without focusing on any and you will see most of the things that look like good ideas won't be significant improvements. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-24 15:13 -0500 |
| Message-ID | <odlm37$rl1$1@dont-email.me> |
| In reply to | #58012 |
On 4/24/2017 1:12 PM, rickman wrote: > On 4/24/2017 1:20 PM, Cecil Bayona wrote: >> On 4/24/2017 1:20 AM, rickman wrote: >>> On 4/23/2017 10:59 PM, Cecil Bayona wrote: >>>> On 4/23/2017 8:52 PM, rickman wrote: >> >>>> 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. >> >> Maybe because LUTS and RAM is all that is inside the FPGA, so one must >> utilize them well. A more complex design requires more LUTs in order to >> have speed by parallelism, wider CPU words require more LUTS of which >> there is a finite number, use the FPGA too densely and then you start >> getting timing issues unless you manually place everything for optimum >> speed not an easy task for a beginner. > > You seem to be repeating the same thought, that LUT count is paramount. > There are many aspects to a good design and LUT usage is just one. > Everything in life is finite including time. > > Timing issues are more likely caused by the logic requiring too many > layers than a crowded part. But timing is a design goal and you only > need to meet your requirement. > > Hand placement doesn't automatically improve timing. Placement is a > hugely complex task. If the structure is very (with the emphasis on > *very*) simple, hand placement can optimize timing. Otherwise you will > find moving one thing to improve timing can make three things worse. > > >> My knowledge is based on what I have read, not what I have done so I >> have to rely on what the experts say. I also have a limited budget so >> buying huge FPGA Development system is out, so I use small cheap devices >> such as the Brevia2 that gives me a lot of features for low dollars but >> with finite resources. > > The LFXP2-5E in the Brevia 2 board has 5000 LUTs. If you get anywhere > near using all of them you are likely not getting an efficient > synthesis. My 16/18 bit stack processor was only a few hundred LUTs. > Don't worry about things you don't need to worry about. > > >> When I say RAM I'm talking about program RAM, some of these designs do >> not have much Program RAM the ep32 and the J1 are examples of that. I >> intend to write complex software for them not hand assemble of a couple >> of operations and that is why I'm working first on a Forth compiler that >> is easily adaptable to create code for various machines because >> otherwise on any customized CPU there is no software available from >> anyone else and a CPU is useless without Development Software. >> >> Try to encourage me instead of discouraging me, and once the compiler is >> finished I might make a special version for your CPU. > > Sorry if I sound like I am trying to discourage you. I'm just trying to > help you not waste time in ineffective areas. > > Certainly I could use help with compiling. I basically wrote an > assembler which was idiot simple as the opcodes were mapped 1 to 1 to > the mnemonics for the most part. The only instructions with variable > fields were the literal and the jump/call. Oddly enough the jump/call > gave me trouble. It uses PC relative addressing and when jumping > backwards across the instruction there was a variable length of > instructions to build the address. The value to be compiled would > affect the starting address and so the value needing to be compiled. In > the end I found if I just calculated the address twice it would work. > But I was never happy with that. > > A new approach I would be interested in exploring combines a register > oriented instruction set with a stack design by using register numbers > to operate on values not at the top of the stack. Combined with a > variable number of items for push/pop and it can eliminate most stack > juggling operations. I suppose some would view this as "combining" > multiple instructions. I don't have a clue as to mapping this to a > Forth model. > > >>> 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. >>> >> >> Not necessarily depends on your instruction encoding, the J1 uses >> horizontal encoding, more features and parallel operations means more >> program RAM, the ep32 is not horizontal, it uses 6 bits to an >> instruction except for a few cases, within those 6 bits there are many >> unused opcodes, so adding opcodes does not increase Program Ram usage >> but decreases it because an optimizing compiler can take advantage of >> those extra instructions to cut down the program size. > > That's because the extra bit has already been allocated and the space > used. *How much* can the program size be reduced by using extra > opcodes? The point is fancy features don't get used so often and so > provide small gains to program size or speed. That's why Koopman's book > is useful. > > I don't remember who, but I think someone has published a list of Forth > idioms that can be used to optimize code. But they often require > multiple operations and so can't be done in a single clock cycle. Single > cycle operation of all instructions is a primary objective in my > designs. Multi-cycle operation complicates the CPU in many ways making > it less efficient by most measures. > > >> There are many options and there isn't just one way to do it. > > Nope, there isn't just one way. But trends are trends and it is very > enlightening to explore a variety of spaces without digging in any too > deep. Learn the trends without focusing on any and you will see most of > the things that look like good ideas won't be significant improvements. > Arrg... I give up, I know nothing, you know it all, not point here. By the way where are your CPU designs published? I would like to look at a perfect design. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-24 16:59 -0400 |
| Message-ID | <odloqf$4ee$3@dont-email.me> |
| In reply to | #58016 |
On 4/24/2017 4:13 PM, Cecil Bayona wrote: > On 4/24/2017 1:12 PM, rickman wrote: >> On 4/24/2017 1:20 PM, Cecil Bayona wrote: >>> On 4/24/2017 1:20 AM, rickman wrote: >>>> On 4/23/2017 10:59 PM, Cecil Bayona wrote: >>>>> On 4/23/2017 8:52 PM, rickman wrote: >>> >>>>> 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. >>> >>> Maybe because LUTS and RAM is all that is inside the FPGA, so one must >>> utilize them well. A more complex design requires more LUTs in order to >>> have speed by parallelism, wider CPU words require more LUTS of which >>> there is a finite number, use the FPGA too densely and then you start >>> getting timing issues unless you manually place everything for optimum >>> speed not an easy task for a beginner. >> >> You seem to be repeating the same thought, that LUT count is >> paramount. There are many aspects to a good design and LUT usage is >> just one. Everything in life is finite including time. >> >> Timing issues are more likely caused by the logic requiring too many >> layers than a crowded part. But timing is a design goal and you only >> need to meet your requirement. >> >> Hand placement doesn't automatically improve timing. Placement is a >> hugely complex task. If the structure is very (with the emphasis on >> *very*) simple, hand placement can optimize timing. Otherwise you >> will find moving one thing to improve timing can make three things worse. >> >> >>> My knowledge is based on what I have read, not what I have done so I >>> have to rely on what the experts say. I also have a limited budget so >>> buying huge FPGA Development system is out, so I use small cheap devices >>> such as the Brevia2 that gives me a lot of features for low dollars but >>> with finite resources. >> >> The LFXP2-5E in the Brevia 2 board has 5000 LUTs. If you get anywhere >> near using all of them you are likely not getting an efficient >> synthesis. My 16/18 bit stack processor was only a few hundred LUTs. >> Don't worry about things you don't need to worry about. >> >> >>> When I say RAM I'm talking about program RAM, some of these designs do >>> not have much Program RAM the ep32 and the J1 are examples of that. I >>> intend to write complex software for them not hand assemble of a couple >>> of operations and that is why I'm working first on a Forth compiler that >>> is easily adaptable to create code for various machines because >>> otherwise on any customized CPU there is no software available from >>> anyone else and a CPU is useless without Development Software. >>> >>> Try to encourage me instead of discouraging me, and once the compiler is >>> finished I might make a special version for your CPU. >> >> Sorry if I sound like I am trying to discourage you. I'm just trying >> to help you not waste time in ineffective areas. >> >> Certainly I could use help with compiling. I basically wrote an >> assembler which was idiot simple as the opcodes were mapped 1 to 1 to >> the mnemonics for the most part. The only instructions with variable >> fields were the literal and the jump/call. Oddly enough the jump/call >> gave me trouble. It uses PC relative addressing and when jumping >> backwards across the instruction there was a variable length of >> instructions to build the address. The value to be compiled would >> affect the starting address and so the value needing to be compiled. >> In the end I found if I just calculated the address twice it would >> work. But I was never happy with that. >> >> A new approach I would be interested in exploring combines a register >> oriented instruction set with a stack design by using register numbers >> to operate on values not at the top of the stack. Combined with a >> variable number of items for push/pop and it can eliminate most stack >> juggling operations. I suppose some would view this as "combining" >> multiple instructions. I don't have a clue as to mapping this to a >> Forth model. >> >> >>>> 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. >>>> >>> >>> Not necessarily depends on your instruction encoding, the J1 uses >>> horizontal encoding, more features and parallel operations means more >>> program RAM, the ep32 is not horizontal, it uses 6 bits to an >>> instruction except for a few cases, within those 6 bits there are many >>> unused opcodes, so adding opcodes does not increase Program Ram usage >>> but decreases it because an optimizing compiler can take advantage of >>> those extra instructions to cut down the program size. >> >> That's because the extra bit has already been allocated and the space >> used. *How much* can the program size be reduced by using extra >> opcodes? The point is fancy features don't get used so often and so >> provide small gains to program size or speed. That's why Koopman's >> book is useful. >> >> I don't remember who, but I think someone has published a list of >> Forth idioms that can be used to optimize code. But they often >> require multiple operations and so can't be done in a single clock >> cycle. Single cycle operation of all instructions is a primary >> objective in my designs. Multi-cycle operation complicates the CPU in >> many ways making it less efficient by most measures. >> >> >>> There are many options and there isn't just one way to do it. >> >> Nope, there isn't just one way. But trends are trends and it is very >> enlightening to explore a variety of spaces without digging in any too >> deep. Learn the trends without focusing on any and you will see most >> of the things that look like good ideas won't be significant >> improvements. >> > Arrg... I give up, I know nothing, you know it all, not point here. > > By the way where are your CPU designs published? I would like to look at > a perfect design. Sorry I bothered you. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-24 14:35 -0700 |
| Message-ID | <763ef20a-3e15-4f91-9b0e-e9ff7df10d32@googlegroups.com> |
| In reply to | #58010 |
понедельник, 24 апреля 2017 г., 20:21:02 UTC+3 пользователь Cecil - k5nwa написал: > On 4/24/2017 1:20 AM, rickman wrote: > > On 4/23/2017 10:59 PM, Cecil Bayona wrote: > >> On 4/23/2017 8:52 PM, rickman wrote: > > >> 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. > > Maybe because LUTS and RAM is all that is inside the FPGA, so one must > utilize them well. A more complex design requires more LUTs in order to > have speed by parallelism, wider CPU words require more LUTS of which > there is a finite number, use the FPGA too densely and then you start > getting timing issues unless you manually place everything for optimum > speed not an easy task for a beginner. > > My knowledge is based on what I have read, not what I have done so I > have to rely on what the experts say. I also have a limited budget so > buying huge FPGA Development system is out, so I use small cheap devices > such as the Brevia2 that gives me a lot of features for low dollars but > with finite resources. Take a look on Arty board. It is 99$, but has 35K logic cells vs 5K in Lattice. > When I say RAM I'm talking about program RAM, some of these designs do > not have much Program RAM the ep32 and the J1 are examples of that. I > intend to write complex software for them not hand assemble of a couple > of operations and that is why I'm working first on a Forth compiler that > is easily adaptable to create code for various machines because > otherwise on any customized CPU there is no software available from > anyone else and a CPU is useless without Development Software. > > Try to encourage me instead of discouraging me, and once the compiler is > finished I might make a special version for your CPU. Don't listen those who wants to discourage you. CPU design is not a mystical skill for chosens. It is impossible to seriously discuss CPU details before you will have 5 designs done. Start from the simplest design and make it working. Command encoding and pipeline optimization often represent a false path without proper experience and understanding pipeline really good. Btw, stack machine is easy to understand and implement in VHDL, if you familiar with Forth.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-24 17:19 -0500 |
| Message-ID | <odltfh$n4r$1@dont-email.me> |
| In reply to | #58023 |
On 4/24/2017 4:35 PM, Ilya Tarasov wrote: > понедельник, 24 апреля 2017 г., 20:21:02 UTC+3 пользователь Cecil - k5nwa написал: >> On 4/24/2017 1:20 AM, rickman wrote: >>> On 4/23/2017 10:59 PM, Cecil Bayona wrote: >>>> On 4/23/2017 8:52 PM, rickman wrote: >> >>>> 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. >> >> Maybe because LUTS and RAM is all that is inside the FPGA, so one must >> utilize them well. A more complex design requires more LUTs in order to >> have speed by parallelism, wider CPU words require more LUTS of which >> there is a finite number, use the FPGA too densely and then you start >> getting timing issues unless you manually place everything for optimum >> speed not an easy task for a beginner. >> >> My knowledge is based on what I have read, not what I have done so I >> have to rely on what the experts say. I also have a limited budget so >> buying huge FPGA Development system is out, so I use small cheap devices >> such as the Brevia2 that gives me a lot of features for low dollars but >> with finite resources. > > Take a look on Arty board. It is 99$, but has 35K logic cells vs 5K in Lattice. > >> When I say RAM I'm talking about program RAM, some of these designs do >> not have much Program RAM the ep32 and the J1 are examples of that. I >> intend to write complex software for them not hand assemble of a couple >> of operations and that is why I'm working first on a Forth compiler that >> is easily adaptable to create code for various machines because >> otherwise on any customized CPU there is no software available from >> anyone else and a CPU is useless without Development Software. >> >> Try to encourage me instead of discouraging me, and once the compiler is >> finished I might make a special version for your CPU. > > Don't listen those who wants to discourage you. CPU design is not a mystical skill for chosens. It is impossible to seriously discuss CPU details before you will have 5 designs done. Start from the simplest design and make it working. Command encoding and pipeline optimization often represent a false path without proper experience and understanding pipeline really good. Btw, stack machine is easy to understand and implement in VHDL, if you familiar with Forth. > Thanks, the Arty gives you a lot for the money and I have read that its fast, I'll start saving my pennies. I have already tried four different CPUs designed by someone else, ep16, ep32, PDP1, i8080 next I want to try the J1, I want to make some small changes to it after it works, it's available in VHDL and Verilog, the original design was in Verilog. I have an optimized version that is 140 lines of Verilog, looking at it I can see that its very simple language. I keep being undecided on which language to learn, Verilog looks simple, VHDL has a lot of error checking, I'm not ready yet to start learning as I'm in the middle of a software project having to do with FPGA CPUs but maybe in a couple of Month I will be ready. What tools do you use with the Xilinx FPGA Vivado, ISE WebPack, or something else? -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-24 15:36 -0700 |
| Message-ID | <2d14b305-7de7-4499-9d2e-b218d52e5c7a@googlegroups.com> |
| In reply to | #58030 |
> Thanks, the Arty gives you a lot for the money and I have read that its > fast, I'll start saving my pennies. No matter, you can use what you feel better for you. > I have already tried four different CPUs designed by someone else, ep16, > ep32, PDP1, i8080 next I want to try the J1, I want to make some small > changes to it after it works, it's available in VHDL and Verilog, the > original design was in Verilog. I have an optimized version that is 140 > lines of Verilog, looking at it I can see that its very simple language. > > I keep being undecided on which language to learn, Verilog looks simple, > VHDL has a lot of error checking, I'm not ready yet to start learning as > I'm in the middle of a software project having to do with FPGA CPUs but > maybe in a couple of Month I will be ready. Verilog is often compared with C, and VHDL is very close to Ada. VHDL code is larger and considered as complex. However it is well structured and you will always been prompted when forgot to complete operands. Also, VHDL don't allows automatic type casting, and this is not bad at the early stage. From my teaching experince, VHDL->Verilog is better than Verilog->VHDL, if you plan to learn both languages. > What tools do you use with the Xilinx FPGA Vivado, ISE WebPack, or > something else? ISE must be used for Spartan-6, because Vivado can support Xilinx FPGA started from the 7 series. Vivado is current CAD and has free version too. For 7 series FPGA you can use both ISE and Vivado.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-25 01:26 -0700 |
| Message-ID | <29029760-e93f-4a75-a280-23b5ffa00ecf@googlegroups.com> |
| In reply to | #58030 |
On Monday, 24 April 2017 23:19:29 UTC+1, Cecil - k5nwa wrote: > I keep being undecided on which language to learn, Verilog looks simple, > VHDL has a lot of error checking, I'm not ready yet to start learning as > I'm in the middle of a software project having to do with FPGA CPUs but > maybe in a couple of Month I will be ready. > I'm in exactly the same place as you. I'm leaning more towards Verilog because it looks easier to understand.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-25 11:21 -0500 |
| Message-ID | <odnssu$6m5$1@dont-email.me> |
| In reply to | #58073 |
On 4/25/2017 3:26 AM, Mark Wills wrote: > On Monday, 24 April 2017 23:19:29 UTC+1, Cecil - k5nwa wrote: >> I keep being undecided on which language to learn, Verilog looks simple, >> VHDL has a lot of error checking, I'm not ready yet to start learning as >> I'm in the middle of a software project having to do with FPGA CPUs but >> maybe in a couple of Month I will be ready. >> > > I'm in exactly the same place as you. I'm leaning more towards Verilog because > it looks easier to understand. > Indecision on my part, every time I'm fairly convinced to go with Verilog because it looks so straightforward I find comments from experts that recommend VHDL instead. It looks like Verilog is a lot easier to understand so my current thinking is to go ahead and work with it and get some things done then later at my leisure dwell into VHDL. I used to design hardware and I miss it, hence FPGAs the hardware designers dream come true to try out design ideas. I like simple designs they keep you out of trouble when it comes to CPUs the concepts in the J1 are a nice starting point it works well but there are major room for improvements with easy remedies so that will be a good starting point to get my feet wet. So eventually a J1-2 maybe although I've read that there is a J2, J3, J4, J5, and a J6 each progressively more advance by other authors, the J6 is extremely complex with multiple levels of pipeline. I'm not interested in a J6 if I wanted that I would use an Intel CPU. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-25 09:50 -0700 |
| Message-ID | <f75d1897-a0ce-433f-9612-0000c6e0e61f@googlegroups.com> |
| In reply to | #58096 |
вторник, 25 апреля 2017 г., 19:21:51 UTC+3 пользователь Cecil - k5nwa написал: > On 4/25/2017 3:26 AM, Mark Wills wrote: > > On Monday, 24 April 2017 23:19:29 UTC+1, Cecil - k5nwa wrote: > >> I keep being undecided on which language to learn, Verilog looks simple, > >> VHDL has a lot of error checking, I'm not ready yet to start learning as > >> I'm in the middle of a software project having to do with FPGA CPUs but > >> maybe in a couple of Month I will be ready. > >> > > > > I'm in exactly the same place as you. I'm leaning more towards Verilog because > > it looks easier to understand. > > > > Indecision on my part, every time I'm fairly convinced to go with > Verilog because it looks so straightforward I find comments from experts > that recommend VHDL instead. > > It looks like Verilog is a lot easier to understand so my current > thinking is to go ahead and work with it and get some things done then > later at my leisure dwell into VHDL. Yes, it is true. But result is predictable - when turning to VHDL, one will need to learn more complex VHDL and design concepts as well. VHDL is not very complex to learn, indeed, it is a question of remembering some code patterns, but after VHDL, Verilog looks easier. Also, there are some checks performed in VHDL. For example, Verilog provides automatic type casting and signal width alignment. It looks fine, until you got a hidden mistake when you 8-bit bus is connected to 16-bit and all missing bits quietly replaces by zero in Verilog. VHDL will not allow such tricks. It takes slightly more time to type CPU sources, but saves much more at debugging stage.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-25 12:37 -0500 |
| Message-ID | <odo1be$n7h$1@dont-email.me> |
| In reply to | #58100 |
On 4/25/2017 11:50 AM, Ilya Tarasov wrote: > вторник, 25 апреля 2017 г., 19:21:51 UTC+3 пользователь Cecil - k5nwa написал: >> On 4/25/2017 3:26 AM, Mark Wills wrote: >>> On Monday, 24 April 2017 23:19:29 UTC+1, Cecil - k5nwa wrote: >>>> I keep being undecided on which language to learn, Verilog looks simple, >>>> VHDL has a lot of error checking, I'm not ready yet to start learning as >>>> I'm in the middle of a software project having to do with FPGA CPUs but >>>> maybe in a couple of Month I will be ready. >>>> >>> >>> I'm in exactly the same place as you. I'm leaning more towards Verilog because >>> it looks easier to understand. >>> >> >> Indecision on my part, every time I'm fairly convinced to go with >> Verilog because it looks so straightforward I find comments from experts >> that recommend VHDL instead. >> >> It looks like Verilog is a lot easier to understand so my current >> thinking is to go ahead and work with it and get some things done then >> later at my leisure dwell into VHDL. > > Yes, it is true. But result is predictable - when turning to VHDL, one will need to learn more complex VHDL and design concepts as well. VHDL is not very complex to learn, indeed, it is a question of remembering some code patterns, but after VHDL, Verilog looks easier. > > Also, there are some checks performed in VHDL. For example, Verilog provides automatic type casting and signal width alignment. It looks fine, until you got a hidden mistake when you 8-bit bus is connected to 16-bit and all missing bits quietly replaces by zero in Verilog. VHDL will not allow such tricks. It takes slightly more time to type CPU sources, but saves much more at debugging stage. > That is what I keep reading about from persons that are quite experience in using VHDL that is why I keep being undecided. Verilog looks a lot simpler to learn but I quit using C a long time back because it quietly lets you do things that will get you in trouble. The experts tend to think the same thing about Verilog, it's easier to learn up front but will not protect you from dumb mistakes. Human nature can often work out against a persons best interest. Take the quicker route but pay for the rest of your life. Too many persons with vast experience on FPGAs keep coming up with the same advice it would most likely be prudent to listen to it and learn the more difficult approach up front rather than pay for the simpler way many times over. I have books on both languages so I will think about it for a month or two before I have to make a decision. Thanks for the advice. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-25 14:11 -0400 |
| Message-ID | <odo3av$tts$1@dont-email.me> |
| In reply to | #58105 |
On 4/25/2017 1:37 PM, Cecil Bayona wrote: > On 4/25/2017 11:50 AM, Ilya Tarasov wrote: >> вторник, 25 апреля 2017 г., 19:21:51 UTC+3 пользователь Cecil - k5nwa >> написал: >>> On 4/25/2017 3:26 AM, Mark Wills wrote: >>>> On Monday, 24 April 2017 23:19:29 UTC+1, Cecil - k5nwa wrote: >>>>> I keep being undecided on which language to learn, Verilog looks >>>>> simple, >>>>> VHDL has a lot of error checking, I'm not ready yet to start >>>>> learning as >>>>> I'm in the middle of a software project having to do with FPGA CPUs >>>>> but >>>>> maybe in a couple of Month I will be ready. >>>>> >>>> >>>> I'm in exactly the same place as you. I'm leaning more towards >>>> Verilog because >>>> it looks easier to understand. >>>> >>> >>> Indecision on my part, every time I'm fairly convinced to go with >>> Verilog because it looks so straightforward I find comments from experts >>> that recommend VHDL instead. >>> >>> It looks like Verilog is a lot easier to understand so my current >>> thinking is to go ahead and work with it and get some things done then >>> later at my leisure dwell into VHDL. >> >> Yes, it is true. But result is predictable - when turning to VHDL, one >> will need to learn more complex VHDL and design concepts as well. VHDL >> is not very complex to learn, indeed, it is a question of remembering >> some code patterns, but after VHDL, Verilog looks easier. >> >> Also, there are some checks performed in VHDL. For example, Verilog >> provides automatic type casting and signal width alignment. It looks >> fine, until you got a hidden mistake when you 8-bit bus is connected >> to 16-bit and all missing bits quietly replaces by zero in Verilog. >> VHDL will not allow such tricks. It takes slightly more time to type >> CPU sources, but saves much more at debugging stage. >> > > That is what I keep reading about from persons that are quite experience > in using VHDL that is why I keep being undecided. Verilog looks a lot > simpler to learn but I quit using C a long time back because it quietly > lets you do things that will get you in trouble. The experts tend to > think the same thing about Verilog, it's easier to learn up front but > will not protect you from dumb mistakes. But if you know these are mistakes, can't you avoid them on your own? I have used VHDL for so long that I don't even have to think about avoiding all the compiler complaints, it is pretty automatic. If I knew the issues to avoid in Verilog I don't think I would have too much trouble with it. > Human nature can often work out against a persons best interest. Take > the quicker route but pay for the rest of your life. Too many persons > with vast experience on FPGAs keep coming up with the same advice it > would most likely be prudent to listen to it and learn the more > difficult approach up front rather than pay for the simpler way many > times over. I've never met anyone using Verilog that thought it was a mistake. Where is Bernd Paysan to weigh in? > I have books on both languages so I will think about it for a month or > two before I have to make a decision. I have one book in *both* languages, "HDL Chip Design" by Douglas J Smith. It is not organized like a typical text book starting you at the basics of HDL. It does however, show each example in VHDL and Verilog side by side. Unless it has been updated for VHDL-2008 it shows VHDL-1993 as my copy does. I strongly encourage anyone interested in VHDL to learn VHDL-2008. If you don't, there is little point to using VHDL, that's how significant the improvements are. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-25 13:51 -0500 |
| Message-ID | <odo5kt$6ct$1@dont-email.me> |
| In reply to | #58110 |
On 4/25/2017 1:11 PM, rickman wrote: > On 4/25/2017 1:37 PM, Cecil Bayona wrote: > > But if you know these are mistakes, can't you avoid them on your own? > > I have used VHDL for so long that I don't even have to think about > avoiding all the compiler complaints, it is pretty automatic. If I knew > the issues to avoid in Verilog I don't think I would have too much > trouble with it. > > That is what I think about sometimes, even in C one can be careful and avoid the dumb mistakes but one has to be paying attention to the subtle issues. >> Human nature can often work out against a persons best interest. Take >> the quicker route but pay for the rest of your life. Too many persons >> with vast experience on FPGAs keep coming up with the same advice it >> would most likely be prudent to listen to it and learn the more >> difficult approach up front rather than pay for the simpler way many >> times over. > > I've never met anyone using Verilog that thought it was a mistake. Where > is Bernd Paysan to weigh in? > > >> I have books on both languages so I will think about it for a month or >> two before I have to make a decision. > > I have one book in *both* languages, "HDL Chip Design" by Douglas J > Smith. It is not organized like a typical text book starting you at the > basics of HDL. It does however, show each example in VHDL and Verilog > side by side. Unless it has been updated for VHDL-2008 it shows > VHDL-1993 as my copy does. I strongly encourage anyone interested in > VHDL to learn VHDL-2008. If you don't, there is little point to using > VHDL, that's how significant the improvements are. > I have that book not useful for learning the language from scratch but useful for the examples on how to do things. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-25 15:14 -0400 |
| Message-ID | <odo71g$btn$1@dont-email.me> |
| In reply to | #58120 |
On 4/25/2017 2:51 PM, Cecil Bayona wrote: > On 4/25/2017 1:11 PM, rickman wrote: >> On 4/25/2017 1:37 PM, Cecil Bayona wrote: > >> >> But if you know these are mistakes, can't you avoid them on your own? >> >> I have used VHDL for so long that I don't even have to think about >> avoiding all the compiler complaints, it is pretty automatic. If I >> knew the issues to avoid in Verilog I don't think I would have too >> much trouble with it. >> >> > > That is what I think about sometimes, even in C one can be careful and > avoid the dumb mistakes but one has to be paying attention to the subtle > issues. I think that is where we differ. I don't think the issues are subtle. They are pretty obvious in my experience, at least once you learn what they are. That's why I don't want to use Verilog without a Verilog book that points them out. I don't want to design in bugs and have them get through testing only to be found in the field. >>> Human nature can often work out against a persons best interest. Take >>> the quicker route but pay for the rest of your life. Too many persons >>> with vast experience on FPGAs keep coming up with the same advice it >>> would most likely be prudent to listen to it and learn the more >>> difficult approach up front rather than pay for the simpler way many >>> times over. >> >> I've never met anyone using Verilog that thought it was a mistake. >> Where is Bernd Paysan to weigh in? >> >> >>> I have books on both languages so I will think about it for a month or >>> two before I have to make a decision. >> >> I have one book in *both* languages, "HDL Chip Design" by Douglas J >> Smith. It is not organized like a typical text book starting you at >> the basics of HDL. It does however, show each example in VHDL and >> Verilog side by side. Unless it has been updated for VHDL-2008 it >> shows VHDL-1993 as my copy does. I strongly encourage anyone >> interested in VHDL to learn VHDL-2008. If you don't, there is little >> point to using VHDL, that's how significant the improvements are. >> > > I have that book not useful for learning the language from scratch but > useful for the examples on how to do things. Both languages are pretty easy to learn actually. The only hard part is letting go of the ideas you have entrenched from writing software. HDL stands for Hardware Description Language which is how you need to treat it unless you have gobs of space in the part and don't care about the speed of your design. I design thinking of the hardware produced rather than the way I think of software which is more abstract and about the data structures and operations on them. When you describe a given behavior the tool will give you a design that implements *exactly* that behavior, no more, no less. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-25 14:15 -0400 |
| Message-ID | <odo3ii$v90$1@dont-email.me> |
| In reply to | #58105 |
On 4/25/2017 1:37 PM, Cecil Bayona wrote: > > I have books on both languages so I will think about it for a month or > two before I have to make a decision. Oh yeah, if you do decide to use VHDL I don't ever want to see you use if (clk'event and clk '1') I will hunt you down and burn your house. I can't believe there are still universities that teach this!!! I'm not over reacting am I? -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web