Activity

I have pushed the updated code to the main branch now.

Hi Michael,
Unfortunately this impacts all OSVVM VC. So the same change is needed for the UartTx.

Are you using sources from OSVVM.org or GitHub? I have updated the GitHub dev branch. I will update the main branch tomorrow. If you are using sources from OSVVM.org, I will update them too, otherwise, they will be updated when 2022.05 is…[Read more]

I went ahead and changed the code and it fixed the issue. Thank you!

One more quick question, my DUT also does the reverse… takes data from 21 UARTs and mux’s it all to one serial output. So while I haven’t gotten around to it yet, the next part of my test bench is going to have 21 UART_TX VC’s in it.

Would I be correct in assuming that I…[Read more]

Thanks for the quick response Jim! I will try to get it working on my end in the meantime, just for the sake of getting deeper into the weeds with OSVVM.

I am simulating with Aldec Riviera Pro v.2019.10

Regards,
Michael

Hi Michael,
Thanks for the long winded question – it gives me the information I need.

It looks like the instance name is the same for all instances of the UART.
As a result statement that constructs the ReceiveFifo is connecting them all
together. Currently this:

ReceiveFifo <= NewID("ReceiveFifo", ID, ReportMode => DISABLED) ;

It is…[Read more]

Hi Steve,
Thanks for the update. I have plans to test with Xcelium 22.03 soon.
Looking forward to seeing the results.

Best Regards,
Jim

Hi Jim,

Thanks again for everything you do! I am just following up regarding full OSVVM support in Xcelium. Xcelium 22.03 was just released. It includes support for VHDL-2019 conditional analysis (pleasant surprise!) along with additional support of VHDL-2008 language features/constructs. OSVVM 2022.01 is pre-packaged, but I believe it is…[Read more]