EBR-1553   |  EBR-1553 IP Core   |  Total EBR-1553 SPI   |  EBR-1553 Boards & Testers   |  EBR-1553 Software

EBR-1553 is a communication standard based on MIL-STD-1553 but is specified to operate at a higher data rate of 10 Mb/s. EBR-1553 operates over a hub (star) topology, with the Bus Controller (BC) node at the center of the hub and RTs located out on the spokes. The EBR-1553 physical layer calls for point-to-point connections using RS-485 transceivers.

Integrate EBR-1553 into your FPGA or SoC with a production-ready IP core designed for deterministic 10 Mb/s operation over RS-485 star networks. Whether you’re building a new bus controller, remote terminal, or monitoring capability, Sital’s IP accelerates development while helping teams avoid common edge cases in timing, topology, and dialect behavior.

EBR-1553 Supports

• EBR-1553 protocol engine for FPGA-based avionics designs
• Deterministic timing and robust interoperability
• Documentation and integration support for program-ready delivery

EBR-1553 Specs

• Data rate: 10 Mb/s
• Topology: Hub-based star (1–32 ports)
• Physical layer: RS-485 point-to-point links
• Modes: BC, RT, Monitor, and RT/Monitor
• Compatibility: DDC Enhanced Mini-ACE architecture; compatible with AceXtreme API
• Platforms: API/library/drivers available for Windows, VxWorks, Linux

Talk To An Engineer

High-Speed Data Transmission for Advanced Applications

EBR-1553 is based on MIL-STD-1553’s familiar command/response protocol, thereby enabling deterministic communication and providing error detection. In addition to its 10 Mb/s data rate, the MIL-STD-1553 response time and inter-message gap time values are modified for 10 Mb/s operation. EBR-1553 is deployed on weapon systems, including Small Diameter Bomb (SDB).

Sital’s EBR-1553 IP core provides DDC’s Enhanced Mini-ACE register/memory architecture; BC, RT, and Monitor operation. It also includes a hub that can be instantiated to provide any number of ports up to and including 32.

The core can be supplied with software API/library/drivers for Windows, VxWorks, and Linux. The API/library/drivers provide the same API that Sital provides for its MIL-STD-1553 IP and standard (single-function) boards and is also compatible with DDC’s AceXtreme API.

BC Mode and Hub Operation

For EBR-1553, the BC is the center point of the hub or star topology. The hub can be specified to be able to connect to any number between 1 and 32 RTs, with each hub branch connecting to a single EBR-1553 remote terminal (RT) over an RS-485 physical layer link.

The BC manages the operation of the hub. For non-broadcast messages, the BC selects which of the hub’s connections is active for each individual message. For broadcast messages, the RS-485 transmitters (but not receivers) will be active for all branches of the hub.

The width (number of branches) for the hub is a synthesis parameter that must be provided prior to Sital supplying the EBR-1553 IP core. The BRM1553D-EBR IP core can also support an RS-485 multi-drop configuration.

RT Mode

In RT mode, the IP core is connected to a single RS-485 transceiver, which is connected to one of the ports of the BC. The RT address can be set by means of hardware pins or by software. All mode codes are supported, as well as illegalization of mode codes and commands.

Monitor Mode

In Monitor mode, the IP core does not transmit messages; it only receives them. In this case, the hub width parameter is programmed to “1”. The Monitor might also connect to a wider hub, i.e., to multiple hub stubs. However, at any given time, it can only be programmed to record a message transmitted to and received from a single RT at any given time.

RT/Monitor Mode

Similar to Sital’s MIL-STD-1553 IP, components and boards, the BRM1553D-EBR IP core can also operate as a simultaneous RT/Monitor.

Integrated 1553 FPGA Service

For users of Sital Technology’s EBR-1553 IP core, Sital offers its “Integrated 1553” service for integrating its IP cores and software onto Xilinx SoC or MPSoC FPGAs. Sital’s “Integrated 1553” service leverages Xilinx’s Vivado(C) design suite software.

