Topic: CTRL and DCO signal errors in ucf file  (Read 11879 times)

vicmarher July 23, 2013, 07:27 AM

  • Member
  • *
  • Posts: 43
Hi all.
I hope you can help us once more! ;)


We are trying to use the SIP generated code to integrate it in our vhdl design. We are trying to use the FMC116 as an AMBA compliant IP-CORE, to be accessed from our RTEMS application running in our LEON3 soft-core.


When we try to compile our project, this error rises for all the DCO signals:



ERROR:Pack:2908 - The I/O component "dco_n_0(0)" has an illegal IOSTANDARD
[/size][/color]value.  The IOB component is configured to use single-ended signaling and can[/font]

[/size][/color]   not use differential IOSTANDARD value LVDS_25.  Two ways to rectify this[/font]
[/size][/color]   issue are: 1) Change the IOSTANDARD value to a single-ended standard. 2)[/font]
[/size][/color]   Correct the I/O connectivity by instantiating a differential I/O buffer.[/font]


It seems that the problem is to use IOSTANDARD LVDS_25, a differential type, instead of using as IOSTANDARD LVCMOS25.


So we've updated the FMC116 provided UCF file changing the lines :



NET "DCO_N_0<0>" LOC="AF21" |IOSTANDARD = "LVDS_25" |DIFF_TERM = TRUE;
by
NET "DCO_N_0<0>" LOC="AF21" |IOSTANDARD = "LVCMOS25" ;


Is that correct? Do we have to create a iobuffer? ([/size][size=78%]http://www.xilinx.com/support/answers/34993.htm[/size][size=78%])[/size]


About the CTRL_0 signal, we have the following warnings for all the pins:



[/color]
WARNING:ConstraintSystem:119 - Constraint <NET "ctrl_0[0]" LOC = AJ24;>[/color][/size]   [leon3mp.ucf(336)]: This constraint cannot be distributed from the design[/size]   objects matching 'NET "ctrl_0[0]"' because those design objects do not[/size]   contain or drive any instances of the correct type.



[/size]
WARNING:ConstraintSystem - A target design object for the Locate constraint[/size][/color]   '<NET "ctrl_0[0]" LOC = AJ24;> [leon3mp.ucf(336)]' could not be found and so[/color]   the Locate constraint will be removed.


Maybe it's because we are not really using by now this signal? (by now we are just trying to instantiate our black-box wrapper).


Thanks a lot!!


Víctor Martín, IEEC







ebarhorst July 23, 2013, 05:45 PM (#1)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Hi


The IO standard in the UCF should match the buffer instantiated in the VHDL. The refence design works in combination with the suplied UCF. Did you change the FMC116 VHDL sources?


You mention black box? I would expect ISE to not go past the NGBUILD stage if it cannot find the FMC116 logic.


Best regards,


Erik

vicmarher July 24, 2013, 12:25 PM (#2)

  • Member
  • *
  • Posts: 43
Hi Erik.
Thanks for your reply.
First, I'll try to explain you better what we are trying to do for you to understand better my question. Off course it's important to tell that this is our first FPGA project, so there are lot of basic concepts that we don't already know.


We have a Xilinx ml605 dev board, and now we've plugged a FMC116. In our FPGA, we have a LEON3 soft-core, and a RTEMS application running, that communicates through ethernet with a host PC. In our application we have several routines implemented that we need, and now we need to access to the samples provided by 4DSP FMC116.


To do that (and maybe here is the first mistake), what we are trying to do, is to create an IP-CORE AMBA compliant to be accessible by our RTEMS application. This IP would only be a wrapper connecting I/O signals of the carrier board, to I/O signals of FMC116 board. And inside our IP, this signals would be routed to an instance of the generated Stellar IP vhdl code (off course without the ethernet star, receiving the commands through our application).


This way, we treat the SIP project as a black box, and that's why I used "black box" in the previous topic.


By now, we have just merged the ucf constraints provided by FMC116ml605 reference design with the ucf constraints of our leon3mp project. We have created a dummy IP-CORE AMBA compliant, checked that it works, and then, we have just tried to add the FMC116 signals to the main entity, and pass them to our IP-CORE. We still have not used any of the SIP generated code.


And doing so, is how we get the errors that I send in the previous topic.


After further tests, we've tried to use IBUFGDS for the DCO signal, in order to have a single-ended signal for the FPGA to work, created by the two differential pins of the original DCO signal.



signal dco_se : std_logic_vector ( 3 downto 0);--Single ended DCO signal after IBUFDS



single_ended_dco: for idx in 0 to 3 generate

    ibufgds_dco : ibufgds
      generic map (
        IOSTANDARD => "LVDS_25",
        DIFF_TERM => TRUE
      )
      port map (
        O  => dco_se(idx),
        I  => dco_p_0(idx),
        IB => dco_n_0(idx)
      );
  end generate;



But we are still having problems. In fact, after remerging ucf files and adding missing clock constraints, and using ibufgds, the new warnings that we have are :



WARNING:ConstraintSystem:137 - Constraint <NET "DCO_P_0[0]" TNM_NET = "DCO0";>
   [leon3mp.ucf(343)]: No appropriate instances for the TNM constraint are
   driven by "dco_p_0[0]".

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC TS_DCO0 = PERIOD "DCO0" 500
   MHz HIGH 50 %;> [leon3mp.ucf(344)]: Unable to find an active 'TNM' or
   'TimeGrp' constraint named 'DCO0'.


We've checked in the vhdl generated by stellar IP if there is any ibufgds used or any other conversion for the DCO signal or for the CTRL_0 signal, but it seems that it just uses them as we tried at the beginning.


So I hope that now you understand better what we try to do, what we are trying now, and of course we all hope that you can help us solving it. Off course, if you think that the design we are trying to implement is wrong, let us know.


Thanks a lot!


Víctor Martín, IEEC





ebarhorst July 25, 2013, 04:26 AM (#3)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Hi Victor,


whenever there is signals without connection they are optimized away and the tool cannot find them anymore. These constraints are only interesting whenever you have real logic in the "black box". For now you should comment them out.




Best regards,
Erik

vicmarher July 25, 2013, 08:00 AM (#4)

  • Member
  • *
  • Posts: 43
Hi Erik,
thanks a lot!
I've modified my "black box" just to make a random logic with dco and ctrl signals, and the warnings dissapear... great!!!... although I must confess that first of all after reading your answer I didn't expect it to work, because I thought that in case of having a non used signal, the warning was kind of "is never used", as I've seen with other signals.


Anyway, what it seems to be clear, is that  I need ibufgds for the dco signals. If I compile without it, I get the errors we have already talked about.


But searching in the output folder from Stellar IP for the reference design, nothing seems to be done with dco signals in that sense. So, which is the difference? is it something about compilation flags? I've tried with "iobuf yes" for XST with same results... anyway, in case of having to use IBUFGDS, is the source code I sent you in last topic correct?


Once more, THANK YOU VERY MUCH!!!


Víctor Martín, IEEC





vicmarher July 26, 2013, 11:44 AM (#5)

  • Member
  • *
  • Posts: 43
Hi Erik!
Now I Know why in your designs I haven't been able to find a IBUFGDS for the DCO signal.
The buffer must always appear previous to any logic operation, so if you have component A, passing signal to B, this one to C, and so on, only the first one using the signal for logical operations,has to use the buffer.
In may case, being my "black box" the last one of the chain, and the first one in using the signal to do logic work, I had to add it ;)


So thanks a lot!
See you in the next topic! ;)


Víctor Martín, IEEC