Some MMU confusion

[wit-3]

Hi all,

I found some codes that are not consistent with the OpenRisc 1000
Architecture Manual:


1. About BA_MASK value
The document says the only 7:0 bit in BA_MASK register will be used. And
it's ANDed with the 23:16 bit of the CSC register. Then the result will
be compare with the input address (28:21 bits?)

But, looks like the code doesn't agree that the mask is 8 bits:

        l.movhi r3,hi(MC_BASE_ADD)
        l.ori   r3,r3,lo(MC_BASE_ADD)
 
        l.addi  r4,r3,MC_CSC(0)
        l.movhi r5,hi(FLASH_BASE_ADD)
line1:  l.srai  r5,r5,6 /* We shift 6 bits right*/
        l.ori   r5,r5,0x0025
        l.sw    0(r4),r5
 
        l.addi  r4,r3,MC_TMS(0)
        l.movhi r5,hi(FLASH_TMS_VAL)
        l.ori   r5,r5,lo(FLASH_TMS_VAL)
        l.sw    0(r4),r5
 
        l.addi  r4,r3,MC_BA_MASK
line2:  l.addi  r5,r0,MC_MASK_VAL /* the MC_MASK_VAL is 0x000003f0 */
        l.sw    0(r4),r5
 
        l.addi  r4,r3,MC_CSR
        l.movhi r5,hi(MC_CSR_VAL)
        l.ori   r5,r5,lo(MC_CSR_VAL)
        l.sw    0(r4),r5

line1, after the shift the most significant bit of r5 is at bit 25. And
also the BA_MASK value is 0x000003f0, it should be 10 bits long, then it
will be actually ANDed with the 25:16bit of the CSC. So the document is
not coincide with the code??
And also, since the CSC stores the most 10 significant bits of the
address (not bit 28:21), why are we comparing the ANDed result of the
CSC and BA_MASK with the 28:21 bits of input address??

2. About the Page Table Entry format.
As described in the document, the Page Table Entry format looks like:

31:10    9   8:6  5  4   3    2    1   0  
PPN      L   PPI  D  A  WOM  WBC  CI  CC

I think the following code is use to load the PTE from the PGD:

d_pmd_good:
        /*
         * pte = *pte_offset(pmd, daddr);
         */
line1: l.lwz r4,0x0(r4) // get **pmd value
line2: l.and r4,r4,r3 // & PAGE_MASK
        l.srli r5,r2,0xd // >> PAGE_SHIFT, r2 == EEAR
        l.andi r3,r5,0x7ff // (1UL << PAGE_SHIFT - 2) - 1
        l.slli r3,r3,0x2 // to get address << 2
        l.add r3,r3,r4
        l.lwz r2,0x0(r3) // this is pte at last

line1, r4 is now the value of the page table entry. We need to use it to
get the address of the level 2 page table base address. But why are we
applying the PAGE_MASK (most significant 19 bits are all 1) to r4? We
leave out the least significant 3 bits of PPN. Are those 3 bits the CID
number?

Thanks,
--Zhanhua


_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Zhanhua Kuang-2]

I still can find a explanation of the below questions. Any one can give
me a hand?

On Mon, 2009-03-02 at 14:06 +0800, Zhanhua Kuang wrote:

