Design paradigms

[kaz1]

I believe in these design paradigms:
-Do not generate errors then fix it downstream
-Do not accept inputs that you don't need
-Produce correct outputs, do not correct inputs but leave that to fellow upstream colleague.
-Do not mess up your outputs because the colleague downstream wants you do that.
-Trust your platform and tools, do not verify basics such is if an AND logic is working or not.
-Do not allow another FPGA on board to borrow your FPGA resources. Unless absolutely necessary
-Do not assume a design is ok if it passes sanity check, wait until it is tested extensively

Can anybody think of any other paradigms?

What mystifies me is how long to wait to do things after reset release:
For example would anyone design a circuit that launches a missile immediately after reset release?

Seriously

 

[dpaul]

What is it that you want to do?
Paradigms vary from project to project, is dependent on the team size, skills and responsibilities of the FPGA engineer.

 

[barry]

What mystifies me is how long to wait to do things after reset release:
For example would anyone design a circuit that launches a missile immediately after reset release?

Seriously

If that was a requirement, then I would definitely design a circuit that launched a missile "immediately" (whatever that means) after reset release. FPGA/digital design is, or SHOULD be, deterministic. I don't understand your mystification.

 

[weetabixharry]

What mystifies me is how long to wait to do things after reset release:
For example would anyone design a circuit that launches a missile immediately after reset release?

Seriously

There is not necessarily anything special about a reset. For example, consider this flip-flop:

process(clk)
begin
    if rising_edge(clk) then
        if rst_n = '0' then
            a_reg <= '0';
        else
            a_reg <= a;
        end if;
    end if;
end process;

What if we rename the (active-low) reset to enable? We might then write it like this:

process(clk)
begin
    if rising_edge(clk) then
        a_reg <= a and enable;
    end if;
end process;

The two implementations are functionally identical and could be synthesized to identical hardware.

It is not unreasonable to expect the 2nd circuit to "do things" in response to enable on the very next rising edge of clk. Similarly, it is not unreasonable to expect the 1st circuit to "do things" in response to rst_n on the very next rising edge of clk. Renaming the signal, or restructuring the HDL code hasn't changed that fact.

If this logic is part of a circuit that controls the launch of a missile, then you would of course need to make absolutely certain that the circuit is not going to behave in an unpredictable manner. That doesn't just apply to a signal that you choose to name a "reset", but to the whole circuit. And it doesn't just apply to circuits that launch missiles; it is very often desirable for a digital circuit to behave predictably in general.

 

[kaz1]

Since reset release is subject of questions and uncertainties I rather not launch a missile immediately on reset release unless It is fireworks

https://www.edaboard.com/threads/why-dont-2-flip-flop-synchronizers-have-a-reset.403790/page-2#posts

 

[barry]

Since reset release is subject of questions and uncertainties I rather not launch a missile immediately on reset release unless It is fireworks

https://www.edaboard.com/threads/why-dont-2-flip-flop-synchronizers-have-a-reset.403790/page-2#posts

Then I don't want you designing my missle control system..

If you don't trust a synchronous-release reset, then you don't trust ANY synchronous circuit.

 

[kaz1]

Then I don't want you designing my missle control system..

If you don't trust a synchronous-release reset, then you don't trust ANY synchronous circuit.

That brings us to trusting the tools/platform or not. Remember many of us talk about state machine entering wrong state. A trusted design doesn't need that to be considered. And if it does occur would state reset sort things out...no way. I trust reset release provided timing path is defined and it passed timing.

 

[barry]

Apparently you are unfamiliar with cosmic rays and radiation effects and ESD whereby a bit can flip and put a state machine in an invalid state. Nothing to do with “trust”; it has to do with good design practice to be able to have a state machine recover from an invalid state.