hazards on important signals

[Spur]

Our design includes a core that has an internal cs_n signal.

Suppose the following:

internal_cs_n <= '0' when cs_sync = '0' and addr_sync(24 downto 22) =
"100" else '1';

cs_sync and addr_sync are completely syncronous to our closk, meaning
that
they're a direct output of FFs.

I'm told that there can be a hazard on internal_cs_n which may cause
the core to work improperly.

Naturally I understand how a hazard can happen, and I know techniques
for avoiding it (redundant multiplicants of the karnaugh map), but
still I wonder.
Should we synchronize EVERYTHING ? But it will only just add to the
latency. Each synchronization is an FF, meaning that the core's cs_n
will come only a cycle later after the general FPGA's cs_sync.

Can't a synthesizer (we use Leonardo and Synplify Pro) avoid hazards
automatically, by means of adding other gates ?

I'm also not sure how to add hazard-avoiding-code manually to the
comparator. If it would be a simple boolean function I'd understand,
but I guess I must look how the synthesis implements the comparator ?

Thanks in advance

 

[Mike Treseler]

Spur wrote:

internal_cs_n <= '0' when cs_sync = '0' and addr_sync(24 downto 22) =
"100" else '1';

cs_sync and addr_sync are completely syncronous to our closk, meaning
that
they're a direct output of FFs.

I assume this means the cpu and fpga use the same clock.

I'm told that there can be a hazard on internal_cs_n which may cause
the core to work improperly.

The simplest timing constraint is register to register
static timing in place and route. The registers in the CPU
driving the fpga pins are outside the scope of this
simple analysis. Some designers "register everything"
to avoid thinking about extra constraints.

The alternative is to figure out how much tco+tsu is
required for each fpga input and add it to the place and
route constraints.

Can't a synthesizer (we use Leonardo and Synplify Pro) avoid hazards
automatically, by means of adding other gates ?

No.

I'm also not sure how to add hazard-avoiding-code manually to the
comparator. If it would be a simple boolean function I'd understand,
but I guess I must look how the synthesis implements the comparator ?

Make the comparison synchronously and relax.
A tick or two of delay is a small price to pay.

-- Mike

 

[VhdlCohen]

internal_cs_n <= '0' when cs_sync = '0' and addr_sync(24 downto 22) =
"100" else '1';

cs_sync and addr_sync are completely syncronous to our closk, meaning
that
they're a direct output of FFs.

I'm told that there can be a hazard on internal_cs_n which may cause
the core to work improperly.
If I understand you correctly, you would like cs_n to be glitch free.

The way you have, you can have glitches because the addr_sync and cs_sync are
outputs of FF with different rise times.
One method to consider is the use of the positive edge of the clock as a
gating, meaning that if the logic is clocked on the positive edge of the clock,
then cs_0 is disable when clock = '1'.
In VHDL:
internal_cs_n <= '0'
when cs_sync = '0' and addr_sync(24 downto 22) ="100" and clock ='0'
else '1';

You might get better synthesis rsults if you put the clock in the last stage.
temp_internal_cs_n <= '0' when cs_sync = '0' and addr_sync(24 downto 22) =
"100" else '1';
internal_cs_n <= '1' when clock='0' else temp_internal_cs_n;

The clock='0' should be faster than FF toggling and that should work.
Of course, the other alternative is to reclock the internal_cs_n, which will
cause 1 pipeline delay!
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------