> Hi all,
>
> I found some codes that are not consistent with the OpenRisc 1000
> Architecture Manual:
>
>
> 1. About BA_MASK value
> The document says the only 7:0 bit in BA_MASK register will be used. And
> it's ANDed with the 23:16 bit of the CSC register. Then the result will
> be compare with the input address (28:21 bits?)
>
> But, looks like the code doesn't agree that the mask is 8 bits:
>
>         l.movhi r3,hi(MC_BASE_ADD)
>         l.ori   r3,r3,lo(MC_BASE_ADD)
>  
>         l.addi  r4,r3,MC_CSC(0)
>         l.movhi r5,hi(FLASH_BASE_ADD)
> line1:  l.srai  r5,r5,6 /* We shift 6 bits right*/
>         l.ori   r5,r5,0x0025
>         l.sw    0(r4),r5
>  
>         l.addi  r4,r3,MC_TMS(0)
>         l.movhi r5,hi(FLASH_TMS_VAL)
>         l.ori   r5,r5,lo(FLASH_TMS_VAL)
>         l.sw    0(r4),r5
>  
>         l.addi  r4,r3,MC_BA_MASK
> line2:  l.addi  r5,r0,MC_MASK_VAL /* the MC_MASK_VAL is 0x000003f0 */
>         l.sw    0(r4),r5
>  
>         l.addi  r4,r3,MC_CSR
>         l.movhi r5,hi(MC_CSR_VAL)
>         l.ori   r5,r5,lo(MC_CSR_VAL)
>         l.sw    0(r4),r5
>
> line1, after the shift the most significant bit of r5 is at bit 25. And
> also the BA_MASK value is 0x000003f0, it should be 10 bits long, then it
> will be actually ANDed with the 25:16bit of the CSC. So the document is
> not coincide with the code??
> And also, since the CSC stores the most 10 significant bits of the
> address (not bit 28:21), why are we comparing the ANDed result of the
> CSC and BA_MASK with the 28:21 bits of input address??
>
> 2. About the Page Table Entry format.
> As described in the document, the Page Table Entry format looks like:
>
> 31:10    9   8:6  5  4   3    2    1   0  
> PPN      L   PPI  D  A  WOM  WBC  CI  CC
>
> I think the following code is use to load the PTE from the PGD:
>
> d_pmd_good:
> /*
> * pte = *pte_offset(pmd, daddr);
> */
> line1: l.lwz r4,0x0(r4) // get **pmd value
> line2: l.and r4,r4,r3 // & PAGE_MASK
> l.srli r5,r2,0xd // >> PAGE_SHIFT, r2 == EEAR
> l.andi r3,r5,0x7ff // (1UL << PAGE_SHIFT - 2) - 1
> l.slli r3,r3,0x2 // to get address << 2
> l.add r3,r3,r4
> l.lwz r2,0x0(r3) // this is pte at last
>
> line1, r4 is now the value of the page table entry. We need to use it to
> get the address of the level 2 page table base address. But why are we
> applying the PAGE_MASK (most significant 19 bits are all 1) to r4? We
> leave out the least significant 3 bits of PPN. Are those 3 bits the CID
> number?
>
> Thanks,
> --Zhanhua
>

__________________________________________________________________________________________________________________
DISCLAIMER:"The information contained in this message and the attachments (if any) may be privileged and confidential and protected from disclosure. You are hereby notified that any unauthorized use, dissemination, distribution or copying of this communication, review, retransmission, or taking of any action based upon this information, by persons or entities other than the intended recipient, is strictly prohibited. If you are not the intended recipient or an employee or agent responsible for delivering this message, and have received this communication in error, please notify us immediately by replying to the message and kindly delete the original message, attachments, if any, and all its copies from your computer system. Thank you for your cooperation."
________________________________________________________________________________________________________________
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

On Tue, 2009-03-03 at 20:52 +0800, Zhanhua Kuang wrote:
> I still can find a explanation of the below questions. Any one can give
> me a hand?

Hi Zhanhua,

This code was written some time ago, and I am not sure the author is
still monitoring this mailing list. Rich D'Addio may know more about
this code.

In general the definitive documentation on OpenRISC 1000 is the Verilog
HDL. The architecture manual occasionally differs in details like this.
I would expect the MMU code to be following what is actually implemented
in the Verilog.

Whenever I have looked at the kernel, I've had to work out what is
happening just from code inspection. If you work out what is happening,
then adding some documentation (possibly just as extended comments)
would be much appreciated.

If there are discrepancies between the implementation and the
documentation, they should be added to the tracker, so the manual can be
updated in the future.

HTH,


Jeremy

> On Mon, 2009-03-02 at 14:06 +0800, Zhanhua Kuang wrote:
> > Hi all,
> >
> > I found some codes that are not consistent with the OpenRisc 1000
> > Architecture Manual:
> >
> >
> > 1. About BA_MASK value
> > The document says the only 7:0 bit in BA_MASK register will be used. And
> > it's ANDed with the 23:16 bit of the CSC register. Then the result will
> > be compare with the input address (28:21 bits?)
> >
> > But, looks like the code doesn't agree that the mask is 8 bits:
> >
> >         l.movhi r3,hi(MC_BASE_ADD)
> >         l.ori   r3,r3,lo(MC_BASE_ADD)
> >  
> >         l.addi  r4,r3,MC_CSC(0)
> >         l.movhi r5,hi(FLASH_BASE_ADD)
> > line1:  l.srai  r5,r5,6 /* We shift 6 bits right*/
> >         l.ori   r5,r5,0x0025
> >         l.sw    0(r4),r5
> >  
> >         l.addi  r4,r3,MC_TMS(0)
> >         l.movhi r5,hi(FLASH_TMS_VAL)
> >         l.ori   r5,r5,lo(FLASH_TMS_VAL)
> >         l.sw    0(r4),r5
> >  
> >         l.addi  r4,r3,MC_BA_MASK
> > line2:  l.addi  r5,r0,MC_MASK_VAL /* the MC_MASK_VAL is 0x000003f0 */
> >         l.sw    0(r4),r5
> >  
> >         l.addi  r4,r3,MC_CSR
> >         l.movhi r5,hi(MC_CSR_VAL)
> >         l.ori   r5,r5,lo(MC_CSR_VAL)
> >         l.sw    0(r4),r5
> >
> > line1, after the shift the most significant bit of r5 is at bit 25. And
> > also the BA_MASK value is 0x000003f0, it should be 10 bits long, then it
> > will be actually ANDed with the 25:16bit of the CSC. So the document is
> > not coincide with the code??
> > And also, since the CSC stores the most 10 significant bits of the
> > address (not bit 28:21), why are we comparing the ANDed result of the
> > CSC and BA_MASK with the 28:21 bits of input address??
> >
> > 2. About the Page Table Entry format.
> > As described in the document, the Page Table Entry format looks like:
> >
> > 31:10    9   8:6  5  4   3    2    1   0  
> > PPN      L   PPI  D  A  WOM  WBC  CI  CC
> >
> > I think the following code is use to load the PTE from the PGD:
> >
> > d_pmd_good:
> > /*
> > * pte = *pte_offset(pmd, daddr);
> > */
> > line1: l.lwz r4,0x0(r4) // get **pmd value
> > line2: l.and r4,r4,r3 // & PAGE_MASK
> > l.srli r5,r2,0xd // >> PAGE_SHIFT, r2 == EEAR
> > l.andi r3,r5,0x7ff // (1UL << PAGE_SHIFT - 2) - 1
> > l.slli r3,r3,0x2 // to get address << 2
> > l.add r3,r3,r4
> > l.lwz r2,0x0(r3) // this is pte at last
> >
> > line1, r4 is now the value of the page table entry. We need to use it to
> > get the address of the level 2 page table base address. But why are we
> > applying the PAGE_MASK (most significant 19 bits are all 1) to r4? We
> > leave out the least significant 3 bits of PPN. Are those 3 bits the CID
> > number?
> >
> > Thanks,
> > --Zhanhua
> >
>
>
> __________________________________________________________________________________________________________________
> DISCLAIMER:"The information contained in this message and the attachments (if any) may be privileged and confidential and protected from disclosure. You are hereby notified that any unauthorized use, dissemination, distribution or copying of this communication, review, retransmission, or taking of any action based upon this information, by persons or entities other than the intended recipient, is strictly prohibited. If you are not the intended recipient or an employee or agent responsible for delivering this message, and have received this communication in error, please notify us immediately by replying to the message and kindly delete the original message, attachments, if any, and all its copies from your computer system. Thank you for your cooperation."
> ________________________________________________________________________________________________________________
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc

--
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com


_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[rich_daddio]

