Origen-SDK / origen_sim

Plugin to enable Origen patterns to be run in a dynamic Verilog simulation
MIT License
1 stars 4 forks source link

Add ability to drive async clks during simulation #51

Open ginty opened 3 years ago

ginty commented 3 years ago

This PR adds the ability to drive a free-running clk on a pin during simulation via this API:

pin(:my_pin).drive_clk(4.ns, 8.ns)  # On duration, Off duration

Here is a picture of an osc clk produced by this feature alongside a tck clock generated by the pattern timing:

image

This will be most useful when running an IP-level simulation where the IP has a clk input which would normally be supplied by the SoC (rather than the ATE). Until now such cases have had to be derived from the vector/pattern timing which makes it much harder to produce for the user.

Aside from scratching this itch, the primary motivation for this was to trial a hware/RTL-based (pin) wave driver rather than one which uses VPI callbacks (as used for all other waveforms currently produced by OrigenSim). The VPI callback method is slower and is the main reason for OrigenSim performing slower in benchmarks vs other virtual tester tools.

For O2, the goal is to use this type of pin driver across the board and have Origen simply download the timing to each driver whenever the timeset is specified and then let the simulation freerun during wait events.

So here is the prototype driver - https://github.com/Origen-SDK/origen_sim/blob/52995264f2f49345175b11cd3254fc4564826711/templates/rtl_v/origen.v.erb#L131-L201

It supports 8 timing edges per period, which I think is the same as the V93K and probably more than the Teradynes, though it could be easily increased if required. Origen will set the timing for each driver by writing to the time t0-t7 variables and then updating the data and other configuration regs as required.

The final O2 driver will be more full-featured (e.g. supporting compare in addition to drive) and would also be synchronized to a global heartbeat representing the pattern cycle period rather than being free-running like this one (though it would still have an optional async mode like this one). i.e. the main loop would be @(posedge heartbeat) rather than while(1) like we have here. It will also likely have some performance optimizations, e.g. such as doing no edge tracking in the common case of driving for a complete clk cycle.

I did a prototype of the heartbeat too, but I've commented it out for now since it would just be doing un-necessary simulation work in the O1 simulations:

https://github.com/Origen-SDK/origen_sim/blob/52995264f2f49345175b11cd3254fc4564826711/templates/rtl_v/origen.v.erb#L7-L25

Finally I made the simulation timescale introspection a bit more robust, adding the ability to now interogate the timeunit and the precision. These are mainly intended for internal use by OrigenSim and are not documented in the user guides.

I plan to hard fork OrigenSim from this point into O2 soon and don't have any plans to further enhance O1 in this direction.

@redxeth be aware of this update as it's pretty useful for the IP-level simulations your team does.

mathieuperret01 commented 1 year ago

Hi All, Just discovering that PR, which seems to be very handy, and I would really like to be able to use that. Can it be merged ? Thanks.

ginty commented 1 year ago

Hey @mathieuperret01, nice to hear from you, hope you're well.

Yeah this feature does look quite useful, I guess it just got forgotten about when I left.

@coreyeng, any objections to merging this?

coreyeng commented 1 year ago

This shouldn't break anything current, correct? I've been working on a branch anyway with my wreal stuff so I think its fine.

mathieuperret01 commented 1 year ago

Hi All, Can we merge that PR also ? I think in combination with the other PR, we could have a gem tag update ? Thanks.

redxeth commented 1 year ago

@ginty would you be merging this or @priyavadan or who will do? @mathieuperret01 could do but he doesn't have Origen Core team priveleges? Should he have permissions perhaps?