Are all these claims in VHDL correct?

W

Weng Tianxiang

Guest
Hi,
I am trying to claim the following things in VHDL in
some written materials, and want to know if they are absolute
correct practically based on Xilinx FPGA implementations, not
theoretically on ModelSim
simulations.

signal X : unsigned(63 downto 0);
signal X0 : unsigned(63 downto 0);
signal X1 : unsigned(63 downto 0);
signal X2 : unsigned(63 downto 0);
signal X3 : unsigned(63 downto 0);
signal A1 : std_logic;
signal A2 : std_logic;
signal A3 : std_logic;

1. The following M1 and M2 process code implementations are the same:

M1 : process(..)
begin
X <= X0;
if A1 = '1' then
X <= X1;
if A2 = '1' then
X <= X2;
elsif A3 = '1' then
X <= X3;
end if;
end if;
end process;

M2 : process(..)
begin
if A1 = '1' then
if A2 = '1' then
X <= X2;
elsif A3 = '1' then
X <= X3;
else
X <= X1;
end if;
else
X <= X0;
end if;
end process;

2. The following M3 to M5 process code implementations are the same:

M3 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
null;
end if;
end process;

M4 : process(A1)
begin
if A1 = '1' then
X <= X1;
end if;
end process;

M5 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end process;

3. The following M6 to M8 process code implementations are the same:

M6 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
else
null;
end if;
end if;
end process;

M7 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
end if;
end if;
end process;

M8 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end if;
end process;

Thank you.

Weng
 
On Wed, 20 May 2009 18:50:56 -0700 (PDT), Weng Tianxiang wrote:

I am trying to claim the following things in VHDL in
some written materials, and want to know if they are absolute
correct practically based on Xilinx FPGA implementations, not
theoretically on ModelSim simulations.
Click to expand...
That's a very strange way to look at it. The VHDL language
is defined by its simulation semantics. Synthesis creates
hardware that conforms to a certain (very useful) subset
of those behaviours. It makes no sense to say that your
understanding of VHDL is "absolutely correct... based on
FPGA implementations".

On the other hand, you CAN reasonably ask "do these two
pieces of VHDL code imply identical synthesised hardware?".

signal X : unsigned(63 downto 0);
signal X0 : unsigned(63 downto 0);
signal X1 : unsigned(63 downto 0);
signal X2 : unsigned(63 downto 0);
signal X3 : unsigned(63 downto 0);
signal A1 : std_logic;
signal A2 : std_logic;
signal A3 : std_logic;

1. The following M1 and M2 process code implementations are the same:

M1 : process(..)
begin
X <= X0;
if A1 = '1' then
X <= X1;
if A2 = '1' then
X <= X2;
elsif A3 = '1' then
X <= X3;
end if;
end if;
end process;

M2 : process(..)
begin
if A1 = '1' then
if A2 = '1' then
X <= X2;
elsif A3 = '1' then
X <= X3;
else
X <= X1;
end if;
else
X <= X0;
end if;
end process;
Click to expand...
Well... single-stepping through the two pieces of
code in a simulator will of course show slightly
different sequences of activity, but I agree that
the externally-visible results of the two processes
should be identical. It is impossible to tell the
difference between

Y <= A;
Y <= B; -- completely replaces assignment Y<=A

and

Y <= B;

(unless the evaluation of expression A has side-effects,
of course).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2. The following M3 to M5 process code implementations are the same:

M3 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
null;
end if;
end process;

M4 : process(A1)
begin
if A1 = '1' then
X <= X1;
end if;
end process;
Click to expand...
I agree that these two are identical in every meaningful way.
"null;" really does nothing.

M5 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end process;
Click to expand...
No, this is not the same. In M5 but not in M4, when
A1 transitions to a value that is not '1', signal X
is written; there will be no value-change on X as a
result, for sure, but there *is* a transaction on X
and that could be detected, outside the process,
with the 'transaction, 'active or 'quiet attributes.

