BEGIN:VCALENDAR
VERSION:2.0
PRODID:Linklings LLC
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20260730T152728Z
LOCATION:DAC Pavilion\, Exhibit Floor
DTSTART;TZID=America/Los_Angeles:20260728T170000
DTEND;TZID=America/Los_Angeles:20260728T180000
UID:dac_DAC 2026_sess295_ENGPOST275@linklings.com
SUMMARY:Beyond Scripting: API Based HDL Generation
DESCRIPTION:Jack Greenbaum (INTEGRITY Security Services)\n\nLooking at the
  block diagram of any modern SoC – whether a standalone device or a chiple
 t – and you will see that most of the blocks, and die area, consists of ge
 nerated logic. From regular structures like RAMs and ROMs, to semi-regular
  structures like control/status register and NoCs, to entire processors, t
 he HDL source and other input files for these blocks is produced by toolin
 g from a higher-level specification, not typed by designers or output by A
 I. My work revolves around raising the level of abstraction used when writ
 ing HDL generators beyond scripts that output text. I propose that generat
 ors should not generate HDL text directly as with a "script", rather gener
 ators should be written with an API to assemble the HDL for output. This a
 ssures that the generator can only output syntactically valid HDL, and tha
 t errors are reported in the context of user input. This is especially imp
 ortant when an HDL generator is product, where failures and poor error rep
 orting result in higher support costs for vendors, and poor outcomes for c
 ustomers.\n\nTopics: AI, Chiplet, Design, EDA, Quantum, Security, Systems\
 n\n
END:VEVENT
END:VCALENDAR
