Hi Chenwei,
A couple of general comments --
1. strictly speaking you should have xilinx "gateway out" blocks between
the slice blocks and the scope, since the scope needs simulink (not xilinx)
data types as input. Having said that, it'll probably work the way you have
the design set up, it might issue warnings though.
2. Block sizes of 2^2 probably work, but I'd recommend testing with
something a little bigger in case there are some special cases which stop
the small block size from behaving as expected.
Now to explain (hopefully!) your results --
The qdr transpose is really a reorder, that is, no rearrangement of the
bits within the 36- bit words you're writing will ever take place. Thus, if
the bottom 18 bits going in are always 2, the bottom bits of the output
will also always be 2.
It is a transpose in the sense that as each word comes in, it is written
row by row in to a matrix with in_block_size columns, and out_block_size
rows. It is then reordered such that it is read out column by column.
Some hastily written python code showing how the output is related to the
input (which may or may not be helpful):
import pylab
in_block_size = 2**3
out_block_size = 2**4
n_cycles = 4 #cycles to plot
in_vec = range(in_block_size) * out_block_size * n_cycles
out_vec = [0 for i in range(len(in_vec))]
print 'in', in_vec
for i in range(n_cycles):
offset = i*in_block_size*out_block_size
for col in range(in_block_size):
for row in range(out_block_size):
out_vec[offset + row + col*out_block_size] = in_vec[offset + col +
row*in_block_size]
print 'out:', out_vec
pylab.subplot(2,1,1)
pylab.title('in')
pylab.plot(in_vec)
pylab.subplot(2,1,2)
pylab.title('out')
pylab.plot(out_vec)
pylab.show()
I'm not sure I can entirely explain the output you get. (Ignoring the '2'
in your LSBs, the block input is [0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, ...]
For an input and output block size of 4, [i think] the output should be:
[0, 4, 0, 4, 1, 5, 1, 5, 2, 6, 2, 6, 3, 7, 3, 7, <repeat>].
It doesn't seem to be quite that so I would suggest that either blocks that
small don't work or (perhaps more likely) something is up with your
sync-ing. If you look inside the block, you'll see a reorder, with text
saying 'order=3' or something like that (it is dependent on the qdr
transpose parameters you've chosen. Note, if you change the 'double buffer'
parameter of that block to 1, it will always have an order of 2, which can
be useful). Your sync period needs to be a multiple of both the matrix size
(in your case, 4*4 = 16 cycles) and also the number of reorder orders. Eg,
a multiple of 16*3 = 48 cycles. (see
https://casper.berkeley.edu/memos/sync_memo_v1.pdf for more info on sync
pulses and their pitfalls). I would suggest, for testing, that you input
only a single sync into the block, at least until you are familiar with
it's working.
Cheers, (and hope that helps!)
Jack
On Fri, 24 Apr 2015 at 15:19 Chenwei Cai <caichenwei1...@gmail.com> wrote:
> Thanks Jack and Dan.
>
> Regarding the qdr_transpose block, I am still confused. I have set up some
> simple models to figure out how this block works, but they just lead me to
> a greater confusion.
>
> One of the models is like this:
> https://www.dropbox.com/s/dwhukesqqhdgllf/Screenshot%20from%202015-04-24%2018%3A26%3A33.png?dl=0
> .
> The parameters of the counter are
> https://www.dropbox.com/s/hboym3amfbrcom9/Screenshot%20from%202015-04-24%2018%3A26%3A51.png?dl=0
> .
> And the parameters of the qdr_transpose block are
> https://www.dropbox.com/s/o9ke9wpur5bucwt/Screenshot%20from%202015-04-24%2018%3A27%3A20.png?dl=0
> .
>
> What I expect to do is to transpose the matrix like this
> https://www.dropbox.com/s/cogwtc3sk0cnuem/Screenshot%20from%202015-04-24%2019%3A09%3A27.png?dl=0.
> I have no idea whether the model is doing the same thing as I expect it to
> finish, since the execution of the simulation results in this
> https://www.dropbox.com/s/c28ya7koy5nyisi/Screenshot%20from%202015-04-24%2018%3A21%3A52.png?dl=0
> in
> the scope, which seems quite chaotic and intractable.
>
> I hope you can give me some more details on how to use the qdr_transpose
> block. Thanks!
>
>
>
>
> On Thu, Mar 26, 2015 at 4:38 PM, Chenwei Cai <caichenwei1...@gmail.com>
> wrote:
>
>> Dear CASPER,
>>
>> My name is Chenwei Cai, and I am constructing the Mega-Channel
>> Spectrometer with ROACH II. To achieve that, two corner turners are
>> required before we implement FFTs, which means I may use qdr_transpose or
>> qdr_ct blocks. Since I cannot find any explanations on these blocks
>> anywhere, could you provide me some details about the functions of these
>> two blocks and what kind of data do those ports receive/export?
>>
>> Look forward to hearing from you!
>>
>> --
>> Best Regards
>> Chenwei CAI
>>
>> Mobile: +86-152-0147-9411
>> Email: caichenwei1...@pku.edu.cn
>>
>>
>
>
> --
> Best Regards
> Chenwei CAI
>
> Mobile: +86-152-0147-9411
> Email: caichenwei1...@pku.edu.cn
>
>
