Patent Description:
Increasingly in automotive and industrial applications, software running on a system-on-a-chip (SoC) or a microcontroller (MCU) use different, dedicated processing paths to exchange data over communications networks, such as Ethernet and controller area network (CAN) networks.

Hardware-implemented filters can be used to check parameters in incoming data received from communication network interfaces to allow a target in the SoC or MCU (such as a CPU) to know what to do with the incoming data. For instance, in Ethernet and CAN frames, such parameters include identifiers (in particular, stream ID or CAN ID), addresses (for example, destination address), message types and higher layer protocol fields (such as IPv4).

Hardware-implemented filters can be implemented in several, different ways.

A memory- or register-based filter can be used to determine whether incoming data matches a filter criterion. A filter criterion may be a pattern (such as a field in a header), a masked pattern, a range or a combination thereof. The filter criterion may take the form of a value stored in memory or register(s) which may be programmed.

A series of filters can be used to process incoming data. Thus, a first filter can be used to perform filtering based on a first criterion, then a second filter can be used to carry out filtering based on a second criterion and so on. This approach is suitable for protocols having a comparatively low event rate, such as CAN, where the interval between events is greater than <NUM>.

Filters, however, can be arranged in parallel using (hardware) registers, Ternary Content Address Memory (TCAM) or hash tables. A parallel approach usually provides a result much faster than a sequential approach and therefore suits protocols with higher event rates, where the interval between events is less than <NUM>, and/or implementations where several data interfaces use the same pool of filters.

Filtering is usually customised for a particular protocol and use case.

For example, in CAN, filtering is mainly done using only media access control layer fields. In Ethernet applications, filtering can also employ only MAC layer fields, but in more sophisticated applications can use higher-level protocols, such as IP protocol.

Use of parallel filter arrangements and deeper forms of filtering comes at a cost. For example, deeper forms of filtering increases complexity of filters in terms of the number of fields use, their variations and depth. Moreover, complex filter arrangements tend to have a large silicon footprint and consume a large amount of power.

<CIT> describes a packet classification apparatus including a rule memory and a criterion memory. One type of rule memory entry contains an operator and a pointer to a criterion memory entry. The operator defines a comparison operation to be performed, such as EQUAL (exact match) or LESS THAN. The criterion memory entry contains one or more values to be used as comparands on one side of the comparison, where corresponding values from a received packet appear on the other side of the comparison. Control logic responds to packet classification requests to retrieve a rule memory entry from the rule memory, retrieve the criterion memory entry identified by the criterion memory pointer in the rule memory entry, and perform the operation specified by the operator in the rule memory entry on the values in the criterion memory entry and corresponding values included in the classification request. This procedure is repeated for a sequence of rule memory entries until an ending condition is encountered, whereupon a packet classification result is generated reflecting the result of the classification operations. This result is provided to a packet processor to take the appropriate action based on the classification result.

<CIT> describes a system and a method for filtering a plurality of frames sent between devices coupled to a fabric by Fiber Channel connections. Frames are reviewed against a set of individual frame filters. Each frame filter is associated with an action, and actions selected by filter matches are prioritized. Groups of devices are "zoned" together and frame filtering ensures that restrictions placed upon communications between devices within the same zone are enforced. Zone group filtering is also used to prevent devices not within the same zone from communicating. Zoning may also be used to create LUN-level zones, protocol zones, and access control zones. In addition, individual frame filters may be created that reference selected portions of frame header or frame payload fields.

According to a first aspect of the present invention there is provided a circuit for use in frame filtering. The circuit comprises a plurality of comparator units. Each comparator unit is configured, in response to receiving at least a part of a data frame, to perform a determination whether data in a portion of the data frame matches respective reference data and to provide a result to a comparator unit output based on the determination. The circuit comprises a crossbar switch having crossbar inputs coupled to respective comparator unit outputs and configured to provide sets of crossbar switch outputs via configurable interconnects. The circuit comprises a set of result-combining logic units, each result-combining logic unit coupled to a respective set of crossbar switch outputs and to provide a logic unit output (or "matching output"). At least one result-combining logic output is configurably provided as a crossbar input.

The circuit can be used to help classify and, thus, filter frames with greater flexibility, which makes better use of resources, and which is easier to adapt to different applications. In addition, by providing a logic output as a crossbar input, results can be re-used.

The configurable interconnects may be provided by multiplexers. At least one crossbar input may be configurably (or "re-configurably" or "selectably", for example, programmably) provided to at least two of the result-combining logic units. Thus, a result of a comparison can be used more than once. The plurality of comparator units may comprise a plurality of configurable comparator units operable in at least first and second modes which are selectable, wherein, in the first mode, the data portion is maskable with a mask. The plurality of configurable comparator units may be operable to receive two sets of reference data and to perform the determination using both sets of reference data. The two sets of data may be concatenated. At least some of the plurality of comparator units may be arranged to apply an offset so as to select the portion of the data frame to be used in the determination. At least some of the plurality of comparator units may comprise one or more finite state machines for processing a comparison of the portion of the data with reference data. The comparator units may comprise at least one block comparator unit configured to compare the portion of the data frame with B sets of reference data, where B is a positive non-zero integer which is greater than or equal to <NUM>, for example, between <NUM> and <NUM>. B may take values of <NUM>n where n is a positive non-zero integer (for example, B may be <NUM>, <NUM>, <NUM> and <NUM>) for identifying up to B matches and/or <NUM>n-<NUM> (for instance, B may be <NUM>, <NUM>, <NUM> or <NUM>) for identifying up to B-<NUM> matches and a no match. The result-combining logic units may be or include AND gates. The result-combining logic units may be or include OR gates, for instance, to identify presence of one of several matches (such as one of several IP addresses).

