Tag: firmware

For the system designer, the platform is a complex supply chain of internal/externally developed hardware/software intellectual property (IP). It’s a complex set of risks and trade offs that must be analyzed in the decision making process. The winning platform provider will go above and beyond, to provide a whole solution, including a programmers guide to the register map, driver code and maybe even an executable specification model.

There are many different requirements that the System Developer may have for the IP deliverables, including:

  • a programmers’ guide on interfaces, interrupts, registers, and so on
  • example/reference firmware for driving and testing the IP in a standard configuration
  • inter-operable models of the IP in various different languages, at different levels of abstraction (firmware, ESL, HVL, RTL, XML, etc.)
  • ability to integrate and even re-code firmware in a system-specific way across all IP in the system
  • ability to easily integrate and brand IP documentation across the entire system in a consistent, professional way

A good approach to the modelling and abstraction of the hardware/software interface can help to achieve these requirements for both the IP producer and the system integrator. The SpectaReg register management tool’s approach is to generate the different deliverables from a common, single-source specification model. This provides opportunities for “bottom up” and “top down” approaches to firmware abstraction and system documentation preparation.

Abstraction by the IP Provider - Bottom Up
The IP provider should provide a memory map document of the different memory mapped elements and registers. Better yet, they may additionally provide a device driver code that abstracts the registers to provides a higher level view of the IP. Since the abstraction is created by the engineers specializing in the IP rather than engineers specializing on the overall system we call this “bottom up” abstraction.

Abstraction by the System Integrator - Top Down:
The IP consumer may have their own special way of doing device drivers, system memory testing and diagnostics. They might be targeting a specialized processor or interconnect architecture, language or operating system. They might be optimizing for throughput, power, or memory. They might have custom monitoring, programming and debugging systems. For these reasons the IP consumer might choose to create their own firmware. This “top down” approach to hardware abstraction requires that both the IP provider and consumer have excellent and inter-operable register management workflows.

The Register Supply Chain:
Something we are seeing in our extensive work with registers is that there is a supply chain of register specifications from the different IP providers. For example, the provider of a SPI core may have several registers that they code in Verilog, VHDL, C/C++ and publish in HTML or PDF. Then, the consumer of the SPI core may want to integrate the registers of the SPI core into their overall register map and C/C++ driver code in a way that is consistent across the entire system. Within this process there are various different teams and perspectives that need to consume the specification and produce work based upon that. This is the Register supply chain.

A Semantic Register Specification and the Supply chain:
Ideally the IP developer captures the registers into a semantic specification model that can be used as a single source of the register interface specifications. With SpectaReg, this is done through a browser based GUI and imported/exported using IP-XACT (and many other formats too). The underlying model specifies all relevant information relating to the registers, including typing information relating to how the register’s bit-fields are implemented and how they function. The model also includes inter-relationships between register fields. For example, a certain bit may be defined as an interrupt and it may be associated with a trigger and mask bits. The firmware programmer knows how the interrupt will operate and the RTL developer knows how it is auto-implemented in the Verilog and/or VHDL, based on the typing of the bit. From the semantic model, the related RTL and firmware code can be auto-generated to target different bus interface protocols and different coding and presentation styles that suit the needs of the system integrator.

Simply throwing the semantic register specification over the wall to the IP consumer (say in an IP-XACT XML file) does not solve everything. There are opportunities for the supply chain to get out of synchronization and for non-formalized communication of information to get lost. The flows for making changes and feeding back information from the different parts of the supply chain are not well defined. Using a dynamic web application to manage the specification model and manage the dynamic and collaborative work-flows of the register supply is part of our vision. We see this as the best way to simplify the overall process and address the needs of all stakeholders. What do you think?

In English Bay off West Point Grey in Vancouver lies an ideal spot for catching Dungeness Crabs - a wonderful delight to eat.  My first experience crabbing was dropping a trap off a friend’s boat en route to Chinook Salmon fishing in the Geogria Straight.  It’s not unusual to catch your limit on Spanish Banks if you know what you’re doing and to buy the equivalent at the local fish market will cost you almost $100.


View Larger Map

Dungeness Crabs

Dungeness Crabs

This summer some friends and I went out in Kayaks and were quite successful at catching our limits.  Google maps on the iPhone helped us to locate the trap after a paddle around the bay.  Being on the water with a 3G connected smartphone is pretty handy.

