Activity

OSVVM supports 2 processes for interrupt handling. See https://github.com/OSVVM/Documentation/blob/main/InterruptHandler_user_guide.pdf for details.

It uses 2 separate records. Control flow automatically switches to the interrupt handling process when an interrupt is pending. As described in the user guide it requires a specific interrupt…[Read more]

I use the Axi4Lite Manager as a master to access an AXI slave in the DUT. I need a solution to access the AXI slave from both the processes whcih I an currently not able to because of the multiple detect error. The AXI slave does have a memory as well as register map for configuration. And the interrupt comes from the slave indicating an arriving…[Read more]

Can you describe what you are doing.

While you can release the record there are other approaches.

For interrupt handling, OSVVM has an interrupt handler. See the common (MIT) repository in OsvvmLibraries.

You can also directly access OSVVM memories – no transaction record required

Out teaching OSVVM this week so it is harder to give…[Read more]

Hi Charles,
Currently OSVVM does not have control of where the Xilinx library goes. While we want it to go in the VHDL_LIBS directory, currently it is not.

Once we have control of where the library is, then to have two projects share the same compiled image of OsvvmLibraries we need to have a separate place for the OsvvmLibraries and the…[Read more]

Actually both, to have a robust test.

For the former, just to be clear, , I have an AxiStreamReceiver and I am testing my DUT which has an axis master. So, I want to assert in the TestCase tready before tvalid or after tvalid (1, 2, n clock cycles). Is that what you meant? Is there any example to follow?

Do you need this as strict “on” and “off” for tready or do you need e.g. random back-pressure on the bus?

I think for the latter we need @JimL answer. For the former, you can setup a coverage model, which acts as a distribution function. This CovModel can be handed over to the receiver to randomly accept data or delay reception.

Hi Patrick,

Thank you for the clear answer. Makes total sense to skip the post-synthesis simulation then for my purpose. I am in fact using the OSVVM AXI Stream components which have tpd. I have a design with mainly several axi streams, so I am following the testcase OsvvmLibraries/AXI4/AxiStream/TestCases/TbStream_SendGetDemo1.vhd.

I need to…[Read more]

Usually, you can trust the synthesis tools. If you really mistrust them, you should skip post-synthesis and post-placement simulation and go to post-routing simulation. Post-synthesis is just after synthesis without optimization, placement and routing. So you would miss critical parts in the transformation from VHDL to bitstream.

Please keep in…[Read more]

I am using Vivado, with behavioral simulation for debugging and step-by-step investigation. Then, I can run all the tests with GHDL, because as you said, Vivado is very slow.

I am getting the same results in behavioral simulation in vivado and also in GHDL. As I want to be sure that post-synthesis works without generating a bitstream (which…[Read more]

I don’t advertise simulations with Vivado xSim
* very low speed (>10x) compare to commercial simulators or open-source simulators
* creates masses of output data (multiple GB where others write just a few MB)
* explicit VHDL features like range checks need to be activated by the user (if not, xSim doesn’t produce correct simulation results…[Read more]

Update: I re-transmitted again and on the second batch of data, then a_ready_in is asserted the clock cycles I set with RECEIVE_READY_DELAY_CYCLES. See here: https://ibb.co/MxD4D0fF

Is there any specific reason? Is it possible to set at the beginning of the process whether tready should be 1 or 0?

Hi Jim,

Are there any updates on this?

I am also looking to not having tready asserted by the receiver at the beginning, but instead using RECEIVE_READY_BEFORE_VALID=FALSE and RECEIVE_READY_DELAY_CYCLES to assert tready after tvalid is asserted. See here https://ibb.co/jZVyy9ZH
Thank you.

ps: Do you have a new and updated documentation for the…[Read more]

Hi Jim,

Are there any updates on this?

I am also looking to not having tready asserted by the receiver at the beginning, but instead using RECEIVE_READY_BEFORE_VALID=FALSE and RECEIVE_READY_DELAY_CYCLES to assert tready after tvalid is asserted.

Thank you.