Forum Replies Created
August 8, 2022 at 23:46 #2048
Thanks so much for the support! We really appreciate it!June 29, 2022 at 19:10 #2018
Thanks for the info! I am planning on making one VC that encapsulates both tx and rx, but takes two transaction interfaces so that you can send and receive independently. Similar to how you mentioned in your first paragraph.
Due to how much the tx and rx need to talk to each other with regards to flow control and intialization, I am thinking of setting up the SpaceWire VC to use the rx and tx fifo that comes with the protocol to interface with the transaction records.
For example, a send command would write the data into the tx fifo, which would then alert the VC that data is ready to be transmitted. The VC would then initalize the link (if not yet initialized) and interleave the data in the tx fifo with the flow control tokens and time codes as necessary. If the tx fifo is empty and the link is connected, then it would simply send null characters until either the link is disconnected or there is data in the tx fifo.
A get command would poll the rx fifo to see if the SpaceWire has received data. The VC internals would take care of managing the flow control tokens being sent out. The SpaceWire VC would continue to receive data until it has run out of flow control tokens and would only allow more data to be read in as you pull it out the other end of the fifo using the get commands (essentially replenishing the flow control token count).
You don’t necessarily have to comment on this, unless you see an obvious error! I am mostly thinking aloud.
Thanks again!June 2, 2022 at 22:57 #1997
One more quick question now that the expression and branch coverage report is working.
I see that Riviera has robust FSM code coverage reporting capabilities which I hope to be able to leverage in conjunction with OSVVM. I was wondering if the SetCoverageAnalyzeEnable function allows a user to gather FSM code coverage? Currently the .html that is being generated only has branch and expression coverage.
Do you know if that is currently supported within the OSVVM commands, or would that be something I would have to do directly through Riviera?
MichaelJune 2, 2022 at 20:36 #1996
Thanks for the quick response. You’re suggestion worked and I am now only collecting the desired coverage information.
I am not running Riviera-PRO in batch mode, but I will be able to work with the current setup thanks to your reply.
MichaelMay 16, 2022 at 18:25 #1975
Thanks for all the support Jim!May 9, 2022 at 23:02 #1971
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 would run into a similar issue with a UART_TX generate statement, and if so, would the same code change fix it? I know you’re going to push out a fix here shortly, I was just curious.
MichaelMay 9, 2022 at 22:31 #1970
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