“Integrated 1553” enables reductions in customers’ times by providing “pre-integrated”, turnkey SoC/MPSoC solutions. It allows them to get their on-chip 1553 IP core(s), processor, and software fully up and running from months to approximately 30 minutes.

The “Integrated 1553” involves providing the on-FPGA interfaces between Sital’s IP core(s) and an on-chip processor such as an ARM Cortex. For Xilinx FPGAs, this typically involves the use of an AXI bus for address/data paths and interrupts.

In addition, it includes the integration of Sital’s API/library, operating system and on-chip interconnect bus (e.g., AXI) low-level software drivers. Before supplying a project to customers, Sital performs testing to verify that customers will be able to use Sital’s API and software stack to access and control Sital’s IP cores through its API.

EBR-1553 FPGA IP Core: BC, RT, And Monitor Operation At 10 Mb/s Over An RS-485 Hub Topology With Up To 32 Ports

EBR-1553 runs the MIL-STD-1553 command/response protocol at 10 Mb/s. Same message formats, same error detection, ten times the bit rate, carried over RS-485 point-to-point links arranged in a star instead of a shared bus. Sital’s BRM1553D-EBR IP Core puts that protocol inside your FPGA or SoC as a Bus Controller (BC), Remote Terminal (RT), Monitor, or simultaneous RT/Monitor, with a hub you can instantiate from 1 to 32 ports.

The core carries DDC®’s Enhanced Mini-ACE register and memory architecture, works with the AceXtreme API, and ships with drivers for Windows, Linux, and VxWorks.

Across 25+ years of building 1553-family cores, we have found that EBR-1553 programs rarely stall on bit rate. They stall on hub routing, on topology decisions locked in too late, and on dialect mismatches between line replaceable units (LRUs) built by different suppliers. We designed the BRM1553D-EBR around those failure points, not only around the specification.

TL;DR Quick Answers

EBR-1553 FPGA IP Core BC/RT/Monitor

Sital’s EBR-1553 FPGA IP Core, part number BRM1553D-EBR, is a protocol engine that implements EBR-1553 inside any FPGA or SoC. It operates as a BC, RT, Monitor, or simultaneous RT/Monitor, and it includes a hub of up to 32 ports.

Key facts:

• Modes: BC, RT, Monitor, and simultaneous RT/Monitor.
• Data rate: 10 Mb/s. MIL-STD-1553 response time and inter-message gap values scale to match.
• Topology: hub-based star. The BC sits at the center. Each branch serves one RT over a point-to-point RS-485 link. RS-485 multi-drop is also supported.
• Hub sizing: 1 to 32 ports. Hub width is a synthesis parameter, fixed before Sital supplies the core.
• Register architecture: DDC® Enhanced Mini-ACE register and memory interface, so existing drivers and applications keep working.
• Software: API, library, and drivers for Windows, Linux, and VxWorks, compatible with DDC®’s AceXtreme API.
• Source: vendor- and technology-independent VHDL. Runs on any FPGA family and needs only a standard 10 Mb/s RS-485 transceiver.
• Assurance: designed for DO-254 and DO-178 certifiability, including DAL A. Proudly made in the USA.

Top Takeaways

1. One core covers four modes. BC, RT, Monitor, and RT/Monitor all come from the same BRM1553D-EBR IP Core. You configure the mode. You do not source a different part.
2. The hub is built in. An EBR-1553 BC needs a hub, so Sital instantiates one of up to 32 ports inside the core and routes each message to the correct link automatically.
3. Your existing 1553 software keeps working. Enhanced Mini-ACE architecture and AceXtreme API compatibility mean most teams migrating from a DDC® device rewrite neither drivers nor applications.
4. Dialects carry the real integration risk. EBR-1553 has no formal validation test regime, which allowed at least two dialects to develop. Sital supports both the Boeing and Lockheed Martin dialects and validates against a test set derived from MIL-STD-1553 RT, MT, and BC validation.
5. This is IP, not silicon. Technology-independent VHDL on any FPGA removes parts-obsolescence exposure and hands you control of area, clocking, and redundancy.

