Spartan 6, Synthese optimiert Signal weg

[X- R. (x-rocka)]

Moin,

da möchte man es richtig machen... und die Synthese (Spartan-6, ISE 
12.3) haut mir die doppelten FF wech. :-(

Fall 1: So wird "q_LC_sync0" von der Synthese eliminiert:

  process(FC_Clk0_in)
  begin
    if( FC_Clk0_in'event and FC_Clk0_in = '1' ) then
      q_LC_sync0     <= LC_in_i;
      LC_sync0     <= q_LC_sync0;
    end if;
  end process;

Fall 2: So nicht:

  process(FC_Clk0_in)
  begin
    if( FC_Clk0_in'event and FC_Clk0_in = '1' ) then
      if( FC_Reset_in = '1' ) then
        q_LC_sync0   <= '1';
        LC_sync0   <= '1';
      else
        q_LC_sync0   <= LC_in_i;
        LC_sync0   <= q_LC_sync90;
      end if;
    end if;
  end process;

Warum das denn bitte?
Fall 2 geht aus anderen Design-Gründen nicht, ich will auf diesen 
Signalen keinerlei Reset, aber unbedingt das doppelte syncen.

Das RTL-Synthese Schematic zeigt in Fall 1 noch q_LC_sync, das 
"Technology-Schematic" nicht mehr.

Wie bekomme ich Fall 1 (also ohne Reset) synthetisiert, ohne dass er mir 
q_LC_sync wegoptimiert?

Danke,
X

[L - Rocka (Gast)]

Was passiert mit "LC_sync0" ? Kann es sein, dass es in deiner weiteren 
(hier nicht gezeigten) Schaltung nicht verwendet wird ?

L-Rocka

[X- R. (x-rocka)]

Es wird verwendet.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

X- Rocka schrieb:
> Das RTL-Synthese Schematic zeigt in Fall 1 noch q_LC_sync, das
> "Technology-Schematic" nicht mehr.
Und wieviele FFs sind dann dort zwischen LC_in_i und LC_sync0?

[X- R. (x-rocka)]

Lothar Miller schrieb:
> X- Rocka schrieb:
>> Das RTL-Synthese Schematic zeigt in Fall 1 noch q_LC_sync, das
>> "Technology-Schematic" nicht mehr.
> Und wieviele FFs sind dann dort zwischen LC_in_i und LC_sync0?

Ah, jetzt ich verstehe!

Im "Technology-Schematic" zeigt er ein SRLC16.
Das hat zur Folge, dass das Signal nach der Synthese nicht mehr als 
q_LC_sync existiert, weil es im SRLC16 nur noch intern vorhanden ist.
Er macht also schon was er soll... hat mich auch gewundert.

Warum ich dachte, q_LC_sync wäre weg: LOC Constraint.
Diese Signale müssen in bestimmte Slices gepackt werden, die nicht alle 
CARRY4 haben (ich nehme an, dass SRLC16 dann mit CARRY4 realisiert wird, 
das im S6 "nur" in der Hälfte der Slices vorhanden ist).

Hmmm, wie sage ich der Synthese, dass sie das bitte nicht mit nem SRLC16 
realisiert? Ich möchte lieber beide FFs in ein Slice packen und den 
"schnellen" Rückweg von Slice In zu Out nehmen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

X- Rocka schrieb:
> wie sage ich der Synthese, dass sie das bitte nicht mit nem SRLC16
> realisiert?
Indem du einen Reset dranbastelst. Denn ein LUT-SR hat keinen Reset...

> Ich möchte lieber beide FFs in ein Slice packen
Das Schieberegister in der LUT ist auch in 1 Slice...

> und den "schnellen" Rückweg von Slice In zu Out nehmen.
Wozu die Hektik?

[X- R. (x-rocka)]

Lothar Miller schrieb:

>> Ich möchte lieber beide FFs in ein Slice packen
> Das Schieberegister in der LUT ist auch in 1 Slice...
Ich werde das mal versuchen, und kucken, ob er das auch in ein SliceX 
(ohne CARRY4) packt.

>> und den "schnellen" Rückweg von Slice In zu Out nehmen.
> Wozu die Hektik?
Äußerst grenzwertiges Design, was Timing angeht. Da ist jeder Signal und 
Clockpfad entscheidend, und wird deswegen mit LOCs vorgegeben. Timing 
Constraints haben leider nicht gereicht, deswegen Platzierung von Hand.