Clock Edge notation

[Tim Hubberstey]

Mohammed A Khader wrote:

Hello,

When synthezing the design with Synplify Pro 8.0 it gave the
follwoing Warning.

CL209 Input port bit <4> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <3> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <2> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <1> of spi_addrs(4 downto 0) is unsed.


I am sure that I am using the slice (4 downto 1) as an input to the
mux.

I tried by assigning this slice to an intermediate wire (signal) and
then to the mux input . But again it is giving the same error.

Following is the relevant piece of code....
ntity Ctrl_Ram is
port(
Ctrl_Data_In : in WORD;
Ctrl_Addrs : in unsigned(3 downto 0);
Spi_Addrs : in unsigned(4 downto 0);
Ctrl_Wr : in std_logic;

Intl_Rst : in std_logic;
Clk : in std_logic;

Reset : in std_logic;

Data32_Out : out DWORD;
Data16_Out : out WORD
);
end entity Ctrl_Ram;

Architecture arch of Ctrl_Ram is
begin
spi_addrs_intl <= Spi_Addrs(4 downto 1);
Addrs_Muxrocess(Ctrl_Addrs,spi_addrs_intl,Intl_Rst)
begin
case Intl_Rst is
when '0' => Addrs_In <= spi_addrs_intl;
when '1' => Addrs_In <= Ctrl_Addrs;

when others => Addrs_In <= (others =>'X');
end case;
end process Addrs_Mux;

I don't see anything wrong with your code, other than being
unnecessarily complex.

This warning from Synplify usually comes from the optimization phase. It
typically means that the signal referred to does not enter into the
reduced equation of any output or stored internal state. This can be
either because you have a logic error somewhere in your design, or
because interaction with some other signal(s) causes the result to not
depend on the flagged signal. In other words, you have to examine the
total portion of the design that includes the entity in question.

This type of warning is an extremely common in large and/or
parameterized designs. It needs to be investigated to make sure the
optimization is reasonable, but it isn't something to panic over.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[Ken McElvain]

If Addrs_In is unused, then the references to spi_addrs will
be pruned leaving spi_addrs unused.

Mohammed A Khader wrote:

Hello,

When synthezing the design with Synplify Pro 8.0 it gave the
follwoing Warning.

CL209 Input port bit <4> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <3> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <2> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <1> of spi_addrs(4 downto 0) is unsed.


I am sure that I am using the slice (4 downto 1) as an input to the
mux.

I tried by assigning this slice to an intermediate wire (signal) and
then to the mux input . But again it is giving the same error.

Following is the relevant piece of code....
ntity Ctrl_Ram is
port(
Ctrl_Data_In : in WORD;
Ctrl_Addrs : in unsigned(3 downto 0);
Spi_Addrs : in unsigned(4 downto 0);
Ctrl_Wr : in std_logic;

Intl_Rst : in std_logic;
Clk : in std_logic;

Reset : in std_logic;

Data32_Out : out DWORD;
Data16_Out : out WORD
);
end entity Ctrl_Ram;

Architecture arch of Ctrl_Ram is
begin
spi_addrs_intl <= Spi_Addrs(4 downto 1);
Addrs_Muxrocess(Ctrl_Addrs,spi_addrs_intl,Intl_Rst)
begin
case Intl_Rst is
when '0' => Addrs_In <= spi_addrs_intl;
when '1' => Addrs_In <= Ctrl_Addrs;

when others => Addrs_In <= (others =>'X');
end case;
end process Addrs_Mux;


Thank you.

-- Mohammed A Khader.

 

[Ken McElvain]

If Addrs_In is unused, then the references to spi_addrs will
be pruned leaving spi_addrs unused.

Mohammed A Khader wrote:

Hello,

When synthezing the design with Synplify Pro 8.0 it gave the
follwoing Warning.

CL209 Input port bit <4> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <3> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <2> of spi_addrs(4 downto 0) is unsed.
CL209 Input port bit <1> of spi_addrs(4 downto 0) is unsed.


I am sure that I am using the slice (4 downto 1) as an input to the
mux.

I tried by assigning this slice to an intermediate wire (signal) and
then to the mux input . But again it is giving the same error.

