simple counter/timer

L

laserbeak43

Guest
Hi,
I'm playing around with the LCD display on my Spartan 3E sk and I've
run into some sort of syntax error in my code and cant figure out why
it's happening. does anyone think they can help me out? Here are the
first 2 errors
the rest of the errors are identical to these:
****************************************
ERROR:HDLCompilers:247 - "lsr_lcd_ctrl.v" line 66 Reference to vector
wire 'SF_D' is not a legal reg or variable lvalue
ERROR:HDLCompilers:44 - "lsr_lcd_ctrl.v" line 66 Illegal left hand
side of blocking assignment
************************************
here is the source code.
http://docs.google.com/Doc?id=dcwnvd4z_10cq93pxdt

Thanks
Malik
 
laserbeak43 wrote:
Hi,
I'm playing around with the LCD display on my Spartan 3E sk and I've
run into some sort of syntax error in my code and cant figure out why
it's happening. does anyone think they can help me out? Here are the
first 2 errors
the rest of the errors are identical to these:
****************************************
ERROR:HDLCompilers:247 - "lsr_lcd_ctrl.v" line 66 Reference to vector
wire 'SF_D' is not a legal reg or variable lvalue
ERROR:HDLCompilers:44 - "lsr_lcd_ctrl.v" line 66 Illegal left hand
side of blocking assignment
************************************
here is the source code.
http://docs.google.com/Doc?id=dcwnvd4z_10cq93pxdt

Thanks
Malik
Are you using Reals or Integers as values you want to assign? Verilog
was originally made for simulation; synthesis is only a subset of what
Verilog allows.

If you show us all the lines in your code that include SF_D, for
instance, we might be able to help more (declaration, where it gets a
value, where the value is used).
 
Are you using Reals or Integers as values you want to assign?  Verilog
was originally made for simulation; synthesis is only a subset of what
Verilog allows.
I'm using integers

If you show us all the lines in your code that include SF_D, for
instance, we might be able to help more (declaration, where it gets a
value, where the value is used).- Hide quoted text -
To be honest, that is all of the code. I had to press the "Check
Syntax" button in
ISE cause I was very unsure of what I was doing.
I'm really new to Verilog

Thanks
Malik
 
laserbeak43 wrote:
Are you using Reals or Integers as values you want to assign? �Verilog
was originally made for simulation; synthesis is only a subset of what
Verilog allows.

I'm using integers

If you show us all the lines in your code that include SF_D, for
instance, we might be able to help more (declaration, where it gets a
value, where the value is used).- Hide quoted text -

To be honest, that is all of the code. I had to press the "Check
Syntax" button in
ISE cause I was very unsure of what I was doing.
I'm really new to Verilog

Thanks
Malik
Sorry - I missed your link to the source in the original note and my
access to docs.google.com is blocked at work. It's probable that your
synthesizer wants register vectors rather than integers. Integers are
good for synthesis control (for loops, for instance) but not for
variables used within the hardware itself.

Try using dimensioned registers in clocked blocks or dimensioned wires
for combinatorial assigns rather than integers.
 
On Sep 30, 12:43 pm, John_H <newsgr...@johnhandwork.com> wrote:
laserbeak43 wrote:
Are you using Reals or Integers as values you want to assign? Verilog
was originally made for simulation; synthesis is only a subset of what
Verilog allows.

I'm using integers

If you show us all the lines in your code that include SF_D, for
instance, we might be able to help more (declaration, where it gets a
value, where the value is used).- Hide quoted text -

To be honest, that is all of the code. I had to press the "Check
Syntax" button in
ISE cause I was very unsure of what I was doing.
I'm really new to Verilog

Thanks
Malik

Sorry - I missed your link to the source in the original note and my
access to docs.google.com is blocked at work.  It's probable that your
synthesizer wants register vectors rather than integers.  Integers are
good for synthesis control (for loops, for instance) but not for
variables used within the hardware itself.

Try using dimensioned registers in clocked blocks or dimensioned wires
for combinatorial assigns rather than integers.- Hide quoted text -

- Show quoted text -
Thanks :)
working on it :)
Malik
 
laserbeak43 wrote:
On Sep 30, 12:43 pm, John_H <newsgr...@johnhandwork.com> wrote:
laserbeak43 wrote:
Are you using Reals or Integers as values you want to assign? Verilog
was originally made for simulation; synthesis is only a subset of what
Verilog allows.
I'm using integers
If you show us all the lines in your code that include SF_D, for
instance, we might be able to help more (declaration, where it gets a
value, where the value is used).- Hide quoted text -
To be honest, that is all of the code. I had to press the "Check
Syntax" button in
ISE cause I was very unsure of what I was doing.
I'm really new to Verilog
Thanks
Malik
Sorry - I missed your link to the source in the original note and my
access to docs.google.com is blocked at work. It's probable that your
synthesizer wants register vectors rather than integers. Integers are
good for synthesis control (for loops, for instance) but not for
variables used within the hardware itself.

Try using dimensioned registers in clocked blocks or dimensioned wires
for combinatorial assigns rather than integers.- Hide quoted text -

- Show quoted text -

Thanks :)
working on it :)
Malik
I've had a chance to glance at your code.

First, the reg dimensions are outrageous. You don't need a 2000 bit
vector to count to 2000; an 11 bit vector will work fine for a count
range of 0-2047. Keep in mind that registers are dimensioned in bits,
not in counts.

Second, You're using blocking operators. Is this your intent? In one
clock do you want to increment EnLen, see if this new value is 12,
and... wait. You are nesting your if statements but you're
incrementing EnLen and using the ==12 at Each stage after the increment?
After already checking for ==12 so you'll always be 13 at any later
check? Whoa. I was going to trace through a very long propagation of
signals through your nested if statements but it looks like I can't
trace that far.

If you're not familiar with the implications of blocking versus
non-blocking operators, find a good Verilog reference and do some
reading. Often programmers used to serial machines code with the
blocking operators. Hardware, however, is typically parallel and best
implemented with non-blocking operators so everything happens at the
clock edge in a very obvious fashion. It's rare that the blocking
operator is needed and then usually only for advanced functionality by a
Verilog veteran. The blocking operator is not to be taken lightly!

Is the docs.google.com link code you've updated since the morning? I
saw no registers.