On another occasion, while trolling on a Salmon fishing mission after having dropped the trap, we pondered how many crabs had entered the trap. At the same time internet radio streamed care of the iPhone’s 3G internet. I got thinking how cool it would be if we had a 3G link to a web camera down below to show us what was inside.  Next thing you know I was drawing up plans for an autonomous crabbing vessel.


Continue reading…

Meeting and talking with customers about their register needs and requirements is one of my favorite things to do.  Not too long ago I met with an embedded firmware guru over coffee and we discussed various topics about registers and register management tooling.  We discussed registers in the context of multi-processor system on chips (MPSoCs) with a lot of different interconnect channels or bridges and buses. In such a system, where there is concurrent software that may access the same registers, we discussed the pains of read-modify-write and how to reduce the need for such operations.  Some of our conclusions on this are discussed in this posting, which was spurred by one Gary Strigham’s recent Embedded Bridge issues.  Gary has hinted that his upcoming issue will discuss “an atomic register design that provides robust support for concurrent driver access to common registers” and I’m curious to see how his techniques compare to the ones discussed herein.

What is  a register read-modify-write operation?

Firmware often needs to modify only one single bit or bit-field of an addressable register without modifying other bits in the register.  This requires the firmware to read the register, change the desired bit(s), then write the register back.

Problem 1: Atomicity for register read-modify-write operation

In a system that has concurrent software accessing the registers, read-modify-writes are a real concern.  Without proper inter-process synchronization (using mutexes or some other form of guaranteed atomicity) there is a danger of race conditions.  These dangers are well described in Issue #37 of Gary Stringham’s Embedded Bridge.

Problem 2: Latency of read-modify-write operations

In a complex MPSoC, with a complex interconnect fabric, register read operations can be painfully slow when compared to pure register write operations.  System performance can be greatly improved by reducing the number of read operations required.

How to trade register read-modify-write transactions with a single register write

The trick to replacing the need for read-modify-write of a register with a register write operation is to create additional CLEAR and SET write-only registers.

Consider the following FLAGS register as an example which uses 8 bit registers for simplicity sake.

reg name bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
FLAGS flag_a flag_b flag_c flag_d flag_e flag_f flag_g flag_h

Without any supporting CLEAR/SET registers, to modify flag_f would require a read-modify-write operation. However, when we add the supporting CLEAR and SET write-only registers and related RTL logic then each bit can be set or cleared independently.  The flag_f bit can be set by writing 0×04 to FLAGS_SET and cleared by writing ox04 to the FLAG_CLEAR register.  The following table shows how the three related registers would look.

reg name bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
FLAGS flag_a flag_b flag_c flag_d flag_e flag_f flag_g flag_h
FLAGS_CLEAR clear_a clear_b clear_c clear_d clear_e clear_f clear_g clear_h
FLAGS_SET set_a set_b set_c set_d set_e set_f set_g set_h

Here the complexities of read-modify-write in a concurrent software environment are traded for additional complexity within the Verilog or VHDL RTL code, and the related verification code. A register management tool like SpectaReg can be setup to allow easy specification of such register patterns in a graphical environment and auto-generation of the related RTL, verification code, and the firmware abstraction of the bits. With such a register management tool, the related work is greatly simplified when compared to the tedious and error-prone process of doing it manually.  An additional advantage relates to architectural exploration - with an automated path between the specification and generation it’s much easier to switch between the two techniques: i) a single read/write register requiring read-modify-write, and ii) a read only register with supporting SET and CLEAR registers.

In addition to register read-modify-writes discussed at the coffee talk with the firmware guru, we also chatted about how specialized hardware registers offer valuable diagnostics, performance profiling, optimization and debugging of MPSoC systems - perhaps a good topic for a future posting so stay tuned.

Lastly, if you have any thoughts to contribute, be sure to leave a comment.

While on an ocean side walk, I daydreamed of being struck by a great IP/subsystem idea with potential for royalty licensing.  I imagined organizing a team and jumping into action, developing the RTL logic, and processor integration.  Should I choose Virtual and/or FPGA prototyping?

English Bay, Oceanside

ocean side walk

Virtual Platform

It’s all about getting the software working as soon as possible.  The Google Android Emulator is an excellent example of how Google was able to get the software working without requiring developers to possess the device hardware.  The Android Emulator is described as a “mobile device emulator — a virtual mobile device that runs on your computer.”  Android abstracts the hardware, ARM processor, and Linux kernel with an Eclipse based Java framework, targeting Android’s Dalvik Virtual Machine, a register-based architecture that’s more memory efficient than the Java VM.

