74HC590 does not start from 0

I'm a bit confused, that the counter 74HC590 is not starting with 0x00 but with 0xFE. Based on the interior setup i had assumed that is would start with low on all flipflop outputs..

Which revision are you using?
This issue is supposed to be solved at Rev 810.

I used R815 :-/

Yes.. I see the problem.
It happens when you start the simulation with reset High.

As far as I know, in a real device you never know the initial state of a flipflop.
And it should be reseted, or started with reset low...

Hmm, I see. for my problem I tried to set up a simple discrete "I2C master" which send the data given in a RAM memory. For this I had one 74HC590 for stepping trought the bits and another one for choosing the bytes.
The complete thing is far away from working, but i attached the file.
I tried to make the initial reset with a flipflop but it seems that i have to create a more sophisticated logic for this.
Do you have a fast idea for this?


Maybe this "Inverse I2C Memory" (= it should be a I2C Master), could also be interesting for other coder as a discrete component. With this, testing I2C could be possible.

I tried to make the initial reset with a flipflop but it seems that i have to create a more sophisticated logic for this.
Do you have a fast idea for this?

So you want it to start by itself?
I mean.. why not just a button controlling the reset?

One thing... those D flipflops should be Set/Reset not inverted.
As it is now it will not work IMO.

Your initial reset circuit is working for me after configuring Set/Reset not inverted for those D FlipFlops (or tie them to 5V).

The idea with the switch is a good one - i just added a switch in order to get the rising edge for MCR after start.
But, for me it looks like first CLK cycle is not increasing the output..
The output before first rising edge on CLK is 0x00 an after the fist edge, too. After the second one the output starts to increase to 0x01, 0x02, .. and so on.

This "not counting for the first time" is also visible for the solution with the flipflops (+ Set/Reset not inverted). It can be best seen for the second 74HC590 (74HC590-908).

But, for me it looks like first CLK cycle is not increasing the output..
The output before first rising edge on CLK is 0x00 an after the fist edge, too. After the second one the output starts to increase to 0x01, 0x02, .. and so on.

Yes, I noticed that.
First clock sets RCO to low, next sets QA high.

I have not idea if this is how it should work or not.

I found this "digital interior" for the 74HC590:
https://assets.nexperia.com/documents/data-sheet/74HC590.pdf#page=3

But there are to much inversions going on for me  in order to understand it at this time of the night...

But there are to much inversions going on for me  in order to understand it at this time of the night...

Of the morning..  

I found this "digital interior" for the 74HC590:

Looks basically the same, but simpler.
This subcircuit is quite old, now it is possible to do it simpler, but at that time it wasn't.

Thinking about this issue and other similar.

Flipflops are currently set to initialize at state "0".
The fact that this circuit didn't do it is because another issue making the clock trigger at start if it's iverted (solved at Rev 843).

In other circuits happens exactly the opposite, they work with JK initial state "1".
By "work" I mean they start in a consistent state that makes sense, for example in a counter it always starts at value = 0.

But in real hardware this is not always the case and often a reset is needed at start.
So in some cases it is possible to do a circuit that consistently "works" in simulide, but in a real circuit would not work.

Then I think FlipFlops should be randomly initialized, as it would happen in a real circuit, forcing to create some initial reset mechanism.
This also has it's educative value in my opinion.

Any opinions?

And a suggestion for your circuit:
Looks like the proper way to drive a 74590 is with complementary clocks.
The counter stage triggers at rising edge and latchs at falling edge when the counter output is stable:



This solves this issue:

TimFish wrote:But, for me it looks like first CLK cycle is not increasing the output..
The output before first rising edge on CLK is 0x00 an after the fist edge, too. After the second one the output starts to increase to 0x01, 0x02, .. and so on.