Reply to thread

Message: [QUOTE="alb, post: 5113205"] Hi Andy, sorry for the late reply, I was offline for few days... On 21/08/2013 16:24, Andy wrote: [] I'm trying to build up a crew of people interested in the course here at Cern, in order to get an on-site course and maybe with a 'discount' considering that we are part of an international organization ;-) I see your point. For what concern the serial protocol in the OP each transaction is atomic and there's no 'memory' in the system to induce any interaction. OTOH there are other interfaces which are 'active' simultaneously and may have an impact when stimulated concurrently. If I need to have a simultaneous testing than I would need to rework the test case a little bit. Since currently I have one sequence of transactions in one process, I may think about using two processes which run concurrently and see what is the interaction. I agree and moreover I do not have a set of configurations to play with, therefore I would need to manually remove/add components along the way (too painful). At Cern we have several licenses and I'm planning to run simulations in batch mode through our batch system. Unfortunately I haven't spent enough time on this part yet and so far I'm running simulations one after the other one on a single license machine. As of now my 'test case' is at the top level. The harness instantiate the most of the common parts (DUT, BFM, clock generation) and the 'test case' instantiate the harness. I guess I didn't get it. What is 'worse than a warning'? If I get an error how can the simulation continue? that is correct, because of the 'bit-stuffing' property of the protocol. meaning the BFM should 'listen' continuously the interface to check if errors need to occur or not. This will require a concurrent interface to the BFM which adds errors on top of the one which creates 'good transactions'. That is indeed yet another type of error, which acts at the level of packet format (wrong CRC, ...). I guess with the combination of the two I can expose many unwanted 'features' of the code. The main question here would be: for how long should I simulate? I guess here I'm stuck with building a coverage model (out of a non existing requirements' document!). [/QUOTE]

Verification