Generative AI for Silicon Design – Article 3 (Simulate My Design)

Generative AI has time and again showcased its power to understand, predict, and explain a myriad of phenomena. Beyond its famed applications in art and text, it’s making ripples in the niche realm of hardware engineering. In this article, our exploration focuses on the potential of Generative AI to comprehend and predict intricate behaviors integral to hardware design simulation. Using a contemporary Generative AI model, we examined how it interprets intricacies of typical hardware modules in simulated environments.

Experiment 3: Simulate My Design

Our latest experiment centers on the capability of Generative AI to understand and predict the behavior of hardware arbiters, which are quintessential in managing access to shared resources in digital designs. Using OpenAI’s GPT4, we assessed the intricate behavior of an arbiter module (sourced from https://github.com/lowRISC/opentitan/blob/master/hw/ip/prim/rtl/prim_arbiter_tree.sv), a predictable round-robin arbiter tailored for multiple requestors. Make no mistake, the second test result shown below proves that Generative AI really understood the “tree” implementation and did not suggest the behavior of a general round-robin arbiter.

Generated Simulations (Validated Against Actual Simulations)

Prompt 1 (test 1):
For 8 number of requestors, and ready_i always asserted, what will be the sequence of grants if all the requests are constantly asserted?

Response 1:
For a constant request vector of [1 1 1 1 1 1 1 1] and with ready_i always asserted, the prim_arbiter_tree module will rotate the grant through the requestors in a fair manner. The behavior of the arbiter is designed to mask out the recently granted requestor and prioritize other pending requests. This way, the arbiter ensures that every requestor gets an equal opportunity in a round-robin fashion.

Given the design of this arbiter, if all requestors are constantly asserting their request, the sequence of grants will be:

Requestor 0 (assuming the arbiter starts with this one by default)
Requestor 1
Requestor 2
Requestor 3
Requestor 4
Requestor 5
Requestor 6
Requestor 7
And then back to Requestor 0, and so on in a loop.
In terms of gnt_o output:

[1 0 0 0 0 0 0 0]
[0 1 0 0 0 0 0 0]
[0 0 1 0 0 0 0 0]
[0 0 0 1 0 0 0 0]
[0 0 0 0 1 0 0 0]
[0 0 0 0 0 1 0 0]
[0 0 0 0 0 0 1 0]
[0 0 0 0 0 0 0 1]
Then back to [1 0 0 0 0 0 0 0], and so on.
The grants will continue in this manner as long as all requests are constantly asserted and ready_i remains asserted.

Prompt 2 (test 2):
For 8 number of requestors, and ready_i always asserted, what will be the sequence of grants if all the requests are toggling between 1 and 0?

Response 2:
If all the requests are toggling between 1 and 0, the sequence in which they toggle will matter. Let's assume all requestors toggle simultaneously, meaning in one cycle all are 1 and in the next cycle all are 0, and then back to all 1, and so on.

Given the behavior of the prim_arbiter_tree module and based on the design, if ready_i is always asserted:

Cycle 1: req_i = [1 1 1 1 1 1 1 1] - Requestor 0 gets granted as it has the highest priority.
Cycle 2: req_i = [0 0 0 0 0 0 0 0] - No grant because no request is asserted.
Cycle 3: req_i = [1 1 1 1 1 1 1 1] - Requestor 1 gets granted. Requestor 0's request is masked out because it was granted in the most recent cycle when there was a request.
Cycle 4: req_i = [0 0 0 0 0 0 0 0] - No grant.
Cycle 5: req_i = [1 1 1 1 1 1 1 1] - Requestor 2 gets granted.
...and so on.
The sequence of granted requestors will be: 0, 1, 2, 3, 4, 5, 6, 7, and then it will loop back to 0.

This pattern is a result of two combined behaviors:

The arbiter's built-in round-robin prioritization.
The synchronous toggling of all request signals.
Since requests are off every alternate cycle, each requestor gets a turn when its respective request signal is on.

Imagine AI-driven Hardware Simulations

Picture a scenario where AI helps you query your hardware design without the need of setting up a full-fledged simulation testbench, allow you to test your DUT for sanity, conduct design exercise (understand high-level behavior of a design), without really firing up your EDA simulator. Preliminary results are promising, and it’s evident that with further advancements, AI will solidify its position in the hardware simulation toolkit.

Challenges and Forward Momentum

Navigating this pioneering terrain isn’t devoid of challenges. While AI offers impressive predictions, these must be meticulously validated against actual hardware simulations to ensure accuracy and reliability. Depending solely on AI without empirical verification can be perilous. Additionally, while AI is adept at recognizing standard patterns, nuanced corner cases might demand traditional evaluation methods.

In Closing

The integration of AI into hardware design simulation is an exciting frontier, promising a blend of innovation and efficiency. As we continue to traverse this path, the symbiotic relationship between AI and hardware design simulation hints at a future filled with unprecedented possibilities. The next chapter in hardware design is unfolding, and it’s an exhilarating era for all stakeholders involved!

Also Read:

Generative AI for Silicon Design – Article 2 (Debug My Waveform)

Generative AI for Silicon Design – Article 1 (Code My FSM)