Re: [casper] dac mkid spi problem

2018-02-22 Thread Jack Hickish
To add the CASPER-specific note to Dave's answer:

To inject constraints for a particular yellow block, you can add them to
the string returned by xps_library/@xps_/gen_ucf.m . See
for example (
https://github.com/jack-h/mlib_devel/blob/roach2/xps_library/%40xps_adc_mkid/gen_ucf.m
)
(I don't know if this is actually the block you want, I'm unfamiliar with
the mkid dac/adc board.)

Cheers
Jack


On Thu, 22 Feb 2018 at 09:43 Hawkins, David W (334B) <
david.w.hawk...@jpl.nasa.gov> wrote:

> Hi All,
>
>
>
> Non-ROACH user here … but a Xilinx tool user.
>
>
>
> The default for unused pins in ISE is to enable pull-downs on unused pins.
> If your SPI pins do not have a pin constraint, then they may just be
> getting pulled low. If the SPI select is active low (likely), then the chip
> is being selected.
>
>
>
> If your pin constraints file does not have the SPI signals defined, then
> use the BitGen option to use pull-ups on unused pins.
>
>
>
> The Tcl command is:
>
> project set "Unused IOB Pins" "Pull Up" -process "Generate Programming
> File"
>
>
>
> Alternatively, you can add pins to your constraints file, and use the “S”
> option to stop ISE deleting them during synthesis. You can then turn on
> pull-ups/downs on a per pin basis, eg., here’s some lines from my Avnet
> Spartan-6 Microboard constraints file …
>
>
>
> # PHY interface
>
> NET "eth_resetN"LOC = T18 | IOSTANDARD = LVCMOS33 | S | TIG;
>
> NET "eth_col"   LOC = M18 | IOSTANDARD = LVCMOS33 | S | PULLDOWN;
>
> NET "eth_crs"   LOC = N17 | IOSTANDARD = LVCMOS33 | S | PULLDOWN;
>
> NET "eth_rx_clk"LOC = L15 | IOSTANDARD = LVCMOS33 | S;
>
> NET "eth_rx_d<0>"   LOC = T17 | IOSTANDARD = LVCMOS33 | S | PULLUP;
>
> NET "eth_rx_d<1>"   LOC = N16 | IOSTANDARD = LVCMOS33 | S | PULLUP;
>
> NET "eth_rx_d<2>"   LOC = N15 | IOSTANDARD = LVCMOS33 | S | PULLUP;
>
> NET "eth_rx_d<3>"   LOC = P18 | IOSTANDARD = LVCMOS33 | S | PULLUP;
>
>
>
> Given that the ROACH flow is mostly automated, this last option might be
> the simplest. Just add the SPI constraints.
>
>
>
> Cheers,
>
> Dave
>
>
>
>
>
> *From:* Jack Hickish [mailto:jackhick...@gmail.com]
> *Sent:* Thursday, February 22, 2018 9:25 AM
> *To:* casper@lists.berkeley.edu
>
>
> *Subject:* Re: [casper] dac mkid spi problem
>
>
>
> Hi Paolo,
>
>
>
> OK, let me know!
>
>
>
> Jack
>
>
>
> On Thu, 22 Feb 2018 at 08:14 Paolo Fresch <paolo.fres...@gmail.com> wrote:
>
> Thank you Jack,
>
> so far the method we have found to fix this issue works as long as we keep
> the roach up, thus the undriven-SPI do not bother us that much. I had a
> look at the verilog hdl, I am quite use to verilog and SPI (I did something
> similar for an I2C interface) but I can't say the same for OPB bus,
> power-pc's and so on... it will take me a while I guess. I will contact you
> when I will be on it.
>
> Cheers,
>
> Paolo
>
>
>
> 2018-02-20 19:57 GMT+01:00 Jack Hickish <jackhick...@gmail.com>:
>
> Hi Paolo,
>
>
>
> If I'm reading the code correctly --
> https://github.com/casper-astro/mlib_devel/blob/roach2/xps_library/%40xps_adc_mkid/xps_adc_mkid.m
>  --
> I believe that none of the SPI pins are driven. I have no idea whether any
> of these pins are pulled in any particular direction on the hardware since
> I haven't checked the schematics.
>
>
>
> I don't think there is a ready-to-use PPC<->SPI block, but there should be
> a variety of examples of SPI interfaces for other ADCs in the library --
> https://github.com/casper-astro/mlib_devel/blob/roach2/xps_base/XPS_ROACH_base/pcores/opb_adc5g_controller_v1_00_a/hdl/verilog/opb_adc5g_controller.v
>
>
>
> Integrating such an interface shouldn't be that hard, though involves
> getting dirty with the toolflow. If you're sure this is your problem and
> want a hand, give me a shout and I'll try and find the time to help you do
> this.
>
>
>
> Cheers
>
> Jack
>
>
>
> On Mon, 19 Feb 2018 at 09:36 Paolo Fresch <paolo.fres...@gmail.com> wrote:
>
> Dear all,
>
>
>
> I am a technical research fellow at INFN sezione di Roma, I am
> experiencing strange issue using roach + mkid DAC/ADC board
> <https://static1.squarespace.com/static/59c075f56f4ca3a44435bdb9/t/59f4e9ae24a694055a5761ad/1509222838779/MKID_DAC_ADC_brief.pdf>
> .
>
>
>
> Basically, after a “cold” startup the DAC does not generate the correct
> sinusoid but either nothing or som

RE: [casper] dac mkid spi problem

2018-02-22 Thread Hawkins, David W (334B)
Hi All,

Non-ROACH user here … but a Xilinx tool user.

The default for unused pins in ISE is to enable pull-downs on unused pins. If 
your SPI pins do not have a pin constraint, then they may just be getting 
pulled low. If the SPI select is active low (likely), then the chip is being 
selected.

If your pin constraints file does not have the SPI signals defined, then use 
the BitGen option to use pull-ups on unused pins.

The Tcl command is:
project set "Unused IOB Pins" "Pull Up" -process "Generate Programming File"

Alternatively, you can add pins to your constraints file, and use the “S” 
option to stop ISE deleting them during synthesis. You can then turn on 
pull-ups/downs on a per pin basis, eg., here’s some lines from my Avnet 
Spartan-6 Microboard constraints file …

# PHY interface
NET "eth_resetN"LOC = T18 | IOSTANDARD = LVCMOS33 | S | TIG;
NET "eth_col"   LOC = M18 | IOSTANDARD = LVCMOS33 | S | PULLDOWN;
NET "eth_crs"   LOC = N17 | IOSTANDARD = LVCMOS33 | S | PULLDOWN;
NET "eth_rx_clk"LOC = L15 | IOSTANDARD = LVCMOS33 | S;
NET "eth_rx_d<0>"   LOC = T17 | IOSTANDARD = LVCMOS33 | S | PULLUP;
NET "eth_rx_d<1>"   LOC = N16 | IOSTANDARD = LVCMOS33 | S | PULLUP;
NET "eth_rx_d<2>"   LOC = N15 | IOSTANDARD = LVCMOS33 | S | PULLUP;
NET "eth_rx_d<3>"   LOC = P18 | IOSTANDARD = LVCMOS33 | S | PULLUP;

Given that the ROACH flow is mostly automated, this last option might be the 
simplest. Just add the SPI constraints.

Cheers,
Dave


From: Jack Hickish [mailto:jackhick...@gmail.com]
Sent: Thursday, February 22, 2018 9:25 AM
To: casper@lists.berkeley.edu
Subject: Re: [casper] dac mkid spi problem

Hi Paolo,

OK, let me know!

Jack

On Thu, 22 Feb 2018 at 08:14 Paolo Fresch 
<paolo.fres...@gmail.com<mailto:paolo.fres...@gmail.com>> wrote:
Thank you Jack,

