Clock Edge notation

[Pieter Hulshoff]

Eric Smith wrote:

Could we please all use the same terminology? A pulse (level) triggered
memory device is usually called a latch. An edge triggered memory device
is usually called a flip-flop.

The book I was quoting distinguishes between level-triggered (latch),
pulse-triggered (master-slave), and edge-triggered. Sorry, I don't know
what better terminology to use to describe it.

It seems I could have used a bit of reading up on my knowledge as well.
Might be a language thing too (I'm Dutch. It appears in literature a
difference is made between level sensitive (Latch), and level triggered
(AKA pulse triggered). There are indeed two different types of FFs: pulse
triggered and edge triggered.

The point was that the behavior of a master-slave FF is NOT always
the same as that of an edge-triggered FF. This is why master-slave FFs
went out of style in the late 1970s.

From what I could find, and it can also be found in the lecture Paul
Uiterlinden wrote about, it's the pulse triggered FF that has the problem
you described, and AFAIK the pulse triggered FF that went out of style.
This is also what I believe Mike Treseler said in a previous post.

That's not what they're talking about, and it's not even theoretically
possible to eliminate metastability.

True, but it's possible to create circuits that properly take signals from
one clock area to the next, despite metastability.

The 7474 does NOT have three in sequence. It has two SR flops in the
first stage, and one in the second. There's no easy way to explain it,
which is why I referenced the diagram in the TI data sheet.

I just had a look at the datasheet (my apologies for not doing so before
posting). From what I can tell that device contains 2 FFs, each edge
triggered, and each having an asynchronous set and reset. The asynchronous
set/reset is why they need 3 latches i.s.o. 2.

Regards,

Pieter Hulshoff

 

[Ken Smith]

In article <qhpt3rtojs.fsf@ruckus.brouhaha.com>,
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:
[...]

device. Why are we not content with this design? Because the
master flip-flop is still a 1's catcher during the positive half
of the clock cycle. This means that R and S must stabilize during
the negative half of the clock, since the master flip-flop will
react to any T glitches during the positive clock phase.

They are either (a) speaking of a different cicruit than the common
master-slave flip-flip or (b) wrong.

If you want to see a schematic that is easier to understand, look at the
CD4013's data sheet. It is much less tricky in how things are done.

The master section of the master-slave circuit followes its input when the
clock is low. Its output drives the input of the slave section. The
slave section follows its input when the clock is high. Whatever state
the master section is in, will appear at the output just after the rising
edge of the clock and remain there until the next rising edge of the
clock.

Unfortunately the authors do not explain the construction of such
a device, though the 7474 and 74109 are real-world examples of it.

Take a very careful look at the 7474's schematic. You will discover that
it is just a funny sort of master-slave design.

Metastability is not explained until Chapter 12.

The 7474 is a slightly tricky master-slave circuit.

The 7474 is not a master-slave flip-flop. It actually contains three
S-R flip-flops in a non-obvious configuration, very much unlike what
Paul Uiterlinden described.

I'm looking at the transistor level schematic of the 7474. There are two
and only 2 flip-flops in the transistor level schematic. Its in the data
sheet. Take a look. There are a cross coupled pair near the bottom of
the page forming the master and a more complex slave above it.

If you look at the "logic diagram" you will see that the uppermost
flip-flip takes the PRE/ and CLR/ as inputs. In the transistor schematic
that part is replaced by some simple stearing logic that does not involve
feedback.

--
--
kensmith@rahul.net forging knowledge

 

[rickman]

Laurent Gauch wrote:

Paul Uiterlinden wrote:
Raghavendra wrote:

Hi all,
Flip flop differs from a latch because of edge detection
circuit.How edge detection circuit is implemented.


By two latches in succesion, the first has an active low enable
(transparant while its enable is low), the second active high. These two
latches form a so called master-slave pair.

Google is your friend. See e.g.
http://bwrc.eecs.berkeley.edu/Classes/ICDesign/EE141_f03/Lectures/Lecture24-Sequential.pdf


Paul.
One Flip-flop is enough if your input signal is synchronous with the clock.

You are on a different topic.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Narendran Kumaraguru Nath]

S.Muralidharan wrote:

hi all,
does any one have the source code of REED SOLOMON DCODER.If so
plz rply to smuralidharan@gmail.com

wishes from
S.Muralidharan

simple googling doesn't look like you'll get it free.. The links I found
are ...

http://www.4i2i.com/reed_solomon_codes.htm
http://www.lateralsands.com/site/pdfs/LS_Reed_Solomon_Decoder_v23.pdf

Hi looks like you are a student. Why don't you start a opencores project?


Narendran Kumaraguru Nathan
TooMuch Semiconductor Solutions Pvt. Ltd.
www.toomuchsemi.com
A Bangalore based startup specialising on services in EDA & Verification.

 

[Paul Uiterlinden]

cristian wrote:

I have done the following declaration as part of my state machine
code:

type states is (b_busy,backoff,base_address,card_present,timer_dat,timer_read,timer_write);
attribute syn_enum_encoding: string;
attribute syn_enum_encoding of states : type is "000 001 011 111 110
101 100";
SIGNAL state, nxt_state : states;

For different reasons I do need to be able to 'read' the value of the
state variables of my enumerated type to do something like this:

oe_rst <= sv(1) and not sv(2) and not sv(3);

int_req <= ((not r_cmd(3) and not r_cmd(2) and r_cmd(1) and sv(1) and
not sv(2) and sv(3)) or (sv(1) and not sv(2) and not sv(3));

start_timer <= ((sv(1) and not sv(2) and not sv(3)) or (sv(1) and not
sv(2) and sv(3)));

where 'sv' is the state variable of the enumerated type defined in the
respective VHDL statement.

I do know that this is not the best way of doing output assignments in
an State Machine. But, I need to follow some directions.

So, in concrete, is there any way to use the value of the state
variables of a declared enumerated type ?

I still do not understand why you must do it this way, but if you insist
you should declare sv a std_logic_vector and create constants (of type
std_logic_vector) for the state values. Use these constants in your FSM
code and use the the bits of sv (as above) in the decoding.

Paul.

 

[Egbert Molenkamp]

Before you can simulate you have to constrain the unconstrained arrays.
In your entity TEST you have three unconstrained arrays that are not
unconstrained if this entity is the top level:

arg: in array_fp32 ;
nn: in array_integer;
resultut array_fp32

You could add a generic part to constrain these I/Os, something like:

entity test is
generic (lgt_int : integer:=4; lgt_fp32 : integer := 5);
port (arg: in array_fp32(lgt_fp32-1 downto 0) ;
nn: in array_integer(lgt_int-1 downto 0);
resultut array_fp32(lgt_fp32-1 downto 0);
.....

If this entity is used in another design you simply can add a "generic map"
where is entity is instantiated to change the generic values in the entity.

Egbert Molenkamp

"cltsaig" <cltsaig@tsmc.com> wrote in message
news:88a94685d2a0241529213b85d91e427c@localhost.talkaboutprogramming.com...

Hi all,

Can someone help me out to overwhelm this problem? The error message "arg
port is not constrained" was occured during the starting of simulation
when I assigned a test waveform.
Technically, Alan (www.doulos.com) had suggested me to implement this
function by using a procedure rather than declared as an entity, this will
get away of this problem. However, I don't know to write a procedure with
clock input. May someone provide me some suggestion to solve this problem
please? Thanks for reading this post!!!


Sincerely,
Stanley

------------------------- my VHDL code here -------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.fphdl_base_pkg.all;
use work.fphdl32_pkg.all;


-- type array_fp32 is array (natural range <&gt of fp32;
-- type array_integer is array (natural range <&gt of integer;

entity TEST is
port(
arg: in array_fp32 ;
nn: in array_integer;
ndim: in integer;
isign: in integer;
clk:in std_logic;
rst:in std_logic;
resultut array_fp32
);
end TEST;


architecture computation of TEST is


subtype size_array_fp32 is array_fp32(1 to 10);
signal temp_in: size_array_fp32;


begin

feed_arg: process (clk, rst) is
begin
if rst = '0' then
elsif rising_edge(clk) then
temp_in<=arg;
end if;
end process feed_arg;
-------------------------------------

-- process to evaluate ntot, nprev
MAIN: process (clk, rst) is
variable ntot, nprev, n, nrem: integer;
variable i1, i2, i3, ip1, ip2, ip3, i2rev, i3rev: integer;
variable temp_a, temp_b: fp32;

------- Procedure -----------
-- #define SWAP(a,b) tempr=(a);(a)=(b);(b)=tempr
procedure SWAP(
a:inout fp32;
b:inout fp32
) is
variable tempr:fp32;
begin
tempr:=a;
a:=b;
b:=tempr;
end SWAP;


begin
if rst='0' then

elsif rising_edge(clk) then

for idim in 1 to ndim loop
ntot := ntot * nn(idim);
nprev:=1;
for idim in ndim downto 1 loop
n:=nn(idim);
nrem:=ntot/(n*nprev);
ip1:=to_integer(to_unsigned(nprev,32) sll 1);
ip2:=ip1*n;
ip3:=ip2*nrem;
i2rev:=1;
i2:=1;
while i2 < ip2 loop
if i2<i2rev then
i1:=i2;
while i1 <= i2+ip1-2 loop
i3:=i1;
while i3 <= ip3 loop
i3rev:=i2rev+i3-i2;
-- SWAP(data[i3],data[i3rev]);
--temp_a:=arg(i3);
--temp_b:=arg(i3rev);
-- SWAP(temp_in(i3),temp_in(i3rev));
-- SWAP(data[i3+1],data[i3rev+1]);
i3:=i3+ip2;
end loop;
i1:=i1+2;
end loop;
end if;
i2:=i2+ip1;
end loop;
end loop;
end loop;
end if;
end process MAIN;
end architecture;
------------------------- my VHDL code end ---------------


------------------------- C code ---------------------------
#define SWAP(a,b) tempr=(a);(a)=(b);(b)=tempr
void test(float data[], unsigned long nn[], int ndim)
{
int idim;
unsigned long i1,i2,i3,i2rev,i3rev,ip1,ip2,ip3;
unsigned long k1,k2,n,nprev,nrem,ntot;

for (ntot=1,idim=1;idim<=ndim;idim++)
ntot *= nn[idim];
nprev=1;
for (idim=ndim;idim>=1;idim--) {
n=nn[idim];
nrem=ntot/(n*nprev);
ip1=nprev << 1;
ip2=ip1*n;
ip3=ip2*nrem;
i2rev=1;
for (i2=1;i2<=ip2;i2+=ip1) {
if (i2 < i2rev) {
for (i1=i2;i1<=i2+ip1-2;i1+=2) {
for (i3=i1;i3<=ip3;i3+=ip2) {
i3rev=i2rev+i3-i2;
SWAP(data[i3],data[i3rev]);
SWAP(data[i3+1],data[i3rev+1]);
}
}
}
}
}
}
------------------------ C code end ------------------------

 

[cltsaig]

Hi Egbert,

Thanks for your feedback, I'll adopt your approach and update you the
result sooner!

Stanley

 

[Ralf Hildebrandt]

Nicolas Matringe wrote:

I have come up with this, which looks like a dual-edge FF but with some
limitations:

Hmmm ... 3 flipflops for dual-edge behavior?
What about

--------------------------------
signal reset,clk,D,ff_rise,ff_fall,de_dff : std_ulogic;

process(reset,clk)
begin
if (reset='1') then
ff_rise<='0';
elsif rising_edge(clk) then
ff_rise<=ff_fall XOR D;
end if;
end process;

process(reset,clk)
begin
if (reset='1') then
ff_fall<='0';
elsif falling_edge(clk) then
ff_fall<=ff_rise XOR D;
end if;
end process;

de_dff<=ff_rise XOR ff_fall;
--------------------------------

I call this thing a "pseudo dual-edge D-flipflop" (de_dff).
In real life one will not use plain D-flipflop behavior, but something like

process(reset,clk)
begin
if (reset='1') then
ff_rise<='0';
elsif rising_edge(clk) then
if (ff_fall='1' AND state=some_state AND some_signal='1') then
ff_rise<=some_other_signal;
else -- and so on...
end if;
end if;
end process;


I used this pseudo dual-edge flipflop for generating a manchester coded
output signal (everytime a transition at the begin of a bit and
additionally a transition in the middle of the bit, if a '0' is
transferred). It was very helpful for a low-power solution.

Ralf

 

[rickman]

VHDL User wrote:

Hi All,
I have a basic doubt. When a signal transitions on a clock edge, and I
want to use the final value of this signal for computation on the same
clock edge (and drive some other signal on the same edge) HOW do I do it ?
Simulation takes the previous value of the signal as the transition is
scheduled ater the simulation delta. I also fear a race condition like
situation.
This is my code :

Ap : process(Clk)
begin
if (posedge(Clk))
A<='1';
end if;
end process Ap;
Bp : process(Clk)
begin
if (posedge(Clk) and A='1')
B<='1';
end if;
end process Bp;

A is global signal, so access by Bp is not a issue.When Ap and Bp get
executed simultaneously, on the +ve edge, an event is scheduled on A after
Simulation delta.This would mean the B signal would be asserted only on
next edge,as A is "seen" as old value,which may not be 1. So,how do I make
B also transit before the next edge ?
One way could be to sample A after some time,say after 1/10 th of period
or something like that. But that is arbitrary? A and B are output signals.
Would using variables in the process and converting back later help to
avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
synthesis of this code lead to a potential race condition ?

I am a little fuzzy on things sometimes, but I am pretty sure that this
is not a problem due to a thing called delta time. The clock edge
transition triggers each of the two processes in an arbitrary order.
But the output transitions (A and B) are queued to occur not immediately
in the simulator, but after 1 delta time (which is not mapped to real
time but occurs in zero real ns). So the Bp process will read the same
value of A (the older one) regardless whether it runs before or after
process Ap.

Once all the events scheduled for zero delta time are run, then the
processes that were scheduled for 1 delta time are run and so on until
no more delta time events are queued and the simulator then looks at the
next real time event.

BTW, A does not need to be a global signal to be visible by process Bp
(I'm not sure there *are* global signals vs. global variables). They
just need to be in the same entity or you can pass A around in a port
declaration.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[VHDL User]

On Wed, 13 Oct 2004, rickman wrote:

VHDL User wrote:

Hi All,
I have a basic doubt. When a signal transitions on a clock edge, and I
want to use the final value of this signal for computation on the same
clock edge (and drive some other signal on the same edge) HOW do I do it ?
Simulation takes the previous value of the signal as the transition is
scheduled ater the simulation delta. I also fear a race condition like
situation.
This is my code :

Ap : process(Clk)
begin
if (posedge(Clk))
A<='1';
end if;
end process Ap;
Bp : process(Clk)
begin
if (posedge(Clk) and A='1')
B<='1';
end if;
end process Bp;

A is global signal, so access by Bp is not a issue.When Ap and Bp get
executed simultaneously, on the +ve edge, an event is scheduled on A after
Simulation delta.This would mean the B signal would be asserted only on
next edge,as A is "seen" as old value,which may not be 1. So,how do I make
B also transit before the next edge ?
One way could be to sample A after some time,say after 1/10 th of period
or something like that. But that is arbitrary? A and B are output signals.
Would using variables in the process and converting back later help to
avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
synthesis of this code lead to a potential race condition ?

I am a little fuzzy on things sometimes, but I am pretty sure that this
is not a problem due to a thing called delta time. The clock edge
transition triggers each of the two processes in an arbitrary order.
But the output transitions (A and B) are queued to occur not immediately
in the simulator, but after 1 delta time (which is not mapped to real
time but occurs in zero real ns). So the Bp process will read the same
value of A (the older one) regardless whether it runs before or after
process Ap.

Once all the events scheduled for zero delta time are run, then the
processes that were scheduled for 1 delta time are run and so on until
no more delta time events are queued and the simulator then looks at the
next real time event.

Precisely. I have mentioned in my post that due to simulation
delta cycle,A will be updated only 1 delta delay later,and hence B will
always read the old value of A.My problem is how to change B based on new
value of A before next positive edge.
My fear of a race condition was only for the hardware.In
simulation, delta delays ensure that no race conditions arise,but (as you
yourself pointed out ) in real time, the two signals get updated in "zero"
time.
My problem still remains.How do I update B once A has been
updated, before the next positive edge.

BTW, A does not need to be a global signal to be visible by process Bp
(I'm not sure there *are* global signals vs. global variables). They
just need to be in the same entity or you can pass A around in a port
declaration.
Sure.I agree completely.By "global" I meant signal in same

entity. Sorry for the needless confusion.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Paul Uiterlinden]

VHDL User wrote:

Ap : process(Clk)
begin
if (posedge(Clk))
A<='1';
end if;
end process Ap;
Bp : process(Clk)
begin
if (posedge(Clk) and A='1')
B<='1';
end if;
end process Bp;

[snip]
My problem still remains.How do I update B once A has been updated,
before the next positive edge.

Solution: put the stuff in one process, make A a variable.

Think in hardware. What you wrote down originally are two flip-flops (Ap
and Bp). You want to clock in the updated value of Ap into Bp. That does
not make sense. If it does, Ap should not have been a flip-flop in the
first place.

Paul.

 

[rickman]

VHDL User wrote:

Precisely. I have mentioned in my post that due to simulation
delta cycle,A will be updated only 1 delta delay later,and hence B will
always read the old value of A.My problem is how to change B based on new
value of A before next positive edge.

You can't since the Bp FF is edge triggered and won't sample the other
inputs until the next clock edge. If you want B to be updated anytime A
changes, you should remove the clock reference.

My fear of a race condition was only for the hardware.In
simulation, delta delays ensure that no race conditions arise,but (as you
yourself pointed out ) in real time, the two signals get updated in "zero"
time.

There will be no race condition in the hardware. Hardware always has
delays. The only problem would be if the clock routing delay is more
than the signal delay. In FPGAs the manufacturer assures this will not
happen. In ASICs it is up to you.

My problem still remains.How do I update B once A has been
updated, before the next positive edge.

Now I don't understand what you are trying to do. Your code describes
two FFs, one a simple clocked FF which starts in some unknown state and
transitions to a '1' on the first clock edge remaining there forever.
The second FF does nothing until the Ap FF becomes a '1' and then does
the same on the next clock edge (not the same one).

What are you trying to do?


--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Element Blue]

On Wed, 13 Oct 2004, rickman wrote:

VHDL User wrote:

Precisely. I have mentioned in my post that due to simulation
delta cycle,A will be updated only 1 delta delay later,and hence B will
always read the old value of A.My problem is how to change B based on new
value of A before next positive edge.

You can't since the Bp FF is edge triggered and won't sample the other
inputs until the next clock edge. If you want B to be updated anytime A
changes, you should remove the clock reference.


My fear of a race condition was only for the hardware.In
simulation, delta delays ensure that no race conditions arise,but (as you
yourself pointed out ) in real time, the two signals get updated in "zero"
time.

There will be no race condition in the hardware. Hardware always has
delays. The only problem would be if the clock routing delay is more
than the signal delay. In FPGAs the manufacturer assures this will not
happen. In ASICs it is up to you.


My problem still remains.How do I update B once A has been
updated, before the next positive edge.

Now I don't understand what you are trying to do. Your code describes
two FFs, one a simple clocked FF which starts in some unknown state and
transitions to a '1' on the first clock edge remaining there forever.
The second FF does nothing until the Ap FF becomes a '1' and then does
the same on the next clock edge (not the same one).

What are you trying to do?

Ok.What I had presented was "representative" code of my actual
code, only to highlight the problem. Certainy the FFs dont stay there
forever. My only concern was the clock edge where both signals are
supposed to change. What I am trying to do is to ensure B changes before
the next clock edge.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

Element Blue wrote:

Ok.What I had presented was "representative" code of my actual
code, only to highlight the problem. Certainy the FFs dont stay there
forever. My only concern was the clock edge where both signals are
supposed to change. What I am trying to do is to ensure B changes before
the next clock edge.

Then Bp should not be a clocked process. By definition a clocked
process only changes on the clock edge.

My question is not about your sample code, but I don't understand what
you are trying to do with these two signals. If you want B to change
immediately on A changing, why do you put it in a clocked process? I
think I am missing something.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[David R Brooks]

How about defining a function which accepts a state variable and a
bit-index as arguments, and returns the selected bit?
ie
function myfunc(signal sv : states; index : natural)
return std_logic is
variable x : std_logic_vector(2 downto 0);
begin
case sv of
b_busy => x <= "000";
... etc
default => x <= "XXX"; -- broken!
end case;
return x(index);
end myfunc;

You would probably want to add asserts on the range of "index", etc.,
but you get the idea.
Now you can write
oe_rst <= myfunc(sv,1) and not myfunc(sv,2) ...

rickman <spamgoeshere4@yahoo.com> wrote:

:cristian wrote:
:>
:> I have done the following declaration as part of my state machine
:> code:
:>
:> type states is (b_busy,backoff,base_address,card_present,timer_dat,timer_read,timer_write);
:> attribute syn_enum_encoding: string;
:> attribute syn_enum_encoding of states : type is "000 001 011 111 110
:> 101 100";
:> SIGNAL state, nxt_state : states;
:>
:> For different reasons I do need to be able to 'read' the value of the
:> state variables of my enumerated type to do something like this:
:>
:> oe_rst <= sv(1) and not sv(2) and not sv(3);
:>
:> int_req <= ((not r_cmd(3) and not r_cmd(2) and r_cmd(1) and sv(1) and
:> not sv(2) and sv(3)) or (sv(1) and not sv(2) and not sv(3));
:>
:> start_timer <= ((sv(1) and not sv(2) and not sv(3)) or (sv(1) and not
:> sv(2) and sv(3)));
:>
:> where 'sv' is the state variable of the enumerated type defined in the
:> respective VHDL statement.
:>
:> I do know that this is not the best way of doing output assignments in
:> an State Machine. But, I need to follow some directions.
:>
:> So, in concrete, is there any way to use the value of the state
:> variables of a declared enumerated type ?
:
:It sounds like you are trying to optimize the coding of your state
:machine so that a given output potentially does not depend on all of the
:state variable bits. If that is not the case, then I don't think you
:will find this added complexity will add much to your design. I guess
:your hard coding of the output functions might save a bit of logic, but
:typically the optimizer will be pretty good.
:
:If you were one-hot encoding, then you might get the best results by
:hand decoding the states.
:
:One way to get the state variable bits is to define an slv that maps to
:the states of the machine using a case statement in a non-clocked
rocess...
:
rocess (state) begin
: case (state) of
: b_busy => slv_state <= "000";
: backoff => slv_state <= "001";
: .
: .
: .
: end case;
:end process;
:
:I don't bother to remember details of syntax so I don't know that it is
:correct for the above code, but you get the idea.

 

[Ken Smith]

In article <Pine.LNX.4.61.0410131957590.4319@phenix.rootshell.be>,
Element Blue <supreet@wrongdomain.com> wrote:
[...]

Ok.What I had presented was "representative" code of my actual
code, only to highlight the problem. Certainy the FFs dont stay there
forever. My only concern was the clock edge where both signals are
supposed to change. What I am trying to do is to ensure B changes before
the next clock edge.

Can't you code "B" as combinatorial logic?

--
--
kensmith@rahul.net forging knowledge

 

[rickman]

Element Blue wrote:

On Wed, 13 Oct 2004, rickman wrote:

My question is not about your sample code, but I don't understand what
you are trying to do with these two signals. If you want B to change
immediately on A changing, why do you put it in a clocked process? I
think I am missing something.
Ok.I ll explain the context. There is a memory block which asserts
signal A (Ready) on a clock edge. The reader block must assert the B
(Upload) signal before the next clock edge,as that is when data appears on
the data bus if Upload is high.Otherwise I incur a clock cycle delay.
The read takes 2 cycles (2 words) and as soon as second word is read,
Upload is to be deasserted irresepective of whether memory is ready for
the next read or not ( irresp. of A),ie.,only 2 word accesses at a time.
As you and Ken have pointed out, making Bp a non clocked process
definitely helped. Thanks.

This is an example where thinking not in the HDL, but in terms of
hardware would have made your solution very obvious. What you are
describing is a clocked signal, A, from the memory that must be gated
(anded) with an enable, another clocked signal. You were trying to
include the AND in the clocked signal while it should be a combinatorial
function that combines the two clocked signals.

I always think in terms of block level (sort of like RTL diagrams) logic
and then write HDL to describe my digital blocks. I have seen some
really bad code when people try to write HDL like it was software.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Mike Treseler]

rickman wrote:

This is an example where thinking not in the HDL, but in terms of
hardware would have made your solution very obvious. What you are
describing is a clocked signal, A, from the memory that must be gated
(anded) with an enable, another clocked signal. You were trying to
include the AND in the clocked signal while it should be a combinatorial
function that combines the two clocked signals.

I always think in terms of block level (sort of like RTL diagrams) logic
and then write HDL to describe my digital blocks. I have seen some
really bad code when people try to write HDL like it was software.

Yes, sometimes it is better to start with schematic entry.
On the other hand, I have seen some really good code
where the designer understands hardware and the
HDL and the synchronous templates and data structures
and algorithmic design.

-- Mike Treseler

 

[Ken Smith]

In article <Pine.LNX.4.61.0410121859440.6817@phenix.rootshell.be>,
VHDL User <supreet@wrongdomain.com> wrote:

Hi All,
I have a basic doubt. When a signal transitions on a clock edge, and I
want to use the final value of this signal for computation on the same
clock edge (and drive some other signal on the same edge) HOW do I do it ?
Simulation takes the previous value of the signal as the transition is
scheduled ater the simulation delta. I also fear a race condition like
situation.
This is my code :

Ap : process(Clk)
begin
if (posedge(Clk))
A<='1';
end if;
end process Ap;
Bp : process(Clk)
begin
if (posedge(Clk) and A='1')
B<='1';
end if;
end process Bp;

[...]
avoid the delta delay? Or adding a wait for 0ns statement ? Wouldnt
synthesis of this code lead to a potential race condition ?

I'll take on only what happens in a real part.

Inside a real part, the "A" and "B" signals will only take on their new
values some short time after the edge of "Clk". In most parts the new
value is actually based on the value on the input to the flip-flop just
before the edge. This means that "B" will become "1" one clock cycle
after "A" does in almost all cases.

In real parts there can be a problem with clock skew where one part of the
chip see the edge before another. Chip designers go to great lengths to
reduce clock skew but you should not ignore the question when working with
large parts.


--
--
kensmith@rahul.net forging knowledge

 

[rickman]

cristian wrote:

I have done the following declaration as part of my state machine
code:

type states is (b_busy,backoff,base_address,card_present,timer_dat,timer_read,timer_write);
attribute syn_enum_encoding: string;
attribute syn_enum_encoding of states : type is "000 001 011 111 110
101 100";
SIGNAL state, nxt_state : states;

For different reasons I do need to be able to 'read' the value of the
state variables of my enumerated type to do something like this:

oe_rst <= sv(1) and not sv(2) and not sv(3);

int_req <= ((not r_cmd(3) and not r_cmd(2) and r_cmd(1) and sv(1) and
not sv(2) and sv(3)) or (sv(1) and not sv(2) and not sv(3));

start_timer <= ((sv(1) and not sv(2) and not sv(3)) or (sv(1) and not
sv(2) and sv(3)));

where 'sv' is the state variable of the enumerated type defined in the
respective VHDL statement.

I do know that this is not the best way of doing output assignments in
an State Machine. But, I need to follow some directions.

So, in concrete, is there any way to use the value of the state
variables of a declared enumerated type ?

It sounds like you are trying to optimize the coding of your state
machine so that a given output potentially does not depend on all of the
state variable bits. If that is not the case, then I don't think you
will find this added complexity will add much to your design. I guess
your hard coding of the output functions might save a bit of logic, but
typically the optimizer will be pretty good.

If you were one-hot encoding, then you might get the best results by
hand decoding the states.

One way to get the state variable bits is to define an slv that maps to
the states of the machine using a case statement in a non-clocked
process...

process (state) begin
case (state) of
b_busy => slv_state <= "000";
backoff => slv_state <= "001";
.
.
.
end case;
end process;

I don't bother to remember details of syntax so I don't know that it is
correct for the above code, but you get the idea.


--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX