Spartan3 SRL16 + SliceFF, LUT stability

Hallo.

When using a Spartan3 SliceM in 2x SRL16-Mode,
the Slice-FlipFlops and the SRLs must share the same clock
(and from the FPGA-Editor, it looks like if that clock's
polarity must be the same for both, SRLs and FFs).

Now, if I want to use the FFs (I don't think they can be 
used for anything else then buffering the SRL's Output),
I'm not fully sure the FF clk will be early enough
to not sample the SRL during undefined output.

I think it's very likely that the FF clk is early enough,
but I don't see a way to ask the xilinx tools about that
(apart from the module attached compiles without errors
in ISE10.1 web).

Has anyone tried a simulation about this?

Gruss

Jan Bruns




module shiftreg16F(di,o,clk,cke,cke2,a);
  input di;
  output o;
  input clk;
  input cke;
  input cke2;
  input [3:0] a;
  reg [15:0] shiftdata;
  reg tmp;
  always @(posedge clk)
  begin
    if (cke) begin
      shiftdata[15:1] <= shiftdata[14:0];
      shiftdata[0] <= di;
    end
    if (cke2) begin  
      tmp <= shiftdata[a];
    end
  end
  assign o = tmp;
// synthesis attribute RLOC of shiftdata[15:0] is "X0Y0"
// synthesis attribute RLOC of tmp is "X0Y0"
// synthesis attribute BEL of shiftdata[15:0] is "F"
// synthesis attribute BEL of tmp is "FFX"
endmodule

"Jan Bruns":
> I think it's very likely that the FF clk is early enough,
> but I don't see a way to ask the xilinx tools about that
> (apart from the module attached compiles without errors
> in ISE10.1 web).
 
>  always @(posedge clk)
>  begin
>    if (cke) begin
>      shiftdata[15:1] <= shiftdata[14:0];
>      shiftdata[0] <= di;
>    end
>    if (cke2) begin  
>      tmp <= shiftdata[a];
>    end
>  end

The following also compiles without error:

  always @(posedge clk)
  begin
    if (cke2) begin  
      tmp = shiftdata[a];
    end
    if (cke) begin
      shiftdata[15:1] = shiftdata[14:0];
      shiftdata[0] = di;
    end
  end

but the opposite blocking behaviour compiles, but infers flipflops
instead of srl16:

  always @(posedge clk)
  begin
    if (cke2) begin  
      tmp = shiftdata[a];
    end
    if (cke) begin
      shiftdata[15:1] = shiftdata[14:0];
      shiftdata[0] = di;
    end
  end

I didn't notice that xst now has better blocking assignment support
(or maybe I got a false impression about older xst versions when
learning verilog).

Gruss

Jan Bruns

On Nov 19, 6:25=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> Hallo.
>
> When using a Spartan3 SliceM in 2x SRL16-Mode,
> the Slice-FlipFlops and the SRLs must share the same clock
> (and from the FPGA-Editor, it looks like if that clock's
> polarity must be the same for both, SRLs and FFs).
>
> Now, if I want to use the FFs (I don't think they can be
> used for anything else then buffering the SRL's Output),
> I'm not fully sure the FF clk will be early enough
> to not sample the SRL during undefined output.
>

Very unlikely.  The SRL clock to output time is longer than
a fabric flip-flop and the clock routing within a slice is very
fast.

> I think it's very likely that the FF clk is early enough,
> but I don't see a way to ask the xilinx tools about that
> (apart from the module attached compiles without errors
> in ISE10.1 web).
>

You could run a timing simulation after place & route.

> Has anyone tried a simulation about this?
>
> Gruss
>
> Jan Bruns
>
> module shiftreg16F(di,o,clk,cke,cke2,a);
> =A0 input di;
> =A0 output o;
> =A0 input clk;
> =A0 input cke;
> =A0 input cke2;
> =A0 input [3:0] a;
> =A0 reg [15:0] shiftdata;
> =A0 reg tmp;
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] <=3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] <=3D di;
> =A0 =A0 end
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp <=3D shiftdata[a];
> =A0 =A0 end
> =A0 end
> =A0 assign o =3D tmp;
> // synthesis attribute RLOC of shiftdata[15:0] is "X0Y0"
> // synthesis attribute RLOC of tmp is "X0Y0"
> // synthesis attribute BEL of shiftdata[15:0] is "F"
> // synthesis attribute BEL of tmp is "FFX"
> endmodule

On Nov 19, 8:49=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Jan Bruns":
>
> > I think it's very likely that the FF clk is early enough,
> > but I don't see a way to ask the xilinx tools about that
> > (apart from the module attached compiles without errors
> > in ISE10.1 web).
> > =A0always @(posedge clk)
> > =A0begin
> > =A0 =A0if (cke) begin
> > =A0 =A0 =A0shiftdata[15:1] <=3D shiftdata[14:0];
> > =A0 =A0 =A0shiftdata[0] <=3D di;
> > =A0 =A0end
> > =A0 =A0if (cke2) begin =A0
> > =A0 =A0 =A0tmp <=3D shiftdata[a];
> > =A0 =A0end
> > =A0end
>
> The following also compiles without error:
>
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp =3D shiftdata[a];
> =A0 =A0 end
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] =3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] =3D di;
> =A0 =A0 end
> =A0 end
>
> but the opposite blocking behaviour compiles, but infers flipflops
> instead of srl16:
>
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp =3D shiftdata[a];
> =A0 =A0 end
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] =3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] =3D di;
> =A0 =A0 end
> =A0 end
>

Am I missing something or did you paste the same code
here twice?  Is this the code that caused XST to infer
flip-flops?

