On Feb 4, 2:09 pm, rickman <gnu...@gmail.com> wrote:
> On Feb 4, 8:42 am, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > If I didn't answer then I apologize. The answer is I don't understand
> > the question. It appears to me from this screen shot:
>
> >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> > that 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. I had some feelings
> > that the issue lied somewhere with that, hence I supplied very careful
> > screen caps of the waveforms,
> > hoping someone would point out how to read them. I have never worked
> > with waveforms/timing
> > diagrams before.
>
> Let me jump back into the discussion here. You seem to be getting
> frustrated with the slowness of the learning curve. Personally, I
> found HDLs to be hard to learn, but I think this is made worse when
> you are very used to designing software (as I have said before). So
> just take a deep breath and accept this fact. Many have dealt with
> this before and lived through it. In fact, maybe there is something
> good that can come of this. At this point there are tons of good HDL
> books out there, but I have not seen one specifically written for
> people with strong software backgrounds. Maybe we can work on a book
> together. You can be the guinea pig! ;^)
>
> I'm not totally clear on the current state of the discussion and some
> of this seems to be focusing on details that may or may not be
> important at this point. Timing diagrams are very simple. They are
> just graphs of signal values as a function of time. I am sure you get
> that, but you are just not accustomed to debugging with them. The
> main reason for using them to debug hardware is because using the
> alternative, code breakpoints and stepping, is rather tedious in HDL
> since the information is presented serially as it happens. A waveform
> display gives you a lot of information in parallel with essentially
> random access as you view it and figure out what is important or what
> is working and what isn't.
>
> I am not sure what is currently working and what isn't in your
> design. I will say that I think I have read that you are testing on
> hardware and something there is not working, I guess the first
> character is not being received by the other UART? Is that UART also
> in the FPGA or are you testing with a PC? Before you worry about
> testing hardware, I recommend that you run the simulation to show the
> circuit is working there. It is a hundred times easier to see what is
> happening in simulation than in a test fixture.
>
> Given that, I can't see anything in your simulation capture that shows
> anything wrong. It appears that sending data to the TX FIFO is
> working. The data sequence seems to be F23456789A123456 which is 16
> chars, filling the FIFO as shown by the tx_buffer_full flag going
> high. After the first char is written to the FIFO I see an enable
> pulse on uart_en_16_x_baud and one clock later I see the rs232_tx_data
> go low. This all seems to be working as expected. I assume the baud
> enable is 16x the actual bit rate, so the simulation time is not long
> enough to watch the actual data emerge. Have you checked this to see
> that the simulation is transmitting the data correctly? If the data
> is being received by the FPGA UART, are all 16 chars received
> correctly?
>
> I am assuming that all of the above is true that the simulation shows
> things working correctly and that your only problem shows when you
> test on hardware. That would make sense given Jonathan's suggestion
> that you delay the start of your data transmission so that the
> receiving UART can clear out any garbage from the startup sequence.
> The startup delay may not be needed in simulation depending on the
> details of the startup sequence. This is one of the places where
> simulation can differ from the real world. In the real world there
> are often uncontrolled variables such as arbitrary delays, that are
> difficult to reproduce in simulation.
>
> Do I understand the current situation?
>
> > And while this might seem hopeless to you, 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. So to that level, this conversation has been productive for
> > me at least.
>
> The funding may be an issue. Even if you don't have funds to bring a
> consultant on board, you should get some training in this rather than
> try to tough it out yourself. I am sure you will eventually get it
> done, but it will be a much more expensive process and take a lot more
> time.
>
> > I am truly sorry my issues are so entry level, but we all must start
> > somewhere. 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.
>
> Don't sweat your inexperience. Every one of us dealt with the same
> problems starting out. Usually the "hello world" program equivalent
> is the "traffic light state machine" when designing HDLs. Remember,
> this is *not* a programming language, it is a hardware *description*
> language. When used for synthesis, you really need to get used to the
> idea that you are NOT writing a program, you are describing hardware
> to be synthesized. Of course that is easy for me to say. I started
> out playing with JK FFs wired together on perf board powered by a 6
> volt lantern battery. :^) Had 8080 CPU chips not been over $100 at
> the time, I might be a total software junkie now instead.
>
> Still, although your UART project may be a bit advanced for a
> beginner, it is not absurd and I expect you will be able to complete
> this shortly. If you find the UART is too frustrating, you might want
> to drop back to the traffic light program.
>
> > ~ You've now futzed around for about three quite long days
> > ~ and you still haven't got UART 101 working reliably.
> > ~ Surely you're smart enough to see that the right solution
> > ~ is to start again, properly?
>
> > Actually, I've been futzing around for 2 months and have "started
> > again"
> > 4 times already. Actually my associate has been futzing for almost
> > 6,
> > and this version is his interpretation of how to program. This
> > version,
> > warts and all, is the first is the first to at least send ANYTHING
> > out.
>
> I think the above is an important data point. 2 months and 4 trials
> should be a sign that this method is not working well. The fact that
> someone has been trying this stuff for 6 months shows that you likely
> will not be ready to tackle a project for over a year!
>
> > 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. Effecting a fix properly I still feel is
> > important
> > before adding another variable to the equation (new code with new
> > issues)
>
> I don't want to sound like I am beating on you, but I think there are
> problems of approach and expectations that are much bigger than the
> technical issues. My first HDL project happened because I took a
> training class for Orcad schematic software that I was going to use
> for an FPGA design (HDL was not so universally used at that time).
> The last day of training taught VHDL. I was so impressed with the
> potential that I recommended that we use it on the project instead of
> schematics. As it turns out my greenness allowed me to miss the fact
> that the Orcad HDL tools blew big chunks. After spending a month or
> maybe two working with the Orcad synthesis tool I realized that it was
> never going to work and we bought the Xilinx tool (a third party tool
> bundled with the Xilinx back end). That worked much better. Looking
> back on my coding style, I realize that much of that code would likely
> not pass muster by my current standards. For example, I was using '-'
> as a don't care condition. I now know that this is not a good idea as
> it is not universally supported. I won't even think about the style I
> used back then... actually some of my style from that first project
> has served me well, but you get the idea. Your first project will
> likely not be anything that you are proud of a year later.
>
> > That's the way I debug, understand what you have first, try and fix,
> > and then break it down to a streamlined scalable procedure.
>
> That is fine for debugging, but you are primarily in a learning mode.
> That works much better when you take bite sized pieces and learn a bit
> at a time rather than to try to get a much more complex effort done
> that involves learning on many different levels.
>
> I think that when you complete the "hello world" example, you will
> still have a long way to go before you are ready to try a project.
> The fact that waveform displays are still new and alien to you is a
> *very* good indicator that you are still in the elementary school of
> HDL design.
>
> The more I think about it, the more I like the idea of writing a
> book. I don't currently have any design work, maybe I should take
> that on as a project.
>
> Rick
Hey rick,
let me bring you up to date.
~ Given that, I can't see anything in your simulation capture that
shows
~ anything wrong. It appears that sending data to the TX FIFO is
~ working. The data sequence seems to be F23456789A123456 which is 16
~ chars, filling the FIFO as shown by the tx_buffer_full flag going
~ high. After the first char is written to the FIFO I see an enable
~ pulse on uart_en_16_x_baud and one clock later I see the
rs232_tx_data
~ go low. This all seems to be working as expected. I assume the
baud
~ enable is 16x the actual bit rate, so the simulation time is not
long
~ enough to watch the actual data emerge. Have you checked this to
see
~ that the simulation is transmitting the data correctly? If the data
~ is being received by the FPGA UART, are all 16 chars received
~ correctly?
That's my big issue, The simulation, seems to show everything is
fine,
but when I download the code to the board, hook up the UART to my
PC terminal session, I get 23456789a123456f, (the F is last rather
than
first) but the simulation as you noticed as well look perfectly fine:
http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap15_firstislast100xdelay.png
also through testing I know this to be true:
I make the message string:
constant project_name_stg : string := "123456789a12345";
aka, 15 characters, all is well, I get on my pc terminal:
123456789a12345
I make it 16 characters:
constant project_name_stg : string := "f23456789a123456";
my output becomes:
23456789a123456f
and the 17 character string:
constant project_name_stg : string := "f23456789a1234567";
yields the output:
23456789a1234567
so it was suggested that I need more settling time in the beginning,
so I have now added a delay, you will note in the screencap 15 above
is now starting at the 120us time area vs the older version that
started
at the 1.2us time area.
No change.
I've spent most of this afternoon starting to clean up the code.
I've collapsed the print mutex and the walk of the message to one
process:
-------------------------------------------------------------------------------------------------
-- P10: INITIALIZING lprj PROJECT MESSAGE COUNT ( project_name_cnt )
-------------------------------------------------------------------------------------------------
-- 090204 JL combined with P9, this will schedule each character of
the project name
-- and send each of its characters to the uart queue.
--
--
P10: PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER)
BEGIN
I01: IF ( rising_edge(clk_16_6mhz)) THEN
I02:IF ( ( UART_RESET_BUFFER = '0' ) AND
( UART_RESET_NEXT = '1' ) ) THEN
project_name_cnt <= project_name_stg'low;
lprj_MESS_TRAN <= '1';
ELSIF ( ( lprj_MESS_TRAN =
'1' ) AND
( TX_WRITE_BUFFER_STB =
'1' ) ) THEN
I03: IF ( project_name_cnt /=
project_name_stg'high ) THEN
project_name_cnt <= ( project_name_cnt
+ 1 );
ELSE
lprj_MESS_TRAN <= '0';
END IF I03;
END IF I02;
END IF I01;
END PROCESS P10;
------------------------------------------------------------------------------------------------
Still no change.