A piece of info that could help: are you using XST as your compiler?
The notes suggest so. If not, what compiler? For instance, SynplifyPro
still doesn't support the register initialization you're using (which
I'd love to use). Most modern synthesizers allow a C-like embedded I/O
declaration port list which can make readability much cleaner; this
feature was introduced in Verilog-2001. Something like:

module
lsr_lcd_ctrl
( input clk //50 MHz
, input reset //active high reset
, inout [11:8] SF_D //4-bit data interface
, output LCD_E //Read/Write Enable Pulse 0: Disabled
. //1: Read/Write operation enabled
.
.


This looks like a school project. Is there help available from a
Graduate Assistant or from your professor? It *looks* like you're
pretty green (we've all been there) but trying to get entry-level help
across a newsgroup can be difficult and time-consuming. It's perhaps
best to leverage resources closer to home.

Happy coding!
 
On Oct 1, 12:48 am, John_H <newsgr...@johnhandwork.com> wrote:
I've had a chance to glance at your code.

First, the reg dimensions are outrageous.  You don't need a 2000 bit
vector to count to 2000; an 11 bit vector will work fine for a count
range of 0-2047.  Keep in mind that registers are dimensioned in bits,
not in counts.
Yeah, I'd learned that earlier today, i was trying to make a counter
that
counted to 750000 so i used "[750000:0] and should've used
[19:0] !!!!!

Second, You're using blocking operators.  Is this your intent?
yes i was trying to count each branch individualy, the way that it's
listed
in the coment above that section of the code.

 > In one clock do you want to increment EnLen, see if this new value
is 12,
and...  wait.  You are nesting your if statements but you're
incrementing EnLen and using the ==12 at Each stage after the increment?
  After already checking for ==12 so you'll always be 13 at any later
check?  
I'd assumed that after incrementing EnLen past 12 it wraps back around
to 0

Whoa.  I was going to trace through a very long propagation of
signals through your nested if statements but it looks like I can't
trace that far.
I'm basically trying to wait the first sect of clock cycles, set LCD_E
high
and then count 12 clock cycles and then set it back to low and
continue to the next
inner branch.

If you're not familiar with the implications of blocking versus
non-blocking operators, find a good Verilog reference and do some
reading.  Often programmers used to serial machines code with the
blocking operators.  Hardware, however, is typically parallel and best
implemented with non-blocking operators so everything happens at the
clock edge in a very obvious fashion.  It's rare that the blocking
operator is needed and then usually only for advanced functionality by a
Verilog veteran.  The blocking operator is not to be taken lightly!
I guess i could've used to clock a bit better. yeah, i could have them
all count down in
parallel, thanks for pointing that out.

Is the docs.google.com link code you've updated since the morning?  I
saw no registers.
I'm checking now...no, it's how it was when I posted, btw, I used
google
docs cause the google groups usenet interface wouldn't let me add any
links
other than a google related one. (it took me about 30 minutes to get
that code
to look the way it does on google docs, not that it's good looking
code LOL)

A piece of info that could help: are you using XST as your compiler?
The notes suggest so.  If not, what compiler?  For instance, SynplifyPro
still doesn't support the register initialization you're using (which
I'd love to use).
Yes, I'm using XST in ISE 9.2.04i

 Most modern synthesizers allow a C-like embedded I/O
declaration port list which can make readability much cleaner; this
feature was introduced in Verilog-2001.  Something like:

   module
     lsr_lcd_ctrl
     ( input  clk          //50 MHz
     , input  reset        //active high reset
     , inout  [11:8] SF_D  //4-bit data interface
     , output LCD_E        //Read/Write Enable Pulse 0: Disabled
        .                   //1: Read/Write operation enabled
        .
        .
yes, noob-lazy-man-inconsiderate-doesn't-know-any-better-coder here..
I'm aware of that, just didn't think about it at the time. Does the
Verilog community tend to lean toward the C-styled look?

This looks like a school project.  Is there help available from a
Graduate Assistant or from your professor?
Nope not a school project, just this Usenet group and a few VERY nice
aquaintances.

 It *looks* like you're
pretty green (we've all been there) but trying to get entry-level help
across a newsgroup can be difficult and time-consuming.  It's perhaps
best to leverage resources closer to home.
I agree, unfortunately, this is closest i can get. well not exactly,
there
is a chat room(hehe), but only a few that can/will help, and i'd hate
to
lay all the burden on them when there's a community dedicated(?) to
that here.
(how big is this community anyway?)

Happy coding!
Thanks for all of your help and suggestions :)
Malik
 
laserbeak43 wrote:
I'd assumed that after incrementing EnLen past 12 it wraps back around
to 0

You have to have an explicit change to your counter; the counter will
automatically wrap from the largest number back to 0 in an up-counter
but we've covered the issue of bits versus counts.

Your code is written like software where the entire code looks like it's
expected to be run with absolutely no use of the internal clock. When
the always block is entered and the posedge of the clock is detected,
the code executes. Once. In nanoseconds. To get to the next 50 MHz
clock cycle, the always block is entered *again*.

By nesting all your IF statements, you don't get the counter to
increment the way you want. Hardware is parallel; when the clock edge
occurs, *everything* is evaluated in parallel. This is why the
non-blocking operator is *expected* because these are not serial
machines. When the clock hits, you want to compare your counter in
several places, look at flags that indicate what portion of the power-up
sequence you're in, toggle your signals, increment the counter, all at
the same time. It's a different mindset than programming but a
necessary one.
__

Also, while this newsgroup is here to share knowledge, it's really not a
place for basic instruction. You would really do yourself a favor by
finding a way to get the personalized instruction you need from those
who teach rather than from those here who - mostly - are working regular
day jobs without the opportunity to sit down for more than a few minutes
to try to help.

The depth of knowledge you can get from here on the broad subject of
Verilog is very limited. The depth of knowledge on a very specific
niche of Verilog might be much better addressed in a newsgroup thread.
It's typically the details that we spend our time and attention dealing
with here - the nuances. The basic science behind hardware design is
much too broad to be properly addressed here.

Notice how many people have come forward brimming with desire to help
out a new entry to the world of Verilog? I'd love for you to find a
local school, mentor, or even a good Verilog book to help you understand
the difference between programming and hardware.

Enjoy the trip into hardware but watch your step - it can get pretty mucky.
 
thanks for clearing that up. i mean i know the basic idea i guess but
that cleared it up a lot. thanks. :)

yeah i get your point about the community. i guess i'll ask more
specific questiions if i have them.
thanks.
 

Welcome to EDABoard.com

Sponsor

Back
Top