Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

VHDL JK FlipFlop Error, Please help

Altera_Forum
Honored Contributor II
3,967 Views

Hello. As you can see in the figure 1, We can make a JK flipflop with 2 ANDs and 2 NORs and two internal signals. 

So I've written a very simple code in ModelSim to make and simulate a JK FlipFlop (Figure 2 - the code and Figure 3 - the benchmark which I simulated it in the software) but the problem is, the output of the flipflop is always same. (Figure 4) What is wrong with the outputs? 

 

I know there are different ways to make a JK FlipFlop, but this is the way that I should make as a part of an other project, yet I have no clue why the outputs are not working. 

 

Fig 1 - click to enlarge: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=12271&stc=1  

Fig 2- click to enlarge: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=12275&stc=1  

Fig 3 - click to enlarge: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=12273&stc=1  

Fig 4 - click to enlarge: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=12274&stc=1
0 Kudos
19 Replies
Altera_Forum
Honored Contributor II
1,171 Views

Did you map yoir testbench signals to the ports of your JK entity? 

You can also add the i1 and i2 signals to look "inside" th4 flip-flop and see if those change"
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

well as you can see I just mapped the signals in the testbench, there is a question here. should I also port map a signal in the JK code?

0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Sorry read over your port map.  

I don't really see anything wrong in your jk code, but you should not use the type buffer. Use an internal signal for the Q's and then put those on an output. But this is more bad practise than not working code. 

 

As for the test bench, which entity do you declare the architecture for?
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

There are 2 errors at the above code: 

 

Note that you defined Q correctly as being resulted from I1 and Qp. 

However, I2 isn't C and Qp and k, but j instead. 

The same correction must be done to the other signal.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Oh yes, thank you. I corrected that still don't work. This project got canceled.

0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Your test bench architecture will replace your JK architecture due to identical naming. I would assume you got some warnings loading the project.

0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

 

--- Quote Start ---  

Your test bench architecture will replace your JK architecture due to identical naming. I would assume you got some warnings loading the project. 

--- Quote End ---  

 

I guess I have never seen a warning while simulating it I actually never paid attention to this while simulating it. But I'm sure there was no warnings while compiling the scripts.  

But good point, I just corrected that. I think I just did that mistake by editing the file too much. 

 

Well after another simulation test and now paying attention to the warnings, nothing changed however I noticed these messages: 

# vsim -voptargs=+acc work.testshjkff # ** Note: (vsim-3813) Design is being optimized due to module recompilation...# # Loading std.standard# Loading std.textio(body)# Loading ieee.std_logic_1164(body)# Loading work.testshjkff(arch)#1# Loading work.shjkff(arch)#1# Loading work.shjkff(arch)# ** Warning: (vsim-3035) Instantiation depth of '/testshjkff/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF' is 51. This might indicate a recursive instantiation. Increasing limit to 75.# # ** Error: (vsim-3036) Instantiation depth of '/testshjkff/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF/HwshJKFF' is 75. Assuming recursive instantiation.#  

It's weird that it is instantiating recursively. 

0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Its not weird - you've written : 

 

archtiecture arch of shJKFF is 

 

instead of  

 

architecture arch of testhsJKFF is 

 

this means the architecture in the testbench overrides the one in the JKFF file, which will then call the instantiation recursively.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

As I mentioned in a sentence before that sentence, I've corrected that mistake. Here is the full testbench code: 

http://oi65.tinypic.com/15n95zc.jpg  

this code gives me those warnings. wierd. 

 

Here is the all VHDL files, I'd be glad if someone check them and see if they're working. 

download here (https://www.mediafire.com/?53t544z55q0hhea)
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Ive run and tested the code - I dont know what code you're compiling to get the error you are, but I just got an iteration error because Q depends on Qp which depends on Q. The errors you are reporting are because of the old issue. did you forget to recompile the code and restart the simulation? 

 

To make this model correctly, you need to put delays between q and qp, but these are not synthessiable.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

 

--- Quote Start ---  

Ive run and tested the code - I dont know what code you're compiling to get the error you are, but I just got an iteration error because Q depends on Qp which depends on Q. The errors you are reporting are because of the old issue. did you forget to recompile the code and restart the simulation? 

 

To make this model correctly, you need to put delays between q and qp, but these are not synthessiable. 

--- Quote End ---  

 

 

I always recompile and restart the simulation, I'm sure I've tested the newest compiled VHDL file. And about the delay, since I'm new to this software, would you tell me how to add delays? I coulnd't find a clue to do so.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

wait on <signal(s)> --wait on signals to change wait for <time> --wait for the specified ammount of time wait until <boolean expression>-- wait until the expression is true 

 

In this case I would use wait for to simulate the propagation delay, and set it to 7ns or something like that, with a simulation resolution of 1 ns. But if you have long wait times between the stimuli you could use higher factors for both.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

You can use after to stimulate a transport delay. 

 

For example 

 

A <= b after 5 ns.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Greetings All: 

Has there been any simulation of the JK Flip-Flop been successful? I have been looking at that to see why Quartus makes warnings on latches or any 'Found combinational loop' issues. Now I see why that creates a warning. 

I had to add a reset, before that it woke up in 'unknown' state in simulation (Quartus 9.1 using .vwf by the way). I tried to make an 'edge clock detector', ie. having an invertion, and say 'edge = '1' when clock = '1' and clock_n = '1' else '0', but that was optimized away by Quartus, and I didn't make it to add the LCELL part to add the propagation delay yet. So I made the clock to a 2% cycle (50% clock always caused oscillation with J & K hi) and tried some seeds, and it made to work properly with 'seed 9'. 

That's interesting, however, if you have a project with that everywhere, the chances of having all of them not going into oscillation approaches zero, thus why the warning. I recommend using a register using the 'if rising_edge(clock)' and define what the four input sates require for the output pin responses. 

I have attached the project using the Quartus 9.1 version, with the part EP2C25FC7 for 'DE1 Altera', and it uses the built in simulation. If any others products or compilation programs are used, it may need trying other seed values, many don't work properly. 

 

I hope all find that interesting. 

 

David K.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

It worked!! The only problem was I should have also update the "work library" of the software each time I recompile the VHDL files. Also I've added the delays when internal signals wanted to get info from Q an Qp and it works like a a JK Latch, I guess (apparently). Here is the results and the modified VHDL file: 

https://i.imgsafe.org/2c9d185abe.jpg  

https://i.imgsafe.org/2c9d100dd9.jpg  

Thank you for your replies. 

 

edit: 

 

--- Quote Start ---  

Greetings All: 

Has there been any simulation of the JK Flip-Flop been successful? I have been looking at that to see why Quartus makes warnings on latches or any 'Found combinational loop' issues. Now I see why that creates a warning. 

I had to add a reset, before that it woke up in 'unknown' state in simulation (Quartus 9.1 using .vwf by the way). I tried to make an 'edge clock detector', ie. having an invertion, and say 'edge = '1' when clock = '1' and clock_n = '1' else '0', but that was optimized away by Quartus, and I didn't make it to add the LCELL part to add the propagation delay yet. So I made the clock to a 2% cycle (50% clock always caused oscillation with J & K hi) and tried some seeds, and it made to work properly with 'seed 9'. 

That's interesting, however, if you have a project with that everywhere, the chances of having all of them not going into oscillation approaches zero, thus why the warning. I recommend using a register using the 'if rising_edge(clock)' and define what the four input sates require for the output pin responses. 

I have attached the project using the Quartus 9.1 version, with the part EP2C25FC7 for 'DE1 Altera', and it uses the built in simulation. If any others products or compilation programs are used, it may need trying other seed values, many don't work properly. 

 

I hope all find that interesting. 

--- Quote End ---  

 

Well as I stated in this message, it apparently works now. About the code, yes it is kinda interesting to see why that happens. Actually my project was for education and we were not allowed to use clocks or flipflops or registers (we ourselves should make them) and I guess your approach is not only better but also suitable for professional basis.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Greetings All: 

I hope the simulation is going well. I've used ModeSim a few times, but I usually stick with the Quartus 9.1 simulation, it has no capability of intelligent response to the FPGA's, but it's much faster and easier to run quickly, especially small projects. I notice the code just posted has the 'after 100ns' added, that is used in testbench parts, but if code is targeted to real hardware, such a FPGA/CPLD, it is ignores or causes an error, there's no capability to perform that in most hardware. 

I put together some information of the the testing I have been doing, take a look. I put up a screenshot showing what happens if I use a different seed. Using seed 5 gets Quartus to place the code's hardware in different logic elements place (compared to seed 9), and that makes the feedback time and path different, and most cause oscillation. 

I was looking at the actual electronics to see how it maintains the oscillations running even if all inputs are off. The simulation under LTSPICE, if any of RC component is altered, it stabilizes quickly after a few changes. I'm guessing the feedback path inside FPGA's is more complex than the 2-RC stage paths. I have shown a zoom in on the waveforms of the JK flip-flop. Notice the oscillation is off-sided, I couldn't get that to happen under the LTSPICE simulation, it's probably due to the simple feedback paths I made for simulation. 

Also, the zoom picture shows the propagation delay between clock edge and the response. On the previous simulation shown, take a look zooming on that to see how the propagation delay between the clock and response are in comparison. 

I noticed the D changes happen at the same as the clock falling edge, there are changes when there is no clock changes (200ns, much beyond hardware propagation), and clock rising with J and K high does not cause the Q toggle as required, like my previous picture showed. 

 

I hope all find this is informative. 

 

David K.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Changing the seed just changes how the fitter places the design. The seed is actually based on your source code and the fit seed, so you cannot get reproducible results. Asynchronous logic in FPGAs is prone to all sorts of variation in timing, the first being the placement, but also fluctuations in voltage, temperature and process (ie. one chip is not identical to another chip). 

 

Basically, asynchronous logic in an FPGA is not usually a good idea. 

 

to D4N005H: your code now simulates, but will not be anything like the simulation on hardware. You're at the mercy of the variability I mentioned above.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

Greetings All: 

Tricky, I used the same source code and changed only the fitter seed several times to see if it was possible to stabilize the feedback oscillation under simulation. You are correct, any change will cause a different result, which is why I posted the Quartus version and chip target. I guessing changing the temperature range may change the propagation time for simulation. In real life, the chip's path times will change over temperature, voltage, other logic switching, and another chip of the same type, just as you have mentioned. 

I have taken a couple screenshot, one shows the layout using seed 5, and the other using seed 9. That's what I expected, it would fit them in a different place. Since I didn't assign the pins used, it also placed the ports to different pins, that surprised me. Here are the propagation times listed under both positions... 

 

Using Seed 5 

+--------------------------------------------------------------+ ; tpd ; +-------+-------------------+-----------------+-------+--------+ ; Slack ; Required P2P Time ; Actual P2P Time ; From ; To ; +-------+-------------------+-----------------+-------+--------+ ; N/A ; None ; 11.836 ns ; clock ; qn_out ; ; N/A ; None ; 11.737 ns ; k_in ; qn_out ; ; N/A ; None ; 11.677 ns ; reset ; qn_out ; ; N/A ; None ; 10.784 ns ; j_in ; q_out ; ; N/A ; None ; 10.709 ns ; j_in ; qn_out ; ; N/A ; None ; 10.674 ns ; clock ; q_out ; ; N/A ; None ; 10.390 ns ; k_in ; q_out ; ; N/A ; None ; 10.330 ns ; reset ; q_out ; +-------+-------------------+-----------------+-------+--------+ 

 

Using seed 9 

+--------------------------------------------------------------+ ; tpd ; +-------+-------------------+-----------------+-------+--------+ ; Slack ; Required P2P Time ; Actual P2P Time ; From ; To ; +-------+-------------------+-----------------+-------+--------+ ; N/A ; None ; 13.884 ns ; clock ; q_out ; ; N/A ; None ; 13.608 ns ; j_in ; q_out ; ; N/A ; None ; 13.607 ns ; reset ; q_out ; ; N/A ; None ; 13.153 ns ; reset ; qn_out ; ; N/A ; None ; 13.043 ns ; k_in ; q_out ; ; N/A ; None ; 12.835 ns ; clock ; qn_out ; ; N/A ; None ; 12.589 ns ; k_in ; qn_out ; ; N/A ; None ; 11.718 ns ; j_in ; qn_out ; +-------+-------------------+-----------------+-------+--------+ 

 

...I notice there is no time reported from Q to Qn, or vice-versa, that is the cross-feedback path which causes the oscillation. The simulations has those path timing, so they must be stored somewhere. Perhaps the newer timing analyzer has better capability. 

 

A while ago I did some simulation testing on the latch capability to emulate a real chip that latches the data. I adjusted the time offset between the clock and the data in thousands of times by pico-seconds. It never oscillated, but yes, gives the latch warning. It did however, work in real life in the FPGA, and behaved as expected. If latches are chosen on purpose (which creates the latch warning), to they have any simulation or real life issues? 

 

I hope that's interesting. 

 

David K.
0 Kudos
Altera_Forum
Honored Contributor II
1,171 Views

I typed in your VHDL source, compiled it (Quartus 13) planned pins: a LED on pins Q and Qp, J K and C on switches.  

 

When clock = '1' also J and K high, the output q and qp go to the input which changes the output. 

The result is weak light of LED's because output changes with a frequency determined by the propagation delay. 

 

One of two leds is full on and the other LED off when clock is low.  

Which one of the LED's depends on the moment the clock is going low. 

 

Solution: insertion just before the end architecture line a wait on (c); statement, however correct syntax for VHDL it is not accepted by the quartus compiler because the compiler omits sensitivity list (c), and hence announces the stripped wait on as a fatal error 

 

Tks Tricky on this forum for his/her help
0 Kudos
Reply