Hi Zhanhua,
I will take a look on the weekend as I am busy with work issues this
week. I have been thru that code before, have you checked all the real
values in the registers? Are they what you expect?

Thanks,

Rich d

----- Original Message -----
From: Jeremy Bennett<jeremy.bennett@e...>
To:
Date: Wed Mar  4 11:15:27 CET 2009
Subject: [openrisc] Re: Some MMU confusion

> On Tue, 2009-03-03 at 20:52 +0800, Zhanhua Kuang wrote:
> > I still can find a explanation of the below questions. Any one
> can give
> > me a hand?
> Hi Zhanhua,
> This code was written some time ago, and I am not sure the author
> is
> still monitoring this mailing list. Rich D'Addio may know more
> about
> this code.
> In general the definitive documentation on OpenRISC 1000 is the
> Verilog
> HDL. The architecture manual occasionally differs in details like
> this.
> I would expect the MMU code to be following what is actually
> implemented
> in the Verilog.
> Whenever I have looked at the kernel, I've had to work out what is
> happening just from code inspection. If you work out what is
> happening,
> then adding some documentation (possibly just as extended comments)
> would be much appreciated.
> If there are discrepancies between the implementation and the
> documentation, they should be added to the tracker, so the manual
> can be
> updated in the future.
> HTH,
> Jeremy
> > On Mon, 2009-03-02 at 14:06 +0800, Zhanhua Kuang wrote:
> > > Hi all,
> > >
> > > I found some codes that are not consistent with the
> OpenRisc 1000
> > > Architecture Manual:
> > >
> > >
> > > 1. About BA_MASK value
> > > The document says the only 7:0 bit in BA_MASK register
> will be used. And
> > > it's ANDed with the 23:16 bit of the CSC register. Then
> the result will
> > > be compare with the input address (28:21 bits?)
> > >
> > > But, looks like the code doesn't agree that the mask is 8
> bits:
> > >
> > > l.movhi r3,hi(MC_BASE_ADD)
> > > l.ori r3,r3,lo(MC_BASE_ADD)
> > >
> > > l.addi r4,r3,MC_CSC(0)
> > > l.movhi r5,hi(FLASH_BASE_ADD)
> > > line1: l.srai r5,r5,6 /* We shift 6 bits right*/
> > > l.ori r5,r5,0x0025
> > > l.sw 0(r4),r5
> > >
> > > l.addi r4,r3,MC_TMS(0)
> > > l.movhi r5,hi(FLASH_TMS_VAL)
> > > l.ori r5,r5,lo(FLASH_TMS_VAL)
> > > l.sw 0(r4),r5
> > >
> > > l.addi r4,r3,MC_BA_MASK
> > > line2: l.addi r5,r0,MC_MASK_VAL /* the MC_MASK_VAL is
> 0x000003f0 */
> > > l.sw 0(r4),r5
> > >
> > > l.addi r4,r3,MC_CSR
> > > l.movhi r5,hi(MC_CSR_VAL)
> > > l.ori r5,r5,lo(MC_CSR_VAL)
> > > l.sw 0(r4),r5
> > >
> > > line1, after the shift the most significant bit of r5 is
> at bit 25. And
> > > also the BA_MASK value is 0x000003f0, it should be 10
> bits long, then it
> > > will be actually ANDed with the 25:16bit of the CSC. So
> the document is
> > > not coincide with the code??
> > > And also, since the CSC stores the most 10 significant
> bits of the
> > > address (not bit 28:21), why are we comparing the ANDed
> result of the
> > > CSC and BA_MASK with the 28:21 bits of input address??
> > >
> > > 2. About the Page Table Entry format.
> > > As described in the document, the Page Table Entry format
> looks like:
> > >
> > > 31:10 9 8:6 5 4 3 2 1 0
> > > PPN L PPI D A WOM WBC CI CC
> > >
> > > I think the following code is use to load the PTE from
> the PGD:
> > >
> > > d_pmd_good:
> > > /*
> > > * pte = *pte_offset(pmd, daddr);
> > > */
> > > line1: l.lwz r4,0x0(r4) // get **pmd value
> > > line2: l.and r4,r4,r3 // & PAGE_MASK
> > > l.srli r5,r2,0xd // >> PAGE_SHIFT, r2 == EEAR
> > > l.andi r3,r5,0x7ff // (1UL << PAGE_SHIFT - 2) - 1
> > > l.slli r3,r3,0x2 // to get address << 2
> > > l.add r3,r3,r4
> > > l.lwz r2,0x0(r3) // this is pte at last
> > >
> > > line1, r4 is now the value of the page table entry. We
> need to use it to
> > > get the address of the level 2 page table base address.
> But why are we
> > > applying the PAGE_MASK (most significant 19 bits are all
> 1) to r4? We
> > > leave out the least significant 3 bits of PPN. Are those
> 3 bits the CID
> > > number?
> > >
> > > Thanks, > > --Zhanhua > > > > >
>

