Trim Unwanted logic from Xilinx IP

[rakeshm55]

Hi,
Is it possible to remove unwanted logic from Xilinx IP?? If so what is the design flow or at which state I can do that. How to do this??
Even if its trial and error approach I can try.


Example use case:
Ethernet Lite IP from Xilinx . Lets say I want  only transmit data logic in place. so receive data logic in IP when realized in FPGA remains as dead logic.

[asmi]

The short answer is no. The longer one is - implementation is very good at removing truly dead logic already - not the logic *you think* is dead, but the one that is actually dead and it can be mathematically proved to never affect outputs.
Specifically for Ethernet you can't really use it in a regular network without receiving anything, at the very least you will need ARP response to find out physical addresses of other nodes and your primary gateway. Also it is required for TCP protocol.

[cruff]

Broadcast only UDP would not require reception of packets, or other broadcast only protocols that run over the Ethernet physical layer might not require it either. However, if you needed to uniquely identify nodes with dynamically generated addresses, you would need some sort of in use detection, which is where ARP comes in the IP world, or static configuration.

[rakeshm55]

Hi,
I happen to come across this article.

""For example, the PCI express core – while extremely configurable and well-vetted – has no way to turn off the AXI slave bridge, even if you’re not using the interface. Even with the inputs unconnected or tied to ground, the logic optimizer won’t remove the unused gates. Unfortunately, this piece of dead logic consumes around 20% of my target FPGA’s capacity. I could only reclaim that space by hand-editing the machine-generated VHDL to comment out the slave bridge. It’s a simple enough thing to do, and it had no negative effects on the core’s functionality.""
..........https://www.bunniestudios.com/blog/?p=5018

So thought of attempting the same once procedure is clear.

Specifically for Ethernet you can't really use it in a regular network without receiving anything, at the very least you will need ARP response to find out physical addresses of other nodes and your primary gateway. Also it is required for TCP protocol.

Regarding Ethernet its true but in my case I used it for raw socket point to point link. Even for Axi Bus with separate Tx and Rx port i could not implement true Full duplex with one Axi ethernet lite core using burst transfer. I resolved it by invoking two Axi ethernet cores with with Tx only and Rx only . Both IP cores programmed for same MAC IDs.

[SiliconWizard]

As asmi said. Truly unused logic will be pruned, but as he mentioned specifically for Ethernet, even if you don't explicitely use "receive", at least a significant part of it will still be used for normal transmission.

But if you're not actually using some part of some IP and this part is actually never used by other parts of the IP, it will usually get pruned without you having anything special to do.

A simple example would be instantiating a memory IP of some kind - say a true dual port memory: if you're not using one of the ports, or if you're only using read or write for one port (logic "write enable" tied to a fixed level for instance), then the synthesizer will definitely prune some part of the required logic by itself.

[asmi]

Regarding Ethernet its true but in my case I used it for raw socket point to point link. Even for Axi Bus with separate Tx and Rx port i could not implement true Full duplex with one Axi ethernet lite core using burst transfer. I resolved it by invoking two Axi ethernet cores with with Tx only and Rx only . Both IP cores programmed for same MAC IDs.

If that's truly the case, why don't you simply design your own MAC? It's not that hard, especially if you know in advance what mode your network is going to function in (10 or 100 Mbit, full or half-duplex). TX path of MAC doesn't really do much beyond wrapping the packet into Ethernet II frame, possibly calculating the checksum and sending it to PHY via some sort of MII. If you don't feel like designing an AXI bus master so that your IP would pull the packet straight from memory, you can use Xilinx's AXI DMA IP to handle all that for you, and give you the data via AXI Stream bus, which is about as simple as it gets (ready/valid for handshake, tdata for, well, data, and tlast to mark the last chunk of the packet). Incidentally, this is how Xilinx paid TriMAC IP works - it uses DMA IP to handle scatter-gather for it, and gives/accepts data via two AXI Stream channels.

[ejeffrey]

There is a big difference between logic that has no effect on your design and logic you don't care about.  A simple example is that if your ethernet IP has a packet counter field that will be enough to keep most of the receive channel intact even if you don't hook the data up to anything.

OTOH it's also not always easy to separate.  There can also be arbitration logic or collision detection logic that needs the receive data path to function properly.  Even if you don't care about receiving it might be necessary for the module to function properly.

I agree it's pretty simple to just implement yourself if you want this sort of specialization.  A minimal ethernet interface is pretty small -- probably a fair bit smaller than you would get just by disabling the receive data path in the Xilinx implementation.

[voltsandjolts]

FYI forum member @hamster_nz has implemented UDP transmit-only:

https://github.com/hamsternz/ArtyEtherentTX
https://github.com/hamsternz/FPGA_GigabitTx