error with synthesis

[Gandalf]

this is my FSM:
http://pastebot.perl.it/cgi-bin/PasteIt.pl?rm=showpaste;id=532
and this is the results of the synthesis:
http://pastebot.perl.it/cgi-bin/PasteIt.pl?rm=showpaste;id=533

where i'm wrong?

 

[Mike Treseler]

Gandalf wrote:

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

Asynchronous feedback.
Synch it up. Run a sim.

-- Mike Treseler

 

[Gandalf]

http://pastebot.perl.it/cgi-bin/PasteIt.pl?rm=showpaste;id=534

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

 

[Ralf Hildebrandt]

Gandalf wrote:

http://pastebot.perl.it/cgi-bin/PasteIt.pl?rm=showpaste;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

 

[Mike Treseler]

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

 

[Ralf Hildebrandt]

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