Following is the relevant piece of code....
ntity Ctrl_Ram is
port(
Ctrl_Data_In : in WORD;
Ctrl_Addrs : in unsigned(3 downto 0);
Spi_Addrs : in unsigned(4 downto 0);
Ctrl_Wr : in std_logic;

Intl_Rst : in std_logic;
Clk : in std_logic;

Reset : in std_logic;

Data32_Out : out DWORD;
Data16_Out : out WORD
);
end entity Ctrl_Ram;

Architecture arch of Ctrl_Ram is
begin
spi_addrs_intl <= Spi_Addrs(4 downto 1);
Addrs_Muxrocess(Ctrl_Addrs,spi_addrs_intl,Intl_Rst)
begin
case Intl_Rst is
when '0' => Addrs_In <= spi_addrs_intl;
when '1' => Addrs_In <= Ctrl_Addrs;

when others => Addrs_In <= (others =>'X');
end case;
end process Addrs_Mux;


Thank you.

-- Mohammed A Khader.

 

[Mike Treseler]

Thorsten Bunte wrote:

** Warning: ../SRC/RTL/arch_ADRDEC.vhd(1977): Case choice must be a locally
static expression.

This has been discussed here.
http://groups-beta.google.com/groups?q=Case+choice+locally+static+expression

-- Mike Treseler

 

[Tim Hubberstey]

Deepa wrote:

Hai all!
I am a newbie in VHDL. And my project involves interfacing digital
camera with FPGA. May I know the ways I can do it?

if method = "do_it_myself" then
specification <= research & write;
comp.lang.vhdl <= questions(reasonable);
code <= write & debug;
happy <= true;

elsif find(sucker) = true then
happy <= true;
task <= sucker;

else
if balance(bank) > $10000 then
report "Ouch!" severity note;
task <= consultant($10000);
happy <= true;

else
happy <= false;
end if;

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

 

[Bert Cuzeau]

johnp wrote:

Bryan -

Maybe I'm jaded since I'm a consultant, but a lot of engineers just
don't
understand subtle issues like clock domain crossing. I've had to clean
up so many bugs in this area that I can't count them all. Just when
you think
you've seen every way to send signals between clock domains
incorrectly,
a new way is invented.

We are a Design house plus we train about 300 engineers per year,
and I have exactly the _same_ experience a Bryan.

And what I see in the newsgroup doesn't tell me that every engineer
writing VHDL does it with a clear understanding of these issues and
of their solutions. I can only say for France, but here, the language
and Electronic Design is very poorly taught even in the most
prestigious Engineering schools (they don't even teach what Static
Timing Analysis is !). We train lots of young engineers, and they
have all the same feedback and stories.

In our consulting business we sometimes do kind of "PostMortem"
on designs that fail miserably, and the issues end up having a
very basic cause. Sort of 80-20 here too : 80% of the failures
have a very low complexity reason and could be avoided by
simple rules. The reason of failures (respins) in Asic design
as reported year after year by Synopsys seem to say as much
(with better figures, since beginners are not allowed here).

Another point I see is personal satisfaction.
It's rewarding to create a complex working system in a small
FPGA in a few days or weeks. It's no so satisfying to laboriously
recreate an inferior version of something done by others and
freely available. That's why, in our Educational Kit, I try to
set up fancy exercises and stay away from Trafic Light Controllers.
I think it's more fun to drive a thermometer chip, an LCD,or read
a Smart Card, or create a UART, and not much more complex.

Bert Cuzeau

 

[Mike Treseler]

Nicolas Matringe wrote:

I was wondering if it was possible (read synthesizable) to assign a
variable to a signal in a clocked process *outside* the reset/clock
edge condition.

Yes. This works as expected to wire a
variable value to a port or signal output.
It synthesizes a wire cleanly for
all tools I have tested it on.

Because the statement.

htbt_led <= led_v;

is executed for both edges of
clock and reset, the signal/port output
reset style *automatically* matches the
the output variable, and a duplicate
output register is avoided.

Logic other than output assignments
should be kept inside the if statement
to avoid synthesis of flops using
the falling clock edge.

Note that you can accomplish the same
thing *inside* the if statement
by manually matching a signal/port reset to
the output variable, that is

if rst = '1' then
cntr <= 0;
led := '0'; -- variable reset assignment
htbt_led <= '0' -- matching port/signal assignment
elsif rising_edge(clk) then
-- etc


-- Mike Treseler

 

[John_H]

"Bryan" <bryan@srccomp.com> wrote in message
news:1114789139.100649.204350@l41g2000cwc.googlegroups.com...

I am not going to tell you that designing an async FIFO is hard, I hope
this doesn't affect your wizard status.

Then face up to his challenge.
If it isn't hard, you should be able to produce the reliable EMPTY-flag
detection and show it works in a couple of hours.

 

[info_]

Nisheeth wrote:

hello group
i have written a vhdl file which is using
packages,generics etc.It compiles successfully and simulation is as
expected.
I went ahead to the next step i.e synthesis and ISE gave no
problem at all. Then i did post translate simulation using Modelsim
and my simulation results are not coming as expected...all o/p lines
are tristated. I got the following warning in Modelsim.

Warning(1) : wpcal_tb.translate_vhw(86) : No default binding for
component "wp_cal" ( Generic "we" is not on the entity)

plz give me some clue how to fix it...

Looks like there is a mismatch between your component
declaration and the actual entity for wp_cal.
(probably the generic section which is lost at synthesis)
If you try to do unitary timing simulation (I hope you've
good reasons to do this, I recommend to wrap up the entity
in a synthesizable "top level" with no generic (and indeed
no exotic type that the synthesis will modify).
Then you should have no trouble (using the same testbench)

Another solution would be to use a configuration section
to reconcile the two different entoty declarations at
instanciation.

regards
nisheeth

nisheethg@gmail.com

 

[Mike Treseler]

Nisheeth wrote:

Warning(1) : wpcal_tb.translate_vhw(86) : No default binding for
component "wp_cal" ( Generic "we" is not on the entity)

plz give me some clue how to fix it...

Your netlist instance is an empty box.
Fire up your text editor and look at wp_cal.vhd
and see what happened to "we".

-- Mike Treseler

 

[info_]

Berty wrote:

Back to simulation yes you can simulate Async FIFO even if
theoretically you can have infinite number of condition, since many of
those infinite are the same, just like when you test SONET Frame you
can argue it is impossible since there is infinite number of
combination as each data can be differ gap between frame can be differ,
number of frame can be differ etc, and there are many more examples of
infinite condition which using finite number of test you can verify
very well your design assuming the test bench is done properly.

To give you an idea of one approach is have a script that generate two
value in define file which you later include in your simulation.
So for example the file output can be
`define clk1 19.9
`define clk2 24.9
in one time and in another time can be for example
`define clk1 36.1
`define clk2 10.8
and so on and so on, where the number and resolution depend on what you
want to test (Myself I run all in unix so this file is generated using
unix script, but I'm sure there is a way to do it also in window/dos
or what ever is your platform).

Berty,

How do you handle the case of timing violations in timing simulations ?
It's usually difficult, and I remember having used VHDL configurations
to turn FlipFlops with timing models into models that do not propagate
X'es while performaing multiple clock domains timing simulation
(and the validation then becomes nil wrt timing violation).

In other words, I naively thought timing simulation wasn't the right tool
to validate asynchronous design, if only because of the "worst case only"
timing models, no MonteCarlo methods etc... I was more confident in
a human expert mind than on a timing simulator based on timings that
do not exist in the design.

I'm sure I'm going to learn something here (I'm NOT an asynchronous
design expert)

And I'm not ashamed to say that I am happy experts like you design the
asynchronous for me and let me focus on higher level issues

Bert Cuzeau

 

[John_H]

What you ask has already occurred: (see embedded links)

"Berty" <wooster.berty@gmail.com> wrote in message
news:1114809109.736832.199490@z14g2000cwz.googlegroups.com...

Peter,
I have no doubt you wrote many FIFO that work ok, and believe it or not
many other Eng did it as well, and even simulate it.

We are all here for the fun and joy of Eng, so Lets not make it a
Contest of who have the bigger ....

A Better approach which I believe will be more suitable and more
education will be since you feel so strongly about the FIFO you design
why don't you write App note or white paper about how it is done so
other Eng that are not aware of how to make Async FIFO will see and
learn and who knows maybe some of us that know how will learn something
new as maybe you have new way, After all there are many way to design
Async FIFO's depend on the requirement and amount of resource
available. (e.g. Phase handler, PPM handler, in high out low, in low
out high, any to any and they can be with and without gray, using
pessimistic approach, and so on and so on).

How about:

http://tinyurl.com/aa9or
(http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=SUPPORT&s
SecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_fifo)

Or maybe:

http://www.eetimes.com/editorial/2000/design0003.html

"In 1970, Alfke invented the first FIFO integrated circuit, the Fairchild
3341"

This individual has made a career out of helping other engineers and it
seems there are some here who don't RESPECT what this man has done for the
average FPGA designer or UNDERSTAND his contributions across the last 4
decades.

I, for one, appreciate the whitepapers and articles contributed outside the
forum, the general help inside therse forums, and the contributions to the
industry as a whole. Honestly, I don't understand the level of disrespect I
see in this conversation. I never quite understood why "flaming" was such a
big issue on the usenet because I've stayed away from the less professional
venues. Here I expect people to have a little homework under their belt
before making disparaging comments toward someone who KNOWS his business.

Back to simulation yes you can simulate Async FIFO even if
theoretically you can have infinite number of condition, since many of
those infinite are the same, just like when you test SONET Frame you
can argue it is impossible since there is infinite number of
combination as each data can be differ gap between frame can be differ,
number of frame can be differ etc, and there are many more examples of
infinite condition which using finite number of test you can verify
very well your design assuming the test bench is done properly.

To give you an idea of one approach is have a script that generate two
value in define file which you later include in your simulation.
So for example the file output can be
`define clk1 19.9
`define clk2 24.9
in one time and in another time can be for example
`define clk1 36.1
`define clk2 10.8
and so on and so on, where the number and resolution depend on what you
want to test (Myself I run all in unix so this file is generated using
unix script, but I'm sure there is a way to do it also in window/dos
or what ever is your platform).

Another parameter which should be randomize is burst of data you write
and how many of them per simulation.
Than you compile all and at the end verify automatically that all work
ok and if so your script start all over.
After one night or what ever depend on how strong is your machine etc
you can cover all the ranges you wanted, as well as maybe some pre
define freq and definition for dedicated tests. Using 1ns/1ps or
1ps/10fs etc can help you get the resolution you need.

The important thing from my experience is once you did all your
dedicated test and verify all to let the $random(seed) work in the
ranges of value you want to cover as well as make sure the test run
automatically just as the verifier so when you run an overnight test
you get large range of coverage.
Of course you should keep all the seed that generate failer in the test
so in the morning you can re-generate the same condition that cause the
failer.

But as always the most important this is Have fun

Having fun *is* important. I appreciate the comments that may help others
explore the subject further and the insights you have into design and test.
But there are people who actually "are" experts out there.

My apologies, Berty, if it seems I'm coming across strong against *your*
post since it's more Bryan's comments that disturbed me, but those
whitepapers and App Notes ARE out there.

 

[Tim Hubberstey]

Jerry Coffin wrote:

Tim Hubberstey wrote:

[ ... your code seems to have a bug or two: ]


elsif find(sucker) = true then


There's never a reason (IMO) to compare to true -- after all, if you're
comparing to true, you must already have a boolean, which is what the
comaparison also produces, so:

elsif find(sucker) then

Not really a bug, just redundant. That's what happens when you code on
the fly without checking the result.

happy <= true;
task <= sucker;


I suspect you really meant:

sucker <= task;

I.e. assigning the task to the sucker.

This all depends on your point of view. Assigning the sucker to the task
is, I believe, an equally valid expression.

Perhaps what is really needed here is some kind of bi-directional
assignment operator, like a transmission gate. I propose a new operator,
the "equivalence" operator, with symbol "<=>", for situations like this.
;-)
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

 

