Using GoConfigure SW 6.45.001 with MacOS Monterey 12.7.6, with an SLG46620V.
When I cascade CNTs such that CNT(n) is clocked by CNT(n-1)'s output, CNT(n)'s output changes on the falling edge of its clock.
It used to change on the rising edge of its clock, with older GoConfigure SW, and designs were based on this!
The attached GP file shows every CNT changing its output on the falling edge of its clock (except CNT0, which is clocked directly
from the RC Osc).
Is there a magic option for specifying the active clock edge? (that would be nice!)
Cascaded CNTs - clocked by falling edge.gp4.zip
Hi,
I ll check and come back to you
Thanks
AB
Kindly check the properties CNT/DLY block , I think edge select is falling for CNT block
Hi AB,
So when you said "There was some bug, our software team has fixed the same . Its will be added in next model", what did you mean by "model"?
...Craig
Hi AB - any answer about this?
Thanks,
It will be added in upcoming Go configure version .
Hi AB, a new model like the 46620?
... Craig
Hi AB, I tried the new 6.46.001 GoConfigure SW, and it still shows the error using the original design file. That was disappointing!
Do the SW developers understand what the problem is that I am describing here? Did they confirm it was fixed with the MacOS version of the 6.46.001 SW?
If they are not clear, please ask them to contact me directly.
They have already fixed it and will be add in coming version. Once it added I ll let you know
Thanks AB.
Hi AB, I tried the new 6.47.001 GoConfigure SW with the same design file used at the beginning of this thread, and I see the behaviour is now different.
At first glance it looks like all the cascaded counter outputs are now changing at the rising edge of their respective clocks, which is good.
However, when you zoom in, you can see that CNT1's outputs are actually changing about 1.76 nsec ahead of its clock, while most of the other counter outputs change about 100 psec (0.1 nsec) after their rising clock edge. The rising edge of CNT9's output does this also, but its falling edge changes ahead of its clock, again by about 1.76 nsec. This is not good.
Not only are the delay times shown by the simulator unrealistic, having outputs change before the clock edge occurs makes no sense. There may be an application for predicting winning lottery numbers that comes to mind, but since the simulator is showing these results, can we trust any of what it is giving us?
I'm not sure if your fix was put in this version, but something changed for the worse and I don't know how widespread it is.
Let me know if you get the same results, or need any more info.
Good luck!
Hi AB, have you been able to reproduce this yet?
Checking with the team . I will get back to you
Hi AB, what does the Team say about these unrealistic SIM results which are still a problem in 6.47.003?
Hello AB, it's been a month since you were going to check with the Team about the unrealistic SIM results - what's happening? Is it safe to rely on the simulation's waveform display?
Hi
The plot which you can see is the matrix signal, not the actual signal which is connected to the counter as long as counter clock source has its own path bypassing the connection matrix.
I agree that it may look confusing but everything should be fine.
Anyway we are also doing double check the characterization data.
Hi AB, the problem comes when you add an element (inverter, for example) to the output of one of the counters and then probe this inverter's output signal compared to the counter's input, the time displayed is still only the prop delay time for that inverter without regard to how many cascaded counters are used.
So after passing through 10 cascaded counters, the output appears to change several nsec after the input (not realistic). That implies that all of in in-between connections you make to these counters via the matrix will not be accurate and subsequent displays cannot really be relied on. Best to avoid having to use connections like that.
Could errors in the characterization data cause this effect?
Has it been seen or reported on Win10 or Win11 systems so far?
Hi AB, I just tried 6.48.001 GoConfigure SW with the designs that produced the errors noted above, and...it looks like the simulation is producing valid-looking results. I'll poke it a bit more, but would you check with the developers to see if they have intentionally fixed this please? I'd hate to think the problem might come up again unexpectedly.