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
Hi all,
In my design, the PC will read data from the Spartan II. I use a state
machine to keep track
the states of the read cycle:
IDLE: wait for PC's ready signal
PREPARE: put data on data line
SEND: raise data_strobe signal
WAITING: wait for PC's acknowledge
POST_CONFIG, POST_CONFIG2: for updating internal signals
The PC sends ready signal to ask for data and then waits for data_strobe
signal to get
the data, and send back acknowledge.
The problem(which happens OCCASSIONALLY) is that:
While the PC is waiting for the data_stroble signal (D2_nDS = '0'), the
Spartan II is in
POST_CONFIG2 state(observed in logic analyser). I don't why it "jumps" to
POST_CONFIG2 state, and why it keeps staying in this state, instead of going
to IDLE
state when it is in POST_CONFIG2 state.
Is it probable that there is timing problem in the design and what will be
the causes for such
situatoin to occur occassionally ?
Thx for ur help,
tk
VHDL code:
=========
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library unisim;
use unisim.vcomponents.all;
entity data_tran is
Port ( CLKIN_P : in std_logic;
PC_R_nW_buf : in std_logic;
PC_Rcv_nDS : in std_logic;
PC_INIT_buf : in std_logic;
data : inout std_logic_vector(7 downto 0);
D2_nDS_out : out std_logic := '1';
D2_nRcv_out : out std_logic := '0';
debug_data : out std_logic_vector(7 downto 0);
LED1, LED2 : out std_logic);
end data_tran;
architecture Behavioral_data_tran of data_tran is
component IBUF
port ( I : in std_logic;
O : out std_logic);
end component;
component CLKDLL
port (CLKIN, CLKFB, RST : in STD_LOGIC;
CLK0, CLK90, CLK180, CLK270, CLK2X, CLKDV, LOCKED : out std_logic);
end component;
component IBUFG
port (I : in STD_LOGIC; O : out std_logic);
end component;
component BUFG
port (I : in STD_LOGIC; O : out std_logic);
end component;
type data_state is (s1, s2, s3, s4, s5, s6, s7, s8);
type send_state is (IDLE, PREPARE, SEND, WAITING, POST_CONFIG,
POST_CONFIG2);
signal PC_R_nW : std_logic;
signal PC_INIT : std_logic;
signal d_in : std_logic_vector(7 downto 0);
signal d_out : std_logic_vector(7 downto 0);
signal q : std_logic_vector(7 downto 0);
signal pcwe : std_logic;
signal pcnre : std_logic;
signal D2_nDS : std_logic;
signal D2_nRcv : std_logic;
signal RST, LOCKED : std_logic;
signal CLKIN, CLK, CLK0 : std_logic;
signal buf : std_logic_vector(63 downto 0);
signal d_state : data_state;
signal s_state : send_state;
begin
U1: IBUF port map(I => PC_R_nW_buf, O => PC_R_nW);
U2: IBUF port map(I => PC_INIT_buf, O => PC_INIT);
U3: IBUFG port map (I=>CLKIN_P, O=>CLKIN);
U4: CLKDLL port map (CLKIN=>CLKIN, CLKFB=>CLK, RST=>RST, CLK0=>CLK0,
LOCKED=>LOCKED);
U5: BUFG port map (I=>CLK0, O=>CLK);
process(PC_INIT)
begin
if (PC_INIT = '1') then
if (PC_R_nW = '1') then
pcwe <= '0';
pcnre <= '0';
elsif (PC_R_nW = '0') then
pcwe <= '1';
pcnre <= '1';
end if;
end if;
end process;
process(PC_INIT, CLK)
begin
if (PC_INIT = '1') then
if (PC_R_nW = '1') then
buf <=
"0000100000000111000001100000010100000100000000110000001000000001";
d_state <= s1;
s_state <= IDLE;
D2_nDS <= '1';
end if;
elsif (LOCKED = '1' and rising_edge(CLK)) then
if (PC_R_nW = '1') then -- PC Read
case s_state is
when IDLE =>
if (PC_Rcv_nDS = '0') then -- PC Ready
s_state <= PREPARE;
end if;
when PREPARE =>
case d_state is
when s1 => d_out <= buf(63 downto 56);
when s2 => d_out <= buf(55 downto 48);
when s3 => d_out <= buf(47 downto 40);
when s4 => d_out <= buf(39 downto 32);
when s5 => d_out <= buf(31 downto 24);
when s6 => d_out <= buf(23 downto 16);
when s7 => d_out <= buf(15 downto 8);
when s8 => d_out <= buf( 7 downto 0);
when others => null;
end case;
s_state <= SEND;
when SEND =>
D2_nDS <= '0'; -- Raise Data Strobe signal
s_state <= WAITING;
when WAITING =>
if (PC_Rcv_nDS = '1') then -- Wait PC
acknowledge
s_state <= POST_CONFIG;
end if;
when POST_CONFIG =>
case d_state is
when s1 => d_state <= s2;
when s2 => d_state <= s3;
when s3 => d_state <= s4;
when s4 => d_state <= s5;
when s5 => d_state <= s6;
when s6 => d_state <= s7;
when s7 => d_state <= s8;
when s8 => d_state <= s1;
when others => null;
end case;
s_state <= POST_CONFIG2;
when POST_CONFIG2 =>
D2_nDS <= '1';
s_state <= IDLE;
when others =>
null;
end case;
end if;
end if;
end process;
d_in <= data when pcwe = '1' else d_out;
q <= d_in;
data <= q when pcnre = '0' else "ZZZZZZZZ";
RST <= '0';
D2_nDS_out <= D2_nDS;
D2_nRcv_out <= D2_nRcv;
debug_data(6 downto 4) <=
"000" when (s_state = IDLE) else
"001" when (s_state = PREPARE) else
"010" when (s_state = SEND) else
"011" when (s_state = WAITING) else
"100" when (s_state = POST_CONFIG) else
"101" when (s_state = POST_CONFIG2) else
"111";
end Behavioral_data_tran;
Article: 51376Russell wrote: > Rene Tschaggelar wrote: > >> I really appreciate to have the major vendors here. >> Hoping to have now at least one reader in charge : >> >> As much as like to use the web based support, I am discouraged. >> >> I do have to log in, giving name adress and so on plus a password. >> The next time, I lost the password, then I enter the name = >> street = whatever = aaaaa. The only correct entry is my email. >> Then I get a mail back : company does not match or alike, after >> a day or two. >> There are error description forms to be filled out (forgot >> which company) but the message is truncated after 160 characters. >> >> Common, this is not useable at all. >> There is not even an email adress as alternative means. >> >> I don't want yet another entry in a postal mailing list... > > > Some email/web browsers (like mozilla) can remember what you > enter into these name/password pages so that the fields are > automatically filled next time you go to that page. The other > way is to record all your passwords in a file locally. The broweser is only able to do that when you visit that page on a regular basis, eg weekly. 3 month later the page usually looks different and is not recognized anymore. Yes, a passwork book (from paper) would be it, technically. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 51377
hi, i would like to know the concept of "BALL GRID ARRAY" used in the fpga technology. thnax naveenArticle: 51378
Andrew Rogers wrote: > It would seem that the Open Source software developers haven't quite > managed to produce a complete tool chain for programming FPGAs. The > remaining issue seems to be that FPGA manufactures are not willing to > supply the necessary bit-stream specification and make excuses, giving > the details of the bit-stream would allow reverse engineering of > commercial products that use their FPGAs. That's probably true, but any > one wishing to clone such a product only has to duplicate the bit-stream > and no reverse engineering is required. > > If FPGA manufactures continue this ridiculous trend then maybe the only > option is to develop a new FPGA which has all of its specifications > available. > > I know that this issue has been raised in the past, but this time I am > following up a different approach, the development of an Open FPGA. > > Can anyone (Xilinx maybe) estimate the cost and time involved in > development of a new and open FPGA? > > Maybe I could test out the new Open FPGA with my University Ph.D. work > on Turbo codecs! There possibly are too many patents in the way of a standardization. Now the customers are tied to the manufacturer by the high complexity of the tools. It takes too long to learn another tool to gain little. To start with, some agreement on the 2D editor handling would be great. Some editors use pageup/down to zoom in/out, others require the zoom to be activated with a mouseclick. Some editors use the scrollbars-only to pan the sheet, while others use eg right mouse down to pan. On the other hand the 3D editors are much worse what their handling concerns. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 51379
Hi, what is the merit & constraint of each of these design entry methods - schematic design - VHDL i have heard pple saying any changes in schematic entry, will cause all timing to be changed and you got to check your timing again; is this true ? ANd how about VHDL; is it really better? I have last done a uni. project to implement a convolutional codec using schematic entry method; and frankly i i can't imagine to program the design in VHDL ...it's just too enormous the codes!Article: 51380
Rene Tschaggelar wrote: > Andrew Rogers wrote: > >> It would seem that the Open Source software developers haven't quite >> managed to produce a complete tool chain for programming FPGAs. The >> remaining issue seems to be that FPGA manufactures are not willing to >> supply the necessary bit-stream specification and make excuses, giving >> the details of the bit-stream would allow reverse engineering of >> commercial products that use their FPGAs. That's probably true, but >> any one wishing to clone such a product only has to duplicate the >> bit-stream and no reverse engineering is required. >> >> If FPGA manufactures continue this ridiculous trend then maybe the >> only option is to develop a new FPGA which has all of its >> specifications available. >> >> I know that this issue has been raised in the past, but this time I am >> following up a different approach, the development of an Open FPGA. >> >> Can anyone (Xilinx maybe) estimate the cost and time involved in >> development of a new and open FPGA? >> >> Maybe I could test out the new Open FPGA with my University Ph.D. work >> on Turbo codecs! > > > There possibly are too many patents in the way of a standardization. > Now the customers are tied to the manufacturer by the high complexity > of the tools. It takes too long to learn another tool to gain little. Not sure that the tools are complex to use as I have yet to use them. I am waiting until I can program an FPGA using open source software. I know the design cycle is complex. In my opinion it would be the similarity between FPGAs that would tie customers to a particular FPGA manufacturer. I should imagine that most of the FPGA design time is spent routing the design to a particular FPGA. > > To start with, some agreement on the 2D editor handling would be great. > Some editors use pageup/down to zoom in/out, others require the zoom to > be activated with a mouseclick. Some editors use the scrollbars-only to > pan the sheet, while others use eg right mouse down to pan. > On the other hand the 3D editors are much worse what their handling > concerns. I should imagine that these are minor differences when compared with differences between FPGAs manufactured by different companies. But I'm speaking without experience. Regards Andrew RogersArticle: 51381
"Andrew Rogers" <andrew@rogerstech.co.uk> schrieb im Newsbeitrag news:3E219BB7.7020509@rogerstech.co.uk... > Not sure that the tools are complex to use as I have yet to use them. I > am waiting until I can program an FPGA using open source software. I > know the design cycle is complex. In my opinion it would be the > similarity between FPGAs that would tie customers to a particular FPGA > manufacturer. I should imagine that most of the FPGA design time is > spent routing the design to a particular FPGA. > I should imagine that these are minor differences when compared with > differences between FPGAs manufactured by different companies. But I'm > speaking without experience. Your open source approach is not new. Have a look at the NG archive. IMHO Ray Andraka pointed out a a very practically issue. He said, for now the open source guys should concentrate on back-end tools, where the data structures are open (like floorplanner, programming tools, design-manager). There is plenty of room for improvement (at least debugging :-( But generating a open source FPGA from the silicone level is damm close to impossible today. But I wont stop you. ;-) Regards FalkArticle: 51382
I see two problems. 1st) You MUST synchronize the control signals from the PC to your FPGA clock domain. Do this by running them through 2 FlipFlops. Access ONLY the synchronized signals with you state machine. 2nd) The VHDL below doesnt look good. > process(PC_INIT, CLK) > begin > if (PC_INIT = '1') then > if (PC_R_nW = '1') then > buf <= > "0000100000000111000001100000010100000100000000110000001000000001"; > d_state <= s1; > s_state <= IDLE; > D2_nDS <= '1'; > end if; > elsif (LOCKED = '1' and rising_edge(CLK)) then > if (PC_R_nW = '1') then -- PC Read > case s_state is What is PC_INIT? A reset signal from the PC? Also, the line > elsif (LOCKED = '1' and rising_edge(CLK)) then is not clean, a rising edge condition should (must?) not be combined with a logic signal. better write it so elsif rising_edge(CLK) then if LOCKED = '1' then -- MfG FalkArticle: 51383
"Andrew Rogers" <andrew@rogerstech.co.uk> schrieb im Newsbeitrag news:3E216C08.3020608@rogerstech.co.uk... > Funny because it seems an impossible task to design a new FPGA? If so, > then is it not possible to just change the bit-stream decoding in an > existing FPGA design to create an open version that has a different > bit-stream to closed FPGAs. Not really. -- MfG FalkArticle: 51384
"John Tan" <bktan1974@netscape.net> schrieb im Newsbeitrag news:eb4dd21b.0301120804.6a2e6729@posting.google.com... > Hi, what is the merit & constraint of each of these design entry > methods > > - schematic design > - VHDL The (un)holy neverending discussion. ;-) > i have heard pple saying any changes in schematic entry, will cause > all timing to be changed and you got to check your timing again; is > this true ? ANd how about VHDL; is it really better? No, its not true. VHDL is the same there, sometimes VHDL is more sensitive to such changes (because the compiler can mess up things :-( > I have last done a uni. project to implement a convolutional codec > using schematic entry method; and frankly i i can't imagine to program > the design in VHDL ...it's just too enormous the codes! Just because you havnt never done VHDL. Its cool. It works good. At least for me. -- MfG FalkArticle: 51385
Andrew Rogers <andrew@rogerstech.co.uk> wrote in message news:<3E214B75.5080507@rogerstech.co.uk>... > It would seem that the Open Source software developers haven't quite > managed to produce a complete tool chain for programming FPGAs. The > remaining issue seems to be that FPGA manufactures are not willing to > supply the necessary bit-stream specification and make excuses, giving > the details of the bit-stream would allow reverse engineering of > commercial products that use their FPGAs. That's probably true, but any > one wishing to clone such a product only has to duplicate the bit-stream > and no reverse engineering is required. > > If FPGA manufactures continue this ridiculous trend then maybe the only > option is to develop a new FPGA which has all of its specifications > available. > > I know that this issue has been raised in the past, but this time I am > following up a different approach, the development of an Open FPGA. > > Can anyone (Xilinx maybe) estimate the cost and time involved in > development of a new and open FPGA? > > Maybe I could test out the new Open FPGA with my University Ph.D. work > on Turbo codecs! > > Thanks > Andrew Rogers Indeed it is an old subject that is pretty much been flogged to death. You could chase after some 6200 stuff or look out for meta FPGA. The funny thing is, big FPGAs have become alot like Pentiums in one respect... If you don't like the x86 architecture, (and who does), design your own and write a simulator & JIT compiler for it in tuned x86. The simulation may well run faster than any actual IC version of your cpu and you don't need a fab or big $. I am assuming that state of the art simulation would use 10 opcodes per new opcode and JITs can get closer to unity. The resulting arch may well be justified as being more effective & desirable than x86 but the simulation will negate all this & more. Still, meta cpus are everywhere, JVM etc. Same deal for FPGA, you could create your own meta FPGA by mostly ignoring the fancy features and simply arraying your own simple instances. This is really just a highly constrained design style, you will lose alot of the speed and density, but now you can write your own tools. No matter how nice the meta FPGA & tools, you will still lose out overall. If you really want to make a real state of the art FPGA (in volumes), you will need a couple $Billion to get access to the fabs, designers, tools etc. You do remember Dynachip, Algotronix, Neocad don't you? Xilinx ended up buying them all, Dynachip IIRC for peanuts. If you only need to prototype your ideas, MOSIS & other share foundries are still around, but will be a few yrs behind on design rules. Academically your fab costs may even be covered. If you do create a HDL source for a better FPGA, you don't really even have to make it, simulation is still rough proof of concept. JJArticle: 51386
thx Falk the PC_INIT is a reset signal I don't quite understand problem 1, could you elaborate more ? tk "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:avsai6$fk2es$1@ID-84877.news.dfncis.de... > I see two problems. > > 1st) You MUST synchronize the control signals from the PC to your FPGA clock > domain. Do this by running them through 2 FlipFlops. Access ONLY the > synchronized signals with you state machine. > > 2nd) The VHDL below doesnt look good. > > > process(PC_INIT, CLK) > > begin > > if (PC_INIT = '1') then > > if (PC_R_nW = '1') then > > buf <= > > "0000100000000111000001100000010100000100000000110000001000000001"; > > d_state <= s1; > > s_state <= IDLE; > > D2_nDS <= '1'; > > end if; > > elsif (LOCKED = '1' and rising_edge(CLK)) then > > if (PC_R_nW = '1') then -- PC Read > > case s_state is > > What is PC_INIT? A reset signal from the PC? Also, the line > > > elsif (LOCKED = '1' and rising_edge(CLK)) then > > is not clean, a rising edge condition should (must?) not be combined with a > logic signal. better write it so > > elsif rising_edge(CLK) then > if LOCKED = '1' then > > -- > MfG > Falk > > >Article: 51387
john jakson wrote: > Andrew Rogers <andrew@rogerstech.co.uk> wrote in message news:<3E214B75.5080507@rogerstech.co.uk>... > >>It would seem that the Open Source software developers haven't quite >>managed to produce a complete tool chain for programming FPGAs. The >>remaining issue seems to be that FPGA manufactures are not willing to >>supply the necessary bit-stream specification and make excuses, giving >>the details of the bit-stream would allow reverse engineering of >>commercial products that use their FPGAs. That's probably true, but any >>one wishing to clone such a product only has to duplicate the bit-stream >>and no reverse engineering is required. >> >>If FPGA manufactures continue this ridiculous trend then maybe the only >>option is to develop a new FPGA which has all of its specifications >>available. >> >>I know that this issue has been raised in the past, but this time I am >>following up a different approach, the development of an Open FPGA. >> >>Can anyone (Xilinx maybe) estimate the cost and time involved in >>development of a new and open FPGA? >> >>Maybe I could test out the new Open FPGA with my University Ph.D. work >>on Turbo codecs! >> >>Thanks >>Andrew Rogers > > > Indeed it is an old subject that is pretty much been flogged to death. > > You could chase after some 6200 stuff or look out for meta FPGA. > Is the XC6200 still available? I can't find any info on it from the Xilinx website. I did manage to a datasheet from elsewhere on the web. The XC6200 datasheet does have the bitstream details. www.vcc.com/Papers/6200.pdf Regards Andrew RogersArticle: 51388
In article <3E216C08.3020608@rogerstech.co.uk>, Andrew Rogers <andrew@rogerstech.co.uk> wrote: >Funny because it seems an impossible task to design a new FPGA? If so, >then is it not possible to just change the bit-stream decoding in an >existing FPGA design to create an open version that has a different >bit-stream to closed FPGAs. Funny because Jbits and Xilinx documentation allow you to create your own configurations, so if you were an Open Source Obsessed individual you could write your own tools, which is already way more work then what you gain. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51389
naveen wrote: > hi, > i would like to know the > concept of "BALL GRID ARRAY" used in the fpga technology. > thnax > naveen It's the method of soldering used. Cirular pads are fabricated on both the chip package and PCB. Small balls of solder are sandwiched between the chip package and the PCB. Regards Andrew RogersArticle: 51390
Hi
I'm having a hard time figuring out how to implement the coefficient
multiplication in a vhdl dsp design. Let's say every registers are 16 bits
wide in two's complement representation and suppose there are no overflow.
The input data is normalised betwen -1 and 1. How can I implement the
following block diagram in vhdl? How is the *0.1 implemented...I'm really
lost here thanks for any help.
x(n)-------------- * 0.1----------- +---------- y(n)
| |
| |
|______z^-1_________|
David
Article: 51391
IMHO, the way to express a design in VHDL is to first envision the
schematic for the circuit you are creating, then write the VHDL to produce
that logic. Too many folks treat the VHDL somewhat like software
programming without a clue as to how it gets mapped into hardware, and
they get crappy designs as a result. Since you are already comfortable
with schematic design, the only hurdle you face is syntax.
Schematic entry has an advantage of being easier to read. VHDL has
advantages of parameterization of components (can be done in schematics
with precompilers, but it is awkward), capability to create good
simulation test benches, and better portability between tools. I would
suggest using VHDL with one of the HDL viewers that translate the code
into a viewable schematic such as RTL analyst in Synplify or Renoir. As
with schematics, designs are much more readable if built up of
hierarchical components...it is sort of a divide and conquer that makes
creation and maintenance much easier.
John Tan wrote:
> Hi, what is the merit & constraint of each of these design entry
> methods
>
> - schematic design
> - VHDL
>
> i have heard pple saying any changes in schematic entry, will cause
> all timing to be changed and you got to check your timing again; is
> this true ? ANd how about VHDL; is it really better?
>
> I have last done a uni. project to implement a convolutional codec
> using schematic entry method; and frankly i i can't imagine to program
> the design in VHDL ...it's just too enormous the codes!
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 51392Andrew Rogers <andrew@rogerstech.co.uk> wrote in message news:<3E219BB7.7020509@rogerstech.co.uk>... > > Not sure that the tools are complex to use as I have yet to use them. I > am waiting until I can program an FPGA using open source software. I > know the design cycle is complex. In my opinion it would be the > similarity between FPGAs that would tie customers to a particular FPGA If you are going to wait for open source tools before using FPGAs, you are going to miss out on this entire technology completely. You are better off using whats there and maybe improving it later. I can understand the thrill of using Linux etc & not being beholden to some (evil?) SW company but open source has little value when it always seems to reinvent for free (whatever free means) something that already exists & is useable but is also transient. There is quite alot of open EDA out there but most of it looks decidely dated & is usually low grade or of historical interest. There simply aren't the nos of user to justify usual OS religion for developing tools. The best people in the world to develop EDA SW should be the users of those tools who might have the spare time & inclination to build something they can use in their work, not somebody who hasn't actually used or understood the design flow but has the GPL religion. There are places where open source EDA can be valuable, ie tools that naturally have longevity such as Verilog, VHDL simulators compilers, linters etc. Or how about OSS C synthesis. HandelC and other synthesis for C seem to be very expensive and won't help spread reconfigurable computing 1 iota if nobody can afford it. As long as the C guys think there is pots of gold where C tools go, they will be dissapointed. Have you looked at what Toronto U and some other edus have done in FPGA tools? If RC ever takes off with an FPGA in the PC cpu, the Visual C++/.Net tools are going to need afordable C synthesis, buts thats another rant. > manufacturer. I should imagine that most of the FPGA design time is > spent routing the design to a particular FPGA. > No, I don't think so, are you thinking PCBs? Most of the time is spent in design, simulation, verification etc. routing takes some of us upto a day or so on some designs, but we don't do that too frequently. JJArticle: 51393
On Sun, 12 Jan 2003, Andrew Rogers <andrew@rogerstech.co.uk> wrote:
>It would seem that the Open Source software developers haven't quite
>managed to produce a complete tool chain for programming FPGAs. The
>remaining issue seems to be that FPGA manufactures are not willing to
>supply the necessary bit-stream specification [chop]
Right. You would have saved the regulars their annual trip down
memory lane by reading
http://opencollector.org/news/Bitstream/
>If FPGA manufactures continue this ridiculous trend then maybe the only
>option is to develop a new FPGA which has all of its specifications
>available.
Impractical until at least September 26, 2006, when the imfamous
Freeman/Xilinx patent 4,870,302 expires. You could start in
2004, when 4,642,487 and 4,706,216 expire. Or do the initial
work in a country that doesn't recognize U.S. patents.
- Larry
Article: 51394nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<avqten$2d19$1@agate.berkeley.edu>... > In article <adb3971c.0301102259.628b0fd3@posting.google.com>, > john jakson <johnjakson@yahoo.com> wrote: > >I only wish Xilinx could have made an ARM deal too. I know, I know, > >next person will want MIPS and so on. > > > >I am pretty sure too that embedded PPC cores are a low priority for > >most FPGA guys right now but the path to PPC leads to certain markets > >(higher performance, high value). The path to ARM leads to lower cost > >and smaller designs I hazard & I bet much larger consumer markets as > >well as perhaps ASIC conversions. Perhaps Spartan.. pro whatever could > >have ARM offering instead. If I were a gadget guy counting all the > >embedded cpus in my toys I'm sure I would find lots of ARMs and few > >PPCs (although my 3com cable box has one). > > How much does choice of ISA really matter? You get decent tools, a > good compiler, your OS, and the ISA itself becomes secondary. > Arm has a couple of gimmics that help (a 16 bit ISA variant for more > code density, condition coding), but those are secondary effects. > > If you have legacy code, or a specific OS support, ISA may matter. > Then again, you can always use a soft core for that. > > But if you are doing a NEW project, why care? Most designs are not new. Most designs are revisions and improvements to existing designs. Would be more fun to always work on new design & forget all the previous stuff and change ISAs on a whim, but the SW guys absolutely don't agree. ARM has one little gimic that IBM doesn't, that is literally 100s of ARM licenses are out there so that an FPGA with included hard ARM core plus all the other stuff can get ASICed. If we switched to PPC, who would be my fab, IBM/Moto/??? They only deal with huge orders, the ARM licenses will take much smaller projects, even mixed signal etc. JJArticle: 51395
The 302 patent doesn't stop Altera or Triscend or others. Xilinx gives all the data to reverse engineer the bitstream. It is not very well documented however. Look at the xdl command. You could write a program that translates the xdl output into and out of the U of Toronto place and route tool. You could take JBits and write a program to figure out the V1 bitstream. I think it would take a small group of programmers (5-10) a year or so but it is possible. Steve > Impractical until at least September 26, 2006, when the imfamous > Freeman/Xilinx patent 4,870,302 expires. You could start in > 2004, when 4,642,487 and 4,706,216 expire.Article: 51396
On Sun, 12 Jan 2003 22:54:13 GMT, Ray Andraka <ray@andraka.com> wrote: >IMHO, the way to express a design in VHDL is to first envision the >schematic for the circuit you are creating, then write the VHDL to produce >that logic. So: schematics allow one to visualize a design, then all you have to do is hand-compile the schematic to VHDL. That leads directly to a wonderful product idea: software that *automatically* generates VHDL from a schematic! Somebody should start working on this. [1] John [1] yes, yes, I know...Article: 51397
Gentlement: I've built a small computer board for a small local college (mostly from one of the professor's designs and partly from designs in the book). The machine uses PLDs in several places and I figured I could simplify the board some (and improve by skills) by (learning about and) using FPGAs, but I don't know where to get the initial software or download equipment. TIA(Thanks In Advance) 2Penny(2cents worth of opinion)Article: 51398
"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.etc> wrote in message news:ksd42v8a2u6flipga2i698c6uce58dl2a5@4ax.com... > On Sun, 12 Jan 2003 22:54:13 GMT, Ray Andraka <ray@andraka.com> wrote: > > >IMHO, the way to express a design in VHDL is to first envision the > >schematic for the circuit you are creating, then write the VHDL to produce > >that logic. > > So: schematics allow one to visualize a design, then all you have to > do is hand-compile the schematic to VHDL. > > That leads directly to a wonderful product idea: software that > *automatically* generates VHDL from a schematic! Somebody should start > working on this. [1] > > John Er, or do as I do...draw the top level like a block diagram, using schematics, and any data path in schematics, and create symbols for modules that can be done in anything you want, VHDL, Verilog...or schematic...even Abel. All the problems and solutions of every methodology...in one place and at one time ;-) AustinArticle: 51399
Peter Alfke <peter@xilinx.com> wrote in message news:<3E1F10A6.66304475@xilinx.com>... > Thanks to all the people that have defended my statement. :-) > Let me make it even clearer: > > If you compare the XC2VP7 against the well-known XC2V1000: > The P7 has 40 rows by 34 columns, the 2V1000 has 40 rows by 32 columns. > The P7 has 4928 slices, and the 2V1000 has 5120 slices, so the difference is 4% > in favor of 2V1000 > The P7 has 44 BlockRAMs, and the 2V1000 has 40, so the difference is 10% in > favor of P7. > The 2V1000 has slightly more I/O. > That means, the comparison is very close, but the P7 is cheaper than the 2V1000. > > That means the PowerPC and the eight 3 gigabit transceivers are really FOR FREE > ! Well, I really need some kind of processor inside, but what about excessive power consumption in case I don't need to use RocketIO's? In VirtexII-Pro datasheet stated that EACH RocketIO channel consumes 310 mW for 2.5 Gb/s and 230 mW for 1.25 Gb/s operations. I may surmise that for 0 Gb/s operations each RocketIO will consume next 80 mW less power: 230 - 80 = 150 mW. Multiplying it by 4 (at least) we get 4*150=600 mW! For embedded applications that excessive power consumption may be critical (at least for my case it is true). > This is the proverbial progress: > smaller geometries due to more advanced processing (130 nm vs 150 nm) > make a smaller die and lower cost. > > So you have a choice, and you either love the PPC and gigabit transceivers, or > you just decide on the economics, the package availability and the available > I/O. > We gladly sell you either part. > > Peter Alfke, Xilinx Applications
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