Jump to content
  • 0

VHDL BASYS3 internal clock problems.


donwazonesko

Question

I've created this simple mod16 counter using basys3 board and something is not right with my clock. The code itself do works, however one count (changing from "1" to "2" etc.) last 40 seconds, instead of 1 second! I've tried to lower the "clk_vector" if condition to 1 but it didn't help either.

library IEEE;                                                                                                  
use IEEE.STD_LOGIC_1164.ALL;                                                                                   
use IEEE.NUMERIC_STD.ALL;                                                                                      
                                                                                                               
entity mod_16_k is                                                                                             
    Port ( sw : in STD_LOGIC_VECTOR (3 downto 0);                                                              
           clk : in STD_LOGIC;                                                                                 
           reset : in STD_LOGIC;                                                                               
           led : out STD_LOGIC_VECTOR (15 downto 0));                                                          
end mod_16_k;                                                                                                  
architecture Behavioral of mod_16_k is                                                                         
                                                                                                               
signal      clk_vector   :integer;                                                                             
signal      clk_vec2      :std_logic_vector(15 downto 0);
                                                                                                               
begin                                                                                                          
zegar_wew : process(clk)                                                                                       
begin                                                                                                          
                                                                                                               
if(clk'event and clk = '1')  then                                                                              
    clk_vector <= clk_vector + 1;                                                                              
        if(clk_vector = 100000000) then                                                                        
            clk_vec2 <= std_logic_vector(unsigned(clk_vec2)  + 1);                                             
        end if;                                                                                                
end if;                                                                                                        
end process;                                                                                                   
led <= clk_vec2;                                                                                               
end Behavioral;

                                                                                               

The .XDC lines for clock are:

set_property PACKAGE_PIN W5 [get_ports clk]							
	set_property IOSTANDARD LVCMOS33 [get_ports clk]
	create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports clk]

If we check the basys3 datasheet, the clock is connected to "W5" port.:

Do you have any idea, what might be the problem in here? It might be connected with detecting the rising edge of an clk, however all of the changes (from 1 to 2 etc.) last ~40 seconds.

Link to comment
Share on other sites

15 answers to this question

Recommended Posts

@donwazonesko,

May I ask how you are verifying your code?  Is the text book your are following, or your course syllabus/professor/whatever, teaching you what you need to debug your code?

I ask this because, from a simple survey, I'm finding that very few text books tell users how to find bugs in code like this. 

The right answer to your problem isn't the bug that you found, but the process you are missing for finding bugs.  You should have a test bench of some type, or a simulation, or a formal model, that will produce a trace with all of your wires and their values/meanings within it.  This trace will lead you directly to this type of bug.

I'm more of a Verilog developer, so I use SymbiYosys for generating traces from formal specifications, and Verilator for my simulation.  I've also got a means for pulling a trace from a live board as a last resort. 

For VHDL, there's a simulation program called ghdl (it's not nearly as good as verilator :D ) that should work similarly for you.

Xilinx also provides a simulation capability, as well as an internal logic analysis capability.

Let me take this moment to *HIGHLY ENCOURAGE* you to learn how to use the tools you have at your finger-tips to avoid this problem in the future.  Why?  Your logic will only get more complex, and more difficult to debug.  The sooner you learn how to handle the tough problems, the sooner you'll be on the road to being a successful developer.

Dan

Link to comment
Share on other sites

I heartily second the recommendations of @Dan. The only things that I might add are the following:

  • Get adept at using the FPGA vendor provided simulation tools. For one thing they have an intimate knowledge of how the specific resources in the device that you are using behave. Very often compiling ( in the case of Xilinx ) the simulation code reveals problems that the synthesis tool overlooks. Dan loves his open source simulation tools, I'm not (yet) a believer. We don't use the same design processes. Simulation in Verilog is better supported than in VHDL. Regardless, he has learned the value of simulating in FPGA development.
  • There are two types of simulation.. behavioral and timing. Behavioral simulation for the most part deals with syntax and design issues. With timing simulation you use the post-routed netlist to get an idea of how a design might perform in an actual device. Both are essential parts of the FPGA design process. TIming simulation while often overlooked offers a more nuanced view of why a design might work one day and not the other. Thinking that because you created a bitstream and it appears to perform perfectly makes the design a good one is a novice mistake ( often made by seasoned developers ). This is complicated stuff here.
  • Simulation is a very good instructor for the beginning FPGA developer and vital to the expert practitioner.
  • Simulation doesn't catch all possible issues like PCB characteristics, thermal issues, external device behavior ( though you can sometimes get pretty far in that area ) bad pin assignments, etc.

