Clock Edge notation

[Paul Uiterlinden]

Thomas Fischer wrote:

Thomas Fischer schrieb:

the problem only occures, if a signal is used as the rdclk, if the
rdclk is taken directly from the entity port clk_i everything
works fine.

I'm still learning, seems to be some sort of "delta cycle race condition"

It is not a race condition in the sense of the definition of a race
condition. The outcome is determinitic because it does not depend of the
order of evaluation of processes (including signal assignments).

Each signal assignment adds a delta cycle delay. By adding a signal
assignment in the clock, the receiving block is clocked one delta cycle
later. The effect of this is that it clocks in the new signal values
(after the clock edge) of sending blocks running on the original clock
(without the extra signal assgnment).

In general it is a bad idea to put signal assignments in clocks. Or you
must make sure that all clocks derived from a common clock source
contain the same number of signal assignments.

Some other solutions are discussed in
http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=1765

Paul.

 

[Mike Treseler]

IcYdRIP wrote:

thank you !

You are welcome.

but I have a doubt. if I invoke a procedure in a process, and the
process with a clock sensitive signal.

A vhdl procedure is not so complicated.
It is mainly an editing convenience.
Get a simulator, try it and see.
Any invocation of a procedure can be replaced
by the one or more lines of code that the
procedure represents.

See my folder for procedure examples for
design and simulation.

http://home.comcast.net/~mike_treseler/


-- Mike Treseler

 

[Engineering Guy]

rbn wrote:

Hi all,

I have a question concerning connection of bidirectional signals.

Consider the code below. The attempt is to make a wrapper, which blasts
a component consisting of a std_logic_vector into separate std_logics.
Both the instantiated component's and the blasting entity's ports are
defined as inouts. The challenge now is to connect index 0 of the
std_logic_vector with the sl0 port and index 1 of the std_logic_vector
with the sl1 port in a bidrectional manner.

My first attempt was - as shown in the code - to make four concurrent
assignments utilizing an intermediate signal, slv_s. This doesn't seem
to work. It reaches the simulator's iteration limit at time 0.

I have attached two files (well, it turned out that I couldn't attach,
so they're inlined below):
fail.vhd contains the code below and some testbench that instantiates
sl. It fails.
pass.vhd is the same code with std_logic_vectors all over. It passes.

What do I do wrong in the connection, or rather, is there another - and
safe - way to connect the signals?

Any help is highly appreciated.
Thanks,
René Břje Nielsen


entity slv is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end slv;

entity sl is
port (
sl0_io : inout std_logic;
sl1_io : inout std_logic
);
end sl;

architecture wrapper of sl is
component slv
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;
signal slv_s : std_logic_vector(1 downto 0) := (others => 'Z');
begin
slv_s(0) <= sl0_io;
slv_s(1) <= sl1_io;
sl0_io <= slv_s(0);
sl1_io <= slv_s(1);
inst_slv : slv
port map (
slv_io => slv_s
);
end wrapper;


--*************************************************************--
--------------------------- fail.vhd BEGIN ----------------------
--*************************************************************--

------------------------------------------------
-- Innermost component
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity slv is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end slv;

architecture behavioral of slv is
begin

p : process
begin
slv_io <= "ZZ";
wait for 200 ns;
slv_io <= "10";
wait for 200 ns;
slv_io <= "01";
wait for 200 ns;
slv_io <= "ZZ";
wait;
end process p;

end behavioral;

------------------------------------------------
-- Wrapper
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity sl is
port (
sl0_io : inout std_logic;
sl1_io : inout std_logic
);
end sl;

architecture wrapper of sl is
component slv
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;

signal slv_s : std_logic_vector(1 downto 0) := (others => 'Z');

begin

slv_s(0) <= sl0_io;
slv_s(1) <= sl1_io;
sl0_io <= slv_s(0);
sl1_io <= slv_s(1);

inst_slv : slv
port map (
slv_io => slv_s
);

end wrapper;

------------------------------------------------
-- Testbench/Top
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity top is
end top;

architecture testbench of top is

component sl
port (
sl0_io : inout std_logic;
sl1_io : inout std_logic
);
end component;

signal sl0_s : std_logic := 'Z';
signal sl1_s : std_logic := 'Z';

begin

p : process
begin
sl0_s <= 'Z';
sl1_s <= 'Z';
wait for 800 ns;
sl0_s <= '1';
sl1_s <= '0';
wait for 200 ns;
sl0_s <= '0';
sl1_s <= '1';
wait for 200 ns;
sl0_s <= 'Z';
sl1_s <= 'Z';
wait;
end process p;

inst_sl : sl
port map (
sl0_io => sl0_s,
sl1_io => sl1_s
);

end testbench;

--*************************************************************--
--------------------------- fail.vhd END ------------------------
--*************************************************************--

--*************************************************************--
--------------------------- pass.vhd BEGIN ----------------------
--*************************************************************--
------------------------------------------------
-- Innermost component
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity slv is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end slv;

architecture behavioral of slv is
begin

p : process
begin
slv_io <= "ZZ";
wait for 200 ns;
slv_io <= "10";
wait for 200 ns;
slv_io <= "01";
wait for 200 ns;
slv_io <= "ZZ";
wait;
end process p;

end behavioral;

------------------------------------------------
-- Wrapper
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity sl is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end sl;

architecture wrapper of sl is
component slv
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;

begin

inst_slv : slv
port map (
slv_io => slv_io
);

end wrapper;

------------------------------------------------
-- Testbench/Top
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity top is
end top;

architecture testbench of top is

component sl
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;

signal slv_s : std_logic_vector(1 downto 0) := "ZZ";

begin

p : process
begin
slv_s <= "ZZ";
wait for 800 ns;
slv_s <= "01";
wait for 200 ns;
slv_s <= "10";
wait for 200 ns;
slv_s <= "ZZ";
wait;
end process p;

inst_sl : sl
port map (
slv_io => slv_s
);

end testbench;

--*************************************************************--
--------------------------- pass.vhd END ------------------------
--*************************************************************--

Your problem is here:

slv_s(0) <= sl0_io;
slv_s(1) <= sl1_io;
sl0_io <= slv_s(0);
sl1_io <= slv_s(1);

Update to sl0_io causes the event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0).

.... and when the iteration limit is reached, the simulator will give you
an error message.

EG

 

[Engineering Guy]

Engineering Guy wrote:

rbn wrote:

Hi all,

I have a question concerning connection of bidirectional signals.

Consider the code below. The attempt is to make a wrapper, which blasts
a component consisting of a std_logic_vector into separate std_logics.
Both the instantiated component's and the blasting entity's ports are
defined as inouts. The challenge now is to connect index 0 of the
std_logic_vector with the sl0 port and index 1 of the std_logic_vector
with the sl1 port in a bidrectional manner.

My first attempt was - as shown in the code - to make four concurrent
assignments utilizing an intermediate signal, slv_s. This doesn't seem
to work. It reaches the simulator's iteration limit at time 0.

I have attached two files (well, it turned out that I couldn't attach,
so they're inlined below):
fail.vhd contains the code below and some testbench that instantiates
sl. It fails.
pass.vhd is the same code with std_logic_vectors all over. It passes.

What do I do wrong in the connection, or rather, is there another - and
safe - way to connect the signals?

Any help is highly appreciated.
Thanks,
René Břje Nielsen


entity slv is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end slv;

entity sl is
port (
sl0_io : inout std_logic;
sl1_io : inout std_logic
);
end sl;

architecture wrapper of sl is
component slv
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;
signal slv_s : std_logic_vector(1 downto 0) := (others => 'Z');
begin
slv_s(0) <= sl0_io;
slv_s(1) <= sl1_io;
sl0_io <= slv_s(0);
sl1_io <= slv_s(1);
inst_slv : slv
port map (
slv_io => slv_s
);
end wrapper;


--*************************************************************--
--------------------------- fail.vhd BEGIN ----------------------
--*************************************************************--

------------------------------------------------
-- Innermost component
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity slv is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end slv;

architecture behavioral of slv is
begin

p : process
begin
slv_io <= "ZZ";
wait for 200 ns;
slv_io <= "10";
wait for 200 ns;
slv_io <= "01";
wait for 200 ns;
slv_io <= "ZZ";
wait;
end process p;

end behavioral;

------------------------------------------------
-- Wrapper
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity sl is
port (
sl0_io : inout std_logic;
sl1_io : inout std_logic
);
end sl;

architecture wrapper of sl is
component slv
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;

signal slv_s : std_logic_vector(1 downto 0) := (others => 'Z');

begin

slv_s(0) <= sl0_io;
slv_s(1) <= sl1_io;
sl0_io <= slv_s(0);
sl1_io <= slv_s(1);

inst_slv : slv
port map (
slv_io => slv_s
);

end wrapper;

------------------------------------------------
-- Testbench/Top
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity top is
end top;

architecture testbench of top is

component sl
port (
sl0_io : inout std_logic;
sl1_io : inout std_logic
);
end component;

signal sl0_s : std_logic := 'Z';
signal sl1_s : std_logic := 'Z';

begin

p : process
begin
sl0_s <= 'Z';
sl1_s <= 'Z';
wait for 800 ns;
sl0_s <= '1';
sl1_s <= '0';
wait for 200 ns;
sl0_s <= '0';
sl1_s <= '1';
wait for 200 ns;
sl0_s <= 'Z';
sl1_s <= 'Z';
wait;
end process p;

inst_sl : sl
port map (
sl0_io => sl0_s,
sl1_io => sl1_s
);

end testbench;

--*************************************************************--
--------------------------- fail.vhd END ------------------------
--*************************************************************--

--*************************************************************--
--------------------------- pass.vhd BEGIN ----------------------
--*************************************************************--
------------------------------------------------
-- Innermost component
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity slv is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end slv;

architecture behavioral of slv is
begin

p : process
begin
slv_io <= "ZZ";
wait for 200 ns;
slv_io <= "10";
wait for 200 ns;
slv_io <= "01";
wait for 200 ns;
slv_io <= "ZZ";
wait;
end process p;

end behavioral;

------------------------------------------------
-- Wrapper
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity sl is
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end sl;

architecture wrapper of sl is
component slv
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;

begin

inst_slv : slv
port map (
slv_io => slv_io
);

end wrapper;

------------------------------------------------
-- Testbench/Top
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;

entity top is
end top;

architecture testbench of top is

component sl
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;

signal slv_s : std_logic_vector(1 downto 0) := "ZZ";

begin

p : process
begin
slv_s <= "ZZ";
wait for 800 ns;
slv_s <= "01";
wait for 200 ns;
slv_s <= "10";
wait for 200 ns;
slv_s <= "ZZ";
wait;
end process p;

inst_sl : sl
port map (
slv_io => slv_s
);

end testbench;

--*************************************************************--
--------------------------- pass.vhd END ------------------------
--*************************************************************--

Your problem is here:

slv_s(0) <= sl0_io;
slv_s(1) <= sl1_io;
sl0_io <= slv_s(0);
sl1_io <= slv_s(1);

Update to sl0_io causes the event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0). This triggers the
assignment sl0_io <= slv_s(0); to be executed and causes an event on
the sl0_io. This triggers the assignment slv_s(0) <= sl0_io; to be
exectued and causes an event on the slv_s(0).

... and when the iteration limit is reached, the simulator will give you
an error message.

EG
On the other hand, if this is the only connection updating the port, the

delta count overflow should not happen. You may want to check if your
simulator works correctly...

EG

 

[Engineering Guy]

rbn wrote:

I found out that I was not the only one having this problem, so
searching in older topics revealed the solution:

The wrapper should look like:

architecture wrapper of sl is
component slv
port (
slv_io : inout std_logic_vector(1 downto 0)
);
end component;
begin
inst_slv : slv
port map (
slv_io(1) => sl1_io,
slv_io(0) => sl0_io
);
end wrapper;

And then it works!!

/René Břje Nielsen.

Well, that's compact and much faster (no need to execute the

assignments). The simple solutions work best.

EG

 

[Tim Hubberstey]

ALuPin wrote:

When performing a functional simulation with Modelsim
Sdram_csn gets "10" at a certain point. (Reset: Sdram_csn="11")

The Timing Simulation with Modelsim instead shows that
Sdram_csn gets "11".

The very first thing you should do when you get a function <-> gate
mismatch is to go back to your static timing analysis report and verify
that there are no timing violations reported.

The second thing is to verify that your testbench meets the setup & hold
requirements for the "real" part. This applies both to outputs from the
tb and inputs to it.

The third thing is to make sure that any combinational processes in your
RTL have *all* of the input signals in the sensitivity list.