[info_]

Symon wrote:

...and learn about 'case' statements.
Syms.

I take advantage of your post (and of the WeekEnd)
for a question to the group.

I often see newbies writing things like :

case my_std_logic is
when '0' =>
when '1' =>
when others => -- they HAVE to write this indeed !!
end case;

They seem to believe it would be a better (more efficient !)
style than :
if my_std_logic='1' then
else
end if;

?????
Since I've seen this a number of times, I'm curious
to know who is telling them this ? and why ? a book ?

And when things get more complex, even more people seem
to say that the case statement is a miracle... and
would magically turn a "serial" computation into a "parallel"
one, more efficient, that one has a priority while the other
would not etc etc.... I usually hear the very same persons
say they don't know what the '-' (don't care) is about !

I'm _not_ saying here that the case statement is never to
be preferred, but the designer must be aware of the reality.
The case statement in VHDL also has it's unfriendly sides
(you often have to qualify the case expression like in
"case A&B is" + there is also the locally static issue
+ no way to use std_match in a case + case must be complete, etc...).
The Verilog case statement, associated with parallel case
pragma, is more versatile (like with a constant selector).

Even using the case statement (and don't cares), obtaining
the minimal logic sometimes requires efforts (as for the one
hot minimal decoder).
My recommendation is to usually favor the style which provides
the best expressiveness even at the (hypothetical) cost of a
few gates.

I quickly wrote the example below.
Note that I didn't merge the cases or the ifs so different
decoding logic can easily be tested. It is also possible
to remove some case(s) (thanks to the default statements).

Has anyone different views or experience to share ?

---------------------------------------------------------
-- Will the "case" statement really change your life ?
--
-- Please let me know if there is one synthesis tool which
-- does provide a different QOR for the two architectures below.
-- I would use the case statement myself, but not in the
-- hope of better QOR.

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

Entity casetest is
port ( A : in std_logic_vector (3 downto 0);
Q : out std_logic_vector (3 downto 0) -- MSB not used (= 0)
);
end;

-- ------------------------------------
architecture RTL_case of casetest is

begin

process (A)
begin
case A is
when x"0" =>
Q <= x"0";
when x"1" =>
Q <= x"1";
when x"2" =>
Q <= x"2";
when x"3" =>
Q <= x"2";
when x"4" =>
Q <= x"3";
when x"5" =>
Q <= x"3";
when x"6" =>
Q <= x"3";
when x"7" =>
Q <= x"3";
when x"8" => -- could use when others here
Q <= x"4";
when x"9" =>
Q <= x"4";
when x"A" =>
Q <= x"4";
when x"B" =>
Q <= x"4";
when x"C" =>
Q <= x"4";
when x"D" =>
Q <= x"4";
when x"E" =>
Q <= x"4";
when x"F" =>
Q <= x"4";
when others =>
Q <= "----";
end case;
end process;

end architecture RTL_case;

-- --------------------------------------------
architecture RTL_if of casetest is

begin

process (A)
begin
if A = x"0" then
Q <= x"0";
elsif A = x"1" then
Q <= x"1";
elsif A = x"2" then
Q <= x"2";
elsif A = x"3" then
Q <= x"2";
elsif A = x"4" then
Q <= x"3";
elsif A = x"5" then
Q <= x"3";
elsif A = x"6" then
Q <= x"3";
elsif A = x"7" then
Q <= x"3";
elsif A = x"8" then -- could put an "else" here
Q <= x"4";
elsif A = x"9" then
Q <= x"4";
elsif A = x"A" then
Q <= x"4";
elsif A = x"B" then
Q <= x"4";
elsif A = x"C" then
Q <= x"4";
elsif A = x"D" then
Q <= x"4";
elsif A = x"E" then
Q <= x"4";
elsif A = x"F" then
Q <= x"4";
else
Q <= "----";
end if;
end process;

end architecture RTL_if;

 

[Benjamin Menküc]

Hi Info,

I have read here, that case is more parallel:

http://www.vhdl-online.de/tutorial/deutsch/t_201.htm

regards,
Benjamin

 

[info_]

Benjamin Menküc wrote:

Hi Info,

I have read here, that case is more parallel:

http://www.vhdl-online.de/tutorial/deutsch/t_201.htm

regards,
Benjamin

I became the Saint Thomas of RTL syntyhesis

So let's take the example from your University course.
-ich verstehe ein bischen Deutsch-
I just modified the names to avoid reserved keywords
and added the proper types :

-- "case" statement tests
-- Bert Cuzeau

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

Entity casetest2 is
port ( A,B,C,Ad : in std_logic_vector (4 downto 0);
Q : out std_logic_vector (4 downto 0)
);
end;

-- --------------------------------------------

architecture RTL_if of casetest2 is
-- 12 LEs

begin

process (Ad,A,B,C)
begin
if unsigned(Ad) > 17 then
Q <= A ;
elsif unsigned(Ad) < 17 then
Q <= B ;
else
Q <= C ;
end if ;
end process;
end architecture RTL_if;

-- ------------------------------------

architecture RTL_case of casetest2 is
-- 12 LEs ?!

begin

process (Ad,A,B,C)
begin
case to_integer(unsigned(Ad)) is
when 0 to 16 =>
Q <= B ;
when 17 =>
Q <= C ;
when others =>
Q <= A ;
end case;
end process;

end architecture RTL_case;

Both RTL views "look" different indeed, but...
both styles end up with exactly the same number of LEs !
(used Quartus II's internal synthesis)
and identical timing performance.
With XST (ISE 6.3.03), the case version is 7 slices vs 6 slices for
the "if" version. We may hope it's slightly faster, but I wouldn't
bet on that either.

So I still don't see any proof that the case statement is the
(only) way to go.

But I am _not_ saying that arithmetic operator inference is
something not to care about !!! Quite the contrary !
With larger operators, I would double check, consider using
only one magnitude comparator, etc... (given a _strong_ motivation
for area or timing perf, otherwise I wouldn't care much and I
would spend my time more productively).

It's just that "coding style QOR" is a more complex issue than
it may seem, and is often very tool-dependant.
Even with a given tool, optimization options may impact the QOR.

....and I believe what I see by myself, and I always verify the big
"we are the best" statements from the tools vendors ;-)

Bert Cuzeau

 

[Benjamin Menküc]

Hi,

it would be interesting to know, if the if-style gets worse compared to
the case-style, when we have a very long if-chain (10x elsif or so).

regards,
Benjamin

 

[DAVID BINNIE]

Thanks Tim,

Deepa should also be aware that his supervisor reads the newsgroups too !

Dr B


"Tim Hubberstey" <bogus@bogusname.com> wrote in message
news:vDgce.8995$HR1.1403@clgrps12...

Deepa wrote:
Hai all!
I am a newbie in VHDL. And my project involves interfacing digital
camera with FPGA. May I know the ways I can do it?

if method = "do_it_myself" then
specification <= research & write;
comp.lang.vhdl <= questions(reasonable);
code <= write & debug;
happy <= true;

elsif find(sucker) = true then
happy <= true;
task <= sucker;

else
if balance(bank) > $10000 then
report "Ouch!" severity note;
task <= consultant($10000);
happy <= true;

else
happy <= false;
end if;

--
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]

