Clock Edge notation

[Uncle Noah]

Mark McDougall wrote:
Actually, I think it's pretty obvious this guy didn't even write the
code in question.
Why steal code you don't know works?

Agree with you. It looks like this code is taken from some other
student (alumni in his institution?) He probably can't get in touch
with him/her, and want us to get his job done.

Uncle Noah

 

[Marcus Harnisch]

ariesxyg@yahoo.com.cn writes:

" wait for 100000ns; "
but it give me error like,
" unsupported feature error: condition clause and timeout clause
together in a wait statment is not support "

[...]

PROCESS(clk)

BEGIN
if hold = '0' then
wait for 100000 ns;
if (clk'event and clk='0') then
if data0 = '0' then uid <= '0';
elsif data1 = '0' then uid <= '1';
end if;
end if;
end if;
end process;

You cannot have a wait statement in a process with sensitivity list.

-- Marcus

 

[Dave Pollum]

ariesxyg@yahoo.com.cn wrote:

hi all:
i have been trapped for a VHDL problem.
it look like very simple, but i really can't fix it. please give me a
hand.
the problem is: i want a process wait a constant period about 100000ns.
i write
" wait for 100000ns; "
but it give me error like,
" unsupported feature error: condition clause and timeout clause
together in a wait statment is not support "

my whole code is:

LIBRARY ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;

ENTITY decode1 IS
PORT(
clk, hold, data0, data1 : in std_logic;
UID : OUT STD_LOGIC;
BIT0_STATE : OUT STD_LOGIC;
BIT25_STATE : OUT STD_LOGIC);
END decode1;

ARCHITECTURE a OF decode1 IS

BEGIN

PROCESS(clk)
BEGIN
if hold = '0' then
if (clk'event and clk='0') then
if data0 = '0' then BIT0_STATE <= '0';
elsif data1 = '0' then BIT0_STATE <= '1';
end if;
end if;
end if;
end process;

PROCESS(clk)

BEGIN
if hold = '0' then
wait for 100000 ns;
if (clk'event and clk='0') then
if data0 = '0' then uid <= '0';
elsif data1 = '0' then uid <= '1';
end if;
end if;
end if;
end process;

PROCESS(clk)

BEGIN
if hold = '0' then
wait for 8400000 ns;
if (clk'event and clk='0') then
if data0 = '0' then BIT25_STATE <= '0';
elsif data1 = '0' then BIT25_STATE <= '1';
end if;
end if;
end if;
end process;
END a;

"i want a process to wait a constant period about 100000ns"
While "WAIT FOR some_time_period" will work for simulation, it will
not be synthesized into hardware. You will need a clock and a counter.
HTH
-Dave Pollum

 

[njsldz@163.com]

Website: http://www.njpcb.com

 

[Mike Treseler]

Davy wrote:

I am new to hierarchical FSM design.
Is there any paper or guideline for design hierarchical FSM?
Any suggestions will be appreciated!

I would suggest that if your state machine
needs a hierarchy, there is likely a simpler
logic description possible, using multiple
process variables, not all of them enumerated.

-- Mike Treseler

 

[radarman]

Mike Treseler wrote:

Davy wrote:

I am new to hierarchical FSM design.
Is there any paper or guideline for design hierarchical FSM?
Any suggestions will be appreciated!

I would suggest that if your state machine
needs a hierarchy, there is likely a simpler
logic description possible, using multiple
process variables, not all of them enumerated.

-- Mike Treseler

It depends on the nature of the state machine (SM). Sometimes it is
helpful to take advantage of the inherent parallelism available in a
FPGAs and ASICs by having multiple state machines operating at once
while a "master" SM coordinates their activities. However, this
typically implies only two levels of hierarchy (the master machine, and
the servant machines)

That said, there are few circumstances that call for true hierarchy in
state machine design, and I would recommend also that you reexamine the
problem. Often, a problem can be more easily solved with an external
(to the SM) counter, pipeline register, or signal than by adding
additional states.

As a hint, try to limit the number of outputs each SM generates. This
will force you to partition the problem better, and should result in a
cleaner design. For example, rather than implement a full
microprocessor for a test application, I wrote two state machines that
were attached to an internal UART model. One state machine handled
incoming data, while the other acted as a message generator. By
partitioning in this way, each machine became much simpler, and
performance improved greatly.

Note, there are some graphical tools on the market (Mentor Graphics'
HDL Designer, and Xilinx' StateCAD) that allow you to implement
hierarchical state machines graphically - allowing them to be
understood more easily. However, if you examine the output, you will
find that the SM has almost invariably been flattened to just one (in
either two or three processes depending on what you specified in the
options)

 

[KJ]

I want to increment the channel_type variable so that I point to the
next element in the FRAME. But channel_type is enumerated and I assume
increment doesn't make sense for an enumerated type.

The increment would make sense if you define simply define an increment

function for the enumerated type something like....

function increment(T: TimeslotType) return TimeslotType is
begin
if (T = EOC_CHANNEL) then <<-- Not sure of an elegant way of
picking off the 'last' enumerated type, any ideas??
return(FRAME_SYNC)
else
return(TimeslotType'succ(T));
end if;
end;

Then to increment some signal 'X' you could just say X <= increment(X);

Actually I don't quite understand why the warnings won't occur for the
enumerated type suggestion also. The hardware is using bits to
represent the different enumerated types. There will still be
combinations of bits that don't map to enumerated types. Indeed, if the
encoding is one hot there will be heaps of combinations that don't map
to valid values.

But if you used the enumerate type you would likely also use a case
statement that would then have a 'when others' case to pick up the
conditions you haven't otherwise defined. Continuing the earlier posted
case, you'd have....

case NextTimeslotType is
when FRAME_SYNC =>
--generate and send frame sync char
when SRC1 =>
--get payload from source 1 and send that
when others =>
-- Define it however you want it here, this takes care of any 'other'
states.
....

So no matter how the synthesizer implemented it (i.e. one hot, gray code,
binary, etc.) it wouldn't run across the situation where you haven't
explicitly chosen what you want as an output for every (im)possible state
encoding that may ever occur.

Like you said earlier, type 'natural' really does seem to be the natural
type to use when selecting from an array of choices as you have in your
situation. The enumerated type approach is a different route that is more
applicable in other situations.

KJ


"Andrew FPGA" <andrew.newsgroup@gmail.com> wrote in message
news:1144039422.778689.72140@u72g2000cwu.googlegroups.com...

Hi Mike,
I'm not quite getting how the enumerated type would work in my
situation.

My point is that if you have an enumeration type say channel_t
as a range that corresponds to the possible mux settings,
you could use a variable of that type as an index for your mux
instead of a natural to eliminate the warnings and the counting of
channels. And you could easily add or remove channels.

I'm actually counting through the FRAME array to pick out the next
channels type. I'm not actually counting through channels.

So are you suggesting something like
type channel_type_t is (CH_TYPE1, CH_TYPE2, CH_TYPE3....); -- mux
select
variable channel_type is channel_type_t;

Then when I'm actually sending the frame one timeslot at a time I go
NextTimeslotType := FRAME(channel_type);
--now how to increment channel_type ??
case NextTimeslotType is
when FRAME_SYNC =
--generate and send frame sync char
when SRC1 =
--get payload from source 1 and send that
...

I want to increment the channel_type variable so that I point to the
next element in the FRAME. But channel_type is enumerated and I assume
increment doesn't make sense for an enumerated type.

You could loop the channels like this:
for index in channel_t loop
-- do something
end loop;

So, in a single clock tick this would go through all the items in the
enumerated type. But, I only want to one channels worth of data to be
generated - don't want to generate the whole frames data in one clock
tick.....

Certainly, the easiest solution is to just ignore the warning.
Not looking for an easy solution, trying to figure out something thats
elegant.

Actually I don't quite understand why the warnings won't occur for the
enumerated type suggestion also. The hardware is using bits to
represent the different enumerated types. There will still be
combinations of bits that don't map to enumerated types. Indeed, if the
encoding is one hot there will be heaps of combinations that don't map
to valid values.

Regards
Andrew

 

[Symon]

Amal,
I guess your Google access is broken? ;-)
http://www.synplicity.com/literature/pdf/inferring_blockRAMs.pdf
Cheers, Syms.

"Amal" <akhailtash@gmail.com> wrote in message
news:1144425031.848581.165630@z34g2000cwc.googlegroups.com...

Anyone has code templates for infering a dual-port, dual-clock, block
RAM (RAMB16) for Xilinix using Synplicity and VHDL?

Xilinx XST supports this using shared variable for memory and two
processes for each write port. But I can't seem to find anything for
Synplicity.

-- Amal

 

[Amal]

Google is not broken, but it's not quite what I need. A dual-clock,
dual-port block memory mapped to RAMB16 using VHDL!

 

[Symon]

D'oh, my mistake, I missed the dual-clock requirement. I know the dual clock
inference didn't work the last time I tried it, maybe 2 years ago. At least,
I mean I didn't find a solution except to instantiate the things. If you do
manage to crack it, it'd be cool if you could post your solution.
Thanks & good luck, Syms.
"Amal" <akhailtash@gmail.com> wrote in message
news:1144428173.435579.123230@g10g2000cwb.googlegroups.com...

Google is not broken, but it's not quite what I need. A dual-clock,
dual-port block memory mapped to RAMB16 using VHDL!

 

[Mike Treseler]

Amal wrote:

Google is not broken, but it's not quite what I need. A dual-clock,
dual-port block memory mapped to RAMB16 using VHDL!

A dual write port RAM template would
have to include a description of the
arbitration of simultaneous
writes to the same address. Lacking
this, there is no guarantee that
simulation and synthesis would match.

Your choices are
1. Use a vendor-specific instance or
2. Use a supported RAM template and add separate
logic to cover all the required cases.

-- Mike Treseler

 

[Amal]

Finally I could map to RAMB16 on Xilinx Virtex and Synplify using the
followig:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.math_real.all;

entity DualPortMemory is
generic (
DEPTH : positive;
WIDTH : positive
);
port (
-- port a (read/write)
clka : in std_logic;
ena : in std_logic;
wea : in std_logic;
addra : in std_logic_vector(integer(ceil(
log2(real(DEPTH))))-1 downto 0);
dia : in std_logic_vector(WIDTH-1 downto 0);
doa : out std_logic_vector(WIDTH-1 downto 0);
-- port b (read/write)
clkb : in std_logic;
enb : in std_logic;
web : in std_logic;
addrb : in std_logic_vector(integer(ceil(
log2(real(DEPTH))))-1 downto 0);
dib : in std_logic_vector(WIDTH-1 downto 0);
dob : out std_logic_vector(WIDTH-1 downto 0)
);
end entity DualPortMemory;

architecture rtl of DualPortMemory is

type MEM_TYPE is array(0 to DEPTH-1) of
std_logic_vector(WIDTH-1 downto 0);
signal memory : MEM_TYPE;

attribute syn_ramstyle : string;
attribute syn_ramstyle of memory : signal is "block_ram";
attribute syn_ramstyle of memory : signal is "no_rw_check";

begin

--------------------------------------
-- Port A (read/write)
--------------------------------------
p_Port_A: process( clka )
begin
if ( rising_edge(clka) ) then

if ( ena = '1' ) then
if ( wea = '1' ) then
memory( conv_integer(unsigned(addra)) ) <= dia;
end if;
doa <= memory( conv_integer(unsigned(addra)) );
end if;

end if;
end process p_Port_A;

--------------------------------------
-- Port B (read/write)
--------------------------------------
p_Port_B: process( clkb )
begin
if ( rising_edge(clkb) ) then

if ( enb = '1' ) then
if ( web = '1' ) then
memory( conv_integer(unsigned(addrb)) ) <= dib;
end if;
dob <= memory( conv_integer(unsigned(addrb)) );
end if;

end if;
end process p_Port_B;

end architecture rtl;

No collision check is done here.
-- Amal

 

[Mike Treseler]

Amal wrote:

Finally I could map to RAMB16 on Xilinx Virtex and Synplify

I don't have Synplify, so I can't verify this.
I like your idea of using math_real
functions for synthesis constants,
however, I am unconvinced that this a useful
simulation model since the signal _memory_
is driven by both processes.

And you may have a typo one one of these
duplicated attribute specifications:

attribute syn_ramstyle of memory : signal is "block_ram";
attribute syn_ramstyle of memory : signal is "no_rw_check";

No collision check is done here.

True, but a vhdl simulator knows nothing
about Synplify attributes declarations.

-- Mike Treseler

 

[Mike Treseler]

vicky wrote:

Is there any article, design flow etc. for inserting the clamps in
multi-voltage domians. Also, what exactly is the function of the clamps.

http://groups.google.com/groups?q=clamp+diode
Note that this has nothing to do with vhdl.

-- Mike Treseler

 

[Mike Treseler]

Andrew FPGA wrote:

# ** Note: Warning: BusWrite() detected invalid bus state prior to
writing to the bus"
# Time: 508552 ns Iteration: 0 Instance:
/pcmrxinterfacetxframerhornettb

The problem is, I make calls to BusWrite() in lots of places in my
testbench. How can I figure out which one of those calls was the one
that caused the message to be printed?

Only by the time.
Bring up the waves and put a cursor on it.

Are there any modelsim hooks that would allow my testbench code to
figure out the call stack and/or where in the source the procedure got
called from.

You could set a breakpoint in the source.

-- Mike Treseler

 

Why not pass an additional parameter to BusWrite() that identifies the
caller

eg if you have 4 drivers, pass D1..D4 as a parameter with the call and
include this in any messages output.

ie.
# ** Note: Warning: D1 - BusWrite() detected invalid bus state prior to

writing to the bus"

- Norm

 

[Bill Mills]

nemgreen@yahoo.co.uk wrote:

Why not pass an additional parameter to BusWrite() that identifies the
caller

eg if you have 4 drivers, pass D1..D4 as a parameter with the call and
include this in any messages output.

ie.
# ** Note: Warning: D1 - BusWrite() detected invalid bus state prior to

writing to the bus"

- Norm

A variation of this is to add a parameter to return the status of the
BusWrite procedure, and let the caller handle it.

 

[Andrew FPGA]

Mike Treseler wrote:

You could set a breakpoint in the source.

Embarrassed to admit I hadn't thought of that. Works well in this case,

I break and then step through until the procedure returns.

But I can imagine for more complicated testbenches, it won't be so easy
to step out quickly. I'm trying to move away from the modelsim gui and
be more automated about my testing. Say I run the testbench in batch
mode overnight and the assert happens near the end of the run...

 

[Andrew FPGA]

Ok, but the downside is I need to remember to pass in unique
identifiers each time I make the call.

 

[Mike Treseler]

Andrew FPGA wrote:

But I can imagine for more complicated testbenches, it won't be so easy
to step out quickly. I'm trying to move away from the modelsim gui and
be more automated about my testing. Say I run the testbench in batch
mode overnight and the assert happens near the end of the run...

There are two phases to simulation:
debugging errors and regressing changes.

The GUI is useful for ad hoc debugging phase.
I want as much information as possible
to find the errors. But one they are
found and fixed, this effort is reduced to
comments in the code.

Once everything is working and meets timing
I need to close the loop on the testbench.
Here, I run a simulation to quickly verify that my small
change has not broken any major function that was
working before. I want to verify all the critical
expected values and see either
a PASS at the end or a break at the first
failure.

Have a look at my reference testbench for
an example.

-- Mike Treseler