need a cheap student edition FPGA

[Paul Jansen]

Sorry, I only check in here when I get really bored...

On 20 Jan 2007 10:43:16 -0800, "spectrallypure" <jorgelagos@gmail.com>
wrote:

Thanks so much for your reply, Paul. Here I add some information:

#1 - Why is one signal rising at 10264ns, and the other at 10263ns?
As I told before, i just can't figure out why there are differences in
the the timming of the signals. What puzzles me the most is that even
the signal SHIFTWR (which is generated by the testbench and has nothing
to do with the synthesized netlist whatsoever) changes its timming,
presenting its rising edge @ 8463ns and @ 8487ns, respectively. Clearly
this is unexpected behavior. I have no clue of what could be the reason
nor how to trace it back...

Cut down your test bench, don't instantiate your device, see if you
can confirm that SHIFTWR timing changes even without the synthesised
netlist. I doubt it, but you will need to fix this first if you're
right. If this really *is* the case, then there's almost certainly an
error in your testbench, which will probably be either a race
condition or a timing resolution problem. If it's not obvious (it
should be), manually check the timing on whatever logic drives
SHIFTWR. At some point, you should find that the numbers start
diverging between 5.8 and 6.2. This will be very tedious, but you
should manage it within a few hours.

You're in trouble if you don't understand race conditions. Google
comp.lang.verilog; you'll find a huge number of posts on it.

If this is a school project, as I suspect it is, then you should
probably give up. If it's a real project and you actually need a fix,
then I'm afraid that you're probably going to have to pay someone to
sort it out. Running PrimeTime and back-annotated ASIC timing sims is
not a job for beginners. Reply if you're interested, and I'll send you
my real email address.

In 5.8b I get a lot (nearly 50,000) of the following warnings:

# ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here-&gt: Failed to find matching specify timing constraint.

Rule #1 when you get an error message you don't understand: Google it.
Ther are some exact matches on your error message, which suggest that
you might not have recompiled your simulation libraries when changing
ModelSim versions. For ModelSim, you always need to recompile
libraries when changing major version numbers.

/PJ

 

[Jeremy Ralph]

Yep, gotta miss the tick attributes: 'left 'right 'high 'low 'range
'length

Don't miss is the super strict typing conversions for something like:

FOR i IN 0 TO N-1 LOOP
IF addr = STD_LOGIC_VECTOR(UNSIGNED(THE_BASE)+ i) THEN
...
END IF;
END IF;

vs.

for(i=0; i<N; i=i+1) begin
if( addr == THE_BASE + i) begin
...
end
end