None of the processes M3 to M5 follow any conventional
synthesis template. If you had included X1 in the
sensitivity list, they would all be perfectly good
descriptions of a transparent latch. If you had
rewritten the condition as "if rising_edge(A1)" they
would all be perfectly good descriptions of a register.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3. The following M6 to M8 process code implementations are the same:

M6 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
else
null;
end if;
end if;
end process;

M7 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
end if;
end if;
end process;
Click to expand...
M6 and M7 are completely identical in behaviour, yes.

M8 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end if;
end process;
Click to expand...
Same discussion as for M5, above.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:ri0a15dqak38clq3j8uuvb2tl6lusob9lu@4ax.com...
M4 : process(A1)
begin
if A1 = '1' then
X <= X1;
end if;
end process;

I agree that these two are identical in every meaningful way.
"null;" really does nothing.

M5 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end process;

No, this is not the same. In M5 but not in M4, when
A1 transitions to a value that is not '1', signal X
is written; there will be no value-change on X as a
result, for sure, but there *is* a transaction on X
and that could be detected, outside the process,
with the 'transaction, 'active or 'quiet attributes.

None of the processes M3 to M5 follow any conventional
synthesis template. If you had included X1 in the
sensitivity list, they would all be perfectly good
descriptions of a transparent latch. If you had
rewritten the condition as "if rising_edge(A1)" they
would all be perfectly good descriptions of a register.



M7 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
end if;
end if;
end process;

M6 and M7 are completely identical in behaviour, yes.

M8 : process(CLK)
begin
if CLK'event and CLK = '1' then
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end if;
end process;

Same discussion as for M5, above.
Click to expand...
I'm missing the point here. The sensitivity list for M4 and M5 only
includes A1, so any change in X1 doesn't propagate through to X in either
case.

Also, are you suggesting that an X <= X; would be seen as a transaction
within a sensitivity list?

M9: process (X)
begin
if X = '1' then
Y <= Y1;
end if;
end process;

where Y will take on the value of Y1, despite no change in X?
 
On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote:

None of the processes M3 to M5 follow any conventional
synthesis template. If you had included X1 in the
sensitivity list, they would all be perfectly good
descriptions of a transparent latch. If you had
rewritten the condition as "if rising_edge(A1)" they
would all be perfectly good descriptions of a register.
[...]
I'm missing the point here. The sensitivity list for M4 and M5 only
includes A1, so any change in X1 doesn't propagate through to X in either
Click to expand...
Right. So the description is not a piece of synthesisable
hardware; it's neither a latch, nor a register, nor a
combinational function. I agree that the externally
observable simulation behaviour would be the same for
all those examples, apart from the 'transaction thing
I mentioned. But it's not very useful.

Also, are you suggesting that an X <= X; would be seen as a transaction
within a sensitivity list?
Click to expand...
No. Be careful about the terminology; sensitivity lists see
EVENTS, i.e. value-changes, on a signal; there is of course
no such event as a result of X<=X. However, there is a
TRANSACTION, an attempt to update X. You can't ordinarily
see transactions in VHDL, but you can detect them using
the built-in attributes I mentioned.

M9: process (X)
begin
if X = '1' then
Y <= Y1;
end if;
end process;

where Y will take on the value of Y1, despite no change in X?
Click to expand...
Sorry, I don't see what you're asking here. If there's no change
in X's value then the process won't run and Y won't update.
In a real hardware transparent latch, you DO expect Y to follow
the input Y1 if the enable X is asserted; you can easily get this
by including both X and Y1 in the sensitivity list, and that gives
you a good synthesisable description of a transparent latch.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:g85a15lp0jd5kap4u0n5rlbq82k2l3mbh1@4ax.com...
On Thu, 21 May 2009 09:46:57 +0100, "Fredxx" wrote:

None of the processes M3 to M5 follow any conventional
synthesis template. If you had included X1 in the
sensitivity list, they would all be perfectly good
descriptions of a transparent latch. If you had
rewritten the condition as "if rising_edge(A1)" they
would all be perfectly good descriptions of a register.
[...]
I'm missing the point here. The sensitivity list for M4 and M5 only
includes A1, so any change in X1 doesn't propagate through to X in either

Right. So the description is not a piece of synthesisable
hardware; it's neither a latch, nor a register, nor a
combinational function. I agree that the externally
observable simulation behaviour would be the same for
all those examples, apart from the 'transaction thing
I mentioned. But it's not very useful.

Also, are you suggesting that an X <= X; would be seen as a transaction
within a sensitivity list?

No. Be careful about the terminology; sensitivity lists see
EVENTS, i.e. value-changes, on a signal; there is of course
no such event as a result of X<=X. However, there is a
TRANSACTION, an attempt to update X. You can't ordinarily
see transactions in VHDL, but you can detect them using
the built-in attributes I mentioned.
Click to expand...
It is synthsisable but perhaps not tgive the intended result. In essence an
event on A1 and A1 = 1, would cause the value X1 to be latched into X. In
both cases?

M9: process (X)
begin
if X = '1' then
Y <= Y1;
end if;
end process;

where Y will take on the value of Y1, despite no change in X?

Sorry, I don't see what you're asking here. If there's no change
in X's value then the process won't run and Y won't update.
In a real hardware transparent latch, you DO expect Y to follow
the input Y1 if the enable X is asserted; you can easily get this
by including both X and Y1 in the sensitivity list, and that gives
you a good synthesisable description of a transparent latch.
Click to expand...

That was my point, how would a transaction on X be "seen"? I thought VHDL
was all about events.
 
On Thu, 21 May 2009 10:09:26 +0100, "Fredxx" wrote:

[regarding this example]

M4 : process(A1)
begin
if A1 = '1' then
X <= X1;
end if;
end process;

It is synthsisable but perhaps not tgive the intended result.
In essence an event on A1 and A1 = 1, would cause the value
X1 to be latched into X.
Click to expand...
I'm confused. I already explained, with justification,
why it's not correctly synthesisable, and then you tell
me it is...

Here's why that is BAD code for synthesis:
- The description, as you say, implies latching only on the
rising edge of A1. Like a D flop.
- But there is no "if A1'event" or "if rising_edge(A1)" in
the process. So it doesn't match the standard clocked
synthesis template.

In the synth tool I tried just now (Mentor Precision)
I got a warning about precisely this, telling me that
there might be synthesis/simulation mismatches (there will).
And it created a transparent latch, because - as usual -
for any non-clocked process, synthesis will assume a
complete sensitivity list. Personally I would prefer it
if synthesis tools were to reject the code as an error,
but that's not what happens; instead you get hardware
whose behaviour doesn't match the simulation. I'm fairly
sure that almost all mainstream synthesis tools behave
in a similar way on this example, but I can't be bothered
trying them all because it's code that should not be
synthesised.

In both cases?
Click to expand...
I already stated, correctly and with explanation, that
Weng's processes M4 and M5 have identical behaviour
in simulation. Both of them are inappropriate for
synthesis.

how would a transaction on X be "seen"? I thought VHDL
was all about events.
Click to expand...
As I already pointed out, you can sense transactions in
simulation by using the 'transaction, 'active and 'quiet
built-in attributes. VHDL transactions have no use
in synthesis.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
I think we can summarize...

M1 and M2 will synthesize to identical combinatorial circuits. There
may be warnings about synthesis/simulations mis-matches if the
sensitivity lists are not complete.

M3, M4 and M5 will synthesize to identical combinatorial circuits,
with a warning on the incomplete sensitivity list.

M6 and M7 will synthesize to identical sequential circuits (D-flop
with clk enable). M8 will synthesize to a sequential circuit with
identical behavior (on a clock cycle basis) to that of M6 and M7, but
the synthesis tool may try to build a feedback mux instead of using
the built-in clk enable on the register. Different synthesis tools may
handle this differently.

It should be noted that if X were a port of mode OUT (or an alias
thereof), then the processes that attempt to read X (M5 & M8) would
not synthesize at all.

