|
We are using a C6711 on a custom board. We have an FPGA on one of the chip-enables. This FPGA receives data from various sensors, and the C6711 periodically reads this data from the FPGA. We seem to be having problems with the L1 cache when doing these reads. We are configured with no L2 cache, but SPRU190C page 4-9 says that the L1D (data cache) does not support freeze or bypass modes. Using a logic analyzer on the external address and data buss has shown clearly that one read from the FPGA appears on the bus, but that a following read does not, which strongly implicates the cache. Apparently I can use a bit in the CCFG to invalidate the current contents of the cache, but it would immediately start filling again. It seems as if I would have to invalidate it before every read from the FPGA in order to be sure the data I get is up-to-date. Does anyone know if there is a better way to get around the interference of the L1 cache? If not, how long does the invalidate take? It seems like a very bad design choice to make a cache you can't disable, especially for a processor used in embedded systems where it's common for data to change all the time. Thanks, Dan Eyer Mayflower Communications |
|
|
C6711 L1 cache problems
Started by ●September 16, 2002
Reply by ●September 16, 20022002-09-16
|
If you use EDMA to periodically read the external FPGA registers to internal SRAM then you shouldn't have any trouble. If you need to do bitbashing, be sure to disable the MARx caching. We have a 6711 with FPGA registers that we use for bitbashing and it seems to work fine. Andrew E. At 02:52 PM 9/16/2002 +0000, dan_eyer wrote: >We are using a C6711 on a custom board. We >have an FPGA on one of the chip-enables. This >FPGA receives data from various sensors, and >the C6711 periodically reads this data from >the FPGA. > >We seem to be having problems with the L1 cache >when doing these reads. We are configured with >no L2 cache, but SPRU190C page 4-9 says that >the L1D (data cache) does not support freeze or >bypass modes. Using a logic analyzer on the >external address and data buss has shown >clearly that one read from the FPGA appears on >the bus, but that a following read does not, >which strongly implicates the cache. > >Apparently I can use a bit in the CCFG to >invalidate the current contents of the cache, >but it would immediately start filling again. >It seems as if I would have to invalidate it >before every read from the FPGA in order to >be sure the data I get is up-to-date. > >Does anyone know if there is a better way to >get around the interference of the L1 cache? >If not, how long does the invalidate take? > >It seems like a very bad design choice to >make a cache you can't disable, especially >for a processor used in embedded systems >where it's common for data to change all >the time. > >Thanks, >Dan Eyer >Mayflower Communications > > >_____________________________________ >Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > >_____________________________________ >About this discussion group: > >To Join: Send an email to > >To Post: Send an email to > >To Leave: Send an email to > >Archives: http://www.yahoogroups.com/group/c6x > >Other Groups: http://www.dsprelated.com >">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●September 16, 20022002-09-16
|
--- In c6x@y..., Andrew Elder <andrew_elder@b...> wrote: > > If you use EDMA to periodically read the external FPGA registers to internal SRAM then you shouldn't have any trouble. > We aren't using the EDMA to read the FPGA registers, just regular reads using addresses, like this: ii = *((int*)0x80221000); The data which the FPGA makes available at this address changes all the time without the DSP doing anything, so we read from this address over and over. Using the logic analyzer on the external bus, we can tell that some of the reads never make it out to the bus. > If you need to do bitbashing, be sure to disable the MARx caching. We have a 6711 with FPGA registers that we use for bitbashing and it seems to work fine. > > Andrew E. > I'm not quite sure what you mean by "bitbashing", but as I understand it the MARs only affect L2 caching, which we don't have. I'm having trouble with the L1 caching. We only noticed the problem when we tried to do a lot of reads from the same address in quick succession, probably because the L1 cache is only 4K bytes. If we do a lot of unrelated external accesses between each read from the FPGA, the problem goes away, probably because the FPGA address was thrown out of the cache by the other accesses. But we need to access it more reliably than that. > At 02:52 PM 9/16/2002 +0000, dan_eyer wrote: > > >We are using a C6711 on a custom board. We > >have an FPGA on one of the chip-enables. This > >FPGA receives data from various sensors, and > >the C6711 periodically reads this data from > >the FPGA. > > > >We seem to be having problems with the L1 cache > >when doing these reads. We are configured with > >no L2 cache, but SPRU190C page 4-9 says that > >the L1D (data cache) does not support freeze or > >bypass modes. Using a logic analyzer on the > >external address and data buss has shown > >clearly that one read from the FPGA appears on > >the bus, but that a following read does not, > >which strongly implicates the cache. > > > >Apparently I can use a bit in the CCFG to > >invalidate the current contents of the cache, > >but it would immediately start filling again. > >It seems as if I would have to invalidate it > >before every read from the FPGA in order to > >be sure the data I get is up-to-date. > > > >Does anyone know if there is a better way to > >get around the interference of the L1 cache? > >If not, how long does the invalidate take? > > > >It seems like a very bad design choice to > >make a cache you can't disable, especially > >for a processor used in embedded systems > >where it's common for data to change all > >the time. > > > >Thanks, > >Dan Eyer > >Mayflower Communications > > > > > > > > > >_____________________________________ > >Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > > >_____________________________________ > >About this discussion group: > > > >To Join: Send an email to c6x-subscribe@y... > > > >To Post: Send an email to c6x@y... > > > >To Leave: Send an email to c6x-unsubscribe@y... > > > >Archives: http://www.yahoogroups.com/group/c6x > > > >Other Groups: http://www.dsprelated.com > > > > > >">http://docs.yahoo.com/info/terms/ |
Reply by ●September 17, 20022002-09-17
|
Dan Have you tried > ii = *((volatile int*)0x80221000); -steve ----- Original Message ----- From: "dan_eyer" <> To: <> Sent: Monday, September 16, 2002 12:28 PM Subject: [c6x] Re: C6711 L1 cache problems > --- In c6x@y..., Andrew Elder <andrew_elder@b...> wrote: > > > > If you use EDMA to periodically read the external FPGA registers to > internal SRAM then you shouldn't have any trouble. > > > > We aren't using the EDMA to read the FPGA registers, > just regular reads using addresses, like this: > > ii = *((int*)0x80221000); > > The data which the FPGA makes available at this > address changes all the time without the DSP doing > anything, so we read from this address over and > over. Using the logic analyzer on the external > bus, we can tell that some of the reads never > make it out to the bus. > > If you need to do bitbashing, be sure to disable the MARx caching. > We have a 6711 with FPGA registers that we use for bitbashing and it > seems to work fine. > > > > Andrew E. > > > > I'm not quite sure what you mean by "bitbashing", > but as I understand it the MARs only affect L2 > caching, which we don't have. I'm having trouble > with the L1 caching. We only noticed the problem > when we tried to do a lot of reads from the same > address in quick succession, probably because the > L1 cache is only 4K bytes. If we do a lot of > unrelated external accesses between each read from > the FPGA, the problem goes away, probably because > the FPGA address was thrown out of the cache by > the other accesses. But we need to access it > more reliably than that. > > At 02:52 PM 9/16/2002 +0000, dan_eyer wrote: > > > > >We are using a C6711 on a custom board. We > > >have an FPGA on one of the chip-enables. This > > >FPGA receives data from various sensors, and > > >the C6711 periodically reads this data from > > >the FPGA. > > > > > >We seem to be having problems with the L1 cache > > >when doing these reads. We are configured with > > >no L2 cache, but SPRU190C page 4-9 says that > > >the L1D (data cache) does not support freeze or > > >bypass modes. Using a logic analyzer on the > > >external address and data buss has shown > > >clearly that one read from the FPGA appears on > > >the bus, but that a following read does not, > > >which strongly implicates the cache. > > > > > >Apparently I can use a bit in the CCFG to > > >invalidate the current contents of the cache, > > >but it would immediately start filling again. > > >It seems as if I would have to invalidate it > > >before every read from the FPGA in order to > > >be sure the data I get is up-to-date. > > > > > >Does anyone know if there is a better way to > > >get around the interference of the L1 cache? > > >If not, how long does the invalidate take? > > > > > >It seems like a very bad design choice to > > >make a cache you can't disable, especially > > >for a processor used in embedded systems > > >where it's common for data to change all > > >the time. > > > > > >Thanks, > > >Dan Eyer > > >Mayflower Communications > > > > > > > > > > > > > > >_____________________________________ > > >Note: If you do a simple "reply" with your email client, only the > author of this message will receive your answer. You need to do a > "reply all" if you want your answer to be distributed to the entire > group. > > > > > >_____________________________________ > > >About this discussion group: > > > > > >To Join: Send an email to c6x-subscribe@y... > > > > > >To Post: Send an email to c6x@y... > > > > > >To Leave: Send an email to c6x-unsubscribe@y... > > > > > >Archives: http://www.yahoogroups.com/group/c6x > > > > > >Other Groups: http://www.dsprelated.com > > > > > > > > >">http://docs.yahoo.com/info/terms/ > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > > To Post: Send an email to > > To Leave: Send an email to > > Archives: http://www.yahoogroups.com/group/c6x > > Other Groups: http://www.dsprelated.com > ">http://docs.yahoo.com/info/terms/ > |
|
|
Reply by ●September 17, 20022002-09-17
|
Yep, one of the first things we tried. No change. The reads are definitely in the compiled code, which is what "volatile" mainly affects. I see the code for the reads when I view the mixed source/asm, and I also saw the code in the instruction fetches that go out to the external RAM. But I don't see the 2nd read actually be executed over the external bus, even though it gets a value back. The value is wrong, because it's the same value the 1st read got. Thanks anyway, though. Dan --- In c6x@y..., "Stephen - Office" <sgturner@a...> wrote: > Dan > > Have you tried > > > ii = *((volatile int*)0x80221000); > > -steve > > ----- Original Message ----- > From: "dan_eyer" <dan_eyer@y...> > To: <c6x@y...> > Sent: Monday, September 16, 2002 12:28 PM > Subject: [c6x] Re: C6711 L1 cache problems > > --- In c6x@y..., Andrew Elder <andrew_elder@b...> wrote: > > > > > > If you use EDMA to periodically read the external FPGA registers to > > internal SRAM then you shouldn't have any trouble. > > > > > > > We aren't using the EDMA to read the FPGA registers, > > just regular reads using addresses, like this: > > > > ii = *((int*)0x80221000); > > > > The data which the FPGA makes available at this > > address changes all the time without the DSP doing > > anything, so we read from this address over and > > over. Using the logic analyzer on the external > > bus, we can tell that some of the reads never > > make it out to the bus. > > > > > > > If you need to do bitbashing, be sure to disable the MARx caching. > > We have a 6711 with FPGA registers that we use for bitbashing and it > > seems to work fine. > > > > > > Andrew E. > > > > > > > I'm not quite sure what you mean by "bitbashing", > > but as I understand it the MARs only affect L2 > > caching, which we don't have. I'm having trouble > > with the L1 caching. We only noticed the problem > > when we tried to do a lot of reads from the same > > address in quick succession, probably because the > > L1 cache is only 4K bytes. If we do a lot of > > unrelated external accesses between each read from > > the FPGA, the problem goes away, probably because > > the FPGA address was thrown out of the cache by > > the other accesses. But we need to access it > > more reliably than that. > > > > > > > At 02:52 PM 9/16/2002 +0000, dan_eyer wrote: > > > > > > >We are using a C6711 on a custom board. We > > > >have an FPGA on one of the chip-enables. This > > > >FPGA receives data from various sensors, and > > > >the C6711 periodically reads this data from > > > >the FPGA. > > > > > > > >We seem to be having problems with the L1 cache > > > >when doing these reads. We are configured with > > > >no L2 cache, but SPRU190C page 4-9 says that > > > >the L1D (data cache) does not support freeze or > > > >bypass modes. Using a logic analyzer on the > > > >external address and data buss has shown > > > >clearly that one read from the FPGA appears on > > > >the bus, but that a following read does not, > > > >which strongly implicates the cache. > > > > > > > >Apparently I can use a bit in the CCFG to > > > >invalidate the current contents of the cache, > > > >but it would immediately start filling again. > > > >It seems as if I would have to invalidate it > > > >before every read from the FPGA in order to > > > >be sure the data I get is up-to-date. > > > > > > > >Does anyone know if there is a better way to > > > >get around the interference of the L1 cache? > > > >If not, how long does the invalidate take? > > > > > > > >It seems like a very bad design choice to > > > >make a cache you can't disable, especially > > > >for a processor used in embedded systems > > > >where it's common for data to change all > > > >the time. > > > > > > > >Thanks, > > > >Dan Eyer > > > >Mayflower Communications > > > > > > > > > > > > > > > > > > > >_____________________________________ > > > >Note: If you do a simple "reply" with your email client, only the > > author of this message will receive your answer. You need to do a > > "reply all" if you want your answer to be distributed to the entire > > group. > > > > > > > >_____________________________________ > > > >About this discussion group: > > > > > > > >To Join: Send an email to c6x-subscribe@y... > > > > > > > >To Post: Send an email to c6x@y... > > > > > > > >To Leave: Send an email to c6x-unsubscribe@y... > > > > > > > >Archives: http://www.yahoogroups.com/group/c6x > > > > > > > >Other Groups: http://www.dsprelated.com > > > > > > > > > > > >">http://docs.yahoo.com/info/terms/ > > > > > > > > _____________________________________ > > Note: If you do a simple "reply" with your email client, only the author > of this message will receive your answer. You need to do a "reply all" if > you want your answer to be distributed to the entire group. > > > > _____________________________________ > > About this discussion group: > > > > To Join: Send an email to c6x-subscribe@y... > > > > To Post: Send an email to c6x@y... > > > > To Leave: Send an email to c6x-unsubscribe@y... > > > > Archives: http://www.yahoogroups.com/group/c6x > > > > Other Groups: http://www.dsprelated.com > > > > > > ">http://docs.yahoo.com/info/terms/ > > |
|
|
Reply by ●September 17, 20022002-09-17
|
Have you looked at SPRU609 section 6.2 ? I think you should try setting the MAR_ register to 0. Andrew E. At 02:16 PM 9/17/2002 +0000, dan_eyer wrote: >Yep, one of the first things we tried. No >change. The reads are definitely in the >compiled code, which is what "volatile" >mainly affects. I see the code for the >reads when I view the mixed source/asm, >and I also saw the code in the instruction >fetches that go out to the external RAM. >But I don't see the 2nd read actually be >executed over the external bus, even though >it gets a value back. The value is wrong, >because it's the same value the 1st read >got. > >Thanks anyway, though. >Dan >--- In c6x@y..., "Stephen - Office" <sgturner@a...> wrote: >> Dan >> >> Have you tried >> >> > ii = *((volatile int*)0x80221000); >> >> -steve >> >> ----- Original Message ----- >> From: "dan_eyer" <dan_eyer@y...> >> To: <c6x@y...> >> Sent: Monday, September 16, 2002 12:28 PM >> Subject: [c6x] Re: C6711 L1 cache problems >> >> >> > --- In c6x@y..., Andrew Elder <andrew_elder@b...> wrote: >> > > >> > > If you use EDMA to periodically read the external FPGA registers >to >> > internal SRAM then you shouldn't have any trouble. >> > > >> > >> > We aren't using the EDMA to read the FPGA registers, >> > just regular reads using addresses, like this: >> > >> > ii = *((int*)0x80221000); >> > >> > The data which the FPGA makes available at this >> > address changes all the time without the DSP doing >> > anything, so we read from this address over and >> > over. Using the logic analyzer on the external >> > bus, we can tell that some of the reads never >> > make it out to the bus. >> > >> > >> > > If you need to do bitbashing, be sure to disable the MARx >caching. >> > We have a 6711 with FPGA registers that we use for bitbashing and >it >> > seems to work fine. >> > > >> > > Andrew E. >> > > >> > >> > I'm not quite sure what you mean by "bitbashing", >> > but as I understand it the MARs only affect L2 >> > caching, which we don't have. I'm having trouble >> > with the L1 caching. We only noticed the problem >> > when we tried to do a lot of reads from the same >> > address in quick succession, probably because the >> > L1 cache is only 4K bytes. If we do a lot of >> > unrelated external accesses between each read from >> > the FPGA, the problem goes away, probably because >> > the FPGA address was thrown out of the cache by >> > the other accesses. But we need to access it >> > more reliably than that. >> > >> > >> > > At 02:52 PM 9/16/2002 +0000, dan_eyer wrote: >> > > >> > > >We are using a C6711 on a custom board. We >> > > >have an FPGA on one of the chip-enables. This >> > > >FPGA receives data from various sensors, and >> > > >the C6711 periodically reads this data from >> > > >the FPGA. >> > > > >> > > >We seem to be having problems with the L1 cache >> > > >when doing these reads. We are configured with >> > > >no L2 cache, but SPRU190C page 4-9 says that >> > > >the L1D (data cache) does not support freeze or >> > > >bypass modes. Using a logic analyzer on the >> > > >external address and data buss has shown >> > > >clearly that one read from the FPGA appears on >> > > >the bus, but that a following read does not, >> > > >which strongly implicates the cache. >> > > > >> > > >Apparently I can use a bit in the CCFG to >> > > >invalidate the current contents of the cache, >> > > >but it would immediately start filling again. >> > > >It seems as if I would have to invalidate it >> > > >before every read from the FPGA in order to >> > > >be sure the data I get is up-to-date. >> > > > >> > > >Does anyone know if there is a better way to >> > > >get around the interference of the L1 cache? >> > > >If not, how long does the invalidate take? >> > > > >> > > >It seems like a very bad design choice to >> > > >make a cache you can't disable, especially >> > > >for a processor used in embedded systems >> > > >where it's common for data to change all >> > > >the time. >> > > > >> > > >Thanks, >> > > >Dan Eyer >> > > >Mayflower Communications >> > > > >> > > > >> > > > >> > > > >> > > >_____________________________________ >> > > >Note: If you do a simple "reply" with your email client, only >the >> > author of this message will receive your answer. You need to do a >> > "reply all" if you want your answer to be distributed to the >entire >> > group. >> > > > >> > > >_____________________________________ >> > > >About this discussion group: >> > > > >> > > >To Join: Send an email to c6x-subscribe@y... >> > > > >> > > >To Post: Send an email to c6x@y... >> > > > >> > > >To Leave: Send an email to c6x-unsubscribe@y... >> > > > >> > > >Archives: http://www.yahoogroups.com/group/c6x >> > > > >> > > >Other Groups: http://www.dsprelated.com >> > > > >> > > > >> > > >">http://docs.yahoo.com/info/terms/ >> > >> > >> > >> > _____________________________________ >> > Note: If you do a simple "reply" with your email client, only the >author >> of this message will receive your answer. You need to do a "reply >all" if >> you want your answer to be distributed to the entire group. >> > >> > _____________________________________ >> > About this discussion group: >> > >> > To Join: Send an email to c6x-subscribe@y... >> > >> > To Post: Send an email to c6x@y... >> > >> > To Leave: Send an email to c6x-unsubscribe@y... >> > >> > Archives: http://www.yahoogroups.com/group/c6x >> > >> > Other Groups: http://www.dsprelated.com >> > >> > >> > ">http://docs.yahoo.com/info/terms/ >> > >_____________________________________ >Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > >_____________________________________ >About this discussion group: > >To Join: Send an email to > >To Post: Send an email to > >To Leave: Send an email to > >Archives: http://www.yahoogroups.com/group/c6x > >Other Groups: http://www.dsprelated.com >">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●September 17, 20022002-09-17
|
I am not clear what you mean by "I don't see the 2nd read actually
be executed". Are you saying you don't see the instruction fetch? Or you're saying you don't see the bus handshake for the second read? In either case, how can you see it get "a value back"? OH, you mean the code thinks it got a value back.... Sounds like a chip bug to me! At 10:16 AM 9/17/02, dan_eyer wrote: >Yep, one of the first things we tried. No >change. The reads are definitely in the >compiled code, which is what "volatile" >mainly affects. I see the code for the >reads when I view the mixed source/asm, >and I also saw the code in the instruction >fetches that go out to the external RAM. >But I don't see the 2nd read actually be >executed over the external bus, even though >it gets a value back. The value is wrong, >because it's the same value the 1st read >got. > >Thanks anyway, though. >Dan Rick Collins Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX |
|
|
Reply by ●September 17, 20022002-09-17
|
Thanks for mentioning this document! I was not previously aware of it. Unlike SPRU190C, which implied that the MARs only controlled the L2 cache, SPRU609 says explicitely that they control all cacheing. I'd also like to apologize to everyone who suggested setting the MAR and who I thought was mistaken. Even though I thought I had checked the MARs before, and even though the manuals say that they default to 0 (disabled), when I went back and checked the running code MAR0 was enabled. As soon as I turned it off our problems went away. Thank you all very much for your help! Dan Eyer --- In c6x@y..., Andrew Elder <andrew_elder@b...> wrote: > > Have you looked at SPRU609 section 6.2 ? > I think you should try setting the MAR_ register to 0. > > Andrew E. > > At 02:16 PM 9/17/2002 +0000, dan_eyer wrote: > > >Yep, one of the first things we tried. No > >change. The reads are definitely in the > >compiled code, which is what "volatile" > >mainly affects. I see the code for the > >reads when I view the mixed source/asm, > >and I also saw the code in the instruction > >fetches that go out to the external RAM. > >But I don't see the 2nd read actually be > >executed over the external bus, even though > >it gets a value back. The value is wrong, > >because it's the same value the 1st read > >got. > > > >Thanks anyway, though. > >Dan > > > > > >--- In c6x@y..., "Stephen - Office" <sgturner@a...> wrote: > >> Dan > >> > >> Have you tried > >> > >> > ii = *((volatile int*)0x80221000); > >> > >> -steve > >> > >> ----- Original Message ----- > >> From: "dan_eyer" <dan_eyer@y...> > >> To: <c6x@y...> > >> Sent: Monday, September 16, 2002 12:28 PM > >> Subject: [c6x] Re: C6711 L1 cache problems > >> > >> > >> > --- In c6x@y..., Andrew Elder <andrew_elder@b...> wrote: > >> > > > >> > > If you use EDMA to periodically read the external FPGA registers > >to > >> > internal SRAM then you shouldn't have any trouble. > >> > > > >> > > >> > We aren't using the EDMA to read the FPGA registers, > >> > just regular reads using addresses, like this: > >> > > >> > ii = *((int*)0x80221000); > >> > > >> > The data which the FPGA makes available at this > >> > address changes all the time without the DSP doing > >> > anything, so we read from this address over and > >> > over. Using the logic analyzer on the external > >> > bus, we can tell that some of the reads never > >> > make it out to the bus. > >> > > >> > > >> > > If you need to do bitbashing, be sure to disable the MARx > >caching. > >> > We have a 6711 with FPGA registers that we use for bitbashing and > >it > >> > seems to work fine. > >> > > > >> > > Andrew E. > >> > > > >> > > >> > I'm not quite sure what you mean by "bitbashing", > >> > but as I understand it the MARs only affect L2 > >> > caching, which we don't have. I'm having trouble > >> > with the L1 caching. We only noticed the problem > >> > when we tried to do a lot of reads from the same > >> > address in quick succession, probably because the > >> > L1 cache is only 4K bytes. If we do a lot of > >> > unrelated external accesses between each read from > >> > the FPGA, the problem goes away, probably because > >> > the FPGA address was thrown out of the cache by > >> > the other accesses. But we need to access it > >> > more reliably than that. > >> > > >> > > >> > > At 02:52 PM 9/16/2002 +0000, dan_eyer wrote: > >> > > > >> > > >We are using a C6711 on a custom board. We > >> > > >have an FPGA on one of the chip-enables. This > >> > > >FPGA receives data from various sensors, and > >> > > >the C6711 periodically reads this data from > >> > > >the FPGA. > >> > > > > >> > > >We seem to be having problems with the L1 cache > >> > > >when doing these reads. We are configured with > >> > > >no L2 cache, but SPRU190C page 4-9 says that > >> > > >the L1D (data cache) does not support freeze or > >> > > >bypass modes. Using a logic analyzer on the > >> > > >external address and data buss has shown > >> > > >clearly that one read from the FPGA appears on > >> > > >the bus, but that a following read does not, > >> > > >which strongly implicates the cache. > >> > > > > >> > > >Apparently I can use a bit in the CCFG to > >> > > >invalidate the current contents of the cache, > >> > > >but it would immediately start filling again. > >> > > >It seems as if I would have to invalidate it > >> > > >before every read from the FPGA in order to > >> > > >be sure the data I get is up-to-date. > >> > > > > >> > > >Does anyone know if there is a better way to > >> > > >get around the interference of the L1 cache? > >> > > >If not, how long does the invalidate take? > >> > > > > >> > > >It seems like a very bad design choice to > >> > > >make a cache you can't disable, especially > >> > > >for a processor used in embedded systems > >> > > >where it's common for data to change all > >> > > >the time. > >> > > > > >> > > >Thanks, > >> > > >Dan Eyer > >> > > >Mayflower Communications > >> > > > > >> > > > > >> > > > > >> > > > > >> > > >_____________________________________ > >> > > >Note: If you do a simple "reply" with your email client, only > >the > >> > author of this message will receive your answer. You need to do a > >> > "reply all" if you want your answer to be distributed to the > >entire > >> > group. > >> > > > > >> > > >_____________________________________ > >> > > >About this discussion group: > >> > > > > >> > > >To Join: Send an email to c6x-subscribe@y... > >> > > > > >> > > >To Post: Send an email to c6x@y... > >> > > > > >> > > >To Leave: Send an email to c6x-unsubscribe@y... > >> > > > > >> > > >Archives: http://www.yahoogroups.com/group/c6x > >> > > > > >> > > >Other Groups: http://www.dsprelated.com > >> > > > > >> > > > > >> > > >">http://docs.yahoo.com/info/terms/ > >> > > >> > > >> > > >> > _____________________________________ > >> > Note: If you do a simple "reply" with your email client, only the > >author > >> of this message will receive your answer. You need to do a "reply > >all" if > >> you want your answer to be distributed to the entire group. > >> > > >> > _____________________________________ > >> > About this discussion group: > >> > > >> > To Join: Send an email to c6x-subscribe@y... > >> > > >> > To Post: Send an email to c6x@y... > >> > > >> > To Leave: Send an email to c6x-unsubscribe@y... > >> > > >> > Archives: http://www.yahoogroups.com/group/c6x > >> > > >> > Other Groups: http://www.dsprelated.com > >> > > >> > > >> > ">http://docs.yahoo.com/info/terms/ > >> > > > > > > > > >_____________________________________ > >Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > > >_____________________________________ > >About this discussion group: > > > >To Join: Send an email to c6x-subscribe@y... > > > >To Post: Send an email to c6x@y... > > > >To Leave: Send an email to c6x-unsubscribe@y... > > > >Archives: http://www.yahoogroups.com/group/c6x > > > >Other Groups: http://www.dsprelated.com > > > > > >">http://docs.yahoo.com/info/terms/ |
Reply by ●September 17, 20022002-09-17
|
As I mentioned in another post, the problem is fixed now, because we found out how to turn off the cache. But to answer your question: --- In c6x@y..., Arius - Rick Collins <dsprelated@a...> wrote: > I am not clear what you mean by "I don't see the 2nd read actually be > executed". Are you saying you don't see the instruction fetch? Or you're > saying you don't see the bus handshake for the second read? In either > case, how can you see it get "a value back"? OH, you mean the code thinks > it got a value back.... > > Sounds like a chip bug to me! > The code is doing the following sequence: Write to address X in FPGA Read from address Y in FPGA Write 2nd value to address X Read 2nd value from address Y Write to address Z Watching the external data bus, address bus, write enable and output enable lines on a logic analyzer, we see: Write to X Read from Y Write to X Write to Z The 2nd read never made it to the external bus, because the cache was intercepting it. The value the code got from the 2nd read was the same as it got from the first read, when it should have gotten a different value if the cache wasn't operating. Hope this clears it up. Dan > > At 10:16 AM 9/17/02, dan_eyer wrote: > > >Yep, one of the first things we tried. No > >change. The reads are definitely in the > >compiled code, which is what "volatile" > >mainly affects. I see the code for the > >reads when I view the mixed source/asm, > >and I also saw the code in the instruction > >fetches that go out to the external RAM. > >But I don't see the 2nd read actually be > >executed over the external bus, even though > >it gets a value back. The value is wrong, > >because it's the same value the 1st read > >got. > > > >Thanks anyway, though. > >Dan > > Rick Collins > > rick.collins@a... > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX |
