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
Peter wrote: > >But: There is a self-discharge mechanism that is the real limitation. > >Good 3-V Lithium batteries have a shelf life of 15 years or more. > > This is a much bigger issue than it first appears. I have designed a > number of very low power products powered by lithium watch-type cells, > did a lot of evaluations of different cells, and it was amazing to > find how bad some cells were. One make (European) had a shelf life > consistently of about 1 year (to <20% capacity), the best Japanese > makes were probably >10 years, but "bad batches" happen right across > the board. > > I would be very unhappy relying on a shelf life of 10-15 years for a > critical application, e.g. where loss of battery power would make a > product *permanently* (i.e. even if the battery is replaced) > non-functional. All you need is a bad batch of cells and maybe 5 years > later you get a whole lot of extremely unhappy customers... > > Peter. > -- & of course when those p****d off customers try to contact the supplier who knows what they'll find - out of business, taken over several times, ``I'm sorry that product is discontinued since all the people who understood it have left'', ``did we make that ?!'', ...Article: 28951
They all change their URL's daily, God knows why. Looks like today they are at http://www.celoxica.com/products/boards/RC1000_ds_final.pdf In article <9573ku$igl$1@nnrp1.deja.com>, erika_uk@my-deja.com wrote: >the link is broken!! >In article <ah6c6.14773$t3.3374499@typhoon.ne.mediaone.net>, > pratipm@hotmail.com (Pratip Mukherjee) wrote: >> A near fit would be >http://technology.celoxica.com/boards/boards_001.asp >> >> In article <94qcnq$d46$1@nnrp1.deja.com>, jimmy75@my-deja.com wrote: >> > >> >> None of our boards will fit this particular application. A board >> >> with a PCI bus interace is needed for the high-speed transfers >> >> between the FPGA board memory and the PC running the desktop >> >> publishing app. All our boards interface through the >> >> parallel port which is too slow for this type of application. >> > >> >Yep. We need a PCI board for our purpose preferably with a DMA >> >controller and a Xilinx Virtex chip(s) and lots of memory. If only we >> >could make one on our own! >> >I had a look on the web and didn't find all these features altogether >> >in one board. We were hoping that somebody out there could help us. >> > >> >-- Jim >> > >> > >> >Sent via Deja.com >> >http://www.deja.com/ >> > > >Sent via Deja.com >http://www.deja.com/Article: 28952
> First of let me ask you why you are trying to convert the gate level > netlist. It would be much easier to convert the RTL. Assuming that you > really want to do the gate level conversion, you have to make models > of all the cells in the netlist. Put them in a library file and > include it in your synthesis script. It can be a tedious and error > prone process. agree. but generally unless you happen to have your own waferfab kicking about you're going to need process docs, techfiles, and pref. semi-custom libraries from your silicon vendor. IMHO, you need to forget everything in your fpga implementation and start again with sim and synthesis based on the vendor library. if for some bizarre reason you actually want to keep a 1-to-1 gate level correspondance, then yes, you need to make your own library, but base it on a verified vendor library. Library development is a lot of work. Even coding styles for FPGA and ASIC implementation can be different at RTL level. FPGA are constrained, in ASIC you would like your synthesis tool to optimise against some cost function which is relatively continuous in comparison to the corresponding cost function in the FPGA. restraining an ASIC design doesn't make much sense. enjoy :) ed chesterArticle: 28953
Does anyone know of any ASIC of FPGA design engineers in the Bay Area that are looking for new career opportunities? I am representing a few great companies that are in need of these engineers, and I am having a tough time finding any. Any referrals that anyone can send will be a great help, and I am in a position to pay a referral fee. If you know of anyone, please email me at amy@stingraysys.com Thanks!!!!!!!Article: 28954
"Pratip Mukherjee" <pratipm@hotmail.com> wrote in message news:ogJd6.29493$t3.5470101@typhoon.ne.mediaone.net... > They all change their URL's daily, God knows why. Looks like today they > are at http://www.celoxica.com/products/boards/RC1000_ds_final.pdf And the company name? Are they the old Handel-C people? Celoxica sounds like an ointment for a social problem.Article: 28955
Hi, We have a whole bunch of old boards with Virtex-E parts on them. The problem is that the Virtex-E parts are engineering samples, and the newer speed files (we're using ver 1.48) produce non-functional designs. I'm fairly sure it's a speed file issue. I need the design to work with a clock period of 'T' ns. Trce says the design should work with a 0.941 * T clock period. I.e. there should be a comfortable margin. At room temperature, I need to increase the clock period to 1.03 * T for the errors to go away. With a short burst of freeze spray, I can get it to work with a clock period of T. The same design in newer silicon on an otherwise identical board works ok over the full temperature range. The question is: what should be done with the old boards? Is it possible to obtain speed files that match the ES parts? Is it possible to change the timespecs to compensate for the changed silicon? For example, if we know that the ES silicon is slow in one particular area (perhaps shift register clock to output delay) we can put a tighter constraint on the affected paths. Other solutions involve scrapping the boards, or trying to change large BGAs, both of which I'd like to avoid if there's a simpler or cheaper way. TIA, Allan. -- Allan Herriman mailto:allan_herriman.hates.spam@agilent.com Agilent Technologies Voice: +61 3 9210 5527 Advanced Networks Division Fax: +61 3 9210 5550 347 Burwood Highway Forest Hill 3131 AustraliaArticle: 28956
Hello! With reference to Mr. Ray Andraka's paper : " A survey of CORDIC algorithms for FPGA based computers": I would like to put forward these questions : 1) In the "arcsin" computation, there is always a negative sign with the result. e.g. we get -30 deg. instead of +30 deg. for c=0.5, Xo=1/An. ? The equation Zn= Zo + arcsin(c/AnXo) suggests +30. deg if we initialize Zo=0; why? 2)In the linear mode (m=0) what is the factor that limits the correct results? We get correct results only when the results of multiplication (XoZo) and division (Yo/Xo) are expected to be less than or equal to 2? is it so? Also in linear VECTORING mode, the equation Zn= Zo - Yo/Xo is not satisfied? Results seem to be according to the equation Zn= Zo + Yo/Xo ( a PLUS sign)... 3) And last but not the least, the fixed point issue. Since we have to perform addition/subtraction operations in the algorithm, so the binary point (for fixed point) must be aligned in all three CORDIC equations. Now since all the e_i 's are pre-stored constants, so doesn't it force the user to represent X,Y,Z,C all in the same fixed point format as the e_i 's? And if so, then is it possible to build a general CORDIC processor in which the format of inputs X,Y,Z,C may not match that of e_i 's? Please if a detailed answer is possible? Thanks. -- --saqib yaqub-- Sent via Deja.com http://www.deja.com/Article: 28957
I discovered that the file generation has to be done in this order: First set the JTAG components on a chain similar to how they are arranged on the board. Then generate the .svf file. After that choose the operation to be performed and execute it, and JTAG Programmer adds the information to the svf file generated before. Then the file is ready to be programmed. Mikko Heikkerö mheikker@cc.hut.fi --Article: 28958
So it looks like you are really close (1.03 x T => off by 3%), but that is at room temp. At hot, or low VCC, you may be off by more than 3%. So what you didn't say is which speed grade you are telling the PAR program. So here is a suggestion. Re-run PAR and tell it the speed grade is 1 grade slower than the speed you have been telling it currently. i.e current rescue speed speed -8 -7 -7 -6 -6 dont know. no slower speed grade, you are hosed. (or maybe for -6, you rewrite all the time specs to be 10% tighter than they are currently) typically there is about 10% to 15% difference in the performance of the chips for adjacent speed grades. Set the placer and router to maximum effort (5) and run several delay-cleanup passes (maybe 5). If you can get this to not have problems with TRCE, you are probably going to be fine. If TRCE shows only a few paths with trouble, maybe you can make design changes (add pipelining, split heavily loaded nets, floorplanning, ....) to get this to meet timing. Good luck Philip Freidin On Wed, 31 Jan 2001 13:06:54 +1100, Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote: >Hi, > >We have a whole bunch of old boards with Virtex-E parts on them. The >problem is that the Virtex-E parts are engineering samples, and the >newer speed files (we're using ver 1.48) produce non-functional designs. > >I'm fairly sure it's a speed file issue. I need the design to work with >a clock period of 'T' ns. >Trce says the design should work with a 0.941 * T clock period. I.e. >there should be a comfortable margin. > >At room temperature, I need to increase the clock period to 1.03 * T for >the errors to go away. With a short burst of freeze spray, I can get it >to work with a clock period of T. >The same design in newer silicon on an otherwise identical board works >ok over the full temperature range. > >The question is: what should be done with the old boards? Try above. May save a bundle of boards. >Is it possible to obtain speed files that match the ES parts? Probably not. >Is it possible to change the timespecs to compensate for the changed >silicon? Yep. Recomended above as one possible solution. >For example, if we know that the ES silicon is slow in one particular >area (perhaps shift register clock to output delay) we can put a tighter >constraint on the affected paths. Yep. >Other solutions involve scrapping the boards, or trying to change large >BGAs, both of which I'd like to avoid if there's a simpler or cheaper >way. The above should be tried first, as the investment and effort are small. Note above, that you could also try load splitting and pipelining and floor planning to improve the situation. >TIA, >Allan. Philip Freidin FliptronicsArticle: 28959
Hi all! We are developing an embedded system that includes a JTAG chain with programmable configuration PROMs (XILINX XC18V00) and FPGAs (Virtex-E 600/400/200) controlled through a Motorola mP (PowerQUICC II). This has been designed in order to have the possibility to download the FPGA programs directly through mP. The question is: how can I write to the ROMs through JTAG (XILINX XC18V00 offers only basic commands)? Does an application note exist? If not, has someone experience with this topic? Many thanks Luca Haab ------------------------------------------------------------------------ Luca Haab Software Engineer BroadNet Division Ascom Transmission Ltd Schwarzenburgstrasse 73 CH-3097 Berne Tel:+41 31 999 3341 Fax:+41 31 999 3057 mailto:luca.haab@ascom.ch Sent via Deja.com http://www.deja.com/Article: 28960
Simon Bacon writes: > And the company name? Are they the old Handel-C people? Yes, they used to be Embedded Solutions and they still do Handel-C. The name change seems to have coincided with the introduction of Handel-C version 3. > Celoxica sounds like an ointment for a social problem. That's what we at CERN think too :-) -- JamieArticle: 28961
I want to build a single cycle micro-programmable "processor" using the Virtex / Virtex2 block ram for the instruction memory. This RAM is synchronous, but could still be used in a single cycle machine if I could use the D-inputs of the flip flops of the address counter to address the block RAM. I would also need to get at the address counter's Q outputs (or just register these D-inputs). My "gate level" counter runs too slow (goal is a 9.4 ns instruction cycle). I've tried an adder, but get way more logic than I need (so its too slow also). Does anyone know if I can get at the D-inputs to the FF's in a fast carry loadable counter like a CC16CLE? Or maybe I need a different kind of counter? It wouldn't HAVE to be binary (although binary would sure be easier). Thanks DanArticle: 28962
Hi Falk,
In article <3A76CA05.615EEC8B@gmx.de>,
Falk Brunner <Falk.Brunner@gmx.de> wrote:
> I just played around with a Spartan 2 demo board. One nice feature of
> Spartan2 / Virtex is the DLL, which can create 4 clock phases and even
> double the input clock. Unfortunately, the minimum input frequency is
25
there has been a thread on this issue two weeks ago, I tried to gather
information on driving a DLL with 24MHz. I ended up combining a
combinational clock doubler with a DLL.
In the following you'll find the code that I am using- which works fine
with my application.
Hope this helps,
best regards
Best regards
Felix Bertram
_____
Dipl.-Ing. Felix Bertram
Trenz Electronic
Duenner Kirchweg 77
D - 32257 Buende
Tel.: +49 (0) 5223 41652
Fax.: +49 (0) 5223 48945
Mailto:felix.bertram@trenz-electronic.de
http://www.trenz-electronic.de
---------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use work.CfgPak.all;
entity Clk4x is
port(
clk24 : in std_ulogic;
dllrst : in std_ulogic;
reset : in std_ulogic;
clk96 : out std_ulogic
);
end Clk4x;
architecture BHV of Clk4x is
component bufg
port (
I : in std_ulogic;
O : out std_ulogic
);
end component;
component clkdll
port (
CLKFB : in std_ulogic := '0';
CLKIN : in std_ulogic := '0';
RST : in std_ulogic := '0';
CLK0 : out std_ulogic := '0';
CLK180 : out std_ulogic := '0';
CLK270 : out std_ulogic := '0';
CLK2X : out std_ulogic := '0';
CLK90 : out std_ulogic := '0';
CLKDV : out std_ulogic := '0';
LOCKED : out std_ulogic := '0'
);
end component;
component FDC
port (
C : in std_ulogic;
CLR : in std_ulogic;
D : in std_ulogic;
Q : out std_ulogic
);
end component;
component inv
port (
I : in std_ulogic;
O : out std_ulogic
);
end component;
component srl16
port (
A0 : in std_ulogic;
A1 : in std_ulogic;
A2 : in std_ulogic;
A3 : in std_ulogic;
CLK : in std_ulogic;
D : in std_ulogic;
Q : out std_ulogic
);
end component;
component xor2
port (
I0 : in std_ulogic;
I1 : in std_ulogic;
O : out std_ulogic
);
end component;
attribute dont_touch: STRING;
constant VCC_CONSTANT : STD_LOGIC := '1';
signal clk48 : std_ulogic;
signal iii_clk96 : std_ulogic;
signal ii_clk96 : std_ulogic;
signal q : std_ulogic;
signal qinv : std_ulogic;
signal NET8262 : std_ulogic;
signal NET8887 : std_ulogic;
signal VCC : STD_LOGIC;
attribute dont_touch of Uff : label is "true";
attribute dont_touch of Uinv1 : label is "true";
attribute dont_touch of Uxor : label is "true";
begin
Ubuf : bufg
port map(
I => ii_clk96,
O => iii_clk96
);
Udll : clkdll
port map(
CLK2X => ii_clk96,
CLKFB => iii_clk96,
CLKIN => clk48,
RST => NET8887
);
Uff : FDC
port map(
C => clk48,
CLR => reset,
D => qinv,
Q => q
);
Uinv1 : inv
port map(
I => q,
O => qinv
);
Uinv2 : inv
port map(
I => NET8262,
O => NET8887
);
Usr : srl16
port map(
A0 => VCC,
A1 => VCC,
A2 => VCC,
A3 => VCC,
CLK => clk48,
D => dllrst,
Q => NET8262
);
Uxor : xor2
port map(
I0 => clk24,
I1 => qinv,
O => clk48
);
VCC <= VCC_CONSTANT;
clk96 <= iii_clk96;
end BHV;
---------------------------------------------------------------------
-- end of file
Sent via Deja.com
http://www.deja.com/
Article: 28963Saqib wrote: > > Hello! > > With reference to Mr. Ray Andraka's paper : " A survey of CORDIC > algorithms for FPGA based computers": I would like to put forward these > questions : > > 1) In the "arcsin" computation, there is always a negative sign with > the result. e.g. we get -30 deg. instead of +30 deg. for c=0.5, > Xo=1/An. ? The equation Zn= Zo + arcsin(c/AnXo) suggests +30. deg > if we initialize Zo=0; why? I think I got the sign of decision variable backwards in the z equation. I think it should be Zi+1=Zi + di atan(2^-i). > > 2)In the linear mode (m=0) what is the factor that limits the correct > results? We get correct results only when the results of multiplication > (XoZo) and division (Yo/Xo) are expected to be less than or equal to 2? > is it so? Depends on where your radix point is. It sounds like you are getting overflow. If you are using fractional fixed point notation, then your statement is correct. > > Also in linear VECTORING mode, the equation Zn= Zo - Yo/Xo is not > satisfied? Results seem to be according to the equation Zn= Zo + > Yo/Xo ( a PLUS sign)... That is correct. I got the signs wrong in a couple of the equations. > > 3) And last but not the least, the fixed point issue. Since we have to > perform addition/subtraction operations in the algorithm, so the binary > point (for fixed point) must be aligned in all three CORDIC equations. > Now since all the e_i 's are pre-stored constants, so doesn't it force > the user to represent X,Y,Z,C all in the same fixed point format as the > e_i 's? And if so, then is it possible to build a general CORDIC > processor in which the format of inputs X,Y,Z,C may not match that of > e_i 's? Please if a detailed answer is possible? As you sort of noted, CORDIC really is not well suited for floating point implementation because the data's radix points have to align for each add/subtract operation. The radix point must have the same alignment for the x and y elements because of the crossover connections. The z element can have a different radix point alignment because the only interaction between the z (phase accumulator) element and the rotator is via the decision variable. As a result, z the units of z can be arbitrarily assigned. Since C is a comparison (we're talking about the Arcsin here) with the Y rotator element, it also must have the same weighting as the x andy elements. If floating point must be handled, then you should first normalize the x and y inputs so that they share a common exponent and so the larger of the two is normalized. Then perform a fixed point rotation, carrying the exponent around the rotator. > > Thanks. > > -- > --saqib yaqub-- > > Sent via Deja.com > http://www.deja.com/ -- -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 or http://www.fpga-guru.comArticle: 28964
javidiaz@my-deja.com wrote: > > Hi, I am student from Puerto Rico: > > We are trying to figure out how to implement an algorith that takes a > 9*9 matrix (8 bits each element)and do a windowing of 5*5 in a column- > wise and row-wise sliding and calculate for each 5*5 Moving-Window the > Standard Deviation. > Questions: > 1. How do I handle the Squared Root of the SD? Depends on the device and yoru required precision. > 2. And Which is better to implement on Xilinx XC4036 a floating-point > or a fix-point approach for the results (another 9x9 matrix)? Use fixed point if you can. > 3. I need to do a storage of those results: How do I configure the RAM > resources for float-P or Fix-point? NOt sure I understand the question. The ram just stores a bit pattern. How you define the bits is up to you. for floating point, some of the bits represent the position of the radix point, where fixed point has an implied fixed location of the radix point. > 4. Can you provide me good web resources to understand how to implement > floating/fix point on FPGA? > > I hope to have some feedback on this regard, > > Javier > > Sent via Deja.com > http://www.deja.com/ -- -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 or http://www.fpga-guru.comArticle: 28965
You can, but not for a logicore/coregen counter. You have to roll your own to get at the D inputs. You may be dissappointed with the performance however. The Block Ram is one of the slowest elements in the FPGA: it has a relatively long setup time. Additionally, you wind up with possibly long routes to connect to it from your logic. In your case, you are driving the addresses directly out of a carry chain, which is typically the critical path in a design, so you are combining all the worst case paths into a single combinatorial run. You'll want to keep the loadable counter logic to one level. (I think the CCxxCLE is two levels of logic). It can be done, but requires some clever coding. The load mux comes before the carry chain in that case, so load has to disable the carry using the MULT_ANDs. I have not found a coding style that reliably infers the correct structure. You may have to instantiate the primitives to get the desires structure. Also, the load control will be a critical path as it has a high fanout and feeds through the carry chain to the BRAM address, so you will need to duplicate it, and put the duplicated registers immediately adjacent to the carry chain to keep the speed up. Dan K wrote: > > I want to build a single cycle micro-programmable "processor" using > the Virtex / Virtex2 block ram for the instruction memory. This > RAM is synchronous, but could still be used in a single cycle machine > if I could use the D-inputs of the flip flops of the address counter to > address the > block RAM. I would also need to get at the address counter's Q outputs > (or just register these D-inputs). > > My "gate level" counter runs too slow (goal is a 9.4 ns instruction cycle). > I've tried an adder, but get way more logic than I need (so its too slow > also). > Does anyone know if I can get at the D-inputs to the FF's in a fast carry > loadable counter like a CC16CLE? > Or maybe I need a different kind of counter? It wouldn't HAVE to be binary > (although binary would sure be easier). > > Thanks > > Dan -- -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 or http://www.fpga-guru.comArticle: 28966
Dan, you may find the paper for my DesignCon'2001 talk (which I am presenting later today) helpful. It provides the annotated Verilog source code for a simple, compact, non-pipelined 16-bit RISC CPU and system-on-a-chip. It uses the same PC incrementer -> BRAM topology you describe in your question. The paper is at http://www.fpgacpu.org/soc-gr0040-001201.pdf. If you have branch or jump-and-link instructions, which can modify the next PC value, it is challenging to execute a single instruction in less than 10 ns without pipelining. In a slow speed Virtex device, the clock-to-out on the BRAM is about 4 ns. Then (minimum) you have to route the instruction's branch displacement field to the PC branch adder, then branch adder latency, a few ns, then perhaps a mux, then back to the BRAM address inputs and the BRAM address setup time of 1 ns or so. If you put in an 'instruction register' pipeline stage to simply absorb the BRAM clock-to-out delay and routing delay, you get a much better chance to hit sub 10 ns. > My "gate level" counter runs too slow (goal is a 9.4 ns instruction cycle). > I've tried an adder, but get way more logic than I need (so its too slow > also). For a loadable binary counter, at a minimum you need one LUT + carry logic per bit. See the detailed discussion at http://www.fpgacpu.org/log/nov00.html#001112. The last time I looked, the loadable binary counter CC16CLE unnecessarily used two LUTs per bit. Xilinx should fix that. A straight adder should also only need one LUT per bit. > Does anyone know if I can get at the D-inputs to the FF's in a fast carry > loadable counter like a CC16CLE? If you use the library symbol CC16CLE you can't get at those inputs. If you build one yourself, you certainly can. If you have a schematic editor, I encourage you to 'open up' the CC16CLE library symbol and see what's going on under the hood. Have fun. Jan Gray, Gray Research LLC FPGA CPU News: www.fpgacpu.orgArticle: 28967
Hi Luca, We had similar problem. I asked Xilinx, but got no solution. So we had to hack it ourselves using Parallel Cable III and logic analyzer. BSDL file of the XC1800 is needed also. For programming we use .mcs (HEX format) data file. First you have to send FERASE instruction, then ISPEN instruction. Programming proceed using FARRD and FPGM instructions. It is complicated enough, different for small PROMs (up to XC1801) and bigger ones. We made a small document, describing XC1800 programming, but it is in Estonian. Jaan Sirp, <BR>Casual >We are developing an embedded system that includes a JTAG chain with >programmable configuration PROMs (XILINX XC18V00) and FPGAs (Virtex-E >600/400/200) controlled through a Motorola mP (PowerQUICC II). This has >been designed in order to have the possibility to download the FPGA >programs directly through mP. >The question is: how can I write to the ROMs through JTAG (XILINX >XC18V00 offers only basic commands)? Does an >application note exist? If not, has someone experience with this topic? > > >Many thanks >Luca Haab > > >------------------------------------------------------------------------ >Luca Haab >Software Engineer >BroadNet Division >Ascom Transmission Ltd >Schwarzenburgstrasse 73 >CH-3097 BerneArticle: 28968
Dear Colleagues, The off-site, pre-registration deadline for FPGA'01 is Friday, February 2. After this deadline all conference registration will take place at the conference site. I hope you will join us for this exciting event. -------------------------------------------------- FPGA 2001 2001 ACM/SIGDA Ninth International Symposium on Field Programmable Gate Arrays Doubletree Hotel, Monterey, California February 11-13, 2001 http://www.ecs.umass.edu/ece/fpga2001 Sponsored by ACM/SIGDA with support from Altera, Xilinx, Agere Systems, Cypress and Actel Join us for the ninth ACM/SIGDA International Symposium on Field Programmable Gate Arrays (FPGA 2001), the premier forum for novel work in all areas related to FPGA technology. This year's symposium features twenty-four papers and twenty-three poster presentations describing cutting-edge FPGA research. Authors from universities, research laboratories and commercial vendors present new work on topics ranging from applications and reconfigurable computing to device architecture and design tools. An entire session is devoted to applications in image and video compression. Paper sessions are separated by ample time to peruse the poster presentations and discuss the latest FPGA news. The panel this year addresses the question of what FPGAs will look like in the era of systems-on-a-chip. Is it now clear that programmable logic should be combined with ASICs and microprocessors? How should they be combined? What tools are needed to support these devices? FPGA 2001 provides a relaxed atmosphere for informal information exchange, networking and stimulating discussions with the leaders in FPGA research and development from industry and academia as well as the next generation of FPGA researchers If you are at all interested in FPGA technology and developments, you won't want to miss this event.Article: 28969
Hi all,
I have actually a problem to reuse a .edf file generated by
LeonardoSpectrum in the Design manager of Foundation.
When I look my report file generated by Foundation, I can see the
following lines:
----------------------
Annotating constraints to design from file "concatened.ucf" ...
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(3)' in design
'interface'. NET entry is 'NET mini_ezx_pin(3) LOC = P42 ;
'
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(2)' in design
'interface'. NET entry is 'NET mini_ezx_pin(2) LOC = P41 ;
'
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(1)' in design
'interface'. NET entry is 'NET mini_ezx_pin(1) LOC = P40 ;
'
ERROR:NgdBuild:397 - Could not find NET 'mini_ezx_pin(0)' in design
'interface'. NET entry is 'NET mini_ezx_pin(0) LOC = P39 ;
----------------------
Now, If I edit my .edf file to find 'mini_ezx_pin(3)' port, I can see
the lines :
----------------------
(port (rename p0 "mini_ezx_pin(3)") (direction INPUT))
(port (rename p1 "mini_ezx_pin(2)") (direction INPUT))
(port (rename p2 "mini_ezx_pin(1)") (direction INPUT))
(port (rename p3 "mini_ezx_pin(0)") (direction INPUT))
I do not understand why LeonardoSpectrum rename all my vectors when I
generate my output .edf file ???
Also, working with Virtex and Virtex-E, what is the better format to use
between EDIF and XNF.
Thank you in advance.
Regards
Laurent
for Amontec (www.amontec.com)
Article: 28970
Hi all,
I have this 'gearbox' coded up in Verilog and it is large
and not quite fast enough when implemented in an FPGA.
The 'gearbox' function is straight forward: 64 bit data
bus input at 200 MHz needs to output a 66 bit data bus at
206.25 MHz. Same bandwidth. The clock rate conversion
isn't a problem (I'm using 2 clocks), but the data width
conversion is getting big and sluggish on me.
The way I have coded it up is a 33 modulo counter and a
case statement (MUXes) with the condition the counter
value at which the data is shifted into the output
register (after prefill). Like:
case(cnt33) /*synthesis parallel_case*/
6'd0: {gearbox_reg[189:0]} <= #1 {datain_64b,
gearbox_reg[191:66]};
6'd1: {gearbox_reg[187:0]} <= #1 {datain_64b,
gearbox_reg[189:66]};
.
.
.
6'd30: {gearbox_reg[129:0]} <= #1 {datain_64b,
gearbox_reg[131:66]};
6'd31: {gearbox_reg[127:0]} <= #1 {datain_64b,
gearbox_reg[129:66]};
default: gearbox_reg[191:128] <= #1 datain_64b;
endcase
I also pipelined this by using an modulo 4 counter nested
in a modulo 8 counter and a temporary register stage. I
got quite a bit more speed then, but the area (# of FPGA
logic blocks) is getting too large.
I also tried to do this function with memory and address
and data pointers, but it became a mess that didn't work
well with the block memories in the FPGA.
So, my question is: does anyone have any ideas or
suggestions on a better way to accomplish this 'gearbox'
function?
Article: 28971Here is some additional information, fresh from the Virtex-II handbook and the newest speeds files: Ray Andraka wrote: > You can, but not for a logicore/coregen counter. You have to roll your own to > get at the D inputs. The D-inputs are brought out on the Y outputs of the CLB, whether you like it or not ( you would like it ). Same in Virtex-II. > You may be dissappointed with the performance however. > The Block Ram is one of the slowest elements in the FPGA: it has a relatively > long setup time. In Virtex the set-up time to address and data inputs is 1.2 to 1.5 ns In Virtex-E the set-up time to address and data inputs is 1.0 to 1.1 ns In Virtex-II the set-up time to address and data inputs is 0.30 to 0.35 ns but since the address decoders and the whole RAM array is "behind" the input flip-flops, the clock-to-out is a relatively long 2.6 to 2.9 ns, even in Virtex-II. So it's not ( or no longer ) a set-up-time problem... Peter Alfke, Xilinx Applications >Article: 28972
A clock doubler chip from ICS may be simpler for most people. And it would be small and cheap. Falk Brunner <Falk.Brunner@gmx.de> wrote: > I just played around with a Spartan 2 demo board. One nice feature of > Spartan2 / Virtex is the DLL, which can create 4 clock phases and even > double the input clock. Unfortunately, the minimum input frequency is > 25Article: 28973
Leonardo did it because it does not know for sure which characters will be reserved/illegal in the estimation of the downstream tools. If you are confident, you can write a small PERL script to unrename the ports. The strings in EDIF2NGD seem to indicate that Xilinx implements a pretty full EDIF grammar - legal EDIF should be OK to Xilinx, though AFAIK they have never published anything on this. Try a simple case. Manually edit one of the renames and see how the tools respond. "Laurent Gauch" <laurent.gauch@amontec.com> wrote in message news:3A784A25.8000303@amontec.com... > Now, If I edit my .edf file to find 'mini_ezx_pin(3)' port, I can see > the lines : > ---------------------- > (port (rename p0 "mini_ezx_pin(3)") (direction INPUT)) > (port (rename p1 "mini_ezx_pin(2)") (direction INPUT)) > (port (rename p2 "mini_ezx_pin(1)") (direction INPUT)) > (port (rename p3 "mini_ezx_pin(0)") (direction INPUT)) > > > I do not understand why LeonardoSpectrum rename all my vectors when I > generate my output .edf file ??? > > Also, working with Virtex and Virtex-E, what is the better format to use > between EDIF and XNF. EDIF. XNF is under a death sentence, though the appeal process is being dragged out.Article: 28974
No, it is just not an obvious implementation. The load control is the critical path on the one layer of logic implementation, so in terms of performance you need to either duplicate the load a bunch or go to two levels. The limitation is the fact that the LUT logic precedes the carry chain, so if it is described in the conventional manner in VHDL using an IF construct, you end up with a mux after the carry, and therefore two levels of logic. Ben Franchuk wrote: > > Jan Gray wrote: > > > The last time I looked, the loadable binary counter CC16CLE unnecessarily > > used two LUTs per bit. Xilinx should fix that. A straight adder should > > also only need one LUT per bit. > > There may be hidden buffering or Hardware dependent limitations on the carry > chain is my guess. > > -- > "We do not inherit our time on this planet from our parents... > We borrow it from our children." > "Luna family of Octal Computers" http://www.jetnet.ab.ca/users/bfranchuk -- -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 or http://www.fpga-guru.com
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