Virtual Prototyping

Clearly the virtual Android emulator/platform makes software development easier. Similarly, a virtual prototype makes abstract product validation easier. With a virtual prototype, the developers can explore different algorithms and architectures across the hardware and software abstractions.  Things like instruction set, on-chip interconnect, acceleration, memory, interrupt, and caching architecture can be explored by digital designers and firmware ahead of the VHDL and Verilog solidification.  Still, despite any effort spent on virtual prototyping, physical validation is essential before offering an IP for license.  FPGA prototyping is a good choice for all but the most complex and highest performance IP.

FPGA Prototyping

Those who know firmware and RTL coding, should have no problem getting basic examples running on an FPGA dev kit in the first day or two.  Those with experience validating a chip in the lab understand that so much really comes down to using embedded software to drive the tests.  Today’s Embedded System FPGA kits provide on-chip processors and the whole development environment.  Some available embedded FPGA processor options are listed in the following table:

Vendor/Processor On-chip interfaces Tools
Altera NIOS II

(soft core)

Avalon SOPC Builder

Quartus II

NIOS II IDE, with Eclipse CDT &

GNU compiler/debugger

Xilinx PowerPC

(hard core)

CoreConnect PLB & OPB Embedded Development Kit (EDK), with Eclipse CDT GNU compiler/debugger

Xilinx Platform Studio (XPS)

ISE

Xilinx MicroBlaze

(soft core)

CoreConnect PLB & OPB Embedded Development Kit (EDK), with Eclipse CDT GNU compiler/debugger

Xilinx Platform Studio (XPS)

ISE

Actel ARM

(soft core)

AMBA AHB & APB Libero IDE, CoreConsole, SoftConsole (Eclipse, GNU Compiler/debugger)

Short of having deep pockets for an ASIC flow, or a platform provider lined up to license the IP and spin prototype silicon, FPGA prototyping makes good sense.  Virtual platforms make sense for reaching software developers, so they can interface with the IP as soon as possible.  One problem with providing models for developing software before the hardware is complete is that it’s difficult to keep the different perspectives aligned as the design evolves.  Tools like SpectaReg that model hardware/software interfacing and auto-generate dependent code keep the different stakeholders aligned, resulting in quicker time to revenue for the IP.

So back to my oceanside daydream… how would I get the IP to market and start making money?  It depends on the target market.  If the end user targets embedded system FPGAs then it’s a no brainer - go straight to FPGA prototyping and don’t worry about virtual platform.  If the target market is mobile silicon platforms, then virtual prototyping/platforming makes sense.  Having validated silicon in hand is ideal but impractical in many circumstances. FPGA prototyping is pretty darn compelling when you consider the speedy turnaround times, and the low startup costs.

This is a technical posting for the firmware readership.

One of the most elegant ways of expressing register bit-fields in C/C++ firmware is using a union of a struct with a register word.  The problem with this is that there is no standard way for representing the bit field packing/ordering in C/C++, which restricts portability across compilers and architectures.  For the simple traffic light controller (TLC) example with the register-map shown here, the LightState Register’s Green, Amber and Red bit-fields can be represented as shown below, assuming most to least significant bit packing.

union TLC_STATUSREGISTERS_LIGHTSTATE {
    struct {
        volatile unsigned : 29;
        volatile unsigned green : 1;
        volatile unsigned amber : 1;
        volatile unsigned red : 1;
    } fields;
    volatile u32 reg;
};

If the bit-order packing is reversed, then it needs to look as follows:

union TLC_STATUSREGISTERS_LIGHTSTATE {
    struct {
        volatile unsigned red : 1;
        volatile unsigned amber : 1;
        volatile unsigned green : 1;
        volatile unsigned : 29;
    } fields;
    volatile u32 reg;
};

The reversal of the bit fields can be done using auto-generation based on a bit-ordering condition with a register automation tool like SpectaReg.  For non-generated static code, it can be accomplished using #ifdefs, and sometimes compiler pragmas.

The most portable way to deal with register bits in C/C++ is NOT to use this struct/union fanciness — instead do the required masking (and possibly shifting) using bitwise operators.  SpectaReg produces both the struct/union format and also the shift/mask format. How does the RegisterBits readership do it?