---
PDTi [ http://www.productive-eda.com ]
SpectaReg -- Spec-down code and doc generation for register maps

 

[spectrallypure]

Thanks so much for your reply, Paul. Here I add some information:

#1 - Why is one signal rising at 10264ns, and the other at 10263ns?
As I told before, i just can't figure out why there are differences in

the the timming of the signals. What puzzles me the most is that even
the signal SHIFTWR (which is generated by the testbench and has nothing
to do with the synthesized netlist whatsoever) changes its timming,
presenting its rising edge @ 8463ns and @ 8487ns, respectively. Clearly
this is unexpected behavior. I have no clue of what could be the reason
nor how to trace it back...

#2 - Who wrote the relevant simulation models? Is there a race in them?
Please excuse me for not been that proficient... I don't understand

what do you mean by "race". But I can assure you that the **very same**
testbech is being used in both cases.

#3 - Why are you set at 1ns resolution? Is this a *very* slow chip? I
bet your sim models are set to 1ps; I'd suspect a rounding problem somewhere.
We also think the problem might have to do with this. I just set the

resolution to 1ns because that is the value of the resolution of the
SDF files, but I have experimented by changing this value and the
timing of the waveform changes A LOT. However, I haven't been able to
make the simulation give the expected results by tweaking this
parameter. The operating frequency of the design is 50MHz.

#4 - What do you get if you enable sdf warnings & errors?

In 5.8b I get a lot (nearly 50,000) of the following warnings:

# ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here-&gt: Failed to find matching specify timing constraint.

.... but the simulation works. On the other hand, in 6.2e, I get this
same error but a lot more times (something like three times more), I
additionally I get the following error (once again, I get it a lot of
times):

# ** Warning: (vsim-SDF-3261) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here-&gt: Failed to find matching specify module path.

I used the VERR command in the hope of finding an explanation for this
errors, but the descriptions of the errors give me no clue of what
could be their real cause.

THANKS A LOT ONCE AGAIN FOR YOUR HELP!!!

 

[Mike Treseler]

Jan Decaluwe wrote:
clked : process(clk)
variable cnt_v : count_t;
begin
if rising_edge(clk) then
cnt_v := cnt_v + 1; -- increment on rising edge
end if;
cnt <= cnt_v; -- wire assignment outside of clocked clause
end process clked;

I never used this template, but started to think about it because
of my work on MyHDL.

The question I have is: is there an equivalent (also synthesizable)
version for Verilog? At first sight, I don't think so, but perhaps
I'm wrong.

Mike Treseler wrote:

I can get the same register init, update, output
in one always block by doing something like this:

http://home.comcast.net/~mike_treseler/dup_reg_remove.v

The Quartus synthesis report and tech viewer get
the correct number of registers (5)

http://home.comcast.net/~mike_treseler/dup_reg_remove_tech.pdf

But I couldn't use my vhdl-style port assignment
trick to eliminate duplication in the verific RTL front end.

The verilog block uses no IF statement for the rising edge of the clock.
The rtl schematic shows 4 duplicated regs that do not
appear in the utilization report or tech schematic.

http://home.comcast.net/~mike_treseler/dup_reg_remove_rtl.pdf

This is really just a cosmetic problem since everything
after synthesis gets it right. The RTL schematic is generated
after analysis and rtl elaboration, but before fitting.
See http://www.verific.com/ for more information.

-- Mike Treseler

 

[comp.arch.fpga]

On 19 Sep., 17:51, Weng Tianxiang <wtx...@gmail.com> wrote:

Hi KS, jg,
"A synchronous or an asynchronous reset signal is vital, either with
clear routing or a hidden procedure within other initial procedures."

No, it is not.
See entries 2 and 3 on this page:
http://www.ics.uci.edu/~eppstein/pubs/misc.html

Kolja Sulimma

 

[Jonathan Bromley]

On Wed, 14 Mar 2007 19:45:17 +0000, Martin Vass
<mv1013@yahoo.com> wrote:

Martin,

My problem is that I don't actually understand what the rules are for
VHDL. There doesn't seem to be anywhere in the LRM that states
explicitly how objects are sized, extended, or truncated, or when,
during expression evaluation. Or have I just missed it? Can anyone
explain expression sizing, or point me to a reference?

Expression evaluation in VHDL is simply the execution of a
series of function calls - remember you can write your own
overloads for "+" and so on. Functions in VHDL are "dynamically
elaborated"; the consequence is that the return subtype can be
chosen by the function itself. Take, for example, (one of)
the RESIZE functions from numeric_std (this is only a
paraphrase, but it illustrates the point in question):

function RESIZE(V: unsigned; N: natural) return unsigned is
-- We can declare variables based on the parameters:
variable result: unsigned (N-1 downto 0);
begin
-- and we can determine the size of array parameters:
assert V'LENGTH >= N
report "RESIZE: result may be truncated"
severity WARNING;
....
return result;
end;

In a similar way, arithmetic functions such as "+" determine the
size of their results from the size of their arguments. For example,
NUMERIC_STD."+" [unsigned, unsigned] returns a result that is
the same width as the wider of its two arguments.

In Verilog-speak, you would say that all VHDL expressions are
"self-determined", but the determination is performed at
runtime by the arithmetic operators themselves, not at
compile/elaborate time.

The only operation you CAN'T overload (c'mon, what about it,
VHDL-200x?) is the assignment operator. When you finally
come to copy the result of the whole expression into its
target, there is a runtime check that the array shape matches.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Martin Vass]