info_ wrote:

They don't quite say this (or they'd lie).
"If ... elseif" has an implied priority (first test true -> next tests
are not taken)... but that makes no sense when you describe a truth table !
(as in my first encoder example)

"case" and "if then else"
have no overlapping cases and therefore no priority.

"if then else elsif elsif ... "
only implies priority if cases overlap.

I think this is the same with std_ulogic, which use was supposed
to help detect multiple drivers situations (it did). But there
are other ways to check this and so many other bad things are
to be tested at synthesis that everybody has dropped now this
unresolved type and obsolete style.

I agree that std_ulogic_vector is usually
more trouble than it's worth.
However std_ulogic has no such downside.
I use std_ulogic as my default bit type.
It port maps directly to std_logic without conversion.

-- Mike Treseler

 

[info_]

Deepa wrote:

Hai all!
I am a newbie in VHDL. And my project involves interfacing digital
camera with FPGA. May I know the ways I can do it?

Aye !

We wrote a short Apnote :
http://www.alse-fr.com/ALSE_Video.pdf
or if you prefer English :
http://www.alse-fr.com/English/ALSE_Video_us.pdf

You'll see page 5 how we connected an Omnivision camera to the
Nios Cyclone 1C20 board (in fact, to one if the SantaCruz extension,
the other being populated wit hthe lancelot Ramdac board.)
We used the PS2 interace of Lancelot for the I2C camera I/F.

It was really easy to set up this demonstrator.
(the Nios Cyclone board is an excellent platform)
-just don't forget to remove the Compact Flash card if you have one-

Bert Cuzeau