ASIC Design what next? specification for a new language

Given the amount of attention given to developing tools and methodologies for backend and verification design and system architecture look like the step child of semiconductor design.

Verilog is still the default design language, and compared to the first verilog compiler in 1984 the language has not made much progress even through it was revised in 2001 and 2005 and later clubbed with systemverilog.

Almost every language from that era or earlier has either died out, or metamorphised into a new language (e.g. Compare Perl 1 with Perl5 or todays Perl 6)or acquired a huge library set (e.g. CPAN or the Matlab/Octave libraries) which make them relevant to the current environment where design complexity is high and storage and compute resources are cheap.

In contrast the ASIC design field is still stuck in an 3 decade old era. The language built for designers who were hand crafting transistors and laying out custom cells is still being used with hardly any modification.

Today's design requirements

Today when we discuss a design we do not discuss the individual gates. Our discussion is more on larger components like interconnects, gearboxes, FIFO's, memories, hard macro's, analog components etc. We can describe a system in a few words and everyone across the table has a common idea on how it is to be implemented.
I can say "The subsystem needs an 32 bit ahb interface with 1 master and 7 slaves with the addressmap of {s1=>0,s2=>300,s3=>2000,s4=>2300,s5=>2800,s6=>3000,s7=>3700}" and every engineer will know how to design this system either manually or using a tool.
I can say that I need a gearbox from 64to66 bit and an engineer has a picture of what is required.
I can say that I want an asynchronous FIFO with input 32bit@200Mhz packet size 1024 interpacket gap of 12 bytes and idle character as 0x0a0a or packet boundry specified by 4 bit byte enables and again an engineer can go ahead and design an elastic fifo as per my need.

What is the current state of art?

Today we do not have a language to capture these design requirements.

• SystemVerilog has hardly anything to expand the design abstraction,
• IP-XACT is more a storage format to be used by tools but not suitable for humans.
• Among the ESL tools Bluespec comes the closest to meeting the requirements as it supplies a library of common components like fifo's and gearboxes.
• The gui tools are an intermediate solution with limited ability to save changes in a version control system and review it at a higher abstraction level. I am much at ease verifying the port connections in an RTL code compared to figuring out the rat's nest in the block diagram viewer GUI of either DC or Verdi.

What is the proposed solution?

To build a language which extends verilog, This language will allow interfacing with IP-XACT and tools to write compact design representation along with normal verilog code. a sample verilog+ code would look like this.

use ipxact ;
use tool ;
use constraints ;
use sv ;
generate verilog;
module modulename (
ipxact.ahb.master#(32) master,
ipxact.ip1.sysintf ip1sys(remove clk,rst),ip2sys(remove clk,rst),
output wire interrupt,
input wire clk,
input wire reset
);

tool.interconnect.ahbgen ahb_bus #(
type=>'simple,
addressmap=>(
master=>'master','m2',
slave=>(s1=>0,
s2=>300,
s3=>2000,
s4=>2300,
s5=>2800,
s6=>3000,
s7=>3700)
),
)
);
Connect interfaces to the entities
ahb_bus.s1=s1.ahb;
ahb_bus.s2=s2.ahb_bus;
<....>

tool.gearbox gbox_serdes #(in=>(in=>64,out=>66)
gbox_serdes.in<=mux(select=>ip_sel,connect=>(0:s1.data,1:s3.data,2:{s4.data,s4.command,s4.parity},3:{32'b0,bitreverse(s7.data)})
serdes.data<=gbox_serdes.out;

tool.csrgen(spec=>ipxact.regfile1)
s1 s1 (/*normal verilog port list*/);
s2 s2 (/*system verilog interface list*/)
serdes serdes (/*no portlist connected elsewhere in the code*/);
...
endmodule

The above code running in a few tens of line can generate thousands of lines of human readable verilog code when compiled.

Advantage of the above system

• Version control friendly.
• Easy to read and review.
• Integrates existing and new tools from multiple sources.
• Based on and extends verilog.

What is required to build this new language.

• A proof of concept language will require tools for csr gen, interconnect gen, gearbox gen and fifo gen.
• There should be a standard wrapper mechanism to convert the parameters passed in verilog to the batch input format for different tools (e.g. from ARM, Xilinx, Synopsys etc.)
• Not every engineer will have access/license for the code generators so we should check whether the data for wrapper has changed before failing on tool invoke.
• There should be a mechanism to integrate the generated code.