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, Yes, but I don't use the floorplanner. I added all placement constraints (RLOC) in my VHDL code. This gives me a more stable and reliable timing. I have actually done a test where I remove all RLOC from my code and let par do the placement. The result is within 5% of the handplaced version. Göran Rick Filipkiewicz wrote: > Goran Bilski wrote: > > > Hi, > > > > MicroBlaze is more pipelined and is more floorplanned than PicoBlaze. > > The 150 MHz for MicroBlaze is on a V2Pro and 116MHz for PicoBlaze is on VII-6. > > MicroBlaze runs at 135 MHz on a VII-6. > > > > Aha! There we have it caught on this very NG a Xilinx person admitting that > floorplanning is important :-)).Article: 48301
Austin,
If I were using a chip that big in terms of I/O and gate count then I
would need a BGA package. In my case and, I suspect, in the case of the
poster, the smallest Virtex2 would be gross overkill in terms of both I/O
and gate count. What drove me to an FPGA approach in the first place is
that an FPGA created far less switching noise than a design based on a
mixture of ECL and 7400 series type logic. After I got into it I also found
that the FPGA offered incredible flexibility and a greatly reduced cost. I
did have to sacrifice a little on the speed end but we (my boss and I)
decided that this would be acceptable. Using a Virtex2 would have more than
gained back that sacrificed clock speed (by using the DCM). In fact, the
Spartan2E got me close to where I was with the mixed ECL design.
If I may ask a hypothetical question...
If one wanted a small Virtex2 in a low pin count package is it do-able?
I understand that a company such as Xilinx has to go for the large profit
customer. I just am wondering if the problem with the Virtex2 is chip
defined (i.e. both on chip routing and bonding to the pins) or pin defined
(the standard soic type pins themselves create an EMC problem at the
switching speeds of the Virtex2) or am I missing the point altogether.
By the way, if funding ever were available to do a proper prototype, I
would still like to use a Virtex2. I think it is probably still a great
part. That also assumes that we can capture sufficient market share for our
product. Those two are probably really the same assumtion.
Theron
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3DAC740F.F619C54@xilinx.com...
> Try using a ff1517 2V8000....
>
> It is the number of pins.
>
> Austin
>
> Theron Hicks wrote:
>
> > Uwe,
> > I can route the package, I just can't assemble it. Changing the
number
> > of pins won't solve the problem. Furthermore, I don't buy that the EMC
> > problems are insurmountable. I regularly build ECL circuits at 1GHz in
> > standard SOIC packages. In fact, try to buy 100K ECL in anthing but
leaded
> > packages be they gullwing or J-lead. The only available packages are
> > leaded, not BGA. For example the MC100EP32 is rated for 4 Gigahertz
toggle
> > (divide by 2). It is only available in an 8 pin SOIC or 8 pin TSSOP
> > package. Check the http://www.onsemi.com web site Only the reduced
swing
> > ECL (RSECL) parts go to BGA. Those are rated for 12 GIGAHERTZ toggle.
> > Unless the problems are simply caused by the number of I/O pins then
I
> > am skeptical of the EMC issue.
> >
> > Just my opinionated opinion,
> > Theron Hicks
> >
> > "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
> > news:aohn4s$olb$1@news.tu-darmstadt.de...
> > > emanuel stiebler <emu@ecubics.com> wrote:
> > > : Is there any chance we could see something like this ?
> > > : I would love to use the speed of the VirtexII on a cheaper PCB.
> > >
> > > : Am I the only one who is dreaming about this packaging ?
> > >
> > > The question came up before. One answer was, that EMC problems nearly
> > > prohibit use of leaded packages for devices fast and powerfull like
the
> > > virtex. One proposal was to put out a BGA package with 1.27 mm pitch.
4
> > > Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules
are
> > > afordable and a 4 row BGA can be routed with these rules.
> > >
> > > Bye
> > > --
> > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
> > >
> > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
> > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
>
Article: 48302Theron Hicks wrote: > > Austin, <snip> > If one wanted a small Virtex2 in a low pin count package is it do-able? > I understand that a company such as Xilinx has to go for the large profit > customer. I just am wondering if the problem with the Virtex2 is chip > defined (i.e. both on chip routing and bonding to the pins) or pin defined > (the standard soic type pins themselves create an EMC problem at the > switching speeds of the Virtex2) or am I missing the point altogether. I think at some stage, they change from ring-bondpads, to bondpads 'all over the die' and the latter clearly has package impacts. Austin will clarify :) That said, something like a 'split MLF' package, with peripheral IO (reduced) and a split slug underneath, for GND.VCC connections would have lower lead inductance than QFP, and much lower power supply and thermal impedances, but still be reflow & reduced layers compatible. Q: Is a package like this being looked at ? -jgArticle: 48303
Did you address the problems that are described in this thread: http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&selm=25c81abf.0210081329.ed45bc4%40posting.google.com The are also a couple of older threads on this topic. CU, Kolja Sulimma "Leon Heller" <leon@heller123.freeserve.co.uk> wrote in message news:<aoh90d$k70$1@newsg3.svr.pol.co.uk>... > Apparently, Xilinx has stopped making the Parallel Cable III. I've designed > a DIY version of it using a single-sided PCB (with a few wire links) capable > of being made at home. All components are through-hole, and it is just under > 3" square. If anyone is interested in making one, please contact me. I can > email the artwork (.PRN file for a LaserJet printer. > > > LeonArticle: 48304
In article <3DAC8FB4.6C3B@designtools.co.nz>, Jim Granville <jim.granville@designtools.co.nz> wrote: > I think at some stage, they change from ring-bondpads, to bondpads >'all over the die' and the latter clearly has package impacts. > > Austin will clarify :) The published die photos still show rings. And area pads would also change how IOs are routed and would show up in the data sheet. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 48305
Theron, The 2V40, 2V80, and 2V250 are available in the CS144 package, or the fg256 package. That is as small (and inexpensive) as it gets. Both packages do quite well with regards to SI and EMC/EMI as they were designed from the bottom up to be good performers. The reason why we abandoned the use of pq/hq packages (in planning Virtex II) is that they provide no good ground plane, and even with the low IO count in these smaller die, the ground bounce due to SSOs can be terrible (if the return path ground inductance is as bad as it gets in the pq/hq lead frame packages). One could cut the SSO budget by half, and then use a pq/hq package, but it would be for a very small market segment. Austin Theron Hicks wrote: > Austin, > If I were using a chip that big in terms of I/O and gate count then I > would need a BGA package. In my case and, I suspect, in the case of the > poster, the smallest Virtex2 would be gross overkill in terms of both I/O > and gate count. What drove me to an FPGA approach in the first place is > that an FPGA created far less switching noise than a design based on a > mixture of ECL and 7400 series type logic. After I got into it I also found > that the FPGA offered incredible flexibility and a greatly reduced cost. I > did have to sacrifice a little on the speed end but we (my boss and I) > decided that this would be acceptable. Using a Virtex2 would have more than > gained back that sacrificed clock speed (by using the DCM). In fact, the > Spartan2E got me close to where I was with the mixed ECL design. > > If I may ask a hypothetical question... > > If one wanted a small Virtex2 in a low pin count package is it do-able? > I understand that a company such as Xilinx has to go for the large profit > customer. I just am wondering if the problem with the Virtex2 is chip > defined (i.e. both on chip routing and bonding to the pins) or pin defined > (the standard soic type pins themselves create an EMC problem at the > switching speeds of the Virtex2) or am I missing the point altogether. > > By the way, if funding ever were available to do a proper prototype, I > would still like to use a Virtex2. I think it is probably still a great > part. That also assumes that we can capture sufficient market share for our > product. Those two are probably really the same assumtion. > > Theron > > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > news:3DAC740F.F619C54@xilinx.com... > > Try using a ff1517 2V8000.... > > > > It is the number of pins. > > > > Austin > > > > Theron Hicks wrote: > > > > > Uwe, > > > I can route the package, I just can't assemble it. Changing the > number > > > of pins won't solve the problem. Furthermore, I don't buy that the EMC > > > problems are insurmountable. I regularly build ECL circuits at 1GHz in > > > standard SOIC packages. In fact, try to buy 100K ECL in anthing but > leaded > > > packages be they gullwing or J-lead. The only available packages are > > > leaded, not BGA. For example the MC100EP32 is rated for 4 Gigahertz > toggle > > > (divide by 2). It is only available in an 8 pin SOIC or 8 pin TSSOP > > > package. Check the http://www.onsemi.com web site Only the reduced > swing > > > ECL (RSECL) parts go to BGA. Those are rated for 12 GIGAHERTZ toggle. > > > Unless the problems are simply caused by the number of I/O pins then > I > > > am skeptical of the EMC issue. > > > > > > Just my opinionated opinion, > > > Theron Hicks > > > > > > "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message > > > news:aohn4s$olb$1@news.tu-darmstadt.de... > > > > emanuel stiebler <emu@ecubics.com> wrote: > > > > : Is there any chance we could see something like this ? > > > > : I would love to use the speed of the VirtexII on a cheaper PCB. > > > > > > > > : Am I the only one who is dreaming about this packaging ? > > > > > > > > The question came up before. One answer was, that EMC problems nearly > > > > prohibit use of leaded packages for devices fast and powerfull like > the > > > > virtex. One proposal was to put out a BGA package with 1.27 mm pitch. > 4 > > > > Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules > are > > > > afordable and a 4 row BGA can be routed with these rules. > > > > > > > > Bye > > > > -- > > > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > > > > > > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > > > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > >Article: 48306
Hello Nacho,
You are getting such error during place and route because
OBUFE8,BUFE8, OBUFE8, OBUF4 etc are macros. See the Xilinx library
guide for more details.
You will need to wire up the single OBUFs etc.. in to their multiples
and then include them into your design.
For example OBUF4 would look like:
Library IEEE;
Use IEEE.std_logic_1164.all;
--RTL_SYNTHESIS OFF
Library unisim;
Use unisim.Vcomponents.ALL;
--RTL_SYNTHESIS ON
entity OBUF4 is
port
(
I0 : in STD_LOGIC;
O0 : out STD_LOGIC;
I1 : in STD_LOGIC;
O1 : out STD_LOGIC;
I2 : in STD_LOGIC;
O2 : out STD_LOGIC;
I3 : in STD_LOGIC;
O3 : out STD_LOGIC
);
end OBUF4;
------------------------------------------------------------
------------------------------------------------------------
architecture structure of OBUF4 is
begin
U1 : OBUF
port map
(
I => I0,
O => O0
);
U2 : OBUF
port map
(
I => I1,
O => O1
);
U3 : OBUF
port map
(
I => I2,
O => O2
);
U4 : OBUF
port map
(
I => I3,
O => O3
);
end structure;
------------------------------------
Hope this helps.
Regards
Avanish Bharati
Altium
"Ulises Hernandez" <ulises@britain.agilent.com> wrote in message news:<1034620566.661643@cswreg.cos.agilent.com>...
> Hello Nacho,
>
> Saludos de parte de otro espanhol :o)
> During the 'translate' step a block can be reported as 'unexpanded', and an
> unexpanded block is a missing part of the design and therefore it can't be
> mapped and you should get and error during the mapping step or for some
> versions of ISE during the translation step.
>
> What tool are you using for synthesis?
> In some synthesis tools you get a detailed LOG where you should get a
> warning telling you that the component OBUFE8 is inferred as a black box or
> something like that, that means your package with the OBUFE8 definition
> doesn't match any known Xilinx component.
> Compare your definition with the one in UNISIM or in the Xilinx web.
>
> What type of device are you targeting? Check the datasheet in case your
> device doesn't contain that resource.
>
> Another thing is, you don't need to define all these buffers in a library,
> most of them will be inferred for your synthesis tool automatically,
> sometimes is usefull to instantiate them in your RTL, I guess depends of the
> design.
>
> Good luck.
> Regards.
>
> --
> Ulises Hernandez
> Design Engineer
> ECS Technology Limited
> ulisesh@ecs-tech.com
>
>
>
> "Nacho" <nanoscobra@yahoo.com> wrote in message
> news:d311f859.0210140102.7c6a5dcc@posting.google.com...
> > Hello:
> >
> > I´m a spanish estudent, sorry for my bad english.
> >
> > I have created a proyect with Xilinx Foundation Series 2.1, all in
> > VHDL.
> > I have not create a library, I have create a package where put all the
> > components of my proyect. BUFE8, OBUFE8, OBUF4, BUFG, IBUF, OBUF,
> > IBUF8 are declarated like components in my package (without
> > architecture) and after are maped in my top_myproyect.vhdl.
> >
> > The are two types of errors when i try to create myproyect.bit.
> >
> > 1) ERROR:NgdBuild:432 - logical block 'I1' with type 'BUFE8' is
> > unexpanded.
> > The same with the others (OBUFE8, OBUF4, ...)
> > What happens?? Must i put other library in my proyect?
> >
> > 2) I have two BUFE8, both are conected in OBUFE8 and i get another
> > error.
> > What an i do about this? two sinals in the same in of OBUFE8?
> >
> > Thank you very much!!!
Article: 48307
That is lower than we typically see for data path designs. For heavily arithmetic
designs in VIrtex, VirtexE and SpartanII, we've consistently seen better than 30%
improvement, and frequently better than 60% doing the same experiment. Of course it
also depends on what you are setting the constraints as. The routing tools only work
as hard as they have to to meet your constraints, so if the target is low compared with
what could be realized, the results are going to be skewed making floorplanning not
look like a big win. For VirtexII, the same applies, except non-arithmetic logic is
quite a bit faster than the carry chains so the routing limit is artificially low if
there is arithmetic covered by the same constraint. 135MHz is not a very high target
for VirtexII.
Goran Bilski wrote:
> Hi,
>
> Yes, but I don't use the floorplanner.
> I added all placement constraints (RLOC) in my VHDL code.
> This gives me a more stable and reliable timing.
>
> I have actually done a test where I remove all RLOC from my code and let par do the
> placement.
> The result is within 5% of the handplaced version.
>
> Göran
--
--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: 48308
You might want to save the CLKDLL and wire up a divider using SRL16E.
It would save you the precious 4 DLLs in the Spartan 2. Mixing is good
approach.
To use CLKDLL you will need to set the CLKDV_DIVIDE attribute to see
the result on the hardware. For simulation you will need to set into
generic map.
------------------------
library ieee;
use ieee.std_logic_1164.all;
Library unisim;
Use unisim.Vcomponents.ALL;
entity CLK50MHZ is
port (
C50MHZ: in std_logic;
C5MHZ: out std_logic
);
end CLK50MHZ;
architecture struct of CLK50MHZ is
attribute CLKDV_DIVIDE : real;
attribute DUTY_CYCLE_CORRECTION : boolean;
attribute FACTORY_JF : bit_vector;
attribute STARTUP_WAIT : boolean;
attribute CLKDV_DIVIDE of U1: label is 10.0;
attribute DUTY_CYCLE_CORRECTION of U1: label is TRUE;
-- (TRUE, FALSE) are valid for DUTY_CYCLE_CORRECTION
attribute FACTORY_JF of U1 : label is X"C080";
attribute STARTUP_WAIT of U1: label is FALSE; -- (TRUE,FALSE)
attribute macrocell : boolean;
attribute macrocell of CLKDLLE : component is true;
signal GND : std_logic;
begin
GND <= '0';
U1 : CLKDLLE
--RTL_SYNTHESIS OFF
generic map (CLKDV_DIVIDE=>10.0) -- (1.5,2,2.5,3,4,5,8,16)
--RTL_SYNTHESIS ON
port map (
CLKDV => C5MHZ,
CLKFB => C50MHZ,
CLKIN => C50MHZ,
RST => GND
);
end architecture struct;
Avanish Bharati
Altium
Peter Alfke <peter@xilinx.com> wrote in message news:<3DAB03D6.5CB171D2@xilinx.com>...
> Why do you need several DLLs to divide a frequency?
> CLBs can do that nicely...
> Peter Alfke
>
> S Embree wrote:
>
> > I am trying to link several CLKDLL components in order to create a frequency divider. I am getting an error message that "Period specification references the TNM group, which contains only pad elements. Only synchronous elements are permitted in a period specification...."
> >
> > How should I set the period constraints when I am linking several CLKDLLs?
Article: 48309One of the big EMC issues is due to ground bounce. Something you'll find with ECL is that if you use balanced I/O, the current drawn by the part is almost constant; only imbalanced drivers cause the limited swing in current draw. The dynamic change in current going through the ground wires will cause the internal chip ground to be significantly different than the system ground when switching. While I/O are responsible for a significant part of the ground bounce issue (leading to SSO guidelines), we cannot ignore the demands of the circuit internals. If you have a design running at 300MHz in a PQ208, the internal demands may compromise the internal ground. If you have a comfortably slow design with designed clock skews to spread the current spikes and limited I/O slew rates, you can probably get the design where you need. If you want 300Mbit I/O, chances are your SSO budget will be very few signals per bank. There are superb rework machines that in-house model shops use to replace BGAs. These could be used to provide first-time assembly with good results. The expense isn't the same as a soldering iron, but you might find it worth its purchase in just a couple prototype runs. Theron Hicks wrote: > Uwe, > I can route the package, I just can't assemble it. Changing the number > of pins won't solve the problem. Furthermore, I don't buy that the EMC > problems are insurmountable. I regularly build ECL circuits at 1GHz in > standard SOIC packages. In fact, try to buy 100K ECL in anthing but leaded > packages be they gullwing or J-lead. The only available packages are > leaded, not BGA. For example the MC100EP32 is rated for 4 Gigahertz toggle > (divide by 2). It is only available in an 8 pin SOIC or 8 pin TSSOP > package. Check the http://www.onsemi.com web site Only the reduced swing > ECL (RSECL) parts go to BGA. Those are rated for 12 GIGAHERTZ toggle. > Unless the problems are simply caused by the number of I/O pins then I > am skeptical of the EMC issue. > > Just my opinionated opinion, > Theron Hicks > > "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message > news:aohn4s$olb$1@news.tu-darmstadt.de... > > emanuel stiebler <emu@ecubics.com> wrote: > > : Is there any chance we could see something like this ? > > : I would love to use the speed of the VirtexII on a cheaper PCB. > > > > : Am I the only one who is dreaming about this packaging ? > > > > The question came up before. One answer was, that EMC problems nearly > > prohibit use of leaded packages for devices fast and powerfull like the > > virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4 > > Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are > > afordable and a 4 row BGA can be routed with these rules. > > > > Bye > > -- > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 48310
Austin Lesea wrote > The 2V40, 2V80, and 2V250 are available in the CS144 package, or the fg256 > package. > > That is as small (and inexpensive) as it gets. Both packages do quite well with > regards to SI and EMC/EMI as they were designed from the bottom up to be good > performers. > > The reason why we abandoned the use of pq/hq packages (in planning Virtex II) is > that they provide no good ground plane, and even with the low IO count in these > smaller die, the ground bounce due to SSOs can be terrible (if the return path > ground inductance is as bad as it gets in the pq/hq lead frame packages). Just wondering: why do processors always(?) have on-package capacitors but FPGAs never?Article: 48311
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes: > In article <6u8z0zwp72.fsf@chonsp.franklin.ch>, > Neil Franklin <neil@franklin.ch.remove> wrote: > >> Linus Torvald uses Bitkeeper because it does a better job, even if it > >> does get RMS's panties in a twist. > > > >In a _large_ twist. We will see whether Linux gets to regret this move > >or not. Only time can show that. > > Personally, I think RMS could use a good twisting. Completely at agreement with you there. His "members only" = freedom formula, and attempts to redefine the meaning of the word free have generated quite a bit or resentment inside the open source camp. > I much prefer BSD > style liscences, as they have more real freedom. Me also. Actually I am placing my stuff in public domain, as I have no interest in enforcing licenses anyway, even the simple BSD one. > >> The only way which this will occur is if you tie your flow in with the > >> Xilinx flow: If you want to do routing, accept post-placement XDL. > >> If you just want to do bitfile manipulation, only do layers on Jbits. > >> You will probably NEVER be able to do static timing analysis without > >> being able to read the Xilinx databases. > > > >And going through the official formats, all of them, is definitely too > >much work. So I intend to be just compatible at the two endpoints, > >source (where programmers put their time) at one, and bitstream (what > >the chip wants to see) at the other. > > Post Routing XDL: You should OUTPUT this so you can do static timing > analysis. Without static timing analysis, NOBODY even remotely > serious will touch your tools. OK, output ist no great problem (no parsing and so). And it adds quite a bit of value which people will want. I have more a problem with parsing all the possible variants in some complicated input file, as that can get very time-expensive. Apropos XDL, which you have mentioned a few times: Where in the toolflow is it? I read the document and flowchart referred to in the other thread. In that I found: EDIF/XNF as inputs, NGD as first internal format (pre-map), NCD after mapping and second NCD after PAR, and then BIT after bitgen. XDL did not get mentioned anywhere. From your descriptions it sounds like the same levels as NCD. > The only other way is to reverse engineer the database format, with > the contents copyrighted so you can't distribute them anyway unless > you OK it with Xilinx. So you want to start by using Xilinx static > timing analysis, before trying to ask nicely for the database format > and permission to distribute. If someone needs closed source time database files, then he can just as good use the closed source tool that processes them. So there I would just make an additional output. Quasi an "transfer" from my flow to Xilinxes one. Those that want timing can be "part open". Those that want pure open have to do without timing. Allows everyone to select their preferred compromise. > Post Placement XDL: You should start your tool, if you want to start > with routing and bitgen, taking this as input. This allows you to > test your tool as you construct it, and allows you to leverage the > Xilinx toolflow to do mapping and placement and all other upstream > stuff. This is a complete description of the design, after mapping, > in a form you can use. This is about where I want to lay the border of my tools (somewhere one needs to draw the line to stop an project being infinite large). The top level "vas" tool is intended to have an post mapped and (relative)placed syntax, but one designed simple enough so that the designer can write it directly by hand, with about the same convenience/power tradeoff as assembly[1] language. [1] I prefer assembly, so long it is not x86 :-) This level is also more fitting my 74xx style "pick chips" design methods. Anything above that level I consider "compiler" level, to be made by 3rd party projects, once mine sets the path to bits free for them. That can include NGD->vas or direct EDIF->vas or even direct VHDL/Verilog/CUPL/...->vas compilers. > EDIF: After you want to start doing mapping and placement as well, > this is the format which compilers (all compilers) targeting Xilinx > output as, with Xilinx specific libraries. That is then already above where I intend to implement :-). -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 48312
Hi Ray, Are you implying something ;-) I could do a better work on BRAM placement but since the number of BRAM connected to MicroBlaze can be of any number it would force me to do a lot of different floorplans dependent on the number of BRAMs. The BRAM is in the critical path. Most requests on MicroBlaze is NOT on the performance but more on functionality and there is where I spend most of my time now. Göran Ray Andraka wrote: > That is lower than we typically see for data path designs. For heavily arithmetic > designs in VIrtex, VirtexE and SpartanII, we've consistently seen better than 30% > improvement, and frequently better than 60% doing the same experiment. Of course it > also depends on what you are setting the constraints as. The routing tools only work > as hard as they have to to meet your constraints, so if the target is low compared with > what could be realized, the results are going to be skewed making floorplanning not > look like a big win. For VirtexII, the same applies, except non-arithmetic logic is > quite a bit faster than the carry chains so the routing limit is artificially low if > there is arithmetic covered by the same constraint. 135MHz is not a very high target > for VirtexII. > > Goran Bilski wrote: > > > Hi, > > > > Yes, but I don't use the floorplanner. > > I added all placement constraints (RLOC) in my VHDL code. > > This gives me a more stable and reliable timing. > > > > I have actually done a test where I remove all RLOC from my code and let par do the > > placement. > > The result is within 5% of the handplaced version. > > > > Göran > > -- > --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, 1759Article: 48313
In article <6u65w3wa0q.fsf@chonsp.franklin.ch>,
Neil Franklin <neil@franklin.ch.remove> wrote:
>nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) writes:
>> I much prefer BSD
>> style liscences, as they have more real freedom.
>
>Me also. Actually I am placing my stuff in public domain, as I have no
>interest in enforcing licenses anyway, even the simple BSD one.
I like the BSD simply because it is "Do what you will, but acknowledge
what I did". :)
>> Post Routing XDL: You should OUTPUT this so you can do static timing
>> analysis. Without static timing analysis, NOBODY even remotely
>> serious will touch your tools.
>
>OK, output ist no great problem (no parsing and so). And it adds quite
>a bit of value which people will want. I have more a problem with
>parsing all the possible variants in some complicated input file, as
>that can get very time-expensive.
>
>
>Apropos XDL, which you have mentioned a few times:
>
>Where in the toolflow is it? I read the document and flowchart
>referred to in the other thread. In that I found: EDIF/XNF as inputs,
>NGD as first internal format (pre-map), NCD after mapping and second
>NCD after PAR, and then BIT after bitgen. XDL did not get mentioned
>anywhere.
>
>From your descriptions it sounds like the same levels as NCD.
XDL is a textual representation of NCD, there is a program in the
xilinx bin directory called xdl to convert back and forth.
Its actually a pretty simple format to parse, althouh rather wedded to
the target Xilinx part, as it is blocks of whatever with parameters
inside. EG, the XDL representation of a placed slice.
inst "U10/U5/U6/NEXT2" "SLICE" , placed R17C14 CLB_R17C14.S1 , module
"U10/U5/U6/$I52/hset" "U10/U5/U6/$I52/hset" "U10/U5/U6/NEXT2" ,
cfg "XORF:U10/U5/U6/$I52/$1I76: XORG:U10/U5/U6/$I52/$1I75:
CYMUXF:U10/U5/U6/$I52/$1I62: CYMUXG:U10/U5/U6/$I52/$1I58:
CYSELF::F CYSELG::G CKINV::1 COUTUSED::0 YUSED::#OFF
XUSED::#OFF XBUSED::#OFF F5USED::#OFF YBMUX::#OFF
CYINIT::CIN DYMUX::1 DXMUX::1 CY0F::F1 CY0G::G1
F:U10/U5/U6/$I52/$1I241:#LUT:D=A1
G:U10/U5/U6/$I52/$1I242:#LUT:D=A1 RAMCONFIG::#OFF
REVUSED::#OFF BYMUX::#OFF BXMUX::#OFF CEMUX::#OFF
SRMUX::#OFF GYMUX::GXOR FXMUX::FXOR SYNC_ATTR::ASYNC
SRFFMUX::#OFF INITY::LOW FFX:U10/U5/U6/$I108:#FF
FFY:U10/U5/U6/$I110:#FF INITX::LOW
_MACRO:U10/U5/U6/$I52/hset:-1"
;
Its actually a pretty simple format, and even spits out comments which
describe the high level structure, but the resource specific structure
is horribly target array specific. Nonetheless, there aren't too many
block types.
The only real problem is that the XDL representation between mapping
and placement doesn't include user specified absolute placement.
Well, that and it can't handle 2 GB designs.
Also, because there are a fair number of parameters and a few
different block types, it is easiest to write a small metatool which
takes a list of parameters and types for a given resource type and
creates the code to parse/creates the datastuctures for the internal
representation. Been there, done that, got the T-shirt.
>> Post Placement XDL: You should start your tool, if you want to start
>> with routing and bitgen, taking this as input. This allows you to
>> test your tool as you construct it, and allows you to leverage the
>> Xilinx toolflow to do mapping and placement and all other upstream
>> stuff. This is a complete description of the design, after mapping,
>> in a form you can use.
>
>This is about where I want to lay the border of my tools (somewhere
>one needs to draw the line to stop an project being infinite large).
Definatly XDL then. I would start with XDL as the input language, as
that way you can take advantage of Xilinx mapping and placement tools.
If you write your own assembly, translate that to XDL, with your
translator handling placement as appropriate.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu
Article: 48314
No, only that the savings is not representative of what can typically be achieved in a
pipelined datapath design through floorplanning. The placement of the BRAMs and multipliers
is certainly a driver. Most of our stuff is tolerant to additional pipelining so we will
typically surround the BRAMs with additional pipeline stages, which is something that doesn't
work too well with a simple microprocessor.
Goran Bilski wrote:
> Hi Ray,
>
> Are you implying something ;-)
>
> I could do a better work on BRAM placement but since the number of BRAM connected to
> MicroBlaze can be of any number it would force me to do a lot of different floorplans
> dependent on the number of BRAMs.
> The BRAM is in the critical path.
>
> Most requests on MicroBlaze is NOT on the performance but more on functionality and there
> is where I spend most of my time now.
>
> Göran
>
> Ray Andraka wrote:
>
> > That is lower than we typically see for data path designs. For heavily arithmetic
> > designs in VIrtex, VirtexE and SpartanII, we've consistently seen better than 30%
> > improvement, and frequently better than 60% doing the same experiment. Of course it
> > also depends on what you are setting the constraints as. The routing tools only work
> > as hard as they have to to meet your constraints, so if the target is low compared with
> > what could be realized, the results are going to be skewed making floorplanning not
> > look like a big win. For VirtexII, the same applies, except non-arithmetic logic is
> > quite a bit faster than the carry chains so the routing limit is artificially low if
> > there is arithmetic covered by the same constraint. 135MHz is not a very high target
> > for VirtexII.
> >
> > Goran Bilski wrote:
> >
> > > Hi,
> > >
> > > Yes, but I don't use the floorplanner.
> > > I added all placement constraints (RLOC) in my VHDL code.
> > > This gives me a more stable and reliable timing.
> > >
> > > I have actually done a test where I remove all RLOC from my code and let par do the
> > > placement.
> > > The result is within 5% of the handplaced version.
> > >
> > > Göran
> >
> > --
> > --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
--
--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: 48315
XDL is tool that a) reports on device usage, b)converts ncd files to xdl files
, c) converts xdl files to ncd files, or d) all of the above.
The correct answer is d.
Basically XDL files are an ascii plain text equivalent of the binary ncd file
which gives you hooks into and out of the normal tool flow without you having
to know the secrets of the NCD file. It intended to provide users with the
ability to write tools to meet their needs without having to write the entire
tool chain. You should definitely learn more about it, because I think you
could gain lots of leverage by using the existing flow to augment what you are
planning to do.
Neil Franklin wrote:
> Apropos XDL, which you have mentioned a few times:
>
> Where in the toolflow is it? I read the document and flowchart
> referred to in the other thread. In that I found: EDIF/XNF as inputs,
> NGD as first internal format (pre-map), NCD after mapping and second
> NCD after PAR, and then BIT after bitgen. XDL did not get mentioned
> anywhere.
>
> From your descriptions it sounds like the same levels as NCD.
>
--
--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: 48316I am not sure that there is power benchmark for FPGA. I think beginning from Xilnx library is a good start. One thing to consider is that the power consumption on FPGA depends on the circuit behavior and the the switching activity of input stimuli. Xpower assumes 12% switching activity if you don't provide the input stimuli. I also believe that Xpower is pretty accurate even though ISE 4.1 and ISE 5.1 from Xilinx give some different values. Hope that it's helpful. "JackC" <shuchin@ece.sunysb.edu> wrote in message news:ee799ee.-1@WebX.sUN8CHnE... > Hi, > > I am looking for a power consumption benchmark for FIR and FFT for Xilinx Vertex (or other newer version). I used Xpower to estimate the power consumption of a 32-tap linear phase FIR filter (sixteen 8-bit multipliers are used), with 1.8V supply voltage and 30 Mhz operation speed. The power is 35.3 mW (with power consumed by clock, signal routing, and logic only) but I don't know if this number is reasonable. Could anybody tell me where I can find the power consumption benchmark? > > thanks, JackCArticle: 48317
Try using the constraint: "uselowskewlines" on the net you have concerns with. Depending on the part, there are some dedicated routing resources that are available, just like being driven from a Bufg, I think, and this will reduce the skew and put the signal on a fast track so to speak. There is a another constraint I have not tried, maxdelay, that might help, but the uselowskewlines is a better choice in my opinion for a high fanout net. I am by no means an expert in constraining these designs. I am still learning. I am just sharing what I know that fixed a similar big problem for me. The Xilinx parts and associated software are a 10,000 bladed Swiss Army knife. Every tool has a little translucent cover on it and you can almost tell what it is going to do when you go to try and use it, but most likely, you will cut yourself at least once. Hope this helps. Clyde "C.W. THomas" wrote: > I have a schematic design with VHDL modules. > In my design I have a state machine with registered outputs one of these > outputs is driving a pair of FIFO read enables. I am shour on > simulation(late, notfast enough) by about 600 NS the signal has 25 loads. > It gets ptimized out if I split it into two parts. I tried entering into > the VHDL module the attribute MAX_LOAD but it dosen't do any thing. I don't > want to buffer anyway. I'd rather have two regs. > I cleared the "equivalent register removal" button in the synth options but > that dosen't seem to help. When I synth the module it dosent remove the 2nd > register but when I try to compile the whold design I seem to lose the > 2 signals and then the tool dies when it runs across: the following > > net "rd_fifo_a" period = 160 Mhz; > net "rd_fifo_b" period = 160 Mhz; > timegrp "tc_rd_fifo_a" = FFS (rd_fifo_a); > timespec "tsrd_fifo_a" = from "tc_rd_fifo_a" 4.23 ns; > timegrp "tc_rd_fifo_b" = FFS (rd_fifo_b); > timespec "tsrd_fifo_b" = from "tc_rd_fifo_b" 4.23 ns; > > and cant find the signal names rd_fifo_a and rd_fifo_b listed in the ucf > file. > > "Jay" <kayrock66@yahoo.com> wrote in message > news:d049f91b.0210112159.359d3164@posting.google.com... > > What is it that you are trying to accomplish by doing this? > > > > "C.W. THomas" <cwthomas@bittware.com> wrote in message > news:<uqehv4ldnktrff@corp.supernews.com>... > > > HI; > > > > > > > > > What is the attribute to keep a component from being optimized away in > ise > > > 4.2?? > > > > > > thanks;Article: 48318
Thanks,
The ground bounce clarifies the issue substantially. As you might have guessed,
much of my problem in my original design was likely due to ground bounce. The
internal ground plane was (and is) critical to to the noise floor improvement that
the FPGA approach brought to my design. While I realize that the PQ and HQ packages
do not provide as good a ground as the BGA type packages, they do much better than a
design based on a mixture of multiple 7400 series and ECL 100K devices (PECL mode).
Given that painful experience, I can certainly understand the advantage of a good
internal ground plane.
Austin Lesea wrote:
> Theron,
>
> The 2V40, 2V80, and 2V250 are available in the CS144 package, or the fg256
> package.
>
> That is as small (and inexpensive) as it gets. Both packages do quite well with
> regards to SI and EMC/EMI as they were designed from the bottom up to be good
> performers.
>
> The reason why we abandoned the use of pq/hq packages (in planning Virtex II) is
> that they provide no good ground plane, and even with the low IO count in these
> smaller die, the ground bounce due to SSOs can be terrible (if the return path
> ground inductance is as bad as it gets in the pq/hq lead frame packages).
>
> One could cut the SSO budget by half, and then use a pq/hq package, but it would
> be for a very small market segment.
>
I understand the small market comment, but what is the meaning of the term SSO?
>
> Austin
>
> Theron Hicks wrote:
>
> > Austin,
> > If I were using a chip that big in terms of I/O and gate count then I
> > would need a BGA package. In my case and, I suspect, in the case of the
> > poster, the smallest Virtex2 would be gross overkill in terms of both I/O
> > and gate count. What drove me to an FPGA approach in the first place is
> > that an FPGA created far less switching noise than a design based on a
> > mixture of ECL and 7400 series type logic. After I got into it I also found
> > that the FPGA offered incredible flexibility and a greatly reduced cost. I
> > did have to sacrifice a little on the speed end but we (my boss and I)
> > decided that this would be acceptable. Using a Virtex2 would have more than
> > gained back that sacrificed clock speed (by using the DCM). In fact, the
> > Spartan2E got me close to where I was with the mixed ECL design.
> >
> > If I may ask a hypothetical question...
> >
> > If one wanted a small Virtex2 in a low pin count package is it do-able?
> > I understand that a company such as Xilinx has to go for the large profit
> > customer. I just am wondering if the problem with the Virtex2 is chip
> > defined (i.e. both on chip routing and bonding to the pins) or pin defined
> > (the standard soic type pins themselves create an EMC problem at the
> > switching speeds of the Virtex2) or am I missing the point altogether.
> >
> > By the way, if funding ever were available to do a proper prototype, I
> > would still like to use a Virtex2. I think it is probably still a great
> > part. That also assumes that we can capture sufficient market share for our
> > product. Those two are probably really the same assumtion.
> >
> > Theron
> >
> > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> > news:3DAC740F.F619C54@xilinx.com...
> > > Try using a ff1517 2V8000....
> > >
> > > It is the number of pins.
> > >
> > > Austin
> > >
> > > Theron Hicks wrote:
> > >
> > > > Uwe,
> > > > I can route the package, I just can't assemble it. Changing the
> > number
> > > > of pins won't solve the problem. Furthermore, I don't buy that the EMC
> > > > problems are insurmountable. I regularly build ECL circuits at 1GHz in
> > > > standard SOIC packages. In fact, try to buy 100K ECL in anthing but
> > leaded
> > > > packages be they gullwing or J-lead. The only available packages are
> > > > leaded, not BGA. For example the MC100EP32 is rated for 4 Gigahertz
> > toggle
> > > > (divide by 2). It is only available in an 8 pin SOIC or 8 pin TSSOP
> > > > package. Check the http://www.onsemi.com web site Only the reduced
> > swing
> > > > ECL (RSECL) parts go to BGA. Those are rated for 12 GIGAHERTZ toggle.
> > > > Unless the problems are simply caused by the number of I/O pins then
> > I
> > > > am skeptical of the EMC issue.
> > > >
> > > > Just my opinionated opinion,
> > > > Theron Hicks
> > > >
> > > > "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
> > > > news:aohn4s$olb$1@news.tu-darmstadt.de...
> > > > > emanuel stiebler <emu@ecubics.com> wrote:
> > > > > : Is there any chance we could see something like this ?
> > > > > : I would love to use the speed of the VirtexII on a cheaper PCB.
> > > > >
> > > > > : Am I the only one who is dreaming about this packaging ?
> > > > >
> > > > > The question came up before. One answer was, that EMC problems nearly
> > > > > prohibit use of leaded packages for devices fast and powerfull like
> > the
> > > > > virtex. One proposal was to put out a BGA package with 1.27 mm pitch.
> > 4
> > > > > Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules
> > are
> > > > > afordable and a 4 row BGA can be routed with these rules.
> > > > >
> > > > > Bye
> > > > > --
> > > > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
> > > > >
> > > > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
> > > > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
> > >
Article: 48319
John_H wrote:
> One of the big EMC issues is due to ground bounce. Something you'll find with
> ECL is that if you use balanced I/O, the current drawn by the part is almost
> constant; only imbalanced drivers cause the limited swing in current draw. The
> dynamic change in current going through the ground wires will cause the internal
> chip ground to be significantly different than the system ground when
> switching. While I/O are responsible for a significant part of the ground
> bounce issue (leading to SSO guidelines), we cannot ignore the demands of the
> circuit internals.
John,
I certainly saw that in the "mixed" design. Even though most of the switching
activity was in the PECL portion of the circuit, most of the switching noise (ground
bounce) was being generated by the 7400 numbered 5v logic.
I will keep the rework machine idea in mind if we ever need to go to the virtex2
or other BGA parts. How does one inspect the solder joints to determine whether the
joints all have flowed correctly? How steep is the learning curve to mount the chip
consistently?
Your comment on the circuit externals also help clarify things somewhat.
Thanks,
Theron
>
>
> If you have a design running at 300MHz in a PQ208, the internal demands may
> compromise the internal ground. If you have a comfortably slow design with
> designed clock skews to spread the current spikes and limited I/O slew rates,
> you can probably get the design where you need. If you want 300Mbit I/O,
> chances are your SSO budget will be very few signals per bank.
>
> There are superb rework machines that in-house model shops use to replace BGAs.
> These could be used to provide first-time assembly with good results. The
> expense isn't the same as a soldering iron, but you might find it worth its
> purchase in just a couple prototype runs.
>
> Theron Hicks wrote:
>
> > Uwe,
> > I can route the package, I just can't assemble it. Changing the number
> > of pins won't solve the problem. Furthermore, I don't buy that the EMC
> > problems are insurmountable. I regularly build ECL circuits at 1GHz in
> > standard SOIC packages. In fact, try to buy 100K ECL in anthing but leaded
> > packages be they gullwing or J-lead. The only available packages are
> > leaded, not BGA. For example the MC100EP32 is rated for 4 Gigahertz toggle
> > (divide by 2). It is only available in an 8 pin SOIC or 8 pin TSSOP
> > package. Check the http://www.onsemi.com web site Only the reduced swing
> > ECL (RSECL) parts go to BGA. Those are rated for 12 GIGAHERTZ toggle.
> > Unless the problems are simply caused by the number of I/O pins then I
> > am skeptical of the EMC issue.
> >
> > Just my opinionated opinion,
> > Theron Hicks
> >
> > "Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message
> > news:aohn4s$olb$1@news.tu-darmstadt.de...
> > > emanuel stiebler <emu@ecubics.com> wrote:
> > > : Is there any chance we could see something like this ?
> > > : I would love to use the speed of the VirtexII on a cheaper PCB.
> > >
> > > : Am I the only one who is dreaming about this packaging ?
> > >
> > > The question came up before. One answer was, that EMC problems nearly
> > > prohibit use of leaded packages for devices fast and powerfull like the
> > > virtex. One proposal was to put out a BGA package with 1.27 mm pitch. 4
> > > Layer PCB prototypes with 0.3mm drill, 0.15mm lines/spaces designrules are
> > > afordable and a 4 row BGA can be routed with these rules.
> > >
> > > Bye
> > > --
> > > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
> > >
> > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
> > > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 48320"Theron Hicks (Terry)" wrote: <snip> > I will keep the rework machine idea in mind if we ever need to go to the virtex2 > or other BGA parts. How does one inspect the solder joints to determine whether the > joints all have flowed correctly? How steep is the learning curve to mount the chip > consistently? It looked like a straight-forward process. I didn't do any of the work myself, but one of the model shop guys showed me the workings of the thing. With the appropriate preheat section and a slider to the hot air reflow, it looked like a solid technique without too much leeway for problems. While a good visual inspection requires expensive inspection microscopes (extremely low profile view) for outside balls, the "right" way to fully inspect the balls is with X-ray inspection. While neither is appropriate for your needs, a cheap boundary scan might be the best way to go. Talking to the vendors that want to sell you those stations, you can probably get a better understanding of the ins and outs.Article: 48321
Tim wrote: > Austin Lesea wrote > > > The 2V40, 2V80, and 2V250 are available in the CS144 package, or the fg256 > > package. > > > > That is as small (and inexpensive) as it gets. Both packages do quite well > with > > regards to SI and EMC/EMI as they were designed from the bottom up to be good > > performers. > > > > The reason why we abandoned the use of pq/hq packages (in planning Virtex II) > is > > that they provide no good ground plane, and even with the low IO count in > these > > smaller die, the ground bounce due to SSOs can be terrible (if the return path > > ground inductance is as bad as it gets in the pq/hq lead frame packages). > > Just wondering: why do processors always(?) have on-package capacitors > but FPGAs never? Good question. Is it the number of I/O options (voltages and signal types) and the extremly wide operational frequency range? uPs usually run at maximum clock frequency which is known. Even fallout grade processors are relatively close to prime in operating frequency.Article: 48322
Hi, There is a commercial product addresses ALL of the issues mentioned in that thread. It is the B5-X-Download cable http://www.burched.biz/b5xdownloadcable.html It is US$52.00. It can also be used with third-party FPGA boards. Solid, hassle free FPGA configuration, even with long parallel cables running all the way across the lab:) Works with the free Xilinx Impact sofware. Does both serial mode and JTAG configuration. Best regards Tony Burch http://www.BurchED.biz FPGA boards for System-On-Chip prototyping and education "Kolja Sulimma" <kolja@bnl.gov> wrote in message news:25c81abf.0210151403.1e436c4a@posting.google.com... > Did you address the problems that are described in this thread: > > http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&selm=25c81abf.0210081329.e d45bc4%40posting.google.com > > The are also a couple of older threads on this topic. > > CU, > Kolja Sulimma > > "Leon Heller" <leon@heller123.freeserve.co.uk> wrote in message news:<aoh90d$k70$1@newsg3.svr.pol.co.uk>... > > Apparently, Xilinx has stopped making the Parallel Cable III. I've designed > > a DIY version of it using a single-sided PCB (with a few wire links) capable > > of being made at home. All components are through-hole, and it is just under > > 3" square. If anyone is interested in making one, please contact me. I can > > email the artwork (.PRN file for a LaserJet printer. > > > > > > LeonArticle: 48323
On Tue, 15 Oct 2002 16:40:49 GMT, "Stefano M" <stefano.mora@antispam.libero.it> wrote: >Allan, >thanks for your attention. > >> >PS: Xilinx Spartan/Virtex >> >> For this particular xilinx family, you *can* use the GCK pins as >> general purpose inputs, with the following restrictions: >> >> - There is no input flip flop >> - You can't use it as an output >> - You must use an IBUFG rather than an IBUF >OK, thanks > >> >> This was fixed in Virtex2, BTW. > >What do you mean with 'fixed' ? I mean that Virtex2 and Virtex2p have a full IOB, with INFF and OUTFF. So the GCK pin can be used as a general purpose I/O. Families prior to Virtex2 just have an IBUFG. Regards, Allan.Article: 48324
>Processors in FPGAs has to be handle more delicate than ASIC processor due to >forwarding in pipeline could easy remove all benefits gain by more pipeline stages. In >FPGA a mux cost as much as an ALU which is not the case for ASIC or custom design. > >Another approach is to rely on advanced compiler techniques for handling all the >pipeline hazardous but it would make it almost impossible to program the processor in >assembler since the user has to do the handling. >I personally don't think that this approach would gain that much more performance than >MicroBlaze and you have to spend a lot of resources on the compiler which could be >used for other stuff. This seems like an interesting opportunity for an open source project. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
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