Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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
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 srikArticle: 123002
http://forums.xilinx.com/ are open if someone didnt notice yet AnttiArticle: 123003
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 urbanArticle: 123004
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
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 AnttiArticle: 123006
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
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 rickArticle: 123008
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, MatthiasArticle: 123009
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, JonArticle: 123010
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? JonArticle: 123011
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 rickArticle: 123012
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, GerhardArticle: 123013
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
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
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: 123016Hi 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, TorstenArticle: 123017
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 SulimmaArticle: 123018
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
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, GaborArticle: 123020
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
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
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: 123023On 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, GaborArticle: 123024
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:
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