Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 142100

Article: 142100
Subject: Re: Xilinx ISE 11.x lossage
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 24 Jul 2009 10:57:48 -0700
Links: << >>  << T >>  << A >>
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: 142101
Subject: Re: spartan-3 starter kit board JTAG-usb cable
From: gabor <gabor@alacron.com>
Date: Fri, 24 Jul 2009 14:20:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 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,
Gabor

Article: 142102
Subject: Re: FPGA development tools for FreeBSD?
From: Torfinn Ingolfsen <tingo@start.no>
Date: Fri, 24 Jul 2009 23:46:11 +0200
Links: << >>  << T >>  << A >>
Uwe Bonnes wrote:
> Dinotrace is another good waveform viewer

Also exists as a FreeBSD port:
http://www.freshports.org/cad/dinotrace/

Great!
-- 
Torfinn Ingolfsen,
Norway

Article: 142103
Subject: Re: FPGA development tools for FreeBSD?
From: Torfinn Ingolfsen <tingo@start.no>
Date: Fri, 24 Jul 2009 23:49:33 +0200
Links: << >>  << T >>  << A >>
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,
Norway

Article: 142104
Subject: Re: Almost everything about Virtex-6 in one location
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 24 Jul 2009 15:09:02 -0700
Links: << >>  << T >>  << A >>
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!

John



Article: 142105
Subject: Re: Xilinx ISE 11.x lossage
From: Andy Peters <google@latke.net>
Date: Fri, 24 Jul 2009 15:35:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

-a

Article: 142106
Subject: Re: spartan-3 starter kit board JTAG-usb cable
From: "alan@nishioka.com" <alan@nishioka.com>
Date: Fri, 24 Jul 2009 16:06:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx ISE 11.x lossage
From: "alan@nishioka.com" <alan@nishioka.com>
Date: Fri, 24 Jul 2009 16:25:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx ISE 11.x lossage
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Fri, 24 Jul 2009 16:59:35 -0700
Links: << >>  << T >>  << A >>
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 order


Article: 142109
Subject: Re: How to implementa an FSM in block ram
From: Brian Davis <brimdavis@aol.com>
Date: Fri, 24 Jul 2009 17:35:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Brian

Article: 142110
Subject: Re: FPGA development tools for FreeBSD?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sat, 25 Jul 2009 01:22:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: Spartan 3 and DDR2
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 24 Jul 2009 21:12:49 -0700
Links: << >>  << T >>  << A >>
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



Article: 142112
Subject: Re: Spartan 3 and DDR2
From: "BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com>
Date: Fri, 24 Jul 2009 23:27:05 -0700
Links: << >>  << T >>  << A >>

"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
Subject: Re: Spartan 3 and DDR2
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 25 Jul 2009 09:31:32 GMT
Links: << >>  << T >>  << A >>
"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: 142114
Subject: Re: FPGA development tools for FreeBSD?
From: Torfinn Ingolfsen <tingo@start.no>
Date: Sat, 25 Jul 2009 11:32:06 +0200
Links: << >>  << T >>  << A >>
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.

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,
Norway

Article: 142115
Subject: Re: FPGA development tools for FreeBSD?
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Sat, 25 Jul 2009 10:19:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: Spartan 3 and DDR2
From: "BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com>
Date: Sat, 25 Jul 2009 08:14:11 -0700
Links: << >>  << T >>  << A >>

"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
Subject: Re: How to implementa an FSM in block ram
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 25 Jul 2009 09:15:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: How to implementa an FSM in block ram
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 25 Jul 2009 10:19:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Antti





Article: 142119
Subject: Re: How to implementa an FSM in block ram
From: Brian Davis <brimdavis@aol.com>
Date: Sat, 25 Jul 2009 12:05:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Brian

Article: 142120
Subject: Re: How to implementa an FSM in block ram
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 25 Jul 2009 13:06:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Alfke

Article: 142121
Subject: Re: How to implementa an FSM in block ram
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 25 Jul 2009 22:54:28 +0200
Links: << >>  << T >>  << A >>
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.de

Article: 142122
Subject: advanced clock divider generator
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 25 Jul 2009 23:06:26 +0200
Links: << >>  << T >>  << A >>
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.de

Article: 142123
Subject: Re: How to implementa an FSM in block ram
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 25 Jul 2009 14:28:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Alfke

Article: 142124
Subject: Re: Almost everything about Virtex-6 in one location
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 25 Jul 2009 19:41:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search