Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 147650

Article: 147650
Subject: Re: what is the fmax of the simple dual port ram in the altera fpga
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Wed, 12 May 2010 09:18:45 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Re: Expecting sequential output, but RTL shows concurrent
From: Sharath Raju <brsharath@gmail.com>
Date: Wed, 12 May 2010 01:49:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 147652
Subject: Re: what is the fmax of the simple dual port ram in the altera fpga
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 12 May 2010 03:34:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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
Subject: Re: I'd rather switch than fight!
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 12 May 2010 04:59:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
>> 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.

KJ

Article: 147654
Subject: Re: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Wed, 12 May 2010 22:17:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 147655
Subject: New 'standard' compact programming header needed!
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Thu, 13 May 2010 11:20:23 +0100
Links: << >>  << T >>  << A >>
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
Subject: Xilinx Synthesis Tool generates clock signals from combinatorial
From: Sharath Raju <brsharath@gmail.com>
Date: Thu, 13 May 2010 06:53:21 -0700 (PDT)
Links: << >>  << T >>  << A >>

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
Subject: Re: Xilinx Synthesis Tool generates clock signals from combinatorial
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 13 May 2010 07:18:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 147658
Subject: Re: New 'standard' compact programming header needed!
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Thu, 13 May 2010 08:36:55 -0700
Links: << >>  << T >>  << A >>
On 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 order

Article: 147659
Subject: Re: New 'standard' compact programming header needed!
From: Thomas Entner <thomas.entner@entner-electronics.com>
Date: Thu, 13 May 2010 09:03:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com

Article: 147660
Subject: Re: New 'standard' compact programming header needed!
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 May 2010 09:46:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 147661
Subject: Re: Xilinx Synthesis Tool generates clock signals from combinatorial
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 May 2010 11:14:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 147662
Subject: Re: New 'standard' compact programming header needed!
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 13 May 2010 14:24:08 -0500
Links: << >>  << T >>  << A >>
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.

Jon

Article: 147663
Subject: Re: Xilinx Synthesis Tool generates clock signals from combinatorial
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 13 May 2010 12:25:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com



Article: 147664
Subject: problem in clock input in virtexpro/spartan3a/spartan3 kit
From: "varun_agr" <VARUN_AGR@n_o_s_p_a_m.YAHOO.COM>
Date: Thu, 13 May 2010 14:30:49 -0500
Links: << >>  << T >>  << A >>
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

Article: 147665
Subject: Re: Xilinx Synthesis Tool generates clock signals from combinatorial
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 May 2010 13:56:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
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?

Rick

Article: 147666
Subject: Re: Xilinx Synthesis Tool generates clock signals from combinatorial
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Thu, 13 May 2010 14:13:16 -0700
Links: << >>  << T >>  << A >>
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 order

Article: 147667
Subject: Re: Expecting sequential output, but RTL shows concurrent
From: rickman <gnuarm@gmail.com>
Date: Thu, 13 May 2010 14:21:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Rick

Article: 147668
Subject: Re: Xilinx Synthesis Tool generates clock signals from combinatorial
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 13 May 2010 14:43:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com

Article: 147669
Subject: Re: problem in clock input in virtexpro/spartan3a/spartan3 kit
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 13 May 2010 16:06:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: 2 New issue of Xcell Now available
From: Mike Santarini <mike.santarini@gmail.com>
Date: Thu, 13 May 2010 16:34:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Journal

Article: 147671
Subject: Re: Xilinx Synthesis Tool generates clock signals from combinatorial
From: Sharath Raju <brsharath@gmail.com>
Date: Thu, 13 May 2010 20:11:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: problem in clock input in virtexpro/spartan3a/spartan3 kit
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 13 May 2010 22:17:49 -0500
Links: << >>  << T >>  << A >>
>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.com

Article: 147673
Subject: Re: Expecting sequential output, but RTL shows concurrent
From: backhus <goouse99@googlemail.com>
Date: Thu, 13 May 2010 23:57:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 147674
Subject: Re: Expecting sequential output, but RTL shows concurrent implementation.
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Fri, 14 May 2010 09:53:30 +0100
Links: << >>  << T >>  << A >>
rickman <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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search