Hi All,
http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
DEMMU - DSP went into virtual addressing space, didn't it?
Rgds,
Andrew
_____________________________________
Integra SoC @ 1500 MHz
Started by ●October 21, 2010
Reply by ●October 23, 20102010-10-23
Hello Andrew,
On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
> Hi All,
>
> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>
> DEMMU - DSP went into virtual addressing space, didn't it?
>
It might depend "on what you mean by virtual addressing space". It
appears that TI has their wires crossed. When I first looked up the
datasheet, [right after your email] the link to SPRUGX9 was broken. Once
it was fixed, the doc [SPRUGX9, 22 October 2010] contained no references
to DEMM.
My guesstimate is that TI has implemented a basic MMU with address
translation [and probably protection fields]. The data sheet indicates
that the 'main purpose in life' for the DEMMU is to translate 'DSP
shared memory addresses to ARM shared memory addresses' [my wording] for
both DSP and EDMA accesses. My personal description of the DEMMU would
be that it performs address translation and protection. I do not think
that it supports virtual memory in the traditional sense where your
program can have a larger memory size than the available memory; if the
fetched memory address is not present, a page fault is generated, data
is fetched from storage, page table[s] is located, and execution
continues. [This would be a difficult task from EDMA]... That's Mike's
take based on the currently available information.
mikedunn
>
> Rgds,
>
> Andrew
On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
> Hi All,
>
> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>
> DEMMU - DSP went into virtual addressing space, didn't it?
>
It might depend "on what you mean by virtual addressing space". It
appears that TI has their wires crossed. When I first looked up the
datasheet, [right after your email] the link to SPRUGX9 was broken. Once
it was fixed, the doc [SPRUGX9, 22 October 2010] contained no references
to DEMM.
My guesstimate is that TI has implemented a basic MMU with address
translation [and probably protection fields]. The data sheet indicates
that the 'main purpose in life' for the DEMMU is to translate 'DSP
shared memory addresses to ARM shared memory addresses' [my wording] for
both DSP and EDMA accesses. My personal description of the DEMMU would
be that it performs address translation and protection. I do not think
that it supports virtual memory in the traditional sense where your
program can have a larger memory size than the available memory; if the
fetched memory address is not present, a page fault is generated, data
is fetched from storage, page table[s] is located, and execution
continues. [This would be a difficult task from EDMA]... That's Mike's
take based on the currently available information.
mikedunn
>
> Rgds,
>
> Andrew
Reply by ●October 23, 20102010-10-23
> Hello Andrew,
>
> On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
>> Hi All,
>>
>> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>>
>> DEMMU - DSP went into virtual addressing space, didn't it?
>>
>
> It might depend "on what you mean by virtual addressing space". It
> appears that TI has their wires crossed. When I first looked up the
> datasheet, [right after your email] the link to SPRUGX9 was broken. Once
> it was fixed, the doc [SPRUGX9, 22 October 2010] contained no references
> to DEMM.
>
> My guesstimate is that TI has implemented a basic MMU with address
> translation [and probably protection fields]. The data sheet indicates
> that the 'main purpose in life' for the DEMMU is to translate 'DSP
> shared memory addresses to ARM shared memory addresses' [my wording] for
> both DSP and EDMA accesses. My personal description of the DEMMU would
> be that it performs address translation and protection. I do not think
> that it supports virtual memory in the traditional sense where your
> program can have a larger memory size than the available memory; if the
> fetched memory address is not present, a page fault is generated, data
> is fetched from storage, page table[s] is located, and execution
> continues. [This would be a difficult task from EDMA]... That's Mike's
> take based on the currently available information.
I would agree with this. In general, TI architects seem to be struggling to catch up with what's needed to fully
support native Linux running on C64x+ cores. At least two significant weaknesses appear to be hyperthreading (i.e.
improved multicore support) and virtual memory support. My understanding is they have made improvements in the
upcoming C66x devices (some preliminary info here: http://focus.ti.com/lit/wp/spry138/spry138.pdf).
But, good news is, they do appear to be moving faster. I don't know for sure what caused the 10-year log-jam on Linux
inside TI, but in the last 2 years it appears to be breaking up and they are getting with it.
-Jeff
_____________________________________
>
> On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
>> Hi All,
>>
>> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>>
>> DEMMU - DSP went into virtual addressing space, didn't it?
>>
>
> It might depend "on what you mean by virtual addressing space". It
> appears that TI has their wires crossed. When I first looked up the
> datasheet, [right after your email] the link to SPRUGX9 was broken. Once
> it was fixed, the doc [SPRUGX9, 22 October 2010] contained no references
> to DEMM.
>
> My guesstimate is that TI has implemented a basic MMU with address
> translation [and probably protection fields]. The data sheet indicates
> that the 'main purpose in life' for the DEMMU is to translate 'DSP
> shared memory addresses to ARM shared memory addresses' [my wording] for
> both DSP and EDMA accesses. My personal description of the DEMMU would
> be that it performs address translation and protection. I do not think
> that it supports virtual memory in the traditional sense where your
> program can have a larger memory size than the available memory; if the
> fetched memory address is not present, a page fault is generated, data
> is fetched from storage, page table[s] is located, and execution
> continues. [This would be a difficult task from EDMA]... That's Mike's
> take based on the currently available information.
I would agree with this. In general, TI architects seem to be struggling to catch up with what's needed to fully
support native Linux running on C64x+ cores. At least two significant weaknesses appear to be hyperthreading (i.e.
improved multicore support) and virtual memory support. My understanding is they have made improvements in the
upcoming C66x devices (some preliminary info here: http://focus.ti.com/lit/wp/spry138/spry138.pdf).
But, good news is, they do appear to be moving faster. I don't know for sure what caused the 10-year log-jam on Linux
inside TI, but in the last 2 years it appears to be breaking up and they are getting with it.
-Jeff
_____________________________________
Reply by ●October 25, 20102010-10-25
Andrew,
On 10/25/2010 3:27 PM, Andrew Nesterov wrote:
>> Date: Fri, 22 Oct 2010 23:37:58 -0500
>> From: mikedunn
>> Subject: Re: [c6x] Integra SoC @ 1500 MHz
>>
>> Hello Andrew,
>>
>> On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
>>>
>>>
>>> Hi All,
>>>
>>> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>>>
>>> DEMMU - DSP went into virtual addressing space, didn't it?
>>>
>>
>> It might depend "on what you mean by virtual addressing space". It
>> appears that TI has their wires crossed. When I first looked up the
>> datasheet, [right after your email] the link to SPRUGX9 was broken.
>> Once it was fixed, the doc [SPRUGX9, 22 October 2010] contained no
>> references to DEMM.
>>
>> My guesstimate is that TI has implemented a basic MMU with address
>> translation [and probably protection fields]. The data sheet
>> indicates that the 'main purpose in life' for the DEMMU is to
>> translate 'DSP shared memory addresses to ARM shared memory
>> addresses' [my wording] for both DSP and EDMA accesses. My personal
>> description of the DEMMU would be that it performs address
>> translation and protection. I do not think that it supports virtual
>> memory in the traditional sense where your program can have a larger
>> memory size than the available memory; if the fetched memory address
>> is not present, a page fault is generated, data is fetched from
>> storage, page table[s] is located, and execution continues. [This
>> would be a difficult task from EDMA]... That's Mike's take based on
>> the currently available information.
>>
>> mikedunn
>> Hi Mike,
>
> Thanks for pointing me to the TRM. At the time I got the D/S, the link
> was
> broken, just like you said. I looked at the doc - indeed there no section
> on the DEMMU as well as on the video port (HDVPSS). So it's difficult to
> say anything definite on the DEMMU functioning. Hopefully, more up to
> date
> doc would contain these sections (I'd like to look at the GSX350 too)...
I was hoping that the TRM link would do it, but it seems that the TRM
[inspite of its recent date] is an older one with a bit of 'lipstick' on
it. I've alerted the tech pubs folks about the problem, but since we are
talking missing chapters its likely that they are awaiting source
material. I've also posted the question to TI's Community board [or
whatever it is called] to see what they have to say.
>
> (It might be possible that the DEMMU from the datasheet is DMM/TILER
> device
> from the TRM)
Assuming the the brief mention in the datasheet is correct, I am pretty
sure that it is not a 'renamed DMM'. The DMM is close to the physical
memory interface and available to all processors where the DEMMU is
between the DSP and the memory subsystem. This would seem to indicate
that DSP memory activity could involve something like
DSP-->DEMMU-->DMM/TILER-->Memory... I think my head is starting to
hurt.... :-)
mikedunn
>
> Rgds,
>
> Andrew
_____________________________________
On 10/25/2010 3:27 PM, Andrew Nesterov wrote:
>> Date: Fri, 22 Oct 2010 23:37:58 -0500
>> From: mikedunn
>> Subject: Re: [c6x] Integra SoC @ 1500 MHz
>>
>> Hello Andrew,
>>
>> On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
>>>
>>>
>>> Hi All,
>>>
>>> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>>>
>>> DEMMU - DSP went into virtual addressing space, didn't it?
>>>
>>
>> It might depend "on what you mean by virtual addressing space". It
>> appears that TI has their wires crossed. When I first looked up the
>> datasheet, [right after your email] the link to SPRUGX9 was broken.
>> Once it was fixed, the doc [SPRUGX9, 22 October 2010] contained no
>> references to DEMM.
>>
>> My guesstimate is that TI has implemented a basic MMU with address
>> translation [and probably protection fields]. The data sheet
>> indicates that the 'main purpose in life' for the DEMMU is to
>> translate 'DSP shared memory addresses to ARM shared memory
>> addresses' [my wording] for both DSP and EDMA accesses. My personal
>> description of the DEMMU would be that it performs address
>> translation and protection. I do not think that it supports virtual
>> memory in the traditional sense where your program can have a larger
>> memory size than the available memory; if the fetched memory address
>> is not present, a page fault is generated, data is fetched from
>> storage, page table[s] is located, and execution continues. [This
>> would be a difficult task from EDMA]... That's Mike's take based on
>> the currently available information.
>>
>> mikedunn
>> Hi Mike,
>
> Thanks for pointing me to the TRM. At the time I got the D/S, the link
> was
> broken, just like you said. I looked at the doc - indeed there no section
> on the DEMMU as well as on the video port (HDVPSS). So it's difficult to
> say anything definite on the DEMMU functioning. Hopefully, more up to
> date
> doc would contain these sections (I'd like to look at the GSX350 too)...
I was hoping that the TRM link would do it, but it seems that the TRM
[inspite of its recent date] is an older one with a bit of 'lipstick' on
it. I've alerted the tech pubs folks about the problem, but since we are
talking missing chapters its likely that they are awaiting source
material. I've also posted the question to TI's Community board [or
whatever it is called] to see what they have to say.
>
> (It might be possible that the DEMMU from the datasheet is DMM/TILER
> device
> from the TRM)
Assuming the the brief mention in the datasheet is correct, I am pretty
sure that it is not a 'renamed DMM'. The DMM is close to the physical
memory interface and available to all processors where the DEMMU is
between the DSP and the memory subsystem. This would seem to indicate
that DSP memory activity could involve something like
DSP-->DEMMU-->DMM/TILER-->Memory... I think my head is starting to
hurt.... :-)
mikedunn
>
> Rgds,
>
> Andrew
_____________________________________
Reply by ●October 25, 20102010-10-25
> Date: Fri, 22 Oct 2010 23:37:58 -0500
> From: mikedunn
> Subject: Re: [c6x] Integra SoC @ 1500 MHz
>
> Hello Andrew,
>
> On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
>> Hi All,
>>
>> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>>
>> DEMMU - DSP went into virtual addressing space, didn't it?
>>
>
> It might depend "on what you mean by virtual addressing space". It appears
> that TI has their wires crossed. When I first looked up the datasheet, [right
> after your email] the link to SPRUGX9 was broken. Once it was fixed, the doc
> [SPRUGX9, 22 October 2010] contained no references to DEMM.
>
> My guesstimate is that TI has implemented a basic MMU with address
> translation [and probably protection fields]. The data sheet indicates that
> the 'main purpose in life' for the DEMMU is to translate 'DSP shared memory
> addresses to ARM shared memory addresses' [my wording] for both DSP and EDMA
> accesses. My personal description of the DEMMU would be that it performs
> address translation and protection. I do not think that it supports virtual
> memory in the traditional sense where your program can have a larger memory
> size than the available memory; if the fetched memory address is not present,
> a page fault is generated, data is fetched from storage, page table[s] is
> located, and execution continues. [This would be a difficult task from
> EDMA]... That's Mike's take based on the currently available information.
>
> mikedunn
>
Hi Mike,
Thanks for pointing me to the TRM. At the time I got the D/S, the link was
broken, just like you said. I looked at the doc - indeed there no section
on the DEMMU as well as on the video port (HDVPSS). So it's difficult to
say anything definite on the DEMMU functioning. Hopefully, more up to date
doc would contain these sections (I'd like to look at the GSX350 too)...
(It might be possible that the DEMMU from the datasheet is DMM/TILER device
from the TRM)
Rgds,
Andrew
_____________________________________
> From: mikedunn
> Subject: Re: [c6x] Integra SoC @ 1500 MHz
>
> Hello Andrew,
>
> On 10/21/2010 12:43 PM, Andrew Nesterov wrote:
>> Hi All,
>>
>> http://focus.ti.com/docs/prod/folders/print/tms320c6a8168.html
>>
>> DEMMU - DSP went into virtual addressing space, didn't it?
>>
>
> It might depend "on what you mean by virtual addressing space". It appears
> that TI has their wires crossed. When I first looked up the datasheet, [right
> after your email] the link to SPRUGX9 was broken. Once it was fixed, the doc
> [SPRUGX9, 22 October 2010] contained no references to DEMM.
>
> My guesstimate is that TI has implemented a basic MMU with address
> translation [and probably protection fields]. The data sheet indicates that
> the 'main purpose in life' for the DEMMU is to translate 'DSP shared memory
> addresses to ARM shared memory addresses' [my wording] for both DSP and EDMA
> accesses. My personal description of the DEMMU would be that it performs
> address translation and protection. I do not think that it supports virtual
> memory in the traditional sense where your program can have a larger memory
> size than the available memory; if the fetched memory address is not present,
> a page fault is generated, data is fetched from storage, page table[s] is
> located, and execution continues. [This would be a difficult task from
> EDMA]... That's Mike's take based on the currently available information.
>
> mikedunn
>
Hi Mike,
Thanks for pointing me to the TRM. At the time I got the D/S, the link was
broken, just like you said. I looked at the doc - indeed there no section
on the DEMMU as well as on the video port (HDVPSS). So it's difficult to
say anything definite on the DEMMU functioning. Hopefully, more up to date
doc would contain these sections (I'd like to look at the GSX350 too)...
(It might be possible that the DEMMU from the datasheet is DMM/TILER device
from the TRM)
Rgds,
Andrew
_____________________________________