This will take care of 99.9% of mismatches. Any remaining issues will be
the proverbial 5% that takes 95% of the time.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Mike Treseler]

IcYdRIP wrote:

and Mike, I've read the uart code.
It seems all procedures(not in testbench vhdl file) have no parameters.

True. For synthesis, I use procedures to break up
the pages of sequential code that a single process
entity requires. Attaching identifiers to blocks of
code allows me to make the top level procedures
easier to read. It also allows me to match the
specific design to the template, that can be used
for _any_ design.

and all variables declared in the process are all visible in the
procedures which are invoked in the process.

Yes. This is the upside for single
process design entities. No signal
declarations are required.

but as book wrote, a procedure doesn't return any result, just change
the parameter value which will affect the actual parameters when
invoking. and all variables in a procedure are dynamic, they don't
store values during two calls. or this rule just affect the variables
which are declared in the procedure.

Note that the variables *and* the procedures
are declared between the IS and BEGIN of the single process.
No variables are declared in the procedures.
Each process has access can read or write variables
declared above above.

This allows code simplification,
like modifying tx and rx state variables
in the the cpu_regs procedure.

so, as the example uart code wrote, if the variables are declared in
the process which invokes the procedure, then the procedure can use
these variables and pass the changed values to the process?

Yes. You've got it.

-- Mike Treseler

 

[Mike Treseler]

Correction:

Wrong:
"Each process has access can read or write variables
declared above above."

Correct:
Each procedure can read or write variables declared above.


-- Mike Treseler

 

[Mike Treseler]

cristian wrote:

Based on the Procedure definition:
"Formal parameters are separated by semicolons in the formal parameter
list. Each formal parameter is essentially a declaration of an
object that is local to the procedure. "

OK, I see what your are saying.
That definition needs some clarification.
A formal parameter (say my_arg_s) is just a local alias for
the actual object that is declared elsewhere in
the calling process or architecture.
This is bookkeeping. No new object results.
I would reword "essentially a declaration".

I was refering to the formal parameter that may be declared as a
signal.

This "declaration" is just a hint to the compiler
that the formal identifier may be treated as
as signal withing the procedure. I don't understand
why this "hint" is necessary, but it is for signals.
Between a procedure's IS and BEGIN I can declare
temporary constants and variables, but not signals.

Therefore, it's local to the procedure.

The "formal" procedural identifier (say my_arg_s) is local
to the procedure. The signal itself has architecture
(or package) scope.

If the formal
parameter is associated with an 'actual' signal that is a clock signal,
the clock can be used within the procedure.

I agree.

Note that procedures declared in a process
already have access to all architecture signals
and all previously declared process variables.
No parameters are needed to access these objects.

A packaged procedure has no scope in the calling
process, so requires parameters for all
inputs and outputs.

-- Mike Treseler

 

[Marcus Harnisch]

"Weng Tianxiang" <wtx@umem.com> writes:

What is your opinion?

Agreeing with all reasons stated by Kai, I can only recommend staying
in your local clock domain fro as much of your logic as possible. You
*will* have to deal with transmission errors which will spoil the
recovered clock. Use the receive clock only to dump data into a FIFO
(if there is more than one lane you'll have to have at least one for
lane alignment).

Best regards,
Marcus

 

[m]

On 14 Apr 2005 15:31:22 -0700, "Weng Tianxiang" <wtx@umem.com> wrote:

Hi,
Here are more details about the design.

3 Modules:
1. DDR controller;
2. DMA engine;
3. PCI-Express interface;

DDR controller uses local clock; OK;
PCI-Express interface uses transition line clock for receiving part;
OK.
Now the problem is for DMA engine;
My opinion is DMA engine must use local clock to make it robust in any
situations;
My collegue wants to use extracted clock from transition line to clock
DMA engine.

What is your opinion?

Weng

Another option is to use an elasticity buffer and isolate the
recovered clock completely. This way the output of the elasticity
buffer is synchronized to the local clock and you don't have any
clock-domain issues anymore. PCI Express spec gives you enough help to
accomplish this relatively easily.

I am also curious if you are implementing your own PHY or whether you
are using an existing PHY. If the latter, does the PHY support PIPE ?
If yes, you don't have any problems to start with.

 

[Kai Harrekilde-Petersen]

Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de> writes:

Paul wrote:


* finally: VHDL code it better human-readable - IMHO ;-)

I used to think that vhdl would be more readable than verilog, but I've
seen too much vhdl code that looks like this:
x := std_logic_vector(to_unsigned((to_integer(unsigned(z1)) +
to_integer(unsigned(z2))), 9));
...
which I *think* is meant to do the same thing as this nice verilog
code:
x = z1 + z2;

I guess we (at work) are not the only ones that have made a package
with a bunch of typecasting functions to reduce this problem as much
as possible. With our 'type_conv' package the above would look like:

x := to_slv(to_uns(z1) + to_uns(z2), 9);

Which is a reasonable compromise. But I concur with the general
comment about VHDL's verbosity

And finally: It is my personal opinion, that it is better
readable. ;-)

IMHO, it ain't.

It started learing VHDL with only little knowledge about the C
syntax. Now, as I have learned C, Verilog is much more readable, but
still my opinion is the same. When I do Verilog I code it like VHDL
and it looks much better than in examples. But again: IMHO!

I learned C first, then Verilog, and then VHDL.

I've learned to loathe all of them for their individual shortcomings.

I think it was Dave Bishop who said, when asked about the difference
between Verilog and VHDL:

Verilog was designed by a bunch of hardware guys who didn't know a
thing about designing software. We had to beat on it to make it work.

VHDL was designed by a bunch of software guys who didn't know a thing
about designing hardware. We had to beat on it to make it work.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[Egbert Molenkamp]

"Ved P Singh" <vedpsingh@gmail.com> schreef in bericht
news:58b11d8f.0504180359.c4c55b4@posting.google.com...

Hello people,
PLease refer the connections and codes mentioned below.

Problem is that I am getting the output changed at rising edge as well
as falling edge of clock !!!
Though i have never mentioned about fallind edge anywhere, and have
used only rising edges only.


p1: process(reset,clk)

variable fr_cache : std_logic_vector(15 downto 0);
VARIABLE fr_length :integer RANGE 0 TO 15;
variable tmp1 : integer RANGE 0 TO 13;
variable data14_enc1 : std_logic_vector(13 downto 0);
variable data_ser_enc1 : std_logic;
begin
if reset='1' then
fr_length:= 0;
fr_cache := "0000000000000000";
else if rising_edge(CLK) then
fr_cache(fr_length):= frame ;

if fr_length = 15 then
fr_length := 0;
else
fr_length:= fr_length +1;
end if;

end if;
end if;

data14_enc1(13 downto 0) := fr_cache(13 downto 0) ;
-------taking only 14bits out of 16bits


if tmp1 = 13 then
tmp1 := 0; ----converting paraller to serial
else
tmp1 := tmp1 + 1;
end if;

data_ser_enc1 := data14_enc1(tmp1) ;
sig_ser_enc1 <= data_ser_enc1;

end process ;

end Top_level_Encoder_Behav;

This process has the following structure:

process(reset,clk)
...
begin
if reset='1' then
async reset actions
elsif rising-edge(clk) then
synchronous actions
end if;
HERE ARE THE PROBLEMS.
end process;

Notice that if reset='0' and clk changes from '1' to '0' the process is
executed and the code "HERE ARE THE PROBLEMS" is executed. Indeed on the
falling edge of the clock.Notice htat it can increment value tmp1 and this
it behaviour changes on the falling edge.

Egbert Molenkamp

 

[Mike Treseler]

ALuPin wrote:

I want to sample 16MHz data with a 125MHz clock.
Is there some tricky method to perform this kind of oversampling ?

There's a simple one if you have both clocks.
Write a synchronous process using 125MHz
as the clock and 16MHz as an input named "rate"
Synchronize "rate" and use it to generate a
rate_rising clock enable pulse.

-- Mike Treseler

 

[Engineering Guy]

Pasacco wrote:

dear

It is for me unclear to understand differences between the following

signal <= '00000000'; # assuming 8 bit signal
signal <= (others => '0';
signal <= (others => (others => '0'));

GIMY, but so far unsuccesful to find --:

Could anyone comment for this?
Thankyou in advance

Well they have something in common - all of them are incorrect.

First of all, signal is a keyword and cannot be used as identifier so
in the following I will use s instead of signal.

s <= '00000000'; -- is erroneous because of use ' instead of "
s <= (others => '0'; -- is missing a closing )
s <= (others => (others => '0')); -- is illegal for a vector
-- (2 dimensional array required)

Use of others in aggregate makes your code generic. Thus you won't have
to replace all "00000000" with "00" when you change your mind and
vectors should be only 2 bits wide.
The last variant is even more powerful. If you take for example 128x8
variable and you want to initialize it to all 0s you will spend a while
typing the initializer.

EG

 

[Mike Treseler]

Egbert Molenkamp wrote:

This process has the following structure:
process(reset,clk)
..
begin
if reset='1' then
async reset actions
elsif rising-edge(clk) then
synchronous actions
end if;
HERE ARE THE PROBLEMS.
end process;

Notice that if reset='0' and clk changes from '1' to '0' the process is
executed and the code "HERE ARE THE PROBLEMS" is executed. Indeed on the
falling edge of the clock.

Excellent diagnosis.

Interesting. The procedure HERE_ARE_THE_PROBLEMS;
is executed on both edges of reset
and on both edges of clock.

Since it follows the /if/elsif/end if/ statement,
HERE_ARE_THE_PROBLEMS will have the last
word on variable and signal assignments.

Synthesizing logic using both clock
edges is not useful to me, but I
have played with a simple HERE_ARE_THE_PROBLEMS;
procedure consisting of a simple assignment.

my_reg_v <= my_port_pin;

This sims and synthesizes fine as a wire
to a port or architecture signal for
Mentor and Quartus tools.

This is not a recommendation.
Such assignments more properly belong
in the /elsif rising_edge(clk) clause.
But it is interesting because the
my_reg_v reset behavior is automatically
duplicated to the port without requiring
a separate assignment or generating
a duplicate register.


-- Mike Treseler

 

[Mike Treseler]

Mike Treseler wrote:

my_reg_v <= my_port_pin;

but he meant:

my_port_pin <= my_reg_v;



-- Mike Treseler

 

[aaaaaa]

case 1 : "00000000" is an assignment to a 8 bit signal . In this type of
assignment you have to assign all the bits.
Case 2 : In this type of assignment all the bits of signal will be
assigned '0' .
case 3 : this type of assignment is used in two dimentional array
assignments .

I think it is helpful.

 

[Symon]

Hi André,
I'd probably do it like this.
Have a 7 bit counter that counts modulo 125 on your 125MHz clock. Call it
'counter'. If you get a transition on the data (which you've already sampled
into the 125MHz clock domain, right?), reset it to 0. When the counter says
4 | 12 | 19 | 27 | 35 | 43 | 51 | 58 | 66 | 74| 82 | 90 | 97 | 105 | 113 |
121 sample the data. (I'd check those numbers for yourself, my arithmetic
isn't what it used to be..) Of course with half the bits there will be a
transition so you'll only be sampling at big counts if you get a lot of
consecutive equal bits. Remember if the count gets to 124 the next count
should be 0, i.e. modulo 125.
Have fun, Syms.

"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0504180203.226a3d5b@posting.google.com...

Hi newsgroup,

maybe someone of you out there has faced some similar problem:

I want to sample 16MHz data with a 125MHz clock.

But 125/16 = 7.8125

Is there some tricky method to perform this kind of oversampling ?

The only thing I know is the Bresenham algorithm, but could that
be the solution ?

Thank you in advance.

Rgds

 

[Symon]

Personally I probably wouldn't do this, depending on the situation. I find
that having as few clocks as possible is the best strategy for FPGAs. I use
enables instead. So, if Andre already has a 125MHz system clock in his
device that he's using, he should stick with it rather than generating a new
clock domain. If, however, the 125MHz is only used in this circuit, I guess
making it into 80MHz might work.
YMMV, Syms.
p.s. I think all my numbers in that previous post were 1 too big for a
proper sync design.
"Peter Alfke" <peter@xilinx.com> wrote in message
news:1113925710.027051.206960@f14g2000cwb.googlegroups.com...

Here is a circuit that generates 16 MHz from a 125 MHz clock:
Use a Xilinx DCM with simultaneous multiply by 16 and division by 25.
That gives you 80 MHz, which might be convenient for 5x oversampling.
Peter Alfke, Xilinx Applications