It should also be noted that of M1 and M2, M1 is preferable for one
significant reason: The default assignemnt to X up front makes it very
easy to verify that M1 will not result in a latch. It is more
difficult to verify that M2 will not result in a latch.

Andy
 
On Thu, 21 May 2009 08:56:15 -0700 (PDT), Weng Tianxiang wrote:


If M5 Xilinx implementation were carried out for M3 or M4, you
couldn't tell there was a transaction on X,
because it didn't generate a transaction information except it really
happend internally.
It may violate the true spirit of coding, but it doesn't hurt anybody
and always gives the correct result.
Click to expand...
Yes, I completely agree. They are the same for synthesis,
in every tool I have tried.

M9: process (X, Y1)
begin
if X = '1' then
Y <= Y1;
end if;
end process;

Does it mean:
X is connected to the latch enable terminal and Y1 to data input
terminal and Y is configured as a transparent latch?
Click to expand...
Yes, exactly. It is a good description both for simulation
and for synthesis. The problem, of course, is that many
FPGAs do not have good latch primitives (except, maybe, on
their I/O pads) and so you can get very strange hardware
implementations that will cause trouble with static
timing analysis.

Regards
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On May 21, 12:40 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Wed, 20 May 2009 18:50:56 -0700 (PDT), Weng Tianxiang wrote:
I am trying to claim the following things in VHDL in
some written materials, and want to know if they are absolute
correct practically based on Xilinx FPGA implementations, not
theoretically on ModelSim simulations.

That's a very strange way to look at it.  The VHDL language
is defined by its simulation semantics.  Synthesis creates
hardware that conforms to a certain (very useful) subset
of those behaviours.  It makes no sense to say that your
understanding of VHDL is "absolutely correct... based on
FPGA implementations".

On the other hand, you CAN reasonably ask "do these two
pieces of VHDL code imply identical synthesised hardware?".





signal   X  : unsigned(63 downto 0);
signal   X0 : unsigned(63 downto 0);
signal   X1 : unsigned(63 downto 0);
signal   X2 : unsigned(63 downto 0);
signal   X3 : unsigned(63 downto 0);
signal   A1 : std_logic;
signal   A2 : std_logic;
signal   A3 : std_logic;

1. The following M1 and M2 process code implementations are the same:

M1 : process(..)
begin
  X <= X0;
  if A1 = '1' then
     X <= X1;
     if A2 = '1' then
        X <= X2;
     elsif A3 = '1' then
        X <= X3;
     end if;
  end if;
end process;

M2 : process(..)
begin
  if A1 = '1' then
     if A2 = '1' then
        X <= X2;
     elsif A3 = '1' then
        X <= X3;
     else
        X <= X1;
     end if;
  else
     X <= X0;
  end if;
end process;

Well... single-stepping through the two pieces of
code in a simulator will of course show slightly
different sequences of activity, but I agree that
the externally-visible results of the two processes
should be identical.  It is impossible to tell the
difference between

  Y <= A;
  Y <= B; -- completely replaces assignment Y<=A

and

  Y <= B;

(unless the evaluation of expression A has side-effects,
of course).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





2. The following M3 to M5 process code implementations are the same:

M3 : process(A1)
begin
  if A1 = '1' then
     X <= X1;
  else
     null;
  end if;
end process;

M4 : process(A1)
begin
  if A1 = '1' then
     X <= X1;
  end if;
end process;

I agree that these two are identical in every meaningful way.
"null;" really does nothing.

M5 : process(A1)
begin
  if A1 = '1' then
     X <= X1;
  else
     X <= X;
  end if;
end process;

No, this is not the same.  In M5 but not in M4, when
A1 transitions to a value that is not '1', signal X
is written; there will be no value-change on X as a
result, for sure, but there *is* a transaction on X
and that could be detected, outside the process,
with the 'transaction, 'active or 'quiet attributes.

None of the processes M3 to M5 follow any conventional
synthesis template.  If you had included X1 in the
sensitivity list, they would all be perfectly good
descriptions of a transparent latch.  If you had
rewritten the condition as "if rising_edge(A1)" they
would all be perfectly good descriptions of a register.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





