This technical report presents current results of the formal verification of VHDL design of Liberouter and Scampi hardware accelerator card for packet routing, originating from the Liberouter project. We use the symbolic model checker Cadence SMV~ to prove desired properties of separate units of the design. We have verified many properties of the number of units. Moreover, we have also gained precious experiences concerning the fight with the state explosion problem.
The aim of the Liberouter project~ is to design and develop the hardware accelerated router. The most important part of this project is development of the Combo6 and Scampi hardware accelerator card~ allowing to route the most of traffic of Gigabit Ethernet in the hardware.
More introduction into the problematics of the verification in this project can be found in~.
After finishing the technical report~ we have found significant failures in our verification. Unfortunately, our previous definition of LATRS register entity was not correct and also further registers (e. g. DFFRS and DFFERS) were translated in the wrong way (by vl2smv utility).
For this reason we have created new models of these registers. We have also created new models of the registers in the cases with more than one clock signal, where it is necessary to have more detailed descriptions (see~).
After corrections of our translation process we have focused our effort to the real model checking of separate units of the design. We have gained precious experience. Now we are able to formulate very interesting formulas and preconditions in LTL, furthermore we can manually model (on the very high level of abstraction) the behavior of certain parts of the design. And this way we are able to simulate the behavior of the units which create inputs (environment) of the verified component (see the verification of Statistic Unit).
In this report we would like to present results and experiences with the model checking of VHDL source in the Liberouter project in the form of description of verification of single units. Techniques used in verification slightly vary according to the particular verified unit.
In the technical report we have introduced our approach to the translation of VHDL to Verilog and then to the Cadence SMV. After releasing the report we have found significant errors in the definition of LATRS entity and we have also found out that further entities representing registers were wrong. The main reason of these mistakes is based on the fact that vl2smv is not able to correctly translate always blocks in a Verilog source code.
The first step which have to be done to verify source codes is downloading them from CVS. You can download them directly via web interface of our CVS or you can use anonymous account and CVS client to download the entire CVS.
The process of translation is almost the same as in . The difference is in definitions and counts of replaced entities. The process of translation and substitutions for entities was strongly automatized. We have created scripts called vhd2v (written in Bash scripting language) and v2smv.pl (written in Perl), which can be found in our CVS. vhd2v calls the synthesizer on the design given in the command line with some optional parameters:
vhd2v [-vhd] DESIGN TO_OPTIMIZE [MOD ..] SRCwhere DESIGN is the name of the synthesized design, TO_OPTIMIZE is the name of the part of the design to optimize (value - stands for the optimization of the entire design), MOD is the VHDL module used for synthesis and SRC is the VHDL module with top-level design.
v2smv.pl calls vl2smv and do few other transformations (e.g. substitutions for the modules). This is the syntax of its usage:
v2smv.pl [-async/-sync] SRCwhere SRC is the Verilog source (preferably the one produced by vhd2v) and parameters have the following meaning:
This is the list of software required for translation, verification, presentation of our results:
Of course, these applications require some additional libraries and applications installed. For example Cadence SMV needs Tk Interface eXtension TIX and saxon, written in Java, requires Java Runtime Environment (available from web page of Sun).
This section is about the synthesis of Scampi project and its translation to Verilog and Cadence SMV. Working directory for Scampi project is
$LIBEROUTER_PATH/vhdl_design/combo6/projects/scampi_ph1In this working directory the content of the file
This translation is provided by v2smv.pl script and uses the following files:
$LIBEROUTER_PATH/vhdl_design/combo6/projects/scampi_ph1/Makefile
$LIBEROUTER_PATH/vhdl_design/base/Makefile.fpga.inc (included)
$LIBEROUTER_PATH/vhdl_design/combo6/projects/scampi_ph1/&ldots;
&ldots;Leonardo.ver.tcl
$LIBEROUTER_PATH/vhdl_design/combo6/projects/scampi_ph1/Modules.tcl
$LIBEROUTER_PATH/vhdl_design/base/Leonardo.inc.tcl (included)
The translation to Cadence SMV can produce empty modules. They can be for example:
DCM, RAM16X1D, RAM32X1D, RAM64X1D, RAMB16_S18_S18, RAMB16_S18_S36, RAMB16_S9_S18
Keeping these modules empty we abstract from their behavior and so all possible outputs of these modules are taken in consideration. The reason is that saving every state of memory module (e. g. RAM16X1D, RAM32X1D) to the computer memory is unfeasible.
One of the biggest problems is the way of obtaining properties which should be verified. There are three main sources of assertions:
Cadence SMV model checker is freely available on the following platforms:
We want to choose the best platform for fast verification process.
For this purpose the test verification was created and the time and space
consumed by Cadence SMV with the test verification as input was
analysed. The time and space consumption on different platforms is shown
in logarithmic scale in Figure.
We found difference between Cadence SMV versions
on different platforms in memory consuming with the same input.
On
Running time of Cadence SMV with the testing input
on several different machines is in Figure.
These times are the average from two running times.
On every row there is a different computer although it may seem that
Pentium 4 2,6 GHz, Linux and Pentium 4 3 GHz, Linux
are only identical copy.
For efficient usage of Cadence SMV we recommended computer with the latest Pentium or Athlon with some Linux distribution installed. The psychical memory size should be 2 GB for huge state spaces.
We will present selected components from Liberouter and Scampi designs which we currently verify according to several properties each time the new version of design appears in CVS. The basic outline of components is depicted in Figure. The highlighted components are currently under verification. Numbers under components are counts of unique verified properties. The similar properties are counted as one (see examples of verification to understand what "similar" means).
Using the number of examples we would like to present the techniques used to achieve sufficiently efficient model checking in Cadence SMV.
Basic documentation of
When
G (! ( plx_wr and plx_rd ) );
G ( ( !DRAM_COM_U.RESET and DRAM_COM_U.START ) -> ( X DRAM_WR_REQ ) );
G ( ( !DRAM_COM_U.RESET and DRAM_COM_U.START ) -> ( X DRAM_ACK ) );
G ( ( !DRAM_COM_U.RESET and DRAM_COM_U.START ) -> ( X DRAM_RD_REQ ) );
G ( ( !DRAM_COM_U.RESET and DRAM_COM_U.START ) -> ( X DRAM_DEC_REQ ) );
G ( ( !DRAM_COM_U.RESET and DRAM_COM_U.START ) -> ( X CTRL_U.DRAM_FINISH) );
G ( !DRAM_COM_U.RESET and !( (DRAM_COM_U.INP_PTR + 1) = DRAM_COM_U.OUT_PTR) );
The first assertion is simple mutual exclusion of signal plx_wr and plx_rd. This assertion is true and verification takes only 0.62 seconds.
All other assertions are the matter of
The second assertion for
Similarly for the other assertions.
We considered these assertions as one unique property.
Some of them are even isomorphic and
The fourth assertion is false. The reason is not the bug in design but a very imperfect specification. More preconditions would have to be added to make this assertion valid.
The last assertion is very important.
DRAM scheduler coordination of data transfer into
No matter which abstraction we have used, the state space was always larger than 4 GB memory. The limit of 4 GB memory is given by our precompiled binary version of Cadence SMV.
VHDL structure of Scampi project contains
16
Special configuration of
Assertions obtained from hardware developer:
Mutual exclusion of control_flag and data_flag.
Mutual exclusion of mode_wr and init_wr_vec.
Mutual exclusion of signals CONTROL_A, CONTROL_B, CONTROL_C, and CONTROL_D.
In the first assertion both signals have been synthesized into
NOT_control_flag and NOT_data_flag
in component
G ( ! (
(!SAU_INS_notri.RESET) and
(!LRESET) and
SAU_INS_notri.NOT_control_flag and
SAU_INS_notri.NOT_data_flag
) );
The second assertion is a mutual exclusion of signal mode_wr
and
vector of 16 signals init_wr_vec in component SAU_INS_notri again.
Signal mode_wr is synthesized into signal nx72 and
vector init_wr_vec is synthesized into 16 signals nx57, nx58, .., nx71, nx73.
No bit of vector init_wr_vec should be enabled,
when mode_wr is enabled,
hence the formula of mutual exclusion should be
The third assertion was not verified. It is due to the size of the state space generated by the resulting formula:
G ( ! ( SAU_INS_notri.sau_cores_0_U_SAU_CORE.CONTROL_A and
SAU_INS_notri.sau_cores_0_U_SAU_CORE.CONTROL_B and
SAU_INS_notri.sau_cores_0_U_SAU_CORE.CONTROL_C and
SAU_INS_notri.sau_cores_0_U_SAU_CORE.CONTROL_D ) );
In each tested abstraction the state space was larger than 4 GB memory.
Same as it was for the last assertion in
Header Field Extractor (
We have chosen the subcomponent
G F (loop_cntr_0_ or loop_cntr_1_ or loop_cntr_2_ or loop_cntr_3_ or loop_cntr_4_ or loop_cntr_5_ or loop_cntr_6_ or loop_cntr_7_);
G ( (indd_inc -> (not indd_dec)) and (indd_dec -> (not indd_inc)))
G ( (set_int -> (not clear_int)) and (clear_int -> (not set_int)))
((not CLK) U G ( not ( ( shortcut_en and sel_gpr ) or ( shortcut_en and sel_din ) or ( shortcut_en and sel_din_i) or ( sel_gpr and sel_din ) or ( sel_gpr and sel_din_i) or ( sel_din and sel_din_i ) ) ));
G ( (ds_ren -> F (not ds_ren)) and ((not ds_ren) -> F ds_ren) )
The first assertion is devised by the verifier. It can be rewritten into the assertions described in as:
loop_cntr is always aliveThis assertion is true, when we specify some additional preconditions about the instruction input, as it will be shown in the next subsection.
The second and the third were assigned by the developer in this form (which is described in ):
Unfortunately it was not the case of the fifth assertion that was given
by this assignment:
ds_ren is the signal, which value determines whether
it is possible to read data. Of course it is very natural to think about
it in such a way that we would like to be always able to see the signal
ds_ren enabled (equal to 1) in the future. But is it
true to specify it in a way the designer did? No, because this requirement
strongly depends on instructions which are processed by the processor (coming
from processor input).
But we do not have instructions for the processor encoded in the design.
Therefore if it will always come
The fourth assertion was given by developer in this form:
exclusion shortcut_en, sel_gpr, sel_din, sel_din_iIt is valid, but it is also very special. This is the fragment of code of HFE_CORE (hfe_core.vhd, version 1.10):
-- Data in bus address decoder
din_addr_decoder : process(clk,src_addr_i, dst_addr_i,
res_wen_reg, acc_wen_reg)
begin
if clk'event and clk = '1' then
sel_gpr <= '0';
sel_din <= '0';
sel_din_i <= '0';
shortcut_en <= '0';
if ( (src_addr_i = dst_addr_i) and
(res_wen_reg = '1' ) ) or
-- "shortcut" enable process
. . .
Here you can see that signals sel_gpr, sel_din,
sel_din_i and shortcut_en are set by the edge
of clock. But they are not set by signal reset. Nevertheless it is not
the fault, because it suffices to initialize the signal at the first
tick of clock. Suppose that formula (not CLK) U FrmThis formula assumes that signal
not CLK
In this place it is also proper to list some basic preconditions we made about the system:
In the case of LTL formulas number 2, 3 and 4 only first two preconditions from the given above suffice to show validity of assertions. In the case of the first LTL formula we get validity only if we add many additional (but valid) preconditions.
First we have to assign the precondition saying that instruction REPI comes infinitely times. In general it has not to be true, but we want to verify, that there is no obstacle to correctly increase and decrease loop_cntr in future. The obstacle should not be the absence of REPI instructions, because we know that REPI instructions are the only instructions working with loop_cntr and therefore these instructions are the only possible source of liveness of loop_cntr.
G F ( (INSTR_IN1[17..10] = 30 and not reg_pc_sel) orThe instruction REPI has one argument. If this argument was always zero, then the REPI instruction would not cause the increase of loop_cntr and the assertion would not be true. Therefore we have to add one more precondition:
(INSTR_IN2[17..10] = 30 and reg_pc_sel) )
G ( (INSTR_IN1[17..10] = 30 -> INSTR_IN1[7..0]>=2) and
(INSTR_IN2[17..10] = 30 -> INSTR_IN2[7..0]>=2) )
Unfortunately it does not suffice for validity of the first assertion. The reason is the asynchronism of the instruction input (signal buses INSTR_IN1 and INSTR_IN2). This piece of code is the only piece, that modifies loop_cntr:
if reset = '1' then
loop_cntr <= (others => '0');
...
elsif clk'event and clk = '1' then
...
if lc_wen='1' then
loop_cntr <= ALU_RES(7 downto 0) - 1;
end if;
if from_loop_ld = '1' then -- write to loop_cntr
loop_cntr <= instruction(7 downto 0)-1;
elsif loop_in_progress = '1' and lc_gtz='1'
and stop='0' then
loop_cntr <= loop_cntr - 1;
end if;
end if;
Signal from_loop_ld is dependent only on the instruction input
(when REPI instruction occurs).
Instruction input is not explicitly synchronized with clock and hence
REPI can cause enabling of from_loop_ld for so short
time that it is not noticed by the above code synchronized with clock.
This would cause invalidity of the first LTL formula. Therefore we have to add the set of preconditions, which set the synchronism of instruction input with clock:
G (X CLK -> CLK)->(INSTR_IN1[0]<->X INSTR_INi[bit])where i is the number of the instruction bus (it can be 1 or 2) and bit is the number of the single bit (it can be from 0 to 17). Therefore the set of preconditions setting synchronism of instruction bus with clock contains 36 preconditions.
All assertions except for the liveness of ds_ren has been found true.
To be able to finish the model checking of single formulas we had to make
the abstraction. We have deleted the content of
Unified Header FIFO (
We have verified this set of assertions:
First two assertions are given by the developer. The others are devised by the verifier. Rewriting to LTL was not so easy as it could seem. The first assertion is rewritten to the set of 32 LTL formulas:
For the purpose of formal verification the second assertion is simplified so that lup_block is substituted by 0 (therefore we verify the assertion only for one of sixteen possible values of lup_block). It is probably not wrong because cases of the verification for different values of lup_block look very similar. The simplified assertion is this one:
It can be easily rewritten to LTL (some variables are substituted by their real counterparts in the SMV code):globally if ready(0) and LUP_ADDR[8..5]=0 then (hfe_block or not write_i)
G ((ready_0_ and LUP_ADDR[8..5]=0) -> (hfe_block_0_ or hfe_block_1_ or hfe_block_2_ or hfe_block_3_ or not (HFE_WEN and hfe_allocated)))
Third assertion is rewritten to LTL using 8 formulas:
where i is the number of bit (from 0 to 3)G ((HFE_RDY and hfe_block_i_)-> or
((hfe_block_i_ U hfe_is_producing)(G hfe_block_i_)))
where i is the number of bit (from 0 to 3)G ((HFE_RDY and not hfe_block_i_)-> or
(((not hfe_block_i_) U hfe_is_producing)(G not hfe_block_i_)))
The assertions 3 and 4 need only the precondition restricting the signal RESET to be valid:
More preconditionsRESET and X G (not RESET) &ldots;This means that signal RESET is 1 only at the first state and then it is 0.
The rest of assertions needs many more preconditions. These preconditions model the behavior of inputs (sometimes with regard to outputs). There is the list of preconditions used in verification of the rest of assertions.
G (
( (LUP_ADDR[5] xor (X LUP_ADDR[5])) or
(LUP_ADDR[6] xor (X LUP_ADDR[6])) or
(LUP_ADDR[7] xor (X LUP_ADDR[7])) or
(LUP_ADDR[8] xor (X LUP_ADDR[8])) ) ->
(
(X not LUP_SR_CLEAN) and
X (
( not ( (LUP_ADDR[5] xor (X LUP_ADDR[5])) or
(LUP_ADDR[6] xor (X LUP_ADDR[6])) or
(LUP_ADDR[7] xor (X LUP_ADDR[7])) or
(LUP_ADDR[8] xor (X LUP_ADDR[8])) ))
U LUP_SR_CLEAN
)
)
);
After change of LUP_ADDR there is no further change of LUP_ADDR until
LUP_SR_CLEAN=1. The only magic about this formula are the positions
of
This is absolutely new implementation of
But if you simply repeat the verification in the same way as above it will not finish because of high memory complexity. There is not any other way than that of making changes inside of VHDL code. We have decided to shrink the length of FIFO to only 4 items. Of course, this modification may cause that the formula which is valid for the modified code would not be valid for the original one, but it is the matter of good reasoning of the verifier to choose formulas, which are valid equivalently in both designs. Formal proof of this equality would be hard and a lot of time consuming.
There are LTL formulas for the shrunk
There are preconditions for the shrunk
G (
( (LUP_ADDR[7] xor (X LUP_ADDR[7])) or
(LUP_ADDR[8] xor (X LUP_ADDR[8])) ) ->
(
(X not LUP_SR_CLEAN) and
X (
( not ( (LUP_ADDR[7] xor (X LUP_ADDR[7])) or
(LUP_ADDR[8] xor (X LUP_ADDR[8])) ))
U LUP_SR_CLEAN
)
)
);
The VHDL code of the shrunk
By the process of verification there have not been found any
mistakes in the design of
Currently there have been verified only properties of the part
The first approach to the verification of this property was very simple.
We took the component
This situation is now solved by the abstraction. The component
Furthermore it has been given by developer that the clock of
init(LBCLK) := 0;
init(lbclk_count) := 0;
init(CLK) := 0;
if ((LBCLK=0) && (lbclk_count=2))
--no lbclk edge when the count of lbclk is high
aux_lbclk := 0;
else
aux_lbclk := {0,1};
next(LBCLK) := aux_lbclk;
if (CLK=0 & lbclk_count=0)
--no clk edge when the count of lbclk is low
aux_clk := 0;
else
aux_clk := {0,1};
next(CLK) := aux_clk;
--computation of lbclk_count:
if (CLK=0 & aux_clk=1)
{
if (LBCLK=0 & aux_lbclk=1)
next(lbclk_count) := lbclk_count;
else
next(lbclk_count) := 0;
}
else
{
if (LBCLK=0 & aux_lbclk)
next(lbclk_count) := lbclk_count + 1;
else
next(lbclk_count) := lbclk_count;
}
The developer also states that READY is enabled at most each 5 ticks of clock. It has been modeled in SMV this way:
init(READY) := 0;
init(delay_ready) := 0;
delay_ready_decrease := {0,1};
if (CLK=0 & aux_clk=1)
{
if (delay_ready~=0)
{
if (delay_ready_decrease)
{ next(delay_ready) := delay_ready - 1; }
else { next(delay_ready) := delay_ready; }
next(READY) := 0; --while waiting producing 0
}
else
{
--after at most 5 ticks it decides to produce 1:
next(delay_ready) := 5;
next(READY) := 1;
}
}
else { next(READY) := READY; }
The LTL property, which has been verified in the system with the above modifications, is the following:
G (not en_reg_5 and (reg_phase_1_ or reg_phase_2_ or reg_phase_3_ or reg_phase_4_) ->
(not reg_addr_out_8_ <-> br_addr_lb_9_))
To prove it we only need these two basic preconditions:
Take notice that the source code of abstract model of
There has been also verified the property of the phase register, which says, that any of bits of the phase register does not remain a zero forever. Expressed in LTL as:
There is only needed one more precondition (together with two above):not F G reg_phase_i_ = 0 &ldots; where i is the index of the bit in the phase register.
G F READY &ldots; READY is infinitely-times 1
In this paper it has been shown that in the complex formal verification we have to
use techniques which are not absolutely formal. For example in
the verification of
It has been also shown that the fight with the state explosion problem may be not always
successful. When it is successful, it is often in spite of the price of large
changes in the model. It was found out that the space complexity
is not directly dependent on the length of source code or the count of
registers. By the virtue of
On one hand we have gained the pessimistic results, because we had to do many changes in the design and write large amounts of preconditions ourselves. It took a lot of time and human resources. On the other hand we have shown that even using such simple freeware verification tool as Cadence SMV it is possible to verify the large amount of complex properties of hardware components.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library unisim;
use unisim.all;
entity UH_FIFO is
port(
-- HFE interface
HFE_DOUT : in std_logic_vector(15 downto 0);
HFE_ADDR : in std_logic_vector(5 downto 0);
HFE_RDY : out std_logic; -- Control signals
HFE_REQ : in std_logic;
HFE_WEN : in std_logic;
HFE_CLK : in std_logic;
-- LUP interface
-- whether cell contains unfied header:
LUP_SR_VALID : out std_logic;
-- clean addressed cell:
LUP_SR_CLEAN : in std_logic;
LUP_DATA : out std_logic_vector(31 downto 0);
LUP_ADDR : in std_logic_vector(8 downto 0);
LUP_CLK : in std_logic;
RESET : in std_logic
);
end UH_FIFO;
architecture behavioral of UH_FIFO is
signal hfe_block : std_logic_vector(1 downto 0);
signal hfe_block_aux : std_logic_vector(1 downto 0);
signal ready : std_logic_vector(3 downto 0);
signal reg_ready : std_logic_vector(3 downto 0);
signal hfe_allocated : std_logic;
signal addra_i : std_logic_vector(9 downto 0);
signal write_i : std_logic;
signal uh_valid : std_logic;
signal hfe_is_producing : std_logic;
signal hfe_rdy_i : std_logic;
signal lup_block : std_logic_vector(1 downto 0);
signal gnd_bus : std_logic_vector(31 downto 0);
signal gnd : std_logic;
signal pwr : std_logic;
component RAMB16_S18_S36
port (
ADDRA: IN std_logic_vector(9 downto 0);
ADDRB: IN std_logic_vector(8 downto 0);
DIA: IN std_logic_vector(15 downto 0);
DIB: IN std_logic_vector(31 downto 0);
DIPA: IN std_logic_vector(1 downto 0);
DIPB: IN std_logic_vector(3 downto 0);
WEA: IN std_logic;
WEB: IN std_logic;
CLKA: IN std_logic;
CLKB: IN std_logic;
SSRA: IN std_logic;
SSRB: IN std_logic;
ENA: IN std_logic;
ENB: IN std_logic;
DOA: OUT std_logic_vector(15 downto 0);
DOB: OUT std_logic_vector(31 downto 0);
DOPA: OUT std_logic_vector(1 downto 0);
DOPB: OUT std_logic_vector(3 downto 0));
END component;
component dp_regflags
generic(
EXADDR : integer
);
port(
RESET : in std_logic;
-- SET part
CLK_SET : in std_logic;
SET : in std_logic;
ADDR_SET : in std_logic_vector(EXADDR-1 downto 0);
DO_SET : out std_logic;
-- CLR part
CLK_CLR : in std_logic;
CLR : in std_logic;
ADDR_CLR : in std_logic_vector(EXADDR-1 downto 0);
DO_CLR : out std_logic;
DO_ALL : out std_logic_vector((2**EXADDR)-1 downto 0)
);
end component;
begin
gnd_bus <= "00000000000000000000000000000000";
gnd <= '0';
pwr <= '1';
lup_block <= LUP_ADDR(8 downto 7); --PP
addra_i <= hfe_block & "00" & HFE_ADDR; --PP
write_i <= HFE_WEN and hfe_allocated;
HFE_RDY <= hfe_rdy_i;
hfe_communication:process(HFE_CLK, RESET)
begin
if reset = '1' then
hfe_rdy_i <= '0';
hfe_allocated <= '0';
hfe_is_producing <= '0';
hfe_block <= "00"; --PP
hfe_block_aux <= "00"; --PP
uh_valid <= '0';
elsif HFE_CLK'event and HFE_CLK = '1' then
uh_valid <= '0';
hfe_rdy_i <= '0';
if HFE_REQ='1' then
if hfe_is_producing='1' then
uh_valid <= '1';
hfe_block <= hfe_block+1;
hfe_is_producing <= '0';
hfe_allocated <= '0';
elsif reg_ready(conv_integer(unsigned(
hfe_block)))='0' then
hfe_rdy_i <= '1';
hfe_allocated <= '1';
hfe_block_aux <= hfe_block;
end if;
elsif hfe_allocated='1' then
hfe_is_producing<='1';
end if;
end if;
end process;
reg_ready_proc: process(HFE_CLK,RESET)
begin
if reset='1' then
reg_ready <= (others => '0');
elsif HFE_CLK'event and HFE_CLK='1' then
reg_ready <= ready;
end if;
end process;
block_ram: RAMB16_S18_S36 port map(
ADDRA => addra_i,
ADDRB => LUP_ADDR,
DIA => HFE_DOUT,
DIB => gnd_bus,
DIPA => gnd_bus(1 downto 0),
DIPB => gnd_bus(3 downto 0),
WEA => write_i,
WEB => gnd,
CLKA => HFE_CLK,
CLKB => LUP_CLK,
SSRA => gnd,
SSRB => gnd,
ENA => pwr,
ENB => pwr,
DOA => open,
DOB => LUP_DATA,
DOPA => open,
DOPB => open
);
flags: dp_regflags
generic map(
EXADDR => 2 --PP
)
port map(
RESET => RESET,
-- SET part
CLK_SET => HFE_CLK,
SET => uh_valid,
ADDR_SET => hfe_block_aux,
DO_SET => open,
-- CLR part
CLK_CLR => LUP_CLK,
CLR => lup_sr_clean,
ADDR_CLR => lup_block,
DO_CLR => LUP_SR_VALID,
DO_ALL => ready
);
end behavioral;
module \lbconn_mem_524288_13_notri (
\ADDR ,\nx1653 ,\LBLAST ,\nx1797 ,\nx1603 ,\NOT_lb_oen ,
\LBFRAME_modgen_select_12 , \data_in_reg_0_ ,\DATA_IN ,
\data_in_reg_1_ ,\data_in_reg_2_ ,\data_in_reg_3_ ,
\data_in_reg_4_ ,\data_in_reg_5_ ,\data_in_reg_6_ ,
\data_in_reg_7_ ,\data_in_reg_8_ ,\data_in_reg_9_ ,
\data_in_reg_10_ ,\data_in_reg_11_ ,\data_in_reg_12_ ,
\data_in_reg_13_ ,\data_in_reg_14_ ,\data_in_reg_15_ ,
\DATA_OUT ,\LBAD ,\RW ,\LBAS_modgen_select_11 ,\LBRW ,
\EN ,\LBCLK , LBCLK_NEXT ,\RESET ,\ARDY_modgen_select_6 ,
\SEL ,\DRDY ){
output \ADDR : array 12..0 of boolean resolve;
\nx1653 : boolean resolve;
input \LBLAST : boolean resolve;
\nx1797 : boolean resolve;
\nx1603 : boolean resolve;
\NOT_lb_oen : boolean resolve;
input \LBFRAME_modgen_select_12:array 9..9 of boolean resolve;
\data_in_reg_0_ : boolean resolve;
input \DATA_IN : array 15..0 of boolean resolve;
\data_in_reg_1_ : boolean resolve;
\data_in_reg_2_ : boolean resolve;
\data_in_reg_3_ : boolean resolve;
\data_in_reg_4_ : boolean resolve;
\data_in_reg_5_ : boolean resolve;
\data_in_reg_6_ : boolean resolve;
\data_in_reg_7_ : boolean resolve;
\data_in_reg_8_ : boolean resolve;
\data_in_reg_9_ : boolean resolve;
\data_in_reg_10_ : boolean resolve;
\data_in_reg_11_ : boolean resolve;
\data_in_reg_12_ : boolean resolve;
\data_in_reg_13_ : boolean resolve;
\data_in_reg_14_ : boolean resolve;
\data_in_reg_15_ : boolean resolve;
output \DATA_OUT : array 15..0 of boolean resolve;
input \LBAD : array 15..0 of boolean resolve;
\RW : boolean resolve;
input \LBAS_modgen_select_11:array 9..9 of boolean resolve;
input \LBRW : boolean resolve;
\EN : boolean resolve;
input \LBCLK : boolean resolve;
input LBCLK_NEXT : boolean resolve;
input \RESET : boolean resolve;
input \ARDY_modgen_select_6:array 9..9 of boolean resolve;
\SEL : boolean resolve;
input \DRDY : boolean resolve;
gener_data: array 8..0 of boolean resolve;
bank: boolean resolve;
aux_bank: boolean resolve;
action: array 2..0 of boolean resolve;
aux_action: array 2..0 of boolean resolve;
delay: array 4..0 of boolean resolve;
init(bank) := 1;
init(action) := 0;
init(gener_data) := 0;
init(DATA_OUT) := 1;
init(RW) := 0;
init(delay) := 0;
if (LBCLK=0 && LBCLK_NEXT=1)
{
if (delay~=0)
{
next(delay) := delay - 1;
next(DATA_OUT) := DATA_OUT;
next(action) := action;
next(gener_data) := gener_data;
next(bank) := bank;
next(RW) := RW;
}
else
{
next(delay) := 5;
next(DATA_OUT[0]) := {0,1};
next(DATA_OUT[2]) := {0,1};
next(DATA_OUT[3]) := {0,1};
next(DATA_OUT[4]) := {0,1};
next(DATA_OUT[5]) := {0,1};
next(DATA_OUT[6]) := {0,1};
next(DATA_OUT[7]) := {0,1};
next(DATA_OUT[8]) := {0,1};
next(DATA_OUT[9]) := {0,1};
next(DATA_OUT[10]) := {0,1};
next(DATA_OUT[11]) := {0,1};
next(DATA_OUT[12]) := {0,1};
next(DATA_OUT[13]) := {0,1};
next(DATA_OUT[14]) := {0,1};
next(DATA_OUT[15]) := {0,1};
aux_action[0] := {0,1};
aux_action[1] := {0,1};
aux_action[2] := {0,1};
if (aux_action > 5) { next(action) := 0; }
else { next(action) := aux_action; }
if (aux_action = 5)
{
next(gener_data) := 0;
aux_bank := {0,1};
next(bank) := aux_bank;
next(DATA_OUT[1]) := !aux_bank;
next(RW) := 1;
}
else
{
next(gener_data[0]) := {0,1};
next(gener_data[1]) := {0,1};
next(gener_data[2]) := {0,1};
next(gener_data[3]) := {0,1};
next(gener_data[4]) := {0,1};
next(gener_data[5]) := {0,1};
next(gener_data[6]) := {0,1};
next(gener_data[7]) := {0,1};
next(gener_data[8]) := {0,1};
next(DATA_OUT[1]) := {0,1};
next(bank) := bank;
next(RW) := 0;
}
}
}
else
{
next(DATA_OUT) := DATA_OUT;
next(bank) := bank;
next(RW) := RW;
next(gener_data) := gener_data;
next(action) := action;
}
ADDR := action::(bank & !RW)::gener_data;
EN := 1;
SEL := 1;
}