Open ginty opened 3 years 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.
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?
This shouldn't break anything current, correct? I've been working on a branch anyway with my wreal stuff so I think its fine.
Hi All, Can we merge that PR also ? I think in combination with the other PR, we could have a gem tag update ? Thanks.
@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?
This PR adds the ability to drive a free-running clk on a pin during simulation via this API:
Here is a picture of an
osc
clk produced by this feature alongside atck
clock generated by the pattern timing: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 thanwhile(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.