Topic: FMC151 ref. design in Vivado  (Read 23359 times)

tedjnsn November 12, 2014, 01:59 PM (#15)

  • Member
  • *
  • Posts: 47
Luis,


Thanks for clarification.


I have few more questions related to reference design:


- Are dac_clock and dac_data outputs programmed to change simultaneously, i.e. with zero setup time? That's how code looks to me.
- looking at dac3283 datasheet, the minimal setup time is NEGATIVE 25 ps. Do I understand it correct that dac_data can be settling for up to 25 AFTER dac_clock transition, which would clarify the above question I have as well?
- Ref. design is set to output dac_data at 122.88 MSPS, while reading ADC data at twice that rate. Are there any particular technical limitations in the hardware or reference firmware I should be aware of if I am to double the dac_data sample rate to match ADC rate?





lmunoz November 12, 2014, 07:04 PM (#16)

  • Member
  • *
  • Posts: 160
- Are dac_clock and dac_data outputs programmed to change simultaneously, i.e. with zero setup time? That's how code looks to me.

Yes that is what it looks like to me as well. This is just a reference design so if it works then it is considered good.

- looking at dac3283 datasheet, the minimal setup time is NEGATIVE 25 ps. Do I understand it correct that dac_data can be settling for up to 25 AFTER dac_clock transition, which would clarify the above question I have as well?

You have these two times :

START_TIME = CLOCK_EDGE_TIME - SETUP_TIME = 0 - (-25) = 25 ps
END_TIME    = CLOCK_EDGE_TIME + HOLD_TIME =  0 + (375) = 375 ps

Since the data is not changing within that window it works. The negative is good it means that the window starts after the clock edge.


- Ref. design is set to output dac_data at 122.88 MSPS, while reading ADC data at twice that rate. Are there any particular technical limitations in the hardware or reference firmware I should be aware of if I am to double the dac_data sample rate to match ADC rate?

Not that I am aware of.
  • « Last Edit: November 12, 2014, 07:16 PM by lmunoz »

arnaudNL November 17, 2014, 09:12 AM (#17)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Sir,


I see that Luis took the extra miles to help you out, thanks for that Luis!


I assume we are good to close this topic for now?


Thanks,
Arnaud

tedjnsn November 17, 2014, 12:08 PM (#18)

  • Member
  • *
  • Posts: 47
Yes, you can close the topic. Thanks for all the info on reference design.

tedjnsn November 17, 2014, 01:22 PM (#19)

  • Member
  • *
  • Posts: 47
Just to update - the ref design seems to work fine in Vivado 2014.3 after doubling txclck* rates in dac3283phy.


I also assigned ASYNC_REG attributes to some signals in pulse2pulse module, that seems to help with closing SPI-related timing.  Is that correct approach?

lmunoz November 17, 2014, 05:23 PM (#20)

  • Member
  • *
  • Posts: 160

Yeah. For clock domain crossing generally use set_false_path so the tools don't waste time trying to meeting timing on something that it shouldn't worry about. That would look like this:

# Generated clock used for SPI interface (system clock divided by 16)
create_generated_clock -name spi_clk -source [get_pins sip_fmc144_0/spi_wrapper_inst0/sclk_prebuf_reg/C] \
                                        -divide_by 16 [get_pins sip_fmc144_0/spi_wrapper_inst0/sclk_prebuf_reg/Q]

set_false_path -from [get_clocks spi_clk] -to [get_clocks clk_out2_ethernet_clock]
set_false_path -from [get_clocks clk_out2_ethernet_clock] -to [get_clocks spi_clk]

tedjnsn November 17, 2014, 09:31 PM (#21)

  • Member
  • *
  • Posts: 47
Thanks Luis. I basically did the same with the timing constraints that I posted above. I just used set_clock_groups -asynchronous in place of set_false_path, perhaps not separating every SPI clock domain into its own group, but async_reg seems to take care of other CDCs.


In any case, I got the ref design to work in Vivado with your help and the subject can be closed. 




arnaudNL November 18, 2014, 09:45 AM (#22)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
This topic is being closed because the issue is considered as resolved by 4DSP. Feel free to create a new topic for any further inquiries.