I think I found a rather strange bug in the okTriggerOut simulation model (don’t know if ngc behaves similarly).
I am using FrontPanel 3 along with the precompiled files for ModelSimXE62G. All coming from the CD-ROM from an XEM3010 purchased about 1 year ago.
I call UpdateTriggerOuts() then IsTriggered() which responds with a ‘not triggered’ response. Simulation clearly shows that the trigger occurred. ep_clk is connected to a 10MHz clock and ti_clk is 48MHz. ep_trigger is synchronous to the ep_clk. I happen to be using ep_address 63h. This combination seems to have exposed the bug.
The okTriggerOut’s ok2 signal drives the value of the endpoint’s internal trigger status register during the UpdateTriggerOut() function call. Strangely, the value of the ok2 signal changes on the rising edge of ep_clk!!! The ok2 signal should be synchronous to the ti_clk and should not be affected by ep_clk’s rising edge.
I don’t have the RTL code for the opTriggerOut but I can see the signals in simulation and attempt to understand how it works. See attached files for the following explanation.
first image: Bit 0 of the ep_trigger input is pulsed before the screen capture starts. It seems that the captrig signal is sampled on ti_clk’rising_edge (see oval highlight). captrig is sampled on ep_clk’rising_edge twice, resulting in the captrig1 signal. The trighold signal samples eptrig on ep_clk’rising edge if captrig1 /= captrig0. trighold is used to drive ok2 which is currently being read by the okHostInterface block.
second image: This is a close up of the first image showing ok2 changing from Z0000 to Z0001. The okHostInterface samples the ok2 signal on ti_clk’falling_edge but gets the wrong value (Z0000).
Please verify that this is in fact a bug and that I’m not doing something wrong. Also please let me know if the bug exists in the ngc file. In the meantime, I will simply use an endpoint with a higher address that gets read by okHostInterface after trighold is stable.
My guess is that captrig0 and 1 and trighold should be on the ti_clk domain, not the ep_clk domain.
oktriggerout bug1.jpg (103.0 KB)
oktriggerout bug2.jpg (98.7 KB)
You say the trigger occurred, but I don’t see this. ep_trigger is 0000 for the duration of both simulation traces.
Also, it seems you’re looking at the ok1/ok2 signals. These are internal to the host interface / endpoint implementation. Simulation versions of these are entirely uncorrelated to implementation versions.
Yes, the trigger on ep_trigger(0) occurs before the window of time shown in the screenshots. eptrig is evidence of that.
I’m glad to hear that the simulation and implementation of the endpoints is different because that means that there is a good chance that the bug is not in the implemenation. However, I do need the simulation model to work properly for the success of my project.
I am trying to build an advanced verification environment for NASA-GSFC that starts in simulation and seemlessly ports over to lab testing. The Opal Kelly XEM3010 is a key element in this environment. If successful, I can guarantee the purchase of dozens of XEM3010 boards. Your diligent help will be much appreciated.
Would you be willing to share the behavioral VHDL code in the okTriggerOut endpoint? I have plenty of experience with writing and debugging behavioral code and would be glad to help.
Please post a simple (minimal) test case for us to simulate and we can look into this.
Here is a simple test fixture that exposes the bug. Play with various values of cLBWrErrAddr. Also my modelsim.ini file uses a variable named $OK_FP_SIM that you can replace with your path to the compiled okfpsim library. Please email me directly if you have any questions as I’ll be able to respond sooner.
Thanks,
Omar.
okTriggerOutBug.zip (4.5 KB)
Is anyone actively looking into this bug? Can I please get a status update or an estimated date when someone can get to it?
Thanks.
@omar1972–
Yes, we are looking into it.
Briefly-- the issue is a difference between simulation and implementation.
We’re still discussing a solution to this, but we may just need increase the simulation timing to account for longer EP_CLK periods. Of course, there’s no real limit to this because, theoretically, whenever the EP_CLK period above a particular amount, this will be an issue. But increasing this timing in our simulation model will allow a larger range of EP_CLK periods.
The most direct workaround in simulation is to just perform two consecutive UpdateTriggerOuts (and IsTriggered) and combine results. We’ll probably just make a note of a minimum EP_CLK for simulational accuracy.
Incidentally, you’ll note that this problem only starts to show up when you reduce your CLK period above about 98ns. (You had 100ns in the setup)
10 MHz is a pretty slow clock by FPGA standards these days which is probably why we just never considered it.
If the behavior of the real okTriggerOut works properly, then it makes sense to make the simulation model behave the same way. I agree that 10MHz is pretty slow, but I’m creating a generic piece of equipement and I can’t constrain the future applications for which it will be used.
Thanks for the status update.
If you decide to simply note a minimum EP_CLK for simulation accuracy, may I please get the source code for the simulation model of the okTriggerOut? Thanks in advance!
@omar1972 – The “real” implementation involves a PC and a microcontroller running firmware, so it is quite impractical to copy the real implementation.
In fact, the “real” implementation will be subject to precisely the same limitation, but with a different value for the maximum EP_CLK period for which a “same-cycle” trigger will be recognized. If this is unconstrained in your piece of equipment, as you suggest, we would recommend using an alternative method to capture the trigger event. One which is better tolerant to the variations in EP_CLK period.
Then, it would be easy to transition your captured trigger to the domain where EP_CLK is constrainted to shorter periods.
For the simulation model, I believe the crux of the problem is that captrig0 and 1 and trighold are driven on the ep_clk domain instead of the ti_clk domain. Can you please address this topic? Is this true? The waveforms I provided imply that it is true. If so, this seems to be a problem. You can’t drive out a signal on one clock domain (okTriggerOut) and sample it on another (okHostInterface) without re-synching it first.
The simulation model is correct, but subject to the requirement that the frequency of EP_CLK is greater than 15 MHz.
