Wait-for / until won't work ? Xilinx Spartan 3

Hello.
I'm new to FPGA desing, so could you please help me with this little  =

problem.
To run my sensor I must have some delays in communication with it  =

(DS18B20).

When I put this into my code
"wait for 500 us;"

I get --> parse error, unexpected WAIT

I tried to desing a down counter with set and reset, and used wait until=
  =

"count=3D0" but I get the same error.

Here is a simple example.

****************
architecture Behavioral of ispis is
begin	=


DQ <=3D '0';
wait for 500 us;

End Behavioral;
****************

How to program delays for my code if "wait" wont work? Maybe I'm using i=
t  =

in the wrong way? Thanks.

On 2007-05-03, Andy <jonesandy@comcast.net> wrote:
> You cannot wait for TIME in synthesizable code.  You can wait until
> rising_edge(clk)! Not usually the best coding style, but it can be
> done and is accepted by most synthesis tools.

I was also of the opinion that it wasn't a very good coding style but
after a couple of years of basic VHDL teaching I think it is actually
better to say that a sequential process looks like this:

  process 
  begin  -- process
    wait until rising_edge(clk);
    -- Some code...
  end process;


The "standard" alternative is this:

  process (clk)
  begin  -- process
    if clk'event and clk = '1' then  -- rising clock edge
	-- Some code...      
    end if;
  end process;



The problem with the second one is that first time students are likely
to produce something like:

  process (clk)
  begin  -- process
    if rst = '1' then
      foo <= (others => '0');
    end if;

    if clk'event and clk = '1' then  -- rising clock edge
      -- Some code...
    else
      somethingelse <= '0';
    end if;
  end process;


This kind of unholy synchronous/asynchronous process will usually be
accepted by the synthesis tool and work badly, if at all whereas it
is not possible to create any asynchronous behaviour if the first version
is used. (Or rather, synthesis tools will not allow it)


So I'd summarize the advantages/disadvantages like this:

wait until rising_edge(clk):
   + No sensitivity list to worry about
   + No asynchronous behaviour to worry about
   - Might lead students to use wait in ways they shouldn't

if rising_edge(clk) then:
   + No wait statement
   + A bit more general
   - Fully legal to create asynchronous logic, including latches
   - Sensitivity list to worry about



/Andreas

On 3 Mai, 13:43, NA <madid87-MAK...@yahoo.com> wrote:
> Hello.
> I'm new to FPGA desing, so could you please help me with this little  
> problem.
> To run my sensor I must have some delays in communication with it  
> (DS18B20).
>
> When I put this into my code
> "wait for 500 us;"
>
> I get --> parse error, unexpected WAIT
>
> I tried to desing a down counter with set and reset, and used wait until  
> "count=0" but I get the same error.
>
> Here is a simple example.
>
> ****************
> architecture Behavioral of ispis is
> begin  
>
> DQ <= '0';
> wait for 500 us;
>
> End Behavioral;
> ****************
>
> How to program delays for my code if "wait" wont work? Maybe I'm using it  
> in the wrong way? Thanks.

wait can only be used in testbenches.
not when targetting FPGA design.

FPGA has no idea what 500 us is, you need to understand this first,
then only you can have success with synthesis

Antti

On Thu, 03 May 2007 13:59:30 +0200, Antti <Antti.Lukats@xilant.com> wrot=
e:
> wait can only be used in testbenches.
> not when targetting FPGA design.
> FPGA has no idea what 500 us is, you need to understand this first,
> then only you can have success with synthesis
> Antti

Thank you very much.
Let's say I try to do something like this

**************************************
signal CTR   : STD_LOGIC_VECTOR (15 downto 0) :=3D "000000000...";

process(CLKIN)
  begin
  if CLKIN'event and CLKIN=3D'1' then
     CTR <=3D CTR - "0000000000000001";
	 end if;
  end process;

  DQ <=3D '0';
  CTR <=3D "0110010000101";  -- some delay value at 50MHz clock speed
  wait until CTR =3D '0';
**************************************

Again,  parse error, unexpected WAIT

If some could just show me the simplest way do do a little delay in  =

communication when I need one I would be able do to my project. It's a  =

study project, my mentor has no time to help me :-(

On 3 Mai, 14:16, NA <madid87-MAK...@yahoo.com> wrote:
> On Thu, 03 May 2007 13:59:30 +0200, Antti <Antti.Luk...@xilant.com> wrote:
> > wait can only be used in testbenches.
> > not when targetting FPGA design.
> > FPGA has no idea what 500 us is, you need to understand this first,
> > then only you can have success with synthesis
> > Antti
>
> Thank you very much.
> Let's say I try to do something like this
>
> **************************************
> signal CTR   : STD_LOGIC_VECTOR (15 downto 0) := "000000000...";
>
> process(CLKIN)
>   begin
>   if CLKIN'event and CLKIN='1' then
>      CTR <= CTR - "0000000000000001";
>          end if;
>   end process;
>
>   DQ <= '0';
>   CTR <= "0110010000101";  -- some delay value at 50MHz clock speed
>   wait until CTR = '0';
> **************************************
>
> Again,  parse error, unexpected WAIT
>
> If some could just show me the simplest way do do a little delay in  
> communication when I need one I would be able do to my project. It's a  
> study project, my mentor has no time to help me :-(

YOU CAN NOT USE "wait" statement for FPGA design.
YOU CAN NOT USE "wait" statement for FPGA design.
YOU CAN NOT USE "wait" statement for FPGA design.
YOU CAN NOT USE "wait" statement for FPGA design.
YOU CAN NOT USE "wait" statement for FPGA design.

read the above 5 times, and try again.

Antti

On Thu, 03 May 2007 14:22:04 +0200, Antti <Antti.Lukats@xilant.com> wrote:
> YOU CAN NOT USE "wait" statement for FPGA design.
> read the above 5 times, and try again.
> Antti

So you can copy-paste that 5 times but you can't give a helpful suggestion.
Thanks anyway.

On 2007-05-03, Ben Jones <ben.jones@xilinx.com> wrote:
> Those are by no means the only options. For example:
>
>   process (clock)
>   begin
>     if rising_edge(clock) then
>
>       -- Put your RTL code in here
>
>       if reset = '1' then
>
>         -- Put the code that resets any signals that need resetting in here
>
>       end if;
>
>     end if;
>   end process;
>
> Pros/cons:
>   - ???

- First time students will disobey the template and create
  unholy processes which works in modelsim (most of the time)
  but has no hope of ever working in a CPLD or FPGA :/
  If the wait until rising_edge(clock) is used instead, the
  tool will not accept anything which isn't synchronous no
  matter how much you try.

Sure, we could (and of course _do_) say "Don't do that!", but
even so I don't think it is an exaggaration to say that at
least one group disobeys the template on every lab, leading to
much frustration (for them :)). In their defense, they usually
come from a programming background and they also have
faith that a design that works in ModelSim will work in
hardware. If they were experts in digital design they wouldn't
have to take this course after all :)

