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
"mk" <kal*@dspia.*comdelete> wrote in message news:f0tjm35dafqqcpap3ipq90vi6nl411mhvr@4ax.com... > >>The reason he is having this warning is because of the inherent skew >>between the clock to a flip flop and the output of that flip flop and >>using them both as clocks which can not be 'managed' no matter how >>much attention you pay. > > I think this is an overly strong statement. > Not at all, I think Kevin is spot on. > > For a more general case > than we're talking here (not restricted to fpgas) what is the > substantial difference between a clock buffer and a clk-> Q delay of a > flop? I'm assuming that you'd agree if two flops were to get their clk > inputs from two separate leaves of the clock tree the skew would be > manageable and it can even be done if the two branches were related > higher in the tree. If one of the branches includes a flop, does the > skew become not managable no matter how much attention one pays? > mk, The problem in an FPGA is that you lose timing margin on the clk -> Q uncertainty of the FF, and then you lose a lot more margin on the uncertainty of the routing from the FF to the global clock tree. This loose timing is the undoing of many a design; some builds work, some don't. Now, don't get me wrong, it may be that you can contrain the design so it always works, but I wouldn't like to try that with current technology at 300MHz. I'm painfully aware that the FPGA timing tools aren't the easiest thing to drive when it comes to multiple clock domains. Be aware that the enabled solution does have issues also, especially at very high clock rates. The enable signal has to get to all destination in one cycle. Synthesis tools can replicate enable nets with many destinations leading to naming issues in the UCF. Synthesis tools sometimes need cajoling into using the CE input of the FF or memory. However, I prefer these problems to the alternative. The async FIFO or a DCM (as suggested by others) are among the other ways to 'properly' solve this issue. The FIFO solution is not 'unnecessary and overkill' IMO. When it comes to crossing timing domains, even overkill isn't overkill. Or something like that! ( BTW, XAPP291 is a personal favourite!) HTH., Syms.Article: 127401
"Eric Smith" <eric@brouhaha.com> wrote in message news:m34peeow1d.fsf@donnybrook.brouhaha.com... >I wrote: >> Am I asking for trouble if I route Vccint on the power plane?P > > John Larkin wrote: >> That works. Cut a square in the power plane, under the chip, and >> insert a smaller square of Vccint, so you can bring two supplies into >> the chip on each layer. Then you can route a fat trace in to power the >> inner island, with a few bypass caps, maybe on the backside of the >> board. > > OK, that's what I'll do. > > If I was using a Spartan-3 or Spartan-3E, which also require a > Vccaux of 2.5V, would it be reasonable to do the same thing to the > ground plane under the chip? > > Thanks! > Eric Hi Eric, I'd keep the ground plane intact and hack up the 'power' plane a bit more. I reason that it's much harder to cock up a PCB design with an intact ground plane! HTH., Syms.Article: 127402
On Thu, 20 Dec 2007 04:15:13 -0600, RCIngham wrote: >>is there a reason why not use the mega wizzard? I have a Stratix II GX >>running with various DP-RAMs. >> > I suspect that the O/P was trying to avoid having technology-dependent > RTL files and hence aid reuse. However, it looks like the synthesis > tools will thwart his worthy aim! You are absolutely right. I try to make my cores as technology independent as possible. I have customers using them in both Xilinx and Altera FPGAs as well as in ASICs. Even if you are staying with one vendor you still want portable code if possible because the vendors make major changes in their architectures. This particular design was done for the Virtex2P, migrated to the Virtex4FX and then to the Stratix2GX. It will eventually be in the Virtex5FX and the next Stratix than has SerDes (I don't know if that will be Stratix3GX or Stratix4GX, I've heard that Altera is skipping the Stratix3GX). Having to directly instantiate components complicates things. It also makes designs messier because you need a couple of levels of wrappers, the wrapper that the wizard generates and a wrapper around that which makes it generic. It also means that you have to do additional simulation because you have to run your testbench on each variant.Article: 127403
>"fpgaguy" <chongv@gmail.com> writes: >> I'm trying to write VHDL code that detects when two signals both rise from >> zero to one at the same time. Do you guys have any idea on how to do this? > >Except in simulation, two signals *never* rise at the "same time". > >A quick reality check for things like this is that if you can't do >something with "real" gates and flip-flops, you can't do it in >synthesizable VHDL (or Verilog) either. If you *can* do it with >gates and flops, then it's trivial to express it in VHDL (or Verilog). > >If you mean that you need to detect when both signals rise within a >clock period (for some arbitrary clock), you can do it fairly easily. >For instance, if you have a 100 MHz clock, you can detect whether >the two signals rise within the same 10ns clock period. Of course, >there's the usual uncertainty if one of the signals has an edge too close >to the active clock edge, so you need some flops as synchronizers. > >The following is completely untested. Provided with no warranty, >your mileage may vary, yada yada. > > >entity detector is > port (clk: in std_logic; > a: in std_logic; > b: in std_logic; > e: out std_logic); -- will ouptut a high pulse for one clock >end detector; > >architecture rtl of detector is > signal a1, a2, b1, b2: std_logic; -- dual-rank synchronizers > signal ap, bp: std_logic; -- previous state >begin > regp: process (clk) > begin > if rising_edge (clk) then > a1 <= a; -- dual-rank synchronizers > a2 <= a1; > b1 <= b; > b2 <= b; > ap <= a2; -- previous state > bp <= b2; > end if; > end process regp; > e <= '1' when ap = '0' and a2 = '1' and bp = '0' and b2 = '1' > else '0'; >end rtl; > Hey Eric, Thanks for the reply. I'll try the code out. FPGAguyArticle: 127404
> I would however advise you to have a quick google on some of the > verification techniques (if you don't already know them) such as > functional coverage, assertions based verification, constraint random and > transaction level modelling, nothing fancy just understand their > advantages and disadvantages and some of the languages they use. Having > said that I suspect a lot of verfication is still done using nothing more > than a VHDL/Verilog testbench in a similar trend to some FPGA engineers > just loading the design on the board and see if it works :-) Thank you Hans for the feedback. I am starting to have a very confident feeling. Especially when the areas you mentioned to google turned out to be areas I am very familiar with. I have been testing those areas in our EDA tools, I have a very firm grasp on those concepts and where they fall apart atleast for one set of EDA tools. Thank you everyone for the feedback the resume's are going out today.Article: 127405
Symon wrote:
> Not at all, I think Kevin is spot on.
Indeed. This can't be stated too strongly.
But I learned this one the hard way,
and I suppose that's the only way to remember it.
-- Mike Treseler
One clock, One heart ...
Article: 127406On Dec 20, 2:11 am, Daniel O'Connor <dar...@dons.net.au> wrote: > Hi, > I have a XC3S400 based design with an XCF02 and I am finding I can't program > the FPGA unless I power cycle it first. If I program the XCF02 it works > fine - I'd rather program the FPGA for testing though, it's quicker for a > start :) > > I am not really sure where to start since I designed the board myself > (although it is closely based on the Memec 3SLC eval board we have), I am > using XC3Sprog (because I don't actually run Linux), and I am an FPGA > noob :) > > Any hints or suggestions gratefully received. > > Thanks. > > -- > Daniel O'Connor software and network engineer > for Genesis Software -http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C There have been some issues with PlatformFlash and Spartan series parts. This usually crops up when your Spartan is behind the XCFxxS in the JTAG chain. If there is a valid bitstream in the XCFxxS part it is possible that the FPGA will start to configure from it during the JTAG programming operation. To see if this is your problem, see if you can program the FPGA directly via JTAG if you first erase the XCF02S. HTH, GaborArticle: 127407
On 2007-12-20, Eric Smith <eric@brouhaha.com> wrote: > I'm not very experienced at SMT PCB layout, but I'm trying to design a > four-layer board with an XC3S50A-4TQG144. I'm using inner layers for > 3.3V (Vcco, Vccaux) and GND. Am I asking for trouble if I route > Vccint on the power plane? I just assembled a 4-layer board with a EP2C8 (Cyclone II) in QFP. The stackup is sig/gnd/3.3/sig. The 1.2V core regulator is derived from the 3.3V and is near one corner of the FPGA. A very fat trace on the component side runs under the chip at the corner and forms a "Y" shape close to the inside perimeter of the pads. The Vccint is a little asymmetrical so that still leaves another corner open if you need it. I made the 1.2V PLL voltages (at the entry corner and the opposite corner) with cap+bead+cap. There's actually lots of room on the bottom, it's just a bunch of caps under the chip. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 127408
On 2007-12-20, Daniel O'Connor <darius@dons.net.au> wrote: > Hi, > I have a XC3S400 based design with an XCF02 and I am finding I can't program > the FPGA unless I power cycle it first. Is the config prom getting left in an odd JTAG state? Can you isolate it from the chain? -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 127409
Ben Jackson wrote: > On 2007-12-20, Daniel O'Connor <darius@dons.net.au> wrote: >> Hi, >> I have a XC3S400 based design with an XCF02 and I am finding I can't >> program the FPGA unless I power cycle it first. > > Is the config prom getting left in an odd JTAG state? Can you isolate it > from the chain? Hmm not without surgery :) You are suggesting the flash chip is doing something odd and preventing the FPGA from being programmed? I can probably bypass it without too much hassle for testing purposes.. The odd thing is that I can program the flash chip 100% reliably, but I can only program the FPGA once per power cycle.. I really need to do some testing with Impact to see if it's a problem with xc3sprog.. I would try http://rmdir.de/~michael/xilinx/ but I'm using FreeBSD and it doesn't emulate Linux's USBFS (yet :) As Gabor suggested I will try erasing the flash and see how I go as well. The flash is closest to TDI in this design - it could be swapped around for the production run but in that I'd mostly be programming the flash only so it's a bit of a moot point :) Thanks for the help. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 127410
Anyway, if we have to use more than one clock, for example, if the CLKI is 600MHz. So we have to use CLKI_DIV, don't we? Then, what should we do without using FIFO? You know, if the data is more than 100bit, FIFO will need a lot of resources.Article: 127411
On Dec 21, 4:04 am, wxy0...@gmail.com wrote:
> Anyway, if we have to use more than one clock,
> for example, if the CLKI is 600MHz.
>
> So we have to use CLKI_DIV, don't we?
>
> Then, what should we do without using FIFO?
> You know, if the data is more than 100bit, FIFO will need a lot of
> resources.
If you INSIST on not using a single 300MHz clock, then you could
handle the clock domain transfer between CLKI and CLKI_DIV without a
fifo using CLKI_DIV as the clock enable for data being transferred to
CLKI:
DOMAIN_XFER:
process (CLKI)
begin
if (CLKI'event and CLKI= '1') then
if (CLKI_DIV) = '1') then
data_clki <= data_clk_div;
end if;
Article: 127412<razzy2@gmail.com> wrote in message news:f7c326f6-f7ab-4546-afd5-ef905158c0c6@i72g2000hsd.googlegroups.com... > On Dec 21, 4:04 am, wxy0...@gmail.com wrote: >> Anyway, if we have to use more than one clock, >> for example, if the CLKI is 600MHz. >> >> So we have to use CLKI_DIV, don't we? > No, you have to use a DCM type solution. >> >> Then, what should we do without using FIFO? >> You know, if the data is more than 100bit, FIFO will need a lot of >> resources. > > If you INSIST on not using a single 300MHz clock, then you could > handle the clock domain transfer between CLKI and CLKI_DIV without a > fifo using CLKI_DIV as the clock enable for data being transferred to > CLKI: > > DOMAIN_XFER: > process (CLKI) > begin > if (CLKI'event and CLKI= '1') then > > if (CLKI_DIV) = '1') then > data_clki <= data_clk_div; > end if; > > Razzy, How, pray tell, does that help? Thanks, Symon.Article: 127413
On Dec 21, 5:41 am, "Symon" <symon_bre...@hotmail.com> wrote: > <raz...@gmail.com> wrote in message > > news:f7c326f6-f7ab-4546-afd5-ef905158c0c6@i72g2000hsd.googlegroups.com...> On Dec 21, 4:04 am, wxy0...@gmail.com wrote: > >> Anyway, if we have to use more than one clock, > >> for example, if the CLKI is 600MHz. > > >> So we have to use CLKI_DIV, don't we? > > No, you have to use a DCM type solution. > > > > >> Then, what should we do without using FIFO? > >> You know, if the data is more than 100bit, FIFO will need a lot of > >> resources. > > > If you INSIST on not using a single 300MHz clock, then you could > > handle the clock domain transfer between CLKI and CLKI_DIV without a > > fifo using CLKI_DIV as the clock enable for data being transferred to > > CLKI: > > > DOMAIN_XFER: > > process (CLKI) > > begin > > if (CLKI'event and CLKI= '1') then > > > if (CLKI_DIV) = '1') then > > data_clki <= data_clk_div; > > end if; > > Razzy, > How, pray tell, does that help? > Thanks, Symon. I've joined this thread a bit late. Although for this design I agree that a single clock domain at 300MHz and an enable signal is a very clean solution, has anyone considered using a PMCD? This would provide low skew versions of the 300 MHz and 150 MHz that the Xilinx tools should analyze properly and provide a robust solution. John ProvidenzaArticle: 127414
"johnp" <johnp3+nospam@probo.com> wrote in message news:a255b8d1-5e12-485c-b800-2ca2e126bdcb@x29g2000prg.googlegroups.com... > > I've joined this thread a bit late. Although for this design I agree > that a single clock > domain at 300MHz and an enable signal is a very clean solution, has > anyone considered > using a PMCD? > > John Providenza Hi John, The OP's assertion that "I can not use DCM" led me to believe that this solution was not to his liking. Cheers, Syms.Article: 127415
Hello, I want to know if the EDK included with the Spartan 3E Embedded Processing Development Kit - SP3E1600E MicroBlaze Edition can be used ONLY for MicroBlaze development, or can it also be used for PowerPC development, like on a Virtex-II Pro. Any hint will be very appreciated. Hugs, -- Jaime Andres Aranguren C. SanJaaC Electronics Soluciones en DSP www.sanjaac.com -- Posted via a free Usenet account from http://www.teranews.comArticle: 127416
Jaime, The Spartan 3E does not have an IBM 405PPC integrated into it, so strictly speaking, you can not develop and run a 405PPC program on the 3E product (or development kit). AustinArticle: 127417
"austin" <austin@xilinx.com> escribió en el mensaje news:fkhaqm$i5m1@cnn.xsj.xilinx.com... > Jaime, > > The Spartan 3E does not have an IBM 405PPC integrated into it, so > strictly speaking, you can not develop and run a 405PPC program on the > 3E product (or development kit). > > Austin Hello Austin, thanks for the reply. What you said is 100% understood. Spartan3 (A/E/AN/A DSP) does not have PowerPC cores, but you can use the MicroBlaze SOFTcore on them. That is what this Spartan 3E Embedded Processing Development Kit - SP3E1600E MicroBlaze Edition is for. The question is about EDK, the software development tool, not about the FPGA. The version of EDK bundled with this kit is dubbed "MicroBlaze Edition". So que question is: is this version of EDK ONLY useful for MicroBlaze development, or is it the full, normal, standard version of EDK which one could also use for PowerPC developement? Regards, -- Jaime Andres Aranguren C. SanJaaC Electronics Soluciones en DSP www.sanjaac.com -- Posted via a free Usenet account from http://www.teranews.comArticle: 127418
Jaime, Understood. According to all the web literature, the Software Platform Studio (EDK) supports both the MicroBlaze(tm) and the IBM 405PPC (both soft, and hard cores). I know that we use the PLB interface for both, and we have peripherals developed that work with both, so it would just make sense to support both with one package (seems to be more trouble to separate the two!). In fact, we have PPC customers, who also use MicroBlaze in their designs (for special tasks). Since Xilinx is "off" next week, I can't do any research into this right now. When I get back (next year) I can check on it for you if there is no other answer, sooner. Merry Christmas, and Happy New Year, AustinArticle: 127419
On 21 dic, 17:36, austin <aus...@xilinx.com> wrote: > Jaime, > > Understood. =A0According to all the web literature, the Software Platform > Studio (EDK) supports both the MicroBlaze(tm) and the IBM 405PPC (both > soft, and hard cores). =A0I know that we use the PLB interface for both, > and we have peripherals developed that work with both, so it would just > make sense to support both with one package (seems to be more trouble to > separate the two!). > > In fact, we have PPC customers, who also use MicroBlaze in their designs > (for special tasks). > > Since Xilinx is "off" next week, I can't do any research into this right > now. =A0When I get back (next year) I can check on it for you if there is > no other answer, sooner. > > Merry Christmas, and Happy New Year, > > Austin Hello Austin, Thanks for the informati=F3n, very instructive. OK, let's wait until next year (sounds faaaar away) in order to have "official" feedback. Also, have a nice Christmas and the best for 2008. JaaCArticle: 127420
Jaime Andres Aranguren Cardona wrote: > The question is about EDK, the software development tool, not about the > FPGA. The version of EDK bundled with this kit is dubbed "MicroBlaze > Edition". So que question is: is this version of EDK ONLY useful for > MicroBlaze development, or is it the full, normal, standard version of EDK > which one could also use for PowerPC developement? I bought that kit, and it appears to be the full, normal, standard version of EDK. It gives me the option of generating PPC projects, and seems to build them just fine, though I haven't actually tried to run the resulting bitstream and object code on a V2 Pro or V4 FX. EricArticle: 127421
On Dec 19, 8:00 pm, Eric Smith <e...@brouhaha.com> wrote: > I wrote: > > Am I asking for trouble if I route Vccint on the power plane?P > John Larkin wrote: > > That works. Cut a square in the power plane, under the chip, and > > insert a smaller square of Vccint, so you can bring two supplies into > > the chip on each layer. Then you can route a fat trace in to power the > > inner island, with a few bypass caps, maybe on the backside of the > > board. > > OK, that's what I'll do. > > If I was using a Spartan-3 or Spartan-3E, which also require a > Vccaux of 2.5V, would it be reasonable to do the same thing to the > ground plane under the chip? > > Thanks! > Eric Like others have said, it's best not to mess with the ground plane. I have a four-layer S3E VQ100 board (1.2/2.5/3.3) that's somewhat ugly inside, but it works. Just divvy the power plane as best you can and run fat traces to the other pins. -MikeArticle: 127422
Hi, Has anyone used the ddr_sdr core (http://www.opencores.org/ projects.cgi/web/ddr_sdr/overview) on real hardware ? This core only uses the DQS lines for writing to the memory, and sets them as outputs. Therefore, during reads, both the FPGA and the DDRAM chip will drive them at the same time. Won't it be a problem ? Maybe not, thanks to the series termination resistors...but can anyone confirm ? Regards, SebastienArticle: 127423
> Hi Dan, > What's wrong with US products? Last time I ordered US$ 100 of stuff from DigiKey, I ended up paying EUR 55 in "extra" (customs taxes etc). But then I'm French and here we really like to tax everything. HOWEVER when the same product costs US$100 or EUR 150, which is really often the case, get a friend in the US to ship it to you ;)Article: 127424
I just click "Auto pin swap" in Altium's menu... However it has a few stupidities, like swapping input-only and ouput pins, which means you have to define the swapgroups yourself. This is quite easy, however the program often deletes some (but not all) of my swap group definitions without warning and then won't swap some pins. So i have to re-define the swap groups every five minutes. I think it sucks. On Thu, 18 Oct 2007 17:20:48 +0200, <cpandya@yahoo.com> wrote: > We are using V5LX110T and V5L330 FPGAs. Are there decent pin swapping > utilities so that we do not have to spend a lot of time in PCB Laout > to do the pin swapping? I am hoping that the tool shows the BGA view > of the FPGA and lets the user to swap pins such that there is good > break out from the FPGA. > > Thanks. > > CP >
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