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_<yellow block name>/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) < [email protected]> 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:[email protected]] > *Sent:* Thursday, February 22, 2018 9:25 AM > *To:* [email protected] > > > *Subject:* Re: [casper] dac mkid spi problem > > > > Hi Paolo, > > > > OK, let me know! > > > > Jack > > > > On Thu, 22 Feb 2018 at 08:14 Paolo Fresch <[email protected]> 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 <[email protected]>: > > 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 <[email protected]> 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 " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > > > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