Anyway, this is a relatively minor point, what would be much
better in a teaching situation is if XST could be configured
to be more strict in what it accepts.

For example, I would like to be able to say that
latches should not be allowed to be inferred at all in a design
(unless they are instantiated manually). Please, implement
always_ff/_latch/_comb from SystemVerilog ASAP :)
(IIRC there is equivalent functionality in VHDL 2006 but I don't
remember the details right now.)

Something which also would be nice is the ability to flag
suspicious combinations of asynchronous/synchronous processes
as errors. While it might be ok with an asynchronous reset it is
probably not ok if that asynchronous reset is generated combinatorially
in the same process as in:

   if bar="1001" then
      foo <= (others => '0');
   else if rising_edge(clk) then
      foo <= foo + x;
      ...


/Andreas

On 3 Mai, 14:22, Antti <Antti.Luk...@xilant.com> wrote:
> > **************************************
> > signal CTR   : STD_LOGIC_VECTOR (15 downto 0) := "000000000...";
>
> > process(CLKIN)
> >   begin
> >   if CLKIN'event and CLKIN='1' then
> >      CTR <= CTR - "0000000000000001";
> >          end if;
> >   end process;
>
> >   DQ <= '0';
> >   CTR <= "0110010000101";  -- some delay value at 50MHz clock speed
> >   wait until CTR = '0';
> > **************************************
>
> > Again,  parse error, unexpected WAIT
>
> > If some could just show me the simplest way do do a little delay in
> > communication when I need one I would be able do to my project. It's a
> > study project, my mentor has no time to help me :-(
>
> YOU CAN NOT USE "wait" statement for FPGA design.

Indeed, you can't. But I consider this to be a deficiency of the
tools. The above example is
easy to synthesize. There have been academic proofs of concept decades
ago.
Essentially you only need to add a state per wait statement.

Kolja Sulimma

On May 3, 7:22 am, Antti <Antti.Luk...@xilant.com> wrote:
> YOU CAN NOT USE "wait" statement for FPGA design.
> YOU CAN NOT USE "wait" statement for FPGA design.
> YOU CAN NOT USE "wait" statement for FPGA design.
> YOU CAN NOT USE "wait" statement for FPGA design.
> YOU CAN NOT USE "wait" statement for FPGA design.
>
> read the above 5 times, and try again.
>
> Antti

WRONG!

You cannot wait for TIME in synthesizable code.  You can wait until
rising_edge(clk)! Not usually the best coding style, but it can be
done and is accepted by most synthesis tools.

NA,

You can wait for time in a testbench (simulation code written to test
the synthesizable FPGA design code).

An additional problem is that the wait statement is a sequential
statement (inside a process), but it is being used in a concurrent
context (outside a process). That won't work for simulation or
synthesis.

Concurrent assignment statements are each their own little implied
process, running in parallel with other concurrent assignment
statements and processes. The order in which they appear in the code
is not necessarily the order in which they execute, and they may
execute repeatedly/continuously.

Andy

On 3 Mai, 14:58, Andy <jonesa...@comcast.net> wrote:
> On May 3, 7:22 am, Antti <Antti.Luk...@xilant.com> wrote:
>
> > YOU CAN NOT USE "wait" statement for FPGA design.
> > YOU CAN NOT USE "wait" statement for FPGA design.
> > YOU CAN NOT USE "wait" statement for FPGA design.
> > YOU CAN NOT USE "wait" statement for FPGA design.
> > YOU CAN NOT USE "wait" statement for FPGA design.
>
> > read the above 5 times, and try again.
>
> > Antti
>
> WRONG!
>
> You cannot wait for TIME in synthesizable code.  You can wait until
> rising_edge(clk)! Not usually the best coding style, but it can be
> done and is accepted by most synthesis tools.
>
> NA,
>
> You can wait for time in a testbench (simulation code written to test
> the synthesizable FPGA design code).
>
> An additional problem is that the wait statement is a sequential
> statement (inside a process), but it is being used in a concurrent
> context (outside a process). That won't work for simulation or
> synthesis.
>
> Concurrent assignment statements are each their own little implied
> process, running in parallel with other concurrent assignment
> statements and processes. The order in which they appear in the code
> is not necessarily the order in which they execute, and they may
> execute repeatedly/continuously.
>
> Andy
ah, ok yes.

its really common that attempts are made to wait for time.
and yes, as best coding the wait should not be used at all..

so for a total newbie its really good advice not to consider
using wait statemant in synthesisable code at all.

Antti