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 15 jun, 16:10, "MM" <m...@yahoo.com> wrote: > "Pablo" <pbantu...@gmail.com> wrote in message > > news:1181903383.310304.114860@q75g2000hsh.googlegroups.com... > > > > > What about the phase difference?. I suppose that there is a little > > skew resolve by the feedback, but it seems that internal feedback > > clock is the same of the proccesor?. > > Exactly, the purpose of the feedback must be to compensate for the skew, > however it is probably small enough on this particular board that it can be > ignored. > > /Mikhail I have probed this method on a Spartan 3E starter kit ( another board used for testing) and works fine. At the moment the custom board doesn't work, but it is possible that exists this few skew. Is it a method to apply a phase to a plb_ddr core? PabloArticle: 120751
"Chris@Austin" <ggkuo@yahoo.com> wrote: >Hi, > >I'm new to FPGA world and currently working on an emulation board with 2 >Virtex-5. I think to forward clock from chip A to chip B. Is that >possible to make these 2 clocks synchronous ? What kind of steps, >components and constraints need to be done to ensure the synchronous >between these 2 FPGAs. The clock frequency is about 50-100 MHz range. > >My current scheme is as following, but doesn't work properly. Any help >is appreciated. > >On FPGA A, >1. A clock, APP_CLK (200 MHz), comes out of a DCM, which is used to >mange the receiving clock from off-chip DDR2 DIMM. > >2. APP_CLK drives another DCM for clock synthesis of 100 MHz and 50 MHz. >The feedback of this DCM is from the output of DCM itself, which may be >an issue. > >3. Takes the 100 MHz clock to an ODDR primitive (Dedicated IOB double >data rate output registers). This is suggested by Xilinx Vitex-5 User >Guide. > >4. forward this clock to FPGA B. > >on FPGA B, > >1. use IBUG, DCM and BUFG to generate the synchronous clock. > >My concern is: >1. The 2 FPGAs don't have knowledge about each other. How does these two >clock synchronize to each other ? > >2. I put huge clock uncertainty (4 ns) with INPUT_JITTER. I hope this >will compensate the latency on board. > >3. What IO standard and PAD's constraints is suitable for this? > >One background that why I didn't choose board clock source to distribute > 2 FPGAS is because we want the 100 MHz clocks of both FPGAs >synchronized to APP_CLK. > >Appreciate any help in advance. I had a similar design requirement. I solved it this way: clock input -> DCM -> IOpad out +-> clock in fpga1 -> DCM |-> clock in fpga2 -> DCM and presto. Synchronous clocking of both fpga's. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 120752
Hi, I have a vague memory that Xilinx used to provide excel spreadsheets that showed the graphical pinout of each FPGA package using coloured cells to represent each pin. I couldn't find any reference after much googling and searching of the Xilinx site. Does anyone have a pointer to these spreadsheets, if indeed they still (or ever) existed? RobArticle: 120753
Hi, can anyone tell me what is the correct way to capture data from 60 mhz sampling, 16 bits ADC? Should I use 4 different phase shifted clock,0,90,180,270 with DCM and then decided which one work the best? If my system clock is different than sampling clock, how can I synchronize the data? should I should BRAM? thank you so much,Article: 120754
On Jun 12, 8:50 pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > My apologies to those who'd consider this spam, but my house in > Milpitas, CA was burglarized and among the less mainstream objects > stolen were a Tektronix THS730 oscilloscope and a Digilent Spartan > 3E-1600 Development Board. > > If anyone comes across a suspect sale of this board for sale, please > let me know. > > Thanks, > Tommy Those sorts of things aren't so easy to pawn, so you might ask if you were being targetted for some other reason. Maybe it's a bit different there, but there just aren't that many people around looking for o- scopes and FPGA development boards. Certainly not enough to get the "quick score". While it's possible that the thieves were just looking for "expensive looking stuff", it's possible that the target was your equipment. Do you do consulting work at home, or bring work home? Just something to consider. In all likelihood, it was probably just bad luck that they took your development hardware.Article: 120755
"cutemonster" <ckh827@hotmail.com> wrote in message news:CuOdneSaAIBJXO_b4p2dnAA@giganews.com... > > Hi, can anyone tell me what is the correct way to capture data from 60 mhz > sampling, 16 bits ADC? Should I use 4 different phase shifted > clock,0,90,180,270 with DCM and then decided which one work the best? If > my system clock is different than sampling clock, how can I synchronize > the data? should I should BRAM? > > thank you so much, Typically the design engineer evaluates the clock-to-out of the ADC and the input setup/hold times of the FPGA input registers in the IOB. If the FPGA uses a DCM, the phase of the DCM can be adjusted or the delay to the input registers can be adjusted. It may be that a DCM isn't required at all. If the timing values cannot be evaluated beforehand, it may be that a synamic approach is required but that's doubtful. How you store the data depends on what you want to do with it. Streaming applications require no storage, just work-in-process. Data acquisition systems need larger external memories that often use BlockRAMs as intermediate storage to buffer DMAs or burst transfers. Whatever you do, please don't use the DCM to generate the clock for the ADC since it could raise the noise floor of the ADC output significantly. Instead, use the clean clock that feeds the ADC to run the FPGA. - John_HArticle: 120756
Zorjak, A non-operational path is a "Hold Violation". We give this type of warning in cases where there is no clock requirements and the clock delay to the destination/latching register is much larger than the clock delay to the source/launching register (larger than the data delay), creating harmful clock skew. This is a problem because the data travels to the destination register much faster than the clock, creating a situation where the destination register will latch data sent by the source register on the "same clock edge" (as oppose to the following clock cycle). This is very serious as it means the circuit will never operate no matter what the clock speed is. See http://en.wikipedia.org/wiki/Clock_skew. So, why are you seeing this? This can happen if Quartus cannot place the clock on a global clock network, or more often, if the design has gated clocks (i.e. logic in the clock path), or ripple clocks not defined as derived clocks. The reason why you get the warning in some cases and not in others is likely plain luck. Based on the fit, the two registers may have positive clock skew (which result in the hold violation) or negative skew (which simply results in a lower Fmax). Or the different fit may simply slow down the data path such that data delay > clock skew. From the Clock Hold Timing Analyzer report panel, select the row with the Non-operational message, and use the mouse right-button "List Path" command to get details on the path. It will show you details on both the clock skew and data path >From the warning, I know you are not defining any clock requirement. I strongly recommend that you create clock requirements for all your clocks. This should include derived clocks on any ripple clocks (e.g. clock dividers). This will help the fitter come up with a better answer. If you go to "Assignments | Settings..." and clock on the "Fitter Settings", you will also find an "Optimize hold timing" check. You can change its value to "All Paths" to have the fitter insert delay to try to avoid hold violations. But this setting will only work well if you define your clocks correctly (this is very important). Please look at the following handbook chapter for more on timing analysis http://www.altera.com/literature/hb/qts/qts_qii53004.pdf David Karchmer Altera CorpArticle: 120757
<rob.dimond@gmail.com> wrote in message news:1181925467.941552.286330@n2g2000hse.googlegroups.com... > Hi, > > I have a vague memory that Xilinx used to provide excel spreadsheets > that showed the graphical pinout of each FPGA package using coloured > cells to represent each pin. > I couldn't find any reference after much googling and searching of the > Xilinx site. Does anyone have a pointer to these spreadsheets, if > indeed they still (or ever) existed? > > Rob > Hi Rob, Try partgen -v device_name at the DOS prompt. HTH, Syms.Article: 120758
>Hi all, >Right now I'm developing a board using virtex-II FPGA, and want to >implement a function >using the DCM to offer variable(dynamic) phase shifting. I use Xilinx >ISE 8.2i, and ModelSim >SE for development. As I setup the IP cores for DCM, everything looks >fine in the PRP simulation, >except that the PSDONE signal never goes high, which means everytime I >trigger the PSEN signal >to high (for exactly one period, as said in the User Guide), the DCM >just doesn't take any action. >I just wonder what is other things that I still need to do. If anybody >who can address my problem, >Thanks!~ > > I have the same problem using my spartan3. Have you solve your problem yet? thanksArticle: 120759
Symon wrote: > Hi Rob, > Try partgen -v device_name at the DOS prompt. Or try Jim Wu's ADEPT: http://home.comcast.net/~jimwu88/tools/adept/ It has a similar functionality built in. Or maybe it calls partgen and displays tne result in Excel? Dunno, but very handy tool nevertheless. -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 120760
radarman wrote: > On Jun 12, 8:50 pm, Tommy Thorn <tommy.th...@gmail.com> wrote: > > My apologies to those who'd consider this spam, but my house in > > Milpitas, CA was burglarized and among the less mainstream objects > > stolen were a Tektronix THS730 oscilloscope and a Digilent Spartan > > 3E-1600 Development Board. > > > > If anyone comes across a suspect sale of this board for sale, please > > let me know. > > > > Thanks, > > Tommy > looks like he 's buiding a time travel machine and being spied by the KGBArticle: 120761
Hi, Nico A good idea! Unfortunately, we have no control on board routing since it 's bought from outside. But thanks though!!! Kuo Nico Coesel wrote: > "Chris@Austin" <ggkuo@yahoo.com> wrote: > >> Hi, >> >> I'm new to FPGA world and currently working on an emulation board with 2 >> Virtex-5. I think to forward clock from chip A to chip B. Is that >> possible to make these 2 clocks synchronous ? What kind of steps, >> components and constraints need to be done to ensure the synchronous >> between these 2 FPGAs. The clock frequency is about 50-100 MHz range. >> >> My current scheme is as following, but doesn't work properly. Any help >> is appreciated. >> >> On FPGA A, >> 1. A clock, APP_CLK (200 MHz), comes out of a DCM, which is used to >> mange the receiving clock from off-chip DDR2 DIMM. >> >> 2. APP_CLK drives another DCM for clock synthesis of 100 MHz and 50 MHz. >> The feedback of this DCM is from the output of DCM itself, which may be >> an issue. >> >> 3. Takes the 100 MHz clock to an ODDR primitive (Dedicated IOB double >> data rate output registers). This is suggested by Xilinx Vitex-5 User >> Guide. >> >> 4. forward this clock to FPGA B. >> >> on FPGA B, >> >> 1. use IBUG, DCM and BUFG to generate the synchronous clock. >> >> My concern is: >> 1. The 2 FPGAs don't have knowledge about each other. How does these two >> clock synchronize to each other ? >> >> 2. I put huge clock uncertainty (4 ns) with INPUT_JITTER. I hope this >> will compensate the latency on board. >> >> 3. What IO standard and PAD's constraints is suitable for this? >> >> One background that why I didn't choose board clock source to distribute >> 2 FPGAS is because we want the 100 MHz clocks of both FPGAs >> synchronized to APP_CLK. >> >> Appreciate any help in advance. > > I had a similar design requirement. > > I solved it this way: > > clock input -> DCM -> IOpad out +-> clock in fpga1 -> DCM > |-> clock in fpga2 -> DCM > > and presto. Synchronous clocking of both fpga's. >Article: 120762
"cutemonster" <ckh827@hotmail.com> wrote in message news:QqqdnTYyipGfU-_b4p2dnAA@giganews.com... > >Hi all, >>Right now I'm developing a board using virtex-II FPGA, and want to >>implement a function >>using the DCM to offer variable(dynamic) phase shifting. I use Xilinx >>ISE 8.2i, and ModelSim >>SE for development. As I setup the IP cores for DCM, everything looks >>fine in the PRP simulation, >>except that the PSDONE signal never goes high, which means everytime I >>trigger the PSEN signal >>to high (for exactly one period, as said in the User Guide), the DCM >>just doesn't take any action. >>I just wonder what is other things that I still need to do. If anybody >>who can address my problem, >>Thanks!~ >> >> > > I have the same problem using my spartan3. Have you solve your problem > yet? > > thanks Something I saw in my own design: the state machine I was using to control the DCM in my Spartan-3E issued a PSEN before the DCM was ready. Since the state machine was waiting for a PSEN that would never come, my initial reaction was that I never received the PSDONE. By adding an explicit timeout for the PSDONE to reissue a PSEN as a workaround in my initial code, I was able to issue a first PSEN as seen by the DCM. Only with this timeout in place did I find that sometimes - making 10s of thousands of adjustments - the time from PSEN to PSDONE would exceed even the 5x timeout period I had designed for on very rare occasions. If you design a state machine to deal with a timeout, I'd suggest disabling the timeout after the first PSDONE is detected. If you're getting an error because you find yourself waiting too long, wait longer. If you're in this latter camp, it might be helpful to record a histogram of how many clock cycles it takes between PSEN and PSDONE. For your specific input jitter environment, you may get results that deviate from the published maximums. - John_HArticle: 120763
>"cutemonster" <ckh827@hotmail.com> wrote in message >news:QqqdnTYyipGfU-_b4p2dnAA@giganews.com... >> >Hi all, >>>Right now I'm developing a board using virtex-II FPGA, and want to >>>implement a function >>>using the DCM to offer variable(dynamic) phase shifting. I use Xilinx >>>ISE 8.2i, and ModelSim >>>SE for development. As I setup the IP cores for DCM, everything looks >>>fine in the PRP simulation, >>>except that the PSDONE signal never goes high, which means everytime I >>>trigger the PSEN signal >>>to high (for exactly one period, as said in the User Guide), the DCM >>>just doesn't take any action. >>>I just wonder what is other things that I still need to do. If anybody >>>who can address my problem, >>>Thanks!~ >>> >>> >> >> I have the same problem using my spartan3. Have you solve your problem >> yet? >> >> thanks > >Something I saw in my own design: the state machine I was using to control >the DCM in my Spartan-3E issued a PSEN before the DCM was ready. Since the >state machine was waiting for a PSEN that would never come, my initial >reaction was that I never received the PSDONE. > >By adding an explicit timeout for the PSDONE to reissue a PSEN as a >workaround in my initial code, I was able to issue a first PSEN as seen by >the DCM. > >Only with this timeout in place did I find that sometimes - making 10s of >thousands of adjustments - the time from PSEN to PSDONE would exceed even >the 5x timeout period I had designed for on very rare occasions. > >If you design a state machine to deal with a timeout, I'd suggest disabling >the timeout after the first PSDONE is detected. If you're getting an error >because you find yourself waiting too long, wait longer. If you're in this >latter camp, it might be helpful to record a histogram of how many clock >cycles it takes between PSEN and PSDONE. For your specific input jitter >environment, you may get results that deviate from the published maximums. > >- John_H > > > I checked lock pin and it's locked. So, it should be ready for phase alignment. I don't know why I still couldn't get it to work. How do you do with your reset sequence? If possible, can I take a look at your code to see what I missed? thanks a lot,Article: 120764
>"cutemonster" <ckh827@hotmail.com> wrote in message >news:CuOdneSaAIBJXO_b4p2dnAA@giganews.com... >> >> Hi, can anyone tell me what is the correct way to capture data from 60 mhz >> sampling, 16 bits ADC? Should I use 4 different phase shifted >> clock,0,90,180,270 with DCM and then decided which one work the best? If >> my system clock is different than sampling clock, how can I synchronize >> the data? should I should BRAM? >> >> thank you so much, > >Typically the design engineer evaluates the clock-to-out of the ADC and the >input setup/hold times of the FPGA input registers in the IOB. If the FPGA >uses a DCM, the phase of the DCM can be adjusted or the delay to the input >registers can be adjusted. It may be that a DCM isn't required at all. If >the timing values cannot be evaluated beforehand, it may be that a synamic >approach is required but that's doubtful. > >How you store the data depends on what you want to do with it. Streaming >applications require no storage, just work-in-process. Data acquisition >systems need larger external memories that often use BlockRAMs as >intermediate storage to buffer DMAs or burst transfers. > >Whatever you do, please don't use the DCM to generate the clock for the ADC >since it could raise the noise floor of the ADC output significantly. >Instead, use the clean clock that feeds the ADC to run the FPGA. > >- John_H > > > Hi John. I have to interface two ADC to my fpga. Should I use one main clock for everything? Since there are not in the same PCB, is that ok to use wires to connect all three boards' clock? Would that generate unnecessary problem like noise? thank you for replying me John,Article: 120765
Jon, I found where we have some info on mixed voltage environments in the config section of the Virtex-II UG http://direct.xilinx.com/bvdocs/userguides/ug002.pdf (see pg 281) While this is not a V4 Users Guide and your issue is not specific to the JTAG pins, the information is applicable to your device. The main point to keep in mind is that the Vih-min for LVCMOS33 is 2.0V. At 2.5V on the pull-ups for DONE and INIT, you exceed this by ~500mV and are OK (assuming no SI issues in the PCB). This may explain the mixed voltages on the ML405. If you have Vcco_0 at 3.3V the configuration pins are expecting LVCMOS33 levels, thus there is no problem with having the pull-up Vcc to DONE and INIT at 3.3V. -David "maxascent" <maxascent@yahoo.co.uk> wrote in message news:urGdndaP-d9ZDO_b4p2dnA@giganews.com... > Just had a look at some of the Xilinx development boards e.g. ML405 and > they seem to have Vcco_0 connected to 3.3V but have the pullups on done, > init_b connected to 2.5V. Is it possible to have them pulled up to 3.3V > instead? The documentation seems a bit vague about what supply you need to > use. > > Jon > >Article: 120766
Has anyone run into an issue where the mult instructions return 0 when using the hard multiplier in the V4FX? BTW, I'm using EDK 8.2. Here's the snippet from my MHS for the microblaze instantiation: BEGIN microblaze PARAMETER INSTANCE = mgmt_mb PARAMETER HW_VER = 5.00.c PARAMETER C_DEBUG_ENABLED = 1 BUS_INTERFACE DOPB = mgmt_opb BUS_INTERFACE IOPB = mgmt_opb BUS_INTERFACE DLMB = mgmt_dlmb BUS_INTERFACE ILMB = mgmt_ilmb PORT INTERRUPT = mgmt_intc_0_Irq PORT DBG_CAPTURE = DBG_CAPTURE_s PORT DBG_CLK = DBG_CLK_s PORT DBG_REG_EN = DBG_REG_EN_s PORT DBG_TDI = DBG_TDI_s PORT DBG_TDO = DBG_TDO_s PORT DBG_UPDATE = DBG_UPDATE_s END I know I don't have it explicitly set, but both the documentation, and the mpd file all default the HW mult parameter to 1. Thanks, MikeArticle: 120767
Look at Xilinx Ultracontroller II ref design. It is possible to put bootloader entirely into the PPC's chache.Article: 120768
Sylvain Munaut wrote: > Jeff Cunningham wrote: >> Andreas Hofmann wrote: >> >>> Do you have disabled the "Mark to initialize BRAMs"-Option for the >>> ppc405_bootloop? The icon next to ppc405_bootloop on the "Applications" >>> tab should contain a small red x. You can adjust the setting by right >>> clicking on the bootloop entry. >> Thanks, Andreas - I didn't notice the bootloop "application" in the >> little window (not in bold type like the other apps). I disabled that, >> and now when I try to update the bitstream, the first time Data2mem >> runs, it crashes. If I run it again, it says nothing needs to be done. >> But when I then go to download the bitstream, it says the bitstream is >> empty. I guess I will need to open a webcase on this unless anyone has >> any better ideas. > > By anychance, did you try to make a compressed or encrypted bitstream ? > > data2mem doesn't support those and it just crashes ... > > > Sylvain No, just a normal uncompressed bitstream. -JeffArticle: 120769
"cutemonster" <ckh827@hotmail.com> wrote in message news:zp-dncz6oLChZu_b4p2dnAA@giganews.com... > > Hi John. I have to interface two ADC to my fpga. Should I use one main > clock for everything? Since there are not in the same PCB, is that ok to > use wires to connect all three boards' clock? Would that generate > unnecessary problem like noise? > > thank you for replying me John, Are you feeling like you're in over your head on this project? Do either/both of your ADC boards have clock input or output available? Does your FPGA board have a clock input or a buffered clock output from the main oscillator? Do you need synchronized operation of your ADC boards or can they run at two different frequencies? How are you bringing the ADC data across to the FPGA board? Are you using wires? _____ I'm sorry that I can't provide you with my DCM phase shift code for your other matter.Article: 120770
Has anyone instantiated a MPMC2 interfaced to a SoDIMM and the following ports: 1) ISPLB (for the ppc405) 2) ISPLB (for the ppc405) 3) an OPB 4) a CDMAC for the hard temac When I try the build, if timing based mapping is used, the mapper dies when it tries to route the clocks saying that too many clocks are trying to enter the same clock domain. If I don't use timing based mapping, the same error occurs during PAR (duh). We're essentially trying to recreate what would be the GSRD setup on a V4FX60, but with an external SoDIMM chip. All of the FPGA is being clocked by an external 100MHz clock. The DDR SoDIMM is being run at 100MHz as well. For the clock report generated by the error, we can't find a clock region that would have too many clocks in it. In fact, the most the report shows is 4 (or 5) out of 8 global clocks in a region. Thanks, MikeArticle: 120771
jetmarc@hotmail.com wrote: >> I guess the choice is to either make a PLB slave that can access the >> flash, or sacrifice two brams. > > There's one more option. You can implement a custom ISOCM slave to > interface a tiny COREGEN ROM with your loader code. It should be do- > able with <32 instructions (128 bytes of ROM). > > Regards, > Marc > oooh, I like that idea. Maybe I wouldn't even need to implement a custom controller. If I make a custom ROM that acts like a block ram, with the 1st 16 locations aliased throughout the bram space that should do it.Article: 120772
Evnin' Just received the download link for ispLever 7.0 and read the announcement... Is it really true that 7.0 supports now mixed Verilog/VHDL projects? And also that Synplify is included with the Linux version as the website says so? cheers rickArticle: 120773
Thanks David for this explanation. I think that I understood you. Thanks for this advices. You are great. Thanks again dkarch...@gmail.com wrote: > Zorjak, > > A non-operational path is a "Hold Violation". We give this type of > warning in cases where there is no clock requirements and the clock > delay to the destination/latching register is much larger than the > clock delay to the source/launching register (larger than the data > delay), creating harmful clock skew. This is a problem because the > data travels to the destination register much faster than the clock, > creating a situation where the destination register will latch data > sent by the source register on the "same clock edge" (as oppose to the > following clock cycle). This is very serious as it means the circuit > will never operate no matter what the clock speed is. See > http://en.wikipedia.org/wiki/Clock_skew. > > So, why are you seeing this? > This can happen if Quartus cannot place the clock on a global clock > network, or more often, if the design has gated clocks (i.e. logic in > the clock path), or ripple clocks not defined as derived clocks. > > The reason why you get the warning in some cases and not in others is > likely plain luck. Based on the fit, the two registers may have > positive clock skew (which result in the hold violation) or negative > skew (which simply results in a lower Fmax). Or the different fit may > simply slow down the data path such that data delay > clock skew. From > the Clock Hold Timing Analyzer report panel, select the row with the > Non-operational message, and use the mouse right-button "List Path" > command to get details on the path. It will show you details on both > the clock skew and data path > > >From the warning, I know you are not defining any clock requirement. I > strongly recommend that you create clock requirements for all your > clocks. This should include derived clocks on any ripple clocks (e.g. > clock dividers). This will help the fitter come up with a better > answer. If you go to "Assignments | Settings..." and clock on the > "Fitter Settings", you will also find an "Optimize hold timing" check. > You can change its value to "All Paths" to have the fitter insert > delay to try to avoid hold violations. But this setting will only work > well if you define your clocks correctly (this is very important). > Please look at the following handbook chapter for more on timing > analysis > > http://www.altera.com/literature/hb/qts/qts_qii53004.pdf > > David Karchmer > Altera CorpArticle: 120774
leevv wrote: > Look at Xilinx Ultracontroller II ref design. It is possible to put bootloader entirely into the PPC's chache. I looked at ultracontroller II. My impression was that it required downloading the code over the jtag port using some server software like XMD. For imbedded (no PC) operation wouldn't I need to clone the XMD functionality in some sort of microcontroller? That seems like a big task, not so much the microcontroller part, but understanding/finding the documentation for the protocol of how to poke at the cache over jtag. I'd love to be shown otherwise. -Jeff
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