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

On Fri, 6 Feb 2009 09:39:09 -0800 (PST), jleslie48 wrote:

> 16.67Mhz is generated by 1/6th of the 100MHZ.  1/9th of that is
> exactly that, 1/6*/19 == 1/54 of the 1000Mhz.  If this machine
> can't get that right, I'm gonna be in a whole world of hurt.

No, no!!!! I'm not disputing either your or the counter's 
arithmetic.  I'm making a crucial point about HARDWARE.
The 16.67MHz clock is used as the clock input to many,
many registers.  If some of those registers see an
active edge of that clock significantly before or
after others, then there is a BIIIIIG problem of
hold time violation.  That is the problem that the
on-chip clock tree is designed to solve, and the problem
that you MUST avoid by ensuring that your clocks find
their way on to those clock trees correctly.  However,
it sounds as though the tools are doing their due 
diligence for you and all is well.

>More importantly, I ran JB_LOKI_TOP. and it works like a charm:

Nice to know that we can help kick-start your efforts.

> and I love the formatted output model.

Hah!  I think "formatted" is stretching a point. But
it certainly makes it easier to change the messages.

However.... I note that you have invented an integer constant
FLF to hold a line separator; you don't need to do that;
VHDL has predefined CHARACTER constants for all those things,
and they can be included in the message strings thanks to
the tua() function that type-converts a string into an
array of bytes:

   the_program =>
     op_DELAY & 255 &
     op_MESSAGE & tua("Just one line" & CR & LF) & EOM &
     op_MESSAGE & tua("2nd line" & CR & LF & "3rd line") & EOM
   .....

> I want to explore controlling when this entity fires,
> for triggered calls to Uart messages.

PLEASE DO NOT think about "firing" or "calling" an entity.
An entity instance just sits there, doing its thing, for
the entire life of the universe.  It "fires" on every 
clock edge, whether you like it or not.  You must find a 
way to modify its operation under control of some other 
signal(s) that come in through its input ports.

Suppose you decided that you want to use an input on the
serial Rx line to trigger something.  You could imagine
adding a "wait for a certain character" opcode to add
to the program.  Just add a couple of new states to the
state machine, and a new command constant, and add ports
to access the receive UART...

So, that thought made me smile, so I've updated the two 
files at the same URL as before.  Here's the "program" now:

  , the_program =>
     -- Long startup delay
     op_DELAY & 200 &
     -- Welcome message starts at address 2.
     op_MESSAGE & tua(CR&LF&"Hello"&CR&LF) & EOM &
     -- Wait for a "+" from the keyboard...
     op_WAIT_FOR_CHAR & tua("+") &
     -- and then print another message
     op_MESSAGE & tua("abcdefghijklmnopqrstuvwxyz"&CR&LF) & EOM &
     -- Wait for a "-" from the keyboard
     op_WAIT_FOR_CHAR & tua("-") &
     -- and then go back to the beginning! - no delay this time.
     op_GOTO & 2

The state machine is getting a tad messy now, and this is a 
good sign that we're starting to do things that are better
done in software using a little embedded processor core 
such as Picoblaze.  I haven't really made any effort to 
clean up the state machine code; it could be much better 
than it currently is.

Enjoy.
-- 
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 6, 2:16 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 6 Feb 2009 09:39:09 -0800 (PST), jleslie48 wrote:
> > 16.67Mhz is generated by 1/6th of the 100MHZ.  1/9th of that is
> > exactly that, 1/6*/19 == 1/54 of the 1000Mhz.  If this machine
> > can't get that right, I'm gonna be in a whole world of hurt.
>
> No, no!!!! I'm not disputing either your or the counter's
> arithmetic.  I'm making a crucial point about HARDWARE.
> The 16.67MHz clock is used as the clock input to many,
> many registers.  If some of those registers see an
> active edge of that clock significantly before or
> after others, then there is a BIIIIIG problem of
> hold time violation.  That is the problem that the
> on-chip clock tree is designed to solve, and the problem
> that you MUST avoid by ensuring that your clocks find
> their way on to those clock trees correctly.  However,
> it sounds as though the tools are doing their due
> diligence for you and all is well.
>
> >More importantly, I ran JB_LOKI_TOP. and it works like a charm:
>
> Nice to know that we can help kick-start your efforts.
>
> > and I love the formatted output model.
>
> Hah!  I think "formatted" is stretching a point. But
> it certainly makes it easier to change the messages.
>
> However.... I note that you have invented an integer constant
> FLF to hold a line separator; you don't need to do that;
> VHDL has predefined CHARACTER constants for all those things,
> and they can be included in the message strings thanks to
> the tua() function that type-converts a string into an
> array of bytes:
>
>    the_program =>
>      op_DELAY & 255 &
>      op_MESSAGE & tua("Just one line" & CR & LF) & EOM &
>      op_MESSAGE & tua("2nd line" & CR & LF & "3rd line") & EOM
>    .....
>
> > I want to explore controlling when this entity fires,
> > for triggered calls to Uart messages.
>
> PLEASE DO NOT think about "firing" or "calling" an entity.
> An entity instance just sits there, doing its thing, for
> the entire life of the universe.  It "fires" on every
> clock edge, whether you like it or not.  You must find a
> way to modify its operation under control of some other
> signal(s) that come in through its input ports.
>
> Suppose you decided that you want to use an input on the
> serial Rx line to trigger something.  You could imagine
> adding a "wait for a certain character" opcode to add
> to the program.  Just add a couple of new states to the
> state machine, and a new command constant, and add ports
> to access the receive UART...
>
> So, that thought made me smile, so I've updated the two
> files at the same URL as before.  Here's the "program" now:
>
>   , the_program =>
>      -- Long startup delay
>      op_DELAY & 200 &
>      -- Welcome message starts at address 2.
>      op_MESSAGE & tua(CR&LF&"Hello"&CR&LF) & EOM &
>      -- Wait for a "+" from the keyboard...
>      op_WAIT_FOR_CHAR & tua("+") &
>      -- and then print another message
>      op_MESSAGE & tua("abcdefghijklmnopqrstuvwxyz"&CR&LF) & EOM &
>      -- Wait for a "-" from the keyboard
>      op_WAIT_FOR_CHAR & tua("-") &
>      -- and then go back to the beginning! - no delay this time.
>      op_GOTO & 2
>
> The state machine is getting a tad messy now, and this is a
> good sign that we're starting to do things that are better
> done in software using a little embedded processor core
> such as Picoblaze.  I haven't really made any effort to
> clean up the state machine code; it could be much better
> than it currently is.
>
> Enjoy.
> --
> 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.