so far the method we have found to fix this issue works as long as we keep the 
roach up, thus the undriven-SPI do not bother us that much. I had a look at the 
verilog hdl, I am quite use to verilog and SPI (I did something similar for an 
I2C interface) but I can't say the same for OPB bus, power-pc's and so on... it 
will take me a while I guess. I will contact you when I will be on it.
Cheers,
Paolo

2018-02-20 19:57 GMT+01:00 Jack Hickish 
<jackhick...@gmail.com<mailto:jackhick...@gmail.com>>:
Hi Paolo,

If I'm reading the code correctly -- 
https://github.com/casper-astro/mlib_devel/blob/roach2/xps_library/%40xps_adc_mkid/xps_adc_mkid.m
 -- I believe that none of the SPI pins are driven. I have no idea whether any 
of these pins are pulled in any particular direction on the hardware since I 
haven't checked the schematics.

I don't think there is a ready-to-use PPC<->SPI block, but there should be a 
variety of examples of SPI interfaces for other ADCs in the library -- 
https://github.com/casper-astro/mlib_devel/blob/roach2/xps_base/XPS_ROACH_base/pcores/opb_adc5g_controller_v1_00_a/hdl/verilog/opb_adc5g_controller.v

Integrating such an interface shouldn't be that hard, though involves getting 
dirty with the toolflow. If you're sure this is your problem and want a hand, 
give me a shout and I'll try and find the time to help you do this.

Cheers
Jack

On Mon, 19 Feb 2018 at 09:36 Paolo Fresch 
<paolo.fres...@gmail.com<mailto:paolo.fres...@gmail.com>> wrote:

Dear all,



I am a technical research fellow at INFN sezione di Roma, I am experiencing 
strange issue using roach + mkid DAC/ADC 
board<https://static1.squarespace.com/static/59c075f56f4ca3a44435bdb9/t/59f4e9ae24a694055a5761ad/1509222838779/MKID_DAC_ADC_brief.pdf>
 .



Basically, after a “cold” startup the DAC does not generate the correct 
sinusoid but either nothing or something senseless. I have a bit of hardware 
background especially in serial chip-to-chip buses, I think it is a problem due 
to the SPI DAC configuration bus that should be tied to Virtex-6. In fact, if I 
“touch” the SPI connector on the DAC/ADC board the DAC starts to output the 
correct signal.



Since no pcore is connected to these pin (and matlab prompt a warning while 
compiling using casper_xps toolchain) I think this strange behavior is caused 
by the undriven pin (at least the spi_resetn) on Virtex side.



Can you confirm that these pins are undriven in the last update of the yellow 
block present in the casper mlib_devel ? There is any block in the casper 
xps_base or xps_library I can use to interface the PPC with the SPI? Do I need 
to design this block from scratch?



Can you help me on this?



Thank you in advance.



BR,

Paolo Fresch
--
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu>" group.
To unsubscribe from this group and stop receiving

Re: [casper] dac mkid spi problem

2018-02-22 Thread Jack Hickish
Hi Paolo,

OK, let me know!

Jack

On Thu, 22 Feb 2018 at 08:14 Paolo Fresch  wrote:

> Thank you Jack,
>
> so far the method we have found to fix this issue works as long as we keep
> the roach up, thus the undriven-SPI do not bother us that much. I had a
> look at the verilog hdl, I am quite use to verilog and SPI (I did something
> similar for an I2C interface) but I can't say the same for OPB bus,
> power-pc's and so on... it will take me a while I guess. I will contact you
> when I will be on it.
>
> Cheers,
> Paolo
>
> 2018-02-20 19:57 GMT+01:00 Jack Hickish :
>
>> Hi Paolo,
>>
>> If I'm reading the code correctly --
>> https://github.com/casper-astro/mlib_devel/blob/roach2/xps_library/%40xps_adc_mkid/xps_adc_mkid.m
>>  --
>> I believe that none of the SPI pins are driven. I have no idea whether any
>> of these pins are pulled in any particular direction on the hardware since
>> I haven't checked the schematics.
>>
>> I don't think there is a ready-to-use PPC<->SPI block, but there should
>> be a variety of examples of SPI interfaces for other ADCs in the library --
>> https://github.com/casper-astro/mlib_devel/blob/roach2/xps_base/XPS_ROACH_base/pcores/opb_adc5g_controller_v1_00_a/hdl/verilog/opb_adc5g_controller.v
>>
>> Integrating such an interface shouldn't be that hard, though involves
>> getting dirty with the toolflow. If you're sure this is your problem and
>> want a hand, give me a shout and I'll try and find the time to help you do
>> this.
>>
>> Cheers
>> Jack
>>
>> On Mon, 19 Feb 2018 at 09:36 Paolo Fresch 
>> wrote:
>>
>>> Dear all,
>>>
>>>
>>>
>>> I am a technical research fellow at INFN sezione di Roma, I am
>>> experiencing strange issue using roach + *mkid DAC/ADC board*
>>> 
>>> .
>>>
>>>
>>>
>>> Basically, after a “cold” startup the DAC does not generate the correct
>>> sinusoid but either nothing or something senseless. I have a bit of
>>> hardware background especially in serial chip-to-chip buses, I think it is
>>> a problem due to the SPI DAC configuration bus that should be tied to
>>> Virtex-6. In fact, if I “touch” the SPI connector on the DAC/ADC board the
>>> DAC starts to output the correct signal.
>>>
>>>
>>>
>>> Since no pcore is connected to these pin (and matlab prompt a warning
>>> while compiling using casper_xps toolchain) I think this strange behavior
>>> is caused by the undriven pin (at least the spi_resetn) on Virtex side.
>>>
>>>
>>>
>>> Can you confirm that these pins are undriven in the last update of the
>>> yellow block present in the casper mlib_devel ? There is any block in the
>>> casper xps_base or xps_library I can use to interface the PPC with the SPI?
>>> Do I need to design this block from scratch?
>>>
>>>
>>>
>>> Can you help me on this?
>>>
>>>
>>>
>>> Thank you in advance.
>>>
>>>
>>>
>>> BR,
>>>
>>> Paolo Fresch
>>>
>>> --
>>> 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 post to this group, send email to casper@lists.berkeley.edu.
>>>
>> --
>> 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 post to this group, send email to casper@lists.berkeley.edu.
>>
>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

-- 
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 post to this group, send email to casper@lists.berkeley.edu.


Re: [casper] dac mkid spi problem

2018-02-22 Thread Paolo Fresch
Thank you Jack,

so far the method we have found to fix this issue works as long as we keep
the roach up, thus the undriven-SPI do not bother us that much. I had a
look at the verilog hdl, I am quite use to verilog and SPI (I did something
similar for an I2C interface) but I can't say the same for OPB bus,
power-pc's and so on... it will take me a while I guess. I will contact you
when I will be on it.

Cheers,
Paolo

2018-02-20 19:57 GMT+01:00 Jack Hickish :

