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
try the File-Start Debug Chain to see if the JTAG is alive at all. From what you wrote I would say either cable is broke or bad contact or the FPGA is fully dead. If cable is OK, the JTAG pins connected then you should see the device in impact no matter the config setting on fpga anttiArticle: 81526
Ken wrote: > Hi folks, > > This question is aimed at those who have created designs including DSP using > a device family containing dedicated arithmetic silicon (e.g. Xilinx > DSP48/18x18s/Altera DSP blocks): > > On what % of designs you have completed did you run out of dedicated > arithmetic blocks and have to implement filters in the main logic fabric? We've some big DSP applications on VirtexIIs with 100% of multipliers or 100% of Ram blocks used (and over 90% of logic used). In VIIs, this sometimes is tricky since they share ressource, and this can put some restrictions on how the blocks (DSP+Ram) can be parameterized to coexist. You may also find difficult to partition the operators between dedicated and logic since the synthesis tool may have a global flag... Manual inference is often the solution. Globally, we've been pleasantly surprised by the routability of very dense arithmetic (DSP) designs (both in Xilinx and Altera parts btw). Last, we're not using (well almost not) ready-made IPs, so we retain control of how the operators are inferred (and which variant), so it's probably a safer situation. Bert CuzeauArticle: 81527
"anony" <none@nowhere.net> wrote in message news:A4N0e.2320$zl.563@newssvr13.news.prodigy.com... > So is it just a matter of time before a lot of the > FPGA-jobs/employment migrate overseas? > That all depends on where you live! Syms.Article: 81528
"che_fong" <che_fong@netzero.com> wrote in message news:1111786662.899977.24100@g14g2000cwa.googlegroups.com... > > > These guys are all biased. When you look at details, they show their > side of the story. Power ? Big deal ! There are other more pressing > issues ! High end FPGAs hardly go in portable devices ! ;-) > Well if you have a " Power ? Big deal ! " attitude, it's gonna be difficult for you to design a portable device with a high-end FPGA. Those of us who know that power _is_ a big deal seem well enough able to do it though. Cheers, Syms.Article: 81529
For whatever reason, I need to be able to initialize the M-RAMs in Altera chips, and I need to do this in a timing simulation, for which I use Modelsim. So I've hacked the stratix_atoms simulation libraries to initialize them, and that works fine. I can start a simulation, look in those memories and everything they have is correct, but now the simulation is incorrect. Anyone know why this might be? Are the columns of the RAM permuted for timing reasons, is it endianness, or anything else? I need to do this with a lot of designs, so setting break points and using the Update Embedded Memories in Quartus' simulator is annoying. Any other suggestions?Article: 81530
"Bob" <nimby1_notspamm_@earthlink.net> wrote: >The first problem is that the LVDS for Spartan 3 is only defined for VCCO of >2.5V. So, a given IOB cannot run LVDS and, for example, LVTTL (3.3V I/O) at >the same time. VCCO only supplies differential drivers the differential receivers run from VCCAUX so I see no reason why you can't have LVDS receivers in a bank with 3.3v VCCO. I have done this without problem but so far only on a prototype. For the OP I suggest you look at an IOB with the FPGA editor and see if you can find a combination of checkboxes to give you what you want. I suspect there isn't but if there is you will have to find out how to make the tools give you what you want.Article: 81531
On Sat, 26 Mar 2005 08:45:26 -0000, "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >If you add the I/O symbols like IBUFGDS_LVDS_25(clock input) or >IBUF_LVDS_25(normal input) to your schematic you will get a proper LVDS >input implementation. With Spartan-3 you will need an external terminating >resistor for input LVDS. For information on buffer types etc look in the >"libraries guide". You will need to dig for the LVDS in particular as text >searching this document does work well for finding a particular I/O standard >buffer type. > >I think you can mix LVDS (input only and not DCI mode) with a 3.3V output >but either check that with your FAE or try in on a development board. I have >done this exactly on a Virtex2-Pro but personally have not tried this >combination on Spartan-3. > What we want to do works fine electrically - we've tried it - but it takes three pins. We have to externally connect the tristate output to one of the LVDS inputs. What I want to do is persuade the ISE compiler to make the connection internally so we can save a pin each time we do this. I think all the required hardware exists inside the S3 I/O cell. What we can't do is get the ISE software to configure it that way. I'm fishing for ideas on that. Thanks, JohnArticle: 81532
"nospam" <nospam@nospam.invalid> wrote in message news:752b4191vjqonk09q53ufd5iltbjpthfap@4ax.com... > "Bob" <nimby1_notspamm_@earthlink.net> wrote: > > >The first problem is that the LVDS for Spartan 3 is only defined for VCCO of > >2.5V. So, a given IOB cannot run LVDS and, for example, LVTTL (3.3V I/O) at > >the same time. > > VCCO only supplies differential drivers the differential receivers run from > VCCAUX so I see no reason why you can't have LVDS receivers in a bank with > 3.3v VCCO. I have done this without problem but so far only on a prototype. > > For the OP I suggest you look at an IOB with the FPGA editor and see if you > can find a combination of checkboxes to give you what you want. I suspect > there isn't but if there is you will have to find out how to make the tools > give you what you want. > > I think you're correct about the LVDS input diff amp running from VCCAUX. However, since VCCAUX is 2.5V (for S3), I wonder if you could still overdrive the 2.5V input stage by the 3.3V topside output fet. It may work, but the long-term reliability may be in question. I'd still like to know why John needs to mix LVDS and a single-ended output. It's probably something evil or illegal ;-O BobArticle: 81533
On Sat, 26 Mar 2005 05:34:11 -0800, "Symon" <symon_brewer@hotmail.com> wrote: >"anony" <none@nowhere.net> wrote in message >news:A4N0e.2320$zl.563@newssvr13.news.prodigy.com... >> So is it just a matter of time before a lot of the >> FPGA-jobs/employment migrate overseas? >> >That all depends on where you live! >Syms. Vagabond! Philip Freidin FliptronicsArticle: 81534
On Sat, 26 Mar 2005 17:04:30 GMT, "Bob" <nimby1_notspamm_@earthlink.net> wrote: > >"nospam" <nospam@nospam.invalid> wrote in message >news:752b4191vjqonk09q53ufd5iltbjpthfap@4ax.com... >> "Bob" <nimby1_notspamm_@earthlink.net> wrote: >> >> >The first problem is that the LVDS for Spartan 3 is only defined for VCCO >of >> >2.5V. So, a given IOB cannot run LVDS and, for example, LVTTL (3.3V I/O) >at >> >the same time. >> >> VCCO only supplies differential drivers the differential receivers run >from >> VCCAUX so I see no reason why you can't have LVDS receivers in a bank with >> 3.3v VCCO. I have done this without problem but so far only on a >prototype. >> >> For the OP I suggest you look at an IOB with the FPGA editor and see if >you >> can find a combination of checkboxes to give you what you want. I suspect >> there isn't but if there is you will have to find out how to make the >tools >> give you what you want. >> >> > >I think you're correct about the LVDS input diff amp running from VCCAUX. >However, since VCCAUX is 2.5V (for S3), I wonder if you could still >overdrive the 2.5V input stage by the 3.3V topside output fet. It may work, >but the long-term reliability may be in question. > As I said, we did it with an external connection, and it worked great. Our only problem is the danged compiler. If you look at figure 1 of the DS099-2.pdf thing, it sure looks like all the wires I want are there. In fact, if we can take this diagram literally, the ttl tristate driver is already connected to one pin of the LVDS receiver. >I'd still like to know why John needs to mix LVDS and a single-ended output. >It's probably something evil or illegal ;-O Both. It's so terrible that if I told you, The Authorities would take away my slide rule. JohnArticle: 81535
"Bob" <nimby1_notspamm_@earthlink.net> wrote: >I think you're correct about the LVDS input diff amp running from VCCAUX. >However, since VCCAUX is 2.5V (for S3), I wonder if you could still >overdrive the 2.5V input stage by the 3.3V topside output fet. It may work, >but the long-term reliability may be in question. I doubt it is a problem. If you look at the simplified IOB schematic all receiver styles appear to be connected to the pin regardless of the pin being configured as in or out with whatever standard. I can only assume all receivers can take the worst a pin can output. The pin clamp diode is connected to VCCO. The datasheet absolute maximum input voltage ratings are specified in relation to VCCO only (apart from dedicated pins which appear to run from VCCAUX).Article: 81536
John Larkin wrote: >I think all the required hardware exists inside the S3 I/O cell. What >we can't do is get the ISE software to configure it that way. I'm >fishing for ideas on that. I've done similar things in the past by: Compiling the design. Converting to XDL. Edit the XDL with a script (Perl would be a good choice) Build the design. Type XDL at a command prompt. "XDL is also a fully featured Physical Design language that provides direct read and write access to Xilinx's proprietary Native Circuit Description (NCD). This access enables all users to write tools to address their individual FPGA design needs." Another method is to use FPGA_editor to create a hard macro, and put this into your design. This probably requires two wrapper files, one for simulation and one for synthesis. -- Phil Hays Phil-hays at posting domain (- .net + .com) should work for emailArticle: 81537
Hi first - I am a very Xilinx biased (possible because I have way more Xilinx boards) but the latest Quartus seems really easy and in some cases better than X tools (at least the built in programmer is FASTER to use than impact) Story: After getting a nice application tested on Xilinx FPGA I just out of curiosity tried to port to Altera devices, the only problem I had was related to lack of documentation on the cyclone_jtag and maxii_jtag, after solving those the original xilinx code compiled without changes and worked too :) http://wiki.openchip.org/index.php/OpenChip:FpgaFreqMeter after first success with Cyclone, I tried it on MAX2 and worked again :) MAX2 is really nice well its not so much an PLD but more like Xilinx XC2K reinvented and made flash based ;) anyway it is really a heavy player on the flash device arena as the other suppliers Atmel and Lattice are not yet shipping their low-cost flash FPGAs AnttiArticle: 81538
Hello,
how do I extend buses in Quartus Schematic Editor?
Say, for instance, there is an input "phase_offset[23..0]"
and a component which expects a 32-bit wide vector.
I would like to map phase_offset to the upper 24 bits
of the vector and hardwire the remaining bits to 0.
In VHDL it would be:
[...] port map (vec => phase_offset & "00000000") [...]
For non-constant data I have already figured it out:
1. Create a bus using the Orthogonal Bus Tool;
2. Select the bus and then in its properties fill the
"name" field with e.g. shifter_out[29..14], phase_out[15..3].
However, it does not work with constants.
My attempt: phase_offset[23..0],0,0,0,0,0,0,0,0
Quartus: Error: Node "0" is missing source
My attempt: phase_offset[23..0],"00000000"
Quartus: Error: Illegal wire or bus name phase_offset[23..0],"0000000" of
type signal
My attempt: use the megafunction wizard to insert a constant
by the name of "Z" and value 0, then write
phase_offset[23..0],Z,Z,Z,Z,Z,Z,Z,Z
Quartus: Error: Node "Z" is missing source.
So then, how should I express my intentions? :-)
Best regards
Piotr Wyderski
Article: 81539Antti Lukats wrote: > try the File-Start Debug Chain to see if the JTAG is alive at all. >From what you wrote I would say either cable is broke or bad contact or the FPGA is fully dead. If cable is OK, the JTAG pins connected then you should see the device in impact no matter the config setting on fpga > > antti I'm pretty sure the FPGA isn't dead; I had it load the factory default configuration from the Platform Flash device and it worked fine. I've tried running the Debug Chain prior to posting my original message, but it seemed the JTAG was okay. Like I said, I'm a beginner to this, but looking online I was somewhat able to figure out how it works and tried making sure the FSM was okay. I tested every transition and they all worked. I didn't try doing the other tests the debug mode gives you though, should I do this? If so, is there a place where I could get a tutorial on how to do so? Thanks a lot for your help. -DGArticle: 81540
Power is important even in non-portable applications. In telecomm applications, which are a major market for fpga's, heat dissipation is a very real problem and determins to some extent how densely racks can be stacked with linecards or similar electronics. Not to mention that no-one likes their power bills to be larger than neccessary. Ljubisa Bajic ATI Technologies --- My opinions do not represent those of my employer "Symon" <symon_brewer@hotmail.com> wrote in message news:<42456556_2@x-privat.org>... > "che_fong" <che_fong@netzero.com> wrote in message > news:1111786662.899977.24100@g14g2000cwa.googlegroups.com... > > > > > > These guys are all biased. When you look at details, they show their > > side of the story. Power ? Big deal ! There are other more pressing > > issues ! High end FPGAs hardly go in portable devices ! ;-) > > > Well if you have a " Power ? Big deal ! " attitude, it's gonna be difficult > for you to design a portable device with a high-end FPGA. Those of us who > know that power _is_ a big deal seem well enough able to do it though. > Cheers, Syms.Article: 81541
Hi Antti, At ALSE, we design all kinds and brands of FPGAs and have been doing so for years and years (the first FPGA I dealt with was a XC2000 under XDE,- 17? years ago-). Until less than two years ago, we did design more Xilinx than Altera parts (we respect the customer's decision when he wants a particular device or family). And ISE is based on a technology (Synario & ECS) that I supported even before it had a name -and I more than liked this tool, still use it occasionnally-. When Quartus was launched, it was terrible, and stayed that way for a while. However... IMO and backed up by concrete experience, I would say that the progress made by Altera with Quartus tools (and devices) over the last two years has been tremendous and probably gone very much unnoticed, until recently. Quartus II has progressed a lot, and it's not over... The new device architectures (like MaxII) are as surprising as they prove efficient concretely. We love the Cyclone family : cheap, extremely low power and they are usually faster than the usual applications require even in their lowest speed grades. - As of tool quality, I keep my fingers crossed, but I don't fear loading the latest QII release (even beta) and start using it right away in the middle of challenging designs. I usually let other tools "ripe" a bit. - As of integrated synthesis, both for QOR and language coverage (VHDL) I won't comment, by fear of offending third party tools vendors. I've witnessed 30% smaller designs with QII v4.2 as compared with older versions, and I have problem with standard descriptions with XST which are perfectly supported by QII now. There are still a few things I would like to see added in QII (like character'pos), but they should be in 5.0 or 5.1 and I stopped asking for VHDL QOR improvement. - QII's Static Timing Analysis + constraint-driven P&R + Physical synthesis are impressive. Most FPGA users need to be educated in order to take advantage of it. Physical synthesis can for example fix design errors by automatically compensating data or clock delays, it can precisely adjust delays for SDRam interfaces, etc... I'm not saying other tools don't have this technology, just that users are often unaware that it's in Quartus II. - Tcl/Tk and command-line tools are so easy to use ! (you find a Tcl console in almost all tools now -yes: ModelSim too : just type parray env-). You can build and download an FPGA with a single double click on a batch file and never see the GUI if you want to, with a trivial script. This contributes greatly to the ease of use of our Tornado FPGA Board and Tornado Education Kit. - SoPC is probably the strongest advantage I see as of now for Altera. The NIOS II processor, the Avalon switch fabric, and the Tools around them have proved their value. I know several companies even purchased the NIOS license... for ASICs. - RTL and Technology graphical Views are very decent, and the cross-probings between all the different descriptions is handy when investigating. - The Constraints Editor, initially clumsy, is now very powerful & versatile. You can for example easily import export CSV pin assignments (with PCB tools or Excell). It is well organized and easy to use. - The GUI commands have their immediately visible Tcl counterpart, so it's a trivial task to automate even the most complex settings. When we deliver an FPGA design to a customer, we only have HDL source files and a single "does-it-all" Tcl script (which also includes the pin & other assignments). - SignalTap and InSystem Memory Contents Editors are _VERY_ easy to use (and cheap if not free). - LogicLock makes floorplanning (almost) easy when the need comes. - JTag (Jam) player is nice in some cases. Not sure Xilinx has the equivalent public code. (well probably) - I think the cost is lower for the full version of QII compared with Foundation and equivalent options (ChipscopePro) but prices move often. - It's very easy to integrate other tools within QII, or to integrate QII inside other tools. I don't think any other tool is as open as QII. - OpenCore IP protection scheme is clever. It lets you play with IPs as you please. The megawizzard is also easy to use. - Power estimation in 4.2 is now simple to use, both as an early tool, then along when the design gets refined. - Early estimators, and fast assignment verifiers, Design assistant, Performance advisors definitely make the designer's life easier. - Never used DSE nor distributed computing (hope I won't have to), but I know it's there. - More new features are announced. As far as I know, Altera bought a couple of small but very brilliant companies that are behind these technology leaps. On the minus side for Altera I would mention : - Truly incremental P&R is coming, but still not quite here yet. Many users are impatient (it will be welcome for the big chips). - For simple designs : Analysis & Elaboration must be run in order to view the hierarchical dependencies (ISE does this automatically), not a real issue but it's a bit unexpected for ISE users when they try QII. For big designs, you don't let the tool guess what it should compile and in which order; we use scripts. It's very easy to use Quartus II and simply not unleash its power even when you need it. That's why we made efforts to build and offer (with lots of help from Altera) an extensive 2-days Training course in France, and we get an excellent feedback on it. What we try to say to our customers is that Quartus II now deserves spending some time learning its many features and capabilities. For simple things, not much if anything at all is necessary (a batch file can do everything), but challenging tasks will be much simpler with a good understanding of the engine under the hood. --- As of Xilinx, I haven't tested 7.1 yet. Has anyone feedback & experience to share ? Obviously, we don't fear designing Xilinx chips (we design mostly very complex applications now) and ISE is easy to use. Besides the lack -as far as I know- of easy and well documented scripting (Tcl/tk), my worst grief is that it's way too easy to have the focus on the wrong design entity :-) This feature didn't exist in Synario, and it was much less error-prone. Definitely minor, but irritating. With QII, you can change your focal point, but you can't do it without noticing. VHDL synthesis (XST) has also some issues and weaknesses, and I sometimes have to partially rewrite some of our IPs for this reason (I complained a couple of times about poor support for qualified expressions for example). I find Impact's look and use a bit clumsy and old-looking, but it works. I guess it has been improved in 7.1. I also hope they removed or rewrote these offending VHDL "examples" !!! (like j2c_vhd on top of my head). On the X. side, I found Xilinx Tech Support outstanding (maybe only ModelSim's does impress me even more). I loved ECS in Synario and first ISE versions, with the generic symbol library and all the cool utilities related with HDL, but I don't like what it became in the latest versions of ISE. But schematic editors are usually a matter of personal taste (I'm not a huge fan of QII's schematic editor either) and we don't use them much if at all (top levels only, if we find enough motivation). If you plan to stay with Xilinx, don't start using Quartus ;-) Things are very cyclic in this industry, so I expect an effort from the competition to regain the lost terrain. It makes things interesting for us to watch. The good news are that the end-user is usually the winner on the end, with powerful and affordable tools and devices. But high-end FPGAs and applications are bringing us lots of challenges : high level descriptions and modelling, ABV, high-speed design, power issues, P&R challenges, IPs reuse, collaborative design... we'll see. Bert Cuzeau --- The opinions above are my own only. --- I may be wrong on some issues. --- If you think so, or believe I am unfair in any way, let me know. Antti Lukats wrote: > Hi > > first - I am a very Xilinx biased (possible because I have way more Xilinx > boards) > but the latest Quartus seems really easy and in some cases better than X > tools > (at least the built in programmer is FASTER to use than impact) > > Story: > After getting a nice application tested on Xilinx FPGA I just out of > curiosity > tried to port to Altera devices, the only problem I had was related to lack > of documentation on the cyclone_jtag and maxii_jtag, after solving those > the original xilinx code compiled without changes and worked too :) > > http://wiki.openchip.org/index.php/OpenChip:FpgaFreqMeter > > after first success with Cyclone, I tried it on MAX2 and worked again :) > > MAX2 is really nice well its not so much an PLD but more like > Xilinx XC2K reinvented and made flash based ;) anyway it is > really a heavy player on the flash device arena as the other > suppliers Atmel and Lattice are not yet shipping their low-cost > flash FPGAs > > Antti > > > >Article: 81542
Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s) board
for a class project to investigate the use of FPGA arrays for accelerating
scientific competition. The idea was to have a 66 MHz 16-bit
single-ended shared TX bus sending 125 MBps to each FPGA, and a shared 66
MHz 16-bit data aggregation bus where a bus controller would poll each
FPGA sequentially to place its output data onto that bus.
After discussions with some signal-integrity-leery friends, I'm no longer
convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended buses is
such a good idea. I've been reading the various datasheets on doing LVDS
and DDR signaling. Multidrop LVDS is still a bit tricky, evidently, but to
cut down on trace number I might be able to go to 125 MHz DDR 4-pair LVDS
for the TX bus; the problem I'm having is with the data aggregation bus.
Could the aggregate data bus be structured in a similar manner, with:
a.) all FPGAs connected to the 4 DDR LVDS pairs?
b.) a single master, with a separate output enable line to each of the 20
FPGAs
Such that when FPGA n is output-enabled, it would drive it's m nibbles of
data onto the output aggregation bus. But this would require FPGA n to
drive its pins within 4 ns; this sounds nearly impossible.
Are there any common solutions I'm missing? One thought was to aggregate
all of the data from the FPGAs via dedicated serial links and do clock
recovery at the bus master; this would require recovering 20 separate
clocks, alas, and with the spartan 3s we don't have quite that many DCMs.
An obvious solution is "do an IBIS simulation, duh" but we don't
have access to the sort of high-end signal integrity simulation software
that this would require.
Can anyone with spartan-3 serial interconnect experience offer
suggestions as to how to make this work, either through different
LVDS configurations or interconnect topolgies?
Thanks for any advice you
can give,
...Eric
Article: 81543Eric wrote: > Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s) board > for a class project to investigate the use of FPGA arrays for accelerating > scientific competition. The idea was to have a 66 MHz 16-bit > single-ended shared TX bus sending 125 MBps to each FPGA, and a shared 66 > MHz 16-bit data aggregation bus where a bus controller would poll each > FPGA sequentially to place its output data onto that bus. > > After discussions with some signal-integrity-leery friends, I'm no longer > convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended buses is > such a good idea. I've been reading the various datasheets on doing LVDS > and DDR signaling. Multidrop LVDS is still a bit tricky, evidently, but to > cut down on trace number I might be able to go to 125 MHz DDR 4-pair LVDS > for the TX bus; the problem I'm having is with the data aggregation bus. > > Could the aggregate data bus be structured in a similar manner, with: > a.) all FPGAs connected to the 4 DDR LVDS pairs? > b.) a single master, with a separate output enable line to each of the 20 > FPGAs > > Such that when FPGA n is output-enabled, it would drive it's m nibbles of > data onto the output aggregation bus. But this would require FPGA n to > drive its pins within 4 ns; this sounds nearly impossible. Howdy Eric, I don't think it necessarily would be, except that there is no telling how long it will take all the reflections to settle out (highly dependant upon PCB routing). One way to cut down on all the reflections would be to put a weak termination pull resistor, or maybe AC-termination, at every couple FPGA's. Don't use the built in pull resistors - you can't tune tune them, and they are too weak to be used as anything as a pure weak pull up/down. But too much termination will affect rise time. > Are there any common solutions I'm missing? One thought was to aggregate > all of the data from the FPGAs via dedicated serial links and do clock > recovery at the bus master; this would require recovering 20 separate > clocks, alas, and with the spartan 3s we don't have quite that many DCMs. > [...] You haven't said how many spare pins the aggregator FPGA will have, but my first thought was to do as you mention and use dedicated serial links for each FPGA, but without the clock recovery. Instead, just keep the whole board synchronous: distribute the clock so that it reaches every FPGA at the same time and put the aggregator FPGA in the middle. Use the IOB flops for both output and input, and I think you'll have plenty of time left over for PCB data prop delay. Good luck, MarcArticle: 81544
Marc, thanks for the answers! > I don't think it necessarily would be, except that there is no telling > how long it will take all the reflections to settle out (highly > dependant upon PCB routing). One way to cut down on all the > reflections would be to put a weak termination pull resistor, or maybe > AC-termination, at every couple FPGA's. Don't use the built in pull > resistors - you can't tune tune them, and they are too weak to be used > as anything as a pure weak pull up/down. But too much termination will > affect rise time. As I understand it reflections are still a problem with LVDS signalling, so you're right, this could be a problem. If I've got a shared (multidrop) LVDS bus with 20 inputs and one driver, I'm also worried about the input capacitance slowing rise time. Would it be possible to use the DCI on the spartan-3s to help cut down on reflections? > You haven't said how many spare pins the aggregator FPGA will have, but > my first thought was to do as you mention and use dedicated serial links > for each FPGA, but without the clock recovery. Instead, just keep the > whole board synchronous: distribute the clock so that it reaches every > FPGA at the same time and put the aggregator FPGA in the middle. Use > the IOB flops for both output and input, and I think you'll have plenty > of time left over for PCB data prop delay. 20 FPGAs * 4 DDR LVDS Pairs = 160 wires, which isn't something I can pull off with any components I can solder by hand. :( Plus this configuration is a bit of overkill, as I really only need ~125 MB/sec aggregate bandwidth (I'm reusing a gigabit ethernet design I did for off-board IO... UDP/IP in vhdl isn't fun, but it's fast). I agree that keeping things synchronous would be best, but then I get worried about the combined effects of propagation delay and clock skew, which would seem to easily swamp the 4 ns window for DDR 125 MHz. Is there any way to use the DCMs on the Spartan-3s to help reduce the effects of clock skew across the 20 FPGAs? I have to confess that I've never quite understood how to use the DCMs, even after reading the app notes. Thanks again for all the help, ...EricArticle: 81545
On Sat, 26 Mar 2005 20:24:45 -0500, Eric wrote: > Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s) board > for a class project to investigate the use of FPGA arrays for accelerating > scientific competition. The idea was to have a 66 MHz 16-bit > single-ended shared TX bus sending 125 MBps to each FPGA, and a shared 66 > MHz 16-bit data aggregation bus where a bus controller would poll each > FPGA sequentially to place its output data onto that bus. > > After discussions with some signal-integrity-leery friends, I'm no longer > convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended buses is > such a good idea. I've been reading the various datasheets on doing LVDS > and DDR signaling. Multidrop LVDS is still a bit tricky, evidently, but to > cut down on trace number I might be able to go to 125 MHz DDR 4-pair LVDS > for the TX bus; the problem I'm having is with the data aggregation bus. > > Could the aggregate data bus be structured in a similar manner, with: > a.) all FPGAs connected to the 4 DDR LVDS pairs? > b.) a single master, with a separate output enable line to each of the 20 > FPGAs > > Such that when FPGA n is output-enabled, it would drive it's m nibbles of > data onto the output aggregation bus. But this would require FPGA n to > drive its pins within 4 ns; this sounds nearly impossible. > > Are there any common solutions I'm missing? One thought was to aggregate > all of the data from the FPGAs via dedicated serial links and do clock > recovery at the bus master; this would require recovering 20 separate > clocks, alas, and with the spartan 3s we don't have quite that many DCMs. > How about daisy chaining these dedicated serial lines in some fashion, rather than running them all to the bus master? The output of each non-master FGPA goes to the next non-master FPGA, and only the last one goes to the bus master. This is not without it's intricacies, but certainly worth considering. > An obvious solution is "do an IBIS simulation, duh" but we don't have > access to the sort of high-end signal integrity simulation software that > this would require. > > Can anyone with spartan-3 serial interconnect experience offer > suggestions as to how to make this work, either through different LVDS > configurations or interconnect topolgies? > > Thanks for any advice you > can give, > ...Eric -- PhilArticle: 81546
Hi I assume this not so widely known and most likely has not so much actual use, but in some cases it may be useful to use JTAG pins as general purpose IO, that is to some extent possible with most modern FPGAs. I havent checked actel and lattice for this issue yet, but for Xilinx and Altera its possible some explanation and simple source code for Altera and Xilinx is available http://gforge.openchip.org/projects/jtagasio/ http://wiki.openchip.org/index.php/OpenChip:JTAG_as_IO it is to be noted that even Altera SCAN primitive has 1 versus 2 (in pre V4 Xilinx) USER commands available Altera SCAN primitive is more flexible than the Xilinx one. This is due to the fact that in Altera all 4 JTAG pins can be monitored from FPGA fabric. In case of multi chip chains this allows the SCAN primitive to be used as JTAG debugger or tracer for scan chain troubleshooting (when working with other devices in the chain). Xilinx V4 as of advertized should have this feature too, but I have not verified if it is actually there or in what form it is useable. AnttiArticle: 81547
Why not use LVDS to connect to a central FPGA. Make a data packet header that indicates where data should be routed and where it is from. This way data can route to/from any pair of FPGAs or even multiple FPGAs (broadcast header). This way you have point to point links which are relatively easy to route on your PCB. Depending on your data needs to you can use multiple links to increase data rate or use quadrant, or whatever suits, routing. Usually with LVDS you should consider if you are going to send a clock with the data. Simplest is to send a clock trace pair with the data pair and skew between data and clock is minimised. At your data rates you may be able to use a central, or common, clock approach but watch for the differences in trace lengths causing skew. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Eric" <acetylcholinerd@gmail.com> wrote in message news:pan.2005.03.27.01.24.45.670450@gmail.com... > Hello! I'm trying to build a 20-FPGA (spartan-3s, XC3S400-TQ144s) board > for a class project to investigate the use of FPGA arrays for accelerating > scientific competition. The idea was to have a 66 MHz 16-bit > single-ended shared TX bus sending 125 MBps to each FPGA, and a shared 66 > MHz 16-bit data aggregation bus where a bus controller would poll each > FPGA sequentially to place its output data onto that bus. > > After discussions with some signal-integrity-leery friends, I'm no longer > convinced that a 12"x12" 20 IC board at 66 Mhz with single-ended buses is > such a good idea. I've been reading the various datasheets on doing LVDS > and DDR signaling. Multidrop LVDS is still a bit tricky, evidently, but to > cut down on trace number I might be able to go to 125 MHz DDR 4-pair LVDS > for the TX bus; the problem I'm having is with the data aggregation bus. > > Could the aggregate data bus be structured in a similar manner, with: > a.) all FPGAs connected to the 4 DDR LVDS pairs? > b.) a single master, with a separate output enable line to each of the 20 > FPGAs > > Such that when FPGA n is output-enabled, it would drive it's m nibbles of > data onto the output aggregation bus. But this would require FPGA n to > drive its pins within 4 ns; this sounds nearly impossible. > > Are there any common solutions I'm missing? One thought was to aggregate > all of the data from the FPGAs via dedicated serial links and do clock > recovery at the bus master; this would require recovering 20 separate > clocks, alas, and with the spartan 3s we don't have quite that many DCMs. > > An obvious solution is "do an IBIS simulation, duh" but we don't > have access to the sort of high-end signal integrity simulation software > that this would require. > > Can anyone with spartan-3 serial interconnect experience offer > suggestions as to how to make this work, either through different > LVDS configurations or interconnect topolgies? > > Thanks for any advice you > can give, > ...EricArticle: 81548
Is there any hazard to mix synchronous and asynchronous reset?
I am making an RS232 controller and I generally use asynchronous reset in my
design except in a process that serve to load the control word (indicate
speed, data length, parity...) where I load the control word when reset =
'1' or ctr_load ='1' , like that it load the control word at every reset and
when we ask to reload it by ctrl_load
Regards
Alexis
my code :
decodeur : process(clk,rst)
begin
if rising_edge(clk) then
if ctl_load='1' or rst='1' then
parity_bit <= ctl_word(2);
parity_type <= ctl_word(1);
stop_bit <= ctl_word(0);
case ctl_word(7 downto 5) is
when "000" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_0-1),log2(1843200/frequency_0)));
when "001" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_1-1),log2(1843200/frequency_0)));
when "010" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_2-1),log2(1843200/frequency_0)));
when "011" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_3-1),log2(1843200/frequency_0)));
when "100" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_4-1),log2(1843200/frequency_0)));
when "101" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_5-1),log2(1843200/frequency_0)));
when "110" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_6-1),log2(1843200/frequency_0)));
when "111" => nb_count <=
std_logic_vector(to_unsigned((1843200/frequency_7-1),log2(1843200/frequency_0)));
when others =>
end case;
case ctl_word(4 downto 3) is
when "00" => data_bit <= "00010000";
when "01" => data_bit <= "00100000";
when "10" => data_bit <= "01000000";
when "11" => data_bit <= "10000000";
when others =>
end case;
end if;
end if;
end process decodeur;
Article: 81549
KCL wrote:
> Is there any hazard to mix synchronous and asynchronous reset?
> I am making an RS232 controller and I generally use asynchronous reset in my
> design except in a process that serve to load the control word (indicate
> speed, data length, parity...) where I load the control word when reset =
> '1' or ctr_load ='1' , like that it load the control word at every reset and
> when we ask to reload it by ctrl_load
>
> Regards
>
> Alexis
>
> my code :
>
> decodeur : process(clk,rst)
> begin
>
> if rising_edge(clk) then
> if ctl_load='1' or rst='1' then
Note : the sensitivity list is incorrect : rst should be removed.
Are you sure you want/need to load an input or a register during a reset ?
If ctl_word is internal (registers) as I suspect, why not load asynchronously the
same default value as these registers ? (like from a package)
Are you sure you want/neet to give these registers a special treatment if the rest of
your design has an asynchronous reset ?
Mixing both sync and async reset may (according to the FPGA technology and whether
your reset will use a global or not) not be a good idea. Synchronous reset means
reset will be part of your datapath. It may then add a logic level which isn't always
welcome. You may also prevent some tools from dissolve your global reset if you don't
use it. And you force static timing into analyzing your reset within fmax/Tsu/Th...
Can you explain why you need mixing both and what functionality it allows that not
mixing would prevent ?
btw : the divider decoding might be expressed in a simpler way.
Like in this example (dtmf coder):
------
-- Fclock is a generic parameter = 60E6 for Tornado
constant fDiv_Max : natural := Fclock/(697*64)-1;
subtype IntDiv_t is integer range 0 to fDiv_Max;
type Ftable_t is array (0 to 3) of IntDiv_t;
constant F1table : Ftable_t
:= ( Fclock/(697*64)-1, Fclock/(770*64)-1,
Fclock/(852*64)-1, Fclock/(941*64)-1 );
signal Div1 : IntDiv_t;
signal or input Fsel : std_logic_vector (1 downto 0);
.../...
the decoder is then simply :
Div1 <= F1table(to_integer(unsigned(Fsel)));
which you may register or not, reset or not, load or not etc....
.../...
Using "integer range" for divisors gets rid of the log2 annoyance and corner cases
(it says you need two bits to divide by 2...) and you have either to use math_real
(not always supported at synthesis) or a custom function. 0 is also faster to write
than (others=>'0'), and it means less cumbersome conversions and type conversions.
You must verify that your design rules accept integer ranges (I know some disallow
them, but mines don't).
Obviously, this also means you should have the freq div in the same module as the
UART core to benefit from the integer range (they are ruled out in ports). But that
brings another debated issue of partitioning granularity....
Hope this helps,
Bert
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