Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Fri, 28 Jul 2006 11:33:25 -0700, Mike Treseler <mike_treseler@comcast.net> wrote: > BobG wrote: >> I read the whole thread and no one recommended "The Art Of Electronics" >> by Horowitz and Hill?? > > That's more of an electronics book than an RTL book. It _is_ an electronics book. There is one mention of RTL, but it's 'resistor-transistor logic'. Not quite the same thing. A bientot Paul -- Paul Floyd http://paulf.free.fr (for what it's worth) Surgery: ennobled Gerald.Article: 105701
Ayon kay PeteS: > yy wrote: > > Hi, > > I have a Working Universal PCI Evaluation Kit (Spartan3) without any > > Bus Switches/resistors etc. The package name is 'TruePCI', and it works > > fine with a motherboard that have 5V slots. The bank VCCO of Spartan 3 > > is wired to +3.3V, many have said that bus switches are needed in order > > to connect Spartan 3 to PCI? But then this board seems to work pretty > > well, Any ideas? BTW, what i'm building is a specialized pci board. > > > > Thanks. > > Bus switches may be necessary in a system that pushes the PCI spec to > it's limits. What you can get away with on an eval kit is not what you > can get away with if you are making something that is required to meet > the PCI 2.2. Spec. > > Note very carefully that you can get away with a LOT at 5V that simply > won't work at 3.3V, and indeed vice versa. I had an 'improved' part > some years ago from Intel where it quit working in an existing design > at 3.3V. Apart from that, have you tried it with a unit that has 3.3V > slots (to match your VIO)? That's a completely different test than you > are doing. > > You don't say what the board you are designing is: is it a drop-in PCI > board, or a self contained unit that has a PCI interface between some > units on it? If it's self contained, there are things you can get away > with as you don't have to interface to the outside world (been there, > done that). > > Cheers > > PeteS PeteS, It is a PCI master/target card connected to an SBC(Single Board Computer) with 5V PCI. The SBC has only one edge (male edge) such that i will be designing the board to have an edge connector(female). -yyArticle: 105702
Hi ! I am new in electronique. I want to make an analog acquisition board with an ARM microcontroler ( Samsung S3C44B0x 66MHz) with a 8Mbytes SDRAM and an A/D converter( Analog AD775 ). The sampling rate of the A/D converter is at 30Mhz, and i would like to connect its digital output to the S3c44b0x data bus by using the DMA of the uC. Data sent by the ADC will be wrote to the SDRAM by using the DMA of uC. But the number of sampling can be very large, and the acquisition/transfert occur at a fixed rate (30 Mhz). The acquisition time and transfert to SDRAM can be more than 64ms (refresh time cycle of SDRAM). So, my question is : is the internal refresh cycle of SDRAM can disturb the data writing by the DMA to the SDRAM ? The ADC send data to the SDRAM through the DMA at a fixed rate during may be 1 or 2 second, and is this process can be stopped/disturbed by the internal refresh process of SDRAM ? If yes, is there a solution, to manage the two process ( fixed acquisition and SDRAM refresh cycle) ? Thank you very much.Article: 105703
Hi Mike,
Thank you.
Weng
mikegurche@yahoo.com wrote:
> You can assignee an initial value when a variable or signal is
> declared, e.g.,
>
> signal mysig: std_logic := '0';
>
> This will be the initial value when simulation starts. According to
> VHDL LRM, if there is no initial value, the first value defined in the
> data type will be used. Since std_logic is defined as ('U', 'X', '0',
> ...) in 1164 package. The 'U' value (for uninitialized) will be the
> default value.
>
> Since the initial value cannot always be synthesized, this approach
> should not be used in synthesis. It is better to use an explicit reset
> mechanism to initialize a sequential circuit.
>
> Mike G.
>
>
> Weng Tianxiang wrote:
> > Hi Mike,
> > Thank you for your response.
> > Now what is the first value after system asynchronous reset for first
> > loop?
> >
> > Thank you.
> >
> > Weng
> >
> > Mike Treseler wrote:
> > > Weng Tianxiang wrote:
> > >
> > > > In the following statement:
> > > > var := (var - 1) mod var_limit;
> > > > var is not assigned any value before it is used. var_limit is a
> > > > constant, of course.
> > > > Anything is wrong?
> > >
> > > No.
> > > For simulation, the present value is used
> > > to calculate and save the expression value.
> > > For synthesis, this is infers a register to save
> > > the value for the next process loop.
> > >
> > > -- Mike Treseler
Article: 105704RobJ wrote: > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:1154099086.215982.7080@m79g2000cwm.googlegroups.com... > > While reviewing the code that the FPGA group has produced, I saw > > something that looks bad. It is not likely to affect the > > functionality, but it is not good coding style and may use extra > > resources. > > > > They are using Verilog which is not my first HDL language and I am not > > as familiar with it as I am VHDL. But because the case statement is > > not fully specified the code below appears to me to produce more > > complex logic than needed. > > > > always @ (negedge rst_n or posedge clk) begin > > if (!rst_n)begin > > mask_wr <= 1'b0; > > clear_wr <= 1'b0; > > end > > else begin > > if (wr == 1'b1)begin > > case (adr [2:1]) > > MASK: mask_wr <= 1'b1; > > CLEAR: clear_wr <= 1'b1; > > endcase > > end > > else begin > > mask_wr <= 1'b0; > > clear_wr <= 1'b0; > > end > > end > > end > > > > The real code is controlling 20 or so signals and is very large so this > > is very simplified. At first I didn't notice the enclosing "always" > > statement and thought it would produce a latch. Now I realize that it > > will make enabled registers when what is really desired is just > > decoders followed by registers. I guess in the grand scheme of things > > this is not a big issue. But wouldn't it make a more streamlined > > result to code the logic separate from the register? Then the logic > > would just be decodes of the address bus and the control signal and the > > register would not have separate enables. > > > > Rick - > > This looks fine to me. It's easy to read and will function correctly, plus > the case statement and use of parameters make it easy to modify. Given what > I've heard of your relationship with the FPGA group, I would not flag this > if I were you. It would be nitpicking. I never said I was going to "flag" it. I was just asking for some help understanding how Verilog worked. If it were VHDL I would know for certain how the synthesizer would handle it. But I am pretty confident that this will be less efficient than a properly constructed description. That is how I code differently from a lot of people. Many designers "program" in the HDL. I design my hardware in block diagrams and use the language to describe my hardware. The above code certainly functions correctly, but it would be just as clear, if not more so to separate the logic and the register. A register description is very, very simple and small. These can be put after the logic or they can be lumped together in a register bunch at the end of the module. The above program coded as logic would have a separate assignment for each signal. These assignments would not have any unspecified conditions and so would implement very efficiently and of course no latches. Expand the above code to 12 address lines and 25 signals and you will see how inefficient this could get.Article: 105705
John_H wrote:
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:1154101628.534694.304340@s13g2000cwa.googlegroups.com...
>
> > Two FFs and four logic elements (x15 in the real circuit). You have to
> > use a LUT to drive the D input and you have to use a LUT to drive the
> > enable input. Of course you can feedback the output to the input and
> > not use the clock enable, but that will also use more LUTs depending on
> > if you have the extra inputs or not on the LUTs you are using. But
> > this will be up to the tool and many times I see the tool generating
> > logic to feed the clock enable.
> >
> > It is not a big deal. I tend to think of things like this when I code
> > in an HDL just so I know my logic generation is lean. Originally I had
> > not seen the enclosing always statement and was thinking it was
> > generating a latch. Once I started looking at it I realize the latch
> > was not an issue but thought about the extra logic being generated. I
> > tend to separate my registers from my logic just to allow me to
> > optimize this sort of thing.
>
> You're taking the code structure as a literal guide for synthesis. There
> will be two FFs and two LUTs without a clock enable. Synthesis typically
> knows what simple logic breaks down to and how to best implement it. If you
> go into the technology view of your synthesizer to look at one of the flops,
> expect to see only one LUT driving it, no clock enable involved.
With this simple example you are right, it will require a single
4-input LUTs even if you don't use the CE. The logic functions only
has four inputs and so can be done in a single 4-input LUT. They are
wr, the two address bits and the feedback from the given register. But
if there is one more address line the feedback will push it to a pair
of LUTs. Like I said, it is not a huge difference, but with the large
number of signals in the real code, this could have been done very
slightly different and would have been optimal.
I realized that a simple change would not be any more typing and would
fully specify the assignments to eliminate the need for the feedback
signal. At least if this works like VHDL it would work correctly.
Like I said, I am not up to speed in Verilog anymore.
always @ (negedge rst_n or posedge clk) begin
if (!rst_n)begin
mask_wr <= 1'b0;
clear_wr <= 1'b0;
end
else begin
mask_wr <= 1'b0;
clear_wr <= 1'b0;
if (wr == 1'b1)begin
case (adr [2:1])
MASK: mask_wr <= 1'b1;
CLEAR: clear_wr <= 1'b1;
endcase
end
end
end
Rather than specify the default condition in the ELSE of the if
condition, it is specified first as the default. Then any signal that
is not assigned in the case statement will still be defined. The above
is the intended function rather than holding the previous state of the
signal. But then like I said in another post, I don't code behavior
and let the tools determine the logic, I describe logic which has the
behavior I want.
Article: 105706On Fri, 28 Jul 2006 08:04:46 -0700, rickman wrote: > While reviewing the code that the FPGA group has produced, I saw > something that looks bad. It is not likely to affect the > functionality, but it is not good coding style and may use extra > resources. > > They are using Verilog which is not my first HDL language and I am not > as familiar with it as I am VHDL. But because the case statement is > not fully specified the code below appears to me to produce more > complex logic than needed. > > always @ (negedge rst_n or posedge clk) begin > if (!rst_n)begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > end > else begin > if (wr == 1'b1)begin > case (adr [2:1]) > MASK: mask_wr <= 1'b1; > CLEAR: clear_wr <= 1'b1; > endcase > end > else begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > end > end > end > > The real code is controlling 20 or so signals and is very large so this > is very simplified. At first I didn't notice the enclosing "always" > statement and thought it would produce a latch. Now I realize that it > will make enabled registers when what is really desired is just > decoders followed by registers. I guess in the grand scheme of things > this is not a big issue. But wouldn't it make a more streamlined > result to code the logic separate from the register? Then the logic > would just be decodes of the address bus and the control signal and the > register would not have separate enables. The only problem with that code is the lack of a default statement. Without a default statement the synthesizer will screw it up because the undefined cases won't be treated as do nothing. If you add a default statement then the synthesizer will do the right thing.Article: 105707
I need to generate signals to dim incandescent lights to one of 16 dimming levels. I have built a 14-bit counter, which gives 16 discrete signals when used with always-on and always-off signals. To properly dim my lights, I need an 840Hz signal (that's the 60Hz mains frequency times 14 clock cycles needed) to drive my 14-bit counter circuit. (Yes, I plan on using the same solution to generate 700Hz (50Hz * 14) for other regions of the world.) Oh yeah, and I'd like this clock synchronized to the zero-crossing of the mains voltage, to minimize line noise when switching loads on. I'm looking at Appnote XAPP462 and I don't think it's going to be possible to generate this singal on-chip. My desired output frequency is lower than the DCM will go. I know I can divide the output of whatever frequency I can generate, but I don't know if (or how) I can sync with the mains zero crossing at such low frequencies. However, I'm an amateur here and wanted to toss it out to the more experienced crowd. Can this be done? Thanks, -NevoArticle: 105708
"Josh Rosen" <bjrosen@polybusPleaseDontSPAMme.com> wrote in message news:pan.2006.07.29.01.04.03.95311@polybusPleaseDontSPAMme.com... > > The only problem with that code is the lack of a default statement. > Without a default statement the synthesizer will screw it up because the > undefined cases won't be treated as do nothing. If you add a default > statement then the synthesizer will do the right thing. > Gotta disagree, Josh. In a clocked process it is understood (and properly implemented by synthesis tools) that for undefined cases the last state of each register is held, which is what you want. You only need to explicitly code transitions. As long as the registers are initialized, which they are here by an async reset, then you're good to go. Even that is mainly a simulation issue. A synthesis tool can even handle no initialization, but you have to know what you're getting. In a non-clocked process you must spec defaults (either before the case statement or inside the case statement), or latches are inferred. In my opinion there is absolutely nothing wrong the code block Rickman posted other than asthetics (I don't care for how the begin/ends are indented). RobArticle: 105709
"Nevo" <nevo_n@hotmail.com> wrote in message news:1154142937.634762.135010@p79g2000cwp.googlegroups.com... >I need to generate signals to dim incandescent lights to one of 16 > dimming levels. > > I have built a 14-bit counter, which gives 16 discrete signals when > used with always-on and always-off signals. To properly dim my lights, > I need an 840Hz signal (that's the 60Hz mains frequency times 14 clock > cycles needed) to drive my 14-bit counter circuit. > > (Yes, I plan on using the same solution to generate 700Hz (50Hz * 14) > for other regions of the world.) > > Oh yeah, and I'd like this clock synchronized to the zero-crossing of > the mains voltage, to minimize line noise when switching loads on. > > I'm looking at Appnote XAPP462 and I don't think it's going to be > possible to generate this singal on-chip. My desired output frequency > is lower than the DCM will go. I know I can divide the output of > whatever frequency I can generate, but I don't know if (or how) I can > sync with the mains zero crossing at such low frequencies. > > However, I'm an amateur here and wanted to toss it out to the more > experienced crowd. Can this be done? > > Thanks, > > -Nevo > Hi Nevo - A 14-bit counter does not cycle every 14 clock cycles. It rolls over every 2^14 clock cycles. It really sounds like you want a 4-bit counter counting modulus 14 and driving 14 PWM outputs (plus your always-on and always-off outputs). I didn't look at XAPP462 so I don't know what you're referring to there, but if you need to multiply the mains frequency to generate a clock, see the recent thread with the subject line "2KHz clock signal from 50Hz main frequency with ADPLL". RobArticle: 105710
MM wrote: > Decimation used not to work in MAC FIR until certain version. I believe it > should have been fixed in v5.1. It might be that you are using an old core. > > /Mikhail Hi Mikhail, I am in fact using version 5.1 logicCore. So, I don't think that's the problem. But thank you for your help anyway. Sophi :)Article: 105711
rickman wrote: > always @ (negedge rst_n or posedge clk) begin > if (!rst_n)begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > end > else begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > if (wr == 1'b1)begin > case (adr [2:1]) > MASK: mask_wr <= 1'b1; > CLEAR: clear_wr <= 1'b1; > endcase > end > end > end But this is different to the initially posted code example! In the inital example both FFs hold their old values in some circumstances while now everytime a value is assigned to their inputs. Therefore this is a functional simplification which can only be done if the resulting behavior is acceptable. If acceptable it seems to me to be a good way to code this. RalfArticle: 105712
Nevo wrote: > For instance, if I want a D4_16E (a 4-bit one-of-sixteen decoder) in my > project, how would I do that? I would recommend to leave this work to the synthesis tool and write a simple case-statement or an if-then-else-statement. always @(sel, inp_0, ..., inp_f) begin case (sel) 4'h0 : sig <= inp_0; 4'h1 : sig <= inp_1; ... 4'hf : sig <= inp_f; endcase end //always If the 16 inputs are concatenated in a vector you could also use a for-loop to select the desired bit. RalfArticle: 105713
RobJ wrote: > "Josh Rosen" <bjrosen@polybusPleaseDontSPAMme.com> wrote in message > news:pan.2006.07.29.01.04.03.95311@polybusPleaseDontSPAMme.com... > > > > The only problem with that code is the lack of a default statement. > > Without a default statement the synthesizer will screw it up because the > > undefined cases won't be treated as do nothing. If you add a default > > statement then the synthesizer will do the right thing. > > > > Gotta disagree, Josh. In a clocked process it is understood (and properly > implemented by synthesis tools) that for undefined cases the last state of > each register is held, which is what you want. You only need to explicitly > code transitions. As long as the registers are initialized, which they are > here by an async reset, then you're good to go. Even that is mainly a > simulation issue. A synthesis tool can even handle no initialization, but > you have to know what you're getting. In a non-clocked process you must spec > defaults (either before the case statement or inside the case statement), or > latches are inferred. In my opinion there is absolutely nothing wrong the > code block Rickman posted other than asthetics (I don't care for how the > begin/ends are indented). Ah, but the unspecified cases are where the code is not doing what was intended. In the code posted, the previous value will be held. Instead the intent was that the value should always be 0 except for the decodes specified in the case statement. It was just luck that the input conditions never create a failure. As long as the address remains constant while the wr strobe is asserted, it will not have to "remember" a value. That is why I said this would not work so well for the read decodes.Article: 105714
billu schrieb: > Just checked. I think they are ok ... 4 MGTs on the top use > TOP_BREF_CLK (pins B14 and C14) and 4 MGTs on the bottom row use > BOTTOM_BREF_CLK2 (pins AE13 and AD13) > > The same code works for a ML310 board, so I'm guessing there some > specific board related issue. > > Any tips? Did you select the right device and packages in the project settings? Regards FalkArticle: 105715
mpierrotb schrieb: > If yes, is there a solution, to manage the two process ( fixed > acquisition and SDRAM refresh cycle) ? I guess you need a inbetween controller with some amount of buffer (FIFO). Regards FalkArticle: 105716
raso schrieb: >>>More or less. Wait a tick. Look at the data sheet of the 74xx297, it >>>says the lock range (pull range) of the PLL is >>>delta_f_max = fc * M / (2*K*N ) >>>using your values >>>delta_f_max = 50 Hz * 600000 / (2* 300000 * 40) = 1.25 Hz >>>Hmm, this should be enought. > > > I/D counter is a 2 divider. In locked condition, its output is 30MHz/2 > = 15MHz. > Therefore, in addition to N=40 divider, I have to use an f_out > prescalar (=7500). In > this case : > > delta_f_max = fc * M / (2*K*N*f_out_prescalar ) > delta_f_max = 50 Hz * 600000 / (2* 300000 * 40 * 7500) = 1.25/7500 Hz > > Is this correct? Hmm, I think so. Pretty narrow pull range. You need to decrease K. Regards FalkArticle: 105717
On Sat, 29 Jul 2006 04:11:30 +0000, RobJ wrote: > "Josh Rosen" <bjrosen@polybusPleaseDontSPAMme.com> wrote in message > news:pan.2006.07.29.01.04.03.95311@polybusPleaseDontSPAMme.com... >> >> The only problem with that code is the lack of a default statement. >> Without a default statement the synthesizer will screw it up because the >> undefined cases won't be treated as do nothing. If you add a default >> statement then the synthesizer will do the right thing. >> > > Gotta disagree, Josh. In a clocked process it is understood (and properly > implemented by synthesis tools) that for undefined cases the last state of > each register is held, which is what you want. You only need to explicitly > code transitions. As long as the registers are initialized, which they are > here by an async reset, then you're good to go. Even that is mainly a > simulation issue. A synthesis tool can even handle no initialization, but > you have to know what you're getting. In a non-clocked process you must spec > defaults (either before the case statement or inside the case statement), or > latches are inferred. In my opinion there is absolutely nothing wrong the > code block Rickman posted other than asthetics (I don't care for how the > begin/ends are indented). > > Rob I can tell you from first hand experience that the current version (8.2sp1) of XST mishandles case statements that don't have defaults, I just ran into the problem. I've seen this happen before with other synthesizers. It's just good practice to include a default in a case statement. That default can be empty but it's presence tell the synthesizer that the states don't change for the un-specified cases.Article: 105718
Hi, is setting the Vcco of Spartan3 banks to +3.3V would allow the FPGA to work with a 5V signaling environment like 5V PCI? Or there are some other means to do this? Thanks.Article: 105719
Ralf Hildebrandt wrote:
> rickman wrote:
>
> > always @ (negedge rst_n or posedge clk) begin
> > if (!rst_n)begin
> > mask_wr <= 1'b0;
> > clear_wr <= 1'b0;
> > end
> > else begin
> > mask_wr <= 1'b0;
> > clear_wr <= 1'b0;
> > if (wr == 1'b1)begin
> > case (adr [2:1])
> > MASK: mask_wr <= 1'b1;
> > CLEAR: clear_wr <= 1'b1;
> > endcase
> > end
> > end
> > end
>
> But this is different to the initially posted code example! In the
> inital example both FFs hold their old values in some circumstances
> while now everytime a value is assigned to their inputs. Therefore this
> is a functional simplification which can only be done if the resulting
> behavior is acceptable.
>
> If acceptable it seems to me to be a good way to code this.
That was the point. The initial code was not coded correctly for the
intended behavior. It only worked in the application (so far) because
the address did not change. This is just a set of address decodes
feeding into a register. It is intended to be clocked on every clock
cycle. In fact if I gave it a bit of thought, I would remove the
enclosing IF and make the signal assignments from the WR signal...
always @ (negedge rst_n or posedge clk) begin
if (!rst_n)begin
mask_wr <= 1'b0;
clear_wr <= 1'b0;
end
else begin
mask_wr <= 1'b0;
clear_wr <= 1'b0;
case (adr [2:1])
MASK: mask_wr <= wr;
CLEAR: clear_wr <= wr;
endcase
end
end
Now the code is doing exactly what it should be doing, anding the
addresses signals with the wr to produce a decode which is then
registered without an enable. This is totally clear and will produce
the optimally minimum logic. Another advantage is that you can easily
combine the read and the write strobes in the same block if the design
were small enough to make that useful. There are many registers in
this design so it would produce too large of a list to combine them.
Article: 105720
Nevo wrote:
> I need to generate signals to dim incandescent lights to one of 16
> dimming levels.
I don't think that 16 levels are sufficient for dimming, because it be
logarithmic: If the lamp is dim, small changes in the pulse width may cause
larger brightness perception than if the lamp is already bright. So I
suggest to use 256 steps and using a lookup table, if your controll unit
has 16 steps.
> I know I can divide the output of
> whatever frequency I can generate, but I don't know if (or how) I can
> sync with the mains zero crossing at such low frequencies.
For such low frequencies you can measure it and adjust a divider for every
rising reference clock edge:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity pll is
generic(multiplier,
reference_clock_frequency,
system_clock_frequency: natural);
port(
reference_clock: in std_logic;
system_clock: in std_logic;
clock_out: out std_logic);
end entity pll;
architecture rtl of pll is
signal system_clock_counter: unsigned(31 downto 0) := (others => '0');
signal system_clock_divider: unsigned(31 downto 0) :=
to_unsigned(system_clock_frequency /
(multiplier * reference_clock_frequency) / 2, 32);
signal clock_counter: unsigned(15 downto 0) := (others => '0');
signal clock_signal: std_logic := '0';
signal old_reference_clock: std_logic := '0';
begin
update_counter: process(system_clock)
begin
if system_clock'event and system_clock = '1' then
if old_reference_clock /= reference_clock
and reference_clock = '1' then
if clock_counter > multiplier * 2 then
system_clock_divider <= system_clock_divider + 1;
else
if clock_counter < multiplier * 2 then
system_clock_divider <= system_clock_divider - 1;
end if;
end if;
clock_counter <= (others => '0');
old_reference_clock <= reference_clock;
else
if system_clock_counter >= system_clock_divider then
system_clock_counter <= (others => '0');
clock_signal <= not clock_signal;
clock_counter <= clock_counter + 1;
else
system_clock_counter <= system_clock_counter + 1;
end if;
old_reference_clock <= reference_clock;
end if;
end if;
end process;
clock_out <= clock_signal;
end architecture rtl;
And a simple dimmer, which turns the lamp on with rising edge of the
reference clock, could look like this:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity dimmer is
port(
clock50hz: in std_logic;
clock_x_256: in std_logic;
on_time: in unsigned(7 downto 0);
lamp: out std_logic);
end entity dimmer;
architecture rtl of dimmer is
signal counter: unsigned(7 downto 0) := (others => '0');
signal counter_max: unsigned(7 downto 0) := (others => '0');
signal old_clock50hz: std_logic := '0';
begin
update_counter: process(clock_x_256)
begin
if clock_x_256'event and clock_x_256 = '1' then
if old_clock50hz /= clock50hz and clock50hz = '1' then
old_clock50hz <= clock50hz;
counter <= (others => '0');
counter_max <= on_time;
else
old_clock50hz <= clock50hz;
if counter < counter_max then
lamp <= '1';
counter <= counter + 1;
else
lamp <= '0';
end if;
end if;
end if;
end process;
end architecture rtl;
I don't think that you need my PLL simulation, because for a simple dimmer
the only important thing is to synchronize with mains zero crossing, so you
can derive the clock_x_256 signal from the main clock, but the advantage of
the PLL is that it synchronize in some seconds automaticly to 60 Hz (or
faster, if you change the divider adjust value), without changing the VHDL
source.
Putting it all together (I'm generating the 50 Hz mains power frequency
with my clock_generator from http://www.frank-buss.de/vhdl/index.html ) I
can dim my LED on my Spartan 3E starter kit:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity dimmer_test is
port(
clk_50mhz: in std_logic;
btn_south: in std_logic;
btn_north: in std_logic;
led: out unsigned(7 downto 0));
end entity dimmer_test;
architecture rtl of dimmer_test is
constant system_speed: natural := 50e6;
signal reference_clock: std_logic;
signal clock_x_256: std_logic;
signal clock50hz: std_logic;
signal on_time: unsigned(7 downto 0) := (others => '0');
begin
clock_50hz_generator: entity clock_generator
generic map(clock_in_speed => system_speed, clock_out_speed => 50)
port map(
clock_in => clk_50mhz,
clock_out => clock50hz);
my_pll: entity pll
generic map(multiplier => 256,
reference_clock_frequency => 50,
system_clock_frequency => system_speed)
port map(
reference_clock => clock50hz,
system_clock => clk_50mhz,
clock_out => clock_x_256);
my_dimmer: entity dimmer
port map(
clock50hz => clock50hz,
clock_x_256 => clock_x_256,
on_time => on_time,
lamp => led(0));
update_on_time: process(clock50hz)
begin
if clock50hz'event and clock50hz = '1' then
if btn_south = '1' then
on_time <= on_time - 1;
end if;
if btn_north = '1' then
on_time <= on_time + 1;
end if;
end if;
end process;
led(1) <= clock50hz;
led(2) <= clock_x_256;
led(3) <= clk_50mhz;
led(4) <= btn_south;
led(5) <= btn_north;
led(6) <= '0';
led(7) <= '1';
end architecture rtl;
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Article: 105721Yeah, definitely changed that. I changed the settings to ML310 board (XC2VP30-FF896) to see if I can find any cues to the problem. I changed phase align module and clock pins in the ucf file and the compilation goes through fine. I cant really find any board specific settings/properties in the code Thanks, Billu Falk Brunner wrote: > billu schrieb: > > Just checked. I think they are ok ... 4 MGTs on the top use > > TOP_BREF_CLK (pins B14 and C14) and 4 MGTs on the bottom row use > > BOTTOM_BREF_CLK2 (pins AE13 and AD13) > > > > The same code works for a ML310 board, so I'm guessing there some > > specific board related issue. > > > > Any tips? > > Did you select the right device and packages in the project settings? > > Regards > FalkArticle: 105722
billu wrote: > Yeah, definitely changed that. > > I changed the settings to ML310 board (XC2VP30-FF896) to see if I can > find any cues to the problem. I changed phase align module and clock > pins in the ucf file and the compilation goes through fine. I cant > really find any board specific settings/properties in the code Several things change in the source when you select a different clock source, at least when using the GT_CUSTOM core and Aurora2.3, assuming that is what the 8 lane sample uses. The input clock signal itself needs to be tied to the the right input to GT_CUSTOM; that is one of the 4 B/REFCLK/2 pins. The input REFCLKSEL needs to reflect the selection. It is '1' for B/REFCLK2 and '0' for B/REFCLK. The generic (in VHDL) REF_CLK_V_SEL is 1 for REFCLK/2 and 0 for BREFCLK/2.Article: 105723
Frank van Eijkelenburg wrote: > sunwei388@gmail.com wrote: > > Siva Velusamy wrote: > > > >>Check your trigger conditions. In the trigger window, apart from > >>specifying the value for each trigger, you also have to mention exactly > >>which trigger condition (or a boolean combination of conditions) needs > >>to be enabled. > >> > >>/S > >> > >>Frank van Eijkelenburg wrote: > >> > >>>I try to use the opb/iba unit of chipscope to monitor the opb bus within > >>>a simple edk design. I took the chipscope lab example as start point. I > >>>am able to see the OPB signals in chipscope, but I can not set a trigger > >>>point. For example, I want to trigger at a certain address 0xFFFFXXXX. > >>>If I wait for the triggercondition, the behaviour is the same if no > >>>condition is set (like the immediate trigger button is clicked). Another > >>>problem is: I don't see assembly or c-source code in the listing window. > >>>Do I have to tell chipscope where it can find sources? What could be wrong? > >>> > >>>In the lab example there are three control ports instantiated at the > >>>ICON unit while only two ports are connected. I have two control ports > >>>instantiated and connected, because ISE failed at the unconnected > >>>control port (in the map phase). > >>> > >>>Any ideas? > >>>Frank > > > > > > Hello Frank, Siva, > > > > I am also working on chipscope but it doesn't work. The error message > > is very strange and I suppose it is an assertion error. I use EDK8.1 > > SP2, ISE8.1 SP3 and Chipscope 8.1SP3. Can you tell me what is your > > configuration? Thanks a lot. > > > > Sunwei > > > > > EDK8.1.1, ISE8.1.3, ChipScope8.1.3 > > I don't have an error message (if I remove one control port from the ICON unit, > but triggering doesn't work and no assembly code is shown in the listing window. > > Frank Hi Frank, Thank you for your information. Maybe I need to reinstall the windows on my computer... SunweiArticle: 105724
You're right; I didn't design a counter. I should have realized that I can't get away with imprecise language use on a technical discussion group! I did, in fact, implement a 14-bit wide PWM output (essentially using a shift register where the incoming bit is always high.) Thank you for the reference to the previous thread; I'll go dig it up! -Nevo > > Hi Nevo - > > A 14-bit counter does not cycle every 14 clock cycles. It rolls over every > 2^14 clock cycles. It really sounds like you want a 4-bit counter counting > modulus 14 and driving 14 PWM outputs (plus your always-on and always-off > outputs). I didn't look at XAPP462 so I don't know what you're referring > to there, but if you need to multiply the mains frequency to generate a > clock, see the recent thread with the subject line "2KHz clock signal from > 50Hz main frequency with ADPLL". > > Rob >
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z