Synthesizable Reports and Assertions

Proposal Details

• Who Updates: DanielKho, ...
• Date Proposed:
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Related: AssertionDirectives

Current Situation

Currently, "report" and "assert" statements are seldom synthesizable. This proposal aims to enable major synthesis vendors to follow a standardized method in the support of synthesizable assertions.

There are many instances where "report" and "assert" are desired to be synthesizable. For instance, when a design needs to be tested, current practice is to design a simulation testbench prior to tapeout, and have a separate team (DFT, BIST, for example) design the hardware test logic for hardware verification. Hardware testing will be performed once the design has taped out. With narrowing time-to-market demands, the DFT team would like to easily convert an existing simulation testbench into a hardware test system. Also, companies may like to streamline their verification teams, so that the hardware DFT team could possibly merge (or work more closely together) with the functional simulation team.

As many testbenches have "report" and "assert" statements, it would be good to allow these constructs to be able to be synthesized.

Requirement

Propose to allow a user-defined interface (see the Block Interfaces proposal) to decorate the "report" and "assert" statements.

For example, if the user wishes to attach a physical interface bus (UART, Ethernet, AXI, Wishbone, etc.) to all report statements within an entity, the user could specify synthesis attributes that attach to those report statements.

type t_cpu_bus is record
    adr : std_logic_vector(15 downto 0); --Address
    dat : std_logic_vector(7 downto 0);  --Data from master to slave=
    ...
end record t_cpu_bus;

subtype t_master is t_cpu_bus port(adr, dat, we, en : out;  sdt, ack, err : in);
signal cpu_bus : t_cpu_bus;

attribute clock of report:type is clk;
attribute address of report:type is cpu_bus.adr;
attribute data of report:type is cpu_bus.dat;

/* Reporting through physical interface. */
process(all) is begin
    report "reporting via ethernet...";
    report "[elapsed]: " & to_string(now);
end process;

Instead of having to write the report / assert statements as subprogram calls, the hardware designer could write the same way as one would when designing testbenches, and still have the text sent through the desired bus interface defined by the interface attributes.

The report statement will implicitly store the string into a string container (strBuf, for example). strBuf will usually be synthesized to memory blocks by synthesis tools. The same report statement is equivalent to:

signal strBuf:string(1 to maxLength);
signal cnt:unsigned(ctrLength-1 downto 0);
type memory is array(0 to memoryDepth-1) of strBuf;
constant strBufCache: memory := (
    "reporting via ethernet..." & (others=>nul),    -- another proposal for "others" here?
    "[elapsed]: " & to_string(now) & (others=>nul)
);

process(clk) is begin
    if rising_edge(clk) then
        if cnt<strBuf'length and strBuf(cnt)/=NUL then
            cpu_bus.dat<=strBuf(cnt);
        end if;
    end if;
end process;

process(reset,clk) is
    variable i: natural := 0;
begin
    if reset then
        i := 0;
        cnt <= (others=>'0');
        write(strBufCache(0));
    elsif rising_edge(clk) then
        if cnt<strBuf'length then
            if strBuf(cnt)/=NUL then cnt<=cnt+1;
            else cnt<=strBuf'length;
            end if;
        else
            write(strBufCache(i));
            cnt <= (others=>'0');
            if i<strBufCache'length then
                i := i+1;
            end if;
        end if;
        strBuf <= strBufCache(i);
    end if;
end process;

The description contains an implicit counter that counts up to the length of the string, or until a NUL character is encountered. The counter holds its value at strBuf'length until the next "report" statement is encountered, during which the counter will reset to 0 and continue counting up until the length of the string.

If the report statement is decorated with synthesis attributes "clock", "address" and "data", the physical interface should be synthesized by the synthesis software. Otherwise, no physical interface will be created by the synthesizer.

Old Proposal

attribute phy: string;
/* 192.168.0.1 = address of physical interface; 1024 = maximum length of string buffer. */
attribute phy of report: type is "192.168.0.2, 1024";

/* then you can use a lot of these in your behavioural model, and have log outputs from the physical interface.
   The string length should be within the specified finite length defined  by the "phy" attribute, otherwise the 
   string is clipped.
*/
report "reporting via ethernet...";

This would be equivalent to having the following bus functional description:

/* x"1234fedc" = address of physical interface. */
logWrite(x"1234fedc","reporting via ethernet...");

Implementation details

Code Examples

Use Cases

Arguments FOR

• Aids hardware verification.
• Helps hardware test engineers convert existing simulation testbenches to harware-based testbenches easily.
• There is already active research in this area. For an example, see this paper: http://cadal.cse.nsysu.edu.tw/seminar/seminar_file_pclee/pdf_1363606622.pdf

Arguments AGAINST

From meeting 2016_MeetingMay26

• Needs more refinement to be actionable.
• Is it include report/assert into gate level netlist or is translate report/assert into some hardware structure?

General Comments

Supporters

-- DanielKho - 2013-11-20

Add your signature here to indicate your support for the proposal