This is far a field but hey....
Don't get much chance these days to talk about this stuff...
Oh and thanks for your reply. It most certainly was the kind of stuff I was
looking for.
On Tue, Apr 5, 2011 at 3:40 AM, JMGross <[email protected]> wrote:
>
> ----- Ursprüngliche Nachricht -----
> Von: Eric Decker
> Gesendet am: 05 Apr 2011 03:14:40
>
> > I know what Read-Modify-Write means. At least in the context of non-TI
> > processors. :-)
> > I've designed and debugged full blown multiprocessors with nasty snooping
> > caches.
> > cache coherency is always entertaining.
>
> The MSP does not have any cache (well, actually it has on some of the newer
> 25MHz chips, where a flash read reads 32 bit instead of just the currently
> requested 16, 'cacheing' the other 16).
> It does nto need one too, since any read or write operation is done in one
> clock cycle.
>
Cache coherency doesn't really come into play until multiprocessor systems
which
also doesn't apply.
>
> > Now in the DMA machine for the CC430f5137 and msp430f5438 there is
> mention
> > of a DMARMWDIS bit. (DMACTL4).
>
> > Now TI says...
>
> > *DMARMWDIS* Bit 2 Read-modify-write disable. When set, this bit inhibits
> any
> > DMA transfers from occurring during CPU
> > read-modify-write operations.
>
> > I've looked through the instruction set and nothing jumps out at me as
> being
> > a RMW instruction.
>
> All 'bit set' or 'bit clear', as well as many (all?) AND/OR/XOR etc.
> instructions
> are RMW. If the target is a memory location, the target is read, the
> operation
> is performed and then the result is written back.
>
> >1) What does setting DMARMWDIS really do?
>
> It prevents the DMA from interrupting an ongoing RMW operation.
> The DMA can stop the CPU in any moment, holding its fetch of a
> parameter (immediate value, memory address, memory value),
> performing the DMA, then continuing with the processor.
> Settign thsi bit will prevent the DMA from interrupting between
> a target fetch and the following writeback (1 cycle later).
> This might be necessary if the operation target is a port register, where
> the read register content may change in the meantime.
> Most registers are synchronized with MCLK, but if a RMW operation
> is extended by a DMA, this synchronisation does not work anymore,
> leading to unwanted side-effects.
>
> Normally, you don't have to deal with this, but under some circumstances
> it can be critical, and it's good that TI has included this option.
>
You've used it then? Is it a good idea to not risk it but just leave it on?
Unless
there is an overriding performance reason to turn it off ie. like you
really need
the dma to run quickly and you know that it won't mess with anything. For
example
you know you are simply copying from memory say out the SPI port and the cpu
won't touch the SPI port because the cpu knows it is busy. The DMA
interrupt
makes the CPU pay attention again.
>
> > 2) Is there some mechanism for hooking h/w up in some fashion where one
> > would need RWM? When
> > would you need a RMW on one of these systems?
>
> Always when modifying any value. Hidden an din one cycle, if the target is
> a
> register, in separate memory calls if the target is a memory location.
>
So one should always run with DMARMWDIS on then?
>
> > 4) Is there a reasonable forum where one can get a real answer from
> someone
> > really in the know at TI?
>
> Try
> http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/default.aspx
>
> Well, you would probably get the same response from the same person there
> :)
> But there are some TI employees too and in difficult cases they'll forward
> the
> questions to a TI engineer.
>
> JMGross
>
> p.s.: the MSP _is_ a RISC processor, since RISC means Reduced Instruction
> Set.
>
The traditional (Patterson et. al, Berkeley and the IBM 801) includes the
concept of
the only memory operations go into registers and all other ops are register
to register.
This allows one to simplify and greatly increase the pipeline and make the
machine
run really fast. The TI ISA doesn't really fit that.
> And the MSP instruction set _is_ reduced. No fance mul/div/loop
> instructions.
> It does not mean that you have to write your programs in microcode,
> splitting
> all operations into separate instructions.
>
Yeah I know. I used to write real microcode. And when I was at cisco we
built
a network blade for FDDI that had a microcode architecture that was 180 bits
wide.
I would call the TI ISA RISC like. Perhaps splitting hairs. But it is
germaine
for the discussion about what DMARMWDIS does. If I understand it properly
because of complications of TI's RISC like architecture and implementation,
the
impact of DMA cycle stealing can have side effects and turning off the DMA
while in a processor execution cycle maintains some level of necessary
atomicity.
True RISCs avoid this kind of thing but not letting it happen. Then again
the old
machines I'm thinking of had seperate CPUs, seperate caches, and seperate
DMA
engines that talked directly to main memory. The CPUs never saw this kind
of
problem because they operated out of the cache.
Now cache coherency definitly was a problem.
> The instruction set is orthogonal. Few instructions, but source and
> destination
> being part of the instruction opcode. If you look at the instruction set
> table,
> you'll see what this means: the upper bits of the opcode define the
> instruction,
> the lower bits define source and destination and addressing mode.
> Except for a few special instructions like push or ret or reti.
> Even enabling/clearing interrupts is a plain bit set/clear operation to one
> of the
> registers (which happens to be the status register).
> Most of the mnemonics are just aliases to other operations.
> So "POP dest" is in fact a "MOV @R1+, dest" and no separate instruction.
>
>
I understand. Thanks again for your response.
eric
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
