Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Apr 1, 8:44=A0am, Koorndyk <kris.koorn...@gmail.com> wrote: > On Mar 31, 7:45=A0pm, wondering.gn...@gmail.com wrote: > > > > > Hi, all. > > > I'm relatively new to the field of digital design, and have completed > > a few FPGA-based designs, successfully integrated and debugged them. > > Writing HDL, using vendor tools and performing simulations have been > > fairly straightforward and within my comfort zone. But now I'm faced > > with the foreign task of debugging some nasty timing problems, and I'm > > realizing how little I understand about some fundamental digital > > design principles, like setup and hold timing, clock skew and jitter, > > and the like. > > > What books and other resources would you recommend for someone who > > needs a better understanding of digital design principles, with a > > special focus on timing concerns? > > > Thanks, > > The Wondering Gnome > > I've found the latest Xilinx Timing Constraints User Guide to be > invaluable. > > www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_c... Thanks for that -- I've also found Xilinx docs to be particularly helpful. But in this case I'm interested in learning about timing considerations from first principles; what are the electrical engineering considerations (so to speak) that I should be aware of, especially with regards to timing. I'm not designing ASICs, but I hope to gain that kind of requisite digital design logic. Any recommendations on that front? Regards, W.G.Article: 139501
Sharan, The DCM requires less area in silicon, thus we can provide more of them. They are digital, and greatly immune to power supply noise (as compared to PLL's). They are a state machine, so a "crummy clock" signal is NOT recommended, as a DCM will have a hard time, where a PLL is commonly used to "clean up" a "crummy clock" in order to make it useful at all. DCM will add totally random, white, broad band jitter, where a PLL will remove high frequency jitter, while adding low frequency jitter (due to its oscillator having very low Q on the silicon). It will also add as jitter any power supply noise present varies the VCO in the PLL. External PLL's may be used with voltage controlled crystal oscillators where the quality of the on-chip PLL oscillator is unacceptable (for example SONET/SDH transmit clock jitter requirements are tough to meet without a very high Q resonantor). PLL and DCM have their uses. We provide a mix of both, and you may precede a DCM with a PLL if you have a "crummy clock" or pass the DCM through the PLL if you wish to remove all nearly all the high frequency jitter components. The DCM also offers precise dynamic phase shifting, which is not so easy to do in a PLL. Use a hammer for nails, and a screwdriver for screws. They are both fasteners. Which is better? Silly question. AustinArticle: 139502
On 1 Apr., 17:36, "Symon" <symon_bre...@hotmail.com> wrote: > PLL's have a higher potential for failures due tu their non-state-machine > behaviour. > > For Example EMI could disturb some clocks getting into a PLL phase > detector and you get a lock loss. Did i miss some braindead engineer's pll design which needs a reset after it got out of lock like the DCM's i know? > Digital DCM's are more tolerant about that and especially if you want > to have deterministic operation that is not component value dependent you > are lost with the PLL. And i also seem to have missed analog PLLs in FPGA's whose process temperature voltage variations violate the specs. > I would always chose a good DCM over analog PLL.- Zitierten Text ausblenden - That's good as long as you can forbid your devices to pick up EMI or any noise on it's clocks and do a preventive restart every minute or so.Article: 139503
austin wrote: > Antti, > > Spartan 3 does not support dynamic reconfiguration. The design of the > memory cells is such that a frame is reset to all zeroes prior to > being written with the configuration. This is the "glitching" that > was referenced. > > Now, Spartan 3A is different, and does not have this reset before > being written behavior. > > I am aware of Recobus, and of their excellent work. I suggest that > the best experience with dynamic reconfiguration will be with > something other than Spartan 3, however. The motivation for Spartan is simple: its cheaper and consumes less power. I was once asked, why to do runtime reconfiguration - and on the argument "we can use a smaller device and save money", I got "but you have to pay more for the according Virtex FPGA". So this was the motivation for using a cheap device and to figure out some fancy workarounds for still supporting partial runtime reconfguration. If you go through the ReCoBus-Builder tutorial (available on www.recobus.de) you will recognize the mentioned "glitching" as an interruption of the video stream running over the reconfigurable resource slots. By using two channels that are displaced by one CLB column (such that there is always a redundant channel), this effect can be easily masked. More on this is in our paper "A Communication Architecture for Complex Runtime Reconfigurable Systems and its Implementation on Spartan-3 FPGAs". One remaining issue is that I/O pins cannot be simply masked. The lesson of this work is that the full "glitchless" reconfiguration feature provided in Virtex FPGAs is not necessary required. But this would require some additional effort in the tools. So let us assume that Xilinx may save 1% of the almost 1 billion USD Virtex market by kicking out all not absolutely required stuff in their high-end devices, then this is 10 million per annum. (OK - not considering the cost for the changes - but still this could be an interesting option for the future) May be I should make a deal with Xilinx: I do the tool for 5 Million per year and Xilinx may save the rest... By then, you follow Austin and take a Spartan 3A. You can request a ReCoBus-Builder version also for this device. Just drop me a mail: info@recobus.de (We provide the tool for free, but only for non-commercial use; this is why you have to explicitly request support for larger Spartan-3 devices or the E/A/AN families. Furthermore, we have no boards with A/AN FPGAs - so its not tested from our side - but I don't expect any major problems.) And if you have already a Spartan-3 board, you may accept "glitches", as we do in our lecture on "Reconfigurable Computing" where students build a partial runtime reconfigurable System on the Spartan-3 FPGA-Board from Digilent in just one evening. Dirk > > If you don't care that the entire frame is set to zeroes before being > written (you can stop what you are doing, and resume), then you can do > what you wish. I suppose this would be just "plain" reconfiguration > (to configure again). > > More to the point, if you call or email with a problem while > dynamically reconfiguring Spartan 3, you will be told that dynamic > reconfiguration is not supported in Spartan 3. > > AustinArticle: 139504
Hi guys, I'm trying to use a MIG v2.3 generated DDRII SRAM controller to verify our hardware for a 36 Mb, x18, Burst length 4, GSI SRAM chip. We're using a Virtex-5 LX110T chip with a 1738 package size. The design passes stage 1 calibration but hangs during stage 2 calibration. The same behaviour is exhibited when running the controller at 250 MHz or 200 MHz. Both the controller and the SRAM chip in question have been verified in simulation (memory test and all calibration stages pass). I had heard that the Xilinx tap controller does not have a large enough window to allow certain devices to operate with worst case datasheet timing... Any thoughts as to what might be occurring? cheers, ColinArticle: 139505
On Apr 1, 10:36=A0am, "Symon" <symon_bre...@hotmail.com> wrote: > "Sharan" <sharan.basa...@gmail.com> wrote in message > > news:6374ea0e-4cdb-474a-9cd6-df68f8252302@v15g2000yqn.googlegroups.com... > > > > > > > Hi, > > > From the datasheets, it is looks like the only major difference > > between DCM and PLL is that PLL additionally does jitter filtering. > > Rest of the features are present in both these macros. So what decides > > whether one should use a PLL or DCM in FPGA. > > > The following are the common features present in both DCM and PLL: > > 1) frequency synth > > 2) deskew > > 3) frequency div > > > Additionally DCM can also do phase shift. > > > Regards, > > Sharan > > PLL's have a higher potential for failures due tu their non-state-machine > behaviour. > > For Example EMI could disturb some clocks getting into a PLL phase > detector and you get a lock loss. > > Digital DCM's are more tolerant about that and especially if you want > to have deterministic operation that is not component value dependent you > are lost with the PLL. > > I would always chose a good DCM over analog PLL.- Hide quoted text - > > - Show quoted text - Haha, It rings the bell about the battle between DLL vs. PLL not long ago. :-) So far, jitter is the only thing I concern about... so who's the winner ?Article: 139506
On 30 mar, 20:46, Andy Ross <andy.ross...@gmail.com> wrote: > I recently bought a Digilent Nexys 2 board, and after a few days of > research got to the point where I can successfully program it over USB > from a Linux host without the use of a separate (and expensive!) JTAG > interface. =A0Google told me even before I purchased the board that this > is a very common requirement; it seems that I'm not the only one > interested in linux-hosted FPGA development. =A0The pieces to make this > work were all there, happily (see the README in the download below for > details -- the chain of responsibility here is long); it just took > work to assemble them correctly. > > For those interested, I wrote a quick perl script to automate the > process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz > [/url] > > This wraps the multi-step mess (device detection/configuration, SVF > generation, and JTAG download) as fully as possible, most importantly > by doing the USB bus enumeration and dynamically reprogramming the > Nexys 2 with a patched usb_jtag firmware blob in the script itself. > The user just specifies the Xilinx bitstream file as the sole > argument. > > Installation is as simple as I could make it, requiring only Xilinx > ISE, two binary packages (fxload and libftdi -- both available via apt- > get on Ubuntu Intrepid) and one source install (UrJTAG -- just a > simple "./configure;make;make install" will do). > > Hopefully this will help other newbies with the learning curve. =A0Let > me know if something doesn't work, or if there are questions. That's great! Any idea if that works for a Nexys (not version 2)? I'm trying to get it working but so far I wasn't able to. The program detects if the cable is present or not, and appears to change the board's firmware somehow, since until the board is powered down, its lsusb output changes from: Bus 007 Device 033: ID 1443:0005 to: Bus 007 Device 034: ID 16c0:06ad VOTI but the program doesn't show anything else. Do you have any idea of what's happening, since it appears both the nexys 1 and 2 have the same programming interface?Article: 139507
Hi, I'd like to control power sockets via an FPGA. Perhaps one of you in this Forum controlled already power sockets from an FPGA. I'm looking for a nice starting point. I have a Spartan 3A starter kit and wondered about an easy way to switch a 230V AC socket. I would be interested in solutions for devices below 100W and devices below 2000W. The laziest option would probably a small power plug / socket with plastic case with all electronic built in and a small connector to connect a controlling low voltage FPGA / TTL signals. Does something like this exist already? Another interesting option would be if anybody knew just a socket / plug in a small plastic box with a small PCB, which has enough space to add the required electronic components. thanks in advance for any suggestions.Article: 139508
On Apr 1, 2:23=A0pm, Ronan Paix=E3o <ronanpai...@yahoo.com.br> wrote:
> Do you have any idea of what's happening, since it appears both the
> nexys 1 and 2 have the same programming interface?
The script was written specifically for the Nexys 2, as obviously
that's all I have available to test with and I'm still new enough at
this stuff (FPGA work, not software development, that is) that I'm
more likely to hurt things than help by guessing at inappropriate
abstractions. But looking really briefly at the schematics, it seems
like it should work in principle. The JTAG pinout on the FX2 chip
looks identical, and obviously you're seeing the firmware reload work
successfully.
First off, run the script with a "-v" to enable verbose mode and see
what the underlying error is.
The one thing I see that will need to be changed is the path to the
BDSL files on line 236; the Nexys has (I think) a Spartan 3, not a 3E,
and Xilinx spreads these files out all over their tree. Try this:
--- nexys2prog
+++ nexys2prog
@@ -233,7 +233,7 @@
sub play_svf {
open JTAG, ">$TMPID.jtag" or die "cannot write to $TMPID.jtag";
# Just the BSDL directories needed for the 2 chips on the
Nexys2...
- print JTAG "bsdl path $XILINX/spartan3e/data;$XILINX/xcf/data\n";
+ print JTAG "bsdl path $XILINX/spartan3e/data;$XILINX/spartan3/
data;$XILINX/xcf/data\n";
print JTAG "cable usbblaster\n";
print JTAG "detect\n";
print JTAG "part 1\n";
Another potential gotcha is that the iMPACT script generator is
specifying an XCF04S and not the 02 part that seems to be on the
Nexys. But as this is just being fed a bypass command, I can't see
why it would matter. And now that I'm understanding JTAG better, I'm
not sure why this chip needs to be specified at all just to generate
SVF, when the real bypass command is actually done by UrJTAG at
runtime...
Let me know how things work out. Now that I have a better handle on
things and am getting out of the "blind stitchwork" phase, I'm
starting to think about nicer interfaces. One thing to note is that a
Xilinx bitstream file embeds its part identifier, so there's really no
need to know anything about the board design a priori -- we could just
scan the JTAG bus for a matching part number, regardless of where it
lives on the chain, and program that. Likewise extending the FX2
interface to handle other known FX2 parts (the KNJN Saxo boards, which
I almost bought, or the Digilent cable), or even arbitrary JTAG
interfaces that can be detected, is possible.
Then again, the whole point here is to allow me to play with FPGAs and
learn something, not do tool integration that won't teach me anything
new. :)
Article: 139509I am trying to optimize some code and I am examining parts of the resulting logic in the Lattice design editor, EPIC. When I look at the details of a slice in the logic block editor it provides details for the LUT data when in logic mode. But when in ripple mode, specifically CC2 mode, it doesn't provide logic equations. You can examine the "Logic Strings" which seem to provide all the info for the entire slice configuration including the LUT data. The part that controls the LUT seems to be: CCU2::S0=0x5006,S1=0x3006:INJECT1_0=NO,INJECT1_1=NO When I try to match the LUT contents (0x5006 and 0x3006) to the inputs, I can't seem to find a match that makes sense. I am thinking I am missing something important in this. I am expecting the LUT to be used intact even though only three inputs are used, A, B and Cin (D). I expect the output to be an Exclusive OR of all three inputs. But the logic string doesn't seem to be that and they are different for the two LUTs in a slice. So what am I missing? When searching for CC2 on the Lattice site, I did find some mention that instead of generating a carry, the slice generates signals propagate and generate for "fast carry" operation. But I don't see any sign of this in EPIC. The adder is connected as a typical ripply carry chain with one carry in and one carry out between slices. I am looking at this, because sometimes other logic seems to be combined with the adder LUT and I want to understand what they are doing. RickArticle: 139510
On Apr 1, 11:04=A0am, wondering.gn...@gmail.com wrote: > On Apr 1, 8:44=A0am, Koorndyk <kris.koorn...@gmail.com> wrote: > > > > > On Mar 31, 7:45=A0pm, wondering.gn...@gmail.com wrote: > > > > Hi, all. > > > > I'm relatively new to the field of digital design, and have completed > > > a few FPGA-based designs, successfully integrated and debugged them. > > > Writing HDL, using vendor tools and performing simulations have been > > > fairly straightforward and within my comfort zone. But now I'm faced > > > with the foreign task of debugging some nasty timing problems, and I'= m > > > realizing how little I understand about some fundamental digital > > > design principles, like setup and hold timing, clock skew and jitter, > > > and the like. > > > > What books and other resources would you recommend for someone who > > > needs a better understanding of digital design principles, with a > > > special focus on timing concerns? > > > > Thanks, > > > The Wondering Gnome > > > I've found the latest Xilinx Timing Constraints User Guide to be > > invaluable. > > >www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_c... > > Thanks for that -- I've also found Xilinx docs to be particularly > helpful. But in this case I'm interested in learning about timing > considerations from first principles; what are the electrical > engineering considerations (so to speak) that I should be aware of, > especially with regards to timing. I'm not designing ASICs, but I hope > to gain that kind of requisite digital design logic. Any > recommendations on that front? > > Regards, > W.G. If you're looking for first principles, it sounds like you want a digital circuit design book. I've never looked at any besides the one I used in undergrad (Rabaey) but if you search "digital circuit design" at Amazon or your library you'll have lots of options. Class notes posted online are also a good place to start. Cheers, MikeArticle: 139511
Can your FPGA send packets? http://www.digital-loggers.com/lpc.htmlArticle: 139512
On Apr 2, 9:46=A0am, News123 <news...@free.fr> wrote: > The laziest option would probably a small power plug / socket with > plastic case with all electronic built in and a small connector to > connect a controlling low voltage FPGA / TTL signals. > > Does something like this exist already? > > Another interesting option would be if anybody knew just a > socket / plug in a small plastic box with a small PCB, which has enough > space to add the required electronic components. > > thanks in advance for any suggestions. Remote Controlled mains Outlets perhaps ? Certainly isolates your FPGA from the Mains!Article: 139513
On Apr 1, 7:09=A0pm, rickman <gnu...@gmail.com> wrote: > > I am looking at this, because sometimes other logic seems to be > combined with the adder LUT and I want to understand what they are > doing. > > Rick I added KEEP attributes to force the logic to be distributed the way I intended and added a register to the output of the adder. The register seems to have been moved to the other side of the adder so that the inputs to the adder are being registered. I guess the tool is free to do that, but when I added a timing constraint to the output of the adder, rather than move the register to where I asked for it, the tool just reports a timing violation! Do I have to add special attributes to get the register where I want it so that it meets timing constraints? RickArticle: 139514
Andy, Sure hope this works. I'm tried of having to reboot into windows to burn code into my boards. Does this reprogram the 8051? Does that mean if I use it I cannot go back and use the digilent adept software? John Eaton Andy Ross wrote: > I recently bought a Digilent Nexys 2 board, and after a few days of > research got to the point where I can successfully program it over USB > from a Linux host without the use of a separate (and expensive!) JTAG > interface. Google told me even before I purchased the board that this > is a very common requirement; it seems that I'm not the only one > interested in linux-hosted FPGA development. The pieces to make this > work were all there, happily (see the README in the download below for > details -- the chain of responsibility here is long); it just took > work to assemble them correctly. > > For those interested, I wrote a quick perl script to automate the > process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz > [/url] > > This wraps the multi-step mess (device detection/configuration, SVF > generation, and JTAG download) as fully as possible, most importantly > by doing the USB bus enumeration and dynamically reprogramming the > Nexys 2 with a patched usb_jtag firmware blob in the script itself. > The user just specifies the Xilinx bitstream file as the sole > argument. > > Installation is as simple as I could make it, requiring only Xilinx > ISE, two binary packages (fxload and libftdi -- both available via apt- > get on Ubuntu Intrepid) and one source install (UrJTAG -- just a > simple "./configure;make;make install" will do). > > Hopefully this will help other newbies with the learning curve. Let > me know if something doesn't work, or if there are questions.Article: 139515
I'm pretty sure that the Digilent 8051 code is loaded from flash at power-up and this process reloads new open-source code from USB which is lost at the next power down or reset. You should be OK using this with Adept as long as you cycle power. Eric On Apr 1, 9:40=A0pm, John Eaton <nos...@spam.com> wrote: > Andy, > > Sure hope this works. I'm tried of having to reboot into windows to burn > code into my boards. > > Does this reprogram the 8051? Does that mean if I use it I cannot go > back and use the digilent adept software? > > John Eaton > > Andy Ross wrote: > > I recently bought a Digilent Nexys 2 board, and after a few days of > > research got to the point where I can successfully program it over USB > > from a Linux host without the use of a separate (and expensive!) JTAG > > interface. =A0Google told me even before I purchased the board that thi= s > > is a very common requirement; it seems that I'm not the only one > > interested in linux-hosted FPGA development. =A0The pieces to make this > > work were all there, happily (see the README in the download below for > > details -- the chain of responsibility here is long); it just took > > work to assemble them correctly. > > > For those interested, I wrote a quick perl script to automate the > > process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz > > [/url] > > > This wraps the multi-step mess (device detection/configuration, SVF > > generation, and JTAG download) as fully as possible, most importantly > > by doing the USB bus enumeration and dynamically reprogramming the > > Nexys 2 with a patched usb_jtag firmware blob in the script itself. > > The user just specifies the Xilinx bitstream file as the sole > > argument. > > > Installation is as simple as I could make it, requiring only Xilinx > > ISE, two binary packages (fxload and libftdi -- both available via apt- > > get on Ubuntu Intrepid) and one source install (UrJTAG -- just a > > simple "./configure;make;make install" will do). > > > Hopefully this will help other newbies with the learning curve. =A0Let > > me know if something doesn't work, or if there are questions.Article: 139516
stephen.craven@gmail.com wrote:
> Though a long-time Xilinx user, I have yet to try partitions or the
> updated smartguide feature. I would appreciate your thoughts on these
> features. Which is best at reducing runtime?
I like simulation.
It doesn't reduce synthesis time,
just the number of repetitions required.
-- Mike Treseler
Article: 139517Thanks for your answer. Basically I'd like that the FPGA does what the box in your URL is doing, but without an ethernet protocol. As means of communication is was looking for ideally a single GPIO signal / or at least nothing more complex than a One-Wire / I2C protocol. Symon wrote: > Can your FPGA send packets? > http://www.digital-loggers.com/lpc.html > >Article: 139518
Hi JG, -jg wrote: >> >> thanks in advance for any suggestions. > > Remote Controlled mains Outlets perhaps ? > Certainly isolates your FPGA from the Mains! In fact I was more thinking about the FPGA being next to the socket and having a simple wired communication. On the other hand: remote controlled would also be interesting. Are there any good, not too expensive sets of remote controlled main outlets (for 230V Europe) where it would be easy to control the transmission unit via the FPGA? preference for wireless protocol wuld then be Zigbee, but the 433 MHz protocols would be OK as well.Article: 139519
Hello, I want to use the XC95144XL CPLD to switching paralell video buses up to 165Mhz frequency. The logic has only combinatorial parts and there are no feedbacks from the macrocells output to the FastConnectII inputs. It's very important that the signals must have the same delays but I'm a bit confused with the delays and the timing modells. I don't use registers or any feedback in my configuration, so I'm pretty sure that Fsystem is irrelevant to me. The combinatorial delays are given as Tpdi for different speed grades, but I'm not sure wether this delay is uniform or not. My Pterms have the same configurations in all FBs due to the symmetrical topology. Will it work with a 10 (lowest) speed grade CPLD or not? Shall I use a faster (and a much more expensive) version or not? What will be the order of jitters between the paralell signals? Thank you for the answers David PS: timings are available at http://www.xilinx.com/support/documentation/data_sheets/ds056.pdf p5-p6Article: 139520
On Apr 2, 11:12=A0am, David Fejes <fej...@gmail.com> wrote: > Hello, > > I want to use the XC95144XL CPLD to switching paralell video buses up > to 165Mhz frequency. The logic has only combinatorial parts and there > are no feedbacks from the macrocells output to the FastConnectII > inputs. > It's very important that the signals must have the same delays but I'm > a bit confused with the delays and the timing modells. > > I don't use registers or any feedback in my configuration, so I'm > pretty sure that Fsystem is irrelevant to me. The combinatorial delays > are given as Tpdi for different speed grades, but I'm not sure wether > this delay is uniform or not. My Pterms have the same configurations > in all FBs due to the symmetrical topology. > > Will it work with a 10 (lowest) speed grade CPLD or not? Shall I use a > faster (and a much more expensive) version or not? What will be the > order of jitters between the paralell signals? > > Thank you for the answers > David > > PS: timings are available athttp://www.xilinx.com/support/documentation/d= ata_sheets/ds056.pdf > p5-p6 have you looked the CPLD output signals at 165MHz with a good DSO? I have. For a project where it was important to generate 120mhz phase shifted clocks with an CPLD. as much as i recall i did not like the cpld output waveforms what i observed. running parallel 165mhz datapaths via XC95 doesnt sound like a good idea but maybe i am wrong, has happened b4 AnttiArticle: 139521
Hi all, Iam using Xilinx XST for synthesis. Iam using almost 20 modules in my design. each if i synthesize seperately iam getting a maximum frequency of more than 400 Mhz. But when i combine everything iam getting only 121Mhz. Can you tell me the reason...??? Does this mean i cannot use a clock more than 121 Mhz in my design(iam using and found it working well..) How can i increase my timing for high frequencies..?? Iam providing the synthesis report here. Can you tell me what is the Maximum frequency mentioned here..? Timing Summary: --------------- Speed Grade: -1 Minimum period: 8.226ns (Maximum Frequency: 121.566MHz) Minimum input arrival time before clock: 3.043ns Maximum output required time after clock: 3.281ns Maximum combinational path delay: 2.072ns I want to acheive minimum 400Mhz for my entire design.... Is it possible...? That is my target.... Do comment...Article: 139522
> running parallel 165mhz datapaths via XC95 doesnt sound like a good > idea > but maybe i am wrong, has happened b4 There is a similar application note at the Xilinx webpage in the xapp944.pdf It is true that the maximum frequency of the signals is only 27Mhz in this design and it uses CoolRunnerII instead of XC95, but there is a interesting sentence at the end of the document: ,,All similar signals travel through the same path in the CPLD, so they will emerge from the other side with negligible skew, because of to the deterministic nature of the timing model and architecture." I think it should be true at higher frequencies too, didn't? On Apr 2, 10:18=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Apr 2, 11:12=A0am, David Fejes <fej...@gmail.com> wrote: > > > > > Hello, > > > I want to use the XC95144XL CPLD to switching paralell video buses up > > to 165Mhz frequency. The logic has only combinatorial parts and there > > are no feedbacks from the macrocells output to the FastConnectII > > inputs. > > It's very important that the signals must have the same delays but I'm > > a bit confused with the delays and the timing modells. > > > I don't use registers or any feedback in my configuration, so I'm > > pretty sure that Fsystem is irrelevant to me. The combinatorial delays > > are given as Tpdi for different speed grades, but I'm not sure wether > > this delay is uniform or not. My Pterms have the same configurations > > in all FBs due to the symmetrical topology. > > > Will it work with a 10 (lowest) speed grade CPLD or not? Shall I use a > > faster (and a much more expensive) version or not? What will be the > > order of jitters between the paralell signals? > > > Thank you for the answers > > David > > > PS: timings are available athttp://www.xilinx.com/support/documentation= /data_sheets/ds056.pdf > > p5-p6 > > have you looked the CPLD output signals at 165MHz with a good DSO? > I have. For a project where it was important to generate 120mhz phase > shifted > clocks with an CPLD. as much as i recall i did not like the cpld > output > waveforms what i observed. > > running parallel 165mhz datapaths via XC95 doesnt sound like a good > idea > but maybe i am wrong, has happened b4 > > AnttiArticle: 139523
Hi, The cell BSCAN_SPARTAN3A allows to monitor the jtag input pins TCK, TDI and TMS of a Spartan3A chip. I was curious, whether I would also be able to capture the value of the TDO pin (without soldering or wiring it back to another pin of the 3AN) If yes, what would be the trick? Thanks in advance and byeArticle: 139524
On Apr 2, 1:25=A0pm, fpgauser <klausf...@gmail.com> wrote: > Hi, > > =A0The cell BSCAN_SPARTAN3A allows to monitor the jtag input pins TCK, > TDI and TMS of a Spartan3A chip. > > I was curious, whether I would also be able to capture the value of > the TDO pin (without soldering or wiring it back to another pin of the > 3AN) > > If yes, what would be the trick? > > Thanks in advance and bye No you only know the TDO value IF the TAP is in USER1/USER2 and DRSCAN state but the value is what you shift out, so you would know it anyway... Antti
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