What EBR-1553 Is, And Why It Runs At 10 Mb/s

EBR-1553 builds on MIL-STD-1553 but specifies 10 Mb/s rather than 1 Mb/s. The familiar command/response protocol and error detection carry over, so you design frame patterns and data flows the same way you always have. What changes is the wiring underneath.

The bus becomes a hub, or star. The BC occupies the center, and RTs sit on the spokes. Each connection is a point-to-point RS-485 differential link, which is what makes the higher bit rate affordable per node. MIL-STD-1553 response time and inter-message gap values scale accordingly for 10 Mb/s operation.

Two naming points are worth settling early, because they cause real confusion in requirements documents. SAE standardizes this protocol as AS5652. The munitions community generally calls the interface MMSI, short for Miniature Munitions Stores Interface. A parallel interface, JMMI, came out of the Small Diameter Bomb competition and is a different thing. Confirm which document your program cites before you select hardware. For background on how the 10 Mbps MMSI interface came out of MIL-STD-1553B, Military Embedded Systems covers the topology and cabling decisions in plain terms.

BC Mode And The Hub: Scaling From 1 To 32 Ports

In EBR-1553, the Bus Controller manages the hub. For non-broadcast messages, the BC selects which hub connection is active for each message. For broadcast messages, the RS-485 transmitters go active on every branch while the receivers do not.

Sital instantiates that hub for you. Because the number of branches is a synthesis parameter supplied before delivery, the fabric cost matches your topology and nothing more. The core also supports an RS-485 multi-drop configuration where a program calls for it.

The detail that saves integration time sits one level down. Routing a message to the right RT in hub link mode gets awkward fast, and some implementations push that work back onto the programmer through manual multiplexer control. Schedule a message to a given RT with Sital’s core, and it selects the correct link, then adjusts the RT address in the command by itself. Your scheduling code stays clean, and it uses the same Enhanced Mini-ACE API functions you already use for MIL-STD-1553.

RT, Monitor, And RT/Monitor Operation

• RT mode: the core connects to a single RS-485 transceiver wired to one port of the BC. You set the RT address by hardware pins or software. The core supports all mode codes, plus illegalization of mode codes and commands, which is how you stop a terminal responding to traffic it has no business acting on.
• Monitor mode: the core receives and never transmits. Hub width is programmed to 1. A Monitor can connect to a wider hub across multiple stubs, but at any given time it records traffic to and from a single RT. EBR-1553 defines monitoring that way. Design around it rather than discovering it during integration.
• RT/Monitor mode: as with Sital’s MIL-STD-1553 IP, components, and boards, the BRM1553D-EBR core runs as a simultaneous RT and Monitor.

Enhanced Mini-ACE Architecture And AceXtreme API Compatibility

The core includes DDC®’s Enhanced Mini-ACE register and memory interface. For a team moving off a DDC® device, that decides whether you are making a hardware change or a program-wide software rewrite. Existing drivers and applications generally keep running, which removes schedule risk and re-verification cost at the same time.

The supplied API, library, and drivers cover Windows, Linux, and VxWorks. They present the same API Sital provides for its MIL-STD-1553 IP and single-function boards, and they work with DDC®’s AceXtreme API. Teams already fluent in that interface do not have to learn a second one to move to EBR-1553. Our CTO made the same point when we announced the 10 Mbit EBR-1553 IP Core: a complete solution covers every mode of operation, the software drivers, and the tester hardware, not just the protocol engine.

Mini-ACE and DDC® are registered trademarks owned by Data Device Corporation, Bohemia, New York, USA. Sital Technology, Ltd. has no affiliation with Data Device Corporation.

Integrating EBR-1553 Into Your FPGA Or SoC

We deliver the core as vendor- and technology-independent VHDL. It runs on any FPGA family, occupies a small area, and accepts a range of clock frequencies so you can keep clock domains to a minimum. Interface options cover 16, 32, and 64 bits. The architecture is modular, dual-redundant configurations are supported, and a full verification environment ships with the core.

The Manchester decoder deserves its own note. It works from a single clock source at any frequency above 120 MHz. Fewer clock inputs and fewer clock domains mean less EMI and RFI on the board, and an easier back-end integration. Its noise-filtering algorithms were built for harsh electromagnetic environments, which is where this protocol actually lives. When a customer’s marginal transceiver put a board at risk of failing RT noise rejection testing, we improved noise durability in the BRM1553 and EBR1553 cores within days, and the board passed without a re-spin. That is the practical argument for IP over silicon.

For Xilinx SoC and MPSoC targets, Sital’s Integrated 1553 service delivers the core pre-integrated with an on-chip processor such as an ARM Cortex, using the Vivado design suite, AXI address, data, and interrupt paths, and Sital’s API, operating system, and low-level drivers. Our engineers verify the full software stack against the delivered project before handover. The core sits alongside the interface boards, testers, and software in the complete EBR-1553 product family.

Dialects, Validation, And Why Interoperability Is The Real Risk

EBR-1553 never received a formal validation test regime, and that gap has consequences. At least two dialects are in service, one associated with Boeing and one with Lockheed Martin, and LRUs built to different dialects can fail to talk to each other. The split traces back to the Small Diameter Bomb Increment II program, where a competing miniature munitions interface was fielded while the SAE document waited.

Sital’s EBR-1553 IP cores and testers support both dialects, and we put the products through a validation suite derived from the MIL-STD-1553 RT, MT, and BC validation test set. No datasheet comparison will surface this part of the specification. In our experience, it is where schedules go: not in bring-up, but in the first integration lab session with a partner’s hardware.

“After two decades of 1553-family integrations, the pattern holds. EBR-1553 programs rarely slip because of the 10 Mb/s bit rate. They slip in the integration lab, the first time two LRUs built to different dialects meet. We validate our cores against a test set derived from MIL-STD-1553 RT, MT, and BC validation, and we support both dialects, so our customers never have to pick one and hope.”

-Sital Technology Team

Essential Resources On EBR-1553 FPGA IP Core BC/RT/Monitor

Seven primary sources worth reading before committing to an EBR-1553 architecture. Each one answers a question no datasheet will.

1. Read The Standard Your Program Actually Cites

SAE AS5652 is the specification behind EBR-1553, covering the 10 Mb/s command/response bus with a star topology. When a requirements document says MMSI, EBR-1553, or AS5652, this is the document those terms point to.

Source: SAE International — AS5652, 10 Megabit/sec Network Configuration Digital Time Division Command/Response Multiplex Data Bus

2. Understand How COTS IP Is Treated In Hardware Certification

FAA Advisory Circular 20-152A supplements RTCA DO-254 with guidance on custom devices, and it addresses commercial off-the-shelf intellectual property directly. If your certified design will contain a purchased IP Core, this is the clearest statement of what an authority expects to see.

Source: FAA — AC 20-152A, Development Assurance for Airborne Electronic Hardware

3. Confirm Your Export-Control Position Before You Specify

The United States Munitions List at 22 CFR Part 121 sets out which defense articles, technical data, and services fall under ITAR, including military electronics under Category XI. For a DataBus core headed into a weapon interface, this governs who may receive the design data and on what terms.

Source: eCFR — 22 CFR Part 121, The United States Munitions List

4. See How A 1553 Terminal Is Built Inside An FPGA

NASA Goddard describes a compact, low-overhead MIL-STD-1553B Remote Terminal controller implemented within part of a modern field-programmable gate array, with on-chip error checking and diagnostic support. It is a useful engineering reference for what a well-scoped 1553-family core looks like in fabric.

Source: NASA Technical Reports Server — Compact, Low-Overhead, MIL-STD-1553B Controller

5. Learn What The Defense Community Expects From FPGA Assurance

