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
Alex, > Could you elaborate why you can't use other low power CPLD's, Lattice > 4000Z, for example? I'm asking this question because in Lattice case > there is C code supplied for you to make the kind of CPLD programming > discussed in this thread very easy. just had a look at the datasheet and I see no technical reason at all not to use these - the devices are good. Can you please point me to the programming info available for them? If I can adopt them and thus forget about Xilinx I would be a happy man. Thanks, Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 20, 4:38 pm, Alex <engin...@gmail.com> wrote: > On Nov 19, 4:19 pm, Didi <didi...@gmail.com> wrote: > > > > > Well the fact of the matter is that there is no CPLD on the market > > > > to compete with all the coolrunner parameters at the same time - and > > > > I do use them. > > > > Across the size range, you may be right. > > > But at the highest volume end Atmel and Lattice have good low power > > > offerings. Actel may start to impact > 128MC CPLDs > > > I would be really happy to see an alternative to the coolrunner, > > especially if its documentation is less secretive. Until then, > > we are all stuck with xilinx for CPLDs above a certain complexity > > and below some power, which is why I am still trying to get some > > way to use them (notice I even accept to use their software to > > produce the jedec file, something unprecedented here). > > > > My understanding there is the parts were not externally foundry fab'd > > > and when the plug was pulled on the fab line, that then killed the > > > product line. ... > > > Well I do not find it very plausible - making a new coolrunner line > > from scratch cannot have been easier than repeating an existing > > product, mask sets and all being available. > > But whatever, their agreement with Philips was to support all > > existing customers the way Philips had supported them. > > This has not been the case with us - we do have the jedec -> jtag > > maps from Philips and we do not have these from Xilinx. > > > Dimiter > > > ------------------------------------------------------ > > Dimiter Popoff Transgalactic Instruments > > >http://www.tgi-sci.com > > ------------------------------------------------------ > > Hi Dimiter, > > Could you elaborate why you can't use other low power CPLD's, Lattice > 4000Z, for example? I'm asking this question because in Lattice case > there is C code supplied for you to make the kind of CPLD programming > discussed in this thread very easy. > > AlexArticle: 126376
Philipp Have a look at Broaddown4 http://www.enterpoint.co.uk/moelbryn/broaddown4.html. An alternative solution is the combination of our Broaddown2 (Spartan-3) with a add on Swinyard1 module. The Broaddown4 can support between 1-4(with 2 Swinyard1 modules) Virtex-4 LX40-160 or SX55 parts. Swinyard1 has a single Virtex-4 LX40-160 or SX55. Some outline details on our university program (UAP) is here http://www.enterpoint.co.uk/uap/uap.html. Discounts are listed there on some products, others are available, as are details of our Synplicity deal for universities where they effectively get a free license with a small pack of our low cost board Raggedstone1 and soon hopefully some others. John Adair Enterpoint Ltd. On 20 Nov, 16:04, Philipp <Patrick.Batema...@gmx.at> wrote: > austin wrote: > > Philipp, > > > Are you a university or school? If so, you should contact the XUP > > (Xilinx University Program). We often grant (gift), or partially fund > > university boards (like the Virtex II Pro board from Digilent that we > > will provide the FPGA on -- the school only pays for the pcb, not the FPGA). > > Thanks for your answer Austin, yes I am at university. So I will check > with the Xilinx University program. Unfortunately it seems that the > board you are offering is too small for my purposes. I would need > a evaluation board with at least a Virtex4 on it and around 25000 > to 30.000 slices. > > If anyone knows a good resource where I could get such a board I would > be thankful for some feedback ;) > > Cheers, > PhilippArticle: 126377
Hi,
I am using a Xilinx Virtex2 Board and would like
to have an instruction and data RAM. I was following
the guidelines in the XST 7.1 but there still must
be something wrong with my description. At the moment
around 16000 FF are inferred for my RAM. In addition
I get the warning that the rst and ram<$n0000> should be
in the sensitive list?
Cheers,
Philipp
library ieee;
use IEEE.std_logic_arith.all;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity ram_prog is
generic (
SIZE : integer := 512;
WL_ADDR : integer := 8;
WL_DATA : integer := 32
);
port (
clk : in std_logic;
rst : in std_logic;
rw_addr_cp0 : in std_logic_vector(WL_ADDR-1 downto 0);
data_in_cp0 : in std_logic_vector(WL_DATA-1 downto 0);
data_out_cp0 : out std_logic_vector(WL_DATA-1 downto 0);
ew_cp0 : in std_logic
);
end ram_prog;
architecture Behavior of ram_prog is
type ram_type is array (0 to SIZE-1) of std_logic_vector (31 downto 0);
signal ram : ram_type :=
(
X"15005304", X"2f501000", X"00000000",....
);
begin
PROC_ram : process (clk, rw_addr_cp0)
begin
if (rst = '0') then -- optional reset
data_out_cp0 <= (others => '0');
elsif (clk'event and clk = '1') then
-- memory write:
if (ew_cp0 = '1') then
if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <=
SIZE-1) then
ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
end if;
end if;
end if;
-- memory read:
if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <=
SIZE-1) then
data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
end if;
end process PROC_ram;
end Behavior;
Article: 126378On Tue, 20 Nov 2007 17:29:58 +0000, Philipp <Patrick.Bateman23@gmx.at> wrote: >Hi, > >I am using a Xilinx Virtex2 Board and would like >to have an instruction and data RAM. I was following >the guidelines in the XST 7.1 but there still must >be something wrong with my description. At the moment >around 16000 FF are inferred for my RAM. In addition >I get the warning that the rst and ram<$n0000> should be >in the sensitive list? ... > begin > PROC_ram : process (clk, rw_addr_cp0) > begin > if (rst = '0') then -- optional reset > data_out_cp0 <= (others => '0'); > elsif (clk'event and clk = '1') then > -- memory write: > if (ew_cp0 = '1') then > if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= >SIZE-1) then > ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0; > end if; > end if; > end if; > > -- memory read: > if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= >SIZE-1) then > data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0))); > end if; > end process PROC_ram; > >end Behavior; Are you sure you can reset memory? You also don't need the address on the sensitivity list either.Article: 126379
mk wrote: > On Tue, 20 Nov 2007 17:29:58 +0000, Philipp <Patrick.Bateman23@gmx.at> > wrote: > >> Hi, >> >> I am using a Xilinx Virtex2 Board and would like >> to have an instruction and data RAM. I was following >> the guidelines in the XST 7.1 but there still must >> be something wrong with my description. At the moment >> around 16000 FF are inferred for my RAM. In addition >> I get the warning that the rst and ram<$n0000> should be >> in the sensitive list? > ... >> begin >> PROC_ram : process (clk, rw_addr_cp0) >> begin >> if (rst = '0') then -- optional reset >> data_out_cp0 <= (others => '0'); >> elsif (clk'event and clk = '1') then >> -- memory write: >> if (ew_cp0 = '1') then >> if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= >> SIZE-1) then >> ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0; >> end if; >> end if; >> end if; >> >> -- memory read: >> if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= >> SIZE-1) then >> data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0))); >> end if; >> end process PROC_ram; >> >> end Behavior; > > Are you sure you can reset memory? You also don't need the address on > the sensitivity list either. Yeah true, I have to get rid of the read address in the sensitivy list, this is some knickknack of former implementations.Article: 126380
I just asked this question a couple of days ago. For the complete answer and process, refer to my "EDK 9.1 Issues" post from 11-15-07. ---Matthew Hicks > Hi all, I'm experiencing problems with adding custom logic to an IP > core that I have generate in EDK. I changed the vhdl file of an auto- > generated IP core that is connected via FSL to the FPGA, but the > behaviour of the program remains still the same. I've tried also to > re- > import the modified core to the project, but I still get errors due to > the fact that the file xparameters.h doesn't contains the appropriated > names. > How can I do to let EDK notice changes in vhdl files? > Thank you in advance! > Giulio >Article: 126381
Yeah, I made extra sure this was happening. Somehow, I've now got it to read and write up to 64 registers. ---Matthew Hicks > Matthew Hicks wrote: > >> I have created a custom peripheral in EDK 9.1/ISE 9.1 that needs to >> have 100 registers and communicates with the PowerPC CPU via the PLB >> bus. >> > [snip] > >> Therefore, I selected 32 registers and tried to change the >> USER_NUM_CE >> constant in the top-level module in the >> created template to 128, as opposed to 32. I have read the PLB IPIF >> datasheet from Xilinx, which only says that USER_NUM_CE needs to be a >> power of two, which is why I used 128 versus 100. After >> implementation, >> access to any register above 32 leads to a returned value of zero, >> when >> it should be non-zero. Any suggestions of what else I need to change >> in >> the generated IPIF code to get this working? > The wizard generates 2 files, the top file and the user logic file. > Make sure that the constants are set up correctly in both files. > > --- > JoeArticle: 126382
> Yeah true, I have to get rid of the read address in the sensitivy list,
> this is some knickknack of former implementations.
Alright, corrected some mistakes and now it seems fine :)
begin
PROC_ram : process (clk, rw_addr_cp0)
begin
if (clk'event and clk = '1') then
-- memory write:
if (ew_cp0 = '1') then
ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
end if;
if (rst = '0') then -- optional reset
data_out_cp0 <= (others => '0');
else
data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
end if;
end if;
end process PROC_ram;
Cheers,
Philipp
Article: 126383I am not able to run the fpga_editor (64-bit ISE install) under my Fedora 7, x86_64 system. After I set the DISPLAY variable to :0 (instead of my :0.0 or :0.1) and trying to start it, I get following output: /opt/xilinx_92/bin/lin64/_fpga_editor: Symbol `_XtperDisplayList' causes overflow in R_X86_64_PC32 relocation /opt/xilinx_92/bin/lin64/_fpga_editor: Symbol `_XtGetPerDisplayInput' causes overflow in R_X86_64_PC32 relocation Cannot register service: RPC: Authentication error; why = Client credential too weak unable to register (registryProg, registryVers, tcp) Wind/U Error (248): Failed to connect to the registry on server workstation.cholunna.local Warning!!: XKEYSYMDB environment variable is set to a wrong location Cannot register service: RPC: Authentication error; why = Client credential too weak Overriding Xilinx file <helpmap/fpga_editor.map> with local file </opt/xilinx_92/data/helpmap/fpga_editor.map> Is there any chance to make it running? Does it run at least in 32-bit ISE install? Before I used 32-bit ISE 8.2 on the same system and fpga_editor worked fine. By the way, why FPGA editor is still Windows application running under Wind/U environment while the rest of Xilinx tools run native in Linux? I do not understand. Thanks, JanArticle: 126384
On Fri, 16 Nov 2007 17:22:34 -0800, rickman wrote: > I am looking at a low end Dell laptop, the Vostro 1500, as a new > computer for work. I may supplement this later with a new desktop unit > for crunching FPGA designs, but I will also be using this laptop for > this sort of work. I am looking for advice on the differences in CPUs > for FPGA work and anything else that is relevant. > > I know that parallel ports are going the way of the serial port and the > dodo bird, but I can live with that. Most tools are available as USB > devices now. > > This particular computer comes with WindowsXP rather than Vista. From > what I have heard, that is an advantage. But I notice that the internal > bluetooth adapter is specific for XP and others from Dell are specific > for Vista. Any idea what is up with that? Is there any significant > advantage to using XP pro over XP home? > > This machine also has the "Intel(R) Integrated Graphics Media > Accelerator X3100". Is that just another way of saying "integrated > video"? Several of my other machines have had integrated video and it > does seem to drag down the CPU noticeably. Any idea if I will notice > the drag on the Core 2 Duo? They also offer an Nvidia Gforce 8400 GS > adapter for $100 and an 8600 for $200 more. Any idea if these are worth > it? The 1500 says it has "VGA video output & S-Video". Does that mean > I can connect two monitors for dual display? > > The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various > processors for significant money. The first stepup is to a T5470 (1.6 > GHz) for $75 and others range up to $575! I am thinking I can live with > the slower processor. The memory is 2GB. > > I was looking at the Vostro 1000 earlier this week with an AMD TK-53 > processor (1.5 GHz, 512 KB cache) and a smaller hard drive. It was $50 > more so the 1500 looks like the better deal. Are there any significant > differences in the two CPUs for FPGA work? I guess the small cache of > the TK-53 would make it significantly slower for FPGA work. > > I saw a thread from earlier this year discussing some of this. I wonder > how much laptops have improved since then. I'm waiting until January when the Penryns come out. The Penryns have 6M caches and amazingly low power. NCVerilog seems to be very sensitive to cache size, my benchmarking shows dramatic performance increases with each jump in cache size. I don't know if we've reached the point of diminishing returns after 4M but it seems like it would be worth the wait for the 6M Penryns to find out.Article: 126385
Didi wrote: > Jim, > > >>Do you have the xsvf file size handy, for your XC2C64 design ? >>That would give Didi some info on the svf pathway. >>(to go with the player info you've given) > > > I am quite sure I can reproduce the entire chain of hoops > in xapp058. It would allow me to eventually reverse engineer > their jedec -> jtag mapping in a matter of days or may be > weeks if I want to include more devices. > The "impact" tool Antonio is using is not available on the > xilinx website, but I am sure I could find it as well, it > must be out there. > Yet the question remains - _why_ do they keep the mapping > data secret? With the SVF pathway, it is not entirely secret. The info IS all there, in an ASCI file, just not in the most uC-friendly way. A middle pathway could be a ' uC compressed SVF', where you get the revision pathway of SVF, but not so much of the size penalty ?. Or even a stripped SVF, that has only the data in the transport-order, but that loses revsion features, and hard codes the device into your uC. The code sizes quoted for players were not huge, and a simple token-compressed player could be smaller. > I predicted we may wait for a century or so > for a plausible answer - the first one we got from their > CPLD support is more arrogant than it is ridiculous. Who > does this person think is talking to, housewifes? :))))) !!! ROFL No, but I suspect students ? They must have the mapping info, as part of their JED2SVF pathways, in a compilable (likely C tables?) form. So, perhaps they could release that ? They release the SVF player source code ? Treat this as an optional piece ? -jgArticle: 126386
> > I predicted we may wait for a century or so > > for a plausible answer - the first one we got from their > > CPLD support is more arrogant than it is ridiculous. Who > > does this person think is talking to, housewifes? > > :))))) !!! ROFL > > No, but I suspect students ? > > They must have the mapping info, as part of their JED2SVF > pathways, in a compilable (likely C tables?) form. Of course they do. I have it for the Philips Coolrunner. And I still have my extraction scripts - I used to edit/copy each of a few excel pages and turn them into text, then the text got processed by a DPS script into something I could simply put somewhere within a source file. > So, perhaps they could release that ? > They release the SVF player source code ? It is generally irrelevant which they will release - the excel, the source lookup table, whatever. They are not after the cash they make on having these data secret, it is negligible for their size. It must be something else - the answer to the _why_ question from above, next answer they have may be good enough for students (I disagree with you, the first one was only good for housewives :-) ). Which will bring us 2 answers closer to the century it will take them to come up with a plausible answer. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 20, 9:13 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Didi wrote: > > Jim, > > >>Do you have the xsvf file size handy, for your XC2C64 design ? > >>That would give Didi some info on the svf pathway. > >>(to go with the player info you've given) > > > I am quite sure I can reproduce the entire chain of hoops > > in xapp058. It would allow me to eventually reverse engineer > > their jedec -> jtag mapping in a matter of days or may be > > weeks if I want to include more devices. > > The "impact" tool Antonio is using is not available on the > > xilinx website, but I am sure I could find it as well, it > > must be out there. > > Yet the question remains - _why_ do they keep the mapping > > data secret? > > With the SVF pathway, it is not entirely secret. > > The info IS all there, in an ASCI file, > just not in the most uC-friendly way. > > A middle pathway could be a ' uC compressed SVF', where > you get the revision pathway of SVF, but not > so much of the size penalty ?. > > Or even a stripped SVF, that has only the data in the > transport-order, but that loses revsion features, > and hard codes the device into your uC. > > The code sizes quoted for players were not huge, > and a simple token-compressed player could be smaller. > > > I predicted we may wait for a century or so > > for a plausible answer - the first one we got from their > > CPLD support is more arrogant than it is ridiculous. Who > > does this person think is talking to, housewifes? > > :))))) !!! ROFL > > No, but I suspect students ? > > They must have the mapping info, as part of their JED2SVF > pathways, in a compilable (likely C tables?) form. > > So, perhaps they could release that ? > They release the SVF player source code ? > Treat this as an optional piece ? > > -jgArticle: 126387
Didi wrote: > Alex, > > >>Could you elaborate why you can't use other low power CPLD's, Lattice >>4000Z, for example? I'm asking this question because in Lattice case >>there is C code supplied for you to make the kind of CPLD programming >>discussed in this thread very easy. > > > just had a look at the datasheet and I see no technical reason at all > not to use these - the devices are good. > Can you please point me to the programming info available for them? > > If I can adopt them and thus forget about Xilinx I would be a happy > man. The only design oversight I recall from Lattice, is that they do NOT have pin-configurable Pullups - the config is global. [IIRC Xilinx and Atmel, do Pin-level select of Pullup, and also Schmitt] So, for very low power designs, you'd set no-pull-ups, and selective external resisitors ( a single pin held the wrong-way, adds up to 150uA ) Data: ["All of the I/Os and dedicated inputs have the capability to provide a bus-keeper latch, Pull-up Resistor or Pull-down Resistor. A fourth option is to provide none of these. The selection is done on a global basis. The default in both hardware and software is such that when the device is erased or if the user does not specify, the input structure is configured to be a Pull-up Resistor."] -jgArticle: 126388
Didi wrote: >>>I predicted we may wait for a century or so >>>for a plausible answer - the first one we got from their >>>CPLD support is more arrogant than it is ridiculous. Who >>>does this person think is talking to, housewifes? >> >>:))))) !!! ROFL >> >>No, but I suspect students ? >> >>They must have the mapping info, as part of their JED2SVF >>pathways, in a compilable (likely C tables?) form. > > > Of course they do. I have it for the Philips Coolrunner. > And I still have my extraction scripts - I used to edit/copy > each of a few excel pages and turn them into text, then > the text got processed by a DPS script into something I could > simply put somewhere within a source file. So you would be quite happy with a portion of JED2SVF, as a source table - for further 'rework' ? > > >>So, perhaps they could release that ? >>They release the SVF player source code ? > > > It is generally irrelevant which they will release - the excel, > the source lookup table, whatever. > They are not after the cash they make on having these data secret, > it is negligible for their size. > It must be something else - the answer to the _why_ question > from above, next answer they have may be good enough for > students (I disagree with you, the first one was only good > for housewives :-) ). Which will bring us 2 answers closer to the > century it will take them to come up with a plausible answer. Big companies have their own inertias and procedures, so it is best to figure out why, and find a way around that :) In this case, I can see that a separate pgm-info PDF, has a separate sign-off procedure, and also has a risk and support cost. The JED2SVF and SVF itself is already released, so they are happy with that level. All I see it needs is either a) The JED mapping table to be also released. Advantage here is that is a proven table, as it is already part of a proven & existing released flow (Impact/JED2SVF), so there are no QC costs. The tables auto-revise with new devices. A designer would take the SVF JEDEC state infos, and port those into the uC, but be able to use the tables to morph a JED. or b) (take a little SW engineering) Make the JED2SVF impact flow, so it can also create a fuse-linear file. Besides the Eng. time, this can get a little trickier, as sometimes fuse arrays have 'don't care, or read-stuck' gaps and portions in them. Getting thst info in there could be a challenge. If I were Xilinx, I'd choose a) :) Comments Peter / Jesse ? PS : Did I see some comment earlier about Xilinx open-sourcing their Impact programming flows ? [That also encompasses a) ] -jgArticle: 126389
A substantial amount of work is required for each appication when we move away from Wind/U. We have decided not to do that for FPGA Editor. Instead, we are creating a new application that is a combination of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be available in 11.1 (March 2009). Steve "Jan Pech" <no@spam.please> wrote in message news:1195582646.3063.9.camel@workstation.cholunna.local... > > By the way, why FPGA editor is still Windows application running under > Wind/U environment while the rest of Xilinx tools run native in Linux? I > do not understand. > > Thanks, > Jan >Article: 126390
> So you would be quite happy with a portion of JED2SVF, > as a source table - for further 'rework' ? Not sure - I have to see it. The lookup table would do, but the utility - no, it would only provide a way to reverse engineering the table, which can be pretty bulky. > Besides the Eng. time, this can get a little trickier, > as sometimes fuse arrays have 'don't care, or read-stuck' > gaps and portions in them. Getting thst info in there > could be a challenge. Indeed so. This info is needed as well. The simplest way for everyone would be just handing me the Excel files, no more questions asked guaranteed by my signature, NDA if necessary, too. I know my way from there. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 20, 10:59 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Didi wrote: > >>>I predicted we may wait for a century or so > >>>for a plausible answer - the first one we got from their > >>>CPLD support is more arrogant than it is ridiculous. Who > >>>does this person think is talking to, housewifes? > > >>:))))) !!! ROFL > > >>No, but I suspect students ? > > >>They must have the mapping info, as part of their JED2SVF > >>pathways, in a compilable (likely C tables?) form. > > > Of course they do. I have it for the Philips Coolrunner. > > And I still have my extraction scripts - I used to edit/copy > > each of a few excel pages and turn them into text, then > > the text got processed by a DPS script into something I could > > simply put somewhere within a source file. > > So you would be quite happy with a portion of JED2SVF, > as a source table - for further 'rework' ? > > > > >>So, perhaps they could release that ? > >>They release the SVF player source code ? > > > It is generally irrelevant which they will release - the excel, > > the source lookup table, whatever. > > They are not after the cash they make on having these data secret, > > it is negligible for their size. > > It must be something else - the answer to the _why_ question > > from above, next answer they have may be good enough for > > students (I disagree with you, the first one was only good > > for housewives :-) ). Which will bring us 2 answers closer to the > > century it will take them to come up with a plausible answer. > > Big companies have their own inertias and procedures, so it is > best to figure out why, and find a way around that :) > > In this case, I can see that a separate pgm-info PDF, has a separate > sign-off procedure, and also has a risk and support cost. > > The JED2SVF and SVF itself is already released, so they are > happy with that level. > > All I see it needs is either > > a) The JED mapping table to be also released. > Advantage here is that is a proven table, as it is > already part of a proven & existing released flow (Impact/JED2SVF), > so there are no QC costs. The tables auto-revise with new devices. > > A designer would take the SVF JEDEC state infos, and port those > into the uC, but be able to use the tables to morph a JED. > > or > b) (take a little SW engineering) > > Make the JED2SVF impact flow, so it can also create a > fuse-linear file. > Besides the Eng. time, this can get a little trickier, > as sometimes fuse arrays have 'don't care, or read-stuck' > gaps and portions in them. Getting thst info in there > could be a challenge. > > If I were Xilinx, I'd choose a) :) > > Comments Peter / Jesse ? > > PS : Did I see some comment earlier about Xilinx open-sourcing their > Impact programming flows ? [That also encompasses a) ] > > -jgArticle: 126391
older version of libXt.so is needed to run WindU based programs like FPGAEditor see Answer Record for details http://www.xilinx.com/support/answers/22022.htm On Nov 20, 3:22 pm, <steve.l...@xilinx.com> wrote: > A substantial amount of work is required for each appication when we > move away from Wind/U. We have decided not to do that for FPGA > Editor. Instead, we are creating a new application that is a combination > of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be > available in 11.1 (March 2009). > > Steve > > "Jan Pech" <n...@spam.please> wrote in message > > news:1195582646.3063.9.camel@workstation.cholunna.local... > > > > > By the way, why FPGA editor is still Windows application running under > > Wind/U environment while the rest of Xilinx tools run native in Linux? I > > do not understand. > > > Thanks, > > JanArticle: 126392
Didi wrote: > The "impact" tool Antonio is using is not available on the > xilinx website, Sure it is! It's part of WebPACK, which is avaiable for download at no charge.Article: 126393
On Nov 19, 3:54 am, Guru <ales.gor...@email.si> wrote: > > About the display: 15.4" in not enough for a real work. > You should better buy a 17", your eyes would be pleased. > As they say: integrated graphic card is OK if you do not use 3D > programs. Yes, I am a big fan of large displays. But I don't want to get Vista. The only machines I have found that come with XP are Dell Vostro (or the much more expensive business models) and they don't provide XP with the 17 inch models for some reason. I even mentioned to the guy on the phone that they would be losing a sale because of this and he said he would pass that on. Actually, I am very impressed with the Vostro 1500 models in terms of price and functionality. Even the 1700 model (17 inch display) is a pretty good buy at around $850, but my understanding is that Vista uses so much memory that 2 GB is not a lot. Buying ram from them is absurdly high so I don't want to have to go above the 2 GB that come with the machine... what ever happened to the days of 640 kB being a lot of RAM??? How fast do you think XST would run if it was rewritten to work with mag tape?Article: 126394
On Nov 20, 1:36 pm, General Schvantzkoph <schvantzk...@yahoo.com> wrote: > > I'm waiting until January when the Penryns come out. The Penryns have 6M > caches and amazingly low power. NCVerilog seems to be very sensitive to > cache size, my benchmarking shows dramatic performance increases with > each jump in cache size. I don't know if we've reached the point of > diminishing returns after 4M but it seems like it would be worth the wait > for the 6M Penryns to find out. Yes, I hope I can wait. But I expect the Penryns to be priced out of my range. I also don't have any confidence that they will be out at any given time. Intel may be shipping in January, but that doesn't mean they will appear in any laptops other than very high end for a while longer.Article: 126395
Hi! I am using Dual Port Block Memory in Virtex-II, V8.2. During simulation in Modelsim, i have encountered an error that reports to me is: $recovery(posedge clk B: .... ps, posedge clk A &&& collision_posa_posb: ... ns, 1ns); How can i cater this issue and how can i remove this error in my simulation??? Regards RaiArticle: 126396
Hi, I have just begin my PhD on SDR and I will have to use a FPGA with partial dynamic reconfiguration. The system which interest me have a Xilinx Virtex-4 SX35 integrated on it and I'm not sure this FPGA can do it. If someone could answer me, it'll be great. Thanks.Article: 126397
On Nov 21, 4:49 am, Eric Smith <e...@brouhaha.com> wrote: > Didi wrote: > > The "impact" tool Antonio is using is not available on the > > xilinx website, > > Sure it is! It's part of WebPACK, which is avaiable for download at no > charge. Oh I see, my mistake, thanks. I have not used their software yet, so I don't know it in much detail. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 126398
Hi, I'm using Xilinx 8.2.03i and I get an Error Xst:528 "Multi-source in Unit ..." It's a wire in a submodule and i checked the code: The signal is an output to module A and an input to module B. There is no other assignment to this signal. Inside module B the signal is only on the right-side of any "=" assignments. Could there be a bug in Xst when using a design containig both VHDL and verilog files? TimoArticle: 126399
steve.lass@xilinx.com wrote: > A substantial amount of work is required for each appication when we > move away from Wind/U. We have decided not to do that for FPGA > Editor. Instead, we are creating a new application that is a combination > of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be > available in 11.1 (March 2009). Steve, did Xilinx consider Wine as a portablility layer for programs written in the windows API? Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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