Cascaded CNTs clock on falling edge

Hi, 

I ll check and come back to you

Thanks 

AB

Hi, 

Kindly check the properties CNT/DLY block , I think edge select is falling for  CNT block 

Thanks 

AB

Hi AB, I tried a very simple design using GoConfigure SW ver 6.45.002 on MacOS and it still shows the same problem where a cascaded counter's output changes on the falling edge of its clock. The design was a new one, but the original file attached still fails also.

You said this problem in 6.45.001 would be fixed in the next SW release but it is still there in 6.45.002.

Please investigate this.

Thanks,

...Craig

Hi, 

V 6.45.002 does not include new model – fix is not included as well

Thanks 

AB

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,

...Craig

Hi, 

It will be added in upcoming Go configure version .

Thanks 

AB

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.

Thanks,

...Craig

Hi, 

They have  already fixed it  and will be add in coming version. Once it added I ll let you know

Thanks 

AB

Thanks AB.

...Craig

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!

...Craig

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!

...Craig

Hi AB, have you been able to reproduce this yet?

Thanks, 

... Craig

Hi,

Checking with the team . I will get back to you

Thanks 

AB

Hi AB, what does the Team say about these unrealistic SIM results which are still a problem in 6.47.003?

...Craig

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?

...Craig

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.

Thanks 

AB

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?

Thanks,

...Craig

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.

Thanks,

...Craig