Sandia National Laboratories maps assurance risk across the whole FPGA lifecycle, covering vendor tools, hard IP, soft IP, design entry, provisioning, field use, and retirement. Few published documents show as plainly where a purchased IP Core sits inside a defense program’s trust chain.

Source: U.S. Department of Energy OSTI — Update: FPGA Trust/Assurance Study, Sandia National Laboratories

6. Verify That Third-Party IP Survives The FPGA Toolchain Intact

This peer-reviewed study lays out physical, functional, and bitstream-level flows for proving that a compiled FPGA design still matches the trusted source IP that went in. Integrating a purchased core into a safety-critical or security-critical design makes this the assurance question to put to your vendor.

Source: NSF Public Access Repository — Approaches for FPGA Design Assurance

7. Set Your Expectations For Firmware And Platform Resiliency

NIST SP 800-193 defines protection, detection, and recovery mechanisms for platform firmware and critical data against destructive attacks. Hold it against any claim that an embedded DataBus device is secure.

Source: NIST — Platform Firmware Resiliency Guidelines (SP 800-193)

Supporting Statistics

Three findings that shape how we build EBR-1553 products.

1. Weapon System Cyber Vulnerabilities Turned Up Routinely, Not Occasionally

• In operational testing, DOD routinely found mission-critical cyber vulnerabilities in systems under development.
• Testers using relatively simple tools and techniques took control of systems and largely operated undetected.
• Known vulnerabilities likely represent a fraction of the total, because not every program was tested and the tests did not reflect the full range of threats.
• DOD planned to spend about $1.66 trillion developing its current portfolio of major weapon systems.

Our read: failure mode was not exotic. It was basic hygiene at the communication layer. That is exactly why we built “SnS” to validate messages at the physical layer instead of trusting the stack above it.

Source: U.S. Government Accountability Office — Weapon Systems Cybersecurity: DOD Just Beginning to Grapple with Scale of Vulnerabilities (GAO-19-128)

2. U.S. Aerospace Manufacturing Holds The Nation’s Strongest Trade Position

• The U.S. aerospace sector produced the highest trade balance of any manufacturing industry, at $77.6 billion in 2019.
• Exports reached roughly $148 billion, the second highest of any manufacturing industry.
• Direct employment ran from 477,700 in 2010 to a high of 534,300 in 2019.

This is the industrial base our customers build into. We manufacture in the USA for that reason: shorter supply chains, ITAR alignment, and delivery commitments that survive contact with a program schedule.

Source: International Trade Administration — Leading Economic Indicators, Aerospace Industry

3. Engineering Capacity, Not Silicon, Is The Scarce Resource

• Aerospace engineers held about 71,600 jobs in 2024, with 37 percent working in aerospace product and parts manufacturing.
• Employment is projected to grow 6 percent from 2024 to 2034, against 3 percent for all occupations.
• About 4,500 openings are projected each year, many created by workers retiring or moving on.

Budget and fabric rarely constrain an EBR-1553 program. Qualified engineering hours do. Every week a team spends rebuilding a protocol engine that already exists is a week it does not spend on the part of the system only that team can build.

Source: U.S. Bureau of Labor Statistics — Occupational Outlook Handbook: Aerospace Engineers

Final Thoughts And Opinion

EBR-1553 is a well-understood protocol with a poorly understood failure mode. The 10 Mb/s bit rate, the RS-485 physical layer, and the star topology all read as straightforward once you have seen them work. Programs get caught out by everything the specification left open.

Our opinion, formed across many EBR-1553 integrations:

• Choose interoperability, not speed. Every credible vendor meets 10 Mb/s. Fewer can show you what they did about dialects.
• Treat the absence of formal validation testing as a program risk with a named owner. It will not resolve itself, and it surfaces late.
• Buy IP rather than silicon when the program outlives a decade. Obsolescence is the quiet schedule killer on long-life munitions and platform programs.
• Protect the API. An interface change rarely costs you the hardware. It costs you to re-verify every line of software that touched the old one.
• Ask where security lives. If the answer is the application layer, then the bus itself is still trusting whatever sits on it.

