Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Toplevel Simulation Control Signal And Retain Post-Fit Netlist

I am working on a large CycloneIII design using QuartusII v9.0.

In our design we have a toplevel input simulation control signal that is routed to various aspects of the design. This simulation control signal overrides specific elements of the design that would require a lot of simulation time e.g. timers, reset periods etc. Therefore when we build the design for the target application we want to force the simulation control signal in to a disabled state while for simulating the design we wish to have control of this signal and retain the post fit simulation netlist.

In the past we have routed the simulation control signal to a specific pin on the target board and disabled the functionality at the pin i.e. grounded on the PCB. For our latest design I wish to retain the toplevel simulation control input signal but avoid using a physical pin that is not used in the target application.

If I assign the simulation control signal as a virtual pin it retains the post fit netlist (i.e. it does not optimise out the simulation control aspects) but I can't find how I can force a logic level on it. Does it default to a certain state?

Or is there a better way of doing this i.e. generics etc?

Thanks.

14 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thanks josyb.

    I understand what a virtual pin is for but what I would like to determine is what QuartusII internally assigns the virtual pin node too. The help says it uses a LUT for a virtual pin so does this mean it is assigned VCC, GND or left floating? Is the LUT value deterministic?

    Your test results are interesting as it suggests it is assigned to GND but I don't think we could conclude that because a floating node can still produce this outcome.

    I am not sure where to go with this one.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I think this would still cause a problem in the target hardware if a virtual pin results in a floating input as you cannot guarantee the input level, thus this would be sampled and ripple through reg1->reg2-> to the simulation control signal.

    Can someone confirm that a virtual pin results in a disconnected signal i.e. left floating in the target FPGA?

    --- Quote End ---

    It will not propagate due to the latching. Once pin is zero (of floating states) it will be latched by reg2 and reg2 will no longer see the pin
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I made a test for both '0' and '1' at the same time. I had this virtual pin drive a led-blinker, when '0' we have a 2Hz blink, when high a 10 Hz.

    When I connected the initialised to '1' virtual pin, the led flashed a 2Hz, steadily.

    I then connected the initialised to '0' virtual pin, but inserted an inverter along the way, the led flashed at 10Hz, again steadily.

    So I think I am safe to conclude that a virtual in pin of a top level module, the module that ultimately connects the pins, carries a '0' value.

    If you look in the Technology Map Viewer in Post-Fitting mode you can find the LUT you mention, but it has a '0' feeding out ...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    It will not propagate due to the latching. Once pin is zero (of floating states) it will be latched by reg2 and reg2 will no longer see the pin

    --- Quote End ---

    Yeah sorry as you said it does indeed guard against a logic '1' propagating so this would be useful.

    --- Quote Start ---

    If you look in the Technology Map Viewer in Post-Fitting mode you can find the LUT you mention, but it has a '0' feeding out ...

    --- Quote End ---

    That is perfect to prove the point on what QuartusII is assigning that node because it wouldn't be nice leaving parts of the design with virtual pins floating.

    Thanks.