SRL16 as synchronizer

Hello All,

I'm wondering, if it's possible to use SRL16s to synchronize external signals to your clock.

If I do the standard thing in VHDL, e.g. a couple of assignments in a clocked process, then XST gives me a SRL anyway.

Mabe I could just leave it that way, without having to instantiate FDEs manually?

Is there any difference w.r.t metastability in using SRLs compared to FDs?

Regards Hans Dorn

Reply to
Hans-Juergen Dorn
Loading thread data ...

Hi Hans-Juergen, Try a search on Google groups "metastability srl". Top answer is a discussion we had here called "Should I worry about metastability". Xilinx's expert, Peter Alfke, said :-

I will not guarantee that SRL16s recover as fast from metastability as the "normal" flip-flops that I documented, since SRLs are implemented in a different circuit design. (Different might mean better or worse).

Ray Andraka replied:-

Actually, the SRL's are probably no good for that. They have a considerably longer minimum pulse width than the regular flip-flops. I'm not privy to the actual construction, but I'd be it is more akin to latches than to real flip-flops. Your best resynchronizer will use the regular flip-flops, floorplanned to use adjacent slices within a CLB and using the fast direct connect route between the flip-flops.

Which makes a lot of sense to me, the question is whether the latch type construction of the SRL FFs is compensated for by the short routing delay between the latch elements, they're in the same LUT structure, after all. My guess is not, so until someone can be bothered to do the experiment, I'm gonna stick with the regular FFs as Peter has tested this to death and so we have hard data to work with. I don't suppose you'd like to do the experiments?? So, rereading your post, it IS possible to use the SRLs to do the resync, how well it works w.r.t metastability see above! Post some frequencies, and you may get a better answer. cheers, Syms.

Reply to
Symon

If not having a reset is ok, then yes.

That's what I would expect.

That's an excellent idea. Easier to sim and more portable.

Don't know. Check the data sheet.

Or check fmax, with and without a reset.

-- Mike Treseler

Reply to
Mike Treseler

Reply to
Peter Alfke

You might find a comment elsewhere in your timing report that fmax is limited by the SRL minimum pulse widths, Twph + Twpl. The 150E-7 timing I had up on my screen (SpeedPrint, v6.1i timing) shows Twph of 2100 ps; Twpl isn't specified in the SpeedPrint output but I recall it's the same as Twph resulting in an SRL-limited fmax of 238 MHz with no jitter and 50.00% duty cycle.

You might be able to get XST to avoid inferring s1 as part of the SRL by specifying to XST that it's an IOB register, allowing s2 and Q to be an SRL if XST so chooses.

If Q was to be your "stable" value and s1 and s2 were metastability registers, why not use s2 as the stable, synchronized value? I thought only two registers were needed for proper metastability protection, the output of s1 being a "maybe" that settles to a high or low by the time s2 grabs the value.

Xilinx's

in

Reply to
John_H

:> >I concur. The SRL16 structure is different from a conventional :> >flip-flop. Although it is only the Master latch in a flip-flop that is :> >reponsible for metastability (the Slave just does the read-out), this :> >might imply that there is no difference. But I still would be leary to :> >venture into untested territory. :>

:>

:> >> Hi Hans-Juergen, :> >> Try a search on Google groups "metastability srl". Top answer is a :> >> discussion we had here called "Should I worry about metastability". :Xilinx's :> >> expert, Peter Alfke, said :- :> >>

:> >> I will not guarantee that SRL16s recover as fast from metastability as :> >> the "normal" flip-flops that I documented, since SRLs are implemented :in :> >> a different circuit design. (Different might mean better or worse). :>

:> Mike Tresseler wrote :> >> Is there any difference w.r.t metastability in using SRLs :> >> compared to FDs? :>

:> >Don't know. Check the data sheet. :>

:> >Or check fmax, with and without a reset. :>

:> Hey, thank you all for answering! :>

:> The fmax of a single SRL seems to be way beyond the :> capacity of the global clock nets. (At least for Spartan2E, that is) :>

:> If I do something like - :>

:> p : process(clk) is :> signal s1, s2 : std_logic; :> begin :> if clk'event and clk='1' then :> s1 s2 Q end if :> end process; :>

:> - I'll get an Fmax of 561Mhz on a XC2S50e-7 !!! :> At least WP4.2's timing analyzer seems to think so... :>

:> But anyway, I guess I'll stick to throwing FDE's at all that :> nasty stuff coming from the outside... :>

:> Regards Hans :>

:> P.S: :>

:> If you think, you found an easy way of doing something in VHDL, :> you're probably doing it wrong. :o) :>

:
Reply to
David R Brooks

Mike Tresseler wrote

Hey, thank you all for answering!

The fmax of a single SRL seems to be way beyond the capacity of the global clock nets. (At least for Spartan2E, that is)

If I do something like -

p : process(clk) is signal s1, s2 : std_logic; begin if clk'event and clk='1' then s1

Reply to
Hans-Juergen Dorn

Thanks John, I have to admit that the timing analyzer output is still mostly obscure to me. I'm doing FPGAs more on a hobbyist level in my spare time.

BTW. If you use s2 rather heavily, then XST might replicate it.

- Hans

Reply to
Hans-Juergen Dorn

Reply to
Peter Alfke

But the timing analyzer does provide a message to the user that the fmax is limited by the SRL (or CLB SelectRAM) write pulse width. I mentioned, Hans-Juergen Dorn responded. He saw earlier that he'd "get an Fmax of

561Mhz on a XC2S50e-7" which I wanted to make sure he wouldn't try to rely on.

I'd be ecstatic with that kind of SRL performance, but I'm designing with registers for my own 260 MHz elements within a 2S150E.

But thanks for clearing up that the timing analyzer doesn't give additional information that was pertinent to the earlier part of this thread.

recovery).

Reply to
John_H

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.