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
Per Jensen wrote: >> Can anyone tell me how i do this, step for step, as i am a new user of >> CPLD's. - preferrably link to a online article describing how it's done. If you are interested in HDL design, learn simulation first. If you want to flash LEDs ASAP, get a newer demo board. -- Mike TreselerArticle: 105426
Click on Assignments->Settings->Fitter Settings and set the "Optimize Hold Timing" drop down to All Paths.The default value for the "Optimize Hold Timing" drop dow is I/O Paths and Minimum tpd paths. Hope this helps, Subroto Datta Altera Corp. "oopere" <oopere@netscape.net> wrote in message news:1153408027.691966.40970@i3g2000cwc.googlegroups.com... > Quartus II is reporting a clock hold time violation in a circuit which > may be described by the following diagram: > > -------- -------- > d FF q--[logic]--d FF q > -clk | -clk | > | -------- | -------- > | | > --o------------------ > > I understand that the problem is that the input d of the second FF > changes too early after the common clock edge. However, somewhere else > in the same circuit I have the following > > -------- -------- > d FF q-----------d FF q > -clk | -clk | > | -------- | -------- > | | > --o------------------ > > and quartus II does _not_ report any hold time violation here, and > obviously enough, the situation is even worse. > > Something similar appears if I build a divide by 2: > a) directly (inverted q to d) or > b)using a 1 bit wide lpm_counter. > In the first case, I get a hold time violation and everything is ok in > the second case. > > Perhaps someone can provide some insight into the following questions: > > 1. Is something inherently wrong with the first schematic? I even > thought it was always good idea to resynchronize signals in a similar > way. > > 2. In case this approach is ok, why does quartus II report clock hold > time problems? > > 3. If applicable, what should I tell the quartus II timing analyzer to > get rid of this error? > > Thanks, > Pere > >Article: 105427
Synchronous design, in which all FFs are synchronized by a single clock, perhaps is the single most important methodology. In a Xilinx Spartan-3 FPGA, there are 8 clock trees, even for the smallest device. What is the purpose of these clocks? - Could someone provide me few meaningful examples (not sloppy design) that use multiple clocks? - Can anyone from Xilinx explain the rational behind these many clock trees? (to accommodate bad habits?) To my understanding, multiple clock domains are needed primarily for 1. extremely large design with large clock skew. 2. power awareness design. Clearly the clock skew is not an issue for Spartan-3. Are these clock trees used for power purpose? Thank you for your help. S. C.Article: 105428
"fp" <fpga002006@yahoo.com> writes: > - Could someone provide me few meaningful examples (not sloppy design) > that use multiple clocks? I have a design with a processor core (one clock domain), two MII interfaces for Ethernet (four clock domains, one for each transmit and receive interface), and a VGA interface (one clock domain). That's a total of six clock domains. Everything gets synchronized to the processor core clock domain by FIFOs, but there is various logic on the interface side of the FIFOs which must be in the interface's clock domain.Article: 105429
> What is the purpose of these clocks? > - Could someone provide me few meaningful examples (not sloppy design) > that use multiple clocks? Well, sure, there are plenty ... Even if you main core is fully synchronous, you have to "talk" to the external world and that's often where clocks are needed. Let's imagine, a simple application : A PCI video card with some hw acceleration (like decompression, or some drawing primitive or filtering ...) You'll have : - The PCI clock - The pixel clock - The core clock, which may be different because you want the core to run faster than 33 MHz and not having a dynamic frequency like the pixel clock. That's also gonna be the memory main clock. - Probably a 90° shifted clock and a dynamically shifted clock for the DDR logic and data capture. That's already 5 clocks ... and for a quite simple design. It only have a "input" (the PCI) and one output (the VGA or DVI). And here the core is fully synchronous. Sometimes, even in "nice" (i.e. not sloppy ;) designs, you will have multiple clocks. Imagine a design where part of the process implies a bit-by-bit operation (like an entropic coder), you might want to be able to push that part at a higher frequency ... SylvainArticle: 105430
heinerlitz@gmx.de wrote: > Hi Joseph, > > thanks a lot I will check all the thing you suggested and yes its a > board made by us. > > Still I have some questions: > > The Calibration process with the dummy reads can be definitely observed > using chip scope and it seems to be ok as the tap_select signal is > asserted. Does that mean that at least the control and the DQS signals > should be fine. I would assume for the moment that the RAM is decoding the control signals correctly. > The question I have is the following in the init > sequence the controller just writes data to the RAM, the Ram itself > does practically nothing. in the init sequence, the controller just READS the RAM, so that the RAM will send back DQS signals so the controller can tweak the input delays. >SO assuming the RAM wouldnt consist at all > would the init and calibration sequence still be succesfull? > > > I tried a board without RAM assembly and it didnt do anything so I > assume not.. No, because the controller needs those DQS signals back from the RAM in order to se the delays. > As I said before the data compare module fails so it could be a signal > integrity problem which casuses the read out data to be corrupt. Or, the read could be correct and the write could be wrong. It's kind of hard to tell that if you aren't getting past Comp_Done. You should probably look at the data going to and from the RAM, to see what's going on. Maybe there's a stuck bit, or maybe data from one bank is wrong but the rest are right. There are a lot of possibilities. It will take some investigating with ChipScope to figure out what's going on. --- Joe Samson Pixel VelocityArticle: 105431
Hello, for the moment, I use SVN to manage different versions of te VHDL code of my projects. I'd like to manage my xilinx projects based on my VHDL code too. Until now, I just put the <project>.ise and <project>.ucf files under version control and it was enough to be rebuild the whole project. Now, I've added an embedded processor to my ISE design and I'm a bit confused because there a huge set of automatically generated files. I'd like to keep under version control just the minimum set of files required to rebuild the whole project. I think there's at least the <project_up>.xmp, <project_up>.mhs and <project_up>.mss files, but is it enough ? Any idea ? ManuArticle: 105432
"fp" <fpga002006@yahoo.com> wrote: >Synchronous design, in which all FFs are synchronized by a single >clock, perhaps is the single most important methodology. In a Xilinx >Spartan-3 FPGA, there are 8 clock trees, even for the smallest device. >What is the purpose of these clocks? >- Could someone provide me few meaningful examples (not sloppy design) >that use multiple clocks? >- Can anyone from Xilinx explain the rational behind these many clock >trees? (to accommodate bad habits?) > >To my understanding, multiple clock domains are needed primarily for >1. extremely large design with large clock skew. >2. power awareness design. >Clearly the clock skew is not an issue for Spartan-3. Are these clock >trees used for power purpose? Higher clock speeds lead to less efficient use of FPGA resources. The design I'm currently working on uses 4 different clock speeds: 6MHz, 25MHz, 50MHz, 100MHz. The 6MHz clock is used for uC configuration stuff (many registers, but no hurry), the 25MHz clock to run a picoblaze, 50MHz for generic logic and 100MHz for anything that needs to go really fast (like a DDR memory interface and some digital filters). In my past experiences with Spartan 2 and Virtex devices, I've noticed that choosing the lowest clock frequency lead to being able to pack a lot more logic into an fpga because the router can use least efficient leftovers for the slow stuff. The downside is that you'll need to cross clock boundaries every now and then. However, routing time is shortened considerably. A design which uses 64% (equivalent gate count: 285000) of a Spartan3-200k device routes in under 3 minutes on a P4 1.6GHz. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 105433
Hi to all; Can anybody help me getting VHDL source code for KASUMI ? Thanks in advance for any help. Best regards. AdamouArticle: 105434
Mike Treseler skrev: > > If you are interested in HDL design, learn simulation first. > If you want to flash LEDs ASAP, get a newer demo board. > > -- Mike Treseler Mike, i want to do some simple adress-decoding that is time-critical, where a PIC micro won't do it fast enough. I don't have a demo board at this point, and won't buy a CPLD one anytime soon, if i buy anything, it will be a Spartan 3E or bigger. At the moment i am using a shitload of modules from my ex-employment company which is 72-pins SIMM modules with 2 * XCR5064C, a PIC, some 245's LM75 temp sensor, 24LC16 EEPROM and so on, actually very sweet. was used for "processor" board for Ericsson DIAX Telephone system PSU.Article: 105435
radarman skrev: > > I have a copy of 4.2i at work, so I can check back Monday with whether > it supports this device or not. I suspect it will, as the datasheet > specifically mentions that you can use VHDL/Verilog in addition to ABEL > and schematic capture. > > Regards, > -Seth > Seth, i would be VERY glad if you would check up on this, since the 3.3 version is pretty mangled in contrast to 8.1 - there is a lot that simply doesn't work. there is a contraints-editor in the program folder but i can't call it from the project manager, it's just not listed as an option, and running it manually doesn't help since i don't have the NGD-file.... Very frustrating. i have learned how to make the file manually, but it's a lot easier for me if it was in a program and not notepad. Regards, Per.Article: 105436
Can I do anything (besides moving the pins around) to improve what you see
below:
============================================================================
====
Timing constraint: TS_system_i_ll_temac_0_ll_temac_0_tx_gmii_mii_clk_in_i =
PERIOD TIMEGRP
"system_i/ll_temac_0/ll_temac_0/tx_gmii_mii_clk_in_i" 8 ns HIGH 50%;
20 items analyzed, 2 timing errors detected. (2 setup errors, 0 hold
errors)
Minimum period is 8.290ns.
----------------------------------------------------------------------------
----
Slack: -0.145ns (requirement - (data path - clock path skew
+ uncertainty))
Source: system_i/ll_temac_0/ll_temac_0/temac_0/v4_emac (CPU)
Destination:
system_i/ll_temac_0/ll_temac_0/rgmii0/txd_falling_i_2 (FF)
Requirement: 4.000ns
Data Path Delay: 3.881ns (Levels of Logic = 0)
Clock Path Skew: -0.123ns
Source Clock: RGMII_TXC_0 rising at 0.000ns
Destination Clock: RGMII_TXC_0 falling at 4.000ns
Clock Uncertainty: 0.141ns
Data Path: system_i/ll_temac_0/ll_temac_0/temac_0/v4_emac to
system_i/ll_temac_0/ll_temac_0/rgmii0/txd_falling_i_2
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
--------------------------------------------------- -------------------
EMAC_X0Y1.EMAC0PHYTXD6 Tmaccko_TXD 2.827
system_i/ll_temac_0/ll_temac_0/temac_0/v4_emac
system_i/ll_temac_0/ll_temac_0/temac_0/v4_emac
SLICE_X19Y153.BY net (fanout=1) 0.712
system_i/ll_temac_0/ll_temac_0/rgmii_txd_falling_i<2>
SLICE_X19Y153.CLK Tdick 0.342
system_i/ll_temac_0/ll_temac_0/rgmii0/txd_falling_i<2>
system_i/ll_temac_0/ll_temac_0/rgmii0/txd_falling_i_2
--------------------------------------------------- -------------------
--------
Total 3.881ns (3.169ns logic,
0.712ns route)
(81.7% logic, 18.3%
route)
Thanks,
/Mikhail
Article: 105437
>> As I said before the data compare module fails so it could be a signal
>> integrity problem which casuses the read out data to be corrupt.
>
> Or, the read could be correct and the write could be wrong. It's kind of
> hard to tell that if you aren't getting past Comp_Done. You should
> probably look at the data going to and from the RAM, to see what's going
> on. Maybe there's a stuck bit, or maybe data from one bank is wrong but
> the rest are right. There are a lot of possibilities. It will take some
> investigating with ChipScope to figure out what's going on.
>
Be aware than when putting chipscope and looking at we / cas / ras ...
you might prevent the tools to put the last register into the IOB and
then you have bad timings ...
So if it's the case, you are actually creating a problem with chipscope
and not debugging the real one ...
Checkout the timing report to see if the clock-to-out of the ddr_clk and
the control signals and the address leads to a valid timing.
Sylvain
Article: 105438Per Jensen wrote: > Mike Treseler skrev: > >> >> If you are interested in HDL design, learn simulation first. >> If you want to flash LEDs ASAP, get a newer demo board. >> >> -- Mike Treseler > > > Mike, i want to do some simple adress-decoding that is time-critical, > where a PIC micro won't do it fast enough. > > I don't have a demo board at this point, and won't buy a CPLD one > anytime soon, if i buy anything, it will be a Spartan 3E or bigger. > > At the moment i am using a shitload of modules from my ex-employment > company which is 72-pins SIMM modules with 2 * XCR5064C, a PIC, some > 245's LM75 temp sensor, 24LC16 EEPROM and so on, actually very sweet. > was used for "processor" board for Ericsson DIAX Telephone system PSU. Is that one the re-banded PZ5064 Philips die ? - if so, you might be able to find and use the Philips Coolrunner tools ? If you need a "5V for-new-designs" part, look at the Atmel ATF1502ASL, and ATF1504ASL - will do simple address decode very easily. -jgArticle: 105439
I have an Aurora core on a VII-Pro. I need to set the RXPOLARITY to 1. Where is this MGT signal controlled from? I thought it would be simple to do but I can't see where it can be set for configuration. TIA. Rog.Article: 105440
Jim Granville skrev: > > Is that one the re-banded PZ5064 Philips die ? > - if so, you might be able to find and use the Philips Coolrunner tools ? > > If you need a "5V for-new-designs" part, look at the Atmel ATF1502ASL, > and ATF1504ASL - will do simple address decode very easily. > > -jg > JG, the chips says Xilinx with the Original logo, but early procuction chips says Philips :-) I have two chips in PLCC packaging (from development of the modules) - that is Indeed Philips parts too, it acts as the Xilinx part 100% I am not doing any "designs", this is pure hobby. i have bough a lot of Xilinx 9572XL in PLCC packaging, that is ample for my needs at this time. I really like the workspace of the Xilinx software, so jumping to another platform is not something i would like to do at this moment. Regards, Per.Article: 105441
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message news:1153584575.288384.141130@m73g2000cwd.googlegroups.com... > Hi, > Can you help explain a method to print a state flow graph for any state > machine design written in VHDL using either Xilinx ISE or ModelSim > software? > > If neither has the ability of doing the function, what else software > can do it? > Well, I did a state machine in ISE some time ago, and as far as I can remeber, it was a matter of chosing "print" from some meny. I dont recall having any trouble with that at all. Another thing is that I write my own state machines from now on. In VHDL. Thats not difficult at all. And the code generated from ISE is not *that* good, when it comes to human readability.Article: 105442
Modern FPGAs be clocked at 13x your 18 MHz sample rate. Doing so lets you share the same hardware for all 13 of your biquads, and also gives you the benefit of allowing a 13 clock pipeline latency in the feedback loops in the filter implementation. If you use the embedded multipliers that are common on many of the modern FPGAs, you should be able to manage with 13 pipeline stages in the loop. It may be a bit of a challenge if it is a floating point implementation: in that case you can use 2 instances, each handling 7 filters to get twice as much pipeline latency around the loop, which should be ample for a floating point implementation. stephaneo@gmail.com wrote: > Hi, > > I have posted on comp.dsp about this and got interesting answers. I > have just discovered this group so I would like to know if some of you > have something to add... > > I have designed a 26 order IIR filter (13 biquads) > > Someone proposed on comp.dsp to use direct form I saying that it's was > not the best structure for optimising the FPGA "space", the easiest to > design though. > > I know that biquads implementation are better to control problems that > occurs with FPGA > > By the way, I think that, when I will have succeed in designing a > efficient 2nd order cells on the FPGA, I will be able to do any order > of filters. As I will know how much "space" a single cell takes, I will > > just need to connect these cells in cascade. > > Do you think that Direct-Form (or even tranposed) I 2nd order > structures with a pipeline at 2*Freq is the best way to achieve such a > design? > > My sample rate is 18 Mhz. > > Thanks for your help. > > NB : The post on comp.dsp was titled "FPGA" >Article: 105443
adamou@gmail.com schrieb: > Hi to all; > > Can anybody help me getting VHDL source code for KASUMI ? > > Thanks in advance for any help. > > > Best regards. > > Adamou yes. anybody can help you. 1) just contact some company selling kasumi IP and purchase the code or 2) take the C reference code and use C to VHDL conversion (like impulse-C) or 3) take the KASUMI specification and write the KASUMI VHDL if you are looking for free open source KASUMI VHDL then ASFAIK there is none. Antti http://antti-brain.comArticle: 105444
All, Any external resistor, no how well implemented is ever as good as an internal termination. It has to do with the short stub to the resistor which is unavoidable being a source of reflections. That aside, the DCI for SSTL/HSTL is a resistance to ground from the rails, so it uses power (more than 200 IO's and we are talking some serious number of watts). Have you considered using LVCMOS DCI in a bidirectional mode? If you would like to see a signal integrity program result, email me directly (or request one from the hotline). Talking about it won't solve your problem. You have to do some real SI engineering for any custom IO requirement. In my opintion, it should be done for any IO requirement. Austin Austin PeteS wrote: > John Adair wrote: > >>Your biggest issue is not the top surface area for the resistor site >>but the via space and extra routing needed to connect resistors. The >>vias especially will have significant routing effects. Even using a >>microvia blocks the path for potentially an extra signal. Conventional >>vias block 2 traces worth in our standard technology. BGA resistor >>packs whilst small tend not to have a good run of routing them and >>generally increase layer count to achieve the end result. >> >>John Adair >>Enterpoint Ltd. > > > Depends on what is being routed, of course. > > In this particular application, the signal can go in and out very > easily (1 track between balls for each ball position) and no vias at > all are required. > > In a parallel termination case, things are different, but for a series > terminator, the devices I have used work just fine with no extra layer > count required. Indeed, the part manufacturers are aware of the issue > that saving space for the package but providing poor access negates any > advantage of the package size, so parts are appearing that have decent > routing ability. > > Cheers > > PeteS > > > >>PeteS wrote: >> >>>John Adair wrote: >>> >>>>Standards like SSTL are good for this due to the low signal swing. The >>>>biggest decision is if to use DCI which burns more power in the V4 or to use >>>>external resistors which take board area and make routing more difficult. >>>> >>>>The other decision is weither you use source synchronous clocking or a >>>>common clock approach. At 150 Mhz the common clock is slightly marginal >>>>depending on how long tracks are, speed grade, etc. unless you use some DCM >>>>based techniques. You can generate a clock that is offset from the common >>>>clock a little by using a DCM and use that as clock for register input to >>>>gain more time. Alternatively you can use a DCM to null out the clock to >>>>output time and get more margin from that. >>>> >>>>John Adair >>>>Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development >>>>Board. >>>>http://www.enterpoint.co.uk >>>> >>>> >>>>"Marc Reinig" <Marco@newsgroups.nospam> wrote in message >>>>news:44bc1fed@darkstar... >>>> >>>>>I have a project where I will have a large array of V4 FPGAs. Each chip is >>>>>intended to connect to its four orthogonal neighbors with no intervening >>>>>logic. I would like the number of bus connections between chips in any >>>>>direction in the array to be 150 (600 total I/O per chip). The connections >>>>>will be bi-directional. The distance between chips will be the minimum I >>>>>can have with sockets, heat sinks (with individual fans), good layout and >>>>>noise control. Some of the lines, what ever is necessary, will be used for >>>>>clock and framing for the bus data signals. I would like to use DDR. >>>>>During bus transfers, all the lines on opposite sides of the chip will be >>>>>operating and the other two sides will be quiescent. I'm hoping for a bus >>>>>clock of 150 MHz. >>>>> >>>>> >>>>>Comments? ;=) >>>>> >>>>>Marco >>>>>________________________ >>>>>Marc Reinig >>>>>UCO/Lick Observatory >>>>>Laboratory for Adaptive Optics >>>>> >>>>> >>> >>>If Marc uses SSTL, and uses resistive terminators, I would agree it >>>takes board space, but I disagree it would make routing significantly >>>more difficult, except for the sheer number of devices. In a point to >>>point situation only a series terminator is really required for speeds >>>up to at least 200MHz / 400Mb/s (I've done it). >>> >>>Assuming these busses would be bidirectional, external series resistors >>>would [arguably, at least] actually be better in reducing EMI and >>>reflections than just DCI (less power too) assuming the devices are >>>close together (of the order of perhaps 4 inches or less). Much really >>>depends on the distance. I've used BGA style resistor packs that cram >>>more resistors into the device than can be done in multipack type SMT >>>devices. Apart from that, the tiny quad pack devices are particularly >>>sensitive to even slightly imperfect chip shooters and have a nasty >>>tendency to crack the resistor, particularly at the ends of the device. >>> >>>CTS corp makes a particularly nice range of devices >>>(http://www.ctscorp.com/components/clearone.asp) [I have no affiliation >>>with them except for having used the parts in the past]. >>> >>>Cheers >>> >>>PeteS > >Article: 105445
S. C. One use I was given is that there is more than one design in the chip. Sort of like an apartment building, with different tenants. Another use is for standard interfaces which you do not get to choose the frequency: SDRAM at 266 MHz, PCI at 33 MHz, and a SONET core at 78 MHz, all working together to perform some overall function. Austin fp wrote: > Synchronous design, in which all FFs are synchronized by a single > clock, perhaps is the single most important methodology. In a Xilinx > Spartan-3 FPGA, there are 8 clock trees, even for the smallest device. > What is the purpose of these clocks? > - Could someone provide me few meaningful examples (not sloppy design) > that use multiple clocks? > - Can anyone from Xilinx explain the rational behind these many clock > trees? (to accommodate bad habits?) > > To my understanding, multiple clock domains are needed primarily for > 1. extremely large design with large clock skew. > 2. power awareness design. > Clearly the clock skew is not an issue for Spartan-3. Are these clock > trees used for power purpose? > > Thank you for your help. > > S. C. >Article: 105446
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:1153510009.206861.78040@p79g2000cwp.googlegroups.com... > Andy wrote: >> Too bad the author is a proponent of the ancient style of separate >> clocked and combinatorial processes in VHDL. He even uses a third >> process for registered outputs. >> >> I think he needs to discover what variables can do for you in a clocked >> process. > > Really? Which of his arguments do you disagree with? > > I always thought of the two-process style as being redundant, but after > reading Dr. Chu's argument, I'm revising my thinking. For one thing, > this style makes it much less disruptive to change a Moore output to a > Mealy and vise versa. > > My thanks to S.C. for the reference. Good one. > But in practice one doesn't much care if any outputs are 'Mealy' or 'Moore'. What one has is a function that needs to be implemented within specific area (or logic resource) constraints and performance (i.e. clock cycle, Tpd, Tsu, Tco) constraints. Breaking what can be accomplished in one process into two (or more) logically equivalent processes should be considered for code clarity which can aid in support and maintenance of the code during it's lifetime as well as for potential design reuse (although realistically re-use of any single process is probably pretty low). Re-use happens more often at the entity/architecture level, but the 'copy/paste/modify' type of re-use probably happens more at the process level when it does happen. Breaking a process into two just to have a combinatorial process to describe the 'next' state and a separate process to clock that 'next' state into the 'current' state has no particular value when using design support and maintenance cost as a metric of 'value'. Since the different methods produce the final end logic there is no function or performance advantage to either approach. On the other hand, there are definite drawbacks to implementing combinatorial logic in a VHDL process. Two of these are - Introduction of 'unintended' latches - Missing signals in the sensitivity list that result in different simulation versus synthesis results Both of these drawbacks have manual methods that can be used to try to minimize them from happening but the bottom line is that extra effort (a.k.a.. cost or negative value) must be incurred to do this....all of which is avoided by simply not using the VHDL process to implement combinatorial logic (i.e. the 'next' state computation). So as far as the VHDL language is concerned, there are real costs that will be incurred every time the two process method is used but no real value add....or at least that's my 2 cents..... KJArticle: 105447
Austin Lesea wrote: > All, > > Any external resistor, no how well implemented is ever as good as an > internal termination. It has to do with the short stub to the resistor > which is unavoidable being a source of reflections. True in a literal sense, provided one can get the precision, which is not that easy in a standard IC. That said, the parasitics you refer to are not an issue for an 0402 device at 5Gb/s signalling (far higher speeds than the OP desires to deal with in this case) - any such parasitics are swamped by other issues of moving a signal across ciruit board (depends on the specific circuit board, of course, but in this case I expect the project to be FR-4 based). There are methods of dealing with the 'stub' (by necking the track to the pad and trickery with adjacent grounds on the same layer) which reduce it to the realm of effectively non-existent. For this particular case, if you look at the part I suggested, the only discontinuity would be at the ball itself, and that is a minor issue. Cheers PeteS > > That aside, the DCI for SSTL/HSTL is a resistance to ground from the > rails, so it uses power (more than 200 IO's and we are talking some > serious number of watts). > > Have you considered using LVCMOS DCI in a bidirectional mode? > > If you would like to see a signal integrity program result, email me > directly (or request one from the hotline). > > Talking about it won't solve your problem. You have to do some real SI > engineering for any custom IO requirement. In my opintion, it should be > done for any IO requirement. > > Austin > > Austin > > PeteS wrote: > > > John Adair wrote: > > > >>Your biggest issue is not the top surface area for the resistor site > >>but the via space and extra routing needed to connect resistors. The > >>vias especially will have significant routing effects. Even using a > >>microvia blocks the path for potentially an extra signal. Conventional > >>vias block 2 traces worth in our standard technology. BGA resistor > >>packs whilst small tend not to have a good run of routing them and > >>generally increase layer count to achieve the end result. > >> > >>John Adair > >>Enterpoint Ltd. > > > > > > Depends on what is being routed, of course. > > > > In this particular application, the signal can go in and out very > > easily (1 track between balls for each ball position) and no vias at > > all are required. > > > > In a parallel termination case, things are different, but for a series > > terminator, the devices I have used work just fine with no extra layer > > count required. Indeed, the part manufacturers are aware of the issue > > that saving space for the package but providing poor access negates any > > advantage of the package size, so parts are appearing that have decent > > routing ability. > > > > Cheers > > > > PeteS > > > > > > > >>PeteS wrote: > >> > >>>John Adair wrote: > >>> > >>>>Standards like SSTL are good for this due to the low signal swing. The > >>>>biggest decision is if to use DCI which burns more power in the V4 or to use > >>>>external resistors which take board area and make routing more difficult. > >>>> > >>>>The other decision is weither you use source synchronous clocking or a > >>>>common clock approach. At 150 Mhz the common clock is slightly marginal > >>>>depending on how long tracks are, speed grade, etc. unless you use some DCM > >>>>based techniques. You can generate a clock that is offset from the common > >>>>clock a little by using a DCM and use that as clock for register input to > >>>>gain more time. Alternatively you can use a DCM to null out the clock to > >>>>output time and get more margin from that. > >>>> > >>>>John Adair > >>>>Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development > >>>>Board. > >>>>http://www.enterpoint.co.uk > >>>> > >>>> > >>>>"Marc Reinig" <Marco@newsgroups.nospam> wrote in message > >>>>news:44bc1fed@darkstar... > >>>> > >>>>>I have a project where I will have a large array of V4 FPGAs. Each chip is > >>>>>intended to connect to its four orthogonal neighbors with no intervening > >>>>>logic. I would like the number of bus connections between chips in any > >>>>>direction in the array to be 150 (600 total I/O per chip). The connections > >>>>>will be bi-directional. The distance between chips will be the minimum I > >>>>>can have with sockets, heat sinks (with individual fans), good layout and > >>>>>noise control. Some of the lines, what ever is necessary, will be used for > >>>>>clock and framing for the bus data signals. I would like to use DDR. > >>>>>During bus transfers, all the lines on opposite sides of the chip will be > >>>>>operating and the other two sides will be quiescent. I'm hoping for a bus > >>>>>clock of 150 MHz. > >>>>> > >>>>> > >>>>>Comments? ;=) > >>>>> > >>>>>Marco > >>>>>________________________ > >>>>>Marc Reinig > >>>>>UCO/Lick Observatory > >>>>>Laboratory for Adaptive Optics > >>>>> > >>>>> > >>> > >>>If Marc uses SSTL, and uses resistive terminators, I would agree it > >>>takes board space, but I disagree it would make routing significantly > >>>more difficult, except for the sheer number of devices. In a point to > >>>point situation only a series terminator is really required for speeds > >>>up to at least 200MHz / 400Mb/s (I've done it). > >>> > >>>Assuming these busses would be bidirectional, external series resistors > >>>would [arguably, at least] actually be better in reducing EMI and > >>>reflections than just DCI (less power too) assuming the devices are > >>>close together (of the order of perhaps 4 inches or less). Much really > >>>depends on the distance. I've used BGA style resistor packs that cram > >>>more resistors into the device than can be done in multipack type SMT > >>>devices. Apart from that, the tiny quad pack devices are particularly > >>>sensitive to even slightly imperfect chip shooters and have a nasty > >>>tendency to crack the resistor, particularly at the ends of the device. > >>> > >>>CTS corp makes a particularly nice range of devices > >>>(http://www.ctscorp.com/components/clearone.asp) [I have no affiliation > >>>with them except for having used the parts in the past]. > >>> > >>>Cheers > >>> > >>>PeteS > > > >Article: 105448
Hallo, I'm working on a interface for TI Delta Sigma Modulator. Following a guide I have developed a sinc^3 filter and decimator in order to have an output of 16 bit, from an input streaming of 1 bit. I have seen the Distributed Arithmetic FIR Filter of Core Generator. There is a way to use it instead of sinc^3 filter to optimize my interface? Many Thanks MarcoArticle: 105449
hi I have problem when opening "old" project file, system.xmp, using XPS 6.3. It seems that "HW_VER" is not set up for each IP for this particular version of EDK. How can we know what is correct (or latest) version of each IPs? thankyou ------------------------------------------------------------------------------------------------------------------------------- PM_SPEC -- Xilinx path component is <C:/EDK> ERROR:MDT - ppc405 (ppc405_i) - C:\Xilinx\Work_July07\system.mhs:159 - PORT TIEC405DISOPERANDFWD not found in mpd. ERROR:MDT - ppc405 (ppc405_i) - C:\Xilinx\Work_July07\system.mhs:167 - PORT TIEC405MMUEN not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:187 - PORT DBGC405DEBUGHALT not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:188 - PORT JTGC405TRSTNEG not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:189 - PORT JTGC405TCK not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:190 - PORT JTGC405TDI not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:191 - PORT JTGC405TMS not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:192 - PORT C405JTGTDO not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\r\system.mhs:193 - PORT C405JTGTDOEN not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:194 - PORT RSTC405RESETSYS not found in mpd. ERROR:MDT - jtagppc_cntlr (jtag_cntl) - C:\Xilinx\Work_July07\system.mhs:196 - PORT HALTNEG not found in mpd. ERROR:MDT - ppc405 (ppc405_i2) - C:\Xilinx\Work_July07\system.mhs:306 - PORT TIEC405DISOPERANDFWD not found in mpd. ERROR:MDT - ppc405 (ppc405_i2) - C:\Xilinx\Work_July07\system.mhs:314 - PORT TIEC405MMUEN not found in mpd.
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