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
<filter001@desinformation.de> wrote in message news:ec6505f4-7051-48e8-b471-6bd5849ded65@q16g2000yqg.googlegroups.com... > On 1 Apr., 16:01, Sharan <sharan.basa...@gmail.com> wrote: > DCM's have a higher potential for failures due tu their state-machine > behaviour. > > For Example EMI could disturb some clocks getting into a DCM locking > up and you need a systen reset. Did i miss some braindead engineer's DCM design which has terrible stability causing it to get out of lock like the PLL's i know? > Analog PLL's are more tolerant about that and especially if you want > to have deterministic jitter-fitering you are lost with the DCM. And i also seem to have missed DCMs in FPGA's whose jitter performance violate the specs. > I would always chose a good analog PLL over DCM.- 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 constantly check the phase lock.Article: 139526
Hi, My own understanding of SSO was that it is to do purely with number of pins switching at the same time. Nothing to do with the rate of switching. The Xilinx virtex 5 datasheet also simply specifies this just in terms of number of permissible IOs that can switch at the same time. But in a recent discussion, when I raised this point I was told that SSO is not an issue at low frequency. So, who is right? RegardsArticle: 139527
On Apr 2, 8:31=A0am, Sharan <sharan.basa...@gmail.com> wrote: > Hi, > > My own understanding of SSO was that it is to do purely with number of > pins switching at the same time. Nothing to do with the rate of > switching. The Xilinx virtex 5 datasheet also simply specifies this > just in terms of number of permissible IOs that can switch at the same > time. But in a recent discussion, when I raised this point I was told > that SSO is not an issue at low frequency. So, who is right? > > Regards You are. AndyArticle: 139528
Ok, From a previous project I have this spectrum digital jtag emulator xds510: http://www.spectrumdigital.com/product_info.php?products_id=29 and for my current project I'm using a xilinx platform cable USB model dlc9G, part number HW-USB-G: http://www.xilinx.com/support/documentation/data_sheets/ds300.pdf I've only used the xds unit with Texa Instruments Code Composer to a DSP, but now I have to set up another development station and I was hoping to use the xds unit with an installation of ISE 10.1 project navigator. Does anybody know if this is OK? I have two of these XDS units sitting around doing nothing, and I'd rather put them into service rather than buy Xilinx's Platform Cable USB II HW-USB-II-G at $225. Sincerely, Jonathan LeslieArticle: 139529
On Apr 2, 6:25 am, fpgauser <klausf...@gmail.com> wrote:
> 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 bye
well, I'm working with enterpoints raggedstone1, and I have the the 4
pins of the jtag readily available to my
top.vhd:
1) my .ucf file:
#-- FPGA pin JTAG signals
#-- WARNING!!!!!! MAKE SURE THESE ARE USED IF YOU
#-- REPROGRAM THE PROMS!!! FAILURE TO DO SO WILL
#-- DISABLE THE JTAG. BRING THESE PINS IN, AND MAKE
#-- A DUMMY OUTPUT FOR THEM.
NET "TCK" LOC = "C11" | IOSTANDARD = LVTTL ;
NET "TDI" LOC = "E11" | IOSTANDARD = LVTTL ;
NET "TDO" LOC = "B20" | IOSTANDARD = LVTTL ;
NET "TMS" LOC = "B11" | IOSTANDARD = LVTTL ;
NET "JTAG_OR_DUMMY" LOC = "T21" | IOSTANDARD = LVTTL ;
and in my top.vhd I've added:
-- preserve the pinouts for the Jtag.
jtag_or_dummy <=
TCK OR
TDI OR
TDO OR
TMS ;
END BEHAVORIAL;
and the those labels to the port.
Article: 139530On Apr 2, 9:51=A0am, Andy <jonesa...@comcast.net> wrote: > On Apr 2, 8:31=A0am, Sharan <sharan.basa...@gmail.com> wrote: > > > Hi, > > > My own understanding of SSO was that it is to do purely with number of > > pins switching at the same time. Nothing to do with the rate of > > switching. The Xilinx virtex 5 datasheet also simply specifies this > > just in terms of number of permissible IOs that can switch at the same > > time. But in a recent discussion, when I raised this point I was told > > that SSO is not an issue at low frequency. So, who is right? > > > Regards > > You are. > > Andy Hold on... Depends how you measure frequency. You can have issues with SSO at any "frequency" if you're talking about the switching rate. However the real culprit is the high frequency component of the switching outputs, i.e. the edge rate. So for low "frequency" edge rates (as in SLEW=3DSLOW for Xilinx), you should have fewer problems with SSO or in fact have a larger number of pins switching to create the same ground bounce. Regards, GaborArticle: 139531
On Thu, 2 Apr 2009 02:36:27 -0700 (PDT), knight <krsheshu@gmail.com> wrote: >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. Synthesis also displays the critical path; the signal which is limiting speed to 121 MHz. Look at this section of the synth report. Most likely it is a path crossing between two (or more) modules. You need to pay attention to these too; possibly adding pipeline stages on your module inputs and outputs. When you synth a module on its own, it may report 400MHz (2.5 ns). But it also reports input and output times as you see below, which may each exceed 2.5 ns. Re-pipeline and re-synth (taking care to synth WITHOUT adding I/O pins!) until < 2.5 ns, then try the top level again. There will still be failures since you need one module's output plus the next module's input to sum to < 2.5 ns. One approach is to keep I/O delays below 1.25ns but this will not generally be possible, and it is unnecessarily conservative (often a slow output will connect to a fast input) >Does this mean i cannot use a clock more than 121 Mhz in my design(iam >using and found it working well..) I'm sure you can easily beat 121 MHz. But getting all the way to 400MHz may be difficult. - Brian > 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.072nsArticle: 139532
On Apr 2, 6:01=A0am, David Fejes <fej...@gmail.com> wrote: > > 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 =A0It 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 delay= s > > > 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/documentati= on/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 > > > Antti > > You may find that the skew is not your problem, but the switching capability of the output drivers in the XC9500 series. Fmax is not just because of clocks, slow output drivers may have reduced output swing and unacceptable rise and fall times at 165 MHz.Article: 139533
With SSO edge rate, current and number of I/O switching at exactly the same time are what is important. It's the inpulse, or step, in current that creates a ground or even a power bounce as current tries to flow through parasitic inductance in lead frames and bond wires etc.. The guidelines are just that and are also affected by things like PCB layout and decoupling as well. Frequency itself does not have effect other than the potential problem happens more or less. Very simple techniques like dithering I/O switch say by offsetting by half a clock (opposite edge clocking) can reduce a potential problem by spreading the current impulse. John Adair Enterpoint Ltd. On 2 Apr, 14:31, Sharan <sharan.basa...@gmail.com> wrote: > Hi, > > My own understanding of SSO was that it is to do purely with number of > pins switching at the same time. Nothing to do with the rate of > switching. The Xilinx virtex 5 datasheet also simply specifies this > just in terms of number of permissible IOs that can switch at the same > time. But in a recent discussion, when I raised this point I was told > that SSO is not an issue at low frequency. So, who is right? > > RegardsArticle: 139534
On Apr 2, 5:09=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > On Apr 2, 6:25 am, 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 > > well, I'm working with enterpoints raggedstone1, and I have the the 4 > pins of the jtag readily available to my > top.vhd: > > 1) =A0my .ucf file: > > #-- FPGA pin JTAG signals > > #-- WARNING!!!!!! =A0MAKE SURE THESE ARE USED IF YOU > #-- REPROGRAM THE PROMS!!! =A0FAILURE TO DO SO WILL > #-- DISABLE THE JTAG. =A0BRING THESE PINS IN, AND MAKE > #-- A DUMMY OUTPUT FOR THEM. > > NET "TCK" =A0LOC =3D "C11" | IOSTANDARD =3D LVTTL ; > NET "TDI" =A0LOC =3D "E11" | IOSTANDARD =3D LVTTL ; > NET "TDO" =A0LOC =3D "B20" | IOSTANDARD =3D LVTTL ; > NET "TMS" =A0LOC =3D "B11" | IOSTANDARD =3D LVTTL ; > > NET "JTAG_OR_DUMMY" =A0 LOC =3D "T21" | IOSTANDARD =3D LVTTL ; > > and in my top.vhd I've added: > > -- preserve the pinouts for the Jtag. > =A0 =A0 jtag_or_dummy =A0 <=3D > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TCK =A0OR > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TDI =A0OR > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TDO =A0OR > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TMS ; > > END BEHAVORIAL; > > and the those labels to the port. those pins are NOT FPGA JTAG pins !! its extra jtag chain connected to FPGA IO, but not to FPGA JTAG AnttiArticle: 139535
NET "CLOCK" TNM_NET = "CLOCK"; TIMESPEC "TS_CLOCK" = PERIOD "CLOCK" 50 ns HIGH 50 %; OFFSET = IN 15 ns VALID 20 ns BEFORE "CLOCK"; OFFSET = OUT 15 ns AFTER "CLOCK"; I believe that this is the correct way to say: 1. I have a 20MHz clock. 2. All inputs are 15 ns SETUP and 5 ns HOLD. 3. All outputs are 15 ns MAXDELAY. Right? It works if the first two lines are commented out, but fails otherwise, even if I set the PERIOD to 500 ns... why? And why is ISE insisting on "HIGH 50 %" when it is an oscillator clock, who cares if it started low or high? Some FFs in my design are using rising_edge, some falling_edge, but any FF has 50ns from edge to edge.Article: 139536
emeb wrote: > 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. Yes, that's exactly right. The FX2 chip has a built-in loader that works irrespective of what the boot configuration was. Once the device reboots (you have to unplug it from the USB bus, it's not controlled by the FPGA power switch) it restreams its firmware from the I2C EEPROM and acts like a Digilent device again. It should be noted that I've only done the integration work here. There were *lots* of people involved in making this work. Here's the relevant section of the README in the package. (One credit that I've since realized I missed is that the usb_jtag firmware is itself based on similar 8051 code from the GNU Radio folks). Xilinx, of course, provides a Linux version of their free (as-in- beer) ISE WebPack product [1]. But Digilent uses a proprietary protocol for their USB interface, and they neither document it nor provide tools other than a (decidedly clunky) Windows GUI [2] to use it. Nonetheless the USB hardware on the device is open. The Cypress FX2 USB chip on the board, which itself is a 8051 microcontroller, is fully programmable from across the USB bus [3] and that interface is supported from linux thanks to the work of the linux-hotplug project [4]. The sdcc project provides a free C compiler [5] for the 8051, which Kolja Waschk used to write a firmware suite named "usb_jtag" [6] for a FX2-based USB/JTAG cable that allows it to be used as a compatible replacement for an Altera USB Blaster -- a cable based on a different USB interface part from FTDI, which is supported under linux by the libftdi project [7]. The UrJTAG project [8], which is a currently-maintained fork of the mostly-abandonware openwince-jtag project, provides a high level JTAG interface (using libftdi as one of many drivers) that can be used to program the FPGA using SVF files from the Xilinx iMPACT tool. The Nexys 2 board enters the picture at last when Sune Mai, in posts on fpga4fun.com [9] and on the UrJTAG mailing list [10], ported Waschk's usb_jtag firmware to the Nexys 2 by simply changing the 8051 port assignments of the JTAG pins (the FX2 on the Digilent board is wired differently than the usb_jtag cable, but is otherwise compatible) and by fixing a integer overflow bug the upstream code had with handling large bitstream files. Neither change has been merged into Kolja's code, unfortunately. Finally, Morgan Delahaye-Prat collected the above into a single walkthrough on his (French) blog [11], providing detailed instructions and downloadable files and patches. The language barrier for non-French-speakers can be surmounted without too much difficulty via google's language tools. The Rube Goldberg-like complexity of the process, however, took much longer to puzzle out and left me with a tree full of tiny scripts, notes, and patched software trees. [1] http://www.xilinx.com/ise/logic_design_prod/webpack.htm [2] http://digilentinc.com/Products/Detail.cfm?Prod=ADEPT [3] http://download.cypress.com.edgesuite.net/design_resources/datasheets/contents/cy7c68013a_8.pdf [4] http://linux-hotplug.sourceforge.net [5] http://sdcc.sourceforge.net [6] http://www.ixo.de/info/usb_jtag/ [7] http://www.intra2net.com/en/developer/libftdi [8] http://urjtag.org [9] http://www.fpga4fun.com/forum/viewtopic.php?p=4779 [10] http://sourceforge.net/forum/forum.php?thread_id=2312452&forum_id=682993 [11] http://www.m-del.net/info.htmlArticle: 139537
Andy Ross <andy.ross.or@gmail.com> wrote: > emeb wrote: > > 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. > Yes, that's exactly right. The FX2 chip has a built-in loader that > works irrespective of what the boot configuration was. Once the > device reboots (you have to unplug it from the USB bus, it's not > controlled by the FPGA power switch) it restreams its firmware from > the I2C EEPROM and acts like a Digilent device again. I have a modified version of the USRP FX2 firmware and a modified version of xc3sprog(Linux) to directly programm Spartan3/XCF and XC95XL via a Bit/Jedecfile. Probably the firmware needs some adapations, as the JTAG Pins will differ. However I don't have a Digilent adapter available, to someone interested must do this changes by himself. Some nearly recent verison is uploaded to the patches section of xc3sprog at sourceforge. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 139538
On Wed, 1 Apr 2009 13:26:47 -0700 (PDT) halong <ccon67@netscape.net> wrote: > 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 - >=20 > Haha, It rings the bell about the battle between DLL vs. PLL not long > ago. :-) >=20 > So far, jitter is the only thing I concern about... so who's the > winner ? >=20 DCM shows. PLL places. Starting off with a good crystal oscillator in first place wins by a length. --=20 Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 139539
On Wed, 01 Apr 2009 23:46:08 +0200 News123 <news123@free.fr> wrote: > 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. A real, honest to god, electromechanical relay. Though you probably can't drive the coil directly from an FPGA, and so you'll need a couple discretes too. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 139540
On Apr 1, 5:46=A0pm, News123 <news...@free.fr> wrote: > 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. If you don't mind spending some money, go to DigiKey and search for "solid state relay". Here's just a sample: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=3DPB553-ND Could be overkill, but definitely can be driven directly from a 3V LVCMOS output. Regards, GaborArticle: 139541
On Apr 2, 9:06=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > I have a modified version of the USRP FX2 firmware and a modified version= of > xc3sprog(Linux) to directly programm Spartan3/XCF and XC95XL via a > Bit/Jedecfile. Probably the firmware needs some adapations, as the JTAG P= ins > will differ. However I don't have a Digilent adapter available, to someon= e > interested must do this changes by himself. Yeah. With all due respect, though, the "someone needs to make it work" part is a huge hurdle. There are all sorts of half-solutions like that floating around the internet in various stages of decay. Your own xc3sprog patches, for example, are still patches because the project itself is abandoned. And of course, xc3sprog itself is a fork of someone else's abandoned work... I did see your stuff, by the way, but ultimately decided on the UrJTAG- based solution instead. UrJTAG is actively maintained, works well, and is more generically useful for anyone working with their FPGA board than a Spartan-specific C program will be. Likewise, Kolja Waschk's FX2 firmware seemed cleaner to me. It emulates an existing protocol (spoken by the FTDI-based Altera USBBlaster cable) and thus works out-of-the-box with UrJTAG without modification. And the patches required for it consist only of a few modified pin assignments and a fix for an integer overflow bug, so it's easier for me to maintain as part of the script. Obviously the Right Thing here would be for someone to write a generic firmware suite for the FX2 (abstracting the JTAG pin assignments somehow), pair it with dynamic USB device detection and configuration for all known FX2-based JTAG controllers, and mate it to UrJTAG such that any bitstream file can be thrown at any JTAG chain with the expected results. But I didn't have time (or the device library, or the domain knowledge) to do that. So instead I wanted to get to a solution that works well for just one device and requires as little from the user as possible. That's what this script does.Article: 139542
Hi, On 2 Apr., 11:36, knight <krshe...@gmail.com> wrote: > more than 400 Mhz. But when i combine everything iam getting > only 121Mhz. > Can you tell me the reason...??? No, I can only guess. 1. Bad timing contraints for frequency 2. Bad crossing of signals between moduls 3. Synthesis of a submodul has another result stand alone than in the overall design 4. Bad timing due to high device usage 5. Wrong understanding of timing analyses 6.... The most likely answer will be a mixture of 2 and 4, but you give to less information to be for sure. > Does this mean i cannot use a clock more than 121 Mhz in my design(iam > using and found it working well..) The maximum frequency in timing report is the highest frequency for which your vendor will guarantee full functionality of the design in select worst case (including some aging of the device). The design is very likely to do well in higher frequencies or under better operating conditions. But nobody will take responsibility if your design fails on a higher frequency than the result from timing analyses. It is very likely that signal changes on long delay path (e.g. carry) will fail sometimes or on some devices, when you exceed the max frequency. bye ThomasArticle: 139543
On Apr 2, 10:01=A0pm, David Fejes <fej...@gmail.com> wrote: > > 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 =A0It 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? What load is this driving, and what time variance can you tolerate ? Within the CPLD the data paths are nominally the same, but you will find signals further from GND pins are more variable, and the signals will also have different thermal-delay-profiles. It's normally best to have the device delays a fraction of our signal, so any variations in those delays are an even smaller fraction of your signal. Why chose the XC95xxx ? -jgArticle: 139544
Andy Ross <andy.ross.or@gmail.com> wrote: ... > like that floating around the internet in various stages of decay. > Your own xc3sprog patches, for example, are still patches because the > project itself is abandoned. And of course, xc3sprog itself is a fork > of someone else's abandoned work... That's the history of most open source projects. > I did see your stuff, by the way, but ultimately decided on the UrJTAG- > based solution instead. UrJTAG is actively maintained, works well, > and is more generically useful for anyone working with their FPGA > board than a Spartan-specific C program will be. The stuff is in SVN locally. > Likewise, Kolja Waschk's FX2 firmware seemed cleaner to me. It > emulates an existing protocol (spoken by the FTDI-based Altera > USBBlaster cable) and thus works out-of-the-box with UrJTAG without > modification. And the patches required for it consist only of a few > modified pin assignments and a fix for an integer overflow bug, so > it's easier for me to maintain as part of the script. This will have a hugh inpact on transfer speed > Obviously the Right Thing here would be for someone to write a generic > firmware suite for the FX2 (abstracting the JTAG pin assignments > somehow), pair it with dynamic USB device detection and configuration > for all known FX2-based JTAG controllers, and mate it to UrJTAG such > that any bitstream file can be thrown at any JTAG chain with the > expected results. Thats a "eierlegende Wollmichsau", doing everything right, but probably never in time. > ... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 139545
Ok, so I have a system that has a 25mhz clock built on it, and I'd like to have either a 20mhz clock or a 100mhz clock, Now I'm thinking of options, 1) make a 20mhz clock out of the 25mhz. - the obvious idea is to count up to 5 and force a state change on one of the counts, but this will give me a 80/20 duty cycle. If i'm only clocking on the rising edge, is this a problem? 2) how would I make a 20mhz clock out of the 25mhz with a closer to 50/50 duty cycle? 3) I keep hearing about clock mulitpliers, how is that done in an fpga? I could on paper multiply the 25mhz by 4 and have a 100mhz clock, that would be good... 4) given I have input pins on my fpga, could I make up a daughter card, that has a 100mhz oscillator on it, send that signal in on one of the pins and use that as the clock and ignore the 25mhz clock? Tia, JonathanArticle: 139546
On Apr 2, 3:46=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > Ok, > > so I have a system that has a 25mhz clock built on it, and I'd like to > have either a 20mhz clock or a 100mhz clock, > > Now I'm thinking of options, > > 1) make a 20mhz clock out of the 25mhz. > - the obvious idea is to count up to 5 and force a state change on one > of the counts, but this will give me a 80/20 duty cycle. If i'm only > clocking on the rising edge, is this a problem? > > 2) how would I make a 20mhz clock out of the 25mhz with a closer to > 50/50 duty cycle? > > 3) I keep hearing about clock mulitpliers, how is that done in an > fpga? =A0I could on paper multiply the 25mhz by 4 and have a 100mhz > clock, that would be good... > > 4) given I have input pins on my fpga, could I make up a daughter > card, that has a 100mhz oscillator on it, send that signal in on one > of the pins and use that as the clock and ignore the 25mhz clock? > > Tia, > > Jonathan If you're using a Xilinx FPGA, you can use a DCM block to multiply the 25MHz up to 100 MHz. The 100MHz can easily be divided down to 20MHz. John ProvidenzaArticle: 139547
On Apr 2, 9:06=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > Andy Ross <andy.ross...@gmail.com> wrote: > > emeb wrote: > > > 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. > > Yes, that's exactly right. =A0The FX2 chip has a built-in loader that > > works irrespective of what the boot configuration was. =A0Once the > > device reboots (you have to unplug it from the USB bus, it's not > > controlled by the FPGA power switch) it restreams its firmware from > > the I2C EEPROM and acts like a Digilent device again. > > I have a modified version of the USRP FX2 firmware and a modified version= of > xc3sprog(Linux) to directly programm Spartan3/XCF and XC95XL via a > Bit/Jedecfile. Probably the firmware needs some adapations, as the JTAG P= ins > will differ. However I don't have a Digilent adapter available, to someon= e > interested must do this changes by himself. > > Some nearly recent verison is uploaded to the patches section of > xc3sprog at sourceforge. > > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- I've got one of the low-end Digilent USB/JTAG cables that uses the FX2 chip at the JTAG end. If you could point me at your app source I'd like to give this a try. EricArticle: 139548
On Apr 2, 7:05 pm, jprovide...@yahoo.com wrote:
> On Apr 2, 3:46 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > Ok,
>
> > so I have a system that has a 25mhz clock built on it, and I'd like to
> > have either a 20mhz clock or a 100mhz clock,
>
> > Now I'm thinking of options,
>
> > 1) make a 20mhz clock out of the 25mhz.
> > - the obvious idea is to count up to 5 and force a state change on one
> > of the counts, but this will give me a 80/20 duty cycle. If i'm only
> > clocking on the rising edge, is this a problem?
>
> > 2) how would I make a 20mhz clock out of the 25mhz with a closer to
> > 50/50 duty cycle?
>
> > 3) I keep hearing about clock mulitpliers, how is that done in an
> > fpga? I could on paper multiply the 25mhz by 4 and have a 100mhz
> > clock, that would be good...
>
> > 4) given I have input pins on my fpga, could I make up a daughter
> > card, that has a 100mhz oscillator on it, send that signal in on one
> > of the pins and use that as the clock and ignore the 25mhz clock?
>
> > Tia,
>
> > Jonathan
>
> If you're using a Xilinx FPGA, you can use a DCM block to multiply the
> 25MHz up
> to 100 MHz. The 100MHz can easily be divided down to 20MHz.
>
> John Providenza
Ok, yeah, that is what I'm reading up on.
there is no good way to divide 25mhz to get 20mhz, that was
incorrect.
I'm still interested in an external oscillator coming in on a pin
though.
I'm seeing some write-ups on dll (delay latch logic?) but I'm
unfamiliar with
DCM (and dll) for that matter. Here is what xilinx has as code:
-----------------------------------------------------------------------------------
-- XAPP174
--
-- DLL 2X and 4X Example
--
library ieee;
use ieee.std_logic_1164.all;
entity dll_standard is
port (CLKIN : in std_logic;
RESET : in std_logic;
CLK2X : out std_logic;
CLK4X : out std_logic;
LOCKED: out std_logic);
end dll_standard;
architecture structural of dll_standard is
component IBUFG
port(
O : out STD_ULOGIC;
I : in STD_ULOGIC);
end component;
component IBUF
port(
O : out STD_ULOGIC;
I : in STD_ULOGIC);
end component;
component CLKDLL
port ( CLKIN : in std_ulogic := '0';
CLKFB : in std_ulogic := '0';
RST : in std_ulogic := '0';
CLK0 : out std_ulogic := '0';
CLK90 : out std_ulogic := '0';
CLK180 : out std_ulogic := '0';
CLK270 : out std_ulogic := '0';
CLK2X : out std_ulogic := '0';
CLKDV : out std_ulogic := '0';
LOCKED : out std_ulogic := '0');
end component;
component BUFG
port(
O : out STD_ULOGIC;
I : in STD_ULOGIC);
end component;
component OBUF
port(
O : out STD_ULOGIC;
I : in STD_ULOGIC);
end component;
component SRL16
port (D : in STD_ULOGIC;
CLK : in STD_ULOGIC;
A0 : in STD_ULOGIC;
A1 : in STD_ULOGIC;
A2 : in STD_ULOGIC;
A3 : in STD_ULOGIC;
Q : out STD_ULOGIC);
end component;
signal CLKIN_w, RESET_w, CLK2X_dll, CLK2X_g, CLK4X_dll, CLK4X_g :
std_logic;
signal LOCKED2X, LOCKED2X_delay, RESET4X, LOCKED4X_dll : std_logic;
signal logic1 : std_logic;
begin
logic1 <= '1';
clkpad : IBUFG port map (I=>CLKIN, O=>CLKIN_w);
rstpad : IBUF port map (I=>RESET, O=>RESET_w);
dll2x : CLKDLL port map (CLKIN=>CLKIN_w, CLKFB=>CLK2X_g,
RST=>RESET_w,
CLK0=>open, CLK90=>open, CLK180=>open,
CLK270=>open,
CLK2X=>CLK2X_dll, CLKDV=>open,
LOCKED=>LOCKED2X);
clk2xg : BUFG port map (I=>CLK2X_dll, O=>CLK2X_g);
rstsrl : SRL16 port map (D=>LOCKED2X, CLK=>CLK2X_g,
Q=>LOCKED2X_delay,
A3=>logic1, A2=>logic1, A1=>logic1,
A0=>logic1);
RESET4X <= not LOCKED2X_delay;
dll4x : CLKDLL port map (CLKIN=>CLK2X_g, CLKFB=>CLK4X_g,
RST=>RESET4X,
CLK0=>open, CLK90=>open, CLK180=>open,
CLK270=>open,
CLK2X=>CLK4X_dll, CLKDV=>open,
LOCKED=>LOCKED4X_dll);
clk4xg : BUFG port map (I=>CLK4X_dll, O=>CLK4X_g);
lckpad : OBUF port map (I=>LOCKED4X_dll, O=>LOCKED);
CLK2X <= CLK2X_g;
CLK4X <= CLK4X_g;
end structural;
-----------------------------------------------------------------------------------------------------
so what, I just make up an instance on this routine, send in my 25mhz
clock, and out comes
a 100mhz clock? And then my program references this 100mhz clock
instead?
That's all there is to it?
Article: 139549On Thu, 2 Apr 2009 09:23:51 -0700, Rob Gaddi <rgaddi@technologyhighland.com> wrote: >On Wed, 01 Apr 2009 23:46:08 +0200 >News123 <news123@free.fr> wrote: > >> Hi, >> >> I'd like to control power sockets via an FPGA. >> thanks in advance for any suggestions. > >A real, honest to god, electromechanical relay. Though you probably >can't drive the coil directly from an FPGA, and so you'll need a couple >discretes too. Seconded, for non-inductive (or not-too-inductive!) loads. In other words, be aware of the possibility for the relay to weld its contacts shut, if run beyond its contact current rating, or if surge currents or disconnection spikes exceed its ratings. If necessary, over-rate the relay; add protection components (a suitable capacitor will be a good idea to suppress interference anyway); and if safety is at stake (e.g. you are controlling power tools) there MUST be an alternative means of fast disconnection. - Brian
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