> Hi Paolo,
>
> If I'm reading the code correctly -- https://github.com/casper-
> astro/mlib_devel/blob/roach2/xps_library/%40xps_adc_mkid/xps_adc_mkid.m --
> I believe that none of the SPI pins are driven. I have no idea whether any
> of these pins are pulled in any particular direction on the hardware since
> I haven't checked the schematics.
>
> I don't think there is a ready-to-use PPC<->SPI block, but there should be
> a variety of examples of SPI interfaces for other ADCs in the library --
> https://github.com/casper-astro/mlib_devel/blob/roach2/
> xps_base/XPS_ROACH_base/pcores/opb_adc5g_controller_
> v1_00_a/hdl/verilog/opb_adc5g_controller.v
>
> Integrating such an interface shouldn't be that hard, though involves
> getting dirty with the toolflow. If you're sure this is your problem and
> want a hand, give me a shout and I'll try and find the time to help you do
> this.
>
> Cheers
> Jack
>
> On Mon, 19 Feb 2018 at 09:36 Paolo Fresch  wrote:
>
>> Dear all,
>>
>>
>>
>> I am a technical research fellow at INFN sezione di Roma, I am
>> experiencing strange issue using roach + *mkid DAC/ADC board*
>> 
>> .
>>
>>
>>
>> Basically, after a “cold” startup the DAC does not generate the correct
>> sinusoid but either nothing or something senseless. I have a bit of
>> hardware background especially in serial chip-to-chip buses, I think it is
>> a problem due to the SPI DAC configuration bus that should be tied to
>> Virtex-6. In fact, if I “touch” the SPI connector on the DAC/ADC board the
>> DAC starts to output the correct signal.
>>
>>
>>
>> Since no pcore is connected to these pin (and matlab prompt a warning
>> while compiling using casper_xps toolchain) I think this strange behavior
>> is caused by the undriven pin (at least the spi_resetn) on Virtex side.
>>
>>
>>
>> Can you confirm that these pins are undriven in the last update of the
>> yellow block present in the casper mlib_devel ? There is any block in the
>> casper xps_base or xps_library I can use to interface the PPC with the SPI?
>> Do I need to design this block from scratch?
>>
>>
>>
>> Can you help me on this?
>>
>>
>>
>> Thank you in advance.
>>
>>
>>
>> BR,
>>
>> Paolo Fresch
>>
>> --
>> 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 post to this group, send email to casper@lists.berkeley.edu.
>>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

-- 
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 post to this group, send email to casper@lists.berkeley.edu.


Re: [casper] dac mkid spi problem

2018-02-20 Thread Jack Hickish
Hi Paolo,

If I'm reading the code correctly --
https://github.com/casper-astro/mlib_devel/blob/roach2/xps_library/%40xps_adc_mkid/xps_adc_mkid.m
--
I believe that none of the SPI pins are driven. I have no idea whether any
of these pins are pulled in any particular direction on the hardware since
I haven't checked the schematics.

I don't think there is a ready-to-use PPC<->SPI block, but there should be
a variety of examples of SPI interfaces for other ADCs in the library --
https://github.com/casper-astro/mlib_devel/blob/roach2/xps_base/XPS_ROACH_base/pcores/opb_adc5g_controller_v1_00_a/hdl/verilog/opb_adc5g_controller.v

Integrating such an interface shouldn't be that hard, though involves
getting dirty with the toolflow. If you're sure this is your problem and
want a hand, give me a shout and I'll try and find the time to help you do
this.

Cheers
Jack

On Mon, 19 Feb 2018 at 09:36 Paolo Fresch  wrote:

> Dear all,
>
>
>
> I am a technical research fellow at INFN sezione di Roma, I am
> experiencing strange issue using roach + *mkid DAC/ADC board*
> 
> .
>
>
>
> Basically, after a “cold” startup the DAC does not generate the correct
> sinusoid but either nothing or something senseless. I have a bit of
> hardware background especially in serial chip-to-chip buses, I think it is
> a problem due to the SPI DAC configuration bus that should be tied to
> Virtex-6. In fact, if I “touch” the SPI connector on the DAC/ADC board the
> DAC starts to output the correct signal.
>
>
>
> Since no pcore is connected to these pin (and matlab prompt a warning
> while compiling using casper_xps toolchain) I think this strange behavior
> is caused by the undriven pin (at least the spi_resetn) on Virtex side.
>
>
>
> Can you confirm that these pins are undriven in the last update of the
> yellow block present in the casper mlib_devel ? There is any block in the
> casper xps_base or xps_library I can use to interface the PPC with the SPI?
> Do I need to design this block from scratch?
>
>
>
> Can you help me on this?
>
>
>
> Thank you in advance.
>
>
>
> BR,
>
> Paolo Fresch
>
> --
> 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 post to this group, send email to casper@lists.berkeley.edu.
>

-- 
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 post to this group, send email to casper@lists.berkeley.edu.