There are no doubt other things to mention but I'll end with this. Dan's advice is the only proper and most helpful advice that you will get from anyone in response to this type of question.

Link to comment
Share on other sites

I did think of one other thing to say to the topic of simulation that I've not said before. 

If you believe that after years of experience with the FPGA development process it gets easier and  more predictable then you'd be wrong. What experience ( hopefully ) gets you is better insight, more useful tools in your personal toolbox, and better instincts on how to proceed with knotty problems. At some point, if you do this for a living, you will need to do complex high throughput work that will present problems that aren't readily solvable by your typical tried and true debugging methods. A design will seem to work on one build and then behave strangely on the next; even with a perfect timing score of 0, even with a good series of testbenches that say it should behave the way that you want it to, even with minor changes to the source code that are seemingly unrelated to areas that appear to be operating improperly. Even with custom instrumentation ( that alters the synthesis and place and route results ) figuring out how to move forward will be elusive. At this level even forcing a re-run of all of the processes involved in getting a bitstream without any changes to the source at all will provide inconsistent behavior in the target hardware from build to build. A this point you will have developed a good sense of what makes a good design and what doesn't.. and the complexity involved.

If you want to make it through these times then you'd better have some pretty awesome simulation skills.

Link to comment
Share on other sites

I'm afraid they are correct :( But no one really knows how the Vivado simulator works, sometimes it does, sometimes it doesn't. As far as I know, there isn't any simulator-simulator to test the simulator and figuring out why it won't simulate properly.

I just debug my VHDL code like I debug C, just stare at it long enough. But I know that doesn't cut it.

Link to comment
Share on other sites

@Tickstart,

I just watched a presentation at ORCONF comparing (two unnamed vendor simulators) with the new (open source) Verliator 4.0.  Performance/speed improvement was over 5x better than the vendor simulators.  Even better, if Verilator's "simulator" doesn't appear to be working, it's just C++ code.  I've debugged my design within that C++ code before, usually only to discover some obscure reality of HDL that the simulator got right but that I just mis-understood.

Even better, it's easy to integrate co-simulation into a Verilator based design.  Consider this design's use of co-simulation to create an on-screen image (i.e. window) of the VGA output of the given design.

You sure you want to use VHDL?  You are missing out on this wonderful Verilog only capability.  :D

As for debugging your code ...

  • Consider this UART 16550 design.  It's been used by the OpenRISC team for years.  The authors desk-checked it over and over, yet never quite realized that the transmitter could be made to send a byte that wasn't in the FIFO due to a race condition between the reset and the FIFO read request.  (The design tests for whether the FIFO is empty, and moves to the read FIFO state, the FIFO is then reset, then the design "reads" from an empty FIFO just getting random garbage.)
  • The conditions that would set this bug off aren't necessarily reliable--it's a race condition.  It will only happen if you reset the transmitter at just the right time.  Chances are that anyone who noticed a weird byte getting sent wouldn't notice it.  Typical debugging depends upon reproducibility.  Race conditions are rarely reproducible.
  • While I highly recommend bench testing at the module level, this design was bench tested.  Yet the author never found this race condition via a simple bench test.  I don't blame the author, since I also struggle to imagine all of the potential bugs I might come across when building a bench test.
  • I also highly recommend integrated simulation.  I've found lots of bugs through simulation.  The bug the OP wrote about would've revealed itself after enough clocks worth of simulation.  However, you may or may not find bugs like this UART 16550 one through simulation.
  • I found this particular UART transmitter bug with less than 30 minutes of staring at the core using formal methods.  It was quick, and certain--once I asserted that the FIFO should not be empty upon any read.  The free formal tool, SymbiYosys, works on Verilog files and finds bugs quickly and efficiently.  I know of no free formal verification tool for VHDL.  Again, are you sure you want to keep using VHDL?

Just sayin',

Dan

Link to comment
Share on other sites

5 hours ago, Tickstart said:

no one really knows how the Vivado simulator works, sometimes it does, sometimes it doesn't

Wow. Just when I think that there's something that you can say that isn't "amazing" you go and prove me wrong. I don't mean that in a good way. Just for the record, it's you, not Vivado simulator.

47 minutes ago, D@n said:

Again, are you sure you want to keep using VHDL?

