• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 410 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

What is a program write?

William Bagshaw62337
Prodigy 90 points

On the 28335, and I think the 2812, the manual talks about a program write. Which instruction causes a program write? It is supposed to take one wait state on the 28335 in L5 etc. But what is a program write? I can understand that an instruction fetch is a program read, but all program space is mapped to the same data space so surly you would just do a data write, how is the programme write possible?

  • 0
    Expert 2355 points

    Someone correct me if i am wrong, but this is why I believe program writes exist:

    Even though the data space and program space is the same memory there still exists two busses to access this memory (legacy of older designs i think).  A program write, as opposed to a data write, is a write involving the program bus rather than the data bus.  You may ask "why not use the data bus".  The answer to this is that program writes are used when the data bus is busy, allowing you to do multiple writes at once.  Program writes are not used that often, most of the time they find their niche in RPT || MAC operations.  If I recall correctly, there are only a few address modes for program writes, mainly involving XAR6 and XAR7.

     

    Tim

  • 0 in reply to Tim King61612
    Prodigy 90 points

    This sounds like what I needed to know. I think the program writes cannot occure at the same time on the L5 ... RAM space but I guess there could be a data write to another memory at the same time as a program write. Does anyone know the exact addressing mode? I would like to find it in the instruction set manual if posible.

    Thanks for the help so far.

  • 0 in reply to Tim King61612
    TI__Guru* 92140 points

    Tim King said:
    Even though the data space and program space is the same memory there still exists two busses to access this memory

    This is correct.

    Tim King said:
    (legacy of older designs i think)

    Actually there is a reason to do this on current devices as well (see below)

    Tim King said:
    The answer to this is that program writes are used when the data bus is busy, allowing you to do multiple writes at once. 

    Sort of - but your next statement clarifies

    Tim King said:
    most of the time they find their niche in RPT || MAC operations.  If I recall correctly, there are only a few address modes for program writes, mainly involving XAR6 and XAR7.

    All of the instructions that use the program data bus are specifically designed to.  PREAD/PWRITE and MAC.  For these instructions you will see one of the operands is grabbed using the XAR7 pointer. 

    As an example RPT || MAC needs two values from memory.  To get the two values it uses  both data bus and the program data bus.  This way the instruction reads one operand from the data side and at the same time it can read the 2nd operand using the program side. 

    Now the RAM blocks on the 28x device are single access (SARAM) so if you put both operands in the same physical memory block there will be a stall for the read even though both data buses are being used.  But if you partition the data such that each operand (as well as the code) is in a different physical block you will not have a stall.  This makes the RPT type MAC instructions single cycle.  

    In the case of memory blocks that have 1-wait in program space you want to avoid having the data accessed by XAR7 in this block else you will see the stall from the wait state.

    Happy coding!

    Lori

     

  • 0 in reply to Lori Heustess
    Prodigy 90 points

    Cool, this is getting into the detail. So one question I have now is am I likly to cause a program read or a program write using "normal" C code as part of some optomization to access DATA or is it it only going to happen with genuine code sections, stuff that normally goes in the text section? (or if I code it in assembler) Its not used by the compiler as a trick to get more performance for data accesses? (Perhaps when I look at the instruction set it will be clearer, I may rummage to find examples in the asm files produced.)

    In other words if I keep text sections out of this memory space the 1 wait state is not going to be an issue, data in these sections will be just as fast. (ignoring all the normal bus contention issues.)

  • 0 in reply to William Bagshaw62337
    Expert 2355 points

    Lori -

    Thanks for the information on needing different sections.  In all my previous coding this just happened naturally (data in one section,  coefficients in another), so I guess I was lucky that it ran at full speed!

    Will -

    I am not sure how likely you are to do a program write / read in C.  As Lori said, scan your disassembly for PWRITE/PREAD and MAC (look in the Instruction Set Guide for its addressing modes - I think it mentions program read/write).  If you are doing RPT || MAC statements you either need to do these in assembler (I recommend this it is more control) or flick a flag in the Linker/Compiler options which says something about allowing repeat commands (I forget which ones) and C will compile these.  Also, a wait state is unlikely to affect program flow too much unless the code is very time critical (such as a RPT || MAC) or in an ISR - so you probably don't need to trawl the entire disassembly.

    In general it is a good idea to keep data in one memory location and program in another.  I recommend using your linker file to its full potential and make multiple sections - they are a really powerful tool.

     

  • 0 in reply to Tim King61612
    Prodigy 90 points

    Ok, so with optimisation full up, opt3 and for speed at gas mark 5, there were no mac instructions. One memcopy was replaced by a rtp and a pwrite (or was it a read). So if this happened on data in a hi L3 I think it would run slower than not using the program bus. Not sure I see any advantage in using the program bus as we can do a fetch, read and write any way. Perhaps it was a register thing. That register was free so it used it. Um? Not sure I under stand why it did that? So I need to lookup the rtp compiler option now. I've always tried to keep code and data separated by the physical boundaries. It looks like code should stay out of high L rams for top speed. Not managed to plan for read and write buffers to be in separate rams, not had the need, so far.