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 123000

Article: 123000
Subject: Re: Design Behavior affected by use of Chipscope
From: "John Retta" <jretta@rtc-inc.com>
Date: Tue, 14 Aug 2007 02:59:04 GMT
Links: << >>  << T >>  << A >> 
You probably have a timing problem in your design.

Make sure you run trace on your design with the -u option.
This will flag any unconstrained paths.  Pursue them with
extreme prejudice.

Also make sure you interface signals have been mapped to
IOB flip-flops.  You can tell by looking at the .pad file.

When you go from chipscope (working) to non-chipscope,
do you see a change in which signals are mapped to IOB FFs?

If a FF output only drives an I/O pad, it can be placed in an
IOB FF.  However, if the output is also added to chipscope,
then feedback to internal logic is required, and the FF can not
be added to an IOB FF.

The three reports to get very familiar with are your .mrp, your
.pad, and your .report.

-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
Colorado Based Xilinx consultant

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


"MNiegl" <Michael.Niegl@cern.ch> wrote in message 
news:1187023975.051359.277000@d55g2000hsg.googlegroups.com...
> Hello everyone,
>
> I have encountered a rather strange behavior in one of my FPGA
> Designs. i have a DDR2 RAM controller (generated partly with the
> Memory Interface Generator) in a Xilinx Virtex-4 FX60. After startup
> it sends out some dummy patterns and reads them back to adjust the
> delay between issuing a command to the RAM and the execution. When I
> don't probe exactly these signals in the FPGA with Chipscope then this
> procedure is only executed sporadically, i.e. most times after
> configuration or a global reset the RAM controller never finishes its
> init-procedure (even when using an identical bit-file the success of
> the initialization can differ when configuring the FPGA another time).
> When I do use Chipscope however, it is executed everytime, so the use
> of it definitely influences the design. So the question is now, what
> could be the reason for it? Could it be a placement issue of the
> IODELAY elements used for the interface to the RAM or any other FPGA
> primitives that interface to it?
> If anyone had any guesses or ideas what could be the main influence
> I'd be happy to hear them, as I obviously would like to have the
> design running stably without needing Chipscope included.
>
> Cheers,
> Michael
>
Article: 123001
Subject: Re: regarding the clock issues in the fpga...
From: "ekavirsrikanth@gmail.com" <ekavirsrikanth@gmail.com>
Date: Mon, 13 Aug 2007 22:36:55 -0700
Links: << >>  << T >>  << A >> 
On Aug 13, 6:15 pm, John_H <newsgr...@johnhandwork.com> wrote:
> ekavirsrika...@gmail.com wrote:
> > hi all,
>
> > i have got one problem:
>
> > i have designed sonet sts-3c framer/deframer  where it works at 155mhz
> > freq which i am getting it form the optics card whrere CDR(clock data
> > recovery circuit outside the board). form that circuit i am getting
> > the  differential data and differetial clock as inputs and  i am
> > processing for output (differential data). which iam sending it to
> > optics card which will convert the electrical diff data into optical
> > signal and it is recongniged in the OmniBer (performace analyzer). my
> > problem is as i am getting the data and the clock i have a problem in
> > detecting the output on OMNIBER but my logic looks quiet ok.
>
> > i am using virtex - 2pro fpga which can support 155mhz clock.......
>
> <snip>
>
> > plz i need feedback from u guys
>
> > regards
> > srik
>
> FPGAs are not precision analog components.  The jitter produced by an
> FPGA will be large compared to SONET jitter specifications.  If your
> "omniber" is not tolerant to this excessive jitter, your results may not
> be what you want.
>
> Please clarify: if pass the data from the omniber to the FPGA and back
> to the omniber, are your results fine?  That wasn't clear.
>
> Is your problem that the loopback data *is* fine but your own frame
> logic is not?
>
> Do you know what portion of the frame and payload is scrambled and what
> is not?- Hide quoted text -
>
> - Show quoted text -

hi john thank you for u r valuble reply...

intially what i am trying is i just wnated to detect the framing
bytes .. in the omniber... rest of the things i will take care once
the logic doesnot show any pattern loss in the omniber.

i am taking the sonet frames form the omniber and at this point of
time i am not descrambling (in deframer) or scrambling (in
framer).just taking what ever omniber is sending then detecting the
framer bytes(a1 and a2 bytes) and then allowing the rest of the
payload and other overhead.  on detecting the framing bytes i am
sending rest of data through fifo and then passign the data to the
framer part. in the framer side just inserting the a1 and a2 bytes and
other overhead bytes and just allowing the payload that i got form
deframer. then sending it to optics card to omniber.

now my loopback (which i have done for just checking if data is
processign wrt the clock) is working the second code which i have
posted before but my sts3c deframer/framer logic is not working as i
am usign the clock (derived form the optics card) somany places in the
design is that creating any problem any clock related issues are
there......

regards
srik
Article: 123002
Subject: new xilinx forums
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 14 Aug 2007 06:00:01 -0000
Links: << >>  << T >>  << A >> 
http://forums.xilinx.com/

are open if someone didnt notice yet

Antti
Article: 123003
Subject: edk + spi
From: "u_stadler@yahoo.de" <u_stadler@yahoo.de>
Date: Mon, 13 Aug 2007 23:53:05 -0700
Links: << >>  << T >>  << A >> 
hi

is there a reason why the clock divisor for the spi clock in edk 9.1
cant be smaller than 16?
i would need 4. is there a way to do that or do i have to write my own
spi module?

thanks
urban
Article: 123004
Subject: SATA OOB using Rocket IO (Virtex 5)
From: mkumarsampath@gmail.com
Date: Tue, 14 Aug 2007 06:55:14 -0000
Links: << >>  << T >>  << A >> 
Hi All,

Does anyone have information on using Rocket IO of Virtex 5 for SATA
OOB.
I would be grateful if anyone can send me a link to the document that
details the
connection settings.

Thanks,
Sampath.
Article: 123005
Subject: Re: edk + spi
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 14 Aug 2007 06:58:43 -0000
Links: << >>  << T >>  << A >> 
On 14 Aug., 08:53, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote:
> hi
>
> is there a reason why the clock divisor for the spi clock in edk 9.1
> cant be smaller than 16?
> i would need 4. is there a way to do that or do i have to write my own
> spi module?
>
> thanks
> urban

its simpler to write your own, besides the OPB_SPI is very bad in
terms of logic levels,
very often it is reducing the max clock of the entire system

hm, I think some xilinx ref design includes some other SPI core
and there is free SPI core from finger lakes also

http://spreadsheets.google.com/ccc?key=ptIl7po0K1kGmgMEYsJIUPw
there are some links

Antti
Article: 123006
Subject: Re: edk+uclinux ??? <about make dep>
From: backhus <nix@nirgends.xyz>
Date: Tue, 14 Aug 2007 09:25:15 +0200
Links: << >>  << T >>  << A >> 
Hi,

look at: realpath(/include) failed, No such file or directory
Your host system probably has no include folder in the root directory.

Something (maybe an include-path variable) is missing in your setup.
Look at your makefiles for something like:

$THE-MISSING-PATH-WITH-THE-UNKNOWN-VARIABLE-NAME/include

If the path variable is empty the resuling path is /include which is 
terribly wrong of course. It should be something like

/home/devel/uclinux/src/uClinux-2.4.x/include

and

this line: make[3]: *** [fastdep] Error 1
tells you where to look at first.

Good luck
   Eilert


kobelai15@gmail.com schrieb:
> what's wrong with following word???
> 
> [root@localhost uClinux-dist]# make dep
> make ARCH=microblaze CROSS_COMPILE=mb- -C linux-2.4.x dep
> make[1]: Entering directory `/home/devel/uclinux/src/uClinux-2.4.x'
> rm -f .depend .hdepend
> make _sfdep_arch/microblaze/kernel _sfdep_arch/microblaze/mm
> _sfdep_arch/microblaze/lib _sfdep_arch/microblaze/xilinx_ocp
> _sfdep_arch/microblaze/platform/uclinux-auto _sfdep_kernel
> _sfdep_drivers _sfdep_mmnommu _sfdep_fs _sfdep_net _sfdep_ipc
> _sfdep_lib _sfdep_crypto _FASTDEP_ALL_SUB_DIRS="arch/microblaze/kernel
> arch/microblaze/mm arch/microblaze/lib arch/microblaze/xilinx_ocp arch/
> microblaze/platform/uclinux-auto kernel drivers mmnommu fs net ipc lib
> crypto"
> make[2]: Entering directory `/home/devel/uclinux/src/uClinux-2.4.x'
> make -C arch/microblaze/kernel fastdep
> make[3]: Entering directory `/home/devel/uclinux/src/uClinux-2.4.x/
> arch/microblaze/kernel'
> /home/devel/uclinux/src/uClinux-2.4.x/scripts/mkdep -D__KERNEL__ -I/
> home/devel/uclinux/src/uClinux-2.4.x/include  -Wall -Wstrict-
> prototypes -Wno-trigraphs -O1 -g -fno-strict-aliasing -fno-common -
> DPLATFORM=uclinux-auto -O3 -fno-builtin -DNO_MM -DNO_FPU -D__ELF__ -
> DMAGIC_ROM_PTR -DUTS_SYSNAME=\"uClinux\" -D__linux__ -I/include -mxl-
> barrel-shift -mno-xl-soft-div -mno-xl-soft-mul -I/home/devel/uclinux/
> src/uClinux-2.4.x/arch/microblaze/xilinx_ocp -nostdinc -iwithprefix
> include -- bug.c crtinit.S entry.S exceptions.c head.S highres_timer.c
> hw_exception_handler.S init_microblaze_timer.c intv.S irq.c mach.c
> mach.h mbvanilla.c memcons.c microblaze.c microblaze_defs.c
> microblaze_defs.h microblaze_intc.c microblaze_ksyms.c
> microblaze_timer.c process.c procfs.c ptrace.c semaphore.c setup.c
> signal.c syscalls.c time.c xmbserial.c xmbserial.h > .depend
> realpath(/include) failed, No such file or directory
> make[3]: *** [fastdep] Error 1
> make[3]: Leaving directory `/home/devel/uclinux/src/uClinux-2.4.x/arch/
> microblaze/kernel'
> make[2]: *** [_sfdep_arch/microblaze/kernel] Error 2
> make[2]: Leaving directory `/home/devel/uclinux/src/uClinux-2.4.x'
> make[1]: *** [dep-files] Error 2
> make[1]: Leaving directory `/home/devel/uclinux/src/uClinux-2.4.x'
> make: *** [dep] Error 2
>
Article: 123007
Subject: mixed Verilog/VHDL in ispLever 7.0 broken
From: Richard Klingler <me@aol.com>
Date: Tue, 14 Aug 2007 10:35:22 +0200
Links: << >>  << T >>  << A >> 
G'day (o;

Just got the confirmation that ispLever 7.0 is broken for
mixed Verilog/VHDL designs...my case was that a VHDL T80
Z80 CPU core module wrapped in a Verilog top file would
fail with Precision unable to find work library...

Now with the patch it's running through (o;

Either contact Lattice for a fix if you have this issue
or wait until end of year for ispLever 7.1 (o;


cheers
rick
Article: 123008
Subject: xst fails...
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Tue, 14 Aug 2007 11:31:52 +0200
Links: << >>  << T >>  << A >> 
Hi,

I'm currently trying to synthesize a big design on a Virtex4-VLX100. Now
the problem is, that xst fails and just gives the following line:

Process "Synthesize" failed

Is there a way to hunt for the problem that causes this behavior? I'm a
little bit lost, since there is no hint by xst.

Thanks,
Matthias
Article: 123009
Subject: Re: xst fails...
From: Jon Beniston <jon@beniston.com>
Date: Tue, 14 Aug 2007 02:44:20 -0700
Links: << >>  << T >>  << A >> 
On 14 Aug, 10:31, Matthias Alles <REMOVEallesCAPIT...@NOeit.SPAMuni-
kl.de> wrote:
> Hi,
>
> I'm currently trying to synthesize a big design on a Virtex4-VLX100. Now
> the problem is, that xst fails and just gives the following line:
>
> Process "Synthesize" failed
>
> Is there a way to hunt for the problem that causes this behavior? I'm a
> little bit lost, since there is no hint by xst.
>
> Thanks,
> Matthias

Try posting the full output.

Cheers,
Jon
Article: 123010
Subject: Re: mixed Verilog/VHDL in ispLever 7.0 broken
From: Jon Beniston <jon@beniston.com>
Date: Tue, 14 Aug 2007 02:45:03 -0700
Links: << >>  << T >>  << A >> 
On 14 Aug, 09:35, Richard Klingler <m...@aol.com> wrote:
> G'day (o;
>
> Just got the confirmation that ispLever 7.0 is broken for
> mixed Verilog/VHDL designs...my case was that a VHDL T80
> Z80 CPU core module wrapped in a Verilog top file would
> fail with Precision unable to find work library...
>
> Now with the patch it's running through (o;
>
> Either contact Lattice for a fix if you have this issue
> or wait until end of year for ispLever 7.1 (o;

Is it ispLever or Precision that is the problem. Does Synplify work
better?

Jon
Article: 123011
Subject: Re: mixed Verilog/VHDL in ispLever 7.0 broken
From: Richard Klingler <me@aol.com>
Date: Tue, 14 Aug 2007 12:02:03 +0200
Links: << >>  << T >>  << A >> 
Jon Beniston wrote:
> On 14 Aug, 09:35, Richard Klingler <m...@aol.com> wrote:
>> G'day (o;
>>
>> Just got the confirmation that ispLever 7.0 is broken for
>> mixed Verilog/VHDL designs...my case was that a VHDL T80
>> Z80 CPU core module wrapped in a Verilog top file would
>> fail with Precision unable to find work library...
>>
>> Now with the patch it's running through (o;
>>
>> Either contact Lattice for a fix if you have this issue
>> or wait until end of year for ispLever 7.1 (o;
> 
> Is it ispLever or Precision that is the problem. Does Synplify work
> better?
> 
> Jon
> 

 From the patched files it looks like an ispLever problem
as no Precision files are included...

Dunno if Synplify works better as you have to install
the full version for this feature...

cheers
rick
Article: 123012
Subject: Re: xst fails...
From: Gerhard Hoffmann <spamtrap@hoffmann-hochfrequenz.de>
Date: Tue, 14 Aug 2007 12:31:02 +0200
Links: << >>  << T >>  << A >> 
On Tue, 14 Aug 2007 02:44:20 -0700, Jon Beniston <jon@beniston.com> wrote:

>> I'm currently trying to synthesize a big design on a Virtex4-VLX100. Now
>> the problem is, that xst fails and just gives the following line:
>>
>> Process "Synthesize" failed
>>
>> Is there a way to hunt for the problem that causes this behavior? I'm a
>> little bit lost, since there is no hint by xst.

>Try posting the full output.


His problem is: this is the full output.

I had cases that were even less verbose: ""


Sometimes it helps to do project->cleanup project files, perhaps with touching
the sources to update the date.

Sometimes I had to rebuilt the project in a different directory under a different name,
source file by source file. That was not funny.

One extra tough problem simply vanished into thin air when I updated 
from ISE 8.2 to 9.1

Last week I changed some VHDL components to direct entity instantiations and 
made a typo in an entity name. I got no error during compilation but a
crash when linking/building the netlist.

So, it could be about everyting.

It would be a great help if ISE could spit out a makefile.


regards, Gerhard
Article: 123013
Subject: Re: xst fails...
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Tue, 14 Aug 2007 12:32:30 +0200
Links: << >>  << T >>  << A >> 
There is nothing of interest in the output:

INFO:Xst:2261 - The FF/Latch <configure.parallelism_2> in Unit <hws> is
equivalent to the following 155 FFs/Latches, which will be removed :
<configure.parallelism_3> <configure.parallelism_4>
<configure.parallelism_5> <configure.use_virtual_edge>
<configure.cnd_123> <configure.cnd_122> <configure.cnd_121>
<configure.cnd_120> <configure.cnd_119> <configure.cnd_118>
<configure.cnd_117> <configure.cnd_116> <configure.cnd_115>
<configure.cnd_114> <configure.cnd_113> <configure.cnd_112> <configure.cn
d_111> <configure.cnd_110> <configure.cnd_109> <configure.cnd_108>
<configure.cnd_107> <configure.cnd_106> <configure.cnd_105>
<configure.cnd_104> <configure.cnd_103> <configure.cnd_102>
<configure.cnd_101> <configure.cnd_100> <configure.cnd_99>
<configure.cnd_98> <configure.cnd_97> <configure.cnd_96>
<configure.cnd_95> <configure.cnd_94> <configure.cnd_93>
<configure.cnd_92> <configure.cnd_91> <configure.cnd_90>
<configure.cnd_89> <configure.cnd_88> <configure.cnd_87>
<configure.cnd_86> <configu
re.cnd_85>
   <configure.cnd_84> <configure.cnd_83> <configure.cnd_82>
<configure.cnd_81> <configure.cnd_80> <configure.cnd_79>
<configure.cnd_78> <configure.cnd_77> <configure.cnd_76>
<configure.cnd_75> <configure.cnd_74> <configure.cnd_73>
<configure.cnd_72> <configure.cnd_71> <configure.cnd_70>
<configure.cnd_69> <configure.cnd_68> <configure.cnd_67>
<configure.cnd_66> <configure.cnd_65> <configure.cnd_64>
<configure.cnd_63> <configure.cnd_62> <configure.cnd_61>
<configure.cnd_60> <configure.cnd_59> <con
figure.cnd_58> <configure.cnd_57> <configure.cnd_56> <configure.cnd_55>
<configure.cnd_54> <configure.cnd_53> <configure.cnd_52>
<configure.cnd_51> <configure.cnd_50> <configure.cnd_49>
<configure.cnd_48> <configure.cnd_47> <configure.cnd_46>
<configure.cnd_45> <configure.cnd_44> <configure.cnd_43>
<configure.cnd_42> <configure.cnd_41> <configure.cnd_40>
<configure.cnd_39> <configure.cnd_38> <configure.cnd_37>
<configure.cnd_36> <configure.cnd_35> <configure.cnd_34>
<configure.cnd_33> <configure.
cnd_32>
   <configure.cnd_31> <configure.cnd_30> <configure.cnd_29>
<configure.cnd_28> <configure.cnd_27> <configure.cnd_26>
<configure.cnd_25> <configure.cnd_24> <configure.cnd_23>
<configure.cnd_22> <configure.cnd_21> <configure.cnd_20>
<configure.cnd_19> <configure.cnd_18> <configure.cnd_17>
<configure.cnd_16> <configure.cnd_15> <configure.cnd_14>
<configure.cnd_13> <configure.cnd_12> <configure.cnd_11>
<configure.cnd_10> <configure.cnd_9> <configure.cnd_8> <configure.cnd_7>
<configure.cnd_6> <configu
re.cnd_5> <configure.cnd_4> <configure.cnd_3> <configure.cnd_2>
<configure.cnd_1> <configure.cnd_0> <configure.cnd_high_1>
<configure.cnd_high_2> <configure.cnd_high_3> <configure.cnd_high_4>
<configure.nr_msg_per_node_3> <configure.nr_msg_per_node_5>
<configure.nr_msg_per_node_7> <configure.nr_msg_per_node_10>
<configure.nr_msg_per_node_11> <configure.nr_chv_per_node_3>
<configure.nr_chv_per_node_4> <configure.nr_chv_per_node_5>
<configure.nr_chv_per_node_10> <configure.virtual_edge_pos_0>
   <configure.virtual_edge_pos_2> <configure.virtual_edge_pos_3>
<configure.virtual_edge_pos_4> <configure.mean_bound_VNR_10>
<configure.mean_bound_VNR_13> <configure.max_iteration_0>
<configure.max_iteration_1> <configure.max_iteration_2>
<configure.max_iteration_3> <configure.cns_per_node_2>
<configure.cns_per_node_3> <configure.cns_per_node_5>
<configure.cns_per_node_6>

Process "Synthesize" failed

That's all! The info is correct, since the values are constant.


Jon Beniston schrieb:
> On 14 Aug, 10:31, Matthias Alles <REMOVEallesCAPIT...@NOeit.SPAMuni-
> kl.de> wrote:
>> Hi,
>>
>> I'm currently trying to synthesize a big design on a Virtex4-VLX100. Now
>> the problem is, that xst fails and just gives the following line:
>>
>> Process "Synthesize" failed
>>
>> Is there a way to hunt for the problem that causes this behavior? I'm a
>> little bit lost, since there is no hint by xst.
>>
>> Thanks,
>> Matthias
> 
> Try posting the full output.
> 
> Cheers,
> Jon
>
Article: 123014
Subject: Re: xst fails...
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Tue, 14 Aug 2007 12:35:38 +0200
Links: << >>  << T >>  << A >> 
At least updating to the newest version didn't help. I'm currently using
ISE 9.2.01i. I will try with the cleaned project and maybe start a new
project as well.

Matthias

Gerhard Hoffmann schrieb:
> On Tue, 14 Aug 2007 02:44:20 -0700, Jon Beniston <jon@beniston.com> wrote:
> 
>>> I'm currently trying to synthesize a big design on a Virtex4-VLX100. Now
>>> the problem is, that xst fails and just gives the following line:
>>>
>>> Process "Synthesize" failed
>>>
>>> Is there a way to hunt for the problem that causes this behavior? I'm a
>>> little bit lost, since there is no hint by xst.
> 
>> Try posting the full output.
> 
> 
> His problem is: this is the full output.
> 
> I had cases that were even less verbose: ""
> 
> 
> Sometimes it helps to do project->cleanup project files, perhaps with touching
> the sources to update the date.
> 
> Sometimes I had to rebuilt the project in a different directory under a different name,
> source file by source file. That was not funny.
> 
> One extra tough problem simply vanished into thin air when I updated 
> from ISE 8.2 to 9.1
> 
> Last week I changed some VHDL components to direct entity instantiations and 
> made a typo in an entity name. I got no error during compilation but a
> crash when linking/building the netlist.
> 
> So, it could be about everyting.
> 
> It would be a great help if ISE could spit out a makefile.
> 
> 
> regards, Gerhard
>
Article: 123015
Subject: Virtex4+PPC+ext. RAM: Problems generating ACE files (solved!?)
From: Torsten Landschoff <t.landschoff@gmx.de>
Date: Tue, 14 Aug 2007 03:44:02 -0700
Links: << >>  << T >>  << A >> 
Hi *,

[Warning: Long post, includes patch for genace.tcl]

I am working with a custom Virtex-4 based board design using an
internal
PowerPC core and external SDRAM for code and data. Using the standard
EDK
flow, all is well: I can download the bitstream, use the PPC JTAG
interface
to upload and debug the software application.

Now, for making my tests reproducible, I wanted to generate an ACE
file
containing both the FPGA and the software configuration. After going
through the documented steps to create an ACE file using genace.tcl,
the
resulting ACE file loaded fine. However, the software did not start
running.

Connecting with XMD revealed that the software was loaded correctly
both
into the SDRAM and the internal data memory. However, the instruction
memory - connected via an isbram_if_cntrl - was not correctly set up.
Which is unfortunate as the start vector points to that memory type.

I spent a lot of time with analyzing the situation. Maybe I am doing
something wrong but I am having trouble accessing the instruction
memory
from XMD even after having the system.xmp imported using

  load xmp system.xmp

in xmd. It's just not working reliable. I tried loading the FPGA
design with
just the bootloop inside the BRAMs but was unable to see the branch
instruction doing the infinite loop. However, I could write new data
to
the instruction memory to jump into my application which then works
fine.



So I thought I had to mark my applicationt to initialize BRAMs in XPS.
This
solution leads to another problem: After configuration of the FPGA and
before
the System ACE controller load the application code to the SDRAM
memory, the
PowerPC inside the FPGA starts running and jumps into the
uninitialized
SDRAM.

As I was able to load the program correctly using xdm in interactive
mode,
I figured I could get it running by loading the system.xmp while
creating the
ACE file. This indeed helped, and my ACE files are now running fine.


What I did is a quick hack that works for me (tm), but I think this
should
be fixed in EDK as well. Here is the diff on genace.tcl:

--- /opt/Xilinx/EDK/data/xmd/genace.tcl 2006-06-30 03:26:56.000000000
+0200
+++ genace.tcl  2007-08-14 11:09:33.729977014 +0200
@@ -209,6 +209,11 @@
     puts "Converting ELF file '$elffile' to SVF file '$svffile'"

     set tgt 0
+
+    if { [catch { xload_sysfile xmp system.xmp } retval] } {
+       puts "$retval"
+       error "ERROR: Unable to load system.xmp"
+    }
     if { $target_type == "ppc_hw" } {
        set a "xconnect ppc hw -cable type xilinx_svffile fname
$svffile $xmd_options"
     } else {


As I understand, the configuration flow now goes as follows:

- System is powered on / reset
- SysACE controller clears the FPGA configuration
- SysACE ctrl. waits for FPGA to get ready for conf
- SysACE downloads the logic and BRAM configuration to the Virtex4
- ### In an ideal world, the PPC would wait
              until the software was downloaded ###
- instead: SysACE senses that FPGA is configured (DONE pin goes high),
  PowerPC starts executing instructions (from BRAM)
- here: instruction BRAM just contains here: b here so PPC loops
- SysACE halts the PowerPC using JTAG, uploads program via JTAG
through the
  PPC's memory interfaces (this is only done correctly if xmd had the
right
  memory map while creating the svf file)
- SysACE sends "continue" command to PPC via JTAG
- Configuration is complete, PPC application up and running


Can somebody tell me if I got it right? Does the patch make sense or
is there
a better way to load instruction memory from System ACE? I tried using

  xmd -xmp system.xmp -tcl genace.tcl -opt genace.opt

but it seems the "-xmp" option is ignored when running a script.


Hoping for a bit of feed back,

  Torsten
Article: 123016
Subject: Re: TEMAC Performance Issues with Virtex 4FX
From: Torsten Landschoff <t.landschoff@gmx.de>
Date: Tue, 14 Aug 2007 04:22:17 -0700
Links: << >>  << T >>  << A >> 
Hi Guru,

On 8 Aug., 13:45, Guru <ales.gor...@email.si> wrote:
> The problem I am faced now is a PPC data caching errata - when turned
> off the performance is significantly lower, when turned on errors in
> DMA descriptors appear.

Data caching errata? Do you have a pointer for those? So far I did not
run into any problems with data caching. I still have the hope it
stays that way.

Greetings, Torsten
Article: 123017
Subject: Re: Amount of wire and logic
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Tue, 14 Aug 2007 12:47:46 -0000
Links: << >>  << T >>  << A >> 
On 10 Aug., 18:26, Peter Alfke <pe...@xilinx.com> wrote:
> Everybody would agree that the need for interconnect grows faster than
> the number of things to be interconnected. Ask any urban planner or
> any phone company...

This is known as Rent's rule
http://en.wikipedia.org/wiki/Rent%27s_Rule

It states essentially that between two portions of the chip that
contain g gates you
should have T=t*g^p wires.
The constants t and p depent on the design.
p is typically between 0.5 and 0.8.
As  a result the number of wires grows at a rate of somewhat over
g^1.5 and the area
of the wires (because the avarage length is g^0.5) grows faster than
g^2


> Much simpler:
> Within a family, the ratio od routing to logic is practically
> constant, mainly for softwarwe reasons.
> One cannot create a completely new optimized software structure for
> every chip size.
The pathfinder algorithm can cope pretty well with arbitrary networks.
However the network needs to be good enough that the placer can
assume a decent cost metric.

I did not closely look at the routing architecture for the newer
architectures
but in the 90s one could clearly see in the FPGA editor that the numer
of
wires (especially longlines) per routing channel increased with the
size
of the chip. This is regular enough that any routing algorithm should
be
able to cope with it.

> Fundamental routability, a big issue years ago, is hardly an issue
> today.
That is a  marketing decision, isn't it?

An FPGA with good routability is more expensive than an FPGA with
bad routability. Therefore early FPGAs were wire starved because it
economically makes more sense to make good use of the wires and
throw away some LUTs that can not be connected.

However as the wires are next to invisible to the designer, everybody
kept complaining that not all LUTs could be connected in a larger
XC4K.
People perceive that as a loss. Therefore all manufacturers switched
theire paradigm and added more of those expensive wires.
Now all LUTs can be used but the wire utilization is really low.

The good side of this is, that the tool runtime inproves a lot if
routing
is easy and the performance results are more predictable. But we
pay a price.

Kolja Sulimma
Article: 123018
Subject: Re: regarding the clock issues in the fpga...
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 14 Aug 2007 13:11:38 GMT
Links: << >>  << T >>  << A >> 
ekavirsrikanth@gmail.com wrote:
> 
> hi john thank you for u r valuble reply...
> 
> intially what i am trying is i just wnated to detect the framing
> bytes .. in the omniber... rest of the things i will take care once
> the logic doesnot show any pattern loss in the omniber.
> 
> i am taking the sonet frames form the omniber and at this point of
> time i am not descrambling (in deframer) or scrambling (in
> framer).just taking what ever omniber is sending then detecting the
> framer bytes(a1 and a2 bytes) and then allowing the rest of the
> payload and other overhead.  on detecting the framing bytes i am
> sending rest of data through fifo and then passign the data to the
> framer part. in the framer side just inserting the a1 and a2 bytes and
> other overhead bytes and just allowing the payload that i got form
> deframer. then sending it to optics card to omniber.
> 
> now my loopback (which i have done for just checking if data is
> processign wrt the clock) is working the second code which i have
> posted before but my sts3c deframer/framer logic is not working as i
> am usign the clock (derived form the optics card) somany places in the
> design is that creating any problem any clock related issues are
> there......
> 
> regards
> srik


If loopback works but your framer/deframer does not and the clock is the 
same in both cases, you have a logic problem that the omniber doesn't like.

If your loopback works without reclocking the data but the loopback 
doesn't work if you do reclock the data, you have a clock problem.

Isolation of the problem is key to debugging.

I'm concerned that your payload and the rest of the frame may be 
descrambled/scrambled incorrectly in the setup where the omniber has 
trouble detecting valid frames.  It's quite possible the omniber uses 
more than just the a1/a2 framing words at the correct repetition 
location to declare a valid frame.  It's that extra information that it 
can't correctly decode.

At least that's what I feel might be going on here.
Article: 123019
Subject: Re: Virtex-4 router failures when trying to mux multiple clocks (WARNING:Route:438)
From: Gabor <gabor@alacron.com>
Date: Tue, 14 Aug 2007 06:16:16 -0700
Links: << >>  << T >>  << A >> 
On Aug 13, 6:55 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote:
> I have a design where I use a 40MHz input clock to create a 40MHz,
> 80MHz, and two variable-frequency output clocks.  The variable-
> frequencies are 80/120, 40/60, 20/30, 10/15, 5/7.5, and 2.5/3.75
> respectively.  The major design utilization is as follows: 9
> BUFGMUX_VIRTEX4, 2 BUFG, 1 DCM_ADV, 3 PMCD.
>

This is confusing.  Are you saying the two clocks are:

Clock 1: 80 40 20 10 5 2.5

Clock 2: 120 60 30 15 7.5 3.75

> When attempting to integrate this clock generation block into our
> existing design, I receive a warning #438 during routing.  I found
> Xilinx answer record 23873, which seems to be a problem similar to
> what I'm seeing.  I'm just somewhat wary of the proposed solution,
> which is using 4 BUFGMUX's as 2:1 clock muxes and then a final 4:1
> output mux based on regular logic.  Has anyone else had this problem,
> and, if so, was this proposed fix used to solve it?

What are the clocks driving?  If they are used inside the FPGA
you should use BUFGMUX as the final driver.  Generally the frequency
generation portion can be based on LUTs and FFs.  In fact in the
Virtex 2 parts, the BUFGMUX didn't like to have global clocks on
its inputs.

In any case it looks like you may have issues if you need the
output clock phase to be coincident with your input clock as any
method of muxing will create relatively large delays.

HTH,
Gabor
Article: 123020
Subject: Re: Virtex-4 router failures when trying to mux multiple clocks (WARNING:Route:438)
From: "bwilson79@gmail.com" <bwilson79@gmail.com>
Date: Tue, 14 Aug 2007 17:07:54 -0000
Links: << >>  << T >>  << A >> 
On Aug 14, 6:16 am, Gabor <ga...@alacron.com> wrote:
> On Aug 13, 6:55 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote:
>
> > I have a design where I use a 40MHz input clock to create a 40MHz,
> > 80MHz, and two variable-frequency output clocks.  The variable-
> > frequencies are 80/120, 40/60, 20/30, 10/15, 5/7.5, and 2.5/3.75
> > respectively.  The major design utilization is as follows: 9
> > BUFGMUX_VIRTEX4, 2 BUFG, 1 DCM_ADV, 3 PMCD.
>
> This is confusing.  Are you saying the two clocks are:
>
> Clock 1: 80 40 20 10 5 2.5
>
> Clock 2: 120 60 30 15 7.5 3.75
>
> > When attempting to integrate this clock generation block into our
> > existing design, I receive a warning #438 during routing.  I found
> > Xilinx answer record 23873, which seems to be a problem similar to
> > what I'm seeing.  I'm just somewhat wary of the proposed solution,
> > which is using 4 BUFGMUX's as 2:1 clock muxes and then a final 4:1
> > output mux based on regular logic.  Has anyone else had this problem,
> > and, if so, was this proposed fix used to solve it?
>
> What are the clocks driving?  If they are used inside the FPGA
> you should use BUFGMUX as the final driver.  Generally the frequency
> generation portion can be based on LUTs and FFs.  In fact in the
> Virtex 2 parts, the BUFGMUX didn't like to have global clocks on
> its inputs.
>
> In any case it looks like you may have issues if you need the
> output clock phase to be coincident with your input clock as any
> method of muxing will create relatively large delays.
>
> HTH,
> Gabor

Sorry it was confusing, but yes, you are correct about the two varying
clock frequencies.  The clocks are driving logic inside the FPGA
fabric.  The logic does not make any assumptions about the phase of
the outputs clocks w.r.t. their inputs.  Are you saying I should be
able to get away with using standard muxes up front and only use
BUFGMUX's at the final stage?  The logic is only interested in the
rising edges of these clocks so I suppose a little duty cycle
distortion wouldn't hurt us.
Article: 123021
Subject: Xilinx Spartan FPGA : Strange Errors
From: moogyd@yahoo.co.uk
Date: Tue, 14 Aug 2007 10:24:17 -0700
Links: << >>  << T >>  << A >> 
Hi,

I wonder if anyone has seen something like this.

I have an FPGA design targeted at an Spartan xc3s1500 and using
ISE8.2.

We are using a spartan evaluation board with some 7 segment LED's.

If I make minor changes to the pinout, sometimes the FPGA stops
functioning completely. What is interesting, is that the 7 segment
LED's are not driven. The VHDL code for this is :

  p_seven_seg : process(clk system_reset_n,)

  begin
    if(system_reset_n = '0')then
      seven_seg_1 <= "1111111";
    elsif(clk = '1'and clkt'event) then
      case (conv_integer(p1)) is
        when 0      =>
          seven_seg_1 <= not("0111111");
        when others =>
          seven_seg_1 <= "1111111";
      end case;
Article: 123022
Subject: Xilinx Spartan FPGA : Strange Errors
From: moogyd@yahoo.co.uk
Date: Tue, 14 Aug 2007 10:26:43 -0700
Links: << >>  << T >>  << A >> 
Hi,

I wonder if anyone has seen something like this.

I have an FPGA design targeted at an Spartan xc3s1500 and using
ISE8.2.

We are using a spartan evaluation board with some 7 segment LED's.

If I make minor changes to the pinout, sometimes the FPGA stops
functioning completely. What is interesting, is that the 7 segment
LED's are not driven. The VHDL code for this is :

  p_seven_seg : process(clk system_reset_n,)

  begin
    if(system_reset_n = '0')then
      seven_seg_1 <= "1111111";
    elsif(clk = '1'and clkt'event) then
      case (conv_integer(p1)) is
        when 0      =>
          seven_seg_1 <= not("0111111");
        when others =>
          seven_seg_1 <= "1111111";
      end case;
end process;

There are no tri-state buffers, seven_seg_1 is an O/P port therefore
should *always* be driven.

This failure mode implies (to me) that FPGA configuration is failing.

Has anyone seen anything like this, can they suggest any debug
strategies?

Thanks,

Steven
Article: 123023
Subject: Re: Virtex-4 router failures when trying to mux multiple clocks (WARNING:Route:438)
From: Gabor <gabor@alacron.com>
Date: Tue, 14 Aug 2007 10:37:36 -0700
Links: << >>  << T >>  << A >> 
On Aug 14, 1:07 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote:
> On Aug 14, 6:16 am, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Aug 13, 6:55 pm, "bwilso...@gmail.com" <bwilso...@gmail.com> wrote:
>
> > > I have a design where I use a 40MHz input clock to create a 40MHz,
> > > 80MHz, and two variable-frequency output clocks.  The variable-
> > > frequencies are 80/120, 40/60, 20/30, 10/15, 5/7.5, and 2.5/3.75
> > > respectively.  The major design utilization is as follows: 9
> > > BUFGMUX_VIRTEX4, 2 BUFG, 1 DCM_ADV, 3 PMCD.
>
> > This is confusing.  Are you saying the two clocks are:
>
> > Clock 1: 80 40 20 10 5 2.5
>
> > Clock 2: 120 60 30 15 7.5 3.75
>
> > > When attempting to integrate this clock generation block into our
> > > existing design, I receive a warning #438 during routing.  I found
> > > Xilinx answer record 23873, which seems to be a problem similar to
> > > what I'm seeing.  I'm just somewhat wary of the proposed solution,
> > > which is using 4 BUFGMUX's as 2:1 clock muxes and then a final 4:1
> > > output mux based on regular logic.  Has anyone else had this problem,
> > > and, if so, was this proposed fix used to solve it?
>
> > What are the clocks driving?  If they are used inside the FPGA
> > you should use BUFGMUX as the final driver.  Generally the frequency
> > generation portion can be based on LUTs and FFs.  In fact in the
> > Virtex 2 parts, the BUFGMUX didn't like to have global clocks on
> > its inputs.
>
> > In any case it looks like you may have issues if you need the
> > output clock phase to be coincident with your input clock as any
> > method of muxing will create relatively large delays.
>
> > HTH,
> > Gabor
>
> Sorry it was confusing, but yes, you are correct about the two varying
> clock frequencies.  The clocks are driving logic inside the FPGA
> fabric.  The logic does not make any assumptions about the phase of
> the outputs clocks w.r.t. their inputs.  Are you saying I should be
> able to get away with using standard muxes up front and only use
> BUFGMUX's at the final stage?  The logic is only interested in the
> rising edges of these clocks so I suppose a little duty cycle
> distortion wouldn't hurt us.


If you're only interested in generating a frequency but not worried
about phase, you should use standard muxes and just use the BUFGMUX
as a final buffer.  Since your clock output frequencies are related,
I'm guessing you don't need the glitchless switching properties of
the BUFGMUX you'd need when switching unrelated asynchronous clocks.

If your variable clocks are all divided down from a single input
frequency (e.g. 240 MHz), it's best to place a register on the
output of the mux.  This can avoid glitches shorter than the minimum
clock period and also help to square up the duty cycle if you need it.
The output of the flip-flop can then directly drive the BUFGMUX.

I'm not too familiar with V4 routing, but in the V2 you needed to
generate your clock near the edge of the chip to reduce routing
delays into the BUFGMUX.  If you don't put a LOC constraint on
the mux output flip-flop (or LUT) you can have significant timing
variation from run to run after place&route.  Also important is
putting a period constraint on the output clock, as I've found that
the tools don't always pick the maximum frequency when attempting
to determine the period from the input clock constraints.

Good Luck,
Gabor
Article: 123024
Subject: Re: xst fails...
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 14 Aug 2007 18:40:14 +0100
Links: << >>  << T >>  << A >> 
On Tue, 14 Aug 2007 12:32:30 +0200, Matthias Alles
<REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de> wrote:

>There is nothing of interest in the output:
>
>INFO:Xst:2261 - The FF/Latch <configure.parallelism_2> in Unit <hws> is
>equivalent to the following 155 FFs/Latches, which will be removed :


Anything in the synthesis report file (.syr)?

Since the error appears to be near register removal, it  may be worth
turning OFF "equivalent register removal" and seeing if the error
remains.

- Brian


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