test pattern
by martstev » Fri, 16 Jan 2009 01:33:10 GMT
I am still learning VHDL and need some help please! This is what i
have
clk: in std_logic;
data : in std_logic_vector ( 3 downto 0);
data_out: out std_logic_vector (3 downto 0);
clock is running at 20 MHz and data is synchronized with the clock.
if data is in this order "1111", "1010" "1111", "xxxx" than, data out
is "xxxx". So basically I have to look at the data pattern back to
back and then activate my output..if pattern matches, "1111", "0xa"
and "0xb", output is good to go, else have just wait...
I was thinking to have data stored in FIFO and the have some sort of
state machine to look for test pattern..but not sure if that's the
best of doing this...any advice???
Re: test pattern
by LittleAlex » Fri, 16 Jan 2009 02:19:17 GMT
If I understand your question, you are looking for the sequence 'F'
'A' 'B', and if found, output the data.
This is a classic state-machine learning/homework study exercise.
There is no need to store the codes while waiting for the pattern.
When you get to the 'found' state, you know what the 3 previous codes
are.
That should be enough to get you started.
AL
Similar Threads:
1.Lisp pattern matching libraries & difference between unification and pattern matching
2.Lisp pattern matching libraries & difference between unification and pattern matching
3.Lisp pattern matching libraries & difference between unification and pattern matching
I want to make small embedded prolog with modular design so I'm
shopping for an existing pattern matching library. If anybody has
some experience using them I would appreciate if you share it.
I started first with cl-unification, because of it's high quality
documentation, that would be even better if Marco gave some examples
of using match & matching macros, and especially what's the idiom
of writing something like below in home made libraries:
(match '(p a b c a) '(p ?x ?y c ?x))
What's the difference between unification & pattern matching?
Especially with examples what could be done with unification that
can't be done with pattern matching or vice versa?
thanks
Slobodan
4.Call oddities: &Test() vs &Test vs Test
Hello,
There are some call oddities in both languages: Delphi and C.
The purpose of a language is to tell the computer what to do... but ofcourse
a language is also for us humans to understand what is written/ment.
Therefore it would be a nobble cause to try and make the language as clearly
as possible.
I now present to you some "cases" where both languages Delphi and C fail in
this regard:
Case 1 (Delphi):
IdentifierA = IdentifierB;
From this single line of code it cannot be said if IdentifierB is a field or
a routine call yet it's still allowed to be written in Delphi. Correct
translation from Delphi to C/C++ without more information, is therefore not
possible.
Case 2 (C):
IdentifierB;
From this single line of code it cannot be said if IdentifierB is a field or
a routine yet it's still allowed to be written in C. If IdentiferB is a
routine then no call will happen, which is inconsistent with Delphi and
could lead to bugs when translating from Delphi to C/C++. Correct
translation from Delphi to C/C++ without more information, is therefore not
possible.
Case 3 (Delphi):
if (Identifier) then
From this single line of code it cannot be said if Identifier is a field or
a routine call yet it's still allowed to be written in Delphi. Correct
translation from Delphi to C/C++ without more information, is therefore not
possible.
The question is can the situation be improved ?
A possible solution could be to make the () for routine calls mandatory.
Also for acquiring a pointer to a routine the () could be mandatory.
Instead of writing:
IdentifierA = &IdentifierB;
It would become:
IdentifierA = &IdentifierB();
Which would return the address of the routine IdentifierB.
IdentifierA = &IdentifierB()();
Would return the address of the second routine which is being called by the
function pointer returned by the first routine.
(Note: Delphi does not have this functionality: Calling a returned function
pointer immediatly).
Currently the situation is reserved to acquire a pointer to a routine in C
the () must not be written:
IdentifierA = &Identifier;
The question is:
Would any functionality in C be lost if this is changed to described as
above:
IdentifierA = &Identifier();
?
Bye,
Skybuck.
5.Testing an assembler using TSOEXEC TEST and breakpoint
Hello,
I'm trying to test and debug an assembler(370) program and i've been
told that i should use TSOEXEC TEST command and by setting a break
point.
Can someone help me.
Thanks,
John
6. test test
7. OVI test and Compliance Commitee test suite......
8. Cool test bench generator for testing some devices which describe by Verilog or VHDL