[casper] QDR simulations
Does anyone know whether simulations involving the QDR yellow block are supposed to work? They don't seem to be working for me. Maybe I'm doing something wrong? Thanks, Dave
Re: [casper] QDR simulations
Yes, there is a simulation model included in the Simulink space for that. I don't believe we've ever tried co-simulating the underlying VHDL from Simulink, if that's what you mean. Jason Manley CBF Manager SKA-SA Cell: +27 82 662 7726 Work: +27 21 506 7300 On 01 Apr 2015, at 3:36, David MacMahon wrote: > Does anyone know whether simulations involving the QDR yellow block are > supposed to work? > > They don't seem to be working for me. Maybe I'm doing something wrong? > > Thanks, > Dave > >
Re: [casper] QDR simulations
Hi, Jason,
On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
> Yes, there is a simulation model included in the Simulink space for that.
Yes, I know there is a simulation model included, but does it work?
It looks like the "qdr_sim_model" passes the "data_in" signal through a Gateway
In block ("sim_data_in") that outputs a 36 bit wide signal. This 36-bit data
path propagate out of "qdr_sim_model" and then through another Gateway In block
("_data_out") that outputs a 72 bit wide signal.
How could that ever work?
> I don't believe we've ever tried co-simulating the underlying VHDL from
> Simulink, if that's what you mean.
No, that's not what I mean. That would require a bus functional model of the
QDR chip and I don't think that exists in the repository.
Thanks,
Dave
Re: [casper] QDR simulations
It might well be that the simulation model is out of date... are you running an
up-to-date library? It was copy-pasted from ROACH-1 (which is 36b vs R2's 72b
and has a latency of 9 vs R2's 10). Paul, Wesley, Andrew and I have just
checked, and our sim models seem to be correct on the SKA-SA github repo.
Jason Manley
CBF Manager
SKA-SA
Cell: +27 82 662 7726
Work: +27 21 506 7300
On 01 Apr 2015, at 10:31, David MacMahon wrote:
> Hi, Jason,
>
> On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
>
>> Yes, there is a simulation model included in the Simulink space for that.
>
> Yes, I know there is a simulation model included, but does it work?
>
> It looks like the "qdr_sim_model" passes the "data_in" signal through a
> Gateway In block ("sim_data_in") that outputs a 36 bit wide signal. This
> 36-bit data path propagate out of "qdr_sim_model" and then through another
> Gateway In block ("_data_out") that outputs a 72 bit wide signal.
>
> How could that ever work?
>
>> I don't believe we've ever tried co-simulating the underlying VHDL from
>> Simulink, if that's what you mean.
>
> No, that's not what I mean. That would require a bus functional model of the
> QDR chip and I don't think that exists in the repository.
>
> Thanks,
> Dave
>
Re: [casper] QDR simulations
Hey Dave
This should have been fixed in commit b1295df1ef.
Cheers
Andrew
On Wed, Apr 1, 2015 at 10:31 AM, David MacMahon
wrote:
> Hi, Jason,
>
> On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
>
> > Yes, there is a simulation model included in the Simulink space for that.
>
> Yes, I know there is a simulation model included, but does it work?
>
> It looks like the "qdr_sim_model" passes the "data_in" signal through a
> Gateway In block ("sim_data_in") that outputs a 36 bit wide signal. This
> 36-bit data path propagate out of "qdr_sim_model" and then through another
> Gateway In block ("_data_out") that outputs a 72 bit wide
> signal.
>
> How could that ever work?
>
> > I don't believe we've ever tried co-simulating the underlying VHDL from
> Simulink, if that's what you mean.
>
> No, that's not what I mean. That would require a bus functional model of
> the QDR chip and I don't think that exists in the repository.
>
> Thanks,
> Dave
>
>
>
Re: [casper] QDR simulations
Hi, Jason,
Really? I just checked ska-sa/master on github (commit 5adf53a, dated
2015-03-06 16:34:34 +0200) and it also has the 36-bit wide "sim_data_in"
Gateway In block inside the "qdr_sim_model" block.
Have you actually tried to simulate QDR using data that is wider than 36 bits?
Thanks,
Dave
On Apr 1, 2015, at 1:37 AM, Jason Manley wrote:
> It might well be that the simulation model is out of date... are you running
> an up-to-date library? It was copy-pasted from ROACH-1 (which is 36b vs R2's
> 72b and has a latency of 9 vs R2's 10). Paul, Wesley, Andrew and I have just
> checked, and our sim models seem to be correct on the SKA-SA github repo.
>
> Jason Manley
> CBF Manager
> SKA-SA
>
> Cell: +27 82 662 7726
> Work: +27 21 506 7300
>
> On 01 Apr 2015, at 10:31, David MacMahon wrote:
>
>> Hi, Jason,
>>
>> On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
>>
>>> Yes, there is a simulation model included in the Simulink space for that.
>>
>> Yes, I know there is a simulation model included, but does it work?
>>
>> It looks like the "qdr_sim_model" passes the "data_in" signal through a
>> Gateway In block ("sim_data_in") that outputs a 36 bit wide signal. This
>> 36-bit data path propagate out of "qdr_sim_model" and then through another
>> Gateway In block ("_data_out") that outputs a 72 bit wide signal.
>>
>> How could that ever work?
>>
>>> I don't believe we've ever tried co-simulating the underlying VHDL from
>>> Simulink, if that's what you mean.
>>
>> No, that's not what I mean. That would require a bus functional model of
>> the QDR chip and I don't think that exists in the repository.
>>
>> Thanks,
>> Dave
>>
>
Re: [casper] QDR simulations
Maybe you've got a script error or something that's preventing the block from
updating? That gateway block should change to 72b when your design updates. You
will see the code in the init script to do this.
I've just tried this on my design, and confirmed that it changes from 36b to
72b when ROACH2 is selected in the XPS block. Paul has independently checked on
his design, too.
Jason Manley
CBF Manager
SKA-SA
Cell: +27 82 662 7726
Work: +27 21 506 7300
On 01 Apr 2015, at 10:44, David MacMahon wrote:
> Hi, Jason,
>
> Really? I just checked ska-sa/master on github (commit 5adf53a, dated
> 2015-03-06 16:34:34 +0200) and it also has the 36-bit wide "sim_data_in"
> Gateway In block inside the "qdr_sim_model" block.
>
> Have you actually tried to simulate QDR using data that is wider than 36 bits?
>
> Thanks,
> Dave
>
> On Apr 1, 2015, at 1:37 AM, Jason Manley wrote:
>
>> It might well be that the simulation model is out of date... are you running
>> an up-to-date library? It was copy-pasted from ROACH-1 (which is 36b vs R2's
>> 72b and has a latency of 9 vs R2's 10). Paul, Wesley, Andrew and I have just
>> checked, and our sim models seem to be correct on the SKA-SA github repo.
>>
>> Jason Manley
>> CBF Manager
>> SKA-SA
>>
>> Cell: +27 82 662 7726
>> Work: +27 21 506 7300
>>
>> On 01 Apr 2015, at 10:31, David MacMahon wrote:
>>
>>> Hi, Jason,
>>>
>>> On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
>>>
Yes, there is a simulation model included in the Simulink space for that.
>>>
>>> Yes, I know there is a simulation model included, but does it work?
>>>
>>> It looks like the "qdr_sim_model" passes the "data_in" signal through a
>>> Gateway In block ("sim_data_in") that outputs a 36 bit wide signal. This
>>> 36-bit data path propagate out of "qdr_sim_model" and then through another
>>> Gateway In block ("_data_out") that outputs a 72 bit wide
>>> signal.
>>>
>>> How could that ever work?
>>>
I don't believe we've ever tried co-simulating the underlying VHDL from
Simulink, if that's what you mean.
>>>
>>> No, that's not what I mean. That would require a bus functional model of
>>> the QDR chip and I don't think that exists in the repository.
>>>
>>> Thanks,
>>> Dave
>>>
>>
>
Re: [casper] QDR simulations
Thanks, Jason.
It seems like my port width problem is due to using an mlib_devel that had
merged ska-sa/master just before Andrew committed a fix for that problem.
Port width problems aside, you still haven't answered my question about whether
the simulation model works properly... :-)
Thanks again,
Dave
On Apr 1, 2015, at 1:53 AM, Jason Manley wrote:
> Maybe you've got a script error or something that's preventing the block from
> updating? That gateway block should change to 72b when your design updates.
> You will see the code in the init script to do this.
>
> I've just tried this on my design, and confirmed that it changes from 36b to
> 72b when ROACH2 is selected in the XPS block. Paul has independently checked
> on his design, too.
>
> Jason Manley
> CBF Manager
> SKA-SA
>
> Cell: +27 82 662 7726
> Work: +27 21 506 7300
>
> On 01 Apr 2015, at 10:44, David MacMahon wrote:
>
>> Hi, Jason,
>>
>> Really? I just checked ska-sa/master on github (commit 5adf53a, dated
>> 2015-03-06 16:34:34 +0200) and it also has the 36-bit wide "sim_data_in"
>> Gateway In block inside the "qdr_sim_model" block.
>>
>> Have you actually tried to simulate QDR using data that is wider than 36
>> bits?
>>
>> Thanks,
>> Dave
>>
>> On Apr 1, 2015, at 1:37 AM, Jason Manley wrote:
>>
>>> It might well be that the simulation model is out of date... are you
>>> running an up-to-date library? It was copy-pasted from ROACH-1 (which is
>>> 36b vs R2's 72b and has a latency of 9 vs R2's 10). Paul, Wesley, Andrew
>>> and I have just checked, and our sim models seem to be correct on the
>>> SKA-SA github repo.
>>>
>>> Jason Manley
>>> CBF Manager
>>> SKA-SA
>>>
>>> Cell: +27 82 662 7726
>>> Work: +27 21 506 7300
>>>
>>> On 01 Apr 2015, at 10:31, David MacMahon wrote:
>>>
Hi, Jason,
On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
> Yes, there is a simulation model included in the Simulink space for that.
Yes, I know there is a simulation model included, but does it work?
It looks like the "qdr_sim_model" passes the "data_in" signal through a
Gateway In block ("sim_data_in") that outputs a 36 bit wide signal. This
36-bit data path propagate out of "qdr_sim_model" and then through another
Gateway In block ("_data_out") that outputs a 72 bit wide
signal.
How could that ever work?
> I don't believe we've ever tried co-simulating the underlying VHDL from
> Simulink, if that's what you mean.
No, that's not what I mean. That would require a bus functional model of
the QDR chip and I don't think that exists in the repository.
Thanks,
Dave
>>>
>>
>
Re: [casper] QDR simulations
I am using the sim model in my designs... it *seems* to work properly! But
you're making me nervous now. Have you got a specific problem apart from the
block not redrawing?
Jason Manley
CBF Manager
SKA-SA
Cell: +27 82 662 7726
Work: +27 21 506 7300
On 01 Apr 2015, at 11:06, David MacMahon wrote:
> Thanks, Jason.
>
> It seems like my port width problem is due to using an mlib_devel that had
> merged ska-sa/master just before Andrew committed a fix for that problem.
>
> Port width problems aside, you still haven't answered my question about
> whether the simulation model works properly... :-)
>
> Thanks again,
> Dave
>
> On Apr 1, 2015, at 1:53 AM, Jason Manley wrote:
>
>> Maybe you've got a script error or something that's preventing the block
>> from updating? That gateway block should change to 72b when your design
>> updates. You will see the code in the init script to do this.
>>
>> I've just tried this on my design, and confirmed that it changes from 36b to
>> 72b when ROACH2 is selected in the XPS block. Paul has independently checked
>> on his design, too.
>>
>> Jason Manley
>> CBF Manager
>> SKA-SA
>>
>> Cell: +27 82 662 7726
>> Work: +27 21 506 7300
>>
>> On 01 Apr 2015, at 10:44, David MacMahon wrote:
>>
>>> Hi, Jason,
>>>
>>> Really? I just checked ska-sa/master on github (commit 5adf53a, dated
>>> 2015-03-06 16:34:34 +0200) and it also has the 36-bit wide "sim_data_in"
>>> Gateway In block inside the "qdr_sim_model" block.
>>>
>>> Have you actually tried to simulate QDR using data that is wider than 36
>>> bits?
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Apr 1, 2015, at 1:37 AM, Jason Manley wrote:
>>>
It might well be that the simulation model is out of date... are you
running an up-to-date library? It was copy-pasted from ROACH-1 (which is
36b vs R2's 72b and has a latency of 9 vs R2's 10). Paul, Wesley, Andrew
and I have just checked, and our sim models seem to be correct on the
SKA-SA github repo.
Jason Manley
CBF Manager
SKA-SA
Cell: +27 82 662 7726
Work: +27 21 506 7300
On 01 Apr 2015, at 10:31, David MacMahon wrote:
> Hi, Jason,
>
> On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
>
>> Yes, there is a simulation model included in the Simulink space for that.
>
> Yes, I know there is a simulation model included, but does it work?
>
> It looks like the "qdr_sim_model" passes the "data_in" signal through a
> Gateway In block ("sim_data_in") that outputs a 36 bit wide signal. This
> 36-bit data path propagate out of "qdr_sim_model" and then through
> another Gateway In block ("_data_out") that outputs a 72 bit
> wide signal.
>
> How could that ever work?
>
>> I don't believe we've ever tried co-simulating the underlying VHDL from
>> Simulink, if that's what you mean.
>
> No, that's not what I mean. That would require a bus functional model of
> the QDR chip and I don't think that exists in the repository.
>
> Thanks,
> Dave
>
>>>
>>
>
Re: [casper] QDR simulations
I hope my problems are all caused by this port width problem. I'll let you
know how it goes once I get the QDR blocks drawn properly.
Thanks,
Dave
On Apr 1, 2015, at 2:14 AM, Jason Manley wrote:
> I am using the sim model in my designs... it *seems* to work properly! But
> you're making me nervous now. Have you got a specific problem apart from the
> block not redrawing?
>
> Jason Manley
> CBF Manager
> SKA-SA
>
> Cell: +27 82 662 7726
> Work: +27 21 506 7300
>
> On 01 Apr 2015, at 11:06, David MacMahon wrote:
>
>> Thanks, Jason.
>>
>> It seems like my port width problem is due to using an mlib_devel that had
>> merged ska-sa/master just before Andrew committed a fix for that problem.
>>
>> Port width problems aside, you still haven't answered my question about
>> whether the simulation model works properly... :-)
>>
>> Thanks again,
>> Dave
>>
>> On Apr 1, 2015, at 1:53 AM, Jason Manley wrote:
>>
>>> Maybe you've got a script error or something that's preventing the block
>>> from updating? That gateway block should change to 72b when your design
>>> updates. You will see the code in the init script to do this.
>>>
>>> I've just tried this on my design, and confirmed that it changes from 36b
>>> to 72b when ROACH2 is selected in the XPS block. Paul has independently
>>> checked on his design, too.
>>>
>>> Jason Manley
>>> CBF Manager
>>> SKA-SA
>>>
>>> Cell: +27 82 662 7726
>>> Work: +27 21 506 7300
>>>
>>> On 01 Apr 2015, at 10:44, David MacMahon wrote:
>>>
Hi, Jason,
Really? I just checked ska-sa/master on github (commit 5adf53a, dated
2015-03-06 16:34:34 +0200) and it also has the 36-bit wide "sim_data_in"
Gateway In block inside the "qdr_sim_model" block.
Have you actually tried to simulate QDR using data that is wider than 36
bits?
Thanks,
Dave
On Apr 1, 2015, at 1:37 AM, Jason Manley wrote:
> It might well be that the simulation model is out of date... are you
> running an up-to-date library? It was copy-pasted from ROACH-1 (which is
> 36b vs R2's 72b and has a latency of 9 vs R2's 10). Paul, Wesley, Andrew
> and I have just checked, and our sim models seem to be correct on the
> SKA-SA github repo.
>
> Jason Manley
> CBF Manager
> SKA-SA
>
> Cell: +27 82 662 7726
> Work: +27 21 506 7300
>
> On 01 Apr 2015, at 10:31, David MacMahon
> wrote:
>
>> Hi, Jason,
>>
>> On Mar 31, 2015, at 11:25 PM, Jason Manley wrote:
>>
>>> Yes, there is a simulation model included in the Simulink space for
>>> that.
>>
>> Yes, I know there is a simulation model included, but does it work?
>>
>> It looks like the "qdr_sim_model" passes the "data_in" signal through a
>> Gateway In block ("sim_data_in") that outputs a 36 bit wide signal.
>> This 36-bit data path propagate out of "qdr_sim_model" and then through
>> another Gateway In block ("_data_out") that outputs a 72 bit
>> wide signal.
>>
>> How could that ever work?
>>
>>> I don't believe we've ever tried co-simulating the underlying VHDL from
>>> Simulink, if that's what you mean.
>>
>> No, that's not what I mean. That would require a bus functional model
>> of the QDR chip and I don't think that exists in the repository.
>>
>> Thanks,
>> Dave
>>
>
>>>
>>
>
