VHDL JK FlipFlop Error, Please help

--- 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.

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.

You can use after to stimulate a transport delay.

For example

A <= b after 5 ns.

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.

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.

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.

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.

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.

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