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
On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote: > Hi, > > At a client's site I have some legacy VHDL code that is being > synthesised with Xilinx XST 13.1 with Virtex 6 as a target. > > This code has some clock domain crossing circuits that use two flip > flops cascaded in the destination clock domain (it's the usual > synchroniser that you've all seen before). > > This code worked fine in whatever version of XST it was originally > written for, but with 13.1 I find that these flip flops are being > replaced by SRL32 primitives, the default inference rule being that > whenever XST sees two or more flip flops (without a reset and with the > same control inputs) in series, it replaces them with an SRL. > > Obviously, the XST team thought that this was an appropriate thing to > do, but anyone with a modicum of experience should know better. > > > Question: just how bad are the SRL for this application? Have they even > been characterised? > > > BTW, there are many possible fixes: > > - Put an attribute (SHREG_something_or_other) on each and every > synchroniser to disable SRL inference. > > - Disable SRL inference globally (not good). > > - Change the XST setting (SHREG_something_else) to 3 so that chains of 2 > flip flops are left alone. > > - Add a reset (or other control signal that will stop SRL inference) to > each and every synchroniser in the design. > > - Wait for XST to be fixed (but don't hold your breath). The relevant attributes are: SHREG_EXTRACT (yes/no) applies to signals or entities (in HDL source) or globally (as an XST option). SHREG_MIN_SIZE (default of 2) global XST option. This defines the smallest number of flip flops in a chain that will be converted to SRL. (I consider the default SHREG_MIN_SIZE value of 2 to be low for a target that has four flip flops for every SRL, but perhaps it has more to do with the routing than the logic.) The fix I applied to the client's design was to put the SHREG_EXTRACT attribute on every synchroniser flip flop. This required more code changes than I would have liked, because many of the flip flops were inferred from variables, and XST doesn't allow the attribute to be applied to variables, only signals. The problem was discovered by a co-worker (hi Adrian!) during a review of the tool report files. The long term fix (for us) involves two steps: 1. Modify the in-house coding standard to require that those attributes be used on synchronising flip flops in the HDL source. 2. Add an automated check of the extracted gate-level netlist that will be run at the end of our (fully scripted) build process which will identify and warn of SRLs being used inappropriately. Regards, AllanArticle: 151326
Tobias Baumann wrote: > So I need some basical information about where I have to find mistakes > in my program and how I can solve them. And I need information about > where the limits are. Your code seems to use too much autovar (stack) memory at runtime. I don't know how you found the value of 496. Maybe your program crashes for higher values? Simple C runtime doesn't do stack checking and you can run out of memory without warning. You should avoid this. A good start would be to move the big buffer outside of the function (possibly with a "static" keyword in front). This will make it a link time allocation in BSS section, and the linker will complain if there's not enough memory available instead of just crash. Also, you can consult the linker map file to see how much bigger your buffer could be. When your project advances and you really need dynamic buffer allocation, you can use a real memory allocator for the bigger stuff. It lets you to handle more memory while the stack requirements remain small. It will also tell you when there is not enough memory and your code can handle that gracefully. You may find more advice from embedded system programmers. The constraints are not always the same as on a desktop system, where resouces are almost infinite. Best regards, MarcArticle: 151327
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: > On Mar 19, 6:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >>> On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote: >> >> (snip) >> >>>> It was at FPL1999 that someone presented this as a sidenote in a >>>> presentation about some >>>> other topic. They said they were able to damage Altera FPGAs by >>>> instantiating ring counters. >> >> (snip) >> >>> What you remember as a ring counter was probably a ring oscillator >>> that was used to get a high frequency clock to drive the rest of the >>> FPGA logic with a high toggle rate. Without system level >>> considerations and monitoring the power requirements could easily push >>> the device into a thermal region that would damage the device. The >>> HDL and bitstream itself is perfectly valid, it is the thermal >>> management that is to blame for the destruction. The failure points >>> would likely be wide spread through the device. >> >> The designs that I am interested in have many signals changing >> on average every other clock cycle, and clocked as fast as I can >> get the design to run. I have wondered when that will cause thermal >> problems, such as requiring a heat sink. >> >>> This failure mode isn't the same as a badly constructed bitstream >>> violating DRC rules and creating device damage that would be difficult >>> to detect as it may only exist at a few points within the device. >> >> Well, a small ring oscillator would cause local heating, which >> may be enough to damage a small portion of the device. >> >>> Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC >>> in the 7 Series families) have the ability to shutdown the device if >>> the junction temperature exceeds user defined values. This can be >>> used to prevent this type of thermal damage, but it would not be able >>> to prevent localized damage due to bad bitstreams. >> >> That should work for heating over the whole array, but maybe not >> good enough for a localized ring oscillator. >> >> Though shouldn't DRC be able to detect ring oscillators? >> Is it that hard to do? >> >> -- glen > > It sounds like you have a pretty aggressive design and if there is a > lot of logic in the design than it would be possible to exceed Tj > without a heat sink. The Xilinx XPE (estimator) and XPA (analyzer) > can help you out with determining the expectated power and thermal > requirements. See http://www.xilinx.com/power for more details. > > I wouldn't be worried about a ring oscillator creating any significant > localized heating in an FPGA to the point that it would damage the > device. Ring oscillator circuits are used extensively in the device > testing and I've never heard of an RMA linked to anything that even > remotely resembled damage due to localized Tj extremes. > > If you do have ring oscillators in your design you will get some > warnings in the timing analysis, but otherwise they are permitted as > there isn't anything wrong with a ring oscillator. > > Ed McGettigan > -- > Xilinx Inc. My own testing has shown this. I've been pretty abusive to one particular S3E with ring oscillators, and it's ticking along just fine.Article: 151328
On Mar 23, 7:05=A0am, Marc Jet <jetm...@hotmail.com> wrote: > Tobias Baumann wrote: > > So I need some basical information about where I have to find mistakes > > in my program and how I can solve them. And I need information about > > where the limits are. > > Your code seems to use too much autovar (stack) memory at runtime. =A0I > don't know how you found the value of 496. =A0Maybe your program crashes > for higher values? > > Simple C runtime doesn't do stack checking and you can run out of > memory without warning. =A0You should avoid this. > > A good start would be to move the big buffer outside of the function > (possibly with a "static" keyword in front). =A0This will make it a link > time allocation in BSS section, and the linker will complain if > there's not enough memory available instead of just crash. =A0Also, you > can consult the linker map file to see how much bigger your buffer > could be. > > When your project advances and you really need dynamic buffer > allocation, you can use a real memory allocator for the bigger stuff. > It lets you to handle more memory while the stack requirements remain > small. =A0It will also tell you when there is not enough memory and your > code can handle that gracefully. > > You may find more advice from embedded system programmers. =A0The > constraints are not always the same as on a desktop system, where > resouces are almost infinite. > > Best regards, > Marc Like Marc said, definitely avoid those stack allocations. In this embedded environment with little runtime support, it can be hard to diagnose problems like these (especially as the program gets more complicated). Thankfully, as an embedded designer targeting a specific platform for a specific application, you can pretty much have free reign over the entire address map. It's perfectly legal to declare a pointer to a known region of unused memory (known and unused in the sense that none of the peripherals are mapped to that address and the code size of the elf won't clash with it). Something like: Xuint8 *buffer =3D 0x04000000; // just the starting address of the buffer Then you can dereference it like an array. I've used this technique, and it's easy, but I'm not 100% sure it's the best/safest/etc. Regards, MBArticle: 151329
jay <jay@jayt.org> wrote: (snip, I wrote) >>> Well, a small ring oscillator would cause local heating, which >>> may be enough to damage a small portion of the device. (someone else wrote) >> I wouldn't be worried about a ring oscillator creating any significant >> localized heating in an FPGA to the point that it would damage the >> device. Ring oscillator circuits are used extensively in the device >> testing and I've never heard of an RMA linked to anything that even >> remotely resembled damage due to localized Tj extremes. (snip) > My own testing has shown this. I've been pretty abusive to one particular > S3E with ring oscillators, and it's ticking along just fine. It seems to me that the smallest is one inverter. If you do that with a single CMOS inverter, I believe it just sits at the switch point dissipating power. (In the CD4000 days, we were cautioned not to leave inputs floating, as they can float to the switch point.) In an FPGA, the routing delay might be long enough to allow oscillation. -- glenArticle: 151330
On Wednesday, March 23, 2011 2:53:54 PM UTC-4, glen herrmannsfeldt wrote: > jay <j...@jayt.org> wrote: > > (snip, I wrote) > >>> Well, a small ring oscillator would cause local heating, which > >>> may be enough to damage a small portion of the device. > > (someone else wrote) > >> I wouldn't be worried about a ring oscillator creating any significant > >> localized heating in an FPGA to the point that it would damage the > >> device. Ring oscillator circuits are used extensively in the device > >> testing and I've never heard of an RMA linked to anything that even > >> remotely resembled damage due to localized Tj extremes. > > (snip) > > My own testing has shown this. I've been pretty abusive to one particular > > S3E with ring oscillators, and it's ticking along just fine. > > It seems to me that the smallest is one inverter. If you do that > with a single CMOS inverter, I believe it just sits at the switch > point dissipating power. (In the CD4000 days, we were cautioned > not to leave inputs floating, as they can float to the switch > point.) In an FPGA, the routing delay might be long enough to > allow oscillation. > > -- glen In an FPGA you can't get close to the simplicity of a single inverter. Even if you consider a LUT programmed to invert its input, you still have some additional buffering in the feedback path. So I wouldn't expect to be able to reproduce the linear feedback behavior of an unbuffered CMOS inverter. It might be too fast to clock anything useful in the FPGA but a single looped back "inverter" would probably still oscillate. -- GaborArticle: 151331
Gabor <gabor@alacron.com> wrote: (snip, I wrote) >> It seems to me that the smallest is one inverter. If you do that >> with a single CMOS inverter, I believe it just sits at the switch >> point dissipating power. (In the CD4000 days, we were cautioned >> not to leave inputs floating, as they can float to the switch >> point.) In an FPGA, the routing delay might be long enough to >> allow oscillation. > In an FPGA you can't get close to the simplicity of > a single inverter. Even if you consider a LUT programmed > to invert its input, you still have some additional > buffering in the feedback path. So I wouldn't expect > to be able to reproduce the linear feedback behavior > of an unbuffered CMOS inverter. It might be too fast > to clock anything useful in the FPGA but a single > looped back "inverter" would probably still oscillate. Yes, that is what I thought. I should have been a little stronger in my wording, but, not having actually tried it, "probably" seemed safe to me. -- glenArticle: 151332
Currently, when trying to download the bitstream to this SP605 board,
I get the following error:
FPGA configuration encountered errors.
Program FPGA failed
ERROR: Connection to Board Failed
Failed to Open JTAG Cable
Check the following:
1. Cable is Connected to the Board and the Board is Powered-ON
2. On Cable Lock Error, Close the other application using the
cable or Remove Cable Locks using "xclean_cablelock" command
3. You have specified the correct JTAG settings for cable type and
port.
So basically the SDK is not seeing the board. It's odd, because in my
"Devices and Printers" window it does appear as "Silicon Labs CP210x
USB to UART Bridge (COM3)". Currently it seems that my computer thinks
this connection is a wired mouse. (That's the icon it's showing.)
Earlier it was using the generic "unidentified device" icon, but it
has been unplugged and reattached a couple times since then.
I'm using SDK version 12.3 on a Windows 7 x64 version 6.1.7600 Build
7600.
I tried following the instructions in the included "Getting Started"
pamphlet to ensure the board was hooked up correctly, and basically
when I got to the part where the Xilinx logo is supposed to appear
onscreen I instead get large horizontal green and purple strips,
overlaid with vertical lines in different shades of grey and black. I
get the impression that either the board as a whole, or perhaps just
the adapter piece for the monitor cable is broken.
I am getting a solid green and a solid red "Error" LED in the upper-
right corner of the board. Not sure if these mean anything. Any ideas
as to how I can get this connected and running projects?
Article: 151333On Mar 23, 4:16=A0pm, DaMunky89 <shwankymu...@gmail.com> wrote: > Currently, when trying to download the bitstream to this SP605 board, > I get the following error: > > FPGA configuration encountered errors. > Program FPGA failed > =A0 =A0ERROR: Connection to Board Failed > Failed to Open JTAG Cable > =A0 =A0 Check the following: > =A0 =A0 1. Cable is Connected to the Board and the Board is Powered-ON > =A0 =A0 2. On Cable Lock Error, Close the other application using the > cable or Remove Cable Locks using "xclean_cablelock" command > =A0 =A0 3. You have specified the correct JTAG settings for cable type an= d > port. > > So basically the SDK is not seeing the board. It's odd, because in my > "Devices and Printers" window it does appear as "Silicon Labs CP210x > USB to UART Bridge (COM3)". Currently it seems that my computer thinks > this connection is a wired mouse. (That's the icon it's showing.) > Earlier it was using the generic "unidentified device" icon, but it > has been unplugged and reattached a couple times since then. > > I'm using SDK version 12.3 on a Windows 7 x64 version 6.1.7600 Build > 7600. > I tried following the instructions in the included "Getting Started" > pamphlet to ensure the board was hooked up correctly, and basically > when I got to the part where the Xilinx logo is supposed to appear > onscreen I instead get large horizontal green and purple strips, > overlaid with vertical lines in different shades of grey and black. I > get the impression that either the board as a whole, or perhaps just > the adapter piece for the monitor cable is broken. > > I am getting a solid green and a solid red "Error" LED in the upper- > right corner of the board. Not sure if these mean anything. Any ideas > as to how I can get this connected and running projects? The SP605 has two mini USB ports on it. One of them is a USB to serial port, and that appears to be what you have connected to if you see the Silicon Labs part. The other one is the USB to JTAG port. Try connecting to that one, and see if the "Failed to Open JTAG Cable" error message goes away. Regards, John McCaskill www.FasterTechnology.comArticle: 151334
>On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote: [elided] > >The long term fix (for us) involves two steps: > >1. Modify the in-house coding standard to require that those attributes >be used on synchronising flip flops in the HDL source. > >2. Add an automated check of the extracted gate-level netlist that will >be run at the end of our (fully scripted) build process which will >identify and warn of SRLs being used inappropriately. > > >Regards, >Allan As I am concerned that this is happening to our designs, I had a trawl on the Xilinx web-site, and found the following: http://www.xilinx.com/support/answers/35967.htm Summary: While SHREG_EXTRACT="no" stops XST, it doesn't stop MAP doing it! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151335
Oh hell yaArticle: 151336
I no langer have the piece, but I used to keep a X. Chip that had holes blown through the lid when it got reloaded from a bsd ROM. My understanding is that most chips now verify a checksum on loading. -- mac the naïfArticle: 151337
On Thursday, March 24, 2011 7:27:14 AM UTC-4, RCIngham wrote: > >On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote: > [elided] > > > >The long term fix (for us) involves two steps: > > > >1. Modify the in-house coding standard to require that those attributes > >be used on synchronising flip flops in the HDL source. > > > >2. Add an automated check of the extracted gate-level netlist that will > >be run at the end of our (fully scripted) build process which will > >identify and warn of SRLs being used inappropriately. > > > > > >Regards, > >Allan > > As I am concerned that this is happening to our designs, I had a trawl on > the Xilinx web-site, and found the following: > http://www.xilinx.com/support/answers/35967.htm > > Summary: While SHREG_EXTRACT="no" stops XST, it doesn't stop MAP doing it! > > > > --------------------------------------- > Posted through http://www.FPGARelated.com My code generally has a reset term for everything whether it needs one or not. I only leave out the reset if I explicitly want to generate SRL-based shift registers. Neither XST nor Map can use an SRL when the register needs a reset. -- GaborArticle: 151338
"Joel Williams" <nospamwhydontyoublogaboutit@nospamgmail.com> a écrit : > > It all depends on whether this is a PCB and circuit design exercise or an FPGA development exercise. Both. > Trying to get high speed designs working on two layer boards can be a complete waste of time when things just plain > don't work and you have to start again. A four layer board is actually considerably easier to lay out for complicated > designs and if you're not in much of a hurry, some of the hobbyist orientated manufacturing services are incredibly > cheap. For example, http://dorkbotpdx.org/wiki/pcb_order charge $10 per square inch with four layers, and that's for > three boards. I'd seriously consider doing this even if I was using the PQ208 package. $10 - 4 layers ! Why did not you tell me this before ;-)) I thought prices were in the hundreds. > If you're interested in soldering BGA packages at home, have a look at this project: > http://danstrother.com/2011/01/16/spartan-6-bga-test-board/ . It hasn't yet been built, but if the reflow oven method > works it would be very easy to adapt this (open source) design for your uses, either by adding a simple VGA output or > an HDMI buffer. Great link, this project is very interesting with many things to learn. I did not realize Spartan-6 had such powerful features (like a mini Virtex...) for the same price I would have paid for a Spartan-3E (6 input LUTs, hard DRAM controller, etc). After some research it seems BGA soldering is not as out of reach as I thought. The hot plate method is very simple and seems to give very good results. There are also refusion ovens on eBay under $300. At the end, I changed my mind and decided to go "BGA / 4 layers / Spartan-6" Many thanks to all who gave their usefull advice.Article: 151339
"Gabor" <gabor@alacron.com> a écrit : > On Monday, March 21, 2011 7:08:32 PM UTC-4, PovTruffe wrote: > You should be worried about pin inductance in the PQ208. In > my experience these packages are not suitable for high-speed I/O. OK > The problem with starting with a flawed design just > to "finish this year" is that your board won't do what > you wanted, and then you could be more discouraged. It seems I would better submit the project here before doing anything... > If you really want to use the large PQ package, you need to > resign yourself to using low slew-rate I/O because of the > horrendous ground-bounce in those packages (even when > using additional "virtual ground" pins). I did not know the PQ packages were that bad. > Single data-rate Mobile SDRAM may be your best choice > because it can run at low clock rates and use only > LVCMOS levels. You won't find a pre-made MIG core > for it, though as you might for DDR memory types. > Writing your own Mobile DDR (also called lpDDR) > controller would be a good exercise as well. I > have used single data rate memories for a number > of video products including UXGA resolution video > capture. You can realize any data rate you need > by making the memory wide enough. It doesn't even > have to be a power of two width. The UXGA capture > board uses 48-bit wide memory which matches the > RGB 2-pixel-wide data stream. > > Video buffering is an easier design than a general > purpose memory controller for fully random access. > My controllers usually have a minimum transfer of > one burst to each of the banks in the memory. The > bank overlap allows me to "bury" the precharge and > activate time and keep the interface streaming at > almost 100% of the peak rate. > > Good luck on your projects. Thank you > -- GaborArticle: 151340
"rickman" <gnuarm@gmail.com> wrote in message news:c37781b2-2437-4dd1-a584-53b710133ba6@w7g2000pre.googlegroups.com... On Mar 14, 6:38 pm, "Abby Brown" <abbybr...@charter.net> wrote: > Hi, > > Does someone produce a cheaper and simpler substitute for > Altera's Cyclone III starter board? It needs to connect to a > laptop to download configuration and test cases and upload > results (ICT). A driver that connects to Windows .Net would be > ideal. > > Thanks, > Gary : I have to say I am pretty ignorant of .NET other than this was : Microsoft's response when Sun told them to stop tinkering with JAVA. : What would the driver accomplish and how would you use it? : Rick It obviates a logic simulator (Altera's free one is limited). Use the actual device instead. I can automate test cases with a C# program. I used to write logic simulators for a living and hate the damn things. GaryArticle: 151341
Hi, I want to measure the delay between two rising edges in modelsim simulation. There are commands in spice like tools where the .measure statements are used to measure the delays. But I am not able to find such method, where I would fire such command to print the delays into a text file through a tcl script. Looking forward to some positive suggestions, Thanks in advance, PratapArticle: 151342
Hi, I want to delay a signal precisely by taking out the signal from the FPGA so that it can be fed to another chip which can control the delay through that. I want to feed this delayed signal back to the FPGA by inputting that signal through another pin on the Xilinx Virtex II Pro board. I am using the EXT_CLK_P and EXT_CLK_N pins for inputting the desired signals. The signal to be delayed is fed to the pin EXT_CLK_P by installing SMA connectors at those points. I have also installed separate connectors at EXT_CLK_N, MGT_TXP and MGT_TXN. But I am not able to route the signals as I get the following error while mapping. Using target part "2vp30ff896-7". Mapping design into LUTs... Running directed packing... ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB component: BUF symbol "inp_for_TI_chip_OBUF" (Output Signal = inp_for_TI_chip) PAD symbol "inp_for_TI_chip" (Pad Signal = inp_for_TI_chip) Each of the following constraints specifies an illegal physical site for a component of type IOB: Symbol "inp_for_TI_chip" (LOC=A6) Please correct the constraints accordingly. The motivation behind using the SMA connectors for the connectivity is to have good signal shape of the input square wave signals, by which the delays can be precisely maintained. I have also tried connect the output from the FPGA pin for the external delay controller and also the input signal from the controller to the chip through other Non-SMA type pins in J5 or J6 connectors. But even doing that doesn't solve my purpose, as I don't get any thing signal reaching at those points. Surprisingly, only when I connect those signals intended to be fed to the external delay controller chip to the externally non-available pins MGT_CLK_P and MGT_CLK_N, I get all the signals toggling, but my purpose of routing the signals through the external chip is not solved. Can anybody help me understand, why this connection to MGT_CLK_P and MGT_CLK_N for the stuff to work and how those are hooked upto the system? How can I solve my purpose of taking the signals fed to EXT_CLK_P and EXT_CLK_N SMA connectors from the Virtex II Pro board and route it through another chip. Looking forward to some helpful suggestions, Thanks in advance, PratapArticle: 151343
On Mar 25, 8:00=A0pm, Pratap <pratap.i...@gmail.com> wrote: > Hi, > I want to measure the delay between two rising edges in modelsim > simulation. There are commands in spice like tools where the .measure > statements are used to measure the delays. But I am not able to find > such method, where I would fire such command to print the delays into > a text file through a tcl script. > Looking forward to some positive suggestions, > Thanks in advance, > Pratap Presuming that you know VHDL or Verilog, then write a handful of lines of code and write the file from the simulation itself. KJArticle: 151344
On Mar 25, 5:59=A0pm, Pratap <pratap.i...@gmail.com> wrote: > Hi, > I want to delay a signal precisely by taking out the signal from the > FPGA so that it can be fed to another chip which can control the delay > through that. I want to feed this delayed signal back to the FPGA by > inputting that signal through another pin on the Xilinx Virtex II Pro > board. I am using the EXT_CLK_P and EXT_CLK_N pins for inputting the > desired signals. The signal to be delayed is fed to the pin EXT_CLK_P > by installing SMA connectors at those points. I have also installed > separate connectors at EXT_CLK_N, MGT_TXP and MGT_TXN. But I am not > able to route the signals as I get the following error while mapping. > > Using target part "2vp30ff896-7". > Mapping design into LUTs... > Running directed packing... > ERROR:Pack:1107 - Unable to combine the following symbols into a > single IOB > =A0 =A0component: > =A0 =A0 =A0 =A0 BUF symbol "inp_for_TI_chip_OBUF" (Output Signal =3D > inp_for_TI_chip) > =A0 =A0 =A0 =A0 PAD symbol "inp_for_TI_chip" (Pad Signal =3D inp_for_TI_c= hip) > =A0 =A0Each of the following constraints specifies an illegal physical > site for a > =A0 =A0component of type IOB: > =A0 =A0 =A0 =A0 Symbol "inp_for_TI_chip" (LOC=3DA6) > =A0 =A0Please correct the constraints accordingly. > > The motivation behind using the SMA connectors for the connectivity is > to have good signal shape of the input square wave signals, by which > the delays can be precisely maintained. I have also tried connect the > output from the FPGA pin for the external delay controller and also > the input signal from the controller to the chip through other Non-SMA > type pins in J5 or J6 connectors. But even doing that doesn't solve my > purpose, as I don't get any thing signal reaching at those points. > Surprisingly, only when I connect those signals intended to be fed to > the external delay controller chip to the externally non-available > pins MGT_CLK_P and MGT_CLK_N, I get all the signals toggling, but my > purpose of routing the signals through the external chip is not > solved. > Can anybody help me understand, why this connection to MGT_CLK_P and > MGT_CLK_N for the stuff to work and how those are hooked upto the > system? How can I solve my purpose of taking the signals fed to > EXT_CLK_P and EXT_CLK_N SMA connectors from the Virtex II Pro board > and route it through another chip. > Looking forward to some helpful suggestions, > Thanks in advance, > Pratap The MGT TXP/TXN/RXP/RXN pins are dedicated pins that can only be used by the MGTs. In the Virtex-II Pro FPGA family the MGT reference clock pins were normal I/Os that had extra dedicated routing to the MGTs. Are you using a Xilinx board? If so which one is it? What are the IO location constraints that you are using for the output and input paths? Ed McGettigan -- Xilinx Inc.Article: 151345
On Mar 26, 7:26=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > On Mar 25, 8:00=A0pm, Pratap <pratap.i...@gmail.com> wrote: > > > Hi, > > I want to measure the delay between two rising edges in modelsim > > simulation. There are commands in spice like tools where the .measure > > statements are used to measure the delays. But I am not able to find > > such method, where I would fire such command to print the delays into > > a text file through a tcl script. > > Looking forward to some positive suggestions, > > Thanks in advance, > > Pratap > > Presuming that you know VHDL or Verilog, then write a handful of lines > of code and write the file from the simulation itself. > > KJ Can you please point me to such examples? I know VHDL...but haven't ever tried writing to a file.Article: 151346
On 3/26/2011 7:18 AM, Pratap wrote: > On Mar 26, 7:26 am, KJ<kkjenni...@sbcglobal.net> wrote: >> On Mar 25, 8:00 pm, Pratap<pratap.i...@gmail.com> wrote: >> >>> Hi, >>> I want to measure the delay between two rising edges in modelsim >>> simulation. There are commands in spice like tools where the .measure >>> statements are used to measure the delays. But I am not able to find >>> such method, where I would fire such command to print the delays into >>> a text file through a tcl script. >>> Looking forward to some positive suggestions, >>> Thanks in advance, >>> Pratap >> >> Presuming that you know VHDL or Verilog, then write a handful of lines >> of code and write the file from the simulation itself. >> >> KJ > > Can you please point me to such examples? I know VHDL...but haven't > ever tried writing to a file. It's just one of numerous examples that Google returns for the search string text io vhdl: http://eesun.free.fr/DOC/vhdlref/refguide/language_overview/test_benches/reading_and_writing_files_with_text_i_o.htm -- AlexanderArticle: 151347
On Fri, 25 Mar 2011 17:00:34 -0700 (PDT), Pratap wrote:
>I want to measure the delay between two rising
> edges in modelsim simulation.
It really depends what you mean by "measure".
In the waveform viewer you can add a second cursor,
put your two cursors on the edges of interest and
read off the time difference in the cursor area of
the wave viewer.
In VHDL or Verilog you can, as KJ said, easily write
a piece of testbench code that waits for the first
edge, takes a copy of the current time in a variable,
waits for the second edge and then reports the
difference. In VHDL it would look something
like this:
MeasureTime: process
variable rise_A_time: time;
variable difference : time;
begin
wait until rising_edge(sigA);
rise_A_time := now;
wait until rising_edge(sigB);
difference := now - rise_A_time;
report "A-to-B time = " & time'image(difference);
wait;
end process;
If you remove the final "wait" statement, you will
get repeated reports; with the "wait" you get only
the first one.
Similarly in Verilog:
initial begin : MeasureTime
real rise_A_time;
real difference;
@(posedge sig_A) rise_A_time = $realtime;
@(posedge sig_B) difference = $realtime - rise_A_time;
$display("At time %t: A-to-B time = %t",
$realtime, difference);
end
and replace the "initial" with "always" if you want
the measurement to repeat. Learn about the $timeformat
system function in Verilog to get pretty time displays.
You could also do it in Tcl, in a simulator script,
using signal breakpoints to trigger some Tcl code
on the edges of the two signals. This, of course,
will be simulator-specific.
I guess you can see that writing it in Verilog or
VHDL code provides many opportunities for doing
much cleverer measurements, such as average or
cumulative values, jitter measurements, ratio
measurements... it's limited only by your
imagination.
--
Jonathan Bromley
Article: 151348> The MGT TXP/TXN/RXP/RXN pins are dedicated pins that can only be used > by the MGTs. =A0In the Virtex-II Pro FPGA family the MGT reference clock > pins were normal I/Os that had extra dedicated routing to the MGTs. > > Are you using a Xilinx board? =A0If so which one is it? > > What are the IO location constraints that you are using for the output > and input paths? > > Ed McGettigan > -- > Xilinx Inc. Hello, I am using the Virtex II Pro development board for my project. I am pasting all the IO constraints written to the ucf file. The signals to take out and then feed in are "inp_for_TI_chip" and "op_from_TI_chip" respectively. NET "reset_in" LOC =3D "AH1" | IOSTANDARD =3D LVCMOS25; #LEFT P/B NET "clk_in" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25; #EXTERNAL_CLOCK_P NET "samp_clk" LOC =3D "F15" | IOSTANDARD =3D LVCMOS25; #EXTERNAL_CLOCK_N NET "op_from_TI_chip" LOC =3D "A6" | IOSTANDARD =3D LVCMOS25; #MGT_TXP NET "inp_for_TI_chip" LOC =3D "A7" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST | DRIVE =3D 8 ; #MGT_TXN NET "ti_delay_chip_cntl" LOC =3D "R9" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST | DRIVE =3D 8 ; #J5-11 NET "dir_fine_delay" LOC =3D "P1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAS= T | DRIVE =3D 8 ; #J5-15 NET "board_in1" LOC =3D "AB1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST | DRIVE =3D 8 ; #J6-27 NET "board_in2" LOC =3D "W8" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST | DRIVE =3D 8 ; #J6-35 NET "cleaned_clk1" LOC =3D "R3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST = | DRIVE =3D 8 ; #J5-31 NET "cleaned_clk2" LOC =3D "U3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST = | DRIVE =3D 8 ; #J5-39 NET "status(3)" LOC =3D "AC4" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | DRIVE =3D 12 ; NET "status(2)" LOC =3D "AC3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | DRIVE =3D 12 ; NET "status(1)" LOC =3D "AA6" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | DRIVE =3D 12 ; NET "status(0)" LOC =3D "AA5" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | DRIVE =3D 12 ; Thanks, PratapArticle: 151349
On Mar 26, 7:53=A0am, Pratap <pratap.i...@gmail.com> wrote: > > The MGT TXP/TXN/RXP/RXN pins are dedicated pins that can only be used > > by the MGTs. =A0In the Virtex-II Pro FPGA family the MGT reference cloc= k > > pins were normal I/Os that had extra dedicated routing to the MGTs. > > > Are you using a Xilinx board? =A0If so which one is it? > > > What are the IO location constraints that you are using for the output > > and input paths? > > > Ed McGettigan > > -- > > Xilinx Inc. > > Hello, > I am using the Virtex II Pro development board for my project. > I am pasting all the IO constraints written to the ucf file. > The signals to take out and then feed in are "inp_for_TI_chip" and > "op_from_TI_chip" respectively. > > NET "reset_in" LOC =3D "AH1" | IOSTANDARD =3D LVCMOS25; > #LEFT P/B > > NET "clk_in" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25; > #EXTERNAL_CLOCK_P > > NET "samp_clk" LOC =3D "F15" | IOSTANDARD =3D LVCMOS25; > #EXTERNAL_CLOCK_N > > NET "op_from_TI_chip" =A0LOC =3D "A6" | IOSTANDARD =3D LVCMOS25; > #MGT_TXP > > NET "inp_for_TI_chip" =A0LOC =3D "A7" | IOSTANDARD =3D LVCMOS25 | SLEW = =3D > FAST | DRIVE =3D 8 ; > #MGT_TXN > > NET "ti_delay_chip_cntl" =A0LOC =3D "R9" | IOSTANDARD =3D LVCMOS25 | SLEW= =3D > FAST | DRIVE =3D 8 ; > #J5-11 > > NET "dir_fine_delay" =A0LOC =3D "P1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D= FAST > | DRIVE =3D 8 ; > #J5-15 > > NET "board_in1" =A0LOC =3D "AB1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAS= T | > DRIVE =3D 8 ; > #J6-27 > > NET "board_in2" =A0LOC =3D "W8" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST= | > DRIVE =3D 8 ; > #J6-35 > > NET "cleaned_clk1" =A0LOC =3D "R3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D F= AST | > DRIVE =3D 8 ; > #J5-31 > > NET "cleaned_clk2" =A0LOC =3D "U3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D F= AST | > DRIVE =3D 8 ; > #J5-39 > > NET "status(3)" LOC =3D "AC4" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | > DRIVE =3D 12 ; > NET "status(2)" LOC =3D "AC3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | > DRIVE =3D 12 ; > NET "status(1)" LOC =3D "AA6" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | > DRIVE =3D 12 ; > NET "status(0)" LOC =3D "AA5" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW | > DRIVE =3D 12 ; > > Thanks, > Pratap > I am using the Virtex II Pro development board for my project. This is about as useful as saying that your computer has an Intel ATX motherboard. Who made the board, and what is the model number? Ed McGettigan -- Xilinx Inc.
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