Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.vhdl > #4414
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.lang.vhdl, comp.lang.forth |
| Subject | Re: Forth in VHDL |
| Date | 2016-07-27 10:01 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <nnaet0$nvs$1@dont-email.me> (permalink) |
| References | (8 earlier) <20160726110441.73da10eb@HP-6550b> <nn7ulv$v73$1@dont-email.me> <2016Jul26.180023@mips.complang.tuwien.ac.at> <nn84qv$m6a$1@dont-email.me> <2016Jul27.113935@mips.complang.tuwien.ac.at> |
Cross-posted to 2 groups.
On 7/27/2016 5:39 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 7/26/2016 12:00 PM, Anton Ertl wrote: >> In the GA144 there are delay paths that are >> activated for each type of instruction with a delay matched to the time >> taken for that class of instruction. > > So you no longer have to do three nops before (or was it after?) a > full-length "+"? That's new then. The way I understood the > description of the MuP21 in the earlier discussion, it had some kind > of on-chip oscillator that clocked the whole core, and the addition > could take up to four cycles. All of the ALU instructions are timed with the same timing path. The add requires extra time for the carry to settle, so one nop is required before an addition unless the previous instruction does not modify either of the two operands in which case no nop is needed. Other, non-alu instructions have various timings and have other timing paths. It is definitely *not* one timing path for the "whole core". I don't recall the various classes of instructions that have separate timing from the ALU, but at one point I made a timing based tool in a spread sheet. Type in the instructions and it gave you the timing. I think it even accounted for instruction word boundaries which require additional timing for the next word fetch under some conditions. -- Rick C
Back to comp.lang.vhdl | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 22:29 -0400
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 23:01 -0400
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-24 23:05 -0400
Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 22:25 -0500
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 00:08 -0400
Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 23:57 -0500
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 01:22 -0400
Re: Forth in VHDL Paul Rubin <no.email@nospam.invalid> - 2016-07-24 22:38 -0700
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 01:53 -0400
Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-25 14:11 -0500
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 17:39 -0400
Re: Forth in VHDL Cecil Bayona <cbayona@cbayona.com> - 2016-07-25 18:01 -0500
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-25 19:40 -0400
Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-26 11:04 +0100
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 11:13 -0400
Re: Forth in VHDL anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-26 16:00 +0000
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-26 12:58 -0400
Re: Forth in VHDL anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 09:39 +0000
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 10:01 -0400
Re: Forth in VHDL Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-27 22:46 +0100
Re: Forth in VHDL rickman <gnuarm@gmail.com> - 2016-07-27 18:15 -0400
csiph-web