The plurality of comparator units may include configurable comparator units (capable of being re-configured), pre-configured comparator units and/or block comparators units. For example, the plurality of comparator units may only include configurable comparator units. Comparator units may be configured to handle data (i.e., perform matching) in different sizes of blocks, such as <NUM> bytes, <NUM> bytes or <NUM> bytes. For each type of comparator unit (e.g., configurable comparator units), there may be a first set of comparator units configured to handle data of a first block size, such as <NUM> bytes, a second set of comparator units configured to handle data of a second, different block size, such as <NUM> bytes, and, further optionally, a third set of comparator units configured to handle data of a third, different block size, such as <NUM> bytes. There may be more configurable comparator units than pre-configured comparator and/or block comparators units.

According to a second aspect of the present invention there is provided a classifier comprising the circuit of the first aspect and a priority select arranged to receive logic unit outputs from the circuit and to generate a classification number in dependence on the logic unit outputs.

According to a third aspect of the present invention there is provided a filter comprising the circuit of the first aspect or the classifier of the second aspect, and an actioning unit configured to process frames in dependence on the logic unit outputs and/or the classification number.

According to a fourth aspect of the present invention there is provided an integrated circuit comprising the classifier of the second aspect or the filter of the third aspect. The integrated circuit is a microcontroller, a system on a chip or an application specific integrated circuit.

According to a fifth aspect of the present invention there is provided a switch or an end station comprising the classifier of the second aspect or the filter of the third aspect.

According to a sixth aspect of the present invention there is provided a system comprising a communication gateway comprising the integrated circuit of the fifth aspect, at least one node (such as a module, electronic control unit or other computing node) in communication with the integrated circuit and the filter is arranged to receive frames from the at least one node and to process the frames according to the classification number. A node may be a powertrain module (such as, an engine electronic control unit), a chassis module (such as, a brake-by-wire electronic control unit), a body/comfort module (such as a climate control electronic control unit), a driver assistance module (such as lane-departure control unit), an infotainment module or the like. The integrated circuit may provide a switch or may provide an end station in a communication system.

According to a seventh aspect of the present invention there is provided a vehicle comprising the system of the sixth aspect which is functionally-integrated into the vehicle. The system may be used to provide communication between computing nodes within the vehicle and/or between a node in the vehicle and a node outside the vehicle (e.g., another vehicle or a node via an external communications network) The vehicle may be motor vehicle. The motor vehicle may be a motorcycle, an automobile (sometimes referred to as a "car"), a minibus, a bus, a truck or lorry. The motor vehicle may be powered by an internal combustion engine, one or more electric motors or both (i.e., "hybrid"). The vehicle may be an aircraft (or other airborne vehicle), a train, a ship (or other watercraft) or spacecraft.

Referring to <FIG>, an IEEE <NUM> frame <NUM> and a filter arrangement <NUM> for filtering frames received by a message handler in an Audio Video Bridging (AVB) end station are shown.

The IEEE <NUM> frame <NUM> includes a preamble <NUM>, a start of frame (SFD) <NUM>, an Ethernet header <NUM>, a payload <NUM> and a frame check sequence (FCS) <NUM>. The IEEE <NUM> frame header <NUM> consists of a destination address <NUM>, a source address <NUM>, a VLAN tag <NUM> and Ethernet Type <NUM>.

Filters <NUM> includes a frame-type identification block <NUM> which can inspect the destination address, VLAN tag and EtherType fields of a frame to determine whether a frame <NUM> received from the media access controller (MAC) (not shown) is an IEEE <NUM> frame <NUM> and whether it is compliant with IEEE <NUM>. The filters <NUM> can include up to <NUM> other filters <NUM> for identifying, for instance, frames with given MAC addresses. Once frames have been identified, a chain selection block <NUM> selects a corresponding chain. A chain identifier <NUM> and the frame <NUM> are passed to a direct memory access controller (DMAC) <NUM> for storing in the appropriate queue in system memory (not shown).

Different applications (i.e., different use cases) may require different filters and follow different approaches to classification. For example, in one application, a user may want to filter frames based on MAC address, VLAN and some (OSI) level <NUM> data, while in another, different application, a user may want to filter frames based on IP address and port numbers.

The AVB filter <NUM> hereinbefore described can only be used for filtering <NUM> AVB frames, and is based on stream ID. If different filtering is required, for example, based on IPv4 or IPv6 addresses or deep-package inspection, then different filters are needed.

One way in which this can be achieved is to provide a full set of filters which cover a full range of applications from which users can choose filters of interest. This, however, increases the size of the silicon footprint needed for filters as well as the number of bits used for configuring the filters.

Referring to <FIG>, for a relatively simple AVB filter <NUM>, as the number of filters increase, the number of configuration flops increases. For a more complex filter, the number of configuration flops increases significantly with the number of filters.

Referring to <FIG>, a filter arrangement <NUM> (herein also referred to simply as "filter") is shown which is flexible and configurable according to application.

The filter <NUM> can provide and/or enable flexible frame identification, flexible filter offset, multiple filter positions, flexible DMA chain mapping and/or filter results to be re-used.