A quick snapshot on the poll described in my previous posting: “for System-on-Chip developers, where is the greatest hardware/software register interface pain?”

Of the 71 votes thus far, 59% indicated that synchronizing the firmware, RTL, hardware verification, and documentation was the greatest pain.  Then 16% voted for register documentation and 16% for hardware verification (like SystemVerilog, Vera, e, SystemC).  The RTL (like Verilog & VHDL) for coding the register-map hardware logic was a pain for 4% of voters and firmware was a pain for 2%.  The live version of the poll is available here, and below is a screenshot of the graph.

SoC Hardware/Firmware register interface pain poll

Snapshot of LinkedIn poll graph

 
That only 2% voted for firmware is surprising to me since when asked where greatest value was received, a SpectaReg.com register-map automation customer indicated that 50% of the value was provided to the firmware developer.  As a result, I would expect that anyone without a register code generation solution would experience a lot of firmware pain.  Perhaps that’s a synchronization pain and the proper solution provides more value for firmware than any other aspect as a result of cross-team synchronization.

For the 41% that did not vote for synchronization, perhaps they have no register map code generation solution, whether it be commercial or homemade.  Perhaps their solution does not sufficiently provide enough value for the option that they voted for.

For the 59% that voted for synchronization, I wonder:

  • How many have a common machine readable data format for specifying registers that can used to generate code?
  • How many auto-generate all deliverables from a common source at the same time using the same code generation (metaprogramming) engine.
  • How many have an in-house vs. commercial solution (like our SpectaReg.com/SpectaReg Onsite or Duolog’s BitWise, Delani’s Blueprint, or Semifore’s CSRCompiler).

Many more polls could be created on these topics.