__________________________________________________________________________________________________________________

> > DISCLAIMER:"The information contained in this message and
> the attachments (if any) may be privileged and confidential and
> protected from disclosure. You are hereby notified that any
> unauthorized use, dissemination, distribution or copying of this
> communication, review, retransmission, or taking of any action
> based upon this information, by persons or entities other than the
> intended recipient, is strictly prohibited. If you are not the
> intended recipient or an employee or agent responsible for
> delivering this message, and have received this communication in
> error, please notify us immediately by replying to the message and
> kindly delete the original message, attachments, if any, and all
> its copies from your computer system. Thank you for your
> cooperation." >
>

________________________________________________________________________________________________________________

> > _______________________________________________ >
> http://www.opencores.org/mailman/listinfo/openrisc -- Tel: +44
> (1202) 416955 Cell: [phone] SkypeID: jeremybennett Email:
> jeremy.bennett at embecosm.com Web: www.embecosm.com
>
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[wit-3]

Hi Rich and Jeremy,

Thanks for the respond.
We dig into the verilog code and the simulator code a bit. Looks like
the hardware implementation is the same as what the docs say, so looks
like this is an simulator issue.

Jeremy, I saw you just updated the simulator, but I didn't have a chance
to look into the new code yet. Are you now taking care of the simulator
code? If so, could you give me some hint? I think the biggest confusion
here is the code for memory controller, is the simulator doing the
following to decide if a chip is selected:

1. ANDed the BA_MASK with the CSC SEL field. The document says only 7:0
bits in BA_MASK are used to mask with the SEL field of the CSC  register
which is also 8 bits long. But it seems that the BA_MASK and the SEL
field is actually 10 bits long in the simulator, isn't it?
2. Compare the result of step 1 with the input address. The doc says bit
28-21 of the input address will be used. If they're the same, and the
chip is selected. As for the code I read, looks like the simulator use
the highest 10 bits (31-22) of the input address to do this, right? And
why is the hardware using bit 28-21 from the input address? Using the
most significant bits may make more sense.

Rich, I don't know how to check the registers. Using gdb to do that?

Thanks,
--Zhanhua

rich_daddio@... wrote:

> Hi Zhanhua,
> I will take a look on the weekend as I am busy with work issues this
> week. I have been thru that code before, have you checked all the real
> values in the registers? Are they what you expect?
>
> Thanks,
>
> Rich d
>
> ----- Original Message -----
> From: Jeremy Bennett<jeremy.bennett@e...>
> To:
> Date: Wed Mar  4 11:15:27 CET 2009
> Subject: [openrisc] Re: Some MMU confusion
>
>  
>> On Tue, 2009-03-03 at 20:52 +0800, Zhanhua Kuang wrote:
>>    
>>> I still can find a explanation of the below questions. Any one
>>>      
>> can give
>>    
>>> me a hand?
>>>      
>> Hi Zhanhua,
>> This code was written some time ago, and I am not sure the author
>> is
>> still monitoring this mailing list. Rich D'Addio may know more
>> about
>> this code.
>> In general the definitive documentation on OpenRISC 1000 is the
>> Verilog
>> HDL. The architecture manual occasionally differs in details like
>> this.
>> I would expect the MMU code to be following what is actually
>> implemented
>> in the Verilog.
>> Whenever I have looked at the kernel, I've had to work out what is
>> happening just from code inspection. If you work out what is
>> happening,
>> then adding some documentation (possibly just as extended comments)
>> would be much appreciated.
>> If there are discrepancies between the implementation and the
>> documentation, they should be added to the tracker, so the manual
>> can be
>> updated in the future.
>> HTH,
>> Jeremy
>>    
>>> On Mon, 2009-03-02 at 14:06 +0800, Zhanhua Kuang wrote:
>>>      
>>>> Hi all,
>>>>
>>>> I found some codes that are not consistent with the
>>>>        
>> OpenRisc 1000
>>    
>>>> Architecture Manual:
>>>>
>>>>
>>>> 1. About BA_MASK value
>>>> The document says the only 7:0 bit in BA_MASK register
>>>>        
>> will be used. And
>>    
>>>> it's ANDed with the 23:16 bit of the CSC register. Then
>>>>        
>> the result will
>>    
>>>> be compare with the input address (28:21 bits?)
>>>>
>>>> But, looks like the code doesn't agree that the mask is 8
>>>>        
>> bits:
>>    
>>>> l.movhi r3,hi(MC_BASE_ADD)
>>>> l.ori r3,r3,lo(MC_BASE_ADD)
>>>>
>>>> l.addi r4,r3,MC_CSC(0)
>>>> l.movhi r5,hi(FLASH_BASE_ADD)
>>>> line1: l.srai r5,r5,6 /* We shift 6 bits right*/
>>>> l.ori r5,r5,0x0025
>>>> l.sw 0(r4),r5
>>>>
>>>> l.addi r4,r3,MC_TMS(0)
>>>> l.movhi r5,hi(FLASH_TMS_VAL)
>>>> l.ori r5,r5,lo(FLASH_TMS_VAL)
>>>> l.sw 0(r4),r5
>>>>
>>>> l.addi r4,r3,MC_BA_MASK
>>>> line2: l.addi r5,r0,MC_MASK_VAL /* the MC_MASK_VAL is
>>>>        
>> 0x000003f0 */
>>    
>>>> l.sw 0(r4),r5
>>>>
>>>> l.addi r4,r3,MC_CSR
>>>> l.movhi r5,hi(MC_CSR_VAL)
>>>> l.ori r5,r5,lo(MC_CSR_VAL)
>>>> l.sw 0(r4),r5
>>>>
>>>> line1, after the shift the most significant bit of r5 is
>>>>        
>> at bit 25. And
>>    
>>>> also the BA_MASK value is 0x000003f0, it should be 10
>>>>        
>> bits long, then it
>>    
>>>> will be actually ANDed with the 25:16bit of the CSC. So
>>>>        
>> the document is
>>    
>>>> not coincide with the code??
>>>> And also, since the CSC stores the most 10 significant
>>>>        
>> bits of the
>>    
>>>> address (not bit 28:21), why are we comparing the ANDed
>>>>        
>> result of the
>>    
>>>> CSC and BA_MASK with the 28:21 bits of input address??
>>>>
>>>> 2. About the Page Table Entry format.
>>>> As described in the document, the Page Table Entry format
>>>>        
>> looks like:
>>    
>>>> 31:10 9 8:6 5 4 3 2 1 0
>>>> PPN L PPI D A WOM WBC CI CC
>>>>
>>>> I think the following code is use to load the PTE from
>>>>        
>> the PGD:
>>    
>>>> d_pmd_good:
>>>> /*
>>>> * pte = *pte_offset(pmd, daddr);
>>>> */
>>>> line1: l.lwz r4,0x0(r4) // get **pmd value
>>>> line2: l.and r4,r4,r3 // & PAGE_MASK
>>>> l.srli r5,r2,0xd // >> PAGE_SHIFT, r2 == EEAR
>>>> l.andi r3,r5,0x7ff // (1UL << PAGE_SHIFT - 2) - 1
>>>> l.slli r3,r3,0x2 // to get address << 2
>>>> l.add r3,r3,r4
>>>> l.lwz r2,0x0(r3) // this is pte at last
>>>>
>>>> line1, r4 is now the value of the page table entry. We
>>>>        
>> need to use it to
>>    
>>>> get the address of the level 2 page table base address.
>>>>        
>> But why are we
>>    
>>>> applying the PAGE_MASK (most significant 19 bits are all
>>>>        
>> 1) to r4? We
>>    
>>>> leave out the least significant 3 bits of PPN. Are those
>>>>        
>> 3 bits the CID
>>    
>>>> number?
>>>>
>>>> Thanks, > > --Zhanhua > > > > >
>>>>        
> __________________________________________________________________________________________________________________
>
>  
>>> DISCLAIMER:"The information contained in this message and
>>>      
>> the attachments (if any) may be privileged and confidential and
>> protected from disclosure. You are hereby notified that any
>> unauthorized use, dissemination, distribution or copying of this
>> communication, review, retransmission, or taking of any action
>> based upon this information, by persons or entities other than the
>> intended recipient, is strictly prohibited. If you are not the
>> intended recipient or an employee or agent responsible for
>> delivering this message, and have received this communication in
>> error, please notify us immediately by replying to the message and
>> kindly delete the original message, attachments, if any, and all
>> its copies from your computer system. Thank you for your
>> cooperation." >
>>
>>    
> ________________________________________________________________________________________________________________
>
>  
>>> _______________________________________________ >
>>>      
>> http://www.opencores.org/mailman/listinfo/openrisc -- Tel: +44
>> (1202) 416955 Cell: [phone] SkypeID: jeremybennett Email:
>> jeremy.bennett at embecosm.com Web: www.embecosm.com
>>
>>    
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc
>
>  

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

