On Tue, 3 Feb 2009 13:21:25 -0800 (PST), jleslie48 wrote:>Here's the simulation of the 16 character printout: > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap13_firstislast16.png > >everything looks to me ship-shape. > >I'm gonna have to compare this simulation to a 15 character one. > >anybody see anything?Yes. Jon, how do I put this politely.... (1) you're not listening; (2) your debugging technique leaves something to be desired. I asked you whether you were leaving enough time for the serial line to settle at its idle condition before the first character goes out. You haven't answered, but the answer, very obviously, ia "no, you're not". Your serial line idles for only a few hundred nanoseconds before the first start bit goes out. Depending on what the FPGA was doing during configuration, that might or might not work downstream. It's hopeless. So your design is immediately broken. If it's broken, then small differences between two forms of brokenness will mask the real trouble. Insisting on fixing one minor issue when so much else is so broken is just a recipe for wasting time. PLEASE, PLEASE fix the dreadful mess that is your data generator. Only when you have something whose behaviour is predictable and controllable can you hope to debug any real problems. I sent you a private email suggesting ways you might be able to get some useful support. It may have fallen into your spamtrap, but whatever, I didn't get a response. Several of us have seen that you are going at this in a creative and generally intelligent, but badly flawed, way; so you've had loads of suggestions that a less thoughtful poster would not have received. For heaven's sake take the higher-level advice too: SORT THE MESS OUT. 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? yours somewhat despairingly -- 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.
Re: rs232 uart: testbench vs real world, and the missing first letter.
Started by ●February 3, 2009
Reply by ●February 4, 20092009-02-04
On Feb 3, 4:45 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote:> On Tue, 3 Feb 2009 13:21:25 -0800 (PST), jleslie48 wrote: > >Here's the simulation of the 16 character printout: > > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen... > > >everything looks to me ship-shape. > > >I'm gonna have to compare this simulation to a 15 character one. > > >anybody see anything? > > Yes. > > Jon, how do I put this politely.... > > (1) you're not listening; > (2) your debugging technique leaves something to be desired. > > I asked you whether you were leaving enough time for the serial > line to settle at its idle condition before the first character > goes out. You haven't answered, but the answer, very obviously, > ia "no, you're not". Your serial line idles for only a few > hundred nanoseconds before the first start bit goes out. > Depending on what the FPGA was doing during configuration, > that might or might not work downstream. It's hopeless. > > So your design is immediately broken. If it's broken, then > small differences between two forms of brokenness will mask > the real trouble. Insisting on fixing one minor issue when > so much else is so broken is just a recipe for wasting time. > > PLEASE, PLEASE fix the dreadful mess that is your data > generator. Only when you have something whose behaviour > is predictable and controllable can you hope to debug any > real problems. > > I sent you a private email suggesting ways you might > be able to get some useful support. It may have fallen > into your spamtrap, but whatever, I didn't get a response. > Several of us have seen that you are going at this in > a creative and generally intelligent, but badly flawed, > way; so you've had loads of suggestions that a less > thoughtful poster would not have received. For heaven's > sake take the higher-level advice too: SORT THE MESS OUT. > 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? > > yours somewhat despairingly > -- > 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.Well, I cannot deny that I am floundering. I don't see your private email in my inbox or spam filter. I'm at jleslie48@yahoo.com or jon@jonathanleslie.com ~ I asked you whether you were leaving enough time for the serial ~ line to settle at its idle condition before the first character ~ goes out. You haven't answered, but the answer, very obviously, ~ ia "no, you're not". Your serial line idles for only a few ~ hundred nanoseconds before the first start bit goes out. ~ Depending on what the FPGA was doing during configuration, ~ that might or might not work downstream. It's hopeless. 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/screencap13_firstislast16.png 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. 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. 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. ~ 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 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) That's the way I debug, understand what you have first, try and fix, and then break it down to a streamlined scalable procedure.
Reply by ●February 4, 20092009-02-04
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
Reply by ●February 4, 20092009-02-04
On Feb 4, 9:09=A0pm, rickman <gnu...@gmail.com> wrote:> On Feb 4, 8:42 am, jleslie48 <j...@jonathanleslie.com> wrote: >[snip]> The more I think about it, the more I like the idea of writing a > book. =A0I don't currently have any design work, maybe I should take > that on as a project. > > Rickto OP: general rule for UART design after power on, and full system init that is UART mode setup, etc uart hardware init complete make sleep( 1 second); just wait 1 second before sending anything out the uart. i have also troubleshooted FPGA system that failed to send data on uart TX, well they actually worked, but during powerup the TX maybe active, those forcing BREAK condition, and only heaven know how much recovery after that may be required before PC will accept UART data. it is possible that FPGA sends 100 chars, and PC receives say 8 if the break was removed to quickly and the uart didnt sync properly at PC side. the problem is hardly ever there where you look first :) to Rick: i also have/have had plans of writing various stuff(books) one of them would be titled "art of abstract problem solving".. missing uart print is one good example where this art shoud be applied :) Antti
Reply by ●February 4, 20092009-02-04
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. > > RickHey 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.
Reply by ●February 5, 20092009-02-05
On Feb 4, 4:28 pm, jleslie48 <j...@jonathanleslie.com> wrote:> > Hey rick, > > let me bring you up to date. > > On Feb 4, 2:09 pm, rickman <gnu...@gmail.com> wrote: > ~ 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/screen... > > 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: > 23456789a123456fI think Jonathan or someone else suggested that if the F that should be the first character is showing up as the last character, this is *clearly not* an issue of startup delay. Something is wrong either with the way you are writing into the FIFO or perhaps the FIFO code itself is not correct. What may well be happening is that the first character written into the FIFO is being skipped by the UART. When you write exactly 16 characters somehow the UART output counter is getting messed up and skips to the second character. Of course this is speculation, but the fact that the 15 char message works ok shows it is not a startup issue. The 17 char message confuses me though. It skips the first char and only outputs 16 chars. Is there an output from the UART that acknowledges the strobe when you write to the tx fifo (other than the full flag)? If not, then the strobe should be accepted at any time. If there is a handshake flag, this needs to be checked before writing to the FIFO again that that might explain the mixup on 16 or more chars. One last comment on the FIFO, check the docs and see if you can actually write 16 chars to it without pause. To handle 16 chars, it needs to have an extra bit to account for 17 states (empty and 1 to 16 chars). If this extra state is omitted, it could explain the symptoms. Since you have the UART code, it should be easy to find the internal in and out counters and monitor them as it runs the 16 char case.> and the 17 character string: > constant project_name_stg : string := "f23456789a1234567"; > yields the output: > 23456789a1234567Yeah, this is the one that sounds like it is overwriting the first char or otherwise not being handled correctly. Is the reset to the UART being handled? Do you have a image of the simulation waveform? I would like to see the same time period as the screencap13_firstislast16.png where it shows the writes to the FIFO. It would also be useful to see the handshakes between the FIFO and the UART. This is an HDL UART, right?> 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.At this point I don't think it is startup issues because the 15 char case works. Something is wrong with the FIFO. Does the UART have a flag from the transmitter shift register to say it is empty? If so, you can set up a handshake with that to control the write to the FIFO so that the FIFO never has more than one char. That should chase away the problem and show that it is in the FIFO interface. I got your email and will give a reply tomorrow. Rick
Reply by ●February 5, 20092009-02-05
On Feb 5, 2:19 am, rickman <gnu...@gmail.com> wrote:> On Feb 4, 4:28 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > > > Hey rick, > > > let me bring you up to date. > > > On Feb 4, 2:09 pm, rickman <gnu...@gmail.com> wrote: > > ~ 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/screen... > > > 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 > > I think Jonathan or someone else suggested that if the F that should > be the first character is showing up as the last character, this is > *clearly not* an issue of startup delay. Something is wrong either > with the way you are writing into the FIFO or perhaps the FIFO code > itself is not correct. What may well be happening is that the first > character written into the FIFO is being skipped by the UART. When > you write exactly 16 characters somehow the UART output counter is > getting messed up and skips to the second character. Of course this > is speculation, but the fact that the 15 char message works ok shows > it is not a startup issue. The 17 char message confuses me though. > It skips the first char and only outputs 16 chars. Is there an output > from the UART that acknowledges the strobe when you write to the tx > fifo (other than the full flag)? If not, then the strobe should be > accepted at any time. If there is a handshake flag, this needs to be > checked before writing to the FIFO again that that might explain the > mixup on 16 or more chars. One last comment on the FIFO, check the > docs and see if you can actually write 16 chars to it without pause. > To handle 16 chars, it needs to have an extra bit to account for 17 > states (empty and 1 to 16 chars). If this extra state is omitted, it > could explain the symptoms. Since you have the UART code, it should > be easy to find the internal in and out counters and monitor them as > it runs the 16 char case. > > > and the 17 character string: > > constant project_name_stg : string := "f23456789a1234567"; > > yields the output: > > 23456789a1234567 > > Yeah, this is the one that sounds like it is overwriting the first > char or otherwise not being handled correctly. Is the reset to the > UART being handled? Do you have a image of the simulation waveform? > I would like to see the same time period as the > screencap13_firstislast16.png where it shows the writes to the FIFO. > It would also be useful to see the handshakes between the FIFO and the > UART. This is an HDL UART, right? > > > 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. > > At this point I don't think it is startup issues because the 15 char > case works. Something is wrong with the FIFO. > > Does the UART have a flag from the transmitter shift register to say > it is empty? If so, you can set up a handshake with that to control > the write to the FIFO so that the FIFO never has more than one char. > That should chase away the problem and show that it is in the FIFO > interface. > > I got your email and will give a reply tomorrow. > > RickI agree its not a startup issue. I have another message that comes out (the cindy message) when the user types "123" and that suffers from the same symptoms. also the symptoms of strings 17+ are the same, first character has been destroyed, but the rest queue perfectly fine. Most of what else your asking involves the internal workings of the UART/ bucket brigade Fifo, and that will need to be explored. it starts with 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 => CLK_16_6MHZ ); which is an instantsiation of this: http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/uart_tx.vhd which breaks out to these two: http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/bbfifo_16x8.vhd http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/kcuart_tx.vhd and is documented here: http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/Docs/UART_Manual.pdf now the vhd code above, kcuart_tx.vhd details a HDL UART yes? So I think the answer to that question is yes... the reset to the UART being handled? I don't think it makes a difference, I never send one. UART flag if empty? doesn't seem to have one that comes out of the process, but it might have one internal. acknowledge the strobe, doesn't look like there is one, I don't see one. I'm gonna have to bring out some of the waveforms of the internals of the UART to answer some of your screen cap issues.
Reply by ●February 6, 20092009-02-06
On Feb 5, 12:43 pm, jleslie48 <j...@jonathanleslie.com> wrote:> On Feb 5, 2:19 am, rickman <gnu...@gmail.com> wrote: > > > > > On Feb 4, 4:28 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > Hey rick, > > > > let me bring you up to date. > > > > On Feb 4, 2:09 pm, rickman <gnu...@gmail.com> wrote: > > > ~ 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/screen... > > > > 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 > > > I think Jonathan or someone else suggested that if the F that should > > be the first character is showing up as the last character, this is > > *clearly not* an issue of startup delay. Something is wrong either > > with the way you are writing into the FIFO or perhaps the FIFO code > > itself is not correct. What may well be happening is that the first > > character written into the FIFO is being skipped by the UART. When > > you write exactly 16 characters somehow the UART output counter is > > getting messed up and skips to the second character. Of course this > > is speculation, but the fact that the 15 char message works ok shows > > it is not a startup issue. The 17 char message confuses me though. > > It skips the first char and only outputs 16 chars. Is there an output > > from the UART that acknowledges the strobe when you write to the tx > > fifo (other than the full flag)? If not, then the strobe should be > > accepted at any time. If there is a handshake flag, this needs to be > > checked before writing to the FIFO again that that might explain the > > mixup on 16 or more chars. One last comment on the FIFO, check the > > docs and see if you can actually write 16 chars to it without pause. > > To handle 16 chars, it needs to have an extra bit to account for 17 > > states (empty and 1 to 16 chars). If this extra state is omitted, it > > could explain the symptoms. Since you have the UART code, it should > > be easy to find the internal in and out counters and monitor them as > > it runs the 16 char case. > > > > and the 17 character string: > > > constant project_name_stg : string := "f23456789a1234567"; > > > yields the output: > > > 23456789a1234567 > > > Yeah, this is the one that sounds like it is overwriting the first > > char or otherwise not being handled correctly. Is the reset to the > > UART being handled? Do you have a image of the simulation waveform? > > I would like to see the same time period as the > > screencap13_firstislast16.png where it shows the writes to the FIFO. > > It would also be useful to see the handshakes between the FIFO and the > > UART. This is an HDL UART, right? > > > > 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. > > > At this point I don't think it is startup issues because the 15 char > > case works. Something is wrong with the FIFO. > > > Does the UART have a flag from the transmitter shift register to say > > it is empty? If so, you can set up a handshake with that to control > > the write to the FIFO so that the FIFO never has more than one char. > > That should chase away the problem and show that it is in the FIFO > > interface. > > > I got your email and will give a reply tomorrow. > > > Rick > > I agree its not a startup issue. I have another message that comes > out > (the cindy message) when the user types "123" and that suffers from > the > same symptoms. also the symptoms of strings 17+ are the same, > first character has been destroyed, but the rest queue perfectly > fine. > > Most of what else your asking involves the internal workings of the > UART/ bucket brigade Fifo, and that will need to be explored. > > it starts with 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 => CLK_16_6MHZ > ); > > which is an instantsiation of this:http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/uart_tx.vhd > > which breaks out to these two: > > http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/bbfifo_16x8.vhdhttp://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/VHDL/kcuart_tx.vhd > > and is documented here: > > http://grace.evergreen.edu/dtoi/arch06w/asm/KCPSM3/Docs/UART_Manual.pdf > > now the vhd code above, kcuart_tx.vhd details a HDL UART yes? So I > think the > answer to that question is yes...Wow! I know it is possible and will potentially give you the optimum size design, but I have never actually seen a unit that was 100% instantiated. Technically this is VHDL. But for all practical purposes, this is a schematic expressed in text.> the reset to the UART being handled? I don't think it makes a > difference, I never send one.I see that the UART has no reset. The FIFO however, *does* have a reset which is the signal reset_buffer driven by your signal UART_RESET_BUFFER. So that needs to be asserted for a while before the UART is used. Otherwise the FIFO counters may not be in the right state.> UART flag if empty? doesn't seem to have one that comes out of the > process, but it might > have one internal.Yes, there is one coming from the internal UART, but it is not brought out to the higher level interface. It is Tx_complete which is used to drive the fifo_read signal to the FIFO. The handshake between the FIFO and the UART is fifo_read and fifo_data_present. To see what is being loaded into the UART, monitor these signals and the fifo_data_out bus in the simulation. Actually, I think I have lost the thread of what the problem is. Is the simulation working 100% and the real chip is *not* working? If so, looking at the simulation won't tell you a lot.> acknowledge the strobe, doesn't look like there is one, I don't see > one. > > I'm gonna have to bring out some of the waveforms of the internals of > the UART to answer > some of your screen cap issues.Ok, but I think I need a high level overview again. What is working and what is not working? Does the TX serial output look right in all of the simulation? Rick
