1. Vayavya Labs 2009

2. Agenda
 About Vayavya Labs
 Our Vision for ESL (Electronic System Level)
 About DDGEN
Vayavya Labs 2009

3. About Vayavya Labs
 System Level Design Tools and Embedded Design
services company
 Markets :
– Semiconductors and
– Embedded Design Services
 USP :
 Significant improvements in TTM, QOR, COR
 A new market segment for device driver generation
World’s first automated device driver generator
(US patent pending)
Vayavya Labs 2009

4. Agenda
 About Vayavya Labs
 Our Vision for ESL
 About DDGEN
Vayavya Labs 2009

5. Pain Points in Lower Layers -1
Application, GUI etc  PainPoints
 Hardware/software
integration – aka device
Middleware Protocols
drivers
Operating System &
 Market Needs
Associated Components  Productivity improvement
tools
Firmware & Device Drivers  Golden reference model
for the hardware
enabling auto-generation
Embedded hardware of the drivers/firmware
Vayavya Labs 2009

6. Pain Points in lower layers -2
Number of SOCs 2(X86 and MIPS
based)
App Domain CE, DTV
Operating System MontaVista Linux
On chip peripherals(drivers) 23
On board peripherals(drivers) 7
Effort for first release of firmware/drivers 78
Team Size 14
Engineering Support Team 5
Automatic Generation of device drivers can significantly reduce the overall cost
& efforts
Vayavya Labs 2009

7. Tools Evolution
 Hardware and Software
differ in abstractions and
ESL 2.0 design flows
 Vayavya bridges the
2000 & now ESL UML
design flows
HDL HLL
 Reuse
90’s & later
 Common Framework
80’s & later Schematics Assembly  Automatic code
generation
Vayavya Labs 2009

8. Agenda
 About Vayavya Labs
 Our Vision for ESL
 About DDGEN
Vayavya Labs 2009

9. Conventional way of device driver
development
Software
architecture
considerations
IC Team
8.1 LINE CONTROL
REGISTER
Data sheet .... Details on each of
bits in .. SW Team
F()
{
Device Drivers
// …
}
F
Currently ad-hoc Methods (Word, Excel etc.) used to communicate
information among IC and Software teams
Vayavya Labs 2009

10. DDGen Use case
Device Driver writer • DDGEN methodology helps
formalize communication
DPS file RTS file between hardware and
1. Registers 1. OS software teams
2. Interrupts 2. ISR
3. Features 3. buffer
4. … 4. …
DDGen
DPS: Device Program Sequence
RTS: Run Time Specification
Device Drivers F()
DDGen: Device Driver Generator
{
//
Vayavya Labs 2009
}F

11. Software Space exploration using
DDGEN
Device Driver writer
Sync/Async
DPS file RTS file
1. Registers 1. OS
2. Interrupts 2. ISR Blocking/non- Buffering Polling/
3. Features 3. buffer
4. … 4. … blocking API • Pingpong Interrupts
• Circular
Split/Single ISR
DDGen
Effective exploration of software design by
relevant specification in RTS. Think in
F()
{ // problem domain than implementation domain
Device Drivers
}F
Vayavya Labs 2009

12. DDGEN- Product details
 ~300% productivity gain in device driver
development
 Generates
 ANSI C code including OS calls. Fully
functional device driver
 Unit test code of device driver
 Supports DDGen
 A range of device complexities: UART,
I2C, USB, Ethernet, PCI, PCI Express, …
 IP-XACT compliant input
 Many popular OS drivers, including null
OS
Vayavya Labs 2009

13. DDGEN derived utilities
 DocGen
– Generates HTML documentation for the device
 RegGen
– Generates HDL code for the register banks of the device
from the register specification in DPS
 Verigen
– Generates SystemVerilog test bench template for
functional verification
Vayavya Labs 2009

14. DPS Entities
 Device Specification
 Register Specification
 Interrupt Specification
 Feature Specification
 FIFO Specification
 Bus Specification
Vayavya Labs 2009

15. Device Specification
device_spec
{
device_name = pc16550D;
manufacturer_name = "National Semiconductors";
device_version = "D";
device_class = STD_D_C;
device_input_clock = 1.8432M, 3.072M, 18.432M;
}
Vayavya Labs 2009 15

16. Register Specification
8.1 LINE CONTROL REGISTER
CONTROL_REGISTERS {
.... Details on each bit follow:
LCR [8] @ 1 {
Bits 0 and 1: These two bits specify the number of bits in each transmitted or received serial character.
type = RW;
The encoding of bits 0 and 1 is as follows: field wls <0:1> {
Bit 1 Bit 0 Character Length type = RW;
0 0 5 Bits clearing_mode = DC;
value_on_reset = 0;
0 1 6 Bits
enum {
1 0 7 Bits FiveBit = 0;
1 1 8 Bits SixBit = 1;
SevenBit= 2;
Bit 2: This bit specifies the number of Stop bits transmitted and received in each serial character. If bit 2
is a logic 0, one Stop bit is generated in the transmitted data. If EightBit= 3; 1 when a 5-bit word
bit 2 is a logic
} generated. If bit 2 is a logic 1 when
length is selected via bits 0 and 1, one and a half Stop bits are
field stb <2:2> {
either a 6-, 7-, or 8-bit word length is selected, two Stop bits are generated. The Receiver checks the
first Stopbit only, regardless of the number of Stop bits selected. = RW;
type
clearing_mode = DC;
Bit 3: This bit is the Parity Enable bit. When bit 3 is a logic 1, a Parity bit is generated (transmit data)
value_on_reset = 0;
or checked (receive data) between the last data word bit and Stop bit of the serial data. (The Parity
enum {
bit is used to produce an even or odd number of 1s when the data word bits and the Parity bit are
OneStopBit = 0;
summed.) OneAndHalfStopBit = 1 when(LCR.wls==0);
Bit 4: This bit is the Even Parity Select bit. When bit 3 is a logic 1 and bit 4 is a=logic 0, an odd number
TwoStopBit 1 when(LCR.wls==1||2||3));
}
of logic 1s is transmitted or checked in the data word bits and Parity bit. When bit 3 is a logic 1 and
} checked.
bit 4 is a logic 1, an even number of logic 1s is transmitted or
. . . (contd.)
Vayavya Labs 2009

17. Interrupt Specification
interrupt_spec {
interrupt_pending = IIR.IntPend(0) ;
IIR.IntID(RxLineStat) {
int_type = error ;
enable_field = IER.elsi(1) ;
disable_field = IER.elsi(0) ;
clear_field = COR LSR ;
source_field = LSR.pe(1)
|| LSR.oe(1)‫‏‬
|| LSR.fe(1)
|| LSR.bi(1)
||LSR.erxfifo(1);
}
IIR.IntID(RxDataAv) {
int_type = device_read ;
enable_field = IER.erbfi(1) ;
disable_field = IER.erbfi(0) ;
clear_field = AUTO_CLEAR ;
}
IIR.IntID(TxRegEmpty) {
int_type = device_write ;
enable_field = IER.etbei(1) ;
disable_field = IER.etbei(0) ;
clear_field = AUTO_CLEAR ;
}
}
Vayavya Labs 2009

18. Feature specification
PROGRAMMABLE BAUD GENERATOR
The UART contains a programmable Baud generator that is capable of taking any
clock input from DC to 24 MHz and dividing it by any divisor from 2 to 216- 1. The
output frequency of the Baud Generator is 16 X the Baud [divisor# = (frequency
input) / (baud rate X 16)]. Two 8 bit latches store the divisor in a 16-bit binary
format. These divisor latches must be loaded during initialization to ensure proper
operation of the Baud Generator. Upon loading either of the configure_baud_rate
feature divisor latches, a 16-bit
baud counter is immediately loaded. Table III provides decimal divisors to use with
{
crystal frequencies of 1.8432 MHz, 3.072 MHz and 18.432 MHz, respectively. For
input int baud (50,75,110,9600,128000);
baud rates of 38400 and below, the error obtained is minimal. The accuracy of the
local int Divisor;
desired baud rate is dependent on the crystal frequency chosen. Using a divisor of
zero is not recommended.
Divisor = DEVICE_INPUT_CLOCK
/(baud * 16);
LCR.dlab = TRUE;
DLL = Divisor & 0x00ff;
DLM = (Divisor >> 8) & 0x00ff;
LCR.dlab = FALSE;
}
Vayavya Labs 2009 18

19. FIFO Specification
FIFO Rcv{
associated_feature_name = device_read;
enable_field = FCR.FifoEnb(1);
enabled_status_field = IIR.FifoEnbd(1);
max_fifo_size = 16;
fifo_size = FCR.RcvTrgr;
}
FIFO Tx{
associated_feature_name = device_write;
enable_field = FCR.FifoEnb(1);
enabled_status_field = IIR.FifoEnbd(1);
max_fifo_size = 16;
fifo_size = FCR.RcvTrgr;
}
Vayavya Labs 2009 19

20. Bus Specification
 Example 1: (UART)
bus_spec
{
register_acces_type = memory_mapped, io_mapped;
}
 Example 2:
bus_spec
{
register_acces_type = memory_mapped, io_mapped;
data_transfer_type = spi, i2c;
spi_mode = 1,2;
base_address = 0xA000 – OxB000;
}
Vayavya Labs 2009 20

21. RTS Entities‫‏‬
 Processor Specification  Entry point Spec
 OS Specification  Code Gen Spec
 ISR Specification  Buffer Spec
 BSP Specification  Compiler Spec
 Bus Specification
 Error Handling
Specification
Vayavya Labs 2009 21

22. RTS for UART
Processor Specification BUS Specification
BUS_SPEC
PROCESSOR_SPEC {
{ REG_ACCESS_TYPE=MEMORY_MAPPED;
PROCESSOR_NAME = ARM9 ;
TRANSFER_MODE = PIO;
CLOCK_FREQ = 32Mhz;
} BASE_ADDRESS = 0x22;
}
ISR Specification BSP Specification
BSP_SPEC
ISR_SPEC {
{ DEVICE_INPUT_CLOCK = 3.072MHz ;
ISR_TYPE = single; }
ISR_DRIVER_SYNC = global_var;
ISR_NO = 7;
}
Vayavya Labs 2009 22

23. continued...
OS Specification Entry Point Specification
OS ENTRY_POINT
{ {
OS_NAME = LINUX ; QUALIFIER = blocking;
RE_ENTRANCY = }
BLOCK_BY_DISABLING_INTERRUPTS;
KERNEL_VERSION = “2.6.22”;
VIRTUAL_MEMORY = YES;
} Error Handling Specification
ERROR_HANDLING
{
RETRY = 3;
TIMEOUT = 9ms;
}
Vayavya Labs 2009 23

24. continued...
Compiler Specification Codegen Specification
COMPILER_SPEC CODEGEN_SPEC
{ {
COMPILER_NAME = GCC ; field_usage_comments = yes;
} TYPEDEFS
{
int = int32 ;
Buff Specification char = int8 ;
BUFF_SPEC }
{
}
BUFF_MANAGEMENT = DRIVER;
RECEIVE
{
BUFFER_TYPE = circular;
MTU = 256;
}
}
Vayavya Labs 2009 24

25. Pilot Results
Customer-1
Device Details SoC for entertainment platform
Peripherals on SoC LCD, PIO, Interrupt Controller, Timers
Application code size, for manual written drivers 5 KB
Application size using tool generated drivers 5.28KB
No. of days for manual drivers writing 17 days
No. of days for drivers generation (by tool) 6 days
Effort and Time savings Close to 200%
% Code size overhead (by use of tool) 5.6%
Vayavya Labs 2009

26. Pilot Results -2
Customer-2
DMA, Interrupt handler,
Event Handler, Clock
Device Details distribution Unit
Device Specification Capture 19 Days
Validating driver code for functionality 10 days
Integrating driver code with environment 2 Days
Total number of days for automated driver generation 31 Days
Total number of days for manual driver generation ( approx) 90+ days
Effort and Time savings > 300%
Vayavya Labs 2009

27. Business Model
 Target
 Semiconductor firms
• SOC, ASIC, FPGA
• IP vendors
 VLSI and Embedded system design services firms
 OEMs/ODMs
 EDA and embedded tools vendors ( partnerships)
 Business model
 Tool licensing
 Design Services using tool – optimised cost & time benefits
 Tool customization and value-add services
Vayavya Labs 2009

28. DDGEN Roadmap
Sept 2009 Dec 2009 June 2010
Optimization DM355 support ModelGen 1.0
knobs
Eclipse GUI
IPXACT Vendor
BSPGEN 1.0
Extensions
CMSIS support
Vayavya Labs 2009

29. Thank You
Vayavya Labs 2009