- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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....Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Without the code - it is difficult to tell what to do to fix it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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 ---
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks for the observations. Quite advanced yes. Was just thinking about it so i asked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page