Error building for Panologic platform ( Spartan 6 xc6slx150)

[skiphansen]

The BUFGMUX instance in gmii.py creates generates the following error when build for the Panologic-g2 platform base on a Spartan 6 xc6slx150. The error message is:

---

ERROR: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 <eth_clocks_rx> is placed at site . The corresponding
BUFG component <eth_rx_clk_BUFG> is placed at site <BUFGMUX_X3Y5>. 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 "eth_clocks_rx" CLOCK_DEDICATED_ROUTE = FALSE; >

After a LOT of study of Table 1-2: Shared Global Clocking Resources for Bank 2 and Bank 3" in ug382.pdf I've concluded (rightly for wrongly) that with eth_clocks_rx on GCLK_28 and eth_clocks_tx on GCLK_29 this is indeed unroutable.

I was able to get liteeth to work by replacing the BUFGMUX with simple combinational logic, but I'm not confident of my fix even thou "it seems to work".

My changes can be found here: https://github.com/skiphansen/liteeth/tree/pano_fixes.

[enjoy-digital]

@skiphansen: i started testing ethernet on the Pano Logic G2: litex-hub/litex-boards@2f3817c
The integration i did builds but does not seem to be working, can you give me a link to your working platform/target to do some checks?

[skiphansen]

@enjoy-digital Sure!

You can find liteth with my kludge for the Pano here: https://github.com/skiphansen/liteeth (pano_fixes branch).

My fork of litex-buildenv that uses my patched repository is here: https://github.com/skiphansen/litex-buildenv (pano_master branch)

My top level Linux project is here: https://github.com/skiphansen/panog2_linux.

Since I added a BUFG on eth_tx.clk my kludge seems to route and work every time, but I've done zero timing analysis.

[enjoy-digital]

@skiphansen: thanks, i've been able to get it working. I mostly integrated your solution with 0feed17 and tested it with:
https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/pano_logic_g2.py
and the following command:
./pano_logic_g2.py --uart-name=crossover --with-etherbone --build --load
And verified the board was responding to ping on 192.168.1.50.

Can you check this is also working in your design?

[skiphansen]

@enjoy-digital Thanks, I'll test it today!

[skiphansen]

@enjoy-digital I've verified that a straight litex-hub/litex-boards build works fine.

I modified my code to give control of the Phy reset to liteeth and everything built w/o a problem, however it doesn't run. I don't get any serial output from the BIOS and the Ethernet PHY is never initialized (at least I don't get the usual link status LEDs). If I comment out "self.comb += pads.rst_n.eq(~reset)" in gmii.py and drive rst_n high elsewhere then Linux boots and the Ethernet works.

I don't understand this behavior. As far as I know the Phy always generates a clock, just at a different frequency when the PHY is in reset. I was worried about the system clock changing frequencies when the PHY was reset causing serial port baud rate issues, but I didn't expect this.

[skiphansen]

@enjoy-digital I hooked up my scope and I see a 25 Mhz clock coming out of the Phy. I have a theory of what the problem might be: The PLL that generates the system clock's can't lock to the 25 Mhz input clock so the system reset is never released.
# System clock - 50MHz self.specials += Instance("BUFG", name="sys_bufg", i_I=unbuf_sys, o_O=self.cd_sys.clk) self.comb += self.cd_por.clk.eq(self.cd_sys.clk) self.specials += AsyncResetSynchronizer(self.cd_sys, ~pll_lckd | (por > 0))

[enjoy-digital]

@skiphansen: in you code, are you setting with_hw_init_reset = False: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/pano_logic_g2.py#L59

[skiphansen]

@enjoy-digital No I am not, I'll give that a try and let you know. Thanks!

[skiphansen]

When I added with_hw_init_reset = False I get an infinite reset loop (The complete BIOS login banner is over and over, looping after "ROM: 32KB").

If I define rst_n to as an LED pin rather than the actual PHY reset then everything works.

This makes no sense to me.

Here's my the code I tested:

    def __init__(self, platform, *args, **kwargs):
        BaseSoC.__init__(self, platform, *args, **kwargs)

        sys_clk_freq = int(125e6)
        # Ethernet MAC
        self.submodules.ethphy = LiteEthPHY(
            clock_pads         = self.platform.request("eth_clocks"),
            pads               = self.platform.request("eth"),
            clk_freq           = sys_clk_freq,
            with_hw_init_reset = False)
        self.add_csr("ethphy")
        self.add_ethernet(phy=self.ethphy)

[enjoy-digital]

@skiphansen: since we are using the clock from the PHY as a clock source for the system on the Pano Logic, the behaviour is probably caused by the CPU reseting the PHY while initializing ethernet. In my design i'm not sure i was using a CPU, so this could explain why it was working. Can you try commenting out the rst_n pin in the platform?

[skiphansen]

I get an undefined error if I comment out rst_n.

Traceback (most recent call last):
File "./make.py", line 169, in
main()
File "./make.py", line 123, in main
soc = get_soc(args, platform)
File "./make.py", line 57, in get_soc
soc = SoC(platform, ident=SoC.name, **soc_sdram_argdict(args), **dict(args.target_option))
File "/home/skip/pano/working/panog2_linux/litex-buildenv/targets/pano_logic_g2/net.py", line 24, in init
with_hw_init_reset = False)
File "/home/skip/pano/working/panog2_linux/litex-buildenv/third_party/liteeth/liteeth/phy/init.py", line 10, in LiteEthPHY
return LiteEthPHYGMIIMII(clock_pads, pads, clk_freq=clk_freq, **kwargs)
File "/home/skip/pano/working/panog2_linux/litex-buildenv/third_party/liteeth/liteeth/phy/gmii_mii.py", line 181, in init
self.submodules.crg = LiteEthPHYGMIICRG(clock_pads, pads, with_hw_init_reset, mode == modes["MII"])
File "/home/skip/pano/working/panog2_linux/litex-buildenv/third_party/liteeth/liteeth/phy/gmii.py", line 84, in init
self.comb += pads.rst_n.eq(~reset)
AttributeError: 'Record' object has no attribute 'rst_n'

[enjoy-digital]

With 291b257 rst_n is now an optional signal for all LiteEth PHYs. I woiuld then recommend commenting it out in the Platform definition for the Panologic due to the specific clocking.