OK, I admit it that there are times when I have the same thoughts ( sometimes I wonder why I do FPGA development at all...) . Of course when I do use Verilog ( you can't simulate MIG designs with VHDL ) I still use Vivado simulator. And sometimes customers require VHDL ( though that's getting less frequent ). As to the examples of "proof" of quality that you offer... I'm not convinced. I can write poor testbenches ( and often do ) that don't expose a flaw and be forced to write a proper one after gaining some insight as to what I need to be looking for as well as anyone else. That's how simulation works. Perhaps your suite of tools shortens this process, or makes it easier to get lucky without having a good understanding of what it is that you are trying to simulate... why wouldn't automating the process intelligently help? What you can;t demonstrate is that ModelSim ( the pricey version that understands Xilinx device behavior ) or Vivado simulator won't do the same thing. I get that you love your development process. I've just never come across it in practice by companies whose living depends on reliable FPGA based products. That's not proof of anything, just an observation.

How well does your toolset do timing simulation? Have you ever done one?

VHDL hasn't evolved with time the way that I'd like. Verilog has simulation features that make it superior to VHDL, especially for programmable logic. I readily concede these points.

Link to comment
Share on other sites

@zygot,

7 minutes ago, zygot said:

How well does your toolset do timing simulation? Have you ever done one?

I've spent my time doing logic simulation, and not so much timing simulations.  While I can simulate (logically) any logic running even at multiple clock rates, I've never gotten into the analog side of how/when transitions actually take place.  In my opinion, I haven't needed it.  Maybe there's something I'm missing.  That''s not to say there's no use for it--I just don't feel like I've needed it.

As to your first question, Verilator simulates sequential (i.e. clocked) logic, and it does so very well.  While it will also do asynchronous logic, it doesn't necessarily model any timing delays in that process.

Dan

Link to comment
Share on other sites

10 minutes ago, D@n said:

@zygot,

I've spent my time doing logic simulation, and not so much timing simulations.  While I can simulate (logically) any logic running even at multiple clock rates, I've never gotten into the analog side of how/when transitions actually take place.  In my opinion, I haven't needed it.  Maybe there's something I'm missing.  That''s not to say there's no use for it--I just don't feel like I've needed it.

As to your first question, Verilator simulates sequential (i.e. clocked) logic, and it does so very well.  While it will also do asynchronous logic, it doesn't necessarily model any timing delays in that process.

Dan

No, that's not timing simulation. Timing simulation, as I pointed out earlier uses a specially formatted post-route netlist representing how your device is going to be configured. It is also, as I pointed out earlier is a vital part of the process when you have to produce reliable products. Neither ISE nor Vivado provide this netlist unless you ask nicely. On reason why people don;t do it as often as they should is because it takes a whole lot longer to simulate than a behavioral simulation. And because your device becomes more of a black box since most of your source signal have been replaced by synthesis optimization ( though you can preserve signal names in your code if you need to..)

Now that I think about it, since the timing netlist format is well known it should be possible for your tools to perform it. Since I don't use your tools I can't say one way ro the other...

 

Link to comment
Share on other sites

@D@n,

I thought that the topic was (turned into by you) developing simulation skills... ( I really want to make a snide comment but ... Ah... it's past... We can agree that the poster need to get started. I can admit that I've not arrived at simulation Nirvana.

Clearly, some posts have questions that, in order to properly answer, raise complicated topics. Clearly, there people who wander into discussion threads and might benefit from exposure to that complexity. But, I won't argue the matter.

Link to comment
Share on other sites

This is my last comment on this thread... I promise.

My reason for taking the time and effort to post replies to Digilent technical forums hinges on learning, not resolving problems ( OK sometimes it's about fixing problems ). Being reminded of the complexity the FPGA process for even seemingly simple questions seems to me to offer an opportunity for all readers, of every level of experience and skill, to expand their mental horizons. It seems to me that having the beginner realize that even those with a lot of expertise are still in the learning phase of their lives is profitable. For those who feel pretty confident about their skills being reminded that there's always room for improvement is also profitable. This post could probably serve as a footer for all of my posts.

[edited] In the spirit of spreading enlightenment instead of confusion it seems to me to be necessary for anyone seeing incorrect information being posted to challenge it. I hope that none of my gaffes go unchallenged.

Link to comment
Share on other sites

On 9/25/2018 at 5:16 PM, zygot said:

Wow. Just when I think that there's something that you can say that isn't "amazing" you go and prove me wrong. I don't mean that in a good way. Just for the record, it's you, not Vivado simulator.

Heh, don't get me wrong, I'm fully aware of this fact =D

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...