Implimentation of BZFAD using VHDL
M1 is a k-1 wide to 1 multiplexer with individual enables driven from the ring counter.  Where the READY signal forces the output to a '0'. M2 is a 1:k-1 selector with individual enables driven off the ring counter. The ring counter has k stages.  MUX1 is a k+1 wide 2:1 multiplexer with a single select input. 

Model M1, M2 and MUX1 behaviorially, you have no access to transistors in the Xilinx Synthesis Technology Integrated Software Environment.  At best you can emulate it in an FPGA.

M1_out &lt;= reduce_or (B(32 downto 1) and Ring_Counter(31 downto 0)) 
              when Ready = '0' else 
          '0' when Ready = '1';`


Ready is Ring_Counter(31).

Where in a transistor level implementation the reduction OR is actually a wire OR. Depending on packages and VHDL version you may aleady have a reduction OR available as a function or an operator.

What's special about the architecture is the ability to use latches for P instead of a parallel load shift right shift register and saving power by reducing the number of nets switching with the clock.

You could write transistor behavioral models but it won't get you any closer to actual transistors.

Addendum  

"can we write structural model instead of the behavior model..."  

Structural in this case is the transistor level.  We can't model transistors accurately without analog simulation, VHDL doesn't know anything about transistors.  We can do a structural digital logic model.

There are two types of transistors used, both incidentally shown in MUX1 which is a k+1 wide 2:1 multiplexer:



Call the top connection to the transistor source, the bottom connection drain and the middle (right) bubble or bubble less connection gate.  

The following isn't the only way to model transistors here. Modelling transistors is something best left to the analog domain.

We model the two transistors differently based on the bubble:

library ieee;
use ieee.std_logic_1164.all;

entity trans is
    port (
        source:     in  std_logic;
        gate:       in  std_logic;
        drain:      out std_logic
    );
end entity;

architecture func of trans is

begin
    drain &lt;= source  when gate = '1' else
             'Z'     when gate = '0' else
             'X';
end architecture;

library ieee;
use ieee.std_logic_1164.all;

entity trans_bubble is
    port (
        source:     in  std_logic;
        gate:       in  std_logic;
        drain:      out std_logic
    );
end entity;

architecture func of trans_bubble is

begin
    drain &lt;= source  when gate = '0' else
             'Z'     when gate = '1' else
             'X';
end architecture;


Without analog simulation about the only thing different we could do would be to model source and drain as mode inout and resolve both outputs.  Seems like a lot of work for something that can't be real accurate anyway.

A simple MUX1 model using transistors:

library ieee;
use ieee.std_logic_1164.all;

entity MUX1 is
    generic (
        k: natural :=32  -- k width
    );
    port (
        a:      in  std_logic_vector (k downto 0);  -- width is k+1
        b:      in  std_logic_vector (k downto 0);
        sel:    in  std_logic;
        outp:   out std_logic_vector (k downto 0)
    );
end entity;

architecture func of MUX1 is
    signal wire_ab:     std_logic_vector (k downto 0);
begin
MUX_1:
    for i in outp'range generate
    MUX1A:
        entity work.trans_bubble 
            port map (source =&gt; a(i), gate =&gt; sel, drain =&gt; wire_ab(i));
    MUX1B:
        entity work.trans 
            port map (source =&gt; b(i), gate =&gt; sel, drain =&gt; wire_ab(i));
    end generate;
WIRED_OR:
    outp &lt;= wire_ab;


end architecture;

The generate statements produce an array of 32 transistors with bubbles for the a side of the mulitplexer and 32 transistors without bubbles for the b side.  The outputs of the transistors or wire OR'd together the output value counting on std_logic resolution.  A transistor is either on or off.  In these models the source input is driven out on the drain when the gate enables, otherwise output 'Z' (high impedance).

Writing a simple test bench for MUX1:

library ieee;
use ieee.std_logic_1164.all;

entity mux1_tb is
    generic 
        ( k:  natural := 32 );
end entity;

architecture foo of mux1_tb is

    signal a:       std_logic_vector(k downto 0) := ('0' &amp; X"FEEDFACE");
    signal b:       std_logic_vector(k downto 0) := ('1' &amp; X"DEADBEEF");
    signal outp:    std_logic_vector(k downto 0);
    signal sel:     std_logic;
begin
DUT:
    entity work.mux1
        generic map (
            k =&gt; k
        )
        port map (
            a =&gt; a,
            b =&gt; b,
            sel =&gt; sel,
            outp =&gt; outp
        );

STIMULUS:
    process 
    begin
        wait for 10 ns;
        sel &lt;= '0';
        wait for 10 ns;
        sel &lt;= '1';
        wait for 10 ns;
        wait;
    end process;
end architecture;


gives us:



Which shows MUX1 works.  Also if you were to peek into the hierarchy you'd find 32 transistor pairs (MUX_1[0-32]/MUX1A and MUX_1[0-32]/MUX1B or some variation, where MUX1As are trans_bubble and MUX1Bs are trans).

M1 and M2 require individual access to gate inputs and have a common rail for either the source (M2) or the drain (M1), see Figure 2 of the paper.  Note that no where in multiplexer MUX1, selector M1 or decoder M2 is there more than one transistor enabled at a time.

Because the Ring Counter also provides a READY signal it also drives the output of the M1 selector to '0' through the transistor below the common drain.  Instead of using resolution functions you can simply invert the connections so the single transistor's drain would be at the top in the schematic symbol.  We can do this because all the transistor enables are mutually exclusive.  The intent is to always having something driving a net.  This prevents latch up and other nasty phenomenon in real implementations.  The ground can be replace by a '0'.