Instead of using hard-coded identification, the filter <NUM> is configurable. The filter <NUM> can check one or more selectable parts of a received frame <NUM>. The filter <NUM> can perform identification distributed across an OSI-layer header (e.g., for UDP, Ethernet Type, IPv4 Address, UDP Protocol type, UDP port, and application-specific IDs in UDP payload) and multiple positions within a frame. In cases where frame identification is based only on, for example, UDP port number, filter results can be re-used and so fewer hardware resource are needed.

Referring to <FIG>, the filter <NUM> comprises a classification unit <NUM> for identifying whether a part (or parts) of a frame <NUM> matches a pre-defined criterion (or corresponding criteria) and outputting a result <NUM> in the form a classification number <NUM>. The classification number <NUM> is passed to an actioning unit <NUM> which determines how the frame <NUM> should be processed based on the classification number <NUM>.

While classification is performed, the frame <NUM> can be stored in memory <NUM>, such as a first-in, first-out (FIFO) buffer.

The classification unit <NUM> includes a pool <NUM> (or "set" or "bank") of comparators. The comparator pool <NUM> can include a set of configurable comparator units <NUM>, a set of pre-configured comparator units <NUM> and/or a set of block comparators units <NUM>.

The comparator pool <NUM> may only include only one type of comparator unit, such as configurable comparator units <NUM>.

The comparator pool <NUM> may include comparator units <NUM>, <NUM>, <NUM> which are used to process data of different sizes, such as <NUM> bytes ("<NUM>-byte filters"), <NUM> bytes ("<NUM>-byte filters") and/or <NUM> bytes ("<NUM>-byte filters"). For example, the comparator pool <NUM> may include sixty-four <NUM>-byte configurable comparator units <NUM>, sixty-four <NUM>-byte configurable comparator units <NUM> and sixty-four <NUM>-byte configurable comparator units <NUM>. There may be, however, fewer or more comparator units <NUM> of each size.

The comparator pool <NUM> may include configurable comparator units <NUM>, pre-configured comparator units <NUM> and a set of block comparators units <NUM>. For example, there may be sixty-four configurable comparator units <NUM> for each filter size, , two pre-configured comparator units <NUM> (optionally, two for each filter size) and one or two block comparators units <NUM> (optionally, one or two for each filter size).

As will be explained in more detail later, a pre-configured comparator units <NUM> and a block comparators unit <NUM> are generally simpler versions of the configurable comparator unit <NUM>, i.e., generally containing less hardware logic, but the hardware logic is optimised for particular situations. For example, pre-configured comparator units <NUM> are intended to be employed for filtering commonly-used fields, such as EtherType. Block comparators units <NUM> are intended for filtering a limited number of fields (for example, only one field) which can have many values (such as up to <NUM> values), for instance, for use in AVB.

Referring still to <FIG>, the classification unit <NUM> includes a matching unit <NUM> for processing outputs <NUM> of the comparator units <NUM>, <NUM>, <NUM>. The matching unit <NUM> includes a crossbar unit <NUM> (herein also referred to as a "crossbar block", "crossbar switch" or simply "crossbar") and a cascade unit <NUM> (herein also referred to as a "cascade block" or simply "cascade"). As will be explained in more detail later, the crossbar <NUM> and cascade <NUM> are programmable and can be used to identify specific combinations of data. Furthermore, at least some of results <NUM> from the cascade <NUM> can be re-used by the crossbar <NUM>.

The classification unit <NUM> includes a priority select block <NUM> (or "priority select unit") which processes the results <NUM> from the matching unit <NUM> and outputs the classification number <NUM>.

The classification unit <NUM> includes an interface <NUM> to a host <NUM>. The host <NUM> can program configuration registers <NUM> (<FIG>) which are used to configure the comparator units <NUM>, <NUM>, <NUM>, configuration registers <NUM> (<FIG>) which are used to configure the crossbar <NUM> and cascade <NUM>, and configuration registers <NUM> (<FIG>) which are used to configure the priority select block <NUM>.

Referring to <FIG>, comparator units <NUM>, <NUM>, <NUM> are built around a value comparator <NUM>. Incoming frames <NUM> are received from a data bus <NUM> via a data store <NUM> and byte selector <NUM> which, based on an offset <NUM>, selects data <NUM> for comparison using first and second values <NUM>, <NUM> according to a mode <NUM> and outputs first and second outputs <NUM>, <NUM> indicating matches ("Match <NUM>" and "Match <NUM>").

A comparator unit <NUM>, <NUM>, <NUM> may include offset and position control unit <NUM> which comprises an offset counter <NUM>, offset mode <NUM> and position control <NUM>. Offsets are described in more detail hereinafter.

A comparator unit <NUM>, <NUM>, <NUM> includes a configuration unit <NUM> which includes a set of configuration registers <NUM> and configuration logic <NUM> for configuring the value comparator <NUM>, the byte selector <NUM> and the offset and position control unit <NUM>.

A comparator unit <NUM>, <NUM>, <NUM> may include one or more finite state machines (FSMs) <NUM>, <NUM> which can process the outputs <NUM>, <NUM> of the value comparator <NUM>.

The outputs <NUM>, <NUM> of the FSMs <NUM>, <NUM> or the output <NUM>, <NUM> of the value comparator <NUM> are output to circuitry <NUM> for further processing. The circuitry <NUM> includes the matching unit <NUM> and the priority select unit <NUM>.

Referring to <FIG>, a value comparator <NUM> receives n bits of data <NUM> from the frame <NUM> (<FIG>) on a first line <NUM> ("data line"), a mode <NUM> on a second line <NUM> ("mode line"), a first n-bit value <NUM> on a first line <NUM> ("first value line") and a second n-bit value <NUM> on a second line <NUM> ("second value line").

As will be explained hereinafter in more detail, the first value <NUM> can serve as a mask or a filter value ("a first filter value" or "first reference"), and the second value <NUM> can serve a filter value ("a second filter value" or "second reference").

The mode <NUM> and the first value <NUM> are fed, via the mode line <NUM> and the first value line <NUM>, as inputs to a bitwise OR gate <NUM> (in the form of n <NUM>-input OR gates). The n-bit wide output of the bitwise OR gate is passed, via line <NUM>, to a bitwise AND gate <NUM> (in the form of n <NUM>-input AND gates) which also receives data <NUM> via the data line <NUM>.

The output of the bitwise AND gate <NUM> is passed, via line <NUM>, as one of the inputs to a first bitwise XOR gate <NUM> (in the form of n <NUM>-input XOR gates) which also receives, as its other input, the second value <NUM> received on the second value line <NUM>. The n-bit wide output of the first bitwise XOR gate <NUM> is output via line <NUM> to a first n-input AND gate <NUM>. The single-bit output of the first n-input AND gate <NUM> is output as a first value comparator output <NUM> via line <NUM>.

Data <NUM> and the first value <NUM> are fed as inputs to a second bitwise XOR gate <NUM> (again in the form of N <NUM>-input XOR gates). The n-bit wide output of the second bitwise XOR gate <NUM> is output via line <NUM> to second n-input AND gate <NUM>. The single-bit output of the second n-input AND gate <NUM> is output as a second value comparator output <NUM> via line <NUM>. The bitwise XOR gates <NUM>, <NUM> are also referred to herein as "comparators".

As mentioned earlier, the comparator units <NUM>, <NUM>, <NUM> may be arranged to receive and process data in <NUM>-byte (<NUM>-bit) blocks, <NUM>-byte (<NUM>-bit) blocks or <NUM>-byte (<NUM>-bit) blocks.

Referring also to <FIG>, in a so-called "mask mode", the first value <NUM> is used as a mask and the second value <NUM> serves as the value to be matched ("reference"). The mask <NUM> is used to mask individual bits so that the comparator <NUM> only compares unmasked bits of the input data <NUM> and the reference <NUM>.

In a so-called "expand mode", the first and second filter values <NUM>, <NUM> can be concatenated to create a double-width filter, i.e., 2n bits wide. Alternatively, in a so-called "precise mode", each of the first and second filter values <NUM>, <NUM> are each used as an n-bit reference. Herein, modes are handled in part by the value comparator <NUM> and in part by the FSMs <NUM>, <NUM>. In some embodiments, however, different modes can be implemented in a value comparator <NUM> using multiplexers (not shown).

A pre-configured comparator unit <NUM> is similar to a configurable comparator unit <NUM>. It may differ, however, in that some of the values <NUM>, <NUM> are fixed. The values <NUM>, <NUM> may be hardwired at time of manufacture or be one-time programmable. Thus, the pre-configured comparator units <NUM> may be identical to the configurable comparator units <NUM> except that re-programming of values is disabled.

Referring to <FIG>, a block comparator <NUM> may comprise a set of B simplified value comparators <NUM>', where B is a positive, non-zero integer, for example between <NUM> and <NUM>. Each simplified value comparators <NUM>' comprises a bitwise XOR gate <NUM> and an AND gate <NUM>. The same n-bit data is supplied to each of the B simplified value comparators <NUM>' and each simplified value comparators <NUM>' compares the data with a respective n-bit value, namely value [<NUM>], value [<NUM>],. , value [B-<NUM>]. In some cases, one or more of the values may be fixed and not configurable. The arrangement can be useful for routing applications.

Block comparator units <NUM>, while less flexible, are simpler and thus cheaper to implement. Using filter modes (for example, mask, precise and expand modes) can help reduce the amount of processing power ("flops") needed to configure fully the classification unit <NUM> (<FIG>). Using block comparator units <NUM> (for example, <NUM> values on <NUM> offset/mask) can help reduce the area of classification unit <NUM>. Also, using comparator units <NUM> (for example, groups of four filters) which share the same offset can also help to reduce the area consumed by the offset selectors.

<FIG> illustrates processing of stream of data <NUM> in a frame <NUM> (<FIG>) which starts from byte <NUM> and includes bytes N, N+<NUM>,. , N+<NUM> by a configurable comparator unit <NUM> having a width of <NUM>-bytes.

Referring to <FIG> and <FIG>, an offset <NUM> is used to select the start <NUM> of the data <NUM> to be processed, which in this case is byte N.

In mask mode, three bytes of data N, N+<NUM> and N+<NUM> are masked using stored mask provided by the first value <NUM> and compared with reference data provided by the second value <NUM> by the first comparator <NUM>.

In expand mode, six bytes of data N, N+<NUM>, N+<NUM>, N+<NUM>, N+<NUM>, N+<NUM> are left unmasked and compared with concatenated data provided by first and second values <NUM>, <NUM> by first and second comparators <NUM>, <NUM>.

In precise mode, the first three bytes of data N, N+<NUM>, N+<NUM> are left unmasked and compared with data provided by a first value <NUM> by the first comparator <NUM>. The second three bytes of data N+<NUM>, N+<NUM>, N+<NUM> are also left unmasked and compared with a second value <NUM> by the second comparator <NUM>.

Further details of the value comparator <NUM> and how the mode is set will be described in more detail hereinafter.