> I didn't notice that xst now has better blocking assignment support
> (or maybe I got a false impression about older xst versions when
> learning verilog).
>
> Gruss
>
> Jan Bruns

"Gabor";

> Am I missing something or did you paste the same code
> here twice?  Is this the code that caused XST to infer
> flip-flops?

Yup, sorry. The version infering the fliflops instead of srl16 clearly was:

  always @(posedge clk)
  begin
    if (cke) begin
      shiftdata[15:1] = shiftdata[14:0];
      shiftdata[0] = di;
    end
    if (cke2) begin  
      tmp = shiftdata[a];
    end
  end

Gruss

Jan Bruns

Jan Bruns wrote:

> I didn't notice that xst now has better blocking assignment support
> (or maybe I got a false impression about older xst versions when
> learning verilog).

There has never been a synthesis problem
with blocking assignments.
However, it is possible for me to
make a simulation race this way
if I am not very careful.

      -- Mike Treseler

On Nov 19, 10:07=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Gabor";
>
> > Am I missing something or did you paste the same code
> > here twice? =A0Is this the code that caused XST to infer
> > flip-flops?
>
> Yup, sorry. The version infering the fliflops instead of srl16 clearly wa=
s:
>
> =A0 always @(posedge clk)
> =A0 begin
> =A0 =A0 if (cke) begin
> =A0 =A0 =A0 shiftdata[15:1] =3D shiftdata[14:0];
> =A0 =A0 =A0 shiftdata[0] =3D di;
> =A0 =A0 end
> =A0 =A0 if (cke2) begin =A0
> =A0 =A0 =A0 tmp =3D shiftdata[a];
> =A0 =A0 end
> =A0 end
>
> Gruss
>
> Jan Bruns

I see.  With the blocking assignments, this actually differs from
the original in the case where cke and cke2 are both asserted
on the same clock cycle.  In this case tmp will get shitdata[a]
after the shift has already occurred.  This does not fit the
standard template for SRL16, although you could probably
build it with an SRL16 and some extra logic on the address
inputs and realizing that it won't work for the zero-delay
case of a =3D 0 while both cke's are active.

"Mike Treseler":
> Jan Bruns wrote:
 
>> I didn't notice that xst now has better blocking assignment support
>> (or maybe I got a false impression about older xst versions when
>> learning verilog).
 
> There has never been a synthesis problem
> with blocking assignments.
> However, it is possible for me to
> make a simulation race this way
> if I am not very careful.

Hm, maybe it just was a decision to "never" use blocking assignments 
for synthesis.

But I remember earlier xst complaining about many blocking assignment 
related things that should have been implmementable (errors or even crahes).

Gruss

Jan Bruns

On Nov 19, 11:40=A0am, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Mike Treseler":
>
> > Jan Bruns wrote:
> >> I didn't notice that xst now has better blocking assignment support
> >> (or maybe I got a false impression about older xst versions when
> >> learning verilog).
> > There has never been a synthesis problem
> > with blocking assignments.
> > However, it is possible for me to
> > make a simulation race this way
> > if I am not very careful.
>
> Hm, maybe it just was a decision to "never" use blocking assignments
> for synthesis.
>
> But I remember earlier xst complaining about many blocking assignment
> related things that should have been implmementable (errors or even crahe=
s).
>
> Gruss
>
> Jan Bruns

Synthesizers use "templates" to fit things like flip-flops and SRL's.
When
a combination of blocking and non-blocking assignments does not fit a
template, the synthesizer throws up its hands and gives up.

That being said...

Your original code with only non-blocking assignments in the
clocked block is easier to fit because there is no combinatorial
logic implied after the clock.  Also the order of assignment only
matters in this case if you re-assign the same register, making
it easier to read, too.  This assignment order is not so apparent
in the version that inferred the flip-flops.  In that case you needed
to see that both if statements can occur under some conditions
causing the output assignment to come after the shift.

You can also get synthesis errors where it isn't obvious why,
like blocking assign in the asynchronous reset block but
non-blocking assigns in the clocked portion or vice-versa.

"Gabor":
> Your original code with only non-blocking assignments in the
> clocked block is easier to fit because there is no combinatorial
> logic implied after the clock.

I think the non-blocking version would ideally sample data exactly 
when it per definition changes, effectively making no choice about
the data sampled beeing the older or the newer version.

Of course, it almost never makes sense to sample digital data when 
it is changing (except perhaps if you're interested in some kind of
random generator).

However, in contrast to the average usage of non-blocking assignments
(just sample a wire on a given event, without any additional constraints,
exactly the same thing real hardware can do), the non-blocking 
"shiftreg16F" code doesn't have implied semantics about the state
of the wire being sampled.


For exaample, in constructs like

  always @(someevent) begin
    somereg <= ~somereg;
  end

it is clear that it is equivalent to 

  wire somewire = ~somereg;
  always @(someevent) begin
    somereg <= somewire;
  end

giving a clear logical relationsship (following the from the practical
requirement) about what is to be assigned.

The original shiftreg16f code intnentionally merely did something like

  always @(someevent) begin
    somereg1 <= somewire;
    somereg2 <= somereg1;
  end

where minimal changes in clock-phase would produce opposite results.
Since xst tool does recognize the difference from

  always @(someevent) begin
    somereg1 = somewire;
    somereg2 = somereg1; // == somewire
  end

to the opposite

  always @(someevent) begin
    somereg2 = somereg1; // old value of somereg1
    somereg1 = somewire;
  end

I wouldn't expect it to produce "@clk(SRL+FF) within a slice" for
any of the two blocking versions, if none of the blocking versions
could be implmented that way.

Gruss

Jan Bruns