People are very passionate and opinionated when it comes to in-house tools, open source, register specification file formats, and register-map methodologies in general.   There was heated discussions on LinkedIn about the following topics, which make for good future blog posts:

  • Open source tooling for register address maps, could it work?
  • Is SystemRDL really needed in addition to IP-XACT?
  • Which comes first, the code or the spec?
  • With an in-house register solution, where’s the pain? (relates to Opportunity cost in build vs. buy decisions

If you have thoughts to share, be sure to leave a comment for discussion.  There is some good meat here for future RegisterBits.com postings so stay tuned.

Did you know that LinkedIn allows users to create polls?  I discovered this today and created my first poll to ask my network of SoC developers where their greatest hardware/software register interface pain lies.  Is it the firmware, RTL, hardware verification, documentation, or is it synchronizing all the different perspectives around the common specification?

Click on the below image or link to have your say!  Tell your colleagues too, and of course if you have a comment for discussion post it here.

soc-register-interface-pain

LinkedIn SoC Register Interface pain poll.

http://polls.linkedin.com/p/31486/ovmia

Update: Someone mentioned that they don’t understand the poll because they have an in-house solution that solves these pains. For those with an in-house solution, read the poll as “where is the greatest value from your in-house solution?” I suppose a sixth option, “my in-house solution is the biggest pain” should have also been an option too, especially now that there are commercial solutions available.

This posting examines how object-oriented typing of BitFields abstracts implementation details, and provides extensibility and simplicity.  This is the second in a series of postings.  The first posting provided background info on using object orientation for register specification and code generation.

With SpectaReg, one of the questions that always comes up is “how do I specify the type of register?”

How does one specify that a particular BitField is a read-only status bit, vs. a read-write flop-based control BitField vs. some other type?  With the SpectaReg register generation tool…

  1. Register type selection is easily done using the web GUI (or through XML)
  2. Register typing is generally done at a BitField-level of granularity
  3. Types are defined in an object oriented hierarchy
  4. Types can have custom attributes including references to other instances
  5. New types/classes can easily be added with some open Python
  6. The code generation layer works at the most abstract level that is applicable, to maximize core reuse (thanks to inheritance and polymorphism)

A clarifying example:

To keep things simple, assume an SoC team only uses three types of BitFields in their register maps as defined by the following table.  In reality there would be many more types.

Type Name Type Description
ExportedFlopBitField A basic read/write control BitField.  This is implemented with flip-flops and has an output wire/signal from the register module that goes into the application specific logic.
WatchedExportedFlopBitField Same as the ExportedFlopBitField except this has an additional output wire/signal that goes into the application specific logic and pulses high when a write transaction is decoded.
ExtDrivenBitField A basic read only status BitField.  This is an input into the register module from the application specific logic.

Now, in SpectaReg’s Specification Object Model (SOM) these types of BitFields would be mapped into the following class hierarchy, all inheriting from the BitField base class (i.e. the IP-XACT field element).

Register BitField Class Hiearchy

Register BitField Class Hierarchy

The WatchedExportedFlopBitField is a specialized type of ExportedFlopBitField, which is a type of ReadWriteBitField, which is a FlopBitField, which is a type of BitField.  As is typical for object orientation, “is a” represents inheritance relationships.

Say the user wants to create a new WatchedExportedFlopBitField in an unused bit-space of an existing register.  The user would create a new BitField and tag it with the specific WatchedExportedFlopBitField class using the GUI widget shown in the following screen shot.

BitField Class/Type Selection Widget

BitField Class/Type Selection Widget

At the code generation layer, such inheritance-based typing really simplifies things.  For creating the synthesizable Verilog and VHDL RTL code, the generation layer needs to know specific class typing to create the implementation of the WatchedExportedFlopBitField.  For the firmware and documentation generation, such detail is not required, so the code generation can work at a more abstract ReadWriteBitField classification level.  This is the beauty of polymorphism — the code-generation templates that need specifics can get into the details whereas the ones that don’t can keep it simple.  Keeping it abstract leads to more re-use and less complexity.

Of course, SpectaReg supports many different types/classes of BitFields other than those dicsussed here.  What Register and BitField types do you use in your design?

Register interfaces are an essential pattern in chip design. They provide a way for sequential software to get information into and out of parallel hardware using memory address reads and writes. At conference many years ago (can’t recall if it was DAC or DesignCon) a panel was asked “what is the best way to measure the complexity of a chip?” One proxy mentioned was “the number of pages in the user documentation.” The register section is often the majority of the firmware programmers’ manual… confirming what you probably know… register interfaces are complex in a variety of dimensions.  For the average hardware RTL coder, the register interface is typically not viewed as an object oriented model.  We believe that IT SHOULD BE!

In the center of the `School of Athens by Raphael are Aristotle and Plato, Aristotles hand level to the Earth symbolizing his realism view of Nature; Platos hand pointed towards the heaven symbolizing the mystical nature to his view of the Universe. This image symbols the sharp change in the meaning of how `natural philosophy or physics will be done for the 2,200 years.

In the center of the `School of Athens' by Raphael are Aristotle and Plato, Aristotle's hand level to the Earth symbolizing his realism view of Nature; Plato's hand pointed towards the heaven symbolizing the mystical nature to his view of the Universe. This image symbols the sharp change in the meaning of how `natural philosophy' or physics will be done for the 2,200 years.

Object Oriented Programming (OOP) is well known for its ability to abstract complexity. A quote from Grady Booch (co-founder of Rational Software, IBM Fellow, and widely respected authority on software methodology) puts this into perspective:

… objects for me provide a means for dealing with complexity. The issue goes back to Aristotle: do you view the world as processes or as objects? Prior to the OO movement, programming focused on processes — structured methods for example. However, that system reached a point of complexity beyond which it could not go. With objects, we can build bigger, more complex systems by raising the level of abstraction — for me the real win of the object-oriented programming movement.[source]

If you took CompSci 101 you may have learned about the following principles of OOP:

  • Inheritance - Classes of objects can be extended and specialized to reuse and override existing code.  For example, an InterruptBitfield inherits from BitField to extend it to have specific attributes and behaviour.
  • Encapsulation - Classes of objects have data and methods that they encapsulate.  For example, a BitField has a bitWidth attribute.
  • Polymorphism - Specific classes of objects should be able to play general roles.  For example, an InterruptBitField instance can also play the role of a general BitField

Certainly most SystemVerilog users for design verification will be familiar with OOP, but I’m not sure about the RTL camp.

In building a data structure for modeling the hardware register interface, an OOP language is preferred. We chose Python since it’s interpreted with decent object orientation.  It’s encouraging to hear that python is one of the 3 “official languages” at Google, alongside C++ and Java.

Another consideration with register automation, is how the specifications get persisted and exchanged? We were asking ourselves this question in 2004 when we learned of the SPIRIT Consortium which has a standard now know as IP-XACT, a XML Schema Definition (XSD) for SoC and IP metadata.  For OOP based register specification, we infer from IP-XACT the classes of objects shown in the following SpectaReg Specification Object Model (SOM) diagram.  The diagram is a UML class diagram that uses UpperCamelCase for defining the classes.  We’ll use this convention for referencing classes in this blog.

Specification Object Model (SOM) base classes from IP-XACT

Specification Object Model (SOM) base classes from IP-XACT

This diagram of the SOM doesn’t show the new RegisterFile class of object which we’ll talk about another time.

In English the diagram reads as follows: A Component is composed of MemoryMaps which are composed of AddressBlocks, which are composed of Registers, which are composed of BitFields.  Or in the other direction BitFields exist within Registers, and so on.

There are many different “types” of Registers in the universe of hardware/software Register interface specifications. The type of a Register’s contained BitFields specifies how the Register behaves in software and hardware. Such granular typing permits BitFields in the same Register to have different types.

We’ll continue this discussion in an upcoming posting to illustrate how the SOM simplifies the complexity of register implementation for both RTL and software engineers.  This exists today at SpectaReg.com without requiring the user to write or install any software or feed any code into the register automation tool.

I met Gary Stringham, an embedded systems consultant, at the 45th DAC SPIRIT Consortium meeting in Anaheim where we demonstrated the SpectaReg web-app using IP-XACT.  Since then, I’ve been subscribing to Gary’s excellent Embedded Bridge monthly newsletter, which provides best practices for the hardware/firmware divide.  Gary is a big proponent for register module generation tools like SpectaReg and he recommends such tools as one of his best practices.

Issue #26, of the Embedded Bridge newsletter discusses level-triggered vs. edge-triggered interrupts and makes a good case for using edge-triggered interrupts. Why?  Well, because level-triggered interrupts are painful for the firmware engineer.  Level-triggered interrupts cause extra complexity, extra CPU cycles, and create a possibility for missed interrupts.

Consider the following example…

Imagine you are creating a packet receiver (PR) hardware component. When the PR processes an errored packet, it asserts a status signal (pkt_err_stat) until the next packet comes in. The following table shows the PR’s register bits, which are mapped into addressable registers and are all one bit wide.

Bit Name Access Bit Description
has_int Read Only The PR component has an outstanding interrupt. Read all of the PR component’s interrupt bits to determine the source.
pkt_err_stat Read Only When 1, the PR’s current packet is in error, when 0, the current packet does not have an error.  For each new packet this will always be 0 for at least one cycle.
pkt_err_int_en Read/Write Write 1 to enable the packet error interrupt (pkt_err_int), write 0 to disable/mask the said interrupt.
pkt_err_int Read/Write When 1 an errored packet has been observed. Write 1 to clear this interrupt event.  [Also, describe here whether this is edge or level sensitive.]

When pkt_err_stat is asserted, an interrupt is generated (if enabled).   The interrupt causes firmware to vector to it’s interrupt handler, where it identifies that PR has an interrupt (since has_int for PR is asserted).  Firmware then reads PR’s interrupts to discover that pkt_err_int is asserted.

Level-triggered case: In the case where pkt_err_int is level-triggered and the next packet has yet to be received, then pkt_err_stat will still be asserted.  To exit the interrupt handler, the firmware must disable then clear the interrupt by writing one to it.  The issue now is… when does firmware re-enable the interrupt?  With the interrupt disabled, how does firmware know if the next packet is errored?  Answering these questions from firmware creates un-needed complexity.

Edge-triggered case: If pkt_err_int is an edge-triggered interrupt, then the firmware is simpler and less prone to missing back-to-back errored packets.  To exit the interrupt handler, the firmware simply clears the interrupt.  When the next packet comes in, if it’s errored another interrupt is generated and there is less risk of missing this event.

One objection to edge triggered interrupts, as Gary points out, is that they take up more logic gates.  When I read Gary’s level vs. edge triggered Embedded Bridge issue, I decided to look at SpectaReg’s generated VHDL and Verilog to see how we did our interrupts.  It turns out that we originally only had level-triggered interrupts.  To add support for positive edge-triggered interrupts, the RTL was pretty much identical to the level-triggered, it just required sampling the last value of the status (pkt_err_stat in the example) and using that to determine when to generate the interrupt. If the current value is 1 and the last value was 0 then the interrupt is generated.  This results in one additional flop per edge-triggered interrupt and a little more combinational logic.  The cost is insignificant compared to the benefit.

So…. all you Verilog and VHDL RTL developers, next time you go to create an interrupt bit do the firmware developer a favor and make it edge triggered.