3. The following M6 to M8 process code implementations are the same:

M6 : process(CLK)
begin
  if CLK'event and CLK = '1' then
     if A1 = '1' then
        X <= X1;
     else
        null;
     end if;
  end if;
end process;

M7 : process(CLK)
begin
  if CLK'event and CLK = '1' then
     if A1 = '1' then
        X <= X1;
     end if;
  end if;
end process;

M6 and M7 are completely identical in behaviour, yes.

M8 : process(CLK)
begin
  if CLK'event and CLK = '1' then
     if A1 = '1' then
        X <= X1;
     else
        X <= X;
     end if;
  end if;
end process;

Same discussion as for M5, above.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -
Click to expand...
Hi Jonathan,
Once again I get your valuable comments.

1. "On the other hand, you CAN reasonably ask "do these two
pieces of VHDL code imply identical synthesised hardware?". "

Yes, you are right and I accept it.

2. >M5 : process(A1)
begin
if A1 = '1' then
X <= X1;
else
X <= X;
end if;
end process;
Click to expand...

No, this is not the same. In M5 but not in M4, when
A1 transitions to a value that is not '1', signal X
is written; there will be no value-change on X as a
result, for sure, but there *is* a transaction on X
and that could be detected, outside the process,
with the 'transaction, 'active or 'quiet attributes.

If M5 Xilinx implementation were carried out for M3 or M4, you
couldn't tell there was a transaction on X,
because it didn't generate a transaction information except it really
happend internally.
It may violate the true spirit of coding, but it doesn't hurt anybody
and always gives the correct result.

3. I have to frankly admit that I have no hardware transparent latch
in my mind. In all my designs, there are only two data signal types:
register or combinational signal.
Your comments bring me back some ideas about transparent latch:

M9: process (X, Y1)
begin
if X = '1' then
Y <= Y1;
end if;
end process;

Does it mean:
X is connected to the latch enable terminal and Y1 to data input
terminal and Y is configured as a transparent latch?

Thank you.

Weng
 
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> writes:

Yes, exactly. It is a good description both for simulation
and for synthesis. The problem, of course, is that many
FPGAs do not have good latch primitives (except, maybe, on
their I/O pads) and so you can get very strange hardware
implementations that will cause trouble with static
timing analysis.
Click to expand...
Hi Jonathan,

I noticed whilst delving with FPGA editor into Xilinx devices that
there is a latch option within the flipflop block - have you ever used
them? Will synth tools map to them do you know?

As an aside - the Virtex-5 version of Microblaze has 3 latches buried
deep inside it...

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
 
On Fri, 22 May 2009 06:52:40 -0700 (PDT), Weng Tianxiang wrote:

Have you received my email?
Click to expand...
no, not yet. Just put the six-letter name of my
company in place of MYCOMPANY in the email address.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On May 21, 9:44 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
On Thu, 21 May 2009 08:56:15 -0700 (PDT), Weng Tianxiang wrote:
If M5 Xilinx implementation were carried out for M3 or M4, you
couldn't tell there was a transaction on X,
because it didn't generate a transaction information except it really
happend internally.
It may violate the true spirit of coding, but it doesn't hurt anybody
and always gives the correct result.

Yes, I completely agree.  They are the same for synthesis,
in every tool I have tried.

M9: process (X, Y1)
begin
   if X = '1' then
       Y <= Y1;
   end if;
end process;

Does it mean:
X is connected to the latch enable terminal and Y1 to data input
terminal and Y is configured as a transparent latch?

Yes, exactly.  It is a good description both for simulation
and for synthesis.  The problem, of course, is that many
FPGAs do not have good latch primitives (except, maybe, on
their I/O pads) and so you can get very strange hardware
implementations that will cause trouble with static
timing analysis.

Regards
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Click to expand...
Hi Jonathan,
Thank you for your answer.

Have you received my email?

Weng
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top