Re: rs232 uart: testbench vs real world, and the missing first letter.

On Wed, 4 Feb 2009 05:42:01 -0800 (PST), jleslie48 wrote:

> my serial line ( rs232_tx_data) idles for 955ns based on the
>whole system waiting for
>uart_reset_buffer.  If that is not enough, then that was not made
>clear to me. 

It's nowhere near enough to make me feel safe.

Any real UART receiver - like the one in your PC - is 
quite likely to get messed-around by whatever happens
in your FPGA during startup.  So you MUST allow the line
to idle for at least one CHARACTER time before sending
anything; that way, the PC or whatever receiver will 
have a chance to sort itself out reliably before 
getting your data.  A character time at 115kBd is, 
by my reckoning, around 90 microseconds - around 
a hundred times more than you currently allow.

I'm not saying it will ALWAYS fail, but rather that
here is a goofy variable in the debugging that might
easily introduce nonsensical behaviour that would
throw you off the scent of more important issues.

>I had some feelings
>that the issue lied somewhere with that, 

I am very sure that you have more than just one issue.

> I have never worked with waveforms/timing diagrams before.

yeah.... powerful, useful tool, but takes a bit of 
getting used to.  

>And while this might seem hopeless to you

Did I say hopeless?  Yes, but not about YOU - 
rather, about a piece of code, I think.

> I have no choice in the matter.  I have no
>funding at this time to bring on additional personnel and quite
>frankly, prior to this
>discussion, I wouldn't of even been qualified to hire someone; one of
>my problems in the past. 

Fair enough.  Though I have to say that you're putting
yourself in a fairly scary position.

>I am truly sorry my issues are so entry level,
> but we all must start somewhere.

I know that very well.  It seems to me that
no beginner need ever apologize for asking
interesting questions.  However, one might
reasonably accuse you of biting off too much
at once.....

> Every programming
>environment I've ever had to learn (and there have been many) has had
>by page 3 demonstrated the
>basic "hello world" program. I have been through many websites and
>textbooks and for this environment,
>it is very suspicious by its absence that the "hello world" program is
>missing.

Hmmm.... I somewhat sympathise, but you might care to question
why people continue to pay us non-trivial amounts of money for
our very, very carefully designed training on exactly this kind
of stuff.  I am willing to bet a few beers that if you had
spent this week on our class, rather than banging your head
against a brick wall, you would be ready to move forward
as soon as you got back to the office.

Looking ahead a little: if you insist on regarding this as
"programming" you are fairly sure to end up in the mire.
Programming skills are good, useful, helpful; but hardware
design requires a very clear *structural* vision of what
you're trying to build, as well as a *procedural* one.

>I think this messed up version is very close to working properly, and
>to abandon it now would be to miss out on understanding something
>important I am missing.

OK.  One last push.  I'm on a couple of days' vacation so 
I will make a genuine effort to work out what you're doing
wrong.  Can't do very much more though, sorry.

>That's the way I debug, understand what you have first, try and fix,
>and then break it down to a streamlined scalable procedure.

Yes, but when you have given yourself something very wrong
indeed, the effort of understanding it may be a lot greater
than the understanding justifies.  Putting the same amount
of effort into understanding a couple of well-written
examples might pay much better dividends.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

OK, I looked pretty hard at your code, and I am
somewhat stumped.  There is so much that is just
so far away from what I would do - not the 
line-by-line minutiae of coding, but the overall
approach.  Two really big things that make it
close to impossible to debug in a reasonable time:

(1) You have several distinct processes, each 
taking responsibility for a block of activity.
Consequently they have to hand-off from one to
another in complicated ways.  Very hard to 
manage correctly.  It is far easier to have 
one process take responsibility for any single
thread of activity.

(2)You've just GOT to learn about state machines.
Using some unholy boolean mess of flags to decide
what to do on each clock is a recipe for disaster.

So....... you'll probably be cross about this, or
simply ignore it, but.... I've written a data 
generator to create your message strings.  It's 
very incomplete so far, but it stores its information
in a Xilinx blockRAM configured as ROM, and allows
you to freely intermix messages and time delays.
It could easily be extended to allow loopback
tests, repeating messages and suchlike.  Here's
how you instantiate it to create two "hello world"
messages:

JSEB_DATA_GENERATOR: entity work.data_gen
         generic map
           ( PC_bits => 9  -- Width of ROM address
           , the_program =>
               -- Long startup delay
               op_DELAY & 200 &
               -- Send the first message
               op_MESSAGE & tua("Hello World") & EOM &
               -- short delay
               op_DELAY & 20 &
               -- send the second message
               op_MESSAGE & tua("Goodbye") & EOM &
               -- Freeze up so we do nothing more
               op_HALT
           )
         port map (.....)

Nice, yes?  op_DELAY, op_MESSAGE, op_HALT and EOM are
single-byte constants.

And I've rewritten the top module to use this alongside
your existing UART transmitter.  You should be able to
try it out rather easily and tell me whether it works -
I've only tried it in simulation so far, but I'll try 
it on my little demo board tomorrow.

The sources are at
  http://www.oxfordbromley.plus.com/files/loki/
and I hope the comments are sufficiently useful.

cheers
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Feb 4, 7:42 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> OK, I looked pretty hard at your code, and I am
> somewhat stumped.  There is so much that is just
> so far away from what I would do - not the
> line-by-line minutiae of coding, but the overall
> approach.  Two really big things that make it
> close to impossible to debug in a reasonable time:
>
> (1) You have several distinct processes, each
> taking responsibility for a block of activity.
> Consequently they have to hand-off from one to
> another in complicated ways.  Very hard to
> manage correctly.  It is far easier to have
> one process take responsibility for any single
> thread of activity.
>
> (2)You've just GOT to learn about state machines.
> Using some unholy boolean mess of flags to decide
> what to do on each clock is a recipe for disaster.
>
> So....... you'll probably be cross about this, or
> simply ignore it, but.... I've written a data
> generator to create your message strings.  It's
> very incomplete so far, but it stores its information
> in a Xilinx blockRAM configured as ROM, and allows
> you to freely intermix messages and time delays.
> It could easily be extended to allow loopback
> tests, repeating messages and suchlike.  Here's
> how you instantiate it to create two "hello world"
> messages:
>
> JSEB_DATA_GENERATOR: entity work.data_gen
>          generic map
>            ( PC_bits => 9  -- Width of ROM address
>            , the_program =>
>                -- Long startup delay
>                op_DELAY & 200 &
>                -- Send the first message
>                op_MESSAGE & tua("Hello World") & EOM &
>                -- short delay
>                op_DELAY & 20 &
>                -- send the second message
>                op_MESSAGE & tua("Goodbye") & EOM &
>                -- Freeze up so we do nothing more
>                op_HALT
>            )
>          port map (.....)
>
> Nice, yes?  op_DELAY, op_MESSAGE, op_HALT and EOM are
> single-byte constants.
>
> And I've rewritten the top module to use this alongside
> your existing UART transmitter.  You should be able to
> try it out rather easily and tell me whether it works -
> I've only tried it in simulation so far, but I'll try
> it on my little demo board tomorrow.
>
> The sources are at
>  http://www.oxfordbromley.plus.com/files/loki/
> and I hope the comments are sufficiently useful.
>
> cheers
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


"So....... you'll probably be cross about this, or
simply ignore it, but.... I've written a data
generator to create your message strings.  "

Hardly.  I am extremely appreciative of this effort.
I've been stuck in meetings all morning and had
not a chance to review, but I'm very interested
in an alternate model.

Thanks again,

Jon