Re: Re: [casper] ROACH2 QDR testing address problem

[zhang laiyu]

  Thanks Jack.

  That is what I need. 

  What I want to do is using CPU interface to write data into QDR and using 
firmware interface to read data out from QDR.

  The two interface of QDR make me confused.





--

Cheers!

>
ZHANG Laiyu   
Phone(China)   010-88233078   
Cellphone(China)   13681385567
E-mail:zhan...@ihep.ac.cn
Address:   19B Yuquan Road,Shijingshan District,Beijing，China
Department:Center for Particle Astrophysics 
Office:Astrophysics Building 205
Institute of High Energy Physics, CAS  
web: http://www.ihep.cas.cn
>





-原始邮件-
发件人:"Jack Hickish" 
发送时间:2020-12-21 19:29:19 (星期一)
收件人: casper 
抄送: sebastian.jorqu...@ug.uchile.cl
主题: Re: [casper] ROACH2 QDR testing address problem


I'm not sure how that particular script / firmware works, but in general, a 
single read/write action in the ROACH2 QDR transfers 144 bits. The granularity 
of the python read writes is 32-bits, so what actually happens is that a read 
from casperfpga grabs 144 bytes, carves it up into 4x36 bit words, throws away 
the most significant 4 bits of each chunk, and then returns the appropriate 32 
bits.

Note that this makes writes from software particularly tricky -- if you don't 
write in bursts of 16 bytes, (aligned to 16-byte addresses) there is a very 
high probability that things will not work the way you want.


These lines ( this and this ) show how the 32-bit selection is implemented. The 
commit message associated with the second line linked says "MSb 32 bits are 
read first, followed by bits 32 to 63". I'm not sure how this relates to the 
convention assumed in the firmware interface. I would imagine the intention is 
that for a QDR write (which takes 2 clock cycles and writes 64 bits on each) 
the logic is (with addressing in 32-bit words):


First write cycle: most significant bits = word 0; least significant bits = 
word 1
Second write cycle: most significant bits = word 2; least significant bits = 
word 3;


I don't know of many occasions when both the CPU and firmware QDR interfaces 
are both used, so it's very possible that the relationship between the firmware 
and software interfaces is either not as intended, or is as intended but with 
an odd, undocumented mapping.


Hopefully the above helps point you in the right direction(?) Hopefully it 
doesn't just add to the confusion(?)


Cheers
Jack


On Mon, 21 Dec 2020 at 10:12, zhang laiyu  wrote:


Hi

  Thanks for your help.

  The firmware and python script had worked (qdr_basic and qdr_counter).I can 
get the plot. But I can not understand the PPC readout script in  
qdr_counter.py thoroughly .The address is really weird. After studying the wiki 
of the CASPER QDR yellow block and datasheet of the QDR chip(CY7C2565KV18), I 
still can not understand the python script very well. Why the 'PPC data' was 
picked like that? Could you give me some suggestion about where can I find more 
clear information about the addree of QDR interface to PowerPC?



 

Cheers!

>
ZHANG Laiyu   
Phone(China)   010-88233078   
Cellphone(China)   13681385567
E-mail: zhan...@ihep.ac.cn Address:   19B Yuquan Road,Shijingshan 
District,Beijing，China
Department:Center for Particle Astrophysics 
Office:Astrophysics Building 205
Institute of High Energy Physics, CAS  
web: http://www.ihep.cas.cn
>







--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/606c0c11.e7c3.17684c842a5.Coremail.zhangly%40ihep.ac.cn.





--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSkVM8Y2Odu%2BW%2BjOMSLbZw8kaOq5jhzUEc_hkZtS2Jdmcg%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/58e39772.eeb0.176189e.Coremail.zhangly%40ihep.ac.cn.

Re: [casper] ROACH2 QDR testing address problem

[Jack Hickish]

I'm not sure how that particular script / firmware works, but in general, a
single read/write action in the ROACH2 QDR transfers 144 bits. The
granularity of the python read writes is 32-bits, so what actually happens
is that a read from casperfpga grabs 144 bytes, carves it up into 4x36 bit
words, throws away the most significant 4 bits of each chunk, and then
returns the appropriate 32 bits.
Note that this makes writes from software particularly tricky -- if you
don't write in bursts of 16 bytes, (aligned to 16-byte addresses) there is
a very high probability that things will not work the way you want.

These lines ( this

and
this

)
show how the 32-bit selection is implemented. The commit message associated
with the second line linked says "MSb 32 bits are read first, followed by
bits 32 to 63". I'm not sure how this relates to the convention assumed in
the firmware interface. I would imagine the intention is that for a QDR
write (which takes 2 clock cycles and writes 64 bits on each) the logic is
(with addressing in 32-bit words):

First write cycle: most significant bits = word 0; least significant bits =
word 1
Second write cycle: most significant bits = word 2; least significant bits
= word 3;

I don't know of many occasions when both the CPU and firmware QDR
interfaces are both used, so it's very possible that the
relationship between the firmware and software interfaces is either not as
intended, or is as intended but with an odd, undocumented mapping.

Hopefully the above helps point you in the right direction(?) Hopefully it
doesn't just add to the confusion(?)

Cheers
Jack

On Mon, 21 Dec 2020 at 10:12, zhang laiyu  wrote:

> Hi
>
>   Thanks for your help.
>
>   The firmware and python script had worked (qdr_basic and qdr_counter).I
> can get the plot. But I can not understand the PPC readout script in
> qdr_counter.py thoroughly .The address is really weird. After studying
> the wiki of the CASPER QDR yellow block and datasheet of the QDR
> chip(CY7C2565KV18), I still can not understand the python script very well.
> Why the 'PPC data' was picked like that? Could you give me some suggestion
> about where can I find more clear information about the addree of QDR
> interface to PowerPC?
>
>
>
>
>  Cheers!
>
> >
> ZHANG Laiyu
> Phone(China)   010-88233078
> Cellphone(China)   13681385567
> E-mail:zhan...@ihep.ac.cn
> Address:   19B Yuquan Road,Shijingshan District,Beijing，China
> Department:Center for Particle Astrophysics
> Office:Astrophysics Building 205
>
> Institute of High Energy Physics, CAS
> web: http://www.ihep.cas.cn 
>
> >
>
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>   
>
>
>
>   * *
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/606c0c11.e7c3.17684c842a5.Coremail.zhangly%40ihep.ac.cn
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSkVM8Y2Odu%2BW%2BjOMSLbZw8kaOq5jhzUEc_hkZtS2Jdmcg%40mail.gmail.com.