% render "layouts/guides.html" do OrigenSim supports analog/mixed-signal (AMS) simulations via real-number modeling (RNM), whereby top-level pins can be defined as real wire types (WREALs) and then Origen APIs can be used to drive and measure real number values from them. By default, OrigenSim's built in simulation setups will run a digital simulation, allowing such real number inputs to be used by behavioral models within that DUT which can themselves output real numbers to be observed on the DUT's pins by Origen APIs. The DUT could also contain full electical models which consume the real number inputs, in that case a [custom simulation configuration](<%= path "guides/simulation/environment/#Custom_Simulator_Configuration" %>) will be required to define the run command to start the simulation. #### Building Support for AMS Simulation AMS support must be added in when building the testbench, this is done by adding the `--wreal` switch to the `sim:build` command: ~~~text origen sim:build path/to/my_dut.v --wreal ~~~ By adding this switch, any pins which are defined as `wreal` types within the given top level will be assigned an analog pin driver by the testbench rather than a digital driver which is the default. Pins can be defined as a `wreal` type either by adding the `real` type to their definition: ~~~verilog input real vddc, ~~~ or by adding a `wreal` wire within the module body: ~~~verilog wreal vddc; ~~~ Here is an example which uses both approaches to declare the `vdd` and `ana` pins as analog pins whenever the `USE_WREAL` define is enabled: ~~~verilog module my_dut( input tck, tdi, tms, trstn, input rstn, input [31:0] din, input p1, input p2, `ifdef USE_WREAL inout real vdd, `else inout vdd, `endif output tdo, output done, output [15:0] test_bus, output [31:0] dout, output ana ); `ifdef USE_WREAL wreal ana; `endif endmodule ~~~ A digital testbench for this would be built via this command: ~~~text origen sim:build path/to/my_dut.v ~~~ while AMS support would be added by running: ~~~text origen sim:build path/to/my_dut.v --wreal --define USE_WREAL ~~~ #### Origen Application Configuration Within the corresponding Origen DUT model of the design, the wreal pins should be declared as either an analog, power or ground pins. From the above example, the wreal pins could be modeled like this: ~~~ruby add_power_pin :vdd # Could also be a regular analog pin too, if you prefer add_pin :ana, type: :analog ~~~ See the [Pins Guide](<%= path "guides/models/pins" %>) for more information on modeling pins in Origen. #### AMS APIs With all of the AMS configuration done, real values can now be driven and read from Origen application code during a simulation like this: ~~~ruby dut.power_pin(:vdd).drive(1.25) dut.pin(:ana).read # => 0.7 # .measure is available as an alias of read for analog pins dut.pin(:ana).measure # => 0.7 ~~~ The `peek`, `poke` and `force` methods from [the Direct DUT Manipulation APIs](<%= path "guides/simulation/direct" %>) are also available to manipulate real valued nets during simulation. The analog pin APIs will not work correctly when generating a pattern for an ATE and the application code is responsible for handling them safely, typically like this: ~~~ruby # Example of a simulation-only assertion if tester.sim? measured = dut.pin(:ana).measure if measured != 0.3125 OrigenSim.error "Expected to measure 0.3125V from the ana pin, got #{measured}V!" end end ~~~ It is easy to build more complex functionality in your application code from these simple APIs, for example to ramp a vdd pin: ~~~ruby # Ramp up the power on VDD v = 0 dut.power_pin(:vdd).drive!(v) until v >= 1.25 v += 0.05 dut.power_pin(:vdd).drive!(v) # Note the use of drive! here which will generate a cycle end ~~~ It is hoped that the community will contribute plugins that contain higher-level functionality like this to make such functions available off-the-shelf in the future. % end