Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Aug 6, 11:38 am, Andy Peters <goo...@latke.net> wrote: > On Aug 4, 4:04 am, Eli Billauer <e...@billauer.co.il> wrote: > > > > > Hello, > > > I would like to utilize a controller for a SINGLE data rate SDRAM > > (Micron MT48LC16M16A2TG-75, to be specific). In the past I've used > > Xilinx' MiG 1.4 to obtain a DDR2 controller, which I ended up pretty > > happy with (after forgetting the via dolorosa to set it up...). Its > > main benefit is a simple and convenient FIFO-based user interface. > > > For some reason, I thought that MiG would create an SDR controller as > > well (it's simpler, after all), but it turned out I'm very wrong: The > > last piece of attention on Xilinx' behalf to SDR, which I've managed > > to find, is xapp134. That paper, along with its HDL code, originates > > in 1999, and is more or less the same ever since. The controller > > offered is hence adapted to Virtex-I and Spartan-II, and is yucky is > > several respects. > > > Newer application notes (as well as MiG) relate to faster memory > > classes (DDR, DDR2, QDR, you name it), with controllers eating up some > > clock resources to solve timing problems. And all I wanted was a cheap > > memory with reasonably simple access. > > > Given the situation, I'm considering to create a DDR controller with > > MiG for a memory with similar attributes (bus width, array size, etc) > > and then hack it down to SDR. Since the command interface is the same, > > that should leave me with changing the data flow, and make the burst > > timing right. Not much fun, but hey, after debugging the MiG DDR > > controller, I should survive this one as well. > > > And here's the irony: I picked this SDRAM to make things simpler for > > me. > > > So before I start this little self torture, does anyone have a better > > idea? > > I'm with Martin. Write your own SDRAM controller from scratch. It's > really not difficult, and you can optimize it for your particular > application. It shouldn't take more than a couple of days to write, > simulate and verify it. > > -a I'm in agreement also, having written a number of them. 20% of the work is getting the timing to the DRAM chip. 80% of the work is getting the right rows open for -your- access requirements. Snag the simulation model from the Micron web site before they tear them down. G.Article: 122951
Hi, Where can one get used Stratix II FPGA's. Thanks, Eswar Saladi email : eswar.saladi@gmail.comArticle: 122952
pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: >Hi > >I want to use in my project (with Spartan3 or Cyclone2) a DDR/DDR2 DIMM >module. I have chosen DDR because is avaiable and cheaper than SDR. >I have no experience with memory controllers and not to big with FPGA, >that's why I don't know which design solution to choose. >I don't need fast data rate (least possible is enough to me) > >I have considered MegaCore function from Altera or solution provide by >Xilinx > >After I read documentation to DDR/DDR2 interface core provide by Xilinx I >have impression that they do it only to prove that it's possible to >interface DDR with their fpgas, but they give no guarantee it will by >works. Am I wrong? No. There is no free usefull DDR core. >And MIG don't support DIMMs for Spartan3. Precisely. Besides the Spartan 3 DDR controller made by the MIG tool is huge and hopeless. You'll have to be carefull though with connecting too many datalines to a Spartan 3. The power consumption of the IO is huge for driving DDR memory. You'll need an FPGA in a BGA package if you want to connect a DIMM. >I consider too make my own DDR/DDR2 controller. I have read DDR2 >specification and it seems complicated. But maybe if I make it for >particular DDR2 module it will be more easier and take less LE or LUTs. > >Have anyone experience with solution that I mentioned? >Or maybe someone may suggest me another solution? >Any help is appreciated. Designing a controller is not so difficult if you are after writing/reading bursts of data. A small hint: the DDR controller can be clocked at half the DDR clock frequency. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 122953
Nico Coesel wrote: > You'll have to be carefull though with > connecting too many datalines to a Spartan 3. The power consumption of > the IO is huge for driving DDR memory. You'll need an FPGA in a BGA > package if you want to connect a DIMM. Even if data rate will by small? I have not consider this aspect before, thanks for advice. > Designing a controller is not so difficult if you are after > writing/reading bursts of data. I am not sure I understand this sentence: "if you are after writing/reading bursts of data" What you mean? PGWArticle: 122954
Thank you all for your help, I managed to get a slight performance improvement by some minor modifications of the configurations. I guess you are right, the platform design is my main problem. Unfortunately I was unable to find one to directly work with my board, as the GSRD2 design provided by xilinx won't work on my Memec V4FX12 LC board without modifications. Thank you for offering sending it to me Guru, unfortunately for me it's a bit late now, but if you could upload it to me anyway for my future designs, I'd be greateful. Will it work on my Memec board? Or do you know what kind of changed will require to work? Thanks in advanceArticle: 122955
On 8 Aug, 19:12, moo...@yahoo.co.uk wrote: > Hi, > > Can someone please point me in the right direction. > > I attempted to define my LVDS inputs via the UCF file for my Xilinx > spartan xc3s1500. > > NET data_in LOC = F19 | IOSTANDARD = LVDS_25 ; > > the Xilinx answer record impies that this will work OK. > > http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=8187 > > Unfortunately I get the following warning, and the input is set to a > standard LVCMOS25. > > WARNING:Pack:946 - The I/O component data_in has an illegal I/O > standard value. Components of type IOB do not support I/O standard > LVDS_25. > Please correct the IOSTANDARD property value. > > I am using ISE 8.2 (Release 8.2.03i Map I.34) > > Any ideas what I am doing wrong? Do I need to istantiate the I/O > buffers? > > Thanks for any input, > > Steven Thanks for all the responses. I instantiated the buffers directly in the HDL with no problems. I know that the S/W is "free", but I don't know why the documentation implies that you can just specify the buffers in the UCF (I had the same issue with BUFG's). Anyway, thanks again, StevenArticle: 122956
Albert Nguyen wrote: > John, > > I have been taking hunt and pack approach in locating the internal signals of the fpga fabric - for example looking at the intermiediate files etc. I felt that there may be a better way to do this. This is why I wanted to pose this question on this forum. It just seems that if there is no direct way then that is a problem that should be fixed. > > Albert The synthesis tools usually have reports when logic is changed from the RTL to an "optimized" form. Since you are allowing state machine optimization, take a look at the reports that are generated by the synthesis tools. If you're in unix, you could grep on the state machine bit names and probably find a line that states the conversion happened *and* perhaps what the new names are. Which synthesizer are you using? XST?Article: 122957
Insert an output signal into each state. <Albert Nguyen> wrote in message news:eea895b.-1@webx.sUN8CHnE... >I am using VCS compiler to do the Xilinx FPGA timing simulation. I have 16 >bit state machine in one of my verilog submodule. I am able to do the >timing simulation but not sure the exact proecdure in locating the internal >state machine and be able to see on the waveform viewer. > > AlbertArticle: 122958
John, I am using XST Synthesis tool on Linux. But we also have Synplify from Synplicity. You mentioned about doing a grep. You do this on .ncd or .ngd file? AlbertArticle: 122959
Albert Nguyen wrote: > John, > > I am using XST Synthesis tool on Linux. But we also have Synplify from Synplicity. You mentioned about doing a grep. You do this on .ncd or .ngd file? > > Albert I don't know the XST synthesis report files since I strictly use Synplicity tools. The .ncd and .ngd are not report files so they would not include user-readable information. Run XST synthesis and check what files are generated by the tool (by looking at the time stamps) and grep anything that looks like a report file.Article: 122960
pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: >Nico Coesel wrote: > >> You'll have to be carefull though with >> connecting too many datalines to a Spartan 3. The power consumption of >> the IO is huge for driving DDR memory. You'll need an FPGA in a BGA >> package if you want to connect a DIMM. > >Even if data rate will by small? >I have not consider this aspect before, thanks for advice. SDRAM, DDR and DDR2 have a minimum clock frequency. This means the datarate cannot be choosen very small. >> Designing a controller is not so difficult if you are after >> writing/reading bursts of data. > >I am not sure I understand this sentence: "if you are after >writing/reading bursts of data" >What you mean? Designing a memory controller which transfers large blocks of data is much easier (the addresslines are driven by a counter) than a random-access memory controller (address lines need to be translated, transactions must be queued). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 122961
Peter Alfke <alfke@sbcglobal.net> writes: > AFAIK you can order Virtex-5 parts from the two major distributors, > Avnet and NewHorizon. > That was a contentious issue a few months ago, that seems to be > resolved now. > I still have some scars from that internal battle. So is there any reason why Xilinx employees that *don't* think that customers should be able to get parts through distribution are still on the payroll? Seems like a good opportunity for Xilinx to cut costs. If you can't fire them outright, send them on the B Ark or something.Article: 122962
I wanted to add to the thread at http://groups.google.co.uk/group/comp.arch.fpga/browse_thread/thread/336b60da5f0091/c7add911f6079243?lnk=st&q=TLENOMADE&rnum=2&hl=en# subject: does SRL exist in non-xilinx FPGAs? But i got the message: replies are not allowed ? i really don't why? and who adds this constraint. as such i am opening this thread as a follow up to the previous posts at the above link. here is my message I have just realised that Lattice LUT can be configured as 16x1 bit RAM (<http://www.latticesemi.com/documents/DS1004.pdf> , page 9). Is this an infringement to the above cited Xilinx Patents? If not why Altera have not equipped their LUT with the same capability? They have instead in startix-3 the 640-bit Memory LAB(MLAB) which can be seen(i hope i am not mistaken) as 10 parallel altera LUTs. This is possible only thpugh in only half of the die If the lattice LUT RAM mode infringes the XILINX patent, it should be the same (IMHO) with ALtera MLAB The above in my opinion contradicts the claims that Xilinx is the unique FPGA device which provides distributed memory through their CLBs any thought please? Many thanks :)Article: 122963
On Aug 12, 4:58 pm, tlenom...@googlemail.com wrote: > I wanted to add to the thread athttp://groups.google.co.uk/group/comp.arch.fpga/browse_thread/thread/... > subject: does SRL exist in non-xilinx FPGAs? > > But i got the message: replies are not allowed ? i really don't why? This is an unmoderated newsgroup. You can write anything you want, from deeply scientific to disgustingly vulgar. It has all been done. Nobody canl allow or disallow that. Whether Xilinx should or will enforce its patents against Lattice is a matter too complex for this newsgroup. Anybody can obviously violate any patent anytime. The question is whether the legal patent owner will let him get away with it... Peter Alfke.Article: 122964
Eric, nobody wanted to prevent or sabotage this. As usual, the devil was in the details. Distributors are independent companies; some contracts needed amending, and we all know what happens at what speed when the lawyers get involved. But that is all behind us. It took some arm-twisting and a lot of patience. More than I am known for... Peter Alfke On Aug 12, 3:10 pm, Eric Smith <e...@brouhaha.com> wrote: > > So is there any reason why Xilinx employees that *don't* think that customers > should be able to get parts through distribution are still on the payroll? > Seems like a good opportunity for Xilinx to cut costs. If you can't fire > them outright, send them on the B Ark or something.Article: 122965
On Sat, 11 Aug 2007 04:24:12 -0700, "u_stadler@yahoo.de" <u_stadler@yahoo.de> wrote: >hi > >i have a question. do i have to edit the ucf file by hand in edk 9.1 >or is there a editor like in ise? i thought i could use the editor >from ise but my ucf file that i created with edk wont load.. > >thanks >urban Yes, you can use PACE or Constraints editor from ISE. Just open the program, and then open your files: ucf file as constraints file (located on your 'data' folder) and ngd file as design file (located in your 'implementation' folder). Of course, you first have to generatethe netlist... Best regards, ZaraArticle: 122966
hi all,
i have got one problem:
i have designed sonet sts-3c framer/deframer where it works at 155mhz
freq which i am getting it form the optics card whrere CDR(clock data
recovery circuit outside the board). form that circuit i am getting
the differential data and differetial clock as inputs and i am
processing for output (differential data). which iam sending it to
optics card which will convert the electrical diff data into optical
signal and it is recongniged in the OmniBer (performace analyzer). my
problem is as i am getting the data and the clock i have a problem in
detecting the output on OMNIBER but my logic looks quiet ok.
i am using virtex - 2pro fpga which can support 155mhz clock.......
i have done small experiment by looping it back the data ... with out
processign ... just what ever the optics card send the data (diff data
input) i am looping inside the fpga and sending it back ... that time
it detecting in omniber . but same exp if i am doing with respect to
clock i am unble to detect the framer in the omniber.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
-- synthesis translate_off
library unisim;
use UNISIM.Vcomponents.ALL;
-- synthesis translate_on
entity loopback is
port (
rxdata_in_p : in std_logic;
rxdata_in_n : in std_logic;
txdata_out_p : out std_logic;
txdata_out_n : out std_logic
);
end loopback;
architecture rtl of loopback is
signal txdata : std_logic;
signal txdata_out : std_logic;
signal rxdata_in : std_logic;
--
****************************************************************--
--
***************************IBUFDS******************************* --
--
****************************************************************--
component IBUFDS
port (O : out STD_ULOGIC;
I : in STD_ULOGIC;
IB : in STD_ULOGIC);
end component;
--
****************************************************************--
--
***************************OBUFDS******************************* --
--
****************************************************************--
component OBUFDS
port (
O : out STD_ULOGIC;
OB : out STD_ULOGIC;
I : in STD_ULOGIC);
end component;
-- Black box declaration --
attribute syn_black_box : boolean;
attribute syn_black_box of OBUFDS: component is true;
begin
--IBUFGDS_INSTANCE_NAME : IBUFGDS
--port map (O => clk155p52,
-- I => clk155p52_p,
-- IB => clk155p52_n);
IBUFDS_INSTANCE_NAME : IBUFDS
port map (O => rxdata_in,
I => rxdata_in_p,
IB => rxdata_in_n
);
txdata_out <= rxdata_in;
OBUFDS_INSTANCE_NAME : OBUFDS
port map ( O => txdata_out_p,
OB => txdata_out_n,
I => txdata_out
);
end rtl;
just what ever i am getting the diff data as input i am giving to
output that all to ensure that the fpga path is fine.if the same thing
i am doing wrt to the clock diff i am not able to detect the data send
in the omniber .
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
-- synthesis translate_off
library unisim;
use UNISIM.Vcomponents.ALL;
-- synthesis translate_on
entity loopback is
port (
porstn : in std_logic;
--clk155p52 : in std_logic;
clk155p52_p : in std_logic;
clk155p52_n : in std_logic;
rxdata_in_p : in std_logic;
rxdata_in_n : in std_logic;
txdata_out_p : out std_logic;
txdata_out_n : out std_logic
);
end loopback;
architecture rtl of loopback is
signal txdata_out : std_logic;
signal clk155p52 : std_logic;
signal rxdata_in : std_logic;
--
******************************************************************--
--
****************************IBUFGDS********************************--
component IBUFGDS
port (O : out STD_ULOGIC;
I : in STD_ULOGIC;
IB : in STD_ULOGIC);
end component;
--
****************************************************************--
--
***************************IBUFDS******************************* --
--
****************************************************************--
component IBUFDS
port (O : out STD_ULOGIC;
I : in STD_ULOGIC;
IB : in STD_ULOGIC);
end component;
--
****************************************************************--
--
***************************OBUFDS******************************* --
--
****************************************************************--
component OBUFDS
port (
O : out STD_ULOGIC;
OB : out STD_ULOGIC;
I : in STD_ULOGIC);
end component;
-- Black box declaration --
attribute syn_black_box : boolean;
attribute syn_black_box of OBUFDS: component is true;
--component sts3c_test
--port(
-- clk155p52 : in std_logic;
-- porstn : in std_logic;
-- dataout : out std_logic
-- );
-- end component;
begin
IBUFGDS_INSTANCE_NAME : IBUFGDS
port map (O => clk155p52,
I => clk155p52_p,
IB => clk155p52_n);
IBUFDS_INSTANCE_NAME : IBUFDS
port map (O => rxdata_in,
I => rxdata_in_p,
IB => rxdata_in_n
);
--sts3c_inst: sts3c_test
--port map (
-- clk155p52 => clk155p52,
-- porstn => porstn,
-- dataout => rxdata_in
-- );
process(porstn,clk155p52)
begin
if(porstn ='0') then
txdata_out <='0';
elsif(clk155p52'event and clk155p52='1') then
txdata_out <= rxdata_in;
end if;
end process;
OBUFDS_INSTANCE_NAME : OBUFDS
port map ( O => txdata_out_p,
OB => txdata_out_n,
I => txdata_out
);
end rtl;
is there is any proble with the clock i am getting form the optics
card..but when the same clock i have used it to process the frmaer
design i am getting the work done . but when i am using it for both
the framer and deframer logic i am not getting the data detected into
omniber (where it will detect the data send in the form of optics
signal in the omniber as SONET standard STS-3 framer/deframer).
what i am doing is i am getting data form omniber which is converted
into diff electrical signal and send to fpga board where i am i am
processign the data and i am catching the data and processig it and
sending it to omniber to detect the sonet framer in the omniber.
i am not understanding whethere it is logic prb inside the fpga or the
board problem or the clock which i am getting is not clean enough.
there are jitters in the clock but with this clock i am able to make
the framer deisgn one module to work but i am adding another module i
unalbe to detect the data in omniber.....
plz i need feedback from u guys
regards
srik
Article: 122967what's wrong with following word??? [root@localhost uClinux-dist]# make dep make ARCH=microblaze CROSS_COMPILE=mb- -C linux-2.4.x dep make[1]: Entering directory `/home/devel/uclinux/src/uClinux-2.4.x' rm -f .depend .hdepend make _sfdep_arch/microblaze/kernel _sfdep_arch/microblaze/mm _sfdep_arch/microblaze/lib _sfdep_arch/microblaze/xilinx_ocp _sfdep_arch/microblaze/platform/uclinux-auto _sfdep_kernel _sfdep_drivers _sfdep_mmnommu _sfdep_fs _sfdep_net _sfdep_ipc _sfdep_lib _sfdep_crypto _FASTDEP_ALL_SUB_DIRS="arch/microblaze/kernel arch/microblaze/mm arch/microblaze/lib arch/microblaze/xilinx_ocp arch/ microblaze/platform/uclinux-auto kernel drivers mmnommu fs net ipc lib crypto" make[2]: Entering directory `/home/devel/uclinux/src/uClinux-2.4.x' make -C arch/microblaze/kernel fastdep make[3]: Entering directory `/home/devel/uclinux/src/uClinux-2.4.x/ arch/microblaze/kernel' /home/devel/uclinux/src/uClinux-2.4.x/scripts/mkdep -D__KERNEL__ -I/ home/devel/uclinux/src/uClinux-2.4.x/include -Wall -Wstrict- prototypes -Wno-trigraphs -O1 -g -fno-strict-aliasing -fno-common - DPLATFORM=uclinux-auto -O3 -fno-builtin -DNO_MM -DNO_FPU -D__ELF__ - DMAGIC_ROM_PTR -DUTS_SYSNAME=\"uClinux\" -D__linux__ -I/include -mxl- barrel-shift -mno-xl-soft-div -mno-xl-soft-mul -I/home/devel/uclinux/ src/uClinux-2.4.x/arch/microblaze/xilinx_ocp -nostdinc -iwithprefix include -- bug.c crtinit.S entry.S exceptions.c head.S highres_timer.c hw_exception_handler.S init_microblaze_timer.c intv.S irq.c mach.c mach.h mbvanilla.c memcons.c microblaze.c microblaze_defs.c microblaze_defs.h microblaze_intc.c microblaze_ksyms.c microblaze_timer.c process.c procfs.c ptrace.c semaphore.c setup.c signal.c syscalls.c time.c xmbserial.c xmbserial.h > .depend realpath(/include) failed, No such file or directory make[3]: *** [fastdep] Error 1 make[3]: Leaving directory `/home/devel/uclinux/src/uClinux-2.4.x/arch/ microblaze/kernel' make[2]: *** [_sfdep_arch/microblaze/kernel] Error 2 make[2]: Leaving directory `/home/devel/uclinux/src/uClinux-2.4.x' make[1]: *** [dep-files] Error 2 make[1]: Leaving directory `/home/devel/uclinux/src/uClinux-2.4.x' make: *** [dep] Error 2Article: 122968
quote from Xilinx webpage: "Xilinx is upgrading its forum software. These forums, along all their content, will be retired on August 30th, 2007. Starting August 13th, you will be given an opportunity to move existing threads to our new forums. Thank you." today is 13th, I expected at least today that there will be more information about how to use the "new forums" - but unfortunatly NOTHING, is the new opportunity really only "for selected members of the community" who have received special invitations? Looks like. Xilinx I will not beg for this opportunity. I was just wondering, and wanted to check if Xilinx this time keeps the promise (use of new forums starting from 13th August 2007). Well 13th is not yet over there are a few hours left, even in Japan, so maybe the webmaster will open the access still today. Antti LukatsArticle: 122969
On 8 Aug., 03:30, austin <aus...@xilinx.com> wrote: > Symon, > > Well, all I can say, is that this is an attempt to improve our service. > Austin, please try todo something, so that "attempts" do not remain as "attempt" but lead somewhere too. Xilinx webpage reads that from 13th of august the messages from old forums can be moved to the new forums. This is not the case, I just posted on Xilinx old forums, and was not able to move the topic to the new forum. So the 13th August thing, (an attempt to impove service ?) - is at least delaying, or so it looks from the public web presence. It makes no sense to announce that something will happen on 13th, and then not do this this on the date promised. To me it seems like the attempt to launch the new forums on 13th have failed. Or maybe they are super secret ones? Antti LukatsArticle: 122970
On Mon, 13 Aug 2007 07:18:41 -0000, Antti <Antti.Lukats@googlemail.com> wrote: >On 8 Aug., 03:30, austin <aus...@xilinx.com> wrote: >> Symon, >> >> Well, all I can say, is that this is an attempt to improve our service. >> >Austin, > >please try todo something, so that "attempts" do not remain as >"attempt" but lead somewhere too. > >Xilinx webpage reads that from 13th of august the messages from old >forums can be moved to the new forums. > >This is not the case, I just posted on Xilinx old forums, and was not >able to move the topic to the new forum. > >So the 13th August thing, (an attempt to impove service ?) - is at >least delaying, or so it looks from the public web presence. > >It makes no sense to announce that something will happen on 13th, and >then not do this this on the date promised. > >To me it seems like the attempt to launch the new forums on 13th have >failed. > >Or maybe they are super secret ones? > >Antti Lukats Maybe it's that Aug 13th has not really started for real in PST yet and the change will happen by the end of monday California time?Article: 122971
On 13 Aug., 09:41, mk <kal*@dspia.*comdelete> wrote: > On Mon, 13 Aug 2007 07:18:41 -0000, Antti > > > > > > <Antti.Luk...@googlemail.com> wrote: > >On 8 Aug., 03:30, austin <aus...@xilinx.com> wrote: > >> Symon, > > >> Well, all I can say, is that this is an attempt to improve our service. > > >Austin, > > >please try todo something, so that "attempts" do not remain as > >"attempt" but lead somewhere too. > > >Xilinx webpage reads that from 13th of august the messages from old > >forums can be moved to the new forums. > > >This is not the case, I just posted on Xilinx old forums, and was not > >able to move the topic to the new forum. > > >So the 13th August thing, (an attempt to impove service ?) - is at > >least delaying, or so it looks from the public web presence. > > >It makes no sense to announce that something will happen on 13th, and > >then not do this this on the date promised. > > >To me it seems like the attempt to launch the new forums on 13th have > >failed. > > >Or maybe they are super secret ones? > > >Antti Lukats > > Maybe it's that Aug 13th has not really started for real in PST yet > and the change will happen by the end of monday California time?- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - yes, there are a few hours left, lets see and wait up AnttiArticle: 122972
On Sun, 12 Aug 2007 22:55:51 -0700, kobelai15@gmail.com wrote: >what's wrong with following word??? > >[root@localhost uClinux-dist]# make dep that you do that as root? GerhardArticle: 122973
On 13 Aug, 08:10, Antti <Antti.Luk...@googlemail.com> wrote: > quote from Xilinx webpage: "Xilinx is upgrading its forum software. > These forums, along all their content, will be retired on August 30th, > 2007. Starting August 13th, you will be given an opportunity to move > existing threads to our new forums. Thank you." > > today is 13th, I expected at least today that there will be more > information about how to use the "new forums" - but unfortunatly > NOTHING, is the new opportunity really only "for selected members of > the community" who have received special invitations? Looks like. US time perhaps?Article: 122974
Antti wrote: > quote from Xilinx webpage: "Xilinx is upgrading its forum software. > These forums, along all their content, will be retired on August 30th, > 2007. Starting August 13th, you will be given an opportunity to move > existing threads to our new forums. Thank you." > > today is 13th, I expected at least today that there will be more > information about how to use the "new forums" - but unfortunatly > NOTHING, is the new opportunity really only "for selected members of > the community" who have received special invitations? Looks like. > > Xilinx I will not beg for this opportunity. I was just wondering, and > wanted to check if Xilinx this time keeps the promise (use of new > forums starting from 13th August 2007). Well 13th is not yet over > there are a few hours left, even in Japan, so maybe the webmaster will > open the access still today. > > Antti Lukats Hi Antti, Whilst you are strictly correct, expecting to time a company like Xilinx, with a stopwatch, has to be the definition of optimism! :) -jg
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