The classification unit <NUM> is able to check an individual part or individual parts of a frame by using an offset or offsets. The relevant parts of the frame vary between protocols and it may be desirable to use different protocols in parallel and, thus, check different parts of the frame in parallel.

Before explaining how offsets are used, some examples of different communication protocols and example of which parts of a frame may be of interest will described.

Referring to <FIG>, first, second and third Ethernet frames <NUM><NUM>, <NUM><NUM>, <NUM><NUM> are shown.

The first Ethernet frame <NUM><NUM> is an untagged Ethernet frame having an IEEE <NUM> frame structure in which the <NUM>-bit EtherType field <NUM> follows directly after the Source MAC address <NUM>. The EtherType field <NUM> is used to indicate which protocol is encapsulated in the payload of the frame. For IPv4, EtherType = 0x0800 and, for IPv6, EtherType = 0x86DD.

The second and third Ethernet frames <NUM><NUM>, <NUM><NUM> support virtual LANs (VLANs) and conform to IEEE <NUM>. In the second Ethernet frame <NUM><NUM>, a <NUM>-bit VLAN header is added immediately after the source MAC address <NUM> thereby shifting the EtherType field <NUM> by <NUM> bytes. In the third Ethernet frame <NUM><NUM>, two VLAN headers are added (referred to as "double-tagging"). A <NUM>-bit service tag (S-VLAN tag) is added immediately after the source MAC address <NUM> followed by a <NUM>-bit customer tag (C-VLAN tag) thereby shifting the EtherType field <NUM> by <NUM> bytes.

An Ethernet frame can be used to transmit data as User Datagram Protocol (UDP) datagrams or in Transmission Control Protocol (TCP) segments transferred via Internet Protocol version <NUM> (IPv4) or Internet Protocol version <NUM> (IPv6).

Referring to <FIG>, an IPv4 header <NUM> and an IPv6 header <NUM> are shown.

Referring in particular to <FIG>, the IPv4 header consists of <NUM> bytes and has <NUM> fields including Version (i.e., b0100), IP Header length (IHL), Type of Service, Total Length (i.e., the size of the datagram including the header and payload), Identification, Flags, Fragment Offset, Time to Love (TTL), Protocol (e.g., <NUM> indicates TCP and <NUM> indicates UDP), Header Checksum, Source Address (i.e., the IP address of the sending node) and Destination Address (i.e., the IP address of the intended receiving node).

Referring in particular to <FIG>, the IPv6 header consists of <NUM> bytes and has eight fields including Version (i.e., b0110), Traffic Class, Flow Label, Payload Length, Next Header which species the type of header (and uses the same scheme used in the Protocol field in IPv4), Hop Limit (which replaces the TTL field in IPv4), Source Address (i.e., the IP address of the sending node) and Destination Address (i.e., the IP address of the intended receiving node).

The classification unit <NUM> can be adjustably configured to check multiple fields to identify EtherType (i.e., IPv4 or IPv6) and Protocol or Next Header (i.e., UDP or TCP).

Variability in the position of the EtherType field can be accommodated by using a dynamic offset which can set according to whether an IEEE <NUM>. 1Q header is used or not used.

EtherType can be analysed by a <NUM>-byte configurable comparator unit <NUM>. This could be achieved, for example, using two comparator units <NUM> operating in precise mode. This, however, can be considered to be an unnecessary overhead since offset may not be needed, offset multiplexing can be computationally expensive and logic for different modes is not required. Thus, a block comparator unit <NUM> for inspecting the EtherType field and, optionally, Protocol/Next Header fields can be used. Herein, such as block comparator unit <NUM> is referred to as an "Ethernet block comparator unit <NUM>". In addition to checking EtherType, the Ethernet block comparator unit <NUM> can also check the Protocol field and/or the Next Header field.

As explained earlier, reference values in a comparator unit may be configurable, i.e., values stored in registers may be configurable, or fixed. Given that the pool of potential values for EtherType and Protocol field and/or the Next Header field is small, then at least some of the values in the Ethernet block comparator units <NUM> can be fixed.

Referring to <FIG>, the Ethernet comparator unit <NUM> includes registers <NUM> (<FIG>) which may store values of EtherType, for example, 0x0806 for Address Resolution Protocol (ARP), 0x0800 for IPv4, 0x08DD for IPv4, and values of Protocol and Next Header, for instance 0x06 for TCP and 0x11 for UDP. <FIG> shows a table <NUM> listing types of header, the EtherType value and a description of the corresponding protocol.

For Ethernet protocols, the number of fields (and, thus, offset values) is limited and so the classification keys tend to be limited, focussing mainly on, for example, <NUM> Stream ID, IPv4 address and MAC address. Accordingly, EtherType can be particularly useful for frame type identification and using dedicated logic, for example in the form of an Ethernet block comparator <NUM>, which consumes less area, can be useful.

Referring to <FIG>, a table <NUM> is shown which lists different types of frames and five different types of filters, i.e., five differently configured comparator units <NUM>, <NUM>, <NUM>.

Frame types include IEEE <NUM>. 1AS network control traffic such as gPTP or SPR, Address Resolution Protocol (ADP), Link Layer Discovery Protocol (LLDP), IEEE <NUM>, IPv4, TCP/IPv4, UDP/IPv4, SOME/IPv4, ICMP/IPv4, IPv6, TCP/IPv6, UDP/IPv6, SOME/IPv6, ICMP/IPv6, Double tagged and Null Stream Identification for FRER (IEEE <NUM>.

A first filter (for example, a first configurable comparator unit <NUM>), Input_o, can inspect protocol (PROT) and EtherType (TYPE) fields and a specific frame-type filter bit.

A second filter (for example, a second configurable comparator unit <NUM>), Input_1, can inspect four bytes using a reference value and an optional mask, in either precise or expand mode.

A third filter (for example, a third configurable comparator unit <NUM>), Input_2, can inspect four bytes using a reference value and an optional mask, in either mask, precise or expand mode.

A fourth filter (for example, a fourth configurable comparator unit <NUM>), Input_3, can inspect four bytes using a reference value and an optional mask, in either precise or expand mode.

A fifth filter (for example, a fifth configurable comparator unit <NUM>), Input_4, can inspect two bytes using the VLAN C tag, a fixed mask of x000F and a mask in mask mode.

In <FIG>, i is the index of the matching filter. The index number depends upon software configuration of the Filter Type. Text fields in grey italics are redundant checks.

Thus, in relation to TCP/IPv4 and TCP/IPv6, depending upon whether a node is server or client, either Destination or Source IP address and port values is used.

Referring again to <FIG>, the matching unit <NUM> includes a crossbar block <NUM> and a cascade <NUM>.

Referring also to <FIG>, the crossbar block <NUM> comprises M multiplexers <NUM> (where M is a positive, non-zero integer) each able to select one of N matches (where N is a positive, non-zero integer), i.e., one of N outputs <NUM> from the comparator units <NUM>, <NUM>, <NUM>, and to provide this as an input Input_0, Input_1,. , Input_M to an AND gate <NUM>. This arrangement is repeated U times (where U is a positive, non-zero integer). One of the inputs to the multiplexers <NUM> includes one or more outputs <NUM> from one or more AND gates <NUM> as a reusable result <NUM>. Additionally or alternatively, OR gates (not shown) can be used receiving, for example, outputs <NUM> of the comparator units <NUM>, <NUM>, <NUM> and/or one or more results <NUM> from the cascade <NUM>.

Referring also to <FIG>, the comparator pool <NUM>, matching unit <NUM> and priority select unit <NUM> are shown in a different way.

As shown in <FIG>, the crossbar block <NUM> (or "crossbar switch") provides junctions <NUM> (or "interconnects") between comparator units <NUM>, <NUM>, <NUM> and the AND gates <NUM>. The junctions <NUM> are configurable via configuration registers <NUM>.

Each AND gate <NUM><NUM>, <NUM><NUM>,. <NUM><NUM>M is supplied with a respective set of crossbar outputs <NUM><NUM>, <NUM><NUM>,. Each set of crossbar outputs <NUM><NUM>, <NUM><NUM>,. , <NUM>M may comprise zero, one, two, three or more crossbar outputs which are coupled to a comparator unit output <NUM>.

Although not shown in <FIG> for clarity, at least one output <NUM><NUM>, <NUM><NUM>,. , <NUM>M from one or more AND gates <NUM><NUM>, <NUM><NUM>,. <NUM>M is brought back as input to the crossbar block <NUM>. This can allow the number of crossbar inputs to be reduced. For example, it is possible to pre-qualify all traffic for a given UDP destination port and use the second round in crossbar to distinguish the possible sources, such as source IP and source port.

For a <NUM>-Gbps link, the minimum event rate is <NUM> ns. When running the filter <NUM> (<FIG>) at <NUM>, there are about <NUM> clock cycles which can be used to pipeline complete filtering.

Referring still to <FIG>, the priority select unit <NUM> comprises logic <NUM> and configuration registers <NUM>.

The priority select unit <NUM> can implement a strict priority scheme. For example, a simple implementation can be used which prioritises output according to the output of the cascade <NUM>. Thus, the first output (identification number <NUM>) has the highest priority, whereas the last output (identification number U) has the lowest priority.

For example, three comparator units <NUM>, <NUM>, <NUM> can be used to identify (a) IPv4 destination address, (b) IP protocol as TCP and (c) TCP destination port as <NUM>. Three AND gates <NUM> ("cascades") can be used, namely (I) a+b+c, (II) a+b and (III) a only.

In the priority select unit <NUM>, the cascades <NUM> can be ordered in a way that cascade I has highest priority (#<NUM>), and cascade III has the lowest priority (e.g., #<NUM>). Thus, according to hierarchical sorting, the three types of frames are sorted in the following order, namely:.

A chain translation can be used which employs a table of numbers to translate between U and an output priority V.

Priority selection allows simple coding of hierarchical conditions, as described earlier. In the case of IPv6 traffic, based on classification number, frames can be forwarded to its own DMA channel or, as per configuration in chain selection, to the DMA channel for the web server (same target as IPv4).

<FIG> shows configuration of the crossbar <NUM> for some of the frame types shown listed in table <NUM> (<FIG>).

Referring to <FIG> and <FIG>, the same output <NUM> can be used to identify different frames.

Referring to <FIG>, an example of a dedicated filter <NUM> (i.e., a configured filter <NUM>) for TCP session requests is shown. In this example, the filter <NUM> is configured to catch a synchronise request (or "SYN request") sent by a client (not shown).

The filter <NUM> can be set by examining:.

The destination address and the destination port are unique for flow control in a virtual machine (VM) (not shown). Once a match has been found, VM configures filtering for the connection.

In this example, the "always present" entry for "TCP SYN" triggers management software (not shown). The management software (not shown) checks if the TCP connection is OK. If yes, the management software (not shown) configures a lower prior filter for this TCP connection. When a frame with "TCP FIN" appears, this again goes to the management software (not shown), which removes the TCP connection from filter.

Referring to <FIG>, using different offset references <NUM><NUM>, <NUM><NUM>, <NUM><NUM>, filter programming can be simplified for the use case. For example, a first offset counter <NUM><NUM> hides the optional <NUM>. 1Q header and a second offset counter <NUM><NUM> could be start at IPv4/IPv6 payload to hide optional IP headers.

Referring to <FIG>, untagged, single-tagged and double-tagged Ethernet frames <NUM>, <NUM>, <NUM> are again shown.

Distinction between fields before and after the EtherType field <NUM> is helpful as it can compensate for the existence of the VLAN tag <NUM> existence during offset calculation. Distinguishing between layer <NUM> and layer <NUM> offset can be done through dedicated configuration or by using a programmed offset value.

Referring to <FIG>, an Ethernet MAC <NUM> typically provides the receive data in serial form, for instance in blocks of <NUM>-bit data words (with size information if the frame size is not a multiple of <NUM> bytes).

A comparator can take two approaches to filtering such data.

In a parallel approach, all data that is potentially needed for the comparator is provided in parallel. This approach needs sufficiently large storage, such as <NUM> flops for a <NUM>-byte offset area. This approach uses byte offset selector logic using N-times <NUM> to one multiplexer for a N-bit comparator as each byte offset is valid.

In a sequential approach, data is compared on a serial receive data stream, for example, on chunks of data (a data word) provided by the MAC <NUM>. An FSM used to identify the relevant parts in frame. In this approach, byte offset selector is limited to positions inside the data word. This can be achieved either by shifting/splitting the value to fit to the byte position inside the frame ("filter checked sequential") or by expanding the receive data to the width of the comparator.

Referring also to <FIG>, byte extraction using a mixture of the two approaches is used. The comparator is expanded by B-<NUM> byes (where B is <NUM> for a <NUM>-bit MAC data bus) to simply byte offset handling. Comparator with greater than B is handled sequentially (e.g., <NUM>-bit comparator on <NUM>-bit MAC data bus).

Referring to <FIG>, a <NUM>-bit configurable comparator unit <NUM> is shown in more detail.

Frame data are forwarded by MAC <NUM> on arrival to buffer <NUM> via a data bus <NUM>.

Referring also to <FIG>, the data bus <NUM> is <NUM>-bit wide and so <NUM>-bit data bytes <NUM>, <NUM>,. , <NUM> are grouped into <NUM>-bit blocks <NUM>, <NUM>. To allow processing of, for example, <NUM>-bytes of data which bridge adjacent blocks <NUM>, <NUM>, a buffer <NUM> can store the last three bytes from a previous block <NUM>. This can allow data to be expanded to <NUM> bits.

Referring again to <FIG>, a byte selector <NUM> selects which bytes of the expanded data to pass to the value comparator <NUM> based on an offset defined in configuration <NUM>. Configuration <NUM> pass a reference value and an optionally mask to the value comparator <NUM>. Configuration <NUM> also sets mode (e.g., mask, expand, precise) which passed to the value comparator <NUM> and the FSMs <NUM>, <NUM>. Offsets are handled by offset counters <NUM>, offset mode controller <NUM> and position control <NUM> according to configuration <NUM>.

In expand mode, position control <NUM> checks byte position P and byte position P+<NUM>. In other the other two modes, position control <NUM> only checks byte position P.

As explained hereinbefore, a value comparator <NUM> receives N-bytes data <NUM> and performs a comparison using two N-byte values (for instance, where N = <NUM>).

The first output <NUM> of the value comparator <NUM> is supplied to a first, three-state FSM <NUM> and the second output <NUM> of the value comparator <NUM> is supplied to each of the first, three-state FSM <NUM> and a second, two-state FSM <NUM>.

Referring to <FIG>, the three-state FSM <NUM> includes first, second and third states <NUM>, <NUM>, <NUM> and a decision point <NUM> (or "check point").

Following a RESET, the FSM <NUM> enters the first state <NUM> (or "WAIT state"). In response to detecting a start of frame ("start"), the FSM <NUM> changes to the second state <NUM> ("CHECK <NUM>"). Match1 is used to decide how to proceed after the check point <NUM>.

At the checkpoint, if the first value comparator output <NUM> is set to '<NUM>' (i.e., there is a match) AND the mode is NOT EXPAND, then the first FSM output <NUM> is set to '<NUM>', otherwise it is kept as '<NUM>'.

At the checkpoint, if the first output <NUM> is set to '<NUM>' (i.e., there is a match) AND the mode is EXPAND, then the FSM <NUM> changes to a third state <NUM> ("CHECK <NUM>"). When the next N bytes are received, another check is performed on match2 and the first FSM output <NUM> depends on whether the second value comparator output <NUM> is set to '<NUM>' or '<NUM>' and returns to the first state <NUM> (i.e., WAIT state).

Referring to <FIG>, the two-state FSM <NUM> includes first and second states <NUM>, <NUM> and a check point <NUM>.

Following a RESET, the FSM <NUM> enters the first state <NUM> (or "WAIT state"). In response to detecting a start of frame ("start"), the FSM <NUM> changes to the second state <NUM> ("CHECK <NUM>").

At the checkpoint, if the second value comparator output <NUM> is set to '<NUM>' (i.e., there is a match), then the second FSM output <NUM> is set to '<NUM>', otherwise it is kept as '<NUM>'.

Implementation of a block comparator unit <NUM> (<FIG>) is similar to that of a configurable comparator unit <NUM> except that for B reference values and thus B value comparators <NUM>' (<FIG>) and B outputs, there are B two-state FSMs <NUM> and B match outputs <NUM> to further processing <NUM>. As block comparators <NUM> do not have an expand mode, only the simple two-state FSM <NUM> is required.

Referring to <FIG>, an integrated circuit <NUM> in the form of a microcontroller is shown.

The microcontroller <NUM> includes the CPU sub-system <NUM>, an integrated level <NUM> and level <NUM> switch <NUM> and system memory <NUM> interconnected by a system bus <NUM>. The CPU sub-system <NUM> includes one or more CPUs <NUM> (herein, for clarity, reference will be made to a CPU <NUM>) and memory <NUM> storing application software <NUM>. The CPU <NUM> loads and executes the application software <NUM>. The system memory <NUM> is used to store data in transmit queues <NUM> and receive queues <NUM>.

Referring still to <FIG>, the switch <NUM> includes layer <NUM> controller <NUM> (e.g., media access controllers) and corresponding temporary storage <NUM>. In some cases (for example, where the integrated layer <NUM> and layer <NUM> device is not a switch, but instead an end station) there may be only one layer <NUM> controller and one temporary storage <NUM>. If there are multiple layer <NUM> controllers <NUM>, then the switch <NUM> may include an arbitration unit <NUM> which feeds frames to the classification unit <NUM>. The classification unit <NUM> is coupled to a forwarding control unit <NUM> which can pass received data to a transmit message handler <NUM> for suitable forwarding or to the bus master interface <NUM> for passing the received data to system memory <NUM>. The forwarding control unit <NUM> and bus master interface <NUM> serve as the actioning unit <NUM>.

The layer <NUM> controller/s is (are) connected to an external physical layer transceiver (PHY) (not shown) or internal (i.e., on chip) PHY module (not shown). The end switch <NUM> may have direct memory access capability and transfer data between a layer <NUM> controller <NUM> and system memory <NUM> without CPU intervention.

The switch <NUM> includes special function register (SFR) <NUM>. The switch <NUM> is controlled by the CPU <NUM> by a peripheral bus interface <NUM> via the SFR <NUM>.

Referring to <FIG> and <FIG>, operation of the filter <NUM> will now be described.

A frame <NUM> is received by the filter <NUM> (step S1). The frame <NUM> is stored in receive buffer <NUM> (step S2) and is classified by the classification unit <NUM> (step S3). The classification unit <NUM> outputs a classification number <NUM>. The actioning unit <NUM> processes the frame <NUM> according to the classification number <NUM> (step S4). The actioning unit <NUM> may, for example, drop the frame, manipulate the frame, forward it to a port or transfer the frame to an on-chip sub-system or peripheral module.

Referring to <FIG>, a communications system <NUM> which is deployed in a vehicle <NUM>, such as a motor vehicle, is shown.

Network traffic is generally increased by the addition of ADAS electronic control units (ECUs) <NUM> and new cloud services <NUM>. Thus, to help prevent unauthorized access, communications module <NUM> and cockpit module <NUM> on which third party applications (not shown) operate should be separated from the in-vehicle network modules <NUM>, <NUM> and filter data appropriately.

The communications system <NUM> includes a communication gateway <NUM> which include a microcontroller <NUM> having an integrated Ethernet switch <NUM> providing a layer-<NUM> ("L2") switch and layer-<NUM> ("L3") routing, and L2 Ethernet switches <NUM>, <NUM>.

The switch <NUM> can have plural Gigabit Ethernet ports <NUM>, <NUM>, <NUM> and provide VLAN tagging/untagging, MAC/IP address filtering and TCP/UDP port filtering.

<FIG> illustrates a configuration whereby the switch <NUM> is separate in-vehicle networks using VLANs <NUM>, <NUM>, <NUM>.

The integrated L2/L3 switch <NUM> is connected to the wireless communications module <NUM> forming a first VLAN <NUM>. The integrated L2/L3 switch <NUM> may be connected via a first L2 Ethernet switch <NUM> to the cockpit module <NUM> via a second VLAN <NUM>. The switch integrated L2/L3 switch <NUM> may be connected via a third L2 Ethernet switch <NUM> to a sensing module <NUM> and a cognitive module <NUM> via a third VLAN <NUM>. Meanwhile, the integrated L2/L3 switch <NUM> may be connected to ADAS electronic control units (ECUs) <NUM> via CAN-FD network <NUM>.

It will be appreciated that various modifications may be made to the embodiments hereinbefore described.

The filter herein described can be included in integrated circuits other than microcontrollers and systems-on-a-chip (SoCs). For example, they can be used in application-specific ICs (ASICs).

Claim 1:
A circuit (<NUM>), comprising:
a plurality of comparator units (<NUM>, <NUM>, <NUM>), each comparator unit configured, in response to receiving at least a part of a data frame (<NUM>), to perform a determination whether data in a portion (<NUM>) of the data frame matches respective reference data (<NUM>; <NUM>, <NUM>) and to provide a result to a comparator unit output (<NUM>) based on the determination;
a crossbar switch (<NUM>) having crossbar inputs coupled to respective comparator unit outputs and configured to provide sets of crossbar switch outputs via configurable interconnects; and
a set of result-combining logic units (<NUM>), each result-combining logic unit coupled to a respective set of crossbar switch outputs and configured to provide a respective logic unit output (<NUM>), wherein at least one result-combining logic output (<NUM>) is configurably provided as a crossbar input.