whoa!!!!  hold on there!  now things are getting interesting!


first,
"However.... I note that you have invented an integer constant
 FLF to hold a line separator; you don't need to do that;
 VHDL has predefined CHARACTER constants for ..."

thanks for the tip.  I tried those first but got an error mesage.
I thought I could use those as

op_MESSAGE & tua("Hello") &CR&LF & EOM &

but that is syntactically incorrect.

thanks for the correct syntax:
op_MESSAGE & tua("Hello"&CR&LF) & EOM &



you've got a whole mess of computing power built into the
entity now, and while I'd love to offset this into a picoblaze
C programming environment, I won't have that at my disposal so
your state machine built out of VHDL is starting to look mighty pretty
to me.

first off, I just took a quick dander at the new code,
and its set for the 50Mhz clock yes?

In my 100Mhz world the line:

          IF ( BAUD_COUNT = 26 ) THEN

in the P4 process:

P4:  PROCESS ( SYSTEM_CLOCK )
BEGIN
     IF ( SYSTEM_CLOCK = '1' AND SYSTEM_CLOCK'EVENT ) THEN
          IF ( BAUD_COUNT = 26 ) THEN
               BAUD_COUNT <= 0;
               UART_EN_16_X_BAUD        <= '1';
          ELSE
               BAUD_COUNT <= BAUD_COUNT + 1 ;
               UART_EN_16_X_BAUD        <= '0';
          END IF;
     END IF;
END PROCESS P4;

should be 54 yes?


and this:


TRANSMIT_UART : entity work.uart_tx


  port map
       (

       data_in               =>   TX_DATA_IN,
       write_buffer          =>   TX_WRITE_BUFFER_STB,
       reset_buffer          =>   UART_RESET_BUFFER,
       en_16_x_baud          =>   UART_EN_16_x_BAUD,
       serial_out            =>   RS232_TX_DATA,
       buffer_full           =>   TX_BUFFER_FULL,
       buffer_half_full      =>   TX_BUFFER_HALF_FULL,
       clk                   =>   SYSTEM_CLOCK

       );


isn't the clk here supposed to be:
the 1/6th clock?

        clk                   =>   CLK_16_6MHZ

I think I'm missing something on understanding how these clocks work.

"PLEASE DO NOT think about "firing" or "calling" an entity.
 An entity instance just sits there, doing its thing, for
 the entire life of the universe.  It "fires" on every
 clock edge, whether you like it or not.  "

Ok, I'm missing something or maybe I'm just not useing the
right words.

In your ver 1.0, the entity data_gen in JB_Loki_Top
generated 1 and only one message output message:

A
abcdefghijkinsertherelmnopqrstuvwxyz12345678pqr

and entity instantiation was in the concurrent logic
portion of the loki_top architecture behavorial.

now it finished with an op_halt, so I'm guessing that
in the details of data gen I'm going to see that HALT
render data_gen silent, until reboot time, or I imagine
if I give that
reset => '0' a real signal to set the output message to
resend.

Again I think I'm mucking up the language of describing what
is the chain of events, but the fact is data_gen put ~something
out once and only once, and I'm quite sure their is a way I can have
that ~something come out again bases on a change of ~some signal.

That is what I meant by ` "firing" or "calling" an entity. `  I
messing up
on the language, but I do realize that the entity is in a state of
continuous
activity, and it is a matter of controlling the boolean signals to a
state of
true and false to make it do one thing (put out a message) or another
(just
sit there)

I'm going to take a good hard look at data_gen, specifically the
change from
simple, one shot firing to your new looper with conditional waits.

I know your going to hate this, but I like that second element of the
generic map
of data_gen being "the_program".  It has established some linear
events that are
a lot more familiar to me.

Sincerely,

Jonathan Leslie