Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,075 Views

up counter needs fixing - confused . simple question

Hi, this is a simple counter with asynch pre-set(not wired in diagram), enable, load and synch add +1. i can't figure the trick to get rid of one extra mux column and use the FF enable (where red arrow is). Do you have any ideas please? 

 

cheers. Pretty sure there's a way to do it....
0 Kudos
17 Replies
Altera_Forum
Honored Contributor I
139 Views

Without the code - it is difficult to tell what to do to fix it.

Altera_Forum
Honored Contributor I
139 Views

something like this, though i tried different combinations for the 'if' condition, as in in different places or using 'elseif', yet still same result... 

 

process(clk, rst) 

variable cnt : unsigned(3 downto 0) 

begin 

if rst = '0' then 

cnt := (others => '1'); 

elsif rising_edge(clk) then 

if load = '1' then 

cnt := new_data; 

end if; 

if ena = '1' then 

cnt := cnt +1; 

end if; 

end if; 

cnt_out <= cnt; 

end process;
Altera_Forum
Honored Contributor I
139 Views

thats because your enable isnt acting as an enable. cnt_out is a combinatorial version of cnt+1 or cnt, using the enable bit to select. This is because you used a variable for cnt, and then assigned it to a signal after you've done +1 

 

The fix : remove the variable complelely and use signals instead. Switch to vhdl 2008 and replace cnt with cnt_out. 

Variables can cause these issues as the ordering of the code can affect the circuit. If you used only signals, then you probably wouldnt have had this problem.
Altera_Forum
Honored Contributor I
139 Views

thanks tricky. i tried with signals too, still same issue. may be the vhdl version. i shall try again and post what happened. does it make much difference wheatear the FF ena is used or like in this case, going to a set of muxes? i'm kinda obsessed with making logic efficient and using least as possible, but some times not sure if it a good thing to do or not.

Altera_Forum
Honored Contributor I
139 Views

 

--- Quote Start ---  

thanks tricky. i tried with signals too, still same issue. may be the vhdl version. i shall try again and post what happened. does it make much difference wheatear the FF ena is used or like in this case, going to a set of muxes? i'm kinda obsessed with making logic efficient and using least as possible, but some times not sure if it a good thing to do or not. 

--- Quote End ---  

 

 

one point: you statement 

cnt_out <= cnt; 

 

is outside clk edge but not in sensitivity list. simulation will not work
Altera_Forum
Honored Contributor I
139 Views

i'll have a look kaz. i just wrote the code snippet quickly as i don’t have quartus available at the moment. shall check tonight and post.... thanks for supporting too, great people

Altera_Forum
Honored Contributor I
139 Views

I fixed it :). super. this is what made me realize : 

 

 

--- Quote Start ---  

thats because your enable isnt acting as an enable. cnt_out is a combinatorial version of cnt+1 or cnt, using the enable bit to select.  

--- Quote End ---  

 

 

it works both with signals and variables, have a look :  

 

process(clk, rst) variable sig_pc : unsigned(n downto 0); begin if rst = '0' then sig_pc := (others => '1'); elsif falling_edge(clk) then if pc_en = '1' then sig_pc := sig_pc +1; if pc_ld = '1' then sig_pc := unsigned(pc_new); end if; end if; end if; pc_out <= std_logic_vector(sig_pc); end process; 

 

awesome. thanks all. great
Altera_Forum
Honored Contributor I
139 Views

 

--- Quote Start ---  

thats because your enable isnt acting as an enable. cnt_out is a combinatorial version of cnt+1 or cnt, using the enable bit to select. This is because you used a variable for cnt, and then assigned it to a signal after you've done +1 

 

The fix : remove the variable complelely and use signals instead. Switch to vhdl 2008 and replace cnt with cnt_out. 

Variables can cause these issues as the ordering of the code can affect the circuit. If you used only signals, then you probably wouldnt have had this problem. 

--- Quote End ---  

 

 

Tricky, I am not sure you are right here. 

cnt is used before assigning it to itself so a register should be generated for the variable. so enable should work and takes priority over load. 

I know for sure such counters work with variables. Though I personally use variables very occasionally. 

I think the problem may be in the last statement outside clk edge.
Altera_Forum
Honored Contributor I
139 Views

 

--- Quote Start ---  

Tricky, I am not sure you are right here. 

cnt is used before assigning it to itself so a register should be generated for the variable. so enable should work and takes priority over load. 

I know for sure such counters work with variables. Though I personally use variables very occasionally. 

I think the problem may be in the last statement outside clk edge. 

--- Quote End ---  

 

 

But the enable overrides load, because they are two separate ifs. So actually its a 3:1 priority mux with cnt+1, new_data or cnt. 

So while I agree I was initially wrong, and it should work with the cnt variable, the fact it's two separate ifs and not an elsif will be the problem.
Altera_Forum
Honored Contributor I
139 Views

 

--- Quote Start ---  

But the enable overrides load, because they are two separate ifs. So actually its a 3:1 priority mux with cnt+1, new_data or cnt. 

So while I agree I was initially wrong, and it should work with the cnt variable, the fact it's two separate ifs and not an elsif will be the problem. 

--- Quote End ---  

 

 

Yes that is a good point. It does not follow standard design 

The way I view it is as follows: 

 

 

--- Quote Start ---  

 

load enable cnt 

0 0 no change of cnt 

0 1 count up, may not get initialised 

1 0 load value to cnt 

1 1 count up 

 

--- Quote End ---  

Altera_Forum
Honored Contributor I
139 Views

the way you guys describe solutions is kinda how you want to synthesizer to design the logic for your needs. I think that's very power full and is gained after years of experience. This one for example : 

 

 

--- Quote Start ---  

load enable cnt 

0 0 no change of cnt 

0 1 count up, may not get initialised 

1 0 load value to cnt 

1 1 count up  

--- Quote End ---  

 

 

Would you kindly explain this methodology please Kaz? As in how you picture the logic will be for the code you describe and the other way round, how do you describe code to get these states (if it makes sense) ? 

 

Also one more thing, in the picture I attached the Load input is driving multiple multiplexers. Is there a trick behind the scenes that takes care of the driving capabilities inside the FPGA. As in can one input drive all that logic at one internally? (is my question clear here?)
Altera_Forum
Honored Contributor I
139 Views

 

--- Quote Start ---  

 

Also one more thing, in the picture I attached the Load input is driving multiple multiplexers. Is there a trick behind the scenes that takes care of the driving capabilities inside the FPGA. As in can one input drive all that logic at one internally? (is my question clear here?) 

--- Quote End ---  

 

 

It is driving muxes because altera registers do not have synchronous inputs, other than D. So synchronous set/reset have to be emulated with logic - hence the muxes.  

Im not exactly sure what your question means - but assuming the design meets timing then this is pretty standard behaviour..
Altera_Forum
Honored Contributor I
139 Views

So lets say we have 64 DFFs (as in picture attached) each requiring a clk, rst and enable in parallel. I guess that's quite a lot of driving current needed right?  

 

1. how do i measure the actual driving current needed? 

2. is it good practice to connect all 64 (clk, rst and ena) together in parallel like in the picture, and drive them from just one input? 

3. say clk is driven internally from a PLL, can the PLL drive all those FF? can it supply enough current to all? Or is there a limit some where in a datasheet? 

4. say rst is driven from an external pin, can this pin handle the current needed? 

5. transient currents create a lot of noise... 

6. are there any fanout techniques used internally in the FPGA to split signals, like clk, rst and ena, in this case, to say groups of 8?
Altera_Forum
Honored Contributor I
139 Views

 

--- Quote Start ---  

So lets say we have 64 DFFs (as in picture attached) each requiring a clk, rst and enable in parallel. I guess that's quite a lot of driving current needed right?  

 

1. how do i measure the actual driving current needed? 

2. is it good practice to connect all 64 (clk, rst and ena) together in parallel like in the picture, and drive them from just one input? 

3. say clk is driven internally from a PLL, can the PLL drive all those FF? can it supply enough current to all? Or is there a limit some where in a datasheet? 

4. say rst is driven from an external pin, can this pin handle the current needed? 

5. transient currents create a lot of noise... 

6. are there any fanout techniques used internally in the FPGA to split signals, like clk, rst and ena, in this case, to say groups of 8? 

--- Quote End ---  

 

 

you don't have to worry about electrical level.  

 

just follow templates and check timing
Altera_Forum
Honored Contributor I
139 Views

Assuming you have connected the FPGA to the board as per the instructions in the data sheet with the correct Vcc and Ground Pins, then current draw wont be a worry as it will always be within the spec on the datasheet. 

There is a power analysis tool that can run your design through to give estimated power draw for your design, but that may be a bit advanced for what you are doing. 

 

Just be assured that if the design fits in the device and meets timing (and you have designed it to correct correctly with the connected IOs) then it will work.
Altera_Forum
Honored Contributor I
139 Views

thanks for the observations. Quite advanced yes. Was just thinking about it so i asked.

Altera_Forum
Honored Contributor I
139 Views

 

--- Quote Start ---  

So lets say we have 64 DFFs (as in picture attached) each requiring a clk, rst and enable in parallel. I guess that's quite a lot of driving current needed right?  

 

1. how do i measure the actual driving current needed? 

2. is it good practice to connect all 64 (clk, rst and ena) together in parallel like in the picture, and drive them from just one input? 

3. say clk is driven internally from a PLL, can the PLL drive all those FF? can it supply enough current to all? Or is there a limit some where in a datasheet? 

4. say rst is driven from an external pin, can this pin handle the current needed? 

5. transient currents create a lot of noise... 

6. are there any fanout techniques used internally in the FPGA to split signals, like clk, rst and ena, in this case, to say groups of 8? 

--- Quote End ---  

 

 

 

Your electrical question was answered, but not the others. 

 

1: Powerplay power analyzer, as mentioned. 

2: There is no issue with driving all 64 locations as long as the design meets timing. 

3: Yes, the PLL can drive all of them, either using local routing or global routing. As mentioned, you don't have to worry about current. 

4: Same answer. 

5: In the past, simultaneous switching noise, large numbers of physically close I/O pins switching levels simultaneously, could affect pins that weren't switching, potentially glitching the pins not switching. This could still be an issue with older devices, but most newer ones don't have a problem with it (the SSN analysis tool was removed from the Quartus software a while ago). 

6: Absolutely. This is usually necessary for high fanout timing issues (so much fanout that destination logic needs to be placed further and further from the source, causing setup timing issues). The main recommendation is to perform register duplication directly in your HDL code. This gives you the most control. However, Quartus does include a max fanout constraint and a register duplication constraint you can use in the Assignment Editor to do this without altering your code.
Reply