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
"smart0604" <smart0604@n_o_s_p_a_m.163.com> wrote in message news:vPudndwfsuELNXTWnZ2dnUVZ_hCdnZ2d@giganews.com... >I used the simple dual port ram in quartus with the altera fpga,but when i > simulate it in 100Mhz, the read data isn't what i haved writen in. but the > classic timing analyzer shows the fmax is about 200Mhz.could anybody help > me. I am so bothered with it. Are you using fully synchronous design? Have you simulated the design to see what's happening? The first is essential, the second is highly recommended! Nial.Article: 147651
On May 12, 10:45=A0am, backhus <goous...@googlemail.com> wrote:
> On 11 Mai, 09:11, Christopher Head <ch...@cs.ubc.ca> wrote:
>
>
>
> > On Mon, 10 May 2010 23:31:23 -0700 (PDT)
>
> > backhus <goous...@googlemail.com> wrote:
>
> > [snip]> Also you have no reset scheme, just default assignments in the
> > > declarations.
> > > Xilinx ISE can handle that, but other tools ignore it.
>
> > [snip]
>
> > Sorry for hijacking the thread, but... do you mean that if I write this
> > code:
>
> > signal foo : std_ulogic_vector(3 downto 0) :=3D "1010";
>
> > I would *not* normally expect the FPGA to power up with "1010" in the
> > signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> > assumed it worked everywhere; is this not the case? (kind of nice to
> > know in case I do some day end up using a different make of FPGA...)
>
> > Chris
>
> Hi Chris,
> That's right.
> The synthesis standard for VHDL treats assignments at declaration time
> as "ignored".
> They work and are intended to use for simulation (e.g. in
> testbenches).
>
> That XST uses these values is due to the fact that they can be held in
> the programming bitstream, and thus be present at power up for an SRAM
> based FPGA.
> Think of ASICs (or antifuse FPGAs) and this is no more true, so, as
> Neal mentioned, your code isn't portable anymore.
> Same is if you use a tool that strictly complies with the VHDL
> simulation standard.
>
> I didn't mention how to solve the problem, because that's a tricky
> question.
> It depends on many things whether you should do it, and how to do it.
> e.g.
> Registers in datapaths don't necessarily need a reset. The values are
> continuously overwritten.
> BUT:
> =A0 If you have a feedback path your simulation can stuck with 'X'es.
> One possible solution is to create Registers with an asynchronous
> reset, that will be used by ths testbench, and tied to the inactive
> state for synthesis.
> So the net will be optimized away and there are no 'X'es in a real
> chip. :-)
>
> For Counters/FSMs and such you have to decide.
> e.g.: A loadable counter doesn't need a reset, if the first thing that
> happens is a load operation.
> Also you should think about asynchronous and synchronous resets.
>
> A nice paper about this topic can be found on the Xilinx website.
>
> Have a nice synthesis
> =A0 =A0Eilert
On May 11, 1:24 pm, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > Sorry for hijacking the thread, but... do you mean that if I write this
> > code:
> > signal foo : std_ulogic_vector(3 downto 0) :=3D "1010";
> > I would *not* normally expect the FPGA to power up with "1010" in the
> > signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> > assumed it worked everywhere; is this not the case? (kind of nice to
> > know in case I do some day end up using a different make of FPGA...)
>
> You shouldn't rely in this if you want your designs to be 'portable'.
>
> You should also think about active reset logic for your design so that
> you know everything will definitely power up to a known state. What
> happens if you have a portion of your design you want to hold in reset
> until something else is configured properly?
>
> I have done this to allow a quick simulation of a module and
> know that Quartus throws up a warning (although I'm not sure if it does a=
ctually
> implement the reset value).
>
> Bottom line is you need a reset mechanism in to set these values.
>
> Nial.
Thanks for all the inputs, particularly bachus.
I paid careful attention to the signal driver concept, and rewrote the
code {link: http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?a=
ttredirects=3D0&d=3D1
}
The resulting RTL schematic is posted here: {link:http://
5483477158486903344-a-1802744773732722657-s-sites.googlegroups.com/
site/brsharath/RTL.png?
attachauth=3DANoY7coSXbMoJLHb5mbgwSAjgt3QN8FYgvT7itNF1lC3peoLOlSNRh7dgnAlxJ=
ClWwXFP8uTl6q387V0zZBmAdQIH5F79SuOJV9mtBqSiAR0s0dCCeGvDqrI-
JlaMoF6x5YETpEBkFYsEPFvVwDq-YKMLvzfo-
r8wz0ByGeZAHE7DP_rFJKDcEFTzDm2ez4o_2m8OlDzqFR5&attredirects=3D0 }
Please have a look and let me know if you have something to say. The
clock updates in the same clock cycle, without any delay.
However, I did not understand what you mean by a Reset scheme and a
time schedule plan. Are you simply referring to having an idea about
"which signals should change when and under what conditions" ?
Thanks,
Sharath
Article: 147652On May 11, 2:57=A0pm, "smart0604" <smart0604@n_o_s_p_a_m.163.com> wrote: > I used the simple dual port ram in quartus with the altera fpga,but when = i > simulate it in 100Mhz, the read data isn't what i haved writen in. but th= e > classic timing analyzer shows the fmax is about 200Mhz.could anybody help > me. I am so bothered with it. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Do you expect the read data to show up the moment the read address is valid? Or perhaps after the clock transition which samples the valid read address?Article: 147653
>> On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote: > > > I guess part of my frustration is that I have yet to see where strong > > > typing has made a real difference in my work... at least an > > > improvement. > On May 12, 12:20 am, rickman <gnu...@gmail.com> wrote: > I know > of a few instances of when strong typing found bugs for me before they > turned into lab bug searches... which is one of the main reasons for > using such features. =A0The earlier in the process bugs are found, the > easier they are found and the smaller the impact. =A0 It seems you've already (re)discovered actual examples where type checking can be useful > Still, there is a > cost and the question is whether the cost is justified... > Depends strongly on the cost of a bug. KJArticle: 147654
On May 12, 7:59=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > >> On Apr 9, 10:07 am, rickman <gnu...@gmail.com> wrote: > > > > I guess part of my frustration is that I have yet to see where stro= ng > > > > typing has made a real difference in my work... at least an > > > > improvement. > > On May 12, 12:20 am, rickman <gnu...@gmail.com> wrote: > > I know > > of a few instances of when strong typing found bugs for me before they > > turned into lab bug searches... which is one of the main reasons for > > using such features. =A0The earlier in the process bugs are found, the > > easier they are found and the smaller the impact. =A0 > > It seems you've already (re)discovered actual examples where type > checking can be useful > > > Still, there is a > > cost and the question is whether the cost is justified... > > Depends strongly on the cost of a bug. Yep! Today we found the hardest bug to date on this project. It was a configuration error... software setting up the hardware. No amount of type checking would have helped to find that one. That is my point. VHDL may help prevent some bugs, but there is a lot more to minimizing bugs than what can be forced on you by tools. Effective design is a holistic practice that has to take into account the unique aspects of each design optimizing the process to match the risk areas. I actually knew that the interface of my board to the rest of the system was the high risk part of the design, both in terms of the system itself and in terms of communicating the details. I failed to give this risk factor enough attention. I tried taking a shortcut of putting too much effort into the test bench and not doing bench testing (not the same as test bench testing) before turning the design over to the customer for integration. It should be smooth sailing from here on. So at least I'll have more time to post here and later look into the advantages of Verilog. RickArticle: 147655
15 years ago a 2x5 pin 0.1" pitch through hole programming header wasn't excessively large, these days it's a bit of a joke, worse if you use a surface mount part. It would be good to have a more compact 'standard' surface mount programming header. I've used Molex Picoblade vertical headers and connectors reasonably sucessfully but these probably aren't robust enough for high volume operation (it's only rated at 30 mating cycles though I've had a lot more out of it). Has anyone any better solutions? Come on Altera (and the rest), give us a standard. Nial.Article: 147656
Hello,
I am facing a problem of clock signals being generated by
combinatorial logic.
Here is the timing report:
TIMING REPORT
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.
Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal | Clock buffer(FF name) | Load |
-----------------------------------+------------------------+-------+
clk | BUFGP | 23 |
Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 |
-----------------------------------+------------------------+-------+
(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
generated by combinatorial logic.
clk is my "true" clock signal, whereas Dec_cnt is some other
combinatorial signal.
I have tried using the CLOCK_SIGNAL constraint both in my source file,
as follows:
attribute clock_signal : string;
attribute clock_signal of clk : signal is "yes";
attribute clock_signal of Dec_cnt : signal is "no";
and in the xilinx constraints file (.xcf)
BEGIN MODEL sdmac
NET "clk" CLK_SIGNAL = yes;
END;
In either case, I get the same problem.
Here is my source file: http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredirects=0&d=1
Please help
Article: 147657
On May 13, 8:53=A0am, Sharath Raju <brshar...@gmail.com> wrote:
> Hello,
>
> I am facing a problem of clock signals being generated by
> combinatorial logic.
>
> Here is the timing report:
>
> TIMING REPORT
>
> NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
> =A0 =A0 =A0 FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REP=
ORT
> =A0 =A0 =A0 GENERATED AFTER PLACE-and-ROUTE.
>
> Clock Information:
> ------------------
> -----------------------------------+------------------------+-------+
> Clock Signal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Clock buffer(F=
F name) =A0| Load =A0|
> -----------------------------------+------------------------+-------+
> clk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| BUFG=
P =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 23 =A0 =A0|
> Dec_cnt(Dec_cnt1:O) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| NONE(*)(Int_count_1)=
=A0 | 10 =A0 =A0|
> -----------------------------------+------------------------+-------+
> (*) This 1 clock signal(s) are generated by combinatorial logic,
> and XST is not able to identify which are the primary clock signals.
> Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
> generated by combinatorial logic.
>
> clk is my "true" clock signal, whereas Dec_cnt is some other
> combinatorial signal.
>
> I have tried using the CLOCK_SIGNAL constraint both in my source file,
> as follows:
>
> attribute clock_signal : string;
> attribute clock_signal of clk : signal is "yes";
> attribute clock_signal of Dec_cnt : signal is "no";
>
> and in the xilinx constraints file (.xcf)
>
> BEGIN MODEL sdmac
> =A0NET "clk" CLK_SIGNAL =3D yes;
> END;
>
> In either case, I get the same problem.
>
> Here is my source file:http://sites.google.com/site/brsharath/sdmac_signa=
l_sched.vhd?attredi...
>
> Please help
The problem is this bit of code:
process (Inc_cnt, Dec_cnt)
begin
if Inc_cnt =3D '1' then
Int_count <=3D Int_count + 1;
elsif Dec_cnt =3D '1' then
Int_count <=3D Int_count - 1;
end if;
end process;
Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the
clock.
If you wanted this to be a clocked process, put the clock in the
sensitivity list and remove Inc_cnt and Dec_cnt.
Regards,
John McCaskill
www.FasterTechnology.com
Article: 147658On 5/13/2010 3:20 AM, Nial Stewart wrote: > 15 years ago a 2x5 pin 0.1" pitch through hole programming header wasn't > excessively large, these days it's a bit of a joke, worse if you use a > surface mount part. > > It would be good to have a more compact 'standard' surface mount programming > header. > > I've used Molex Picoblade vertical headers and connectors reasonably sucessfully > but these probably aren't robust enough for high volume operation (it's only > rated at 30 mating cycles though I've had a lot more out of it). > > Has anyone any better solutions? > > > Come on Altera (and the rest), give us a standard. > > > > Nial. > Some of the newer ARM devkits we've been using lately have come with 2x5 0.05" through hole instead. 75% of your surface area back is a pretty decent victory. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147659
With our EEBlaster (http://www.entner-electronics.com/tl/index.php/ eeblaster.html), we support a 2x3 2mm pitch header which uses just about 1/3 of the area of the 2x5 header. We think this is a good compromise of size, price, reliability and availability. We have the pinout made public on the mentioned link, so everyone can use it, either together with our EEBlaster or with a self-made adapter-cable. Best regards Thomas Entner www.entner-electronics.comArticle: 147660
On May 13, 6:20 am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > 15 years ago a 2x5 pin 0.1" pitch through hole programming header wasn't > excessively large, these days it's a bit of a joke, worse if you use a > surface mount part. > > It would be good to have a more compact 'standard' surface mount programming > header. > > I've used Molex Picoblade vertical headers and connectors reasonably sucessfully > but these probably aren't robust enough for high volume operation (it's only > rated at 30 mating cycles though I've had a lot more out of it). > > Has anyone any better solutions? > > Come on Altera (and the rest), give us a standard. > > Nial. I've only once used anything other than the standard connectors for programming where the devices needed to be very miniature and we had some bucks to spend on the issue. The approach we took was to use a 1 mm pitch surface mount two piece connector and created a flex cable to bring this connector out to a standard 0.1" header. Then we used all the standard cables for programming, debug and even used this port in automated testing (it had some additional capabilities). A good connector for this is also Molex, called "Conan" (not the barbarian or the comedian). I expect you could go as low as 9 pins on this connector. Digikey carries them. Male: 91910-21109LF, female: 91930-21109LF. The male is available in different heights with a mated height from 4.15 mm to 7.52 mm. The receptacle has a fixed height of 3.28 mm, which is lower than the shortest header so that is likely what you want on the target board. The outline is about 9 x 6 mm. One of the really nice things about these connectors is that they have a detent "click" when mated and do not tend to come apart from vibration. I have used them myself for daughtercard mounting. They serve both as a mounting method and as an electrical connector. I have seen similar connectors that are smaller in all dimensions, but not with a positive mated feel. Using one of these as a "standard" programming header wouldn't be a big problem except for the expense of making the adapter. A flex circuit would cost quite a few bucks for the NRE. I suppose a cheaper alternative would be a paddle board PCB. That could be inexpensive although the flex cable is much more versatile. RickArticle: 147661
On May 13, 10:18 am, John McCaskill <jhmccask...@gmail.com> wrote: > On May 13, 8:53 am, Sharath Raju <brshar...@gmail.com> wrote: > > > > > Hello, > > > I am facing a problem of clock signals being generated by > > combinatorial logic. > > > Here is the timing report: > > > TIMING REPORT > > > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT > > GENERATED AFTER PLACE-and-ROUTE. > > > Clock Information: > > ------------------ > > -----------------------------------+------------------------+-------+ > > Clock Signal | Clock buffer(FF name) | Load | > > -----------------------------------+------------------------+-------+ > > clk | BUFGP | 23 | > > Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 | > > -----------------------------------+------------------------+-------+ > > (*) This 1 clock signal(s) are generated by combinatorial logic, > > and XST is not able to identify which are the primary clock signals. > > Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) > > generated by combinatorial logic. > > > clk is my "true" clock signal, whereas Dec_cnt is some other > > combinatorial signal. > > > I have tried using the CLOCK_SIGNAL constraint both in my source file, > > as follows: > > > attribute clock_signal : string; > > attribute clock_signal of clk : signal is "yes"; > > attribute clock_signal of Dec_cnt : signal is "no"; > > > and in the xilinx constraints file (.xcf) > > > BEGIN MODEL sdmac > > NET "clk" CLK_SIGNAL = yes; > > END; > > > In either case, I get the same problem. > > > Here is my source file:http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredi... > > > Please help > > The problem is this bit of code: > > process (Inc_cnt, Dec_cnt) > begin > if Inc_cnt = '1' then > Int_count <= Int_count + 1; > elsif Dec_cnt = '1' then > Int_count <= Int_count - 1; > end if; > > end process; > > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > clock. > > If you wanted this to be a clocked process, put the clock in the > sensitivity list and remove Inc_cnt and Dec_cnt. > > Regards, > > John McCaskillwww.FasterTechnology.com This is not describing edge sensitive clocked logic. It is describing a latch. But both signals, Inc_cnt and Dec_cnt would be used to generate the latch enable. So the question is whether the OP intended this to use a latch or if it was supposed to be clocked by a system clock edge. The danger in this case is that the logic is a feedback loop and if the enable is asserted long enough for a change on the output to reach back around to the input, it would be counting up or down at its fastest possible rate the entire time the enable is asserted. I haven't looked at the code. Is it possible this was meant to use separate signals for cur_count and nxt_count with cur_count a register and nxt_count the logic output? RickArticle: 147662
Nial Stewart wrote: > 15 years ago a 2x5 pin 0.1" pitch through hole programming header wasn't > excessively large, these days it's a bit of a joke, worse if you use a > surface mount part. > > It would be good to have a more compact 'standard' surface mount programming > header. I use a 2x4 pin 2mm header for JTAG programming of Xilinx CPLDs. This seems to work quite well, but maybe for chipscope or similar testing, you need a couple more pins. JonArticle: 147663
On May 13, 1:14=A0pm, rickman <gnu...@gmail.com> wrote: > On May 13, 10:18 am, John McCaskill <jhmccask...@gmail.com> wrote: > > > > > On May 13, 8:53 am, Sharath Raju <brshar...@gmail.com> wrote: > > > > Hello, > > > > I am facing a problem of clock signals being generated by > > > combinatorial logic. > > > > Here is the timing report: > > > > TIMING REPORT > > > > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > > =A0 =A0 =A0 FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE= REPORT > > > =A0 =A0 =A0 GENERATED AFTER PLACE-and-ROUTE. > > > > Clock Information: > > > ------------------ > > > -----------------------------------+------------------------+-------+ > > > Clock Signal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Clock buff= er(FF name) =A0| Load =A0| > > > -----------------------------------+------------------------+-------+ > > > clk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = BUFGP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 23 =A0 =A0| > > > Dec_cnt(Dec_cnt1:O) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| NONE(*)(Int_coun= t_1) =A0 | 10 =A0 =A0| > > > -----------------------------------+------------------------+-------+ > > > (*) This 1 clock signal(s) are generated by combinatorial logic, > > > and XST is not able to identify which are the primary clock signals. > > > Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) > > > generated by combinatorial logic. > > > > clk is my "true" clock signal, whereas Dec_cnt is some other > > > combinatorial signal. > > > > I have tried using the CLOCK_SIGNAL constraint both in my source file= , > > > as follows: > > > > attribute clock_signal : string; > > > attribute clock_signal of clk : signal is "yes"; > > > attribute clock_signal of Dec_cnt : signal is "no"; > > > > and in the xilinx constraints file (.xcf) > > > > BEGIN MODEL sdmac > > > =A0NET "clk" CLK_SIGNAL =3D yes; > > > END; > > > > In either case, I get the same problem. > > > > Here is my source file:http://sites.google.com/site/brsharath/sdmac_s= ignal_sched.vhd?attredi... > > > > Please help > > > The problem is this bit of code: > > > process (Inc_cnt, Dec_cnt) > > begin > > =A0 if Inc_cnt =3D '1' then > > =A0 =A0 Int_count <=3D Int_count + 1; > > =A0 elsif Dec_cnt =3D '1' then > > =A0 =A0 Int_count <=3D Int_count - 1; > > =A0 end if; > > > end process; > > > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > > clock. > > > If you wanted this to be a clocked process, put the clock in the > > sensitivity list and remove Inc_cnt and Dec_cnt. > > > Regards, > > > John McCaskillwww.FasterTechnology.com > > This is not describing edge sensitive clocked logic. =A0It is describing > a latch. =A0But both signals, Inc_cnt and Dec_cnt would be used to > generate the latch enable. =A0So the question is whether the OP intended > this to use a latch or if it was supposed to be clocked by a system > clock edge. =A0The danger in this case is that the logic is a feedback > loop and if the enable is asserted long enough for a change on the > output to reach back around to the input, it would be counting up or > down at its fastest possible rate the entire time the enable is > asserted. > > I haven't looked at the code. =A0Is it possible this was meant to use > separate signals for cur_count and nxt_count with cur_count a register > and nxt_count the logic output? > > Rick Actually, it is just incorrect. If if is supposed to be a latch (but I hope not), it should also have Int_count in the sensitivity list. As written, it will synthesize with warnings as a latch, but not simulate as one. This is still the cause of Dec_cnt being reported as a clock. Int_count is not used outside of this process, so it is not clear what the intention was. Int_count is also defined as std_logic_vector, which is a problem. A std_logic_vector has no numerical value. I would also replace: use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; with: use IEEE.NUMERIC_STD.ALL; Regards, John McCaskill www.FasterTechnology.comArticle: 147664
hi In virtexpro/spartan3a/spartan3 kit when we using system clock(100Mz/50Mhz) and take this clock on i/o pin(by writing VHDL program) on digital C.R.O. it will show corrupred signal , I also tried this by DCM CORE GENERATOR again it is giving wrong o/p. Can anybody suggested me solution of this problem. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147665
On May 13, 3:25=A0pm, John McCaskill <jhmccask...@gmail.com> wrote: > On May 13, 1:14=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > On May 13, 10:18 am, John McCaskill <jhmccask...@gmail.com> wrote: > > > > On May 13, 8:53 am, Sharath Raju <brshar...@gmail.com> wrote: > > > > > Hello, > > > > > I am facing a problem of clock signals being generated by > > > > combinatorial logic. > > > > > Here is the timing report: > > > > > TIMING REPORT > > > > > NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > > > =A0 =A0 =A0 FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRA= CE REPORT > > > > =A0 =A0 =A0 GENERATED AFTER PLACE-and-ROUTE. > > > > > Clock Information: > > > > ------------------ > > > > -----------------------------------+------------------------+------= -+ > > > > Clock Signal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Clock bu= ffer(FF name) =A0| Load =A0| > > > > -----------------------------------+------------------------+------= -+ > > > > clk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | BUFGP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 23 =A0 =A0| > > > > Dec_cnt(Dec_cnt1:O) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| NONE(*)(Int_co= unt_1) =A0 | 10 =A0 =A0| > > > > -----------------------------------+------------------------+------= -+ > > > > (*) This 1 clock signal(s) are generated by combinatorial logic, > > > > and XST is not able to identify which are the primary clock signals= . > > > > Please use the CLOCK_SIGNAL constraint to specify the clock signal(= s) > > > > generated by combinatorial logic. > > > > > clk is my "true" clock signal, whereas Dec_cnt is some other > > > > combinatorial signal. > > > > > I have tried using the CLOCK_SIGNAL constraint both in my source fi= le, > > > > as follows: > > > > > attribute clock_signal : string; > > > > attribute clock_signal of clk : signal is "yes"; > > > > attribute clock_signal of Dec_cnt : signal is "no"; > > > > > and in the xilinx constraints file (.xcf) > > > > > BEGIN MODEL sdmac > > > > =A0NET "clk" CLK_SIGNAL =3D yes; > > > > END; > > > > > In either case, I get the same problem. > > > > > Here is my source file:http://sites.google.com/site/brsharath/sdmac= _signal_sched.vhd?attredi... > > > > > Please help > > > > The problem is this bit of code: > > > > process (Inc_cnt, Dec_cnt) > > > begin > > > =A0 if Inc_cnt =3D '1' then > > > =A0 =A0 Int_count <=3D Int_count + 1; > > > =A0 elsif Dec_cnt =3D '1' then > > > =A0 =A0 Int_count <=3D Int_count - 1; > > > =A0 end if; > > > > end process; > > > > Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > > > clock. > > > > If you wanted this to be a clocked process, put the clock in the > > > sensitivity list and remove Inc_cnt and Dec_cnt. > > > > Regards, > > > > John McCaskillwww.FasterTechnology.com > > > This is not describing edge sensitive clocked logic. =A0It is describin= g > > a latch. =A0But both signals, Inc_cnt and Dec_cnt would be used to > > generate the latch enable. =A0So the question is whether the OP intende= d > > this to use a latch or if it was supposed to be clocked by a system > > clock edge. =A0The danger in this case is that the logic is a feedback > > loop and if the enable is asserted long enough for a change on the > > output to reach back around to the input, it would be counting up or > > down at its fastest possible rate the entire time the enable is > > asserted. > > > I haven't looked at the code. =A0Is it possible this was meant to use > > separate signals for cur_count and nxt_count with cur_count a register > > and nxt_count the logic output? > > > Rick > > Actually, it is just incorrect. > > If if is supposed to be a latch (but I hope not), it should also have > Int_count in the sensitivity list. As written, it will synthesize with > warnings as a latch, but not simulate as one. =A0This is still the cause > of Dec_cnt being reported as a clock. > > Int_count is not used outside of this process, so it is not clear what > the intention was. > > Int_count is also defined as std_logic_vector, which is a problem. =A0A > std_logic_vector has no numerical value. > > I would also replace: > > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > with: > > use IEEE.NUMERIC_STD.ALL; Yeah, I guess the code is pretty ugly. Why, after all these years of people discussing the issues with std_logic_unsigned, et. al., do people still start out this way? Do they teach this in the universities or something? RickArticle: 147666
On 5/13/2010 1:56 PM, rickman wrote: > On May 13, 3:25 pm, John McCaskill<jhmccask...@gmail.com> wrote: >> On May 13, 1:14 pm, rickman<gnu...@gmail.com> wrote: >> >> >> >>> On May 13, 10:18 am, John McCaskill<jhmccask...@gmail.com> wrote: >> >>>> On May 13, 8:53 am, Sharath Raju<brshar...@gmail.com> wrote: >> >>>>> Hello, >> >>>>> I am facing a problem of clock signals being generated by >>>>> combinatorial logic. >> >>>>> Here is the timing report: >> >>>>> TIMING REPORT >> >>>>> NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. >>>>> FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT >>>>> GENERATED AFTER PLACE-and-ROUTE. >> >>>>> Clock Information: >>>>> ------------------ >>>>> -----------------------------------+------------------------+-------+ >>>>> Clock Signal | Clock buffer(FF name) | Load | >>>>> -----------------------------------+------------------------+-------+ >>>>> clk | BUFGP | 23 | >>>>> Dec_cnt(Dec_cnt1:O) | NONE(*)(Int_count_1) | 10 | >>>>> -----------------------------------+------------------------+-------+ >>>>> (*) This 1 clock signal(s) are generated by combinatorial logic, >>>>> and XST is not able to identify which are the primary clock signals. >>>>> Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) >>>>> generated by combinatorial logic. >> >>>>> clk is my "true" clock signal, whereas Dec_cnt is some other >>>>> combinatorial signal. >> >>>>> I have tried using the CLOCK_SIGNAL constraint both in my source file, >>>>> as follows: >> >>>>> attribute clock_signal : string; >>>>> attribute clock_signal of clk : signal is "yes"; >>>>> attribute clock_signal of Dec_cnt : signal is "no"; >> >>>>> and in the xilinx constraints file (.xcf) >> >>>>> BEGIN MODEL sdmac >>>>> NET "clk" CLK_SIGNAL = yes; >>>>> END; >> >>>>> In either case, I get the same problem. >> >>>>> Here is my source file:http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredi... >> >>>>> Please help >> >>>> The problem is this bit of code: >> >>>> process (Inc_cnt, Dec_cnt) >>>> begin >>>> if Inc_cnt = '1' then >>>> Int_count<= Int_count + 1; >>>> elsif Dec_cnt = '1' then >>>> Int_count<= Int_count - 1; >>>> end if; >> >>>> end process; >> >>>> Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the >>>> clock. >> >>>> If you wanted this to be a clocked process, put the clock in the >>>> sensitivity list and remove Inc_cnt and Dec_cnt. >> >>>> Regards, >> >>>> John McCaskillwww.FasterTechnology.com >> >>> This is not describing edge sensitive clocked logic. It is describing >>> a latch. But both signals, Inc_cnt and Dec_cnt would be used to >>> generate the latch enable. So the question is whether the OP intended >>> this to use a latch or if it was supposed to be clocked by a system >>> clock edge. The danger in this case is that the logic is a feedback >>> loop and if the enable is asserted long enough for a change on the >>> output to reach back around to the input, it would be counting up or >>> down at its fastest possible rate the entire time the enable is >>> asserted. >> >>> I haven't looked at the code. Is it possible this was meant to use >>> separate signals for cur_count and nxt_count with cur_count a register >>> and nxt_count the logic output? >> >>> Rick >> >> Actually, it is just incorrect. >> >> If if is supposed to be a latch (but I hope not), it should also have >> Int_count in the sensitivity list. As written, it will synthesize with >> warnings as a latch, but not simulate as one. This is still the cause >> of Dec_cnt being reported as a clock. >> >> Int_count is not used outside of this process, so it is not clear what >> the intention was. >> >> Int_count is also defined as std_logic_vector, which is a problem. A >> std_logic_vector has no numerical value. >> >> I would also replace: >> >> use IEEE.STD_LOGIC_ARITH.ALL; >> use IEEE.STD_LOGIC_UNSIGNED.ALL; >> >> with: >> >> use IEEE.NUMERIC_STD.ALL; > > Yeah, I guess the code is pretty ugly. Why, after all these years of > people discussing the issues with std_logic_unsigned, et. al., do > people still start out this way? Do they teach this in the > universities or something? > > Rick I know that all of Xilinx's example code and templates still don't use numeric_std. No idea how the template code from the other vendors looks. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147667
On May 11, 3:11 am, Christopher Head <ch...@cs.ubc.ca> wrote: > On Mon, 10 May 2010 23:31:23 -0700 (PDT) > > backhus <goous...@googlemail.com> wrote: > > [snip]> Also you have no reset scheme, just default assignments in the > > declarations. > > Xilinx ISE can handle that, but other tools ignore it. > > [snip] > > Sorry for hijacking the thread, but... do you mean that if I write this > code: > > signal foo : std_ulogic_vector(3 downto 0) := "1010"; > > I would *not* normally expect the FPGA to power up with "1010" in the > signal!? I've only ever worked with Xilinx FPGAs using ISE, so I > assumed it worked everywhere; is this not the case? (kind of nice to > know in case I do some day end up using a different make of FPGA...) > > Chris I can't say for sure, but I think the reason *why* declaration assignments are not used in synthesis is because they are not associated with any sort of signal. If you want FFs in an FPGA to initialize to a known state, this has to be done on the power up reset which is normally done through a global Set/Reset signal. The synthesis tools understand this signal and the fact that it can be driven externally as well as by a power up reset. The declaration assignment only sets the signal value on start up which is not the same thing, so it is just ignored. I find that to prevent warnings in functions like std_match I do need declaration assignments so that there are no 'u'/'x'/'-' states in buses at simulation startup when everything gets run. After that signals have values according to the code. This can mask missing reset assignments, but I believe the tools I am using give a warning on such things, it's not a very loud warning. It often hides in all the other warnings I need to ignore. RickArticle: 147668
On May 13, 4:13=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > On 5/13/2010 1:56 PM, rickman wrote: > > > > > On May 13, 3:25 pm, John McCaskill<jhmccask...@gmail.com> =A0wrote: > >> On May 13, 1:14 pm, rickman<gnu...@gmail.com> =A0wrote: > > >>> On May 13, 10:18 am, John McCaskill<jhmccask...@gmail.com> =A0wrote: > > >>>> On May 13, 8:53 am, Sharath Raju<brshar...@gmail.com> =A0wrote: > > >>>>> Hello, > > >>>>> I am facing a problem of clock signals being generated by > >>>>> combinatorial logic. > > >>>>> Here is the timing report: > > >>>>> TIMING REPORT > > >>>>> NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > >>>>> =A0 =A0 =A0 =A0FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE = TRACE REPORT > >>>>> =A0 =A0 =A0 =A0GENERATED AFTER PLACE-and-ROUTE. > > >>>>> Clock Information: > >>>>> ------------------ > >>>>> -----------------------------------+------------------------+------= -+ > >>>>> Clock Signal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Clock bu= ffer(FF name) =A0| Load =A0| > >>>>> -----------------------------------+------------------------+------= -+ > >>>>> clk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | BUFGP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 23 =A0 =A0| > >>>>> Dec_cnt(Dec_cnt1:O) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| NONE(*)(Int_co= unt_1) =A0 | 10 =A0 =A0| > >>>>> -----------------------------------+------------------------+------= -+ > >>>>> (*) This 1 clock signal(s) are generated by combinatorial logic, > >>>>> and XST is not able to identify which are the primary clock signals= . > >>>>> Please use the CLOCK_SIGNAL constraint to specify the clock signal(= s) > >>>>> generated by combinatorial logic. > > >>>>> clk is my "true" clock signal, whereas Dec_cnt is some other > >>>>> combinatorial signal. > > >>>>> I have tried using the CLOCK_SIGNAL constraint both in my source fi= le, > >>>>> as follows: > > >>>>> attribute clock_signal : string; > >>>>> attribute clock_signal of clk : signal is "yes"; > >>>>> attribute clock_signal of Dec_cnt : signal is "no"; > > >>>>> and in the xilinx constraints file (.xcf) > > >>>>> BEGIN MODEL sdmac > >>>>> =A0 NET "clk" CLK_SIGNAL =3D yes; > >>>>> END; > > >>>>> In either case, I get the same problem. > > >>>>> Here is my source file:http://sites.google.com/site/brsharath/sdmac= _signal_sched.vhd?attredi... > > >>>>> Please help > > >>>> The problem is this bit of code: > > >>>> process (Inc_cnt, Dec_cnt) > >>>> begin > >>>> =A0 =A0if Inc_cnt =3D '1' then > >>>> =A0 =A0 =A0Int_count<=3D Int_count + 1; > >>>> =A0 =A0elsif Dec_cnt =3D '1' then > >>>> =A0 =A0 =A0Int_count<=3D Int_count - 1; > >>>> =A0 =A0end if; > > >>>> end process; > > >>>> Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like the > >>>> clock. > > >>>> If you wanted this to be a clocked process, put the clock in the > >>>> sensitivity list and remove Inc_cnt and Dec_cnt. > > >>>> Regards, > > >>>> John McCaskillwww.FasterTechnology.com > > >>> This is not describing edge sensitive clocked logic. =A0It is describ= ing > >>> a latch. =A0But both signals, Inc_cnt and Dec_cnt would be used to > >>> generate the latch enable. =A0So the question is whether the OP inten= ded > >>> this to use a latch or if it was supposed to be clocked by a system > >>> clock edge. =A0The danger in this case is that the logic is a feedbac= k > >>> loop and if the enable is asserted long enough for a change on the > >>> output to reach back around to the input, it would be counting up or > >>> down at its fastest possible rate the entire time the enable is > >>> asserted. > > >>> I haven't looked at the code. =A0Is it possible this was meant to use > >>> separate signals for cur_count and nxt_count with cur_count a registe= r > >>> and nxt_count the logic output? > > >>> Rick > > >> Actually, it is just incorrect. > > >> If if is supposed to be a latch (but I hope not), it should also have > >> Int_count in the sensitivity list. As written, it will synthesize with > >> warnings as a latch, but not simulate as one. =A0This is still the cau= se > >> of Dec_cnt being reported as a clock. > > >> Int_count is not used outside of this process, so it is not clear what > >> the intention was. > > >> Int_count is also defined as std_logic_vector, which is a problem. =A0= A > >> std_logic_vector has no numerical value. > > >> I would also replace: > > >> use IEEE.STD_LOGIC_ARITH.ALL; > >> use IEEE.STD_LOGIC_UNSIGNED.ALL; > > >> with: > > >> use IEEE.NUMERIC_STD.ALL; > > > Yeah, I guess the code is pretty ugly. =A0Why, after all these years of > > people discussing the issues with std_logic_unsigned, et. al., do > > people still start out this way? =A0Do they teach this in the > > universities or something? > > > Rick > > I know that all of Xilinx's example code and templates still don't use > numeric_std. =A0No idea how the template code from the other vendors look= s. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order This is starting to change. The Xilinx VHDL course recommends numeric_std since the 11.1 version, and the create new source wizard in ISE 12.1 uses numeric_std now. I still see templates and examples that don't use it. I expect (but don't know) that will change over the next few releases. Regards, John McCaskill www.FasterTechnology.comArticle: 147669
On May 13, 12:30=A0pm, "varun_agr" <VARUN_AGR@n_o_s_p_a_m.YAHOO.COM> wrote: > hi > In virtexpro/spartan3a/spartan3 kit when we using system clock(100Mz/50Mh= z) > and take this clock on i/o pin(by writing VHDL program) on digital C.R.O. > it will show corrupred signal , I also tried this by DCM CORE GENERATOR > again it is giving wrong o/p. Can anybody suggested me solution of this > problem. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Based on your post you have the exact same behaviour on three different families, Virtex-II Pro, Spartan-3A and Spartan-3. This is strong indication that physical implementions are an exact match with the VHDL code that you wrote. Since you never indicated what your intended output was, what the output actually appears as nor the VHDL code it is unlikely that anyone can help you. Ed McGettigan -- Xilinx Inc.Article: 147670
My small but mighty team has recently issued two new issues of Xcell Journal magazine. The first is our 2010 Customer Innovation issue of Xcell, which features profiles of 20 customer designs. The latest issue is the Spring issue of Xcell, which features a cover story on the new ARM-MPU core device architecture and a lot of other great methodology and how-to content. You can find these new issues at http://www.xilinx.com/publications/xcellonline/index.htm. I hope you find them informative and useful and will contribute to future issues. Cheers, Mike Santarini Editor/Publisher, Xcell JournalArticle: 147671
On May 14, 2:43=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > On May 13, 4:13=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > > > > > On 5/13/2010 1:56 PM, rickman wrote: > > > > On May 13, 3:25 pm, John McCaskill<jhmccask...@gmail.com> =A0wrote: > > >> On May 13, 1:14 pm, rickman<gnu...@gmail.com> =A0wrote: > > > >>> On May 13, 10:18 am, John McCaskill<jhmccask...@gmail.com> =A0wrote= : > > > >>>> On May 13, 8:53 am, Sharath Raju<brshar...@gmail.com> =A0wrote: > > > >>>>> Hello, > > > >>>>> I am facing a problem of clock signals being generated by > > >>>>> combinatorial logic. > > > >>>>> Here is the timing report: > > > >>>>> TIMING REPORT > > > >>>>> NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE. > > >>>>> =A0 =A0 =A0 =A0FOR ACCURATE TIMING INFORMATION PLEASE REFER TO TH= E TRACE REPORT > > >>>>> =A0 =A0 =A0 =A0GENERATED AFTER PLACE-and-ROUTE. > > > >>>>> Clock Information: > > >>>>> ------------------ > > >>>>> -----------------------------------+------------------------+----= ---+ > > >>>>> Clock Signal =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Clock = buffer(FF name) =A0| Load =A0| > > >>>>> -----------------------------------+------------------------+----= ---+ > > >>>>> clk =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| BUFGP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 23 =A0 =A0| > > >>>>> Dec_cnt(Dec_cnt1:O) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| NONE(*)(Int_= count_1) =A0 | 10 =A0 =A0| > > >>>>> -----------------------------------+------------------------+----= ---+ > > >>>>> (*) This 1 clock signal(s) are generated by combinatorial logic, > > >>>>> and XST is not able to identify which are the primary clock signa= ls. > > >>>>> Please use the CLOCK_SIGNAL constraint to specify the clock signa= l(s) > > >>>>> generated by combinatorial logic. > > > >>>>> clk is my "true" clock signal, whereas Dec_cnt is some other > > >>>>> combinatorial signal. > > > >>>>> I have tried using the CLOCK_SIGNAL constraint both in my source = file, > > >>>>> as follows: > > > >>>>> attribute clock_signal : string; > > >>>>> attribute clock_signal of clk : signal is "yes"; > > >>>>> attribute clock_signal of Dec_cnt : signal is "no"; > > > >>>>> and in the xilinx constraints file (.xcf) > > > >>>>> BEGIN MODEL sdmac > > >>>>> =A0 NET "clk" CLK_SIGNAL =3D yes; > > >>>>> END; > > > >>>>> In either case, I get the same problem. > > > >>>>> Here is my source file:http://sites.google.com/site/brsharath/sdm= ac_signal_sched.vhd?attredi... > > > >>>>> Please help > > > >>>> The problem is this bit of code: > > > >>>> process (Inc_cnt, Dec_cnt) > > >>>> begin > > >>>> =A0 =A0if Inc_cnt =3D '1' then > > >>>> =A0 =A0 =A0Int_count<=3D Int_count + 1; > > >>>> =A0 =A0elsif Dec_cnt =3D '1' then > > >>>> =A0 =A0 =A0Int_count<=3D Int_count - 1; > > >>>> =A0 =A0end if; > > > >>>> end process; > > > >>>> Inc_cnt looks like an asynchronous reset, and Dec_cnt looks like t= he > > >>>> clock. > > > >>>> If you wanted this to be a clocked process, put the clock in the > > >>>> sensitivity list and remove Inc_cnt and Dec_cnt. > > > >>>> Regards, > > > >>>> John McCaskillwww.FasterTechnology.com > > > >>> This is not describing edge sensitive clocked logic. =A0It is descr= ibing > > >>> a latch. =A0But both signals, Inc_cnt and Dec_cnt would be used to > > >>> generate the latch enable. =A0So the question is whether the OP int= ended > > >>> this to use a latch or if it was supposed to be clocked by a system > > >>> clock edge. =A0The danger in this case is that the logic is a feedb= ack > > >>> loop and if the enable is asserted long enough for a change on the > > >>> output to reach back around to the input, it would be counting up o= r > > >>> down at its fastest possible rate the entire time the enable is > > >>> asserted. > > > >>> I haven't looked at the code. =A0Is it possible this was meant to u= se > > >>> separate signals for cur_count and nxt_count with cur_count a regis= ter > > >>> and nxt_count the logic output? > > > >>> Rick > > > >> Actually, it is just incorrect. > > > >> If if is supposed to be a latch (but I hope not), it should also hav= e > > >> Int_count in the sensitivity list. As written, it will synthesize wi= th > > >> warnings as a latch, but not simulate as one. =A0This is still the c= ause > > >> of Dec_cnt being reported as a clock. > > > >> Int_count is not used outside of this process, so it is not clear wh= at > > >> the intention was. > > > >> Int_count is also defined as std_logic_vector, which is a problem. = =A0A > > >> std_logic_vector has no numerical value. > > > >> I would also replace: > > > >> use IEEE.STD_LOGIC_ARITH.ALL; > > >> use IEEE.STD_LOGIC_UNSIGNED.ALL; > > > >> with: > > > >> use IEEE.NUMERIC_STD.ALL; > > > > Yeah, I guess the code is pretty ugly. =A0Why, after all these years = of > > > people discussing the issues with std_logic_unsigned, et. al., do > > > people still start out this way? =A0Do they teach this in the > > > universities or something? > > > > Rick > > > I know that all of Xilinx's example code and templates still don't use > > numeric_std. =A0No idea how the template code from the other vendors lo= oks. > > > -- > > Rob Gaddi, Highland Technology > > Email address is currently out of order > > This is starting to change. =A0The Xilinx VHDL course recommends > numeric_std since the 11.1 version, and the create new source wizard > in ISE 12.1 uses numeric_std now. =A0I still see templates and examples > that don't use it. I expect (but don't know) that will change over the > next few releases. > > Regards, > > John McCaskillwww.FasterTechnology.com Thanks for your inputs. I don't want the process (Inc_cnt, Dec_cnt) to be a clocked process. Inc_cnt and Dec_cnt are control signals that if set, either increment or decrement the Int_count counter signal. Hence the reason for putting Inc_cnt and Dec_cnt in the sensitivity list. The purpose of the code is to : 1. delay del_X signal by one clock cycle, 2. Multiply X (8-bit) and del_X (8-bit), and accumulate the product into a register Y (24 bit). I have split the accumulation into two steps. 14 bit addition (Sum signal) , followed by a 10-bit counter that updates the (Int_count signal) if an overflow (Inc_cnt signal) or a borrow (Dec_cnt signal) is generated by the addition operation.Article: 147672
>hi >In virtexpro/spartan3a/spartan3 kit when we using system clock(100Mz/50Mhz) >and take this clock on i/o pin(by writing VHDL program) on digital C.R.O. >it will show corrupred signal , I also tried this by DCM CORE GENERATOR >again it is giving wrong o/p. Can anybody suggested me solution of this >problem. > > > >--------------------------------------- >Posted through http://www.FPGARelated.com > How are you measuring this? scope? probe? analyzer? Try dividing it down by 100 and see if you can measure that. What is you pad drive current set to? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147673
On 12 Mai, 10:49, Sharath Raju <brshar...@gmail.com> wrote:
> On May 12, 10:45=A0am, backhus <goous...@googlemail.com> wrote:
>
>
>
> > On 11 Mai, 09:11, Christopher Head <ch...@cs.ubc.ca> wrote:
>
> > > On Mon, 10 May 2010 23:31:23 -0700 (PDT)
>
> > > backhus <goous...@googlemail.com> wrote:
>
> > > [snip]> Also you have no reset scheme, just default assignments in th=
e
> > > > declarations.
> > > > Xilinx ISE can handle that, but other tools ignore it.
>
> > > [snip]
>
> > > Sorry for hijacking the thread, but... do you mean that if I write th=
is
> > > code:
>
> > > signal foo : std_ulogic_vector(3 downto 0) :=3D "1010";
>
> > > I would *not* normally expect the FPGA to power up with "1010" in the
> > > signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> > > assumed it worked everywhere; is this not the case? (kind of nice to
> > > know in case I do some day end up using a different make of FPGA...)
>
> > > Chris
>
> > Hi Chris,
> > That's right.
> > The synthesis standard for VHDL treats assignments at declaration time
> > as "ignored".
> > They work and are intended to use for simulation (e.g. in
> > testbenches).
>
> > That XST uses these values is due to the fact that they can be held in
> > the programming bitstream, and thus be present at power up for an SRAM
> > based FPGA.
> > Think of ASICs (or antifuse FPGAs) and this is no more true, so, as
> > Neal mentioned, your code isn't portable anymore.
> > Same is if you use a tool that strictly complies with the VHDL
> > simulation standard.
>
> > I didn't mention how to solve the problem, because that's a tricky
> > question.
> > It depends on many things whether you should do it, and how to do it.
> > e.g.
> > Registers in datapaths don't necessarily need a reset. The values are
> > continuously overwritten.
> > BUT:
> > =A0 If you have a feedback path your simulation can stuck with 'X'es.
> > One possible solution is to create Registers with an asynchronous
> > reset, that will be used by ths testbench, and tied to the inactive
> > state for synthesis.
> > So the net will be optimized away and there are no 'X'es in a real
> > chip. :-)
>
> > For Counters/FSMs and such you have to decide.
> > e.g.: A loadable counter doesn't need a reset, if the first thing that
> > happens is a load operation.
> > Also you should think about asynchronous and synchronous resets.
>
> > A nice paper about this topic can be found on the Xilinx website.
>
> > Have a nice synthesis
> > =A0 =A0Eilert
>
> On May 11, 1:24 pm, "Nial Stewart"
>
>
>
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > > Sorry for hijacking the thread, but... do you mean that if I write th=
is
> > > code:
> > > signal foo : std_ulogic_vector(3 downto 0) :=3D "1010";
> > > I would *not* normally expect the FPGA to power up with "1010" in the
> > > signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> > > assumed it worked everywhere; is this not the case? (kind of nice to
> > > know in case I do some day end up using a different make of FPGA...)
>
> > You shouldn't rely in this if you want your designs to be 'portable'.
>
> > You should also think about active reset logic for your design so that
> > you know everything will definitely power up to a known state. What
> > happens if you have a portion of your design you want to hold in reset
> > until something else is configured properly?
>
> > I have done this to allow a quick simulation of a module and
> > know that Quartus throws up a warning (although I'm not sure if it does=
actually
> > implement the reset value).
>
> > Bottom line is you need a reset mechanism in to set these values.
>
> > Nial.
>
> Thanks for all the inputs, particularly bachus.
>
> I paid careful attention to the signal driver concept, and rewrote the
> code {link:http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?=
attredi...
>
> }
>
> The resulting RTL schematic is posted here: {link:http://
> 5483477158486903344-a-1802744773732722657-s-sites.googlegroups.com/
> site/brsharath/RTL.png?
> attachauth=3DANoY7coSXbMoJLHb5mbgwSAjgt3QN8FYgvT7itNF1lC3peoLOlSNRh7dgnAl=
xJClWwXFP8uTl6q387V0zZBmAdQIH5F79SuOJV9mtBqSiAR0s0dCCeGvDqrI-
> JlaMoF6x5YETpEBkFYsEPFvVwDq-YKMLvzfo-
> r8wz0ByGeZAHE7DP_rFJKDcEFTzDm2ez4o_2m8OlDzqFR5&attredirects=3D0 }
> =A0Please have a look and let me know if you have something to say. The
> clock updates in the same clock cycle, without any delay.
>
> However, I did not understand what you mean by a Reset scheme and a
> time schedule plan. Are you simply referring to having an idea about
> "which signals should change when and under what conditions" ?
>
> Thanks,
> Sharath
Hi Sharath,
your new code has some mistakes:
The sensitivity lists in the last two processes are incomplete,
rewrite like this:
process (Sum,P)
process (Inc_cnt, Dec_cnt, Int_count)
The last proces will result in latches anyway, which is no good.
And still you are triggering on both clock edges in the first process.
Look at the Synthesis Templates (light bulb icon) that come with the
ISE software:
Using a simple asynchronous reset would look like this:
Process (reset,clk) is
begin
If reset =3D '1' then
--assign start values for registered signals
elsif rising_edge(clk) then
-- do something
end if;
end process;
About the time scheduling plan:
Not just "having an idea" but a plan.
The only condition for signal changes here is the active clock edge.
e.g.:
clock_cycle | 0 |
X | * | P(13 :0)
Del_X | XOR | P(14)
(There would normally be lines from the inputs to the operators
(*,xor) and from there to the outputs. but it's hard to do in ASCII)
Also there would be more steps, but in your new code you have moved
most everything out of the clocked process,
so it's combinatorical stuff, and no longer under clock controll.
Even your counter is fully combinatorical now. Crap!
This may look nice in behavioral simulation, but makes your code
useless in a larger system.
No registered outputs mean: No predictable timing behavior in the
system, latches and other nasty stuff.
With careful scheduling your algorithm needs a three stage pipeline :
1st Stage: generating P adn Del_2_X
2nd Stage: generating ones_compl_P
3rd Stage: adding Sum and ones_compl_P (sumdash is not needed, since
sum is a registered signal and can be fed back)
This can all be done in one simple clocked process.
The counter can either be put in the 3rd stage too, or as an extra
process.
In any case the signal P has to be delayed once or twice to match the
latency of the sum signal (e.g. for generating Inc_cnt anf Dec_cnt )
With such a design you have a beginning latency of three clock cycles
but then new results on every clock cycle.
Have a nice synthesis
Eilert
Article: 147674rickman <gnuarm@gmail.com> writes: > On May 11, 3:11 am, Christopher Head <ch...@cs.ubc.ca> wrote: >> On Mon, 10 May 2010 23:31:23 -0700 (PDT) >> >> backhus <goous...@googlemail.com> wrote: >> >> [snip]> Also you have no reset scheme, just default assignments in the >> > declarations. >> > Xilinx ISE can handle that, but other tools ignore it. >> >> [snip] >> >> Sorry for hijacking the thread, but... do you mean that if I write this >> code: >> >> signal foo : std_ulogic_vector(3 downto 0) := "1010"; >> >> I would *not* normally expect the FPGA to power up with "1010" in the >> signal!? I've only ever worked with Xilinx FPGAs using ISE, so I >> assumed it worked everywhere; is this not the case? (kind of nice to >> know in case I do some day end up using a different make of FPGA...) >> >> Chris > > I can't say for sure, but I think the reason *why* declaration > assignments are not used in synthesis is because they are not > associated with any sort of signal. The point is that those assignments *are* used in synthesis by some tools. XST does it for one. It makes no sense for an ASIC, but for FPGAs which have a well defined startup condition defined by the bitstream it makes eminent sense. Now whether you want to take advantage of it depends on how portable to ASIC you want your code to be > If you want FFs in an FPGA to initialize to a known state, this has > to be done on the power up reset which is normally done through a > global Set/Reset signal. The synthesis tools understand this signal > and the fact that it can be driven externally as well as by a power > up reset. That's another way of getting (part) of the FPGA back to it's initialised state. But the RAMs will be potentially different. And be aware that this signal is a) slow and b) connected to asynchronous (p)reset ports on the FFs, so you can quite feasibly have parts of your design coming out of reset in one clock cycle and others a tick later if you assert the GSR willy-nilly. And then you can do a "normal ASIC-like" reset explicit in your logic... That is a fundamentally different thing - it's not "initialisation", it's resetting. It's quite feasible to have a FF which inits to '1' and has a reset signal to set it to '0'. Personally I avoid the GSR. I create reset signals which are synchronous to each of my clocks from a single async reset source and distribute those to the flipflops that need them explicitly, and use the synchronously. I occasionally make use of the startup value of the FFs being definable (in my resetn synchroniser for example!). I do arrange the logic to work with them initialising to '0's however, as in the past when synth tools didn't read the intialisation statements, it ensured the simulation matched the "default" behaviour of the FPGA flops. > The declaration assignment only sets the signal value on start up > which is not the same thing, so it is just ignored. > IIRC it *is* the same thing - the INIT state of a FF in the bitstream also defines its behaviour when the global set/reset (GSR) is asserted. > I find that to prevent warnings in functions like std_match I do need > declaration assignments so that there are no 'u'/'x'/'-' states in > buses at simulation startup when everything gets run. After that > signals have values according to the code. This can mask missing > reset assignments, but I believe the tools I am using give a warning > on such things, it's not a very loud warning. It often hides in all > the other warnings I need to ignore. > With modelsim you can set up a script to turn off the "numeric_std" warnings about those states, run for 0 ns (or a few ticks if you need to get your pipelines filled) and then turn them back on again so you don't miss any others. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
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