uPP receive issues
Added by minh tung about 11 years ago
Hi,
I am using Upp to transfer data between FPGA and OMAP.
The data send from FPGA to OMAP is OK. But FPGA can not receive exactly data from OMAP.
FPGA has missed 2 byte from OMAP.
in FPGA design, i have used clock from OMAP to receive data and store in fifo( write and read clock are different).
I didn't used any contrains between data and clock input.
Can you give some advice to bypass this issues or give me example upp interface.
(I have follow from this instruction :http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/UPP_Design_Considerations)
Replies (4)
RE: uPP receive issues - Added by minh tung about 11 years ago
I have updated my source code
This is my *.ucf file
NET "o_upp_2xtxclk" LOC = "F4" | IOSTANDARD = LVCMOS18;
NET "io_upp_chb_clock" LOC = "T1" | IOSTANDARD = LVCMOS18;
NET "io_upp_chb_start" LOC = "T2" | IOSTANDARD = LVCMOS18 | PULLDOWN;
NET "io_upp_chb_enable" LOC = "M3" | IOSTANDARD = LVCMOS18 | PULLDOWN;
NET "io_upp_chb_wait" LOC = "P3" | IOSTANDARD = LVCMOS18 | PULLUP;
NET "io_upp_cha_clock" LOC = "H7" | IOSTANDARD = LVCMOS18;
NET "io_upp_cha_start" LOC = "C1" | IOSTANDARD = LVCMOS18 | PULLDOWN;
NET "io_upp_cha_enable" LOC = "H5" | IOSTANDARD = LVCMOS18 | PULLDOWN;
NET "io_upp_cha_wait" LOC = "L5" | IOSTANDARD = LVCMOS18;
- Littel Endian
NET "upp_core_0_i_upp_chb_d_pin<7>" LOC = "M1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<6>" LOC = "L2" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<5>" LOC = "H2" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<4>" LOC = "L1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<3>" LOC = "K2" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<2>" LOC = "H1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<1>" LOC = "K1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<0>" LOC = "J1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<15>" LOC = "F3" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<14>" LOC = "D3" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<13>" LOC = "M5" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<12>" LOC = "D2" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<11>" LOC = "E3" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<10>" LOC = "D1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<9>" LOC = "E4" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_i_upp_chb_d_pin<8>" LOC = "F1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<7>" LOC = "L4" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<6>" LOC = "H4" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<5>" LOC = "P1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<4>" LOC = "P2" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<3>" LOC = "H3" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<2>" LOC = "N1" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<1>" LOC = "N2" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<0>" LOC = "G3" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<15>" LOC = "F5" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<14>" LOC = "F6" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<13>" LOC = "G6" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<12>" LOC = "L6" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<11>" LOC = "J6" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<10>" LOC = "H6" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<9>" LOC = "K5" | IOSTANDARD = LVCMOS18;
NET "upp_core_0_o_upp_cha_d_pin<8>" LOC = "L7" | IOSTANDARD = LVCMOS18;
RE: uPP receive issues - Added by Michael Williamson about 11 years ago
Do you know which two byes you are missing? Are they consistently the same two bytes?
Do you have a chipscope license?
RE: uPP receive issues - Added by minh tung about 11 years ago
I have resolve that problems. Maybe I was wrong to select uPP clock sources (PLL1_SYSCLK2).
But, when my FPGA sytem is bigger. I have an other bugs when mapping the logic.
Place:1108 - A clock IOB / BUFGMUX clock component pair have been found that are not placed at an optimal clock
IOB / BUFGMUX site pair. The clock IOB component <io_upp_chb_clock> is placed at site <PAD296>. The corresponding
BUFG component <io_upp_chb_clock_BUFGP/BUFG> is placed at site <BUFGMUX_X2Y11>. There is only a select set of IOBs
that can use the fast path to the Clocker buffer, and they are not being used. You may want to analyze why this
problem exists and correct it. If this sub optimal condition is acceptable for this design, you may use the
CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING and allow your design to
continue. However, the use of this override is highly discouraged as it may lead to very poor timing results. It is
recommended that this error condition be corrected in the design. A list of all the COMP.PINs used in this clock
placement rule is listed below. These examples can be used directly in the .ucf file to override this clock rule.
< NET "io_upp_chb_clock" CLOCK_DEDICATED_ROUTE = FALSE; >
Maybe, the reasons is that the io_upp_chb_clock pin is not come from GCLK pin.
I have no chipscope license.
RE: uPP receive issues - Added by Michael Williamson about 11 years ago
Yes, this is the issue. The pin-muxed OMAP-L138 net that includes the UPP_CHB_CLOCK is not connected to a GCLK pin. We didn't have the routing resources (or the clock pins) to connect every possible clock pin on the OMAP-L138 to a GCLK pin on the FPGA.
As the message says, you can force the placer to use the assignment anyway with the constraint mentioned above.
We have done this on several designs and in all cases have been able to close timings. The SDR max frequency for the UPP clock is only 75 MHz, so the routing skew from a non-clock pin to a clock net is usually very small compared to the overall period and pad to clock requirements.
-Mike
