I hate VHDL!!!

[Niv]

when I did my timing simulation, I got the warning message:
# ** Warning: /X_FF SETUP Low VIOLATION ON I WITH RESPECT TO CLK;
# Expected := 0.67 ns; Observed := 0.258 ns; At : 1.9 ns

Can someone tell me more about the X_FF component from the simprim
library? Or is there any link for the explanation. I failed to find
out any in the past 60 minutes. Thanks for your help.

This looks like a setup & hold type violation.

Is the signal into the flip-flop asynchronous to its clock? most likely.
So pass the signal thru several stages of FFs to reduce meta stability.
You'll still get the above message though. The massage can be turned off
but it's probably better to leave it on & check that each one really is a
meta stability issue.

(Unless of course you have an incredibly fast clock, like GHz range).

Anyway, that's what I think, others are wlecome to correct me or re-enforce!

 

[Mike Treseler]

Gunit wrote:

When I synthesise the state machine, I get a warning
"'flag' is not always assigned. Storage may be needed.."
Am I avoiding generating a latch if I am certain that the flag will be
cleared in a subsequent state, or is this bad practice in general??

post your code.
consider simulation before synthesis.
http://groups.google.com/groups?q=state_example

-- Mike Treseler

 

[Just an Illusion]

Hi Sion,

Gunit wrote:

snip

When I synthesise the state machine, I get a warning
"'flag' is not always assigned. Storage may be needed.."
Am I avoiding generating a latch if I am certain that the flag will be
cleared in a subsequent state, or is this bad practice in general??


I don't know how you can avoid to have a flip-flop, because in your

example you have a logic which must maintain a value between two events
(a set event and a clear event).

You can try to define the flag value at each state with:

if (flag = '0') then
flag='0';
else
flag='1';
end if;

but I am not sure that you remove the ff after synthesis by this way.

Question: I am not sure to well understand your example, could you
confirm me if the following pseudo code is the expected once ?

if (reset = '0') then
state <= idle; -- aka a
then (clk'event and clk='1') then
state <= nxt_state;
end if;

case state
when a =>
if (flag = '0') then
nxt_state <= b;
else
nxt_state <= f;
end if;
-- The fsm stays in state a only during one clock cycle
end case;

That's correct ?

JaI

 

[Tim Hubberstey]

ALuPin wrote:

can someone tell me how to define the programming time of a EP1C12 Cyclone
when using PL-BYTEBLASTER2 cable in comparison to PL-USB-BLASTER cable?

Wrong newsgroup, try comp.arch.fpga.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Just an Illusion]

Hi Chao,

Or use a type.

type FOO is ("VARIABLE", "FIXED", "LONG"...);

it is equivalent to Mike proposal about integers.

JaI

Mike Treseler wrote:

c.chen@gmx.de (Chao) wrote in message news:<8228a344.0406260707.225cf92a@posting.google.com>...



but when I tried to implement it in ISE6.2 with parameter "FIXED", it
gave the following warning message: WARNING:Xst:795: at Line002, Size
of operands are different : result is <false>. My assumption is that
the string length is different, therefore ISE prints out the message.



That's right. Consider:

"VAR"
"FIX"
"LOW"

or use integers.



Does anyone give me some hint how to solve it? Or is it harmless?



Not harmless.
Sim won't work and generates won't happen until
all the string lengths match the base entity.

-- Mike Treseler

 

[Just an Illusion]

Hi Weng,

Weng Tianxiang wrote:
<snip>

When many sources driver one bit, designers don't have to write
special code to tell simulators to tell if they are wrong.

In case of multidriving signal, you must be sure that only one value is

given at a time (possible by many drivers, but the same).
If not, a warning (possible an error) must be given, because if compiler
conclude that two differents values can be set at same time, that can be
because you have an error.

If your proposal hide this, you can recover this problem in a later step
of developpement; and in this case, it can be very hard to find the true
origin. It is time consuming, and money cost.

Doing so will relieve all designers from writing all unnecessary
assert or 'errels' to detect errors.

Amy comments are welcome.

Weng

 

[Tim Hubberstey]

ALuPin wrote:

Tim Hubberstey <bogus@bogusname.com> wrote in message news:<e0YDc.29232$E84.16282@edtnps89>...

ALuPin wrote:

can someone tell me how to define the programming time of a EP1C12 Cyclone
when using PL-BYTEBLASTER2 cable in comparison to PL-USB-BLASTER cable?


Wrong newsgroup? Why?

First, because this group is for discussing the VHDL language and tools
directly related to the language. Check the FAQs for the charter (
http://www.eda.org/comp.lang.vhdl ). Details of programming hardware
does not fall under this definition, IMO. If all questions were
appropriate for all newsgroups, there would be no reason to have
anything other than one giant group instead of the hierarchy of groups
that does exist.

Second, because, presumably, you want an answer to your question.
comp.arch.fpga is a better venue for getting an answer because you have
a broader base of people who are specifically interested in FPGAs.

Does describing hardware not mean programming it sooner or later?

Actually, no it doesn't. FPGA/CPLD devices are only a subset of the
hardware developed using VHDL. I have written thousands of lines of VHDL
(for ASICs) that have never passed through any kind of programmer. And
then there's the 60% of the total code that is used for verification
that isn't even synthesizable.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Just an Illusion]

Hi Jim, Weng,

Hence, my advice is for you to learn PSL. It is planned
to be integrated into VHDL in the next revision and
will provide much greater functionality than your
proposed exclusive.

psl is an assertion language to define formal properties.
I don't think that psl can be use to drive simulation or synthesis. The
psl must drive formal validation engines.

Why psl can't be use for simulation ?
In psl, you can write what is must be, but what you mustn't too.
Simulation test only what the design can do, not more.
If you put an assert (generally to trace an unexpected behavior), and if
you find the trace in your simulation. It is because you have an error.
Some time, you have no assert generation, because your test cases are
not enough.

Take the following example: you have a fifo of 1k element, this fifo
have an error because it erase the begining of fifo data when the fifo
is full, and an input is add.
You use this fifo into a system, which require only 512 elements from
the fifo. You can do all your simulations without any error (and any
assert).
Formal validation can point you the weak of the fifo, not simulation.

Why psl can't be use for synthesis ?
Some psl properties can be help for reduce a little some logic
equations, but in general you describe some 'trace' or 'scenario' and
that is not usefull for synthesis.
Example:
If you have a handshake protocol: {REQ,*,ACK} => after a request you
must have an acknowledge

Could you tell me how you can use this property to drive synthesizer ?

Rgrds,
JaI

 

[Tim Hubberstey]

Naimesh wrote:

I am using XILINX ISE 6.1 and Modelsim for simulation. when I run the
simulation I get follwoing warning.

Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, the
result will be 'X'(es).
# Time: 0 ps Iteration: 0 Instance: /testbenchcmedmain/uut/dpll1
# ** Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic
operand, the result will be 'X'(es).
# Time: 0 ps Iteration: 0 Instance: /testbenchcmedmain/uut/dpll1

Now when I see the WAVE window I dont get any X'es in any signal. How
do I find out which signal is creating the problem.

It's not a problem. Note that they are warnings and occur at time = 0.
This is typically the result of doing an integer conversion (either
directly or implicitly) on an std_logic_vector or unsigned/signed in
combinational logic.

e.g. n:1 mux
out <= input_vector(to_integer(unsigned(select_vector));

These vectors are 'X' at time=0, hence the warnings. It is possible to
disable them but unless there are a huge number of them, I usually just
ignore them.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Gary Michels]

c.chen@gmx.de (Chao) writes:

thank you for your answer. yes, I knew that was caused by the setup
time requirement. It is a good idea to avoid the meta-stability for
sampling the input data. Can you give me some explanation to the X_FF
component? because it is appeard very often in the timing_sim.vhd
(i.e. tool-generated timing simulation file). Thanks

X_FF is just the simulation model of a Flip-Flop. As far as I remember
the sources of the model are delivered with your copy of ISE. Search
the Xilinx directory for the simlation sources. Normally you compile
these sources to build your simulation library.

If you don't like the original simulation model, just write your own one

But if your problem is asynchronous inputs that cause many 'X' in simulation,
then I'd suggest searching the group on how to switch of x-propagation of your
simulator.

BR

 

[Barry Brown]

For ModelSim, you add this option to your vsim command:
-GXon=FALSE

"Gary Michels" <i_ll_reply_to_the_group@hotmail.com> wrote in message
news:1xjywcpw.fsf@inter.net...

c.chen@gmx.de (Chao) writes:

thank you for your answer. yes, I knew that was caused by the setup
time requirement. It is a good idea to avoid the meta-stability for
sampling the input data. Can you give me some explanation to the X_FF
component? because it is appeard very often in the timing_sim.vhd
(i.e. tool-generated timing simulation file). Thanks

X_FF is just the simulation model of a Flip-Flop. As far as I remember
the sources of the model are delivered with your copy of ISE. Search
the Xilinx directory for the simlation sources. Normally you compile
these sources to build your simulation library.

If you don't like the original simulation model, just write your own one


But if your problem is asynchronous inputs that cause many 'X' in
simulation,
then I'd suggest searching the group on how to switch of x-propagation of
your
simulator.

BR

 

[Ken Smith]

In article <10e309llhjf87fa@corp.supernews.com>,
Jim Lewis <Jim@SynthWorks.com> wrote:
[...]

is that nothing validates this claim. By making
a limited number of assertions synthesizable
(perhaps it is only onehot), then the claim can be
verified in the simulator. I agree this has the
limitation if I write incomplete tests, however,

I'm joining this argument late and am far from an expert but it seems to
me that this is the hard way to get where we want to go. It seems simpler
to me to be able to do something like this:

process (SomeStd_logic_vector) begin
if 1 = HowManyHigh(SomeStd_logic_vector) then
-- prehaps nothing here
else
assert-it-is-broken;
end if;
end process;


The Sim. can implement the real assert. The Synth can make everything a
don't care in the asserted state. The advantage is that the language
designers don't have to know about my "3.5 hot" state machine that I'm
just about to patent but I can still test that it is going to work right.

--
--
kensmith@rahul.net forging knowledge

 

[Brian Philofsky]

Let me start by saying, do not write your own X_FF model and do not use
the -GXon switch. Neither is good advice in my opinion and both of
these can get you into far more trouble than help in almost any
situation. Let me first address the initial question: "Can someone tell
me more about the X_FF component from the simprim library? Or is there
any link for the explanation."

Simulation is covered in the Synthesis and Verification Design Guide.
The current version is located at:
http://toolbox.xilinx.com/docsan/xilinx6/books/docs/sim/sim.pdf
If you go to chapter 6 and go to the section "Debugging Timing Problems"
(page 265) it will explain the timing message and how to understand what
it is telling you, how to debug the issue and hopefully solve the
problem. This is also explained in less detail in Answer Record #5255
SIMPRIM, Timing Simulation - What are "$setup" and "$hold" violations,
and how do I fix them? (VHDL, Verilog) (at www.xilinx.com/techdocs/5255.htm)

If the input is truly an asynchronous input, then you need to design
your circuit to avoid the side-effects of missing timing such as
metastability and once you are satisfied, you can put an ASYNC_REG
attribute on that register. This has the advantage of disabling
X-propogation on that register only so if you have a timing violation
elsewhere, it will still behave appropriately. The global disabling of
X-propogation adds the danger of missing a timing violation in a
synchronous path which can cause a very unpredictable circuit. This too
is covered in more detail in the documents referenced above. Look at
the "Disabling 'X' Propagation" section in the Synth & Verification
Guide which is also referenced from the above section on debugging
timing problems and the link in the Answer record.

I highly suggest you browse through the chapters of this book as it may
explain other things you are seeing in functional and timing simulation
and give more elegant solutions that you may have thought otherwise.
Also the on-line answer records cover many of these topics. Finding the
right answer record is not always easy as there is a lot of information
available there but if you type in the right key words, it generally
comes out in the top few and should not be too hard to find. You should
not need anything near 60 minutes to find this information and if that
is the case, then something is wrong. If you have suggestions on
improving how this data is presented, let me know and I can be sure to
pass that on to the appropriate people.


-- Brian


Barry Brown wrote:

For ModelSim, you add this option to your vsim command:
-GXon=FALSE

"Gary Michels" <i_ll_reply_to_the_group@hotmail.com> wrote in message
news:1xjywcpw.fsf@inter.net...

c.chen@gmx.de (Chao) writes:


thank you for your answer. yes, I knew that was caused by the setup
time requirement. It is a good idea to avoid the meta-stability for
sampling the input data. Can you give me some explanation to the X_FF
component? because it is appeard very often in the timing_sim.vhd
(i.e. tool-generated timing simulation file). Thanks

X_FF is just the simulation model of a Flip-Flop. As far as I remember
the sources of the model are delivered with your copy of ISE. Search
the Xilinx directory for the simlation sources. Normally you compile
these sources to build your simulation library.

If you don't like the original simulation model, just write your own one



But if your problem is asynchronous inputs that cause many 'X' in

simulation,

then I'd suggest searching the group on how to switch of x-propagation of

your

simulator.

BR

 

[Just an Illusion]

Hi Daragoth,

Sorry for the delay, but I have not time to look your code.

One remark about your code and the shared variables:
* comm_state is use like a fsm state. It is better if you modelize
all your fsm with the same structure.
One process to compute the fsm state, and an other process to
compute the outputs.
A typical structure can be:

signal comm_state : comm_type; -- Your current fsm state
signal nxt_comm_state : comm_type; -- Your next fsm state

...

GenNxtState: process (comm_type,clock_count,bitnum,maxbit)
begin
case comm_type is
when wait_X =>
nxt_comm_state <= receive_X;
when receive_X =>
-- When you are in this state you go nowhere
when receive_Y =>
if (clock_count = 6) then
nxt_comm_state <= send_X;
end if;
when send_X =>
if (clock_count = 4 and bitnum = maxbit) then
nxt_comm_state <= wait_X;
end if;
when others => null; -- or better nxt_comm_state <=
wait_X to go back to a know state
end case;
end process;

GenFSMState : process (clock)
-- You need certainly a reset to ensure that you fsm begin at
wait_X state
begin
if falling_edge(clock) then
comm_state <= nxt_comm_state;
end if;
end process;

GenOutputs : process (comm_state)
begin
case comm_state is
...
end case;
end process;

* clock_count is a counter with multi asynchronous reset.
You can made some specific process which manage the counter:

signal reset_counter : std_logic;

genResetCounter : process (comm_state, clock_count)
-- Becarefull, I think that you expected a synchronous reset for
clock_count=6 and clock_count=4
begin
case comm_state is
when receive_X =>
reset_counter <= '0';
when receive_Y =>
if (falling_edge(data_Y) or clock_count = 6) then
reset_counter <= '0';
else
reset_counter <= '1';
end if;
when send_X =>
if (clock_count = 4) then
reset_counter <= '0';
else
reset_counter <= '1';
end if;
when others =>
reset_counter <= '1';
end case;
end process;

GenCounter : process (clock, reset_counter)
begin
if (reset_counter = '0')
clock_count <= 0;
elsif (falling_edge(clock)) then
clock_count := clock_count + 1;
end if;
end process;

In general, you can't synthesize your current code, because comm_state
appear as drive by two clock signals data_X and clock.
More it missing condition to get out from receive_X state.

You have a wait to partially solve you problem of double clock, you can
modifie in my previous example process by:

GenNxtState: process (comm_type, data_X,clock_count,bitnum,maxbit)
begin
case comm_type is
when wait_X =>
if (falling_edge(data_X)) then
nxt_comm_state <= receive_X;
end if;
when receive_X =>
-- I am not sure that you need this state, expect to
drive an external resynchronization circuit for clock, as dpll
-- In fact you certainly need a state to detect Y arrival.
-- Otherwise you need count the number of bits in X
frame, then you couldn't reset clock_count
when receive_Y =>
if (clock_count = 6) then
nxt_comm_state <= send_X;
end if;
when send_X =>
if (clock_count = 4 and bitnum = maxbit) then
nxt_comm_state <= wait_X;
end if;
when others => null; -- or better nxt_comm_state <=
wait_X to go back to a known state
end case;
end process;

To help you understand, design the sytem with in mind that one process
must handle one signal (only).
After, you can merged the process with similar structure (same
sensitivity list, same control structure).

Remember that register must be drive by only one clock, the design must
be locally synchronous, even if it's appear asynchronous at top level.

In any case if you want use a fpga as target, remember that fpga have
generally one clock input (a few with 2) that drive all register cells
(always on the same edge).

I hope that can help you,
JaI

Daragoth wrote:

Thanks for the tips. What I'm thinking of doing is using a 1 MHz
clock to sample for the value of a bit 2 us after a falling edge in
the data line. The only time the data falls is at the begining of a
new bit. So I would synchronize the clock with each of these edges
and use a counter to determine how many ticks occur. To find the end
of a word I would just check if the clock surpasses 5 ticks after
every synchronization (X sends Y a constant high signal when it is not
sending data). For sending data I would use the clock, by first
sending '0', then for the next 2 us the bit's value, then '1', then
moving to the next bit. Is this a good solution, or is there a better
way? As I said I want to minimize the number of chips I use as I have
very limited space so I can't use a seperate chip as a shift register.

Here is the code I made for this process. I would like to change the
shared variables it uses to signals, but because they are used in
multiple processes it causes errors. Any idea how to change this?
Any improvements or suggestions to the method I used?



library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity mod_X_Y is
generic (tpd : Time := 10 ns);
port (clock : in std_logic;
reset : out std_logic;
data_Y, data_X : inout std_logic);
end mod_X_Y;

architecture behavior of mod_X_Y is
type comm_type is (wait_X, receive_X, receive_Y, send_X);
shared variable comm_state : comm_type := wait_X;
shared variable clock_count : integer range 0 to 6;
begin
comm_X: process (data_X)
begin
if falling_edge(data_X) then
case comm_state is
when receive_X =
clock_count := 0;
reset <= '1' after tpd;
when wait_X =
comm_state := receive_X;
when others => null;
end case;
else null;
end if;
end process comm_X;
comm_Y: process (data_Y)
begin
if falling_edge(data_Y) then
case comm_state is
when receive_Y =
clock_count := 0;
reset <= '1' after tpd;
when others => null;
end case;
else null;
end if;
end process comm_Y;
count_up: process (clock)
-- insert constants and variables pertaining to modification
here
constant word_len_Y : natural := 86;
variable data_i, data_o, data_q : std_logic_vector(word_len_Y -
1 downto 0);
variable bitnum, maxbit : integer range 0 to word_len_Y - 1 :=
0;
begin
if falling_edge(clock) then
clock_count := clock_count + 1;
case comm_state is
when send_X =
data_Y <= '1' after tpd;
case clock_count is
when 1 =
data_X <= '0' after tpd;
when 2 | 3 =
data_X <= data_o(bitnum) after tpd;
when 4 =
data_X <= '1' after tpd;
clock_count := 0;
bitnum := bitnum + 1;
if bitnum = maxbit then
comm_state := wait_X;
bitnum := 0;
else null;
end if;
when others => null;
end case;
when others =
data_Y <= data_X after tpd;
data_X <= '1' after tpd;
end case;
if comm_state = receive_Y then
case clock_count is
when 3 =
data_i(bitnum) := data_Y;
bitnum := bitnum + 1;
when 6 =
comm_state := send_X;
data_o := data_i;
-- insert modification code here
data_q := data_i;
clock_count := 0;
maxbit := bitnum;
bitnum := 0;
when others => null;
end case;
else null;
end if;
else null;
end if;
end process count_up;
end behavior;



If the code is difficult to read, I made a commented version of it
too:



library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity mod_X_Y is
generic (tpd : Time := 10 ns);
port (clock : in std_logic;
-- 1 MHz clock
reset : out std_logic;
-- resets clock
data_Y, data_X : inout std_logic);
-- communication lines to devices X and Y
end mod_X_Y;

architecture behavior of mod_X_Y is
type comm_type is (wait_X, receive_X, receive_Y, send_X);
shared variable comm_state : comm_type := wait_X;
shared variable clock_count : integer range 0 to 6;
begin
comm_X: process (data_X)
begin
if falling_edge(data_X) then
case comm_state is
when receive_X =
clock_count := 0;
-- synchronizes clock with data stream
reset <= '1' after tpd;
when wait_X =
comm_state := receive_X;
-- 'wakes' device out of waiting state
when others => null;
end case;
else null;
end if;
end process comm_X;
comm_Y: process (data_Y)
begin
if falling_edge(data_Y) then
case comm_state is
when receive_Y =
clock_count := 0;
-- synchronizes clock with data stream
reset <= '1' after tpd;
when others => null;
end case;
else null;
end if;
end process comm_Y;
count_up: process (clock)
-- insert constants and variables pertaining to modification here
constant word_len_Y : natural := 86;
variable data_i, data_o, data_q : std_logic_vector(word_len_Y - 1
downto 0);
variable bitnum, maxbit : integer range 0 to word_len_Y - 1 := 0;
begin
if falling_edge(clock) then
clock_count := clock_count + 1;
-- increment clock counter every time clock ticks
case comm_state is
when send_X =
data_Y <= '1' after tpd;
-- send high bits to Y when communicating with X
case clock_count is
when 1 =
data_X <= '0' after tpd;
-- 1st us of the bit is always low
when 2 | 3 =
data_X <= data_o(bitnum) after tpd;
-- 2nd and 3rd us of the bit are equal to the bit's value
when 4 =
data_X <= '1' after tpd;
-- 4th bit is always high
clock_count := 0;
-- reset clock counter
bitnum := bitnum + 1;
-- begin process again on next bit
if bitnum = maxbit then
comm_state := wait_X;
bitnum := 0;
-- if the last bit of the word has been sent, go
-- back to initial conditions and wait for X
else null;
end if;
when others => null;
end case;
when others =
data_Y <= data_X after tpd;
-- send to Y what X is sending if not in the process of sending to X
data_X <= '1' after tpd;
-- only time Y doesn't send high bits to X is taken care of already
end case;
if comm_state = receive_Y then
case clock_count is
when 3 =
data_i(bitnum) := data_Y;
bitnum := bitnum + 1;
-- when 2 us have passed after the falling edge of data,
-- sample data for its value, then increment bit
when 6 =
-- because of the reset and synchronization, the clock should
-- never get this far unless the word of data has been finished
comm_state := send_X;
data_o := data_i;
-- for use with modification
-- insert modification code here
data_q := data_i;
-- for use with modification
clock_count := 0;
maxbit := bitnum;
-- if receiving data from Y, record the length of the word
bitnum := 0;
-- prepare for sending word
when others => null;
end case;
else null;
end if;
else null;
end if;
end process count_up;
end behavior;



Thanks a lot for any help regarding the issue.

 

[Tim]

Brian Philofsky wrote:

Finding the right answer record is not always easy as there
is a lot of information available there but if you type in
the right key words, it generally comes out in the top few
and should not be too hard to find.

But nowhere near as easily as if you had a Google-style search
interface. Searching answers at X is absurdly difficult unless
you are in the priesthood.

 

[Brian Philofsky]

Tim wrote:

Brian Philofsky wrote:

Finding the right answer record is not always easy as there
is a lot of information available there but if you type in
the right key words, it generally comes out in the top few
and should not be too hard to find.


But nowhere near as easily as if you had a Google-style search
interface. Searching answers at X is absurdly difficult unless
you are in the priesthood.

For me, it is generally not too difficult to find what I want there but
I generally have a good idea what to type to get it. In other words, I
have enough knowledge about what I am searching for to type in the
correct keywords and the practice using the system and understanding the
search tips (http://www.xilinx.com/support/tips.htm) to get the right
items to show up to the top (and I didn't even realize I have joined the
priesthood). I realize that I may not be the typical user of this
resource though so it is always good to hear from others. It is my
understanding that people within Xilinx are actively looking at the
search engine for improvements but what would help is a little more
information on how people are using it. If you are searching for
something and do not find it, spend a few moments to notify Xilinx about
this and give the specifics about how you were attempting to get that
information. Sending this feedback can be as easy as clicking on the
first Answer record that pops up, select the Feedback link and let them
know what you typed, what you are looking for, the fact you could not
easily find it and that this was the first answer record displayed but
unrelated to what you were trying to find. It is this specific
information that will likely best help in improving the search engine
more-so that just telling us it is difficult to find information. This
really should not take much time to do and hopefully that feedback will
improve the search in the future and end up giving back that time and
then some by better displaying the appropriate information more quickly.


-- Brian

 

[Jim Lewis]

Weng,

Tell me what advantages of your assert() is over my keyword
'exclusive'.

If I am confused, I don't know how many would be consufed.

exclusive (A1, A2, A3);

Semantically both are the same. Don't forget that you need

to add syntax to tell exclusive to operate only at a specific
edge of a specific clock.

From a language designer perspective, PSL (assertions)
are already being integrated (separate standard) with
VHDL. EDA vendors are starting to support it.

So it is a simple matter learning the syntax and using it
rather than adding a new language feature. Note that
anytime a new keyword is added to the language there
is the possibility that the keyword will conflict with
an identifier existing code.

I will tell you why 'orif' is better than 'exclusive'
in most of time in examples next time.
A good long example would most helpful.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Mike Treseler]

Pino wrote:

I'm not completely clear on how to use bidirectional ports in VHDL for
use with connecting to SDRAM shared data lines. How do I specify this
in my state machine if I am to read and then write to the line?

http://groups.google.com/groups?q=vhdl+inout+oe

-- Mike Treseler

 

[Jim Lewis]

Weng,

1. When one declares that two signals are exclusive,
they must be registered at the same clock, ...

Mutually exclusive RTL signals may overlap when they
are changing if one has more delta cycles than another.
Hence, somehow an eda tool must have a way to determine
when this overlap is a failure and when this overlap
is irrelevant. An easy way to do this is for the
construct to specify the relevant edge of the
clock.

I suppose alternately you could expect the tool to
do this. Of course this would mean it would need to
trace from the logic to all the registers in the
logic cone and check the constraint there. What
if the register is in a separate logic block?

Note that anytime a new keyword is added to the language there is the possibility that the keyword will conflict with an
identifier existing code.

This is another wrong assumption with either 'exclusive' or 'orif'.

If someone currently has this in their code:
signal exclusive : std_logic ;

and I add exclusive as a keyword to the language,
then their code will no longer compile and they
must change their signal name.


Still waiting patiently for your more extensive
"orif" examples.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Nicolas Matringe]

Just an Illusion a écrit:

Hi Pino,

You must have something like:

Z : inout std_logic;
...

signal A, OE, Y : std_logic;


Z <= A when OE = '1' else '-';
Y <= Z ;

Canonical form here is
Z <= A when OE = '1' else 'Z';

or, for vectors:
Z <= A when OE = '1' else (others => 'Z');

'-' is "don't care" (never understood what this stands for, actually),
not "high impedance".

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/