error with synthesis

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

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

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

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

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

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

Ralf Hildebrandt