On Thu, 2009-03-05 at 23:48 +0800, Zhanhua wrote:

> Hi Rich and Jeremy,
>
> Thanks for the respond.
> We dig into the verilog code and the simulator code a bit. Looks like
> the hardware implementation is the same as what the docs say, so looks
> like this is an simulator issue.
>
> Jeremy, I saw you just updated the simulator, but I didn't have a chance
> to look into the new code yet. Are you now taking care of the simulator
> code? If so, could you give me some hint? I think the biggest confusion
> here is the code for memory controller, is the simulator doing the
> following to decide if a chip is selected:

Hi Zhanhua,

I am looking after the simulator, but this is not an area I have
touched.

I have recently made available cycle accurate models of ORPSoC generated
from the Verilog using Verilator. I have yet to provide a version that
can run Linux (it has a slightly different memory map to ORPSoC), but
that should allow definitive checking of behavior. For details see:

        http://www.embecosm.com/download/ean6.html

> 1. ANDed the BA_MASK with the CSC SEL field. The document says only 7:0
> bits in BA_MASK are used to mask with the SEL field of the CSC  register
> which is also 8 bits long. But it seems that the BA_MASK and the SEL
> field is actually 10 bits long in the simulator, isn't it?

The general rule is that the Verilog implementation is definitive. It is
not unknown for the simulator and/or documentation to be out of step. If
you can provide details, and a test case in the OpenRISC tracker, then I
can try to get it fixed in the next release. Or feel free to contribute
your own fix.

> 2. Compare the result of step 1 with the input address. The doc says bit
> 28-21 of the input address will be used. If they're the same, and the
> chip is selected. As for the code I read, looks like the simulator use
> the highest 10 bits (31-22) of the input address to do this, right? And
> why is the hardware using bit 28-21 from the input address? Using the
> most significant bits may make more sense.

As noted above, Or1ksim is intended to mirror the behavior of the
Verilog.

> Rich, I don't know how to check the registers. Using gdb to do that?

Or1ksim in interactive mode allows you to inspect the registers. Or you
can use GDB as you suggest.

HTH,


Jeremy

--
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com


_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc