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 148600

Article: 148600
Subject: Spartan 3AN Starter Kit. Sell.
From: "siriokds" <siriokds@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 05 Aug 2010 05:23:43 -0500
Links: << >>  << T >>  << A >>
I'd like to sell my Xiling Spartan 3AN Starter Kit (almost new and full
working). http://www.xilinx.com/products/devkits/HW-SPAR3AN-SK-UNI-G.htm

If anyone interested contact me.

Thank you.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148601
Subject: Re: Logic implementation probelm
From: "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com>
Date: Thu, 05 Aug 2010 06:59:13 -0500
Links: << >>  << T >>  << A >>
Hey 

Related to constraints like period. I have PERIOD constraints on my clocks
and related signals have also been placed into TIMEGRPs. Also i mention the
duty cycle of clocks

here are some numbers
there are 2 clocks in the systems. a 50mhz mclk and a 25mhz phy_clk.. The
controller interface runs at mclk and is seperated from other logic.

i use the following statements to constraint

NET "phy_clk" TNM_NET = "phy_clk";
TIMESPEC "TS_phy_clk" = PERIOD "phy_clk" 40 ns HIGH 50 %;

NET "mclk" TNM_NET = "mclk";
TIMESPEC "TS_mclk" = PERIOD "mclk" 20 ns HIGH 50 %;



Further the TIMEGRPS are

TIMEGRP "phy_clk_pads" OFFSET = IN 35 ns BEFORE "phy_clk"  ;
TIMEGRP "mclk_pads" OFFSET = IN 15 ns BEFORE "mclk"  ;
TIMEGRP "phy_clk_pads" OFFSET = OUT 35 ns AFTER "phy_clk"  ;
TIMESPEC "TS_P2P" = FROM "PADS" TO "PADS" 15 ns;


so now the controller interface constraints are

INST "data_bus<7>" TNM = "mclk_pads";
INST "data_bus<6>" TNM = "mclk_pads";
INST "data_bus<5>" TNM = "mclk_pads";
INST "data_bus<4>" TNM = "mclk_pads";
INST "data_bus<3>" TNM = "mclk_pads";
INST "data_bus<2>" TNM = "mclk_pads";
INST "data_bus<1>" TNM = "mclk_pads";
INST "data_bus<0>" TNM = "mclk_pads";
INST "read_" TNM = "mclk_pads";
INST "cs_" TNM = "mclk_pads";
INST "write_" TNM = "mclk_pads";

SO i dont think that i am missing the constraints. However if u think i am
then comment on it plz
///////////////////////////////////////////////////////

Related to your comment on flopping signals only once in one clock domain:

I am not doing any branching for the first stage of floping which is
exaclty the point u made. However i have more flops down the chain just to
add delay but that doesnot realy count as a problem.


Regards








>On Aug 4, 9:23=A0am, "salimbaba"
><a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
>> Hey i am using ise 9.1i for synthesizing my designs for spartan 3 fpgas.
=
>I
>> am facing a very wierd problem.
>> My system comprises of 1 xcs400 fpga and an ARM 7 processor. My RTL
desig=
>n
>> is very modular. Here is the problem.
>>
>> I have a microcontroller interface in my rtl design to communicate with
>> arm. other portions of my rtl design are related to some other logic
>> implementations.now what happens is that when i change some line of code
=
>or
>> logic in the other modules WHICH ARE IN NO WAY CONNECTED TO CONTROLLER
>> INTERFACE, the bit file that is generated causes my processor to crash
an=
>d
>> go into abort conditions. this happens primarily because of contention
on
>> the data bus of the processor.
>> However, i cannot tell why this is happening that a change in logic is
so=
>me
>> very remote part of the design causes the controller interface to
>> misbehave. Keep in view that my controller interface is perfected and
is
>> running perfectly on a couple of other systems.the only difference
betwee=
>n
>> a working bit file and a non working bit file is a small change in some
>> other part of the design and it is so small that it may include only a
si=
>ze
>> change of a register.
>>
>> i have pulled down all unused ios and all other setups are exactly the
>> same
>>
>> Regards =A0 =A0
>>
>> --------------------------------------- =A0 =A0 =A0 =A0
>> Posted throughhttp://www.FPGARelated.com
>
>It's very likely that you are having timing problems.  If your design
>is
>not properly constrained, the timing can vary significantly from run
>to run, even for parts of the design that don't change.  I assume
>you at least have PERIOD constraints on any clocks in the design.
>In addition you should constrain inputs and outputs for setup/hold
>and clock to out.  Alternately turn on the switch in the tools that
>says to push all of your I/O flip-flops into the IOB's.  This will
>cause the timing at the pin interface to be constant from run
>to run.  There may be cases where you I/O logic cannot be
>pushed into the IOB's however, so you need to check for these
>and make sure that you have constrained the timing for them
>appropriately.
>
>A good source of information is your post place&route timing
>report.  Make sure you tell the report generator to add the
>data sheet section.  This gives you a view into the setup/hold
>and clock to out timing of your design as built.  See if there
>are significant differences between the versions that work
>and those that don't.
>
>Finally another cause of build-to-build design instability is
>also caused by timing differences but not in a way that
>lends itself to being constrained.  If you have any signals
>that come in asynchronously or cross clock domains be
>sure that for each clock they are only registered in one
>flip-flop.  Any further logic in that clock domain should use
>the output of the same initial synchronizing flip-flop.  If
>the same async input goes through multiple flip-flops,
>those flip-flops can see the signal change on different
>clock cycles, and which one sees the signal first can
>change from build to build based on the relative routing
>delays from the source to the flip-flop D input.
>
>HTH,
>Gabor
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148602
Subject: Re: Logic implementation probelm
From: Gabor <gabor@alacron.com>
Date: Thu, 5 Aug 2010 05:54:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 7:59=A0am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
> Hey
>
> Related to constraints like period. I have PERIOD constraints on my clock=
s
> and related signals have also been placed into TIMEGRPs. Also i mention t=
he
> duty cycle of clocks
>
> here are some numbers
> there are 2 clocks in the systems. a 50mhz mclk and a 25mhz phy_clk.. The
> controller interface runs at mclk and is seperated from other logic.
>
> i use the following statements to constraint
>
> NET "phy_clk" TNM_NET =3D "phy_clk";
> TIMESPEC "TS_phy_clk" =3D PERIOD "phy_clk" 40 ns HIGH 50 %;
>
> NET "mclk" TNM_NET =3D "mclk";
> TIMESPEC "TS_mclk" =3D PERIOD "mclk" 20 ns HIGH 50 %;
>
> Further the TIMEGRPS are
>
> TIMEGRP "phy_clk_pads" OFFSET =3D IN 35 ns BEFORE "phy_clk" =A0;
> TIMEGRP "mclk_pads" OFFSET =3D IN 15 ns BEFORE "mclk" =A0;
> TIMEGRP "phy_clk_pads" OFFSET =3D OUT 35 ns AFTER "phy_clk" =A0;
> TIMESPEC "TS_P2P" =3D FROM "PADS" TO "PADS" 15 ns;
>
> so now the controller interface constraints are
>
> INST "data_bus<7>" TNM =3D "mclk_pads";
> INST "data_bus<6>" TNM =3D "mclk_pads";
> INST "data_bus<5>" TNM =3D "mclk_pads";
> INST "data_bus<4>" TNM =3D "mclk_pads";
> INST "data_bus<3>" TNM =3D "mclk_pads";
> INST "data_bus<2>" TNM =3D "mclk_pads";
> INST "data_bus<1>" TNM =3D "mclk_pads";
> INST "data_bus<0>" TNM =3D "mclk_pads";
> INST "read_" TNM =3D "mclk_pads";
> INST "cs_" TNM =3D "mclk_pads";
> INST "write_" TNM =3D "mclk_pads";
>
> SO i dont think that i am missing the constraints. However if u think i a=
m
> then comment on it plz

The only way to see if your design is properly constrained is to
create
a "Verbose" timing report (post P&R) and turn on "Report Unconstrained
Paths" for say 100 paths.  See if any paths look like they should be
constrained.  Also enable the "data sheet" section of the timing
report.
Compare the data sheet numbers (I/O timing) for a working version
vs. a non-working version to see if anything looks like it could be
causing the problem.  Your I/O constraints are quite loose.  They
only leave 5 ns for setup and clock to Q at the external device.  Make
sure this is acceptable.

Regards,
Gabor

Article: 148603
Subject: Re: Logic implementation probelm
From: Jeff Cunningham <jcc@sover.net>
Date: Thu, 05 Aug 2010 09:30:11 -0400
Links: << >>  << T >>  << A >>
Do you have state machines in the design? Are they properly reset with a 
SYNCHRONOUS reset at the beginning of the day? Using the global async 
reset is not sufficient. You must provide a reset signal that is 
synchronous to the state machine's clock. Failure to do this can result 
in illegal states and erratic behavior.

-Jeff

Article: 148604
Subject: Re: Xilinx EasyPath Pricing
From: Jeff Cunningham <jcc@sover.net>
Date: Thu, 05 Aug 2010 09:41:29 -0400
Links: << >>  << T >>  << A >>
On 8/5/10 2:09 AM, muhammad_umer wrote:

> One more thing, i google internet and found some articles, mentioning
> EasythPath saves 80% of FPGA cost. so this mean that, for instance, if FPGA
> cost $100 then its EasyPath partner will cost $20. Am i correct in my
> understanding?

No. Though you ARE correct that 100 reduced by 80% is 20.

If you go back and look at those articles I think it will say something 
like easypath "can" save "up to" 80% in the right situation. There are 
other factors, like how many per year are you going to buy. Like others 
have said, talk to your xilinx salesman.

-Jeff

Article: 148605
Subject: Re: Connecting "signed" to "std_logic_vector" ports.
From: Andrew Feldhaus <Reply@thread.pls>
Date: 05 Aug 2010 15:41:32 +0100 (BST)
Links: << >>  << T >>  << A >>

Thank you all for your helpful responses.

Ultimately I had to write a wrapper to hide the workarounds required to 
connect signals to ports of (semantically) different types.

This was after discovering that in:

U1: somedevice
  port map (  DIN => std_logic_vector(x),
              DOUT => U1DOUT);
 
Xilinx tools also do not connect 'x' to 'DIN', and fail to warn that the 
line is being ignored until 'DIN' is subsequently noted as disconnected...

I must agree with KJ that correctness is defined by compliance to the 
standard.  Xilinx reminds me more and more of Internet Explorer 6 but 
that is a rant for another day.

Thanks again,


Andrew
0xADF

Article: 148606
Subject: Re: DMA operation to 64-bits PC platform (continued)
From: sreekanth <user@compgroups.net/>
Date: Thu, 05 Aug 2010 10:44:44 -0500
Links: << >>  << T >>  << A >>
AFAIK, in x86 architectures, io writes will be cache coherent, unless you're setting SNR (no snoop) in the write header by mistake

But to me this sounds like a Windows problem. Typically garden variety PC's don't block PCIE accesses, all of the address space is open to a peripheral.  Acid test : if you can write to a given physical address from your FPGA, and read the value, you're golden in the physical address domain. So maybe what you think you're reading in your code is not actually getting to the correct physical address. 

try : 

write from FPGA card to a physical address
read back using FPGA card, see if good. 
write some known data from windows software
read back using FPGA card.  



Article: 148607
Subject: Verification of the SEU estimates
From: "rafayhasan" <rafayhasan@n_o_s_p_a_m.gmail.com>
Date: Thu, 05 Aug 2010 14:14:05 -0500
Links: << >>  << T >>  << A >>
Hello All,

I am writing this to seek your guidance in knowing the possible
methods/procedures to verify the analytical SEU estmiates for an FPGA
designs.  To my understanding the way to go about it is beam testing or
laser testing. The fault injection methods don't seem to me prudent in this
case as we are checking the estimate of soft errors in an FPGA design and
not verifying a mitigating methodology ?

My second query is related to the method of estimating SEU rate in Xilinx
FPGAs. I am utilizing the knowledge obtained from XDL and FPGA Editor to
make an estimate of configuration bits used by my design. The problem I am
encountering is how to estimate total configuration bits in the nets that
are related to "pips". 

for example it is true that a pip connecting two nodes of a switch will
require only one configuration bit, but at the same time each node of the
switch is connected to several other nodes. Hence potentially the net may
get connected to an irrelevant node (erroneously) due to SEU. And this
leads to me the question that what should I do to cope such a scenario in
an effort to provide realistic estimate of configuration bits ?

Of course what I am doing is with publicly available information from
Xilinx and hence it should not cause any legal hitch.

Your recommendations would be highly appreciated.

Rafay  


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148608
Subject: Re: Vendor Tool Stability
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 05 Aug 2010 19:28:01 GMT
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.com> wrote:

>On 8/4/2010 6:43 AM, Gabor wrote:
>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com>  wrote:
>>> A project I am considering undertaking would require that an FPGA's
>>> implementation flow (synthesis through bitgen) be routinely run in a
>>> scripted form at customer locations by the end customer, likely a non-
>>> engineer.  The RTL input can be assumed to be good.  All aspects of
>>> the vendor tools would be hidden from the end user via scripts or GUI.
>>>
>>> The stability of the vendor tools are the biggest concern in this
>>> project.  I am not tied to any vendor.  The performance specs are such
>>> that almost any current or last generation FPGA could handle the
>>> load.
>>>
>>> I would appreciate hearing your thoughts on which vendor to consider
>>> for this application.  Unpredictable errors and crashes are something
>>> that must be avoided.
>>>
>>> Thank you in advance.
>>> Angie
>>
>> Having worked with Xilinx tools and devices for many years, I would
>> say that it is possible to have very stable results as long as you
>> know what to avoid.  Generally speaking, a design with one system
>> clock and no special feature usage almost never has any issues
>> through the tool chain.  Start adding too many clock resources
>> or other special features and you can run into issues where the
>> tools need to be guided to complete the design.  I don't know
>> enough about your application to say whether Xilinx tools are
>> stable enough for your purposes.  Whichever chip vendor you
>> pick, you will have some things you need to avoid.  Only the
>> synthesis portion of the tool chain can be de-coupled from the
>> chip vendor.  It would really help if you had extensive experience
>> working with your vendor of choice before going into your own
>> tool implementation.  Most of the annoying bugs from Xilinx
>> are not in the actual synthesis / place / route / build, but in the
>> GUI wrapper.

I agree. The command line tools seem to work just fine.

>> Regards,
>> Gabor
>
>I've had nothing but problems with stability of Xilinx designs, 
>actually.  Routinely in going from one version of the toolchain to the 
>next, command line options are changed or deprecated, forcing me to 
>tweak the settings in my Makefile.  Right now I'm in the process of 
>opening a Webcase because a design which, under 12.1, was willing to 
>respect IOB=FORCE to push some input flip-flops into the ILOGIC cells 
>for timing reasons, it no longer will under 12.2.

IIRC it is possible to install and use several different versions of
the Xilinx tools if you use make or batch files.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 148609
Subject: Re: Vendor Tool Stability
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Thu, 05 Aug 2010 16:43:43 -0700
Links: << >>  << T >>  << A >>
On 8/5/2010 12:28 PM, Nico Coesel wrote:
> Rob Gaddi<rgaddi@technologyhighland.com>  wrote:
>
>> On 8/4/2010 6:43 AM, Gabor wrote:
>>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com>   wrote:
>>>> A project I am considering undertaking would require that an FPGA's
>>>> implementation flow (synthesis through bitgen) be routinely run in a
>>>> scripted form at customer locations by the end customer, likely a non-
>>>> engineer.  The RTL input can be assumed to be good.  All aspects of
>>>> the vendor tools would be hidden from the end user via scripts or GUI.
>>>>
>>>> The stability of the vendor tools are the biggest concern in this
>>>> project.  I am not tied to any vendor.  The performance specs are such
>>>> that almost any current or last generation FPGA could handle the
>>>> load.
>>>>
>>>> I would appreciate hearing your thoughts on which vendor to consider
>>>> for this application.  Unpredictable errors and crashes are something
>>>> that must be avoided.
>>>>
>>>> Thank you in advance.
>>>> Angie
>>>
>>> Having worked with Xilinx tools and devices for many years, I would
>>> say that it is possible to have very stable results as long as you
>>> know what to avoid.  Generally speaking, a design with one system
>>> clock and no special feature usage almost never has any issues
>>> through the tool chain.  Start adding too many clock resources
>>> or other special features and you can run into issues where the
>>> tools need to be guided to complete the design.  I don't know
>>> enough about your application to say whether Xilinx tools are
>>> stable enough for your purposes.  Whichever chip vendor you
>>> pick, you will have some things you need to avoid.  Only the
>>> synthesis portion of the tool chain can be de-coupled from the
>>> chip vendor.  It would really help if you had extensive experience
>>> working with your vendor of choice before going into your own
>>> tool implementation.  Most of the annoying bugs from Xilinx
>>> are not in the actual synthesis / place / route / build, but in the
>>> GUI wrapper.
>
> I agree. The command line tools seem to work just fine.
>
>>> Regards,
>>> Gabor
>>
>> I've had nothing but problems with stability of Xilinx designs,
>> actually.  Routinely in going from one version of the toolchain to the
>> next, command line options are changed or deprecated, forcing me to
>> tweak the settings in my Makefile.  Right now I'm in the process of
>> opening a Webcase because a design which, under 12.1, was willing to
>> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
>> for timing reasons, it no longer will under 12.2.
>
> IIRC it is possible to install and use several different versions of
> the Xilinx tools if you use make or batch files.
>

That's actually what I'm doing now on my Linux build machine; the 
different versions of the Xilinx tools seems to all play fairly nicely 
there.  On my Windows box, versions 11 and higher (FlexLM) get seriously 
snippy with one another.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 148610
Subject: Re: Vendor Tool Stability
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 05 Aug 2010 22:03:57 -0700
Links: << >>  << T >>  << A >>
On 08/05/2010 04:43 PM, Rob Gaddi wrote:
> On 8/5/2010 12:28 PM, Nico Coesel wrote:
>> Rob Gaddi<rgaddi@technologyhighland.com> wrote:
>>
>>> On 8/4/2010 6:43 AM, Gabor wrote:
>>>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
>>>>> A project I am considering undertaking would require that an FPGA's
>>>>> implementation flow (synthesis through bitgen) be routinely run in a
>>>>> scripted form at customer locations by the end customer, likely a non-
>>>>> engineer. The RTL input can be assumed to be good. All aspects of
>>>>> the vendor tools would be hidden from the end user via scripts or GUI.
>>>>>
>>>>> The stability of the vendor tools are the biggest concern in this
>>>>> project. I am not tied to any vendor. The performance specs are such
>>>>> that almost any current or last generation FPGA could handle the
>>>>> load.
>>>>>
>>>>> I would appreciate hearing your thoughts on which vendor to consider
>>>>> for this application. Unpredictable errors and crashes are something
>>>>> that must be avoided.
>>>>>
>>>>> Thank you in advance.
>>>>> Angie
>>>>
>>>> Having worked with Xilinx tools and devices for many years, I would
>>>> say that it is possible to have very stable results as long as you
>>>> know what to avoid. Generally speaking, a design with one system
>>>> clock and no special feature usage almost never has any issues
>>>> through the tool chain. Start adding too many clock resources
>>>> or other special features and you can run into issues where the
>>>> tools need to be guided to complete the design. I don't know
>>>> enough about your application to say whether Xilinx tools are
>>>> stable enough for your purposes. Whichever chip vendor you
>>>> pick, you will have some things you need to avoid. Only the
>>>> synthesis portion of the tool chain can be de-coupled from the
>>>> chip vendor. It would really help if you had extensive experience
>>>> working with your vendor of choice before going into your own
>>>> tool implementation. Most of the annoying bugs from Xilinx
>>>> are not in the actual synthesis / place / route / build, but in the
>>>> GUI wrapper.
>>
>> I agree. The command line tools seem to work just fine.
>>
>>>> Regards,
>>>> Gabor
>>>
>>> I've had nothing but problems with stability of Xilinx designs,
>>> actually. Routinely in going from one version of the toolchain to the
>>> next, command line options are changed or deprecated, forcing me to
>>> tweak the settings in my Makefile. Right now I'm in the process of
>>> opening a Webcase because a design which, under 12.1, was willing to
>>> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
>>> for timing reasons, it no longer will under 12.2.
>>
>> IIRC it is possible to install and use several different versions of
>> the Xilinx tools if you use make or batch files.
>>
>
> That's actually what I'm doing now on my Linux build machine; the
> different versions of the Xilinx tools seems to all play fairly nicely
> there. On my Windows box, versions 11 and higher (FlexLM) get seriously
> snippy with one another.

Give Xilinx time, they'll get the deficiencies in the Linux versions 
sorted out soon enough -- then your dissimilar versions will have 
trouble playing together on the Linux box, too!

(Kudos to Xilinx, by the way -- the Linux version of their tool set is 
perking along quite nicely under Ubuntu.  Other than having to roll my 
own driver for the parallel cable, all has worked straight out of the box).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 148611
Subject: xilinx usb cable
From: "chinnathurai" <chinnathurai.c@n_o_s_p_a_m.n_o_s_p_a_m.rediffmail.com>
Date: Fri, 06 Aug 2010 01:02:07 -0500
Links: << >>  << T >>  << A >>
which cypress tool is used to read or write the PID,VID in EEPROM in xilinx
usb programmer?

I want to read the PID,VID from xilinx spartan-3E starter kit how can i do
that?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148612
Subject: Re: Vendor Tool Stability
From: David Brown <david@westcontrol.removethisbit.com>
Date: Fri, 06 Aug 2010 09:35:59 +0200
Links: << >>  << T >>  << A >>
On 06/08/2010 07:03, Tim Wescott wrote:
> On 08/05/2010 04:43 PM, Rob Gaddi wrote:
>> On 8/5/2010 12:28 PM, Nico Coesel wrote:
>>> Rob Gaddi<rgaddi@technologyhighland.com> wrote:
>>>
>>>> On 8/4/2010 6:43 AM, Gabor wrote:
>>>>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
>>>>>> A project I am considering undertaking would require that an FPGA's
>>>>>> implementation flow (synthesis through bitgen) be routinely run in a
>>>>>> scripted form at customer locations by the end customer, likely a
>>>>>> non-
>>>>>> engineer. The RTL input can be assumed to be good. All aspects of
>>>>>> the vendor tools would be hidden from the end user via scripts or
>>>>>> GUI.
>>>>>>
>>>>>> The stability of the vendor tools are the biggest concern in this
>>>>>> project. I am not tied to any vendor. The performance specs are such
>>>>>> that almost any current or last generation FPGA could handle the
>>>>>> load.
>>>>>>
>>>>>> I would appreciate hearing your thoughts on which vendor to consider
>>>>>> for this application. Unpredictable errors and crashes are something
>>>>>> that must be avoided.
>>>>>>
>>>>>> Thank you in advance.
>>>>>> Angie
>>>>>
>>>>> Having worked with Xilinx tools and devices for many years, I would
>>>>> say that it is possible to have very stable results as long as you
>>>>> know what to avoid. Generally speaking, a design with one system
>>>>> clock and no special feature usage almost never has any issues
>>>>> through the tool chain. Start adding too many clock resources
>>>>> or other special features and you can run into issues where the
>>>>> tools need to be guided to complete the design. I don't know
>>>>> enough about your application to say whether Xilinx tools are
>>>>> stable enough for your purposes. Whichever chip vendor you
>>>>> pick, you will have some things you need to avoid. Only the
>>>>> synthesis portion of the tool chain can be de-coupled from the
>>>>> chip vendor. It would really help if you had extensive experience
>>>>> working with your vendor of choice before going into your own
>>>>> tool implementation. Most of the annoying bugs from Xilinx
>>>>> are not in the actual synthesis / place / route / build, but in the
>>>>> GUI wrapper.
>>>
>>> I agree. The command line tools seem to work just fine.
>>>
>>>>> Regards,
>>>>> Gabor
>>>>
>>>> I've had nothing but problems with stability of Xilinx designs,
>>>> actually. Routinely in going from one version of the toolchain to the
>>>> next, command line options are changed or deprecated, forcing me to
>>>> tweak the settings in my Makefile. Right now I'm in the process of
>>>> opening a Webcase because a design which, under 12.1, was willing to
>>>> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
>>>> for timing reasons, it no longer will under 12.2.
>>>
>>> IIRC it is possible to install and use several different versions of
>>> the Xilinx tools if you use make or batch files.
>>>
>>
>> That's actually what I'm doing now on my Linux build machine; the
>> different versions of the Xilinx tools seems to all play fairly nicely
>> there. On my Windows box, versions 11 and higher (FlexLM) get seriously
>> snippy with one another.
>
> Give Xilinx time, they'll get the deficiencies in the Linux versions
> sorted out soon enough -- then your dissimilar versions will have
> trouble playing together on the Linux box, too!
>
> (Kudos to Xilinx, by the way -- the Linux version of their tool set is
> perking along quite nicely under Ubuntu. Other than having to roll my
> own driver for the parallel cable, all has worked straight out of the box).
>

If you are having trouble with several different versions of the tools 
installed at the same time, consider running each one within its own 
virtual machine (I like VirtualBox, but it's a matter of taste).  I've 
done that for other programs that conflict with each other.


Article: 148613
Subject: Re: xilinx usb cable
From: Socrates <mailsoc@gmail.com>
Date: Fri, 6 Aug 2010 03:18:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 6, 9:02=A0am, "chinnathurai"
<chinnathurai.c@n_o_s_p_a_m.n_o_s_p_a_m.rediffmail.com> wrote:
> which cypress tool is used to read or write the PID,VID in EEPROM in xili=
nx
> usb programmer?
>
> I want to read the PID,VID from xilinx spartan-3E starter kit how can i d=
o
> that? =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

Hello,
download Cypress Suite USB. I've used it to program my Cypress USB
controller. You will have to use Control Center or CyConsole, can't
remember exactly now.

Article: 148614
Subject: Re: Vendor Tool Stability
From: Jason Thibodeau <jason.p.thibodeau@gmail.com>
Date: Fri, 06 Aug 2010 09:32:35 -0400
Links: << >>  << T >>  << A >>
On 08/06/2010 01:03 AM, Tim Wescott wrote:
> On 08/05/2010 04:43 PM, Rob Gaddi wrote:
>> On 8/5/2010 12:28 PM, Nico Coesel wrote:
>>> Rob Gaddi<rgaddi@technologyhighland.com> wrote:
>>>
>>>> On 8/4/2010 6:43 AM, Gabor wrote:
>>>>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> wrote:
>>>>>> A project I am considering undertaking would require that an FPGA's
>>>>>> implementation flow (synthesis through bitgen) be routinely run in a
>>>>>> scripted form at customer locations by the end customer, likely a
>>>>>> non-
>>>>>> engineer. The RTL input can be assumed to be good. All aspects of
>>>>>> the vendor tools would be hidden from the end user via scripts or
>>>>>> GUI.
>>>>>>
>>>>>> The stability of the vendor tools are the biggest concern in this
>>>>>> project. I am not tied to any vendor. The performance specs are such
>>>>>> that almost any current or last generation FPGA could handle the
>>>>>> load.
>>>>>>
>>>>>> I would appreciate hearing your thoughts on which vendor to consider
>>>>>> for this application. Unpredictable errors and crashes are something
>>>>>> that must be avoided.
>>>>>>
>>>>>> Thank you in advance.
>>>>>> Angie
>>>>>
>>>>> Having worked with Xilinx tools and devices for many years, I would
>>>>> say that it is possible to have very stable results as long as you
>>>>> know what to avoid. Generally speaking, a design with one system
>>>>> clock and no special feature usage almost never has any issues
>>>>> through the tool chain. Start adding too many clock resources
>>>>> or other special features and you can run into issues where the
>>>>> tools need to be guided to complete the design. I don't know
>>>>> enough about your application to say whether Xilinx tools are
>>>>> stable enough for your purposes. Whichever chip vendor you
>>>>> pick, you will have some things you need to avoid. Only the
>>>>> synthesis portion of the tool chain can be de-coupled from the
>>>>> chip vendor. It would really help if you had extensive experience
>>>>> working with your vendor of choice before going into your own
>>>>> tool implementation. Most of the annoying bugs from Xilinx
>>>>> are not in the actual synthesis / place / route / build, but in the
>>>>> GUI wrapper.
>>>
>>> I agree. The command line tools seem to work just fine.
>>>
>>>>> Regards,
>>>>> Gabor
>>>>
>>>> I've had nothing but problems with stability of Xilinx designs,
>>>> actually. Routinely in going from one version of the toolchain to the
>>>> next, command line options are changed or deprecated, forcing me to
>>>> tweak the settings in my Makefile. Right now I'm in the process of
>>>> opening a Webcase because a design which, under 12.1, was willing to
>>>> respect IOB=FORCE to push some input flip-flops into the ILOGIC cells
>>>> for timing reasons, it no longer will under 12.2.
>>>
>>> IIRC it is possible to install and use several different versions of
>>> the Xilinx tools if you use make or batch files.
>>>
>>
>> That's actually what I'm doing now on my Linux build machine; the
>> different versions of the Xilinx tools seems to all play fairly nicely
>> there. On my Windows box, versions 11 and higher (FlexLM) get seriously
>> snippy with one another.
>
> Give Xilinx time, they'll get the deficiencies in the Linux versions
> sorted out soon enough -- then your dissimilar versions will have
> trouble playing together on the Linux box, too!
>
> (Kudos to Xilinx, by the way -- the Linux version of their tool set is
> perking along quite nicely under Ubuntu. Other than having to roll my
> own driver for the parallel cable, all has worked straight out of the box).
>

Agreed. I have a few versions running great on two separate Fedora 
machines. One is F13 and one is F12.

-- 
Jason Thibodeau

Article: 148615
Subject: Re: A question from a VHDL beginner
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 06 Aug 2010 07:29:00 -0700
Links: << >>  << T >>  << A >>
On 8/4/2010 11:10 AM, alessandro.strazzero@gmail.com wrote:

> With my surprise, the model doesn't work well as in ModelSim and I
> don't understand the
> reasons.
> could you suggest me some guidelines where to search for the
> problems ?

You might also have a look at the rtl viewer for missing wires or flops.

  -- Mike Treseler



Article: 148616
Subject: Re: Vendor Tool Stability
From: John McCaskill <jhmccaskill@gmail.com>
Date: Fri, 6 Aug 2010 08:48:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 6:43=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
> On 8/5/2010 12:28 PM, Nico Coesel wrote:
>
>
>
> > Rob Gaddi<rga...@technologyhighland.com> =A0wrote:
>
> >> On 8/4/2010 6:43 AM, Gabor wrote:
> >>> On Aug 3, 11:23 pm, Angela O<angieoak...@gmail.com> =A0 wrote:
> >>>> A project I am considering undertaking would require that an FPGA's
> >>>> implementation flow (synthesis through bitgen) be routinely run in a
> >>>> scripted form at customer locations by the end customer, likely a no=
n-
> >>>> engineer. =A0The RTL input can be assumed to be good. =A0All aspects=
 of
> >>>> the vendor tools would be hidden from the end user via scripts or GU=
I.
>
> >>>> The stability of the vendor tools are the biggest concern in this
> >>>> project. =A0I am not tied to any vendor. =A0The performance specs ar=
e such
> >>>> that almost any current or last generation FPGA could handle the
> >>>> load.
>
> >>>> I would appreciate hearing your thoughts on which vendor to consider
> >>>> for this application. =A0Unpredictable errors and crashes are someth=
ing
> >>>> that must be avoided.
>
> >>>> Thank you in advance.
> >>>> Angie
>
> >>> Having worked with Xilinx tools and devices for many years, I would
> >>> say that it is possible to have very stable results as long as you
> >>> know what to avoid. =A0Generally speaking, a design with one system
> >>> clock and no special feature usage almost never has any issues
> >>> through the tool chain. =A0Start adding too many clock resources
> >>> or other special features and you can run into issues where the
> >>> tools need to be guided to complete the design. =A0I don't know
> >>> enough about your application to say whether Xilinx tools are
> >>> stable enough for your purposes. =A0Whichever chip vendor you
> >>> pick, you will have some things you need to avoid. =A0Only the
> >>> synthesis portion of the tool chain can be de-coupled from the
> >>> chip vendor. =A0It would really help if you had extensive experience
> >>> working with your vendor of choice before going into your own
> >>> tool implementation. =A0Most of the annoying bugs from Xilinx
> >>> are not in the actual synthesis / place / route / build, but in the
> >>> GUI wrapper.
>
> > I agree. The command line tools seem to work just fine.
>
> >>> Regards,
> >>> Gabor
>
> >> I've had nothing but problems with stability of Xilinx designs,
> >> actually. =A0Routinely in going from one version of the toolchain to t=
he
> >> next, command line options are changed or deprecated, forcing me to
> >> tweak the settings in my Makefile. =A0Right now I'm in the process of
> >> opening a Webcase because a design which, under 12.1, was willing to
> >> respect IOB=3DFORCE to push some input flip-flops into the ILOGIC cell=
s
> >> for timing reasons, it no longer will under 12.2.
>
> > IIRC it is possible to install and use several different versions of
> > the Xilinx tools if you use make or batch files.
>
> That's actually what I'm doing now on my Linux build machine; the
> different versions of the Xilinx tools seems to all play fairly nicely
> there. =A0On my Windows box, versions 11 and higher (FlexLM) get seriousl=
y
> snippy with one another.
>
> --
> Rob Gaddi, Highland Technology
> Email address is currently out of order


Xilinx has been changing how they install their software to make it
easier to have multiple versions on Windows machines.  Starting with
11.1 (I think) they put each installed version into its own sub-
directory under /Xilinx by default.  You still need to deal with
environment variables. I did this on my machines by replacing the hard
coded version in the environment variables with a XIL_VERSION
variable. Then I would just change that one when I switched between
versions, in this case only running one version at a time.

Starting with 12.1, the install no longer sets environment variables.
Instead, the entries in the start menu point to a batch file that sets
the environment variables for the shell the tools are launched in for
that run.

I currently have 12.1 and 11.4 running at the same time with out
interfering with each other.

I have not had any problems related to FlexLM, and in addition to ISE
System Edition, I also have ModelSim SE, two versions of HyperLynx and
Impulse C all which use FlexLM installed on twenty similar Windows
Vista machines using node locked licenses (locked to MAC IDs).   I
also have a subset of that software running without problems on a few
more Windows XP machines that are not similar to the others. I have
not tried the floating licenses yet.

Your post strongly implies that you are seeing FlexLM problems, is
that what you mean when you say the tools get snippy with each other,
or did you mean something else?



Regards,

John McCaskill
www.FasterTechnology.com
Xilinx Alliance Partner and exclusive Xilinx Authorized Training
Provider for eight US states.


Article: 148617
Subject: Re: Generic parameters in Actel Libero SmartDesign Components
From: "Joan@Actel" <actel.joan@gmail.com>
Date: Fri, 6 Aug 2010 14:06:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Aragorc,

You can't set generic parameters for the components in SmartDesign. If
you have generic parameters, they have to do that part of the design
in HDL and specify any generic parameters in the HDL code.

Regards,

Joan - you can reach me on Twitter: @Actelcorp or by email at
socialmedia@actel.com

On Aug 4, 3:20=A0pm, "Aragorc" <Aragorc@n_o_s_p_a_m.hotmail.com> wrote:
> Hello
>
> I need some help for using Actel Libero IDE.
> The SmartDesign fonctionnality enable me to design my code as a block
> diagramm.
> This is a very convenient way to keep global view of my programm.
> But I don't know how to set generic parameters with components. I know th=
is
> is really easy to do with Altera Active HDL, but I can't find the way wit=
h
> Libero.
> Does anyone knows how to use generics with components?
>
> I hope my question is understable.
> Thank you for your help.
> +++
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com


Article: 148618
Subject: Re: A question from a VHDL beginner
From: "Ammar2k" <aas.connect@n_o_s_p_a_m.gmail.com>
Date: Sat, 07 Aug 2010 09:27:53 -0500
Links: << >>  << T >>  << A >>
All above points are gud.

one more point i would like to add.

Run Post-Synthesis Simulation 

or

Post-Place-and-Route Simulation on your design

(on Xilinx ISE its possible, dont know about other softwares)

and check if post-synthesis results are still the same with RTL Simulation
Results, 

if they are not consistent with each other, you need to debug your code
again.. if they are consistent, then probablly there are more physical
issues as discussed by others

regards
Ammar

>On 8/4/2010 11:10 AM, alessandro.strazzero@gmail.com wrote:
>
>> With my surprise, the model doesn't work well as in ModelSim and I
>> don't understand the
>> reasons.
>> could you suggest me some guidelines where to search for the
>> problems ?
>
>You might also have a look at the rtl viewer for missing wires or flops.
>
>  -- Mike Treseler
>
>
>

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148619
Subject: VHDL newbie- stuck just weeks before project submission :(..please
From: lastminutepanic <sheetalgandhi333@gmail.com>
Date: Sat, 7 Aug 2010 10:14:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

For my Masters project, I'm trying to implement a multiplier, and a
MAC where the outputs are calculated per clock cycle and stored in a
text file which can then be used for further processing.

However, both these designs are giving out partial products(I guess
they are partial products) at the output too, before they give the
final result..I've tried changing the codes, changing clock frequency
in testbench etc. but nothing seems to work...

Is there any way to implement a output_ready signal for multipliers/
adders?(I saw a few codes using shifter for rdy, but could not
understand the logic behind it)

I'm using the embedded Mult18X18 in Spartan 3..but do not want to use
the Core generator for MAC(which has a RDY signal) as the code has to
be kept portable.


Code for multiplier is--

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Single_Mul is
    Port ( Clk : in  STD_LOGIC;
           Mul1 : in  STD_LOGIC_VECTOR (17 downto 0);
           Mul2 : in  STD_LOGIC_VECTOR(17 downto 0);
           Mul_Res : out  STD_LOGIC_VECTOR(35 downto 0));
end Single_Mul;

architecture Behavioral of Single_Mul is
Signal Prod : Signed( 35 downto
0):="000000000000000000000000000000000000";

begin
process(clk)is
begin

if rising_edge(Clk) then
Prod<=signed(Mul1)*signed(Mul2);
end if;
end process;

Prod_Process:Process(prod)
begin

Mul_Res<=STD_LOGIC_VECTOR(Prod);--here I was hoping this process is
invoked only when the --clocked process above is complete...

end process;

end Behavioral;


Code for MAC--

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_STD.all;


entity Mul_Adder is
    Port ( MulA : in STD_LOGIC_VECTOR (17 downto 0);
           MulB : in STD_LOGIC_VECTOR(17 downto 0);
           Multi_Res : in STD_LOGIC_VECTOR(35 downto 0);
           MulAdd_Res : out STD_LOGIC_VECTOR(35 downto 0);
           Clk : in  STD_LOGIC);
end Mul_Adder;

architecture Behavioral of Mul_Adder is
shared variable temp :SIGNED(35 downto
0);--:="000000000000000000000000000000000000";
Signal temp1:SIGNED(35 downto
0):="000000000000000000000000000000000000";


begin
Process(Clk) is
BEGIN

If rising_edge(Clk)
then
temp:=signed(MulA)*signed(MulB);
temp1<=signed(Multi_Res)+temp;
end if;

End Process;

MulAdd_Res_process: Process(temp1)
begin
MulAdd_Res<=STD_LOGIC_VECTOR(temp1);
end Process;


end Behavioral;


Am I doing anything wrong here? Any help in this direction would be
useful

Article: 148620
Subject: Re: VHDL newbie- stuck just weeks before project submission
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Mon, 9 Aug 2010 08:15:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 7 Aug., 19:14, lastminutepanic <sheetalgandhi...@gmail.com> wrote:

> For my Masters project, I'm trying to implement a multiplier, and a
> MAC where the outputs are calculated per clock cycle and stored in a
> text file which can then be used for further processing.

Calculation per clock cycle and storing in file means unnecessary mix
of RTL and behavioral in most cases.
Per cycle is used for HW, storing in files is pure SW. Are you sure
you intend this?

> However, both these designs are giving out partial products(I guess
> they are partial products) at the output too, before they give the
> final result..I've tried changing the codes, changing clock frequency
> in testbench etc. but nothing seems to work...

Partial products for 12*34 would be 340 and 68.
You see intermediate results when not every bit is settled. This means
you need to wait until the output is settled.
normally you do combinatoric between two register stages and your
timing analysis ensures the output is settled before the next clock
cycle.
But in real hardware you will see some intermediate results even on
the output register when having more then one bit. You just need to
ensure, that the output settling between first and last bit is small
enough for your requirements (often within less than 1 ns).

> Is there any way to implement a output_ready signal for multipliers/
> adders?(I saw a few codes using shifter for rdy, but could not
> understand the logic behind it)

Yes. But I doubt I can teach you this in 2 lines, when you didn't
learn this up to now.

> library IEEE;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> use IEEE.NUMERIC_STD.ALL;

Never mix those two packages without very good reason.  It is like
left foot on brake an right foot on gas at the same time.

> architecture Behavioral of Single_Mul is
> Signal Prod : Signed( 35 downto
> 0):="000000000000000000000000000000000000";

Initialisations of signals shall be used only with good reason. It
masks potential errors. If needed, use (others=>'0') instead of
"00..00"

> if rising_edge(Clk) then
> Prod<=signed(Mul1)*signed(Mul2);
> end if;
> end process;
>
> Prod_Process:Process(prod)
> begin
>
> Mul_Res<=STD_LOGIC_VECTOR(Prod);--here I was hoping this process is
> invoked only when the --clocked process above is complete...

Hopeless. If you move this line between rising_edge(Clk) and end if,
you get something like you intended (but one clock cycle latency)

regards Thomas


Article: 148621
Subject: Re: VHDL newbie- stuck just weeks before project submission
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 9 Aug 2010 12:16:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Aug., 17:15, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:

> > use IEEE.STD_LOGIC_UNSIGNED.ALL;
> > use IEEE.NUMERIC_STD.ALL;
>
> Never mix those two packages without very good reason. =A0It is like
> left foot on brake an right foot on gas at the same time.

Indeed. Use numeric_std only.
>
> > architecture Behavioral of Single_Mul is
> > Signal Prod : Signed( 35 downto
> > 0):=3D"000000000000000000000000000000000000";
>
> Initialisations of signals shall be used only with good reason.
I don't agree.
The initialization should match the hardware.
So if you have one of these old fashioned ASIC registers that come
up at a random state you initialize them to "U" (which is the default
for VHDL)
but in modern FPGAs and many ASIC libraries registers have a defined
power on
state and simulation should reflect that.

XST honors the initialization values during synthesis and I expect
other tools to do the same.

Kolja

Article: 148622
Subject: Re: VHDL newbie- stuck just weeks before project submission
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 9 Aug 2010 13:19:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 9, 3:16=A0pm, Kolja Sulimma <ksuli...@googlemail.com> wrote:

>
> > Initialisations of signals shall be used only with good reason.
>
> I don't agree.
> The initialization should match the hardware.
> So if you have one of these old fashioned ASIC registers that come
> up at a random state you initialize them to "U" (which is the default
> for VHDL)
> but in modern FPGAs and many ASIC libraries registers have a defined
> power on
> state and simulation should reflect that.
>

Do you think it's still a good idea to have signal initializations to
'match the hardware' in the following contexts as well?
- Free running oscillator on the board is input to the FPGA which
implies there is no control of the setup/hold time of anything for
that very first rising edge of the clock (which then overwrites that
initialization anyway)?
- Unskilled designer that does not provide any form of hardware reset
to their logic.

KJ

Article: 148623
Subject: Signal value clears for no reason [VHDL, ISE 10.1]
From: "ColdStart" <teslashock@n_o_s_p_a_m.msn.com>
Date: Mon, 09 Aug 2010 21:16:12 -0500
Links: << >>  << T >>  << A >>
Hello,

Well my code is huge... but the interesting part is.. lets say i have some
10 bit wide signal, and in my logic i clear it when it reaches value 768.

Actually its not just signal, its a D flip-flop with a controlling mux, and
i load new value or clear it using the Mux...

When i was running and synthesizing this code in ISE 9.1 my logic was just
fine... but now, with version 10.1 it compiles and synthesizes good... but
during debug...i noticed that when that signal reaches value 13... it
suddenly goes to 0... 

(actually it is my FSM which checks if its 768, the through the mux cleares
it...and starts whole thing again...)

But now, its NOT MY FSM who cleares it before 768...its reset by itself!...
very weird... any ideas?

p.s. im running same code which compiled and worked well from previous
version, without any changes...

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 148624
Subject: Re: Signal value clears for no reason [VHDL, ISE 10.1]
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 9 Aug 2010 19:50:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 9, 10:16=A0pm, "ColdStart" <teslashock@n_o_s_p_a_m.msn.com>
wrote:
> Hello,
>
> Well my code is huge... but the interesting part is.. lets say i have som=
e
> 10 bit wide signal, and in my logic i clear it when it reaches value 768.
>

My reading of what you wrote is that you *asynchronously* clear the 10
bits when those 10 bits happen to reach the value 768.  If that's the
case, then you're bound to have trouble.

> Actually its not just signal, its a D flip-flop with a controlling mux, a=
nd
> i load new value or clear it using the Mux...
>

To many uses of the word 'it' and nobody will be clear about just what
'it' is.  Less description and more posting of the actual code snippet
would be 10x more useful than what you're trying to describe.

> When i was running and synthesizing this code in ISE 9.1 my logic was jus=
t
> fine... but now, with version 10.1 it compiles and synthesizes good... bu=
t
> during debug...i noticed that when that signal reaches value 13... it
> suddenly goes to 0...
>

Not surprising at all if my first sentence regarding what I think
you're describing is correct.

> (actually it is my FSM which checks if its 768, the through the mux clear=
es
> it...and starts whole thing again...)
>

Starts what whole thing?

> But now, its NOT MY FSM who cleares it before 768...its reset by itself!.=
..
> very weird... any ideas?
>

1. If the logic defining the behavior of the 10 bit thing causes that
10 bit thing to be reset when it reaches a particular value, you've
got some rewriting of the code to do.
2. Could be timing.  Have you:
    - Setup the timing constraints and run static timing analysis?
Did it pass?
    - Is there more than one clock domain in this design?

> p.s. im running same code which compiled and worked well from previous
> version, without any changes...
>
Some things to keep in mind...
- You can't debug a working system.  Don't waste time analyzing the
working system, focus on the non-working one as if you didn't know
about the older, working one.
- Sometimes things 'work' although they have latent design issues
still to be uncovered.  Whether you should consider yourself 'lucky'
that it was working or 'unfortunate' because you didn't uncover the
problem sooner is up to you to decide.

Feel free to post some actual snippets of code that demonstrate what
you're saying that accurately represent what you're doing. (1)

Kevin Jennings

(1) An example of what I think you're describing (which would be a
problem if it is what you have is)

process(clk, clear)
begin
  if (clear =3D '1') then
    big_sig <=3D (others =3D> '0');
  elsif rising_edge(clk) then
    big_sig <=3D big_sig + 1;
  end if;
end process;

clear <=3D '1' when (big_sig =3D 768) else '0';



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