On Thu, 15 Mar 2007 09:35:55 +0000, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

Hi Jonathan -

In Verilog-speak, you would say that all VHDL expressions are
"self-determined", but the determination is performed at
runtime by the arithmetic operators themselves, not at
compile/elaborate time.

I've been writing VHDL for over 10 years and this has never really
occurred to me, even though it seems obvious now that you've said it.
I guess I only had to think about this when writing the same code in
VHDL and Verilog.

This leads to another question - what is the point of the Verilog Way?
What advantage do the propagate up/propagate down again rules actually
give you? My immediate thoughts are (but my head is still spinning!) -

1) Everything is static, so the compiler can determine all object
sizes during compilation. This is safer than doing it at runtime; you
don't want to get an expression error after running for a couple of
days. But, hang on a minute - the Verilog rules also take into account
the *destination* size. So, there's no error checking anyway - you
can't tell if the expression has the 'wrong' size, because the size is
just adjusted to fit the destination. Ok, you can't get an error
flagged after 2 days running, but the downside is that your code is
just plain wrong anyway, and you may never find out.

2) It's presumably easier to write the Verilog compiler. But so what?
That doesn't help me.

So, what *is* the point of the Verilog sizing rules? Is it just a
badly designed language?

Thanks -

-MV

 

[Jonathan Bromley]

On Thu, 15 Mar 2007 11:00:44 +0000, Martin Vass
<mv1013@yahoo.com> wrote:

This leads to another question - what is the point of the Verilog Way?

I think you have somewhat answered your own question
For me, the one really big advantage is that Verilog makes it
very easy to capture carry/overflow information if I need it.
5bits<=4bits+4bits correctly captures the carry bit.
Doing the same in VHDL is irksome.

Ok, you can't get an error
flagged after 2 days running, but the downside is that your code is
just plain wrong anyway, and you may never find out.

As we tend to say on courses:
Verilog: You know best.
VHDL: Nanny knows best.

As I tend to say in private:
Verilog -> West Coast hippydom
VHDL -> European bureaucracy

Take your pick, according to taste.

I have to admit that I find it VERY frustrating that I can't overload
the assignment operators in VHDL. I'm very glad to be told
about my own stupidity, but I also would very much like to be
able to define types that have automatic rounding and/or
truncation behaviour when I want it. I fell foul of this when
writing a fixed-point package for VHDL - which, in other
respects, was a rather nice example of why VHDL's way is
so much more flexible; arithmetic operators can "know about"
the attributes of their operands in an intelligent way. But
I could never find a way to prevent idiots (i.e. me) from
copying a fixed-point number with one scaling on to a
fixed-point variable with the same width but different
scaling, thereby trashing the numeric value. Overloading
of the assignment operator would have permitted me to
build mathematically-reasonable, synthesisable rounding
and overflow behaviour into such assignments.

David Bishop, writing the package that's now part of
VHDL-200x, had more staying power than I did

2) It's presumably easier to write the Verilog compiler

I am not at all sure about that. And don't even ask about
SystemVerilog.

So, what *is* the point of the Verilog sizing rules? Is it just a
badly designed language?

No, it's not badly designed; it just chooses a set of compromises
that typically seem rather bizarre to the averagely thoughtful
computer-science-literate grunt like you or me. In fairness,
as I've grown to know Verilog more intimately I have gained
considerable respect for its far-sighted design and its (albeit
often counterintuitive) internal consistency.

Personal prejudice only: The arithmetic sizing/signing rules
seem to me to be an ill-advised attempt to make simple
things really easy, with the inevitable side-effect that
complicated things are somewhere on the scale of
difficult to impossible. VHDL goes too far the other way:
in an attempt to be elegant and consistent, it makes
it unpleasantly hard to do some rather simple things,
whilst making it possible (it's never easy) to do the
really hard stuff.

It's not often that I draw attention to the own-opinions-only
disclaimer in my sig, but this is definitely such a moment!
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[glen herrmannsfeldt]

Marwan wrote:

I will be coding in verilog. There will not by a host of functions
for me to call, so functions like eigenvalues and eigenvectors will
need to be coded explicitly.

I have added comp.arch.fpga and comp.lang.verilog, where someone
may have worked on similar problems.

Basically, my issue, is when I try to directly translate the TQLI.F OR
TQLI.C code to matlab, it just will not work for reason totally beyond
me...

Someone else can help figure out Matlab. I will note that the hardware
implementations of algorithms tend to be somewhat different from the
usual software implementations, but you should understand the software
first. Matlab seems to me a fine way to do that.

I recommend systolic arrays for hardware matrix processing. The usual
reason for wanting a hardware implementation is speed, and systolic
arrays usually work pretty well for that. Also, they scale with problem
size when needed. About how big are your matrices and how fast do you
need the results?

-- glen

 

On Jun 7, 3:54 pm, Eric Smith <e...@brouhaha.com> wrote:

willwestw...@gmail.com writes:
I hope I explained ok here. I'm having trouble putting this behavior
into codes in VHDL. Someone has any idea?

How would you design it with logic gates (and flip-flops, if required)?

Once you know that, you can just do the same thing in VHDL.

Yes you can do it in logic gates, but I want behavior modeling. If
using FF and logic gates, it would make this totally a netlist
coding.

Here is the Requset, Reset, and Acknowledge again:

Request(0 to 3): 0000 1010 0110 1101 0010 1001 0001 1000 1011 1011
1000 0101 1001
Reset:
HHHHLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLHHHHLLLLLLLLLLLLLLLLLLLLL
Ack(0 to 3): 0000 1000 0010 0100 0010 1000 0001 1000 0000 1000
1000 0100 0001

I also plan to convert this code into Verilog, C or C++ later on, so
if you have algorithm or codes in those languages, it's fine too.

 

[jtw]

Eric asked 'how' you would do it with logic gates. Once you know that, then
the question is to how to describe that behavior in VHDL, verilog, c, c++...

If you can write behavioral descriptions for your FFs and logic gates in
VHDL (etc.), you have a solution to your problem.

If you can abstract the sequence to a state machine, and code that in VHDL
(etc.), you have another solution to your problem.

If you understand what it is you really want to do, and appropriately
describe and code it, you are likely to have a better solution to your
problem. A better solution, because it will respond to other sequences the
way you intend, rather than just matching the small set of stimulus-response
vectors described. There will be many solutions that will pass the test
vectors, but will not 'do the right thing' in general.

JTW

<willwestward@gmail.com> wrote in message
news:1181261769.985939.84080@x35g2000prf.googlegroups.com...

On Jun 7, 3:54 pm, Eric Smith <e...@brouhaha.com> wrote:
willwestw...@gmail.com writes:
I hope I explained ok here. I'm having trouble putting this behavior
into codes in VHDL. Someone has any idea?

How would you design it with logic gates (and flip-flops, if required)?

Once you know that, you can just do the same thing in VHDL.

Yes you can do it in logic gates, but I want behavior modeling. If
using FF and logic gates, it would make this totally a netlist
coding.

Here is the Requset, Reset, and Acknowledge again:

Request(0 to 3): 0000 1010 0110 1101 0010 1001 0001 1000 1011 1011
1000 0101 1001
Reset:
HHHHLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLHHHHLLLLLLLLLLLLLLLLLLLLL
Ack(0 to 3): 0000 1000 0010 0100 0010 1000 0001 1000 0000 1000
1000 0100 0001

I also plan to convert this code into Verilog, C or C++ later on, so
if you have algorithm or codes in those languages, it's fine too.

 

On Jun 7, 11:07 pm, "jtw" <wrightjt @hotmail.invalid> wrote:

Eric asked 'how' you would do it with logic gates. Once you know that, then
the question is to how to describe that behavior in VHDL, verilog, c, c++...

If you can write behavioral descriptions for your FFs and logic gates in
VHDL (etc.), you have a solution to your problem.

If you can abstract the sequence to a state machine, and code that in VHDL
(etc.), you have another solution to your problem.

If you understand what it is you really want to do, and appropriately
describe and code it, you are likely to have a better solution to your
problem. A better solution, because it will respond to other sequences the
way you intend, rather than just matching the small set of stimulus-response
vectors described. There will be many solutions that will pass the test
vectors, but will not 'do the right thing' in general.

JTW

willwestw...@gmail.com> wrote in message

news:1181261769.985939.84080@x35g2000prf.googlegroups.com...



On Jun 7, 3:54 pm, Eric Smith <e...@brouhaha.com> wrote:
willwestw...@gmail.com writes:
I hope I explained ok here. I'm having trouble putting this behavior
into codes in VHDL. Someone has any idea?

How would you design it with logic gates (and flip-flops, if required)?

Once you know that, you can just do the same thing in VHDL.

Yes you can do it in logic gates, but I want behavior modeling. If
using FF and logic gates, it would make this totally a netlist
coding.

Here is the Requset, Reset, and Acknowledge again:

Request(0 to 3): 0000 1010 0110 1101 0010 1001 0001 1000 1011 1011
1000 0101 1001
Reset:
HHHHLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLHHHHLLLLLLLLLLLLLLLLLLLLL
Ack(0 to 3): 0000 1000 0010 0100 0010 1000 0001 1000 0000 1000
1000 0100 0001

I also plan to convert this code into Verilog, C or C++ later on, so
if you have algorithm or codes in those languages, it's fine too.- Hide quoted text -

- Show quoted text -

I will describle the behavior again and hopefully someone can help.

The arbiter is 4 bits input and output but it can only allow 1 bit to
go high at a time on the ouput (i.e. 0010). It compares the input,
current request (C_R) with previous request (P_R) in memory to
generate output, acknowledge (ACK). If a bit on P_R is also on the
C_R, the acknowledge is not changed because it thinks the P_R is
requested on C_R again. If the C_R bit was also in the P_R and that
bit didn't get the acknowledge bit last time, it will get it this
time. There's also a reset line which sets all the output to 0000 when
it's high.

Here is a sample input and output when reset is low.

C_R(0 to 3): 0000 1010 0110 1101 0010 1001 0001 1000 1011 1011
ACK(0 to 3): 0000 1000 0010 0100 0010 1000 0001 1000 0000 1000

I understand the behavior but just can't seem to figure out the coding
style.

 

[Walter Roberson]

In article <1181337745.613125.274670@r19g2000prf.googlegroups.com>,
<willwestward@gmail.com> wrote:

I will describle the behavior again and hopefully someone can help.

The arbiter is 4 bits input and output but it can only allow 1 bit to
go high at a time on the ouput (i.e. 0010). It compares the input,
current request (C_R) with previous request (P_R) in memory to
generate output, acknowledge (ACK). If a bit on P_R is also on the
C_R, the acknowledge is not changed because it thinks the P_R is
requested on C_R again. If the C_R bit was also in the P_R and that
bit didn't get the acknowledge bit last time, it will get it this
time.

There's a problem in that specification. If there are three simultaneous
requests, one of them will be granted the first time, leaving two
bits in P_R that are still present in the next cycle's C_R.
The first sentance allowed only one output to go high (be acknowledged),
but the last sentance I quoted above, about "and that bit didn't
get the acknowledge bit last time", requires that -both- of the two
old requests be acknowledged in the current cycle.

To resolve this, the spec would have to be rewritten to something
similar to,
"If there are C_R bits that were also in the P_R and those bits
did not get the acknowledge bit last time, one of them will get
it this time."

But even this has problems, because it allows for indefinite
postponement. Suppose A, B, C have simultaneous requests. One
of them is granted, say A. Suppose A re-requests before the next
sampling, so at the time of the next sampling A is active because
of the re-request and B and C are still active because they have
not been acknowledged. This time, A will not be the one serviced
because of the "and that bit didn't get the acknowledge bit last time"
clause (which imparts some fairness), so one of B or C will be served,
say B, leaving A and C active. The next cycle, A and C (at least)
are still waiting from and were waiting in the previous cycle, and
neither were granted in the previous cycle, so by the clause above,
both of them are eligable for service this time. Which one will be
chosen? The specs don't say, so although serving C would be fairest
because it has been waiting longest, it could be A that is served
this time. If B had re-requested as well during the same cycle,
then again the next cycle around you have two requests that
hadn't been served the previous time, and again it might not be C
that you choose to serve. Repeat indefinitely and you can see that
C might never be served if the ACKs toggle between A and B.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

 

On Jun 7, 5:16 pm, willwestw...@gmail.com wrote:

On Jun 7, 3:54 pm, Eric Smith <e...@brouhaha.com> wrote:

willwestw...@gmail.com writes:
I hope I explained ok here. I'm having trouble putting this behavior
into codes in VHDL. Someone has any idea?

How would you design it with logic gates (and flip-flops, if required)?

Once you know that, you can just do the same thing in VHDL.

Yes you can do it in logic gates, but I want behavior modeling. If
using FF and logic gates, it would make this totally a netlist
coding.

Here is the Requset, Reset, and Acknowledge again:

Request(0 to 3): 0000 1010 0110 1101 0010 1001 0001 1000 1011 1011
1000 0101 1001
Reset:
HHHHLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLHHHHLLLLLLLLLLLLLLLLLLLLL
Ack(0 to 3): 0000 1000 0010 0100 0010 1000 0001 1000 0000 1000
1000 0100 0001

I also plan to convert this code into Verilog, C or C++ later on, so
if you have algorithm or codes in those languages, it's fine too.

Here is my code. There's a problem, the acknowledge only changes on
reset='1' and request='1111'. How can I fix this so it will give the
right output like the behavior given earlier?

LIBRARY IEEE;
USE IEEE.std_logic_1164.ALL;

entity rrarbiter is
port ( request : in std_logic_vector(0 to 3);
reset : in std_logic;
acknowledge : inout std_logic_vector(0 to 3)
);
end entity rrarbiter;

architecture rrobin_behave of rrarbiter is

signal reg_ack: std_logic_vector(0 to 3); --:=
std_logic_vector'(B"0000");

begin
behavior: process(reset, request)
begin
if reset = '1' then
acknowledge <= std_logic_vector'("0000");

------IF BIT IN ACKNOWLEDGE IS NOT IN REQUEST THEN
acknowledge<=MSB SET OF acknowledge----

elsif NOT(request(0)=reg_ack(0) or
request(1)=reg_ack(1) or request(2)=reg_ack(2) or
request(3)=reg_ack(3)) then
if request(0)='1' then
acknowledge<= std_logic_vector'("1000");

elsif request(1)='1' then
acknowledge<= std_logic_vector'("0100");

elsif request(2)='1' then
acknowledge<= std_logic_vector'("0010");

elsif request(3)='1' then
acknowledge<= std_logic_vector'("0001");

end if;

-----A BIT IN REQUEST IS ALSO IN acknowledge THEN
acknowledge<=REG_ACK----
elsif (request(0)=reg_ack(0) or
request(1)=reg_ack(1) or request(2)=reg_ack(2) or
request(3)=reg_ack(3)) then

if request(0)='1' and reg_ack(0)='1'then
acknowledge <=
std_logic_vector'("1000");

elsif request(1)='1' and reg_ack(1)='1' then
acknowledge<= std_logic_vector'("0100");

elsif request(2)='1' and reg_ack(2)='1' then
acknowledge<= std_logic_vector'("0010");

elsif request(3)='1' and reg_ack(3)='1' then
acknowledge<= std_logic_vector'("0001");

end if;

end if;

end process;

reg_ack <= acknowledge;

end rrobin_behave;

 

[mk]

Hi,
I updated the GTKWave for Win32 port I am maintaining. It's at 3.1.0
which supports reload now.

http://www.dspia.com/gtkwave.html

 

[Weng Tianxiang]

Hi,
OK, a state machine is defined by standard one process or two
processes in VHDL.

There is no short cut.

It can be implemented in anywhere in a design and where the state
machine is located is decided by compilers and beyond the interest of
this topics.

I have to expand the guess to include Verilog group people, because
VHDL people may have no chance to do the designs.

I may know the answer. The final result may surprise everyone who
gives a guess.

Thank you.

Weng

 

[Shannon]

On Sep 17, 11:03 am, Weng Tianxiang <wtx...@gmail.com> wrote:

Hi,
OK, a state machine is defined by standard one process or two
processes in VHDL.

There is no short cut.

It can be implemented in anywhere in a design and where the state
machine is located is decided by compilers and beyond the interest of
this topics.

I have to expand the guess to include Verilog group people, because
VHDL people may have no chance to do the designs.

I may know the answer. The final result may surprise everyone who
gives a guess.

Thank you.

Weng

Ok Weng,

Since you obviously don't understand the questions the people who have
responded...

let's define a state machine as a process or processes that have a
classic "state variable". Sigh...
Furthermore since you rejected the concept that our guess should not
be based on what is "possible" but instead on what has actually been
done...

I will answer you question that ***I*** have created the design that
has the most classic state machines in it. And since you know the
answer you will tell ***me** how many I had to use. Hint: It's more
than 27 and I know you ***will*** be surprised by the answer!

Shannon

 

[Weng Tianxiang]

On Sep 17, 11:14 am, Shannon <sgo...@sbcglobal.net> wrote:

On Sep 17, 11:03 am, Weng Tianxiang <wtx...@gmail.com> wrote:





Hi,
OK, a state machine is defined by standard one process or two
processes in VHDL.

There is no short cut.

It can be implemented in anywhere in a design and where the state
machine is located is decided by compilers and beyond the interest of
this topics.

I have to expand the guess to include Verilog group people, because
VHDL people may have no chance to do the designs.

I may know the answer. The final result may surprise everyone who
gives a guess.

Thank you.

Weng

Ok Weng,

Since you obviously don't understand the questions the people who have
responded...

let's define a state machine as a process or processes that have a
classic "state variable". Sigh...
Furthermore since you rejected the concept that our guess should not
be based on what is "possible" but instead on what has actually been
done...

I will answer you question that ***I*** have created the design that
has the most classic state machines in it. And since you know the
answer you will tell ***me** how many I had to use. Hint: It's more
than 27 and I know you ***will*** be surprised by the answer!

Shannon- Hide quoted text -

- Show quoted text -

Hi Shannon,
"let's define a state machine as a process or processes that have a
classic "state variable". Sigh... "

I don't write code for them, but you can expect how people in VHDL
define a state machine: by using type (...) as I like to do, but not
necessarily.

I cannot guess the largest number of state machines you have written
for a design, but I know clearly the number of state machines you may
have written in a design is less than 100k. Any question?

Weng

 

[Weng Tianxiang]

Hi Glen,
There is a theory behind to resolve the problem.

A state machine can be defined in such a scentific way:
1. All states in a state machine have their own names;
2. All states in a state machine are mutually exclusive;
3. Only one state is active in any cycle;
4. The number of states in a state machine must be 2 or more;
5. There must have either asynchronous or a synchronous reset signal
for the state machine and after their assertion, the state machine
must be in initial state.

I guess there are less than 27 engineers in the world who have the
experiences to do the designs.

If your experiences are fully in FPGA and VHDL worlds, you may never
have a chance to get a right guess with any possible wildest
imagination,

Any more question?

Weng

 

[Shannon]

On Sep 17, 11:39 am, Weng Tianxiang <wtx...@gmail.com> wrote:

I know clearly the number of state machines you may
have written in a design is less than 100k. Any question?

Ok, so we have your mysterious answer then. The most state machines
is 100k. Ok.. ho hum. So? Is there a point to this drivel?

Shannon