«

this is my FSM:
http://pastebot.perl.it/cgi-bin/Past...owpaste;id=532
and this is the results of the synthesis:
http://pastebot.perl.it/cgi-bin/Past...owpaste;id=533

where i'm wrong?

Gandalf wrote:

> http://pastebot.perl.it/cgi-bin/Past...owpaste;id=532
> and this is the results of the synthesis:
> http://pastebot.perl.it/cgi-bin/Past...owpaste;id=533
> where i'm wrong?

Asynchronous feedback.
Synch it up. Run a sim.

-- Mike Treseler

http://pastebot.perl.it/cgi-bin/Past...owpaste;id=534

ERROR:Xst:827 - c:/Xilinx/bin/RFID/msf.vhd line 31: Signal min cannot be
synthesized, bad synchronous description.

Gandalf wrote:

> http://pastebot.perl.it/cgi-bin/Past...owpaste;id=534
>
> ERROR:Xst:827 - c:/Xilinx/bin/RFID/msf.vhd line 31: Signal min cannot be
> synthesized, bad synchronous description.

If you don't read my messages you will never get a solution. Again:

process(reset,clk)
begin
-- nothing here
if (reset='1') then
-- do some reset
elsif rising_edge(clk) then
-- do something
end if;
-- nothing here
end process;

Although it may be possible to put code into the locations that I have
marked with "nothing here", synthesis tools may refuse to work with it.


Mike Treseler often suggests a single process statement and variables as
a good syle of coding, but especially for a beginner it may be also a
good idea to separate the 3 basic pieces you have: combinational logic,
latches and flipflops. Make a single process for every piece you have.
This makes it more clear what you are modeling. This is very low-level
and hardware-oriented design. If you get more experienced, Mike's coding
style is an option to write clean and compressed code, which is helpful
for larger projects.

Ralf

Ralf Hildebrandt wrote:

> Mike Treseler often suggests a single process statement and variables as
> a good syle of coding, but especially for a beginner it may be also a
> good idea to separate the 3 basic pieces you have: combinational logic,
> latches and flipflops.

I see combinational processes as an advanced topic.

A beginner is just a likely to have success at writing
three procedures for a canned synchronous template,
and quickly seeing the results on an RTL viewer.
Since Gandalf is targeting an fpga rich in flops,
what is the advantage of purposely inferring latches?

> Make a single process for every piece you have.
> This makes it more clear what you are modeling.

Gandalf is modeling a controller, not gates and flops.
All that is needed is a clean logic description and simulation.

> This is very low-level
> and hardware-oriented design. If you get more experienced, Mike's coding
> style is an option to write clean and compressed code, which is helpful
> for larger projects.

And small ones too

-- Mike Treseler

Mike Treseler wrote:

>> Mike Treseler often suggests a single process statement and variables
>> as a good syle of coding, but especially for a beginner it may be also
>> a good idea to separate the 3 basic pieces you have: combinational
>> logic, latches and flipflops.
>
> I see combinational processes as an advanced topic.

I am surprised. For me it is something very obvious, if I have some
input signals ans some output signals and no storage elements between them.


> Since Gandalf is targeting an fpga rich in flops,
> what is the advantage of purposely inferring latches?

I never recommended to use latches for that example. I just wanted to
make it clear, what it means to model hardware. And as this result I
wanted to point out, that there are only these 3 pieces of hardware
available.


>> Make a single process for every piece you have. This makes it more
>> clear what you are modeling.
>
> Gandalf is modeling a controller, not gates and flops.
> All that is needed is a clean logic description and simulation.

For me hardware modeling means _everytime_ modeling gates and flops. I
can do it at a very low level (down to making synthesis for my own, what
is obviously not a good design practice) and if I know what I am doing I
can do it at higher level of abstraction.
I always (try to) have in mind, what kind of hardware I model, if I code
something.
Especially beginners tend to write VHDL like writing software if they do
it at a very high level of abstraction. For the first steps I think it
is a good idea make simple constructs, that easily show, what hardware
will be the result.


>> This is very low-level and hardware-oriented design. If you get more
>> experienced, Mike's coding style is an option to write clean and
>> compressed code, which is helpful for larger projects.
>
> And small ones too

Yes, you are right.

Ralf