error with synthesis

Discussion in 'VHDL' started by Gandalf, May 25, 2006.

  1. Gandalf

    Gandalf Guest

    Gandalf, May 25, 2006
    #1
    1. Advertising

  2. Mike Treseler, May 25, 2006
    #2
    1. Advertising

  3. Gandalf

    Gandalf Guest

    Gandalf, May 25, 2006
    #3
  4. 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
     
    Ralf Hildebrandt, May 26, 2006
    #4
  5. 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, May 26, 2006
    #5
  6. 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, May 26, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. walala
    Replies:
    4
    Views:
    2,175
    Ralf Hildebrandt
    Sep 8, 2003
  2. walala
    Replies:
    4
    Views:
    1,271
    Technology Consultant
    Sep 9, 2003
  3. rajan

    synthesis error with DC

    rajan, Aug 30, 2004, in forum: VHDL
    Replies:
    3
    Views:
    1,755
    Metin Yerlikaya
    Sep 1, 2004
  4. lomtik
    Replies:
    5
    Views:
    440
    lomtik
    Dec 20, 2004
  5. fpgaengineer
    Replies:
    7
    Views:
    3,926
    Mike Treseler
    Mar 12, 2007
Loading...

Share This Page