Here is the position we will defend, and it is not the popular one. The most valuable thing we ship with the EBR-1553 IP Core does not appear on the datasheet. It is the validation test regime behind it. Features compare cleanly across a spec sheet. Evidence that two different suppliers’ LRUs will actually talk to each other on your bench does not compare cleanly at all, and it is the one thing that reliably predicts whether integration takes a week or a quarter.

Frequently Asked Questions

What Is EBR-1553?

EBR-1553 is a 10 Mb/s variant of MIL-STD-1553 that runs over point-to-point RS-485 links in a hub, or star, topology. It keeps the command/response protocol and error detection of MIL-STD-1553, with response and inter-message gap timings scaled for the higher bit rate. SAE standardizes it as AS5652, and munitions programs commonly call it MMSI.

How Does EBR-1553 Differ From MIL-STD-1553?

Four differences matter in practice: bit rate at 10 Mb/s rather than 1 Mb/s, a hub or star topology rather than multi-drop, RS-485 point-to-point links rather than transformer-coupled twinax stubs, and a typical application in miniature munitions and stores interfaces rather than platform avionics. The protocol logic your software sees stays familiar.

How Many Ports Can The EBR-1553 Hub Support?

Sital’s core instantiates a hub of up to 32 ports, each branch serving one RT. Hub width is a synthesis parameter, so we fix it before supplying the core rather than configuring it at runtime. Scope your topology first, growth included, because widening the hub later means a new synthesis. RS-485 multi-drop is supported as an alternative.

Which Operating Modes Does The BRM1553D-EBR IP Core Support?

Four: Bus Controller, Remote Terminal, Monitor, and simultaneous RT/Monitor. The BC manages hub routing. The RT responds to commands and supports all mode codes plus illegalization. The Monitor receives only. RT/Monitor combines terminal operation with traffic recording, exactly as it does on Sital’s MIL-STD-1553 products.

Is The Core Compatible With Existing DDC® Software?

Yes. The core provides DDC®’s Enhanced Mini-ACE register and memory architecture, and the supplied API works with DDC®’s AceXtreme API. Teams migrating from a DDC® device generally keep their existing drivers and applications, which is usually the single largest cost a migration avoids. Mini-ACE and DDC® are registered trademarks of Data Device Corporation. Sital has no affiliation with Data Device Corporation.

Which FPGAs And Operating Systems Are Supported?

Any FPGA family. We deliver the core as vendor- and technology-independent VHDL, and it needs only a standard RS-485 transceiver rated for 10 Mb/s. API, library, and drivers cover Windows, Linux, and VxWorks. For Xilinx SoC and MPSoC targets, our Integrated 1553 service delivers the core pre-integrated with an on-chip processor and software stack.

Does The Core Support Boeing And Lockheed Martin EBR-1553 Dialects?

Yes, both. EBR-1553 never received a formal validation test regime, and that gap allowed at least two dialects to develop. LRUs built to different dialects can fail to interoperate. Sital supports both and validates its cores and testers against a test set derived from the MIL-STD-1553 RT, MT, and BC validation tests. In our experience, this single issue causes more lost time in an EBR-1553 integration lab than any other.

Can The EBR-1553 IP Core Be Certified To DO-254 Or DO-178?

We design the core for DO-254 and DO-178 certifiability, including DAL A. Certification artifacts are available through our partners Logicircuit for hardware and ConsuNova for software. Certification applies to your system rather than to a component in isolation, so plan the evidence trail alongside the design rather than after it.

Talk To An Expert About Your EBR-1553 Program

Tell us your topology, your target FPGA, and the dialect your program requires, and we will confirm whether the BRM1553D-EBR IP Core fits before you commit a line of RTL. Request an Evaluation for hardware samples, or Talk To An Expert to walk through hub sizing, API migration, and your DO-254 and DO-178 evidence path.

Sital Technology  |  Databus Communication Solutions