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
Andy Peters wrote:
> No, actually, I've being doing this for a long time -- remember XACT?
Yes. That was a good demo of the halting problem.
> I realize that things change all the time, which is why I like to
> minimize my dependency on the tools. But unfortunately, that's not
> always possible.
I need synthesis for STA and for the .bit file,
but I have started using svn tags for archiving the files.
Not exactly easy to use, but it does work and is unlikely
to vanish without a trace.
-- Mike Treseler
Article: 142101On Jul 24, 8:57=A0am, "dwecker" <dw...@online.de> wrote: > Configuration the Flash PROM for Spartan-3 Starter Kit Board. > Loading the serial configuration Flash PROM. > If you have no parallel port at your PC or Laptop, you can use > Digilent=92s JTAG-USB cable to load the Flash PROM with the configuration > File. There are several Methods to load the PROM and SRAM on the Spartan-= 3 > Board. Here is one Method that works properly: > 1) =A0 =A0 =A0Start the =93Generate Programming File=94 from the Xilinx I= SE Software > 2) =A0 =A0 =A0=93Configure device using Boundary Scan (JTAG)=94. > 3) =A0 =A0 =A0Prepare a PROM File: name.mcs > 4) =A0 =A0 =A0Select the Flash PROM Type (XCF02S). > 5) =A0 =A0 =A0Generate the File: name .mcs > > Xilinx expects now a parallel port to load the Flash PROM or Xilinx > specific ports. > Now use Digilent=92s =A0Adept Software: > Connect the JTAG-USB cable between Laptop and Spartan-3 Board. > 6) =A0 =A0 =A0Start the Adept Software of Digilent. If the Adept driver i= s correctly > installed, Digilent=92s Adept recognized the device and initialized the > chain. > 7) =A0 =A0 =A0Select the File: name.mcs for the PROM (XCF02S). > 8) =A0 =A0 =A0Start =93Program=94 to load the PROM. > > Now you can work with the Spartan-3 Board. > > I had a Problem to load the .bit File directly in the FPGA. There was a > warning: =93Startup clock for this File is =93CCLK=94 instead of =93JTAG > CLK=94. > But you don=92t need the .bit File for configuration the Flash PROM, you > can take the .mcs File. > > See also: Application with Spartan-3 Board: =A0www.d-wecker.de Great post! If you had the Xilinx USB JTAG cable, you could use impact software and the warning about CCLK would have been followed by a notice that the startup clock will be changed to JTAG for this download only. Otherwise if you really wanted to download the .bit file directly, you could change your bitgen settings to use JTAG clock, but then remember to change them back to CCLK before you make the .mcs file for the flash. Regards, GaborArticle: 142102
Uwe Bonnes wrote: > Dinotrace is another good waveform viewer Also exists as a FreeBSD port: http://www.freshports.org/cad/dinotrace/ Great! -- Torfinn Ingolfsen, NorwayArticle: 142103
Poojan Wagh wrote: > Look in /usr/ports/cad (http://www.freebsd.org/ports/cad.html) to find > more. Thanks. > Still won't help you on programming the part, though. Has anyone got any experince with urjtag[1]? That tool loks to me like it is the "programming" part... References: 1) http://www.freshports.org/devel/urjtag/ -- Torfinn Ingolfsen, NorwayArticle: 142104
On Thu, 23 Jul 2009 15:57:22 -0700 (PDT), Peter Alfke <peter@xilinx.com> wrote: >Here is a concise overview with links to most User Guides. >http://www.pldesignline.com/ >Spartan-6 will get the same treatment in about a week. >Peter Alfke, Xilinx The thing we can't find out about S6's is when can we get some! JohnArticle: 142105
On Jul 24, 10:57=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > Andy Peters wrote: > > No, actually, I've being doing this for a long time -- remember XACT? > > Yes. That was a good demo of the halting problem. > > > I realize that things change all the time, which is why I like to > > minimize my dependency on the tools. But unfortunately, that's not > > always possible. > > I need synthesis for STA and for the .bit file, > but I have started using svn tags for archiving the files. > Not exactly easy to use, but it does work and is unlikely > to vanish without a trace. The project is in an svn repo. The great thing about this now-deleted feature was that it boiled the ISE project file down to a couple of tcl scripts which are scc-friendly. The only other things in the repo are the sources and a .ucf. So I'd check out the project, then open ISE, use the Project | Source Control | Import feature and it would reconstruct the ISE project file. When the design is final, I tag it by svn add-ing the bitfile and the .mcs and creating a tag from the working copy. Then I revert the add because my working copy is still the trunk. I suppose I could go back to scripts and Makefiles, but EDK adds another whole level of bullshit to the process and that makes it difficult to use without the GUI. -aArticle: 142106
On Jul 24, 2:20=A0pm, gabor <ga...@alacron.com> wrote: > Otherwise if you really wanted to > download the .bit file directly, you could change your > bitgen settings to use JTAG clock, but then remember to > change them back to CCLK before you make the .mcs file for the > flash. if you have a prom on board and you download a bit file using jtag but with the cclk bit set, the prom generates cclk and starts the fpga. so you don't need to switch anything. at least i think that's how it worked the last time i tried this.Article: 142107
On Jul 24, 3:35=A0pm, Andy Peters <goo...@latke.net> wrote: > I suppose I could go back to scripts and Makefiles, but EDK adds > another whole level of bullshit to the process and that makes it > difficult to use without the GUI. if you're using edk you should *definitely* use scripts and makefiles. edk uses make for a backend after all. sometimes i use platform studio to make project modifications (like adding chipscope), since it does some error checking, but all builds are with makefiles from a cygwin shell. perhaps it is different if you use ise to drive xps, but i use xps to drive ise.Article: 142108
On Fri, 24 Jul 2009 15:35:37 -0700 (PDT) Andy Peters <google@latke.net> wrote: > On Jul 24, 10:57=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > > Andy Peters wrote: > > > No, actually, I've being doing this for a long time -- remember > > > XACT? > > > > Yes. That was a good demo of the halting problem. > > > > > I realize that things change all the time, which is why I like to > > > minimize my dependency on the tools. But unfortunately, that's not > > > always possible. > > > > I need synthesis for STA and for the .bit file, > > but I have started using svn tags for archiving the files. > > Not exactly easy to use, but it does work and is unlikely > > to vanish without a trace. >=20 > The project is in an svn repo. The great thing about this now-deleted > feature was that it boiled the ISE project file down to a couple of > tcl scripts which are scc-friendly. The only other things in the repo > are the sources and a .ucf. >=20 > So I'd check out the project, then open ISE, use the Project | Source > Control | Import feature and it would reconstruct the ISE project > file. >=20 > When the design is final, I tag it by svn add-ing the bitfile and > the .mcs and creating a tag from the working copy. Then I revert the > add because my working copy is still the trunk. >=20 > I suppose I could go back to scripts and Makefiles, but EDK adds > another whole level of bullshit to the process and that makes it > difficult to use without the GUI. >=20 > -a Unless I'm mistaken, the new ISE project files are already SVN friendly text files. Only took a decade to get there. --=20 Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 142109
Rob Gaddi wrote: > > This sounds like it can be pretty easily worked around > by using the lock output of the DCM to switch a clock > through a BUFGCE. Assuming, of course, one knows about > the need to do so. > That is in fact the workaround described earlier in the thread by Allan, and is one of the three possibilities discussed in those old threads for handling the clock startup problem: 1) disable clocks with glitch-free clock mux until stable 2) gate the BRAM enable off until all clocks are known stable 3) use DCM STARTUP_WAIT & bitgen dcm lock settings #1 is easiest, no logic mods, and works with buried-in-IP ROMs #2 requires adding logic to any existing usage of BRAM enables #3 is inadvisable in a real world design to the numerous practical problems arising from the use of that option ( e.g. AR #14425 ) ----------- Note that this cures ONLY the DCM startup problem, not any similar problems caused by the numerous other sources of clock anomalies during operation ( DCM unlocks, external reference transients, etc. ) For instance, let us suppose that one of your FPGA based DDS/waveform generator cards allows the user to clock or sync the FPGA/DAC clock directly from an external source. And that said card uses FPGA BRAMs to store the DDS wave table coefficients. And that the end user does something like turn the clock on _after_ the card is powered up; or, disconnect/reconnect the ref/sync cable during operation; or, changes the external clock source frequency using a signal generator that glitches during frequency changes. If propagated to the FPGA, the resulting clock glitch can silently corrupt the BRAMs containing the DDS waveform tables. BrianArticle: 142110
Torfinn Ingolfsen <tingo@start.no> wrote: > Poojan Wagh wrote: > > Look in /usr/ports/cad (http://www.freebsd.org/ports/cad.html) to find > > more. > Thanks. > > Still won't help you on programming the part, though. > Has anyone got any experince with urjtag[1]? > That tool loks to me like it is the "programming" part... > References: > 1) http://www.freshports.org/devel/urjtag/ > -- For programming the devices with bit/jedecfiles, look for xc3sprog on sourceforge. I just checked in to SVN the framework for Coolrunner II programming. It is the first open implementation I kno of. Xc3sprog should run(with few effort) on BSD too. Please let me know. But probably people mean transforming the HDL file to bit/jedecfile by "programming the part" ... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142111
On Fri, 24 Jul 2009 10:44:40 GMT, nico@puntnl.niks (Nico Coesel) wrote: >John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >>Hi, >> >>We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2 >>dram chip. The coregen thing seems to successfully build a dram >>interface that's claimed to work up to 133 MHz. The DRAM is spec'd to >>work down to 128 MHz, so there's a small overlap window. We'd run at >>128. >> >>Our Xilinx FAE seems to be discouraging us from doing this, without >>saying precisely why, suggesting some other parts. Spartan 6 would be >>ideal (hard dram controller as I understand it) but are unavailable >>for some vague time. We'd rather not use a new part for a single >>project, since we will cut over to the s6's when they are available. >> >>Has anyone done DDR2 from a Spartan 3? Success/horror stories? > >I did a DDR design at 100MHz which shares a standard PC memory module >(64 bit wide) between two Spartan 3 FPGAs (800MB/s per FPGA). I didn't >like the MIG tool (way too big, ugly and too limited) so I rolled my >own DDR controller. The trick is to get the sampling point for the >incoming data right. I used a 90 degrees phase shifted capture clock >that hit the sweet spot perfectly. I'm planning on upgrading this >design to DDR2 using the speed grade 5 devices. I still have to do the >math whether the phase shifted clock will work. There has to be a >window in which the data is stable for the FPGA to sample it. If there >is no such window a calibration scheme is required. > >I looked at the Spartan 6 FPGA but I doubt it will offer much >improvement. The memory controller is still very limited when it comes >to the amount of memory (width and address space) it can control. *Now* our Xilinx guy is saying, oops, the XC3S is fine to work with DDR2. Maybe I'll add an external variable delay just in case we need to tweak the read clock edge. JohnArticle: 142112
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:ia1l6511mrt05k4vhifkcu1j9s1kc5i4nu@4ax.com... > On Fri, 24 Jul 2009 10:44:40 GMT, nico@puntnl.niks (Nico Coesel) > wrote: > >>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >> >>>Hi, >>> >>>We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2 >>>dram chip. The coregen thing seems to successfully build a dram >>>interface that's claimed to work up to 133 MHz. The DRAM is spec'd to >>>work down to 128 MHz, so there's a small overlap window. We'd run at >>>128. >>> >>>Our Xilinx FAE seems to be discouraging us from doing this, without >>>saying precisely why, suggesting some other parts. Spartan 6 would be >>>ideal (hard dram controller as I understand it) but are unavailable >>>for some vague time. We'd rather not use a new part for a single >>>project, since we will cut over to the s6's when they are available. >>> >>>Has anyone done DDR2 from a Spartan 3? Success/horror stories? >> >>I did a DDR design at 100MHz which shares a standard PC memory module >>(64 bit wide) between two Spartan 3 FPGAs (800MB/s per FPGA). I didn't >>like the MIG tool (way too big, ugly and too limited) so I rolled my >>own DDR controller. The trick is to get the sampling point for the >>incoming data right. I used a 90 degrees phase shifted capture clock >>that hit the sweet spot perfectly. I'm planning on upgrading this >>design to DDR2 using the speed grade 5 devices. I still have to do the >>math whether the phase shifted clock will work. There has to be a >>window in which the data is stable for the FPGA to sample it. If there >>is no such window a calibration scheme is required. >> >>I looked at the Spartan 6 FPGA but I doubt it will offer much >>improvement. The memory controller is still very limited when it comes >>to the amount of memory (width and address space) it can control. > > *Now* our Xilinx guy is saying, oops, the XC3S is fine to work with > DDR2. Maybe I'll add an external variable delay just in case we need > to tweak the read clock edge. > > John > The issue with not clocking the read data from each byte's DQS is that you're losing some of your data valid window. However, if you're set on using Spartan 3 then it's your only choice. The trick is to make sure that your internal fabric clock is phase stable with the incoming data (over voltage, temperature, and unit-to-unit variations) in order to maximize the read data valid window at each IOB. There are also techniques for stabilizing the write data and FPGA-generated RAM clock with respect to voltage, temperature, and unit-to-unit variations. This involves routing an output pin back to a clock input (IBUFG) and putting it in the DCM->BUFG feedback loop. I would assume that the Xilinx appnote does this (I think it does, iirc). You'll need to use DCMs, anyway, so adding external variable delay doesn't buy you anything. I would recommend putting hooks in your code so that you can, at run time, adjust the read DCM phase shift so you can find the middle of the data valid window while testing over supply and temperature variation. If you use an external clock (copy of the one feeding the FPGA) to clock your RAM then you lose the ability to do RAM checking via JTAG at production test time. If you do FPGA JTAG-controlled RAM testing then you'll need to have the FPGA forward the clock to the RAM. With all that, you should be able to get it to work reliably at your 256M data rate, but it takes a lot of up-front planning. Bob -- == All google group posts are automatically deleted due to spam ==Article: 142113
"BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com> wrote:
>
>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
>news:ia1l6511mrt05k4vhifkcu1j9s1kc5i4nu@4ax.com...
>> On Fri, 24 Jul 2009 10:44:40 GMT, nico@puntnl.niks (Nico Coesel)
>> wrote:
>>
>>>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>>>
>>>>Hi,
>>>>
>>>>We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2
>>>>dram chip. The coregen thing seems to successfully build a dram
>>>>interface that's claimed to work up to 133 MHz. The DRAM is spec'd to
>>>>work down to 128 MHz, so there's a small overlap window. We'd run at
>>>>128.
>>>>
>>>>Our Xilinx FAE seems to be discouraging us from doing this, without
>>>>saying precisely why, suggesting some other parts. Spartan 6 would be
>>>>ideal (hard dram controller as I understand it) but are unavailable
>>>>for some vague time. We'd rather not use a new part for a single
>>>>project, since we will cut over to the s6's when they are available.
>>>>
>>>>Has anyone done DDR2 from a Spartan 3? Success/horror stories?
>>>
>>>I did a DDR design at 100MHz which shares a standard PC memory module
>>>(64 bit wide) between two Spartan 3 FPGAs (800MB/s per FPGA). I didn't
>>>like the MIG tool (way too big, ugly and too limited) so I rolled my
>>>own DDR controller. The trick is to get the sampling point for the
>>>incoming data right. I used a 90 degrees phase shifted capture clock
>>>that hit the sweet spot perfectly. I'm planning on upgrading this
>>>design to DDR2 using the speed grade 5 devices. I still have to do the
>>>math whether the phase shifted clock will work. There has to be a
>>>window in which the data is stable for the FPGA to sample it. If there
>>>is no such window a calibration scheme is required.
>>>
>>>I looked at the Spartan 6 FPGA but I doubt it will offer much
>>>improvement. The memory controller is still very limited when it comes
>>>to the amount of memory (width and address space) it can control.
>>
>> *Now* our Xilinx guy is saying, oops, the XC3S is fine to work with
>> DDR2. Maybe I'll add an external variable delay just in case we need
>> to tweak the read clock edge.
>>
>> John
>>
>There are also techniques for stabilizing the write data and FPGA-generated
>RAM clock with respect to voltage, temperature, and unit-to-unit variations.
>This involves routing an output pin back to a clock input (IBUFG) and
>putting it in the DCM->BUFG feedback loop. I would assume that the Xilinx
>appnote does this (I think it does, iirc).
IMHO this trick has no effect if you source the memory clock from the
FPGA, the delay variation in the IOB is cancelled when writing.
Writing data becomes a walk in the park.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142114Uwe Bonnes wrote: > For programming the devices with bit/jedecfiles, look for xc3sprog on > sourceforge. I just checked in to SVN the framework for Coolrunner II > programming. It is the first open implementation I kno of. > Xc3sprog should run(with few effort) on BSD too. Please let me know. Isn't xc3sprog[1] only for programming Xilinx devices? Will it work with devices from Altera as well? I couldn't find anything about it in the documentation. Anyway, I downloaded the files from sf.net, but it doesn't com pile cleany on FreeBSD: tingo@kg-v2$ mkdir build; cd build; tingo@kg-v2$ pwd /usr/home/tingo/work/xc3sprog-r216/build tingo@kg-v2$ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- checking for module 'libftdi' -- found libftdi, version 0.14 -- Found LIBFTDI: /usr/local/lib/libftdi.a -- checking for module 'libusb' -- found libusb, version 0.1.12 -- Found LIBUSB: /usr/local/lib/libusb.so -- Configuring done -- Generating done -- Build files have been written to: /usr/home/tingo/work/xc3sprog-r216/build tingo@kg-v2$ gmake Scanning dependencies of target bitparse [ 1%] Building CXX object CMakeFiles/bitparse.dir/bitfile.cpp.o [ 3%] Building CXX object CMakeFiles/bitparse.dir/bitparse.cpp.o Linking CXX executable bitparse [ 3%] Built target bitparse Scanning dependencies of target debug [ 5%] Building CXX object CMakeFiles/debug.dir/debug.cpp.o [ 6%] Building CXX object CMakeFiles/debug.dir/iobase.cpp.o [ 8%] Building CXX object CMakeFiles/debug.dir/ioparport.cpp.o /usr/home/tingo/work/xc3sprog-r216/ioparport.cpp: In member function 'int IOParport::write_data(int, unsigned char)': /usr/home/tingo/work/xc3sprog-r216/ioparport.cpp:447: error: 'port' was not declared in this scope /usr/home/tingo/work/xc3sprog-r216/ioparport.cpp: In member function 'int IOParport::write_control(int, unsigned char)': /usr/home/tingo/work/xc3sprog-r216/ioparport.cpp:467: error: 'port' was not declared in this scope /usr/home/tingo/work/xc3sprog-r216/ioparport.cpp: In member function 'int IOParport::read_control(int, unsigned char*)': /usr/home/tingo/work/xc3sprog-r216/ioparport.cpp:488: error: 'port' was not declared in this scope gmake[2]: *** [CMakeFiles/debug.dir/ioparport.cpp.o] Error 1 gmake[1]: *** [CMakeFiles/debug.dir/all] Error 2 gmake: *** [all] Error 2 References: 1) http://xc3sprog.sourceforge.net/ -- Torfinn Ingolfsen, NorwayArticle: 142115
Torfinn Ingolfsen <tingo@start.no> wrote: > Uwe Bonnes wrote: > > For programming the devices with bit/jedecfiles, look for xc3sprog on > > sourceforge. I just checked in to SVN the framework for Coolrunner II > > programming. It is the first open implementation I kno of. > > Xc3sprog should run(with few effort) on BSD too. Please let me know. > Isn't xc3sprog[1] only for programming Xilinx devices? Will it work with > devices from Altera as well? > I couldn't find anything about it in the documentation. It works now with the Atmel JTAG Parts too. It could work, if Altera provides the BSDL-1532 files for their devices , or the programming algorithm is know otherwise and somebody provides ant tests progalgXXX files for the Altera devices. I will gladly apply provided patches. If you look at the Xilinx 1532 files and the implementation in progalgxcXX, implemention is straightforward. > Anyway, I downloaded the files from sf.net, but it doesn't com pile > cleany on FreeBSD: ... > /usr/home/tingo/work/xc3sprog-r216/ioparport.cpp: In member function > 'int IOParport::write_data(int, unsigned char)': Silly cut and past bug. Please try SVN revision-272 from sourceforge. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142116
"Nico Coesel" <nico@puntnl.niks> wrote in message news:4a6acdbc.71573125@news.planet.nl... > "BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com> wrote: > >> >>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in >>message >>news:ia1l6511mrt05k4vhifkcu1j9s1kc5i4nu@4ax.com... >>> On Fri, 24 Jul 2009 10:44:40 GMT, nico@puntnl.niks (Nico Coesel) >>> wrote: >>> >>>>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>>>Hi, >>>>> >>>>>We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2 >>>>>dram chip. The coregen thing seems to successfully build a dram >>>>>interface that's claimed to work up to 133 MHz. The DRAM is spec'd to >>>>>work down to 128 MHz, so there's a small overlap window. We'd run at >>>>>128. >>>>> >>>>>Our Xilinx FAE seems to be discouraging us from doing this, without >>>>>saying precisely why, suggesting some other parts. Spartan 6 would be >>>>>ideal (hard dram controller as I understand it) but are unavailable >>>>>for some vague time. We'd rather not use a new part for a single >>>>>project, since we will cut over to the s6's when they are available. >>>>> >>>>>Has anyone done DDR2 from a Spartan 3? Success/horror stories? >>>> >>>>I did a DDR design at 100MHz which shares a standard PC memory module >>>>(64 bit wide) between two Spartan 3 FPGAs (800MB/s per FPGA). I didn't >>>>like the MIG tool (way too big, ugly and too limited) so I rolled my >>>>own DDR controller. The trick is to get the sampling point for the >>>>incoming data right. I used a 90 degrees phase shifted capture clock >>>>that hit the sweet spot perfectly. I'm planning on upgrading this >>>>design to DDR2 using the speed grade 5 devices. I still have to do the >>>>math whether the phase shifted clock will work. There has to be a >>>>window in which the data is stable for the FPGA to sample it. If there >>>>is no such window a calibration scheme is required. >>>> >>>>I looked at the Spartan 6 FPGA but I doubt it will offer much >>>>improvement. The memory controller is still very limited when it comes >>>>to the amount of memory (width and address space) it can control. >>> >>> *Now* our Xilinx guy is saying, oops, the XC3S is fine to work with >>> DDR2. Maybe I'll add an external variable delay just in case we need >>> to tweak the read clock edge. >>> >>> John >>> > >>There are also techniques for stabilizing the write data and >>FPGA-generated >>RAM clock with respect to voltage, temperature, and unit-to-unit >>variations. >>This involves routing an output pin back to a clock input (IBUFG) and >>putting it in the DCM->BUFG feedback loop. I would assume that the Xilinx >>appnote does this (I think it does, iirc). > > IMHO this trick has no effect if you source the memory clock from the > FPGA, the delay variation in the IOB is cancelled when writing. > Writing data becomes a walk in the park. > That's right. Writing is always the easy part. When you generate the clock from the FPGA then that clock and data will always remain stable in relative phase. However, when you do this, the phase of the read data will now "drift" with respect to FPGA's internal clock. That's the problem. So, if you phase lock the output clock (and associated write data) by using the clock loop around technique then the read data will be locked, too. Of course, this all assumes that John needs to read the RAM. Maybe he's using it in WOM mode. ;-D Bob -- == All google group posts are automatically deleted due to spam ==Article: 142117
On Jul 23, 6:50=A0pm, Brian Davis <brimda...@aol.com> wrote: > > =A0Overall, I consider this corruption issue to be a much > more serious problem than does Peter. > > =A0Why? > > =A0Because any application that switches clock sources on > the fly without a-priori knowledge ( e.g. A/V, networking, > variable sample clocks ), or one that simply recovers > from DCM unlocks, CAN NOT SAFELY USE INITIALIZED BRAM !!! > I, too, consider it an ugly problem. But there is a very effective work-around: Disable the BRAM whenever you are not certain about the clock. You must already prevent a WE when the clock is unknown, so add the requirement for CE being inactive. Nobody is happy about this constraint, but it is very fundamental, and it has a 100% effectivework-around. It's just not obvious, and the FPGA vendors had to make you aware of it. Which we did. Peter Alfke, from home.Article: 142118
On Jul 25, 7:15=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Jul 23, 6:50=A0pm, Brian Davis <brimda...@aol.com> wrote: > > > =A0Overall, I consider this corruption issue to be a much > > more serious problem than does Peter. > > > =A0Why? > > > =A0Because any application that switches clock sources on > > the fly without a-priori knowledge ( e.g. A/V, networking, > > variable sample clocks ), or one that simply recovers > > from DCM unlocks, CAN NOT SAFELY USE INITIALIZED BRAM !!! > > =A0I, too, consider it an ugly problem. But there is a very effective > work-around: > Disable the BRAM whenever you are not certain about the clock. > You must already prevent a WE when the clock is unknown, so add the > requirement for CE being inactive. > Nobody is happy about this constraint, but it is very fundamental, and > it has a 100% effectivework-around. > It's just not obvious, and the FPGA vendors had to make you aware of > it. Which we did. > Peter Alfke, from home. i cant see the workaround be 100% in the case external clocks and DCM's are involved the code in FPGA can not foresee the ext clock to change and the DCM would go mad, and the ROM is corrupted... there are no crystal balls inside FPGA to forecast the coming in the future loss of external clock signal (to de-assert CE in time) i dont see ANY workaround for this, except that all DCM must be clocked from oscillators that are running all the time or then BRAMs can not be clocked from dcm/ext clock at all AnttiArticle: 142119
Antti wrote: > > i cant see the workaround be 100% in the case external clocks > and DCM's are involved > the code in FPGA can not foresee the ext clock to change > and the DCM would go mad, and the ROM is corrupted... > That is precisely the problem. > > there are no crystal balls inside FPGA to forecast the coming > in the future loss of external clock signal (to de-assert CE in time) > My 2007 explanation to Peter was that the hardware designer required PHD (Psychic Hardware Design) skills. http://groups.google.com/group/comp.arch.fpga/msg/a7723a92f8b90735 " " But real world clocking systems that monitor DCM status, " or perform automatic clock failovers, CAN NOT USE ENABLE " (OR AN ENABLED CLOCK) TO PROTECT BLOCK ROM CONTENTS!!! " " Unless, of course, you have mastered the obscure art of " Psychic Hardware Design, and can design clock enable logic " that knows ahead of time when the DCM will unlock, the DRO " suffer a phase hit, or the clock recovery PLL hiccup :) " > > i dont see ANY workaround for this, except that all DCM > must be clocked from oscillators that are running all the time > or then BRAMs can not be clocked from dcm/ext clock at all > Yes, or perhaps else scrubbed/ECC'd with one port. I have explained this aspect of the BRAM problem to Peter repeatedly over the past few years, but he continues to claim their "fix" is all that is needed. BrianArticle: 142120
On Jul 25, 12:05=A0pm, Brian Davis <brimda...@aol.com> wrote: > Antti wrote: > > > i cant see the workaround be 100% in the case external clocks > > and DCM's are involved > > the code in FPGA can not foresee the ext clock to change > > and the DCM would go mad, and the ROM is corrupted... > > =A0That is precisely the problem. > > > > > there are no crystal balls inside FPGA to forecast the coming > > in the future loss of external clock signal (to de-assert CE in time) > > My 2007 explanation to Peter was that the hardware designer > required PHD (Psychic Hardware Design) skills. > > http://groups.google.com/group/comp.arch.fpga/msg/a7723a92f8b90735 > " > " =A0But real world clocking systems that monitor DCM status, > " or perform automatic clock failovers, CAN NOT USE ENABLE > " (OR AN ENABLED CLOCK) TO PROTECT BLOCK ROM CONTENTS!!! > " > " =A0Unless, of course, you have mastered the obscure art of > " Psychic Hardware Design, and can design clock enable logic > " that knows ahead of time when the DCM will unlock, the DRO > " suffer a phase hit, or the clock recovery PLL hiccup :) > " > > > > > i dont see ANY workaround for this, except that all DCM > > must be clocked from oscillators that are running all the time > > or then BRAMs can not be clocked from dcm/ext clock at all > > =A0Yes, or perhaps else scrubbed/ECC'd with one port. > > =A0I have explained this aspect of the BRAM problem to Peter > repeatedly over the past few years, but he continues to claim > their "fix" is all that is needed. > > Brian C'mon, let's not get nasty. This is a deep-rooted "feature" in all Xilinx (and Altera) BlockRAMs, and I claim it has a solid work-around: Enable the clock only when you are interested in the read data output. Obviously, you don't really care about the read data when the clock is undefined and glitching. So make clock disable the default, and only enable the clock when you really care about the read data. I wish all problems had that good a work-around. Peter AlfkeArticle: 142121
Peter Alfke wrote: > C'mon, let's not get nasty. > This is a deep-rooted "feature" in all Xilinx (and Altera) BlockRAMs, > and I claim it has a solid work-around: > Enable the clock only when you are interested in the read data > output. > Obviously, you don't really care about the read data when the clock is > undefined and glitching. > So make clock disable the default, and only enable the clock when you > really care about the read data. This could be a little bit more difficult. E.g. imagine an AES3 receiver and sender: One example could be a BRAM with fixed AES3 status bits, which are embedded into the outgoing stream and the clock is derived from the input stream, which is the usual case in studios with one master clock. If the user pulls the plug, the clock gets unstable and the status bit BRAM gets corrupted. You are not interested in the content while the clock is not stable, but as soon as the user connects the plug again (someone came across the wire), the status bits are wrong. So I have to notify the CPU system about the event, hoping that it was not too short, so that the PLL unlock output was detected and then write the status bits BRAM again. I wasn't aware of this problem, now this means some work for workarounds for me, if this is possible with Altera parts, too. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142122
I've tested the XC9572XL to see how many logic you can implement with it and looks like quite some relative big designs for this small part are possible, e.g. a clock divider with two quadrature outputs and arbitrary duty cycle output: http://www.frank-buss.de/vhdl/advancedClock.html I hope it works in real hardware, too, so far I've tested it in the simulator, only. But I think the concept should be really portable for many devices, if they support triggering on both edges of a clock in different processes, and it should be glitch-free. Feel free to use this design, if you need it. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142123
On Jul 25, 1:54=A0pm, Frank Buss <f...@frank-buss.de> wrote: > Peter Alfke wrote: > > C'mon, let's not get nasty. > > This is a deep-rooted "feature" in all Xilinx (and Altera) BlockRAMs, > > and I claim it has a solid work-around: > > Enable the clock only when you are interested in the read data > > output. > > Obviously, you don't really care about the read data when the clock is > > undefined and glitching. > > So make clock disable the default, and only enable the clock when you > > really care about the read data. > > This could be a little bit more difficult. E.g. imagine an AES3 receiver > and sender: One example could be a BRAM with fixed AES3 status bits, whic= h > are embedded into the outgoing stream and the clock is derived from the > input stream, which is the usual case in studios with one master clock. I= f > the user pulls the plug, the clock gets unstable and the status bit BRAM > gets corrupted. You are not interested in the content while the clock is > not stable, but as soon as the user connects the plug again (someone came > across the wire), the status bits are wrong. So I have to notify the CPU > system about the event, hoping that it was not too short, so that the PLL > unlock output was detected and then write the status bits BRAM again. > > I wasn't aware of this problem, now this means some work for workarounds > for me, if this is possible with Altera parts, too. > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys= tems.de Interesting. So let's dig deeper: The problem is really not the clock glitch by itself. It is any uncontrolled address change during the metastable-catching timing window right before any rising clock edge (if the clock is enabled). So either: disable the clock, or keep the address constant for a set-up time prior to any rising clock edge or do both. In other words: Never use the internal BlockRAM address register as a synchronizer that might (occasionally) go metastable, and screw up the address decoder. Peter AlfkeArticle: 142124
On Jul 23, 6:21=A0pm, whygee <why...@yg.yg> wrote: > > hmmm.... It can be useful, I have no doubt about it, > but it's not very practical :-/ > I have examined Actel's method which, if not what I would > like to find, looks more solid. > > Maybe the next revisions of the family will include > a secret serial number in OTP, and challenge-based authentication > so update of the bitstream through the 'net could be safe, > or something along these lines ? > yg, not a cryptographer > --http://ygdes.com/http://yasep.org yg, I only described what has been implemented, and is publicly documented, guaranteed and supported. I did not mention things that are already implemented, but are so new and insufficiently tested, and thus not yet supported, and I did of course not mention features that we plan for the next generation. You seem to be interested in authentication, and not in encryption. That is understandable, and we expect to support that. Peter Alfke
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