Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding task to fault #306

Open
Kuree opened this issue Apr 26, 2021 · 4 comments
Open

Adding task to fault #306

Kuree opened this issue Apr 26, 2021 · 4 comments

Comments

@Kuree
Copy link
Collaborator

Kuree commented Apr 26, 2021

I'm in the process of rewriting tbg to support more complex configuration semantics. One challenging part is to dynamically select signals based on the signal values. It's typically done via driver tasks in SV-based testbench.

Most of the logic are already there, such as set values (poke), loop, and if. I think the only additional feature is how to create a task definition, in particular, input and output variables.

@leonardt
Copy link
Owner

Could we do it similar to how we handle loops/if? E.g. task1 = tester.create_task() and task1 provides the tester interface for doing the actions? Seems like we could track a list of tasks and generate code for them pretty easily. I'm guessing we need to add code to start the tasks and/or hook them up to the DUT?

@Kuree
Copy link
Collaborator Author

Kuree commented Apr 27, 2021

Could we do it similar to how we handle loops/if? E.g. task1 = tester.create_task() and task1 provides the tester interface for doing the actions? Seems like we could track a list of tasks and generate code for them pretty easily.

Yes this is what I have in mind.

I'm guessing we need to add code to start the tasks and/or hook them up to the DUT?
Calling task is the same as calling a function. I think the pysv integration already added function call code gen, so that should be easily extended.

If we only focus on TB-side tasks, i.e. tasks used to drive DUT interface, I think we can just directly generate it in the top scope, which should work out just fine. There are several things to consider, however:

  1. Usually there are timing control inside a task, e.g. wait for next clock cycle etc. We definitely should support that. Ideally it should work with loops/if as well, i.e. control statement inside a task.
  2. Tasks in Verilator driver can be directly generated as cpp functions, where the first argument is the DUT pointer. I think this is the easiest way to implement.

Please let me know what you think.

@leonardt
Copy link
Owner

That all sounds reasonable. Do the timing controls usually use the SV wait statement?

@Kuree
Copy link
Collaborator Author

Kuree commented Apr 28, 2021

Usually it's things like

@(posedge clk);
// or
@(value);
// or event
-> event_var;
// and then
@(event_var)

@ is more commonly used for clock and events, whereas wait is used for expressions.

If default clocking is set, sometimes people just do ##1 to skip to next clock cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants