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, FPGA synthesis can be transparent to Ambit when the library contain sufficent information (loading, drive, timing model and so on). The netlist can be converted to EDIF and then Alliance should be able to P&R it. It can be done thru design compiler since .db file is provided. (Not only FPGA compiler but also dc.) Yet we cannot do it with Ambit with an Ambit library. Muzaffer Kal wrote: > Ambit is strictly an ASIC synthesis tool. I don't believe it supports > any FPGA devices. You're much better off with Synplicity tools for > Virtex anyway. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.comArticle: 29601
Kelvin CHEUNG/ÕżÒΰ/±i®a°¶ <cheungkw@solomon-systech.com> wrote: >Hi, > >FPGA synthesis can be transparent to Ambit when the library contain > sufficent information (loading, drive, timing model and so on). >The netlist can be converted to EDIF and then Alliance should be >able to P&R it. It can be done thru design compiler since .db file > is provided. (Not only FPGA compiler but also dc.) Yet we cannot > do it with Ambit with an Ambit library. Yes it "can" be. What makes Buildgates a strictly ASIC synthesis tool is that Cadence doesn't support any FPGA devices. There are no FPGA libraries for Buildgates. In theory, theory and practice are the same thing. In practice they aren't. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 29602
Hello,
I would not worry for this.
I would define and instantiate the STARTUP component in your top level
module. If you do that you won't need to include the UNISIN library, it is
an enormous library and your compile time could be increased.
-- component definition for the startup block
component STARTUP
port
(
GSR : in std_logic;
GTS : in std_logic;
CLK : in std_logic;
Q2 : out std_logic;
Q3 : out std_logic;
Q1Q4 : out std_logic;
DONEIN : out std_logic
);
end component;
-- Instantiate the xilinx specific startup component.
-- This ensures that the reset signal uses the specific
-- global reset resources.
SU : STARTUP
port map
(
GSR => RST,
GTS => RST,
CLK => dummy,
Q2 => open,
Q3 => open,
Q1Q4 => open,
DONEIN => open
);
I hope this help you.
"Qian" <junciu@yahoo.com> wrote in message news:ee6fc84.-1@WebX.sUN8CHnE...
> Hi I try to use GSR then I include
> --LIBRARY ieee;
> library IEEE;
> library UNISIM;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.std_logic_unsigned.all;
> use UNISIM.all;
>
> I use Xilinx Foundation and try to
> check syntax, however it says
>
> "library logic name UNISIM cannot be mapped to a host directory"
>
> How to solve it ?
> Thanks al ot!
Article: 29603Not so fast. I did run BuildGates with a library of Lucent ORCA3 fpga. I manage to get a verilog netlist then had it converted to edif. I then ran the edif in Lucent's P&R. While I did get results they were less than optimal. I didn't get the library from Cadence. regards Jerry Muzaffer Kal wrote: > Kelvin CHEUNG/ÕżÒΰ/±i®a°¶ <cheungkw@solomon-systech.com> wrote: > > >Hi, > > > >FPGA synthesis can be transparent to Ambit when the library contain > > sufficent information (loading, drive, timing model and so on). > >The netlist can be converted to EDIF and then Alliance should be > >able to P&R it. It can be done thru design compiler since .db file > > is provided. (Not only FPGA compiler but also dc.) Yet we cannot > > do it with Ambit with an Ambit library. > > Yes it "can" be. What makes Buildgates a strictly ASIC synthesis tool > is that Cadence doesn't support any FPGA devices. There are no FPGA > libraries for Buildgates. In theory, theory and practice are the same > thing. In practice they aren't. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.comArticle: 29604
Rick, I think you may have misunderstood my comment. The original thinking was 'Virtex thinking' for larger parts -- which breaks down completely for smaller parts! I agree with you. 1 watt for 4 2S15's split between all of the IO's at 3.3 Vdc, and the cores at 2.5 Vdc is a real challenge, I admit. If in the steady state, 1 watt is plenty to operate the four parts, that leaves us with the startup issue. I admit that for -40C, worst case is 2 amperes (right now, as we don't have enough 2S15 silicon to characterize the -40C number, so we have to go with what we know from larger parts -- it could be less). The thought of having to supply 8 amperes to start them up at 2.5 Vdc is a little (lot) daunting. Is there any way to use a larger part, rather than four separate smaller parts? I suppose that isn't a very smart question, as you probably already optimized your system architecture, but I have to ask. Ultimately, one could design an 8 amp peak switcher than would deliver the 8 amps for at least 1 ms to get them all started. If you could tolerate a 500 mV dip in the 3.3 volts running the DC to DC switcher, the input capacitor has to be I*dt/dv, or 8 * .001/.5 = 4,000 uF. That isn't all that obscene, as 4,700 uF at 6.3 wv is still a pretty small component. I would go with 10,000uF as at -40 C the capacitor (if it is the proper one engineered for -55C in the data sheet) will have 40% of its room temperature value. Do not use a standard -40C capacitor, as they have 0 capacitance at -40C (really, I measure them all of the time to prove this to the disbelievers!). The capacitor specifications refer to damage, not operation, and since they are electrolytes (i.e. there is water in there), it just makes sense that at really low temperatures they are not a capacitor any more. I am not recommending staging, or sequencing, but rather hitting them all at the same time. Any attempt to mess with the program pin is doomed to failure in Virtex and Spartan II. As I have said, the chip doesn't even know its name yet at 0.7 to 1 V where the pop is needed. Any attempt to slow down the ramp is doomed to fail as well. The 4K parts had decreasing current with increasing ramp, and some dependency of current on the pins, but not Virtex/Spartan II. Ultimately, there may be a better way to solve the problem, as you state, as there are always alternatives. By the way, the board is almost built. Austin Rick Collins wrote: > I don't follow the thinking that a fully utilized FPGA requires a lot of > power. In an earlier thread I was told that the startup current is the > largest in the smallest Spartan II parts. An XC2S15 should not require a > lot of operating current in many applications. This is also a function > of clock speed. > > Not all designs require the highest clock speed and many have large > parts of the circuit that do not cycle on every clock edge. BTW, not > every design is systolic or serially calculable. Much of my current > designs take a serial data stream and perfrom DMA to/from memory. By > definition there is not much I can do to trade off logic for speed > either way. > > The board I am currently selling has a total power consumption of 3 > watts. Over half of that is in the DSP and memory, about .5 Watts are in > the IO section. This leaves less than a Watt in the four FPGAs on the > board for an average of 75 mA at 3.3 volts. The smaller parts are > utilized at about 80%. So where is the under utilization coming in? > > I don't see how requiring a 500 mA X 4 power supply is what I need on my > board. I really don't see how I need to add booster supplies or staging > switches to allow the FPGAs to boot in sequence. What I need is an FPGA > that does not require up to 2 Amps of startup current in the industrial > temperature range. > > Unfortunately every FPGA I have looked at has drawbacks. But then that > is what makes it engineering, right? Anyone can choose a solution that > is clearly better. It is harder to pick between two different tradeoffs. > > Ray Andraka wrote: > > > > IIRC, you can get around the monotonicity requirement by holding the program pin > > until the power is stable. > > As to the boot current, this should not be a problem if you are really using the > > FPGA to its potential, as > > the operating current for a well utilized FPGA is higher than the boot current > > (if it is not, then you can > > usually use serial or time multiplex techniques to get into a smaller part with > > a smaller boot current). > > > > Austin Lesea wrote: > > > > > > Rick, > > > > > > Call it what you will. > > > > > > It is intended to aid those that have less than the 500 mA available. > > > > > > Initially, we thought, "anyone using this IC will probably run it at a clock speed, > > > and with enough IO's that 500 mA will be required for its normal operation." > > > Obviously, there is a smaller contingent of users that do not use the fast clock > > > rates, or the large drive strengths, and need to get by with 200 or so mA. > > > > > > To help those users, we are working on the kick start circuit. > > > > > > As I said before, it is now being built, and we hope to have some results to report > > > by next week. > > > > > > The area we are talking about here is pretty tiny. Surface mount caps are required > > > anyway for good bypassing. The comparator is a tiny three leaded surface mount part > > > (2 X 2 mm?). Resistors are pretty tiny as well. I can't see them anymore (getting > > > old). > > > > > > The LDO will supply the voltage to the Vccint from the big capacitor, and at the > > > output of the LDO, the power will be rising monotonically. The 3.3 Vdc may droop > > > (that is why it is better if available to run the core voltage LDO off 5 Vdc), but > > > the droop is something one engineers (I=C dV/dt) to be small. > > > > > > The monotonicity "rule" is not a hard rule. We care about the voltage rising > > > through the POR trip point, and not falling back down after once passing through the > > > POR trip point. I believe this is stated in a number of tech notes/tech tips. It > > > may also be stated in the configuration section of the data sheet similar to how I > > > have stated it above. This is even to be relaxed at some point in the future Virtex > > > II as we designed it to not care about this point in the power on ramp. This is > > > something we will later test and verify as not being a problem. As well, Virtex II > > > power on is in the tens of mA range, so we do try to improve in every subsequent > > > generation. > > > > > > Austin > > > > > > Rick Collins wrote: > > > > > > > Austin, > > > > > > > > I don't mean to be rude, but is this circuit intended to be a "fix" to > > > > the power up issue? > > > > > > > > I can just as easily increase the surge capacity of my power converter > > > > than to add a secondary circuit to handle the few mS of startup current. > > > > The cost of this added startup circuit may be small, but it uses a lot > > > > of board space. By the time you account for the power requirement of the > > > > I grade, the board space of the chip has doubled. > > > > > > > > The other issue that I would raise with this circuit is the requirement > > > > that the voltage at startup be increased monotonically. If you depend on > > > > capacitors to provide current to the load, then the voltage will sag > > > > during that time. Perhaps the parts are not affected by a small voltage > > > > droop, hence the huge capacitor requirement. But doesn't the data sheet > > > > say that the voltage must increase monotonically? I can't find that now. > > > > Perhaps I saw it in an app note or the data sheet for the Virtex parts? > > > > Or am I mistaken about this? > > > > > > > > Austin Lesea wrote: > > > > > > > > > > Rick & Paul, > > > > > > > > > > Been out on vacation, so I missed this question. > > > > > > > > > > Spartan II is a Virtex derivative, so it has the same behavior during power up > > > > > as the Virtex family. Now this is about 2.5 years old, so it is a pretty well > > > > > known behavior. > > > > > > > > > > The ramp up time has a secondary effect on the amount of current required. > > > > > The shortest ramps require more current than the longer ramps, but as they get > > > > > close to 50 ms (the spec), the currents may start going back up again. > > > > > Current increases as temperature decreases. > > > > > > > > > > The current is required at about twice the Vt of the transistors (~0.7 to 1.0 > > > > > Vdc), and lasts perhaps as long as 200 us in the smaller parts of Spartan. > > > > > > > > > > We are now building the "kick start" circuit I had previously described. It > > > > > uses a 500 mA current limited LDO regulator with an enable pin. > > > > > > > > > > The enable pin comes from a micro power comparator /voltage reference ( we > > > > > abandoned the simple RC -- too unpredictable). > > > > > > > > > > When the input voltage (3.3 or 5 Vdc) passes a set threshold (set by two > > > > > resistors), the LDO is enabled. > > > > > > > > > > Ahead of the LDO is a ~1,000 uF 6.3 V cap that stores the necessary current to > > > > > start up the part. > > > > > > > > > > For four devices, this same technique can be extended to a larger cap, and a 2 > > > > > ampere LDO. > > > > > > > > > > The idea is quite simple: use the stored charge in the big cap to provide the > > > > > necessary kick to get all the parts started. For the I grade, at -40C, you > > > > > need 2 amps per part, and again, it is bigger capacitor, and larger regulators > > > > > (better is a low voltage switcher enabled by the comparator). > > > > > > > > > > The added cost is the mico power comparator / reference (less than 1$), two > > > > > resistors, and a big cap (<25 cents for a good aluminium electrolytic of large > > > > > value). (This assumes you have to provide a 2.5 V power supply regulator > > > > > anyway). > > > > > > > > > > In the meantime, the Spartan designers continue to optimize process / design / > > > > > test to improve the startup behavior. > > > > > > > > > > As soon as we have tested the kick starter with all process corner silicon, I > > > > > will publish it as a note. > > > > > > > > > > Again, I apologize for the delays, > > > > > > > > > > Austin > > > > > > > > -- > > > > > > > > Rick "rickman" Collins > > > > > > > > rick.collins@XYarius.com > > > > Ignore the reply address. To email me use the above address with the XY > > > > removed. > > > > > > > > Arius - A Signal Processing Solutions Company > > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > > 4 King Ave 301-682-7772 Voice > > > > Frederick, MD 21701-3110 301-682-7666 FAX > > > > -- > > -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 > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 29605
Rick Filipkiewicz wrote > > Question: What i/f has the PP got ? There are basically 3 ``levels'' of > IDE: > > (1) PIO: Programmed I/O i.e. the disk is just treated as a dumb ISA > peripheral & you read/write data via some polled/int driven s/w routine. > [NB the data port is 16 bits wide but all the other registers are 8]. > > (2) DMA: Old fashioned 80?? DMA. Single transfer at a time. > > (2a) MultiDMA: As above but you can do bursts as long as the DMA req's > active. > > (3) UDMA: A ``source synchronous'' abomination but it can get very high > data rates, UDMA66 up to 133MBytes/sec. Hard to design & get right since > the h/w protocol is both async wrt your system clock & tediously > complicated. > > For something like a PP I would not have thought you'd need to go beyond 2a > if that. Hello Rick Thanks for replying. In the specificfation data from the Hard disk is to be sent to the Palm Pilot via the Palm Pilot's RS-232 link. Therefore to reduce control overheads I am looking at developing some form of secondary processor to handle file input and retrieval from the hardrive, then sending the data up the RS 232, DanielArticle: 29606
Will wrote: > > > You can download free software from both Xilinx and Altera to design > > FPGAs in VHDL or Verilog. So why both learning CUPL? You don't need to > > be limimted by your software. > > CUPL is bad comparad to vhdl? CUPL was a buggy piece of crap last time I looked at it. --apArticle: 29607
Qian wrote: > > Hi I try to use GSR then I include > --LIBRARY ieee; > library IEEE; > library UNISIM; > use IEEE.STD_LOGIC_1164.all; > use IEEE.std_logic_unsigned.all; > use UNISIM.all; > > I use Xilinx Foundation and try to > check syntax, however it says > > "library logic name UNISIM cannot be mapped to a host directory" > > How to solve it ? > Thanks al ot! You solve it by not putting the library unisim stuff in your code. The synthesis tool will infer GSR automatically, if you follow the rule. The rule is: always make sure your reset net resets EVERY flop in your design. -aArticle: 29608
Seb C wrote: > > hi, > > i obtained this error message : > > ERROR:baste:314 - NCD was not produced. All logic was removed from design. > This > is usually due to having no input or output PAD connections in the design > and > no nets or symbols marked as 'SAVE'. You can either add PADs or 'SAVE' > attributes to the design, or run 'map -u' to disable logic trimming in > the > mapper. > > what means, NCD, PAD connections, because i used hierarchy connectors for > inputs and outputs and finally i don't understand this message, it's my > single error !! > > If somebody can help me, don't hesitate !! Do your schematics have IPADs and OPADs and such on the top level? -aArticle: 29609
Austin Lesea wrote: > > Andy, > > I will probably shock someone somewhere, but I agree with you. There are > some things that are so well entrenched, so ubiquitous, and/or so screwey to > implement (perhaps intentionally), that FPGA's are not even a realistic > consideration. The ASIC is just too cheap and easy not to use. Methinks it's a case of "if the only tool available is a hammer, everything starts to look like a nail." -andyArticle: 29610
Hi, We design cores which must be available both in VHDL and Verilog. So, I wrote a translator that supports a limited but useful subset of synthesisable VHDL. Although limited, this program correctly translated our Triple DES and JPEG cores. Since we have no commercial interest in such sw I decided to release it in the public domain under GPL. The program is not particularly well written (my first attempt to use YACC), but it does a decent job at translating RTL, better, in some cases, than some commercial programs I've seen. This was a warm up exercise for a VHDL and Verilog to C, cycle based compiler I have in mind. One day, maybe...... It is based on YACC/ C and it has been tested on Linux and Sun. I believe that porting to Win should be easy. You can fetch it at our download page: http://www.ocean-logic.com/downloads.htm Regards, Vincenzo Liguori --------------------------------------------------------------------------- Vincenzo Liguori Ocean Logic Pty Ltd PO BOX 768 Manly NSW 1655 Australia Ph : +61-2-99054152 Fax : +61-2-99050921 WWW : http://www.ocean-logic.comArticle: 29611
Hello! This may be a silly question... Why are CPLDs mostly FLASH based and FPGAs SRAM based? Is the FLASH technology too complex or expensive to use in FPGAs? I'm just curious... / JonasArticle: 29612
It's their heritage. When PALs were born, they were made with fuses, and thus were non-volatile. Nonvolatility has remained the religion through their evolution to CPLDs with EPROM, then EEPROM and finally Flash. Due to their structure, all CPLDs have considerable power consumption ( except CoolRunner ) and they are thus limited in complexity. So it all goes together: non-volatile, single-chip, high power, limited logic complexity and versatility. To hell with the complexity and expense of a unique process. SRAM-based FPGAs were born with high logic flexibility and complexity in mind, which dictates a standard CMOS-Logic process. Adding Flash to this process is considered heresy because it makes the process more complex, most likely slower, and is unnecessary if one emphasizes reconfiguration. Antifuses hang in-between, neither fowl nor fish. Sorry, was not meant as an insult. There are plenty of opportunities to shoot holes into individual arguments, but they are basically logical. Peter Alfke, Xilinx Applications Jonas Thor wrote: > Hello! > > This may be a silly question... Why are CPLDs mostly FLASH based and > FPGAs SRAM based? Is the FLASH technology too complex or expensive to > use in FPGAs? > > I'm just curious... > > / JonasArticle: 29613
Side note: uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns) not 133 MB/sec. -- Yury Rick Filipkiewicz wrote: > Bard_64 wrote: > > > Hello Everyone. > > > > I am currently doing backgroud reading on a project > > involving the > > interfacing of a Hard disk to a Palm Pilot. > > > > I was wondering could it be possible to access the IDE > > interface > > using an FPGA (specifically the X4003). > > > > Thanks > > > > Daniel > > Question: What i/f has the PP got ? There are basically 3 ``levels'' of > IDE: > > (1) PIO: Programmed I/O i.e. the disk is just treated as a dumb ISA > peripheral & you read/write data via some polled/int driven s/w routine. > [NB the data port is 16 bits wide but all the other registers are 8]. > > (2) DMA: Old fashioned 80?? DMA. Single transfer at a time. > > (2a) MultiDMA: As above but you can do bursts as long as the DMA req's > active. > > (3) UDMA: A ``source synchronous'' abomination but it can get very high > data rates, UDMA66 up to 133MBytes/sec. Hard to design & get right since > the h/w protocol is both async wrt your system clock & tediously > complicated. > > For something like a PP I would not have thought you'd need to go beyond 2a > if that.Article: 29614
Recently I completed a design interfacing Spartan XL (which is rather similar to 4000 family) to IDE interface implementing PIO-4 and uDMA66 protocols. Yes it is possible. -- Yury Bard_64 wrote: > Hello Everyone. > > I am currently doing backgroud reading on a project > involving the > interfacing of a Hard disk to a Palm Pilot. > > I was wondering could it be possible to access the IDE > interface > using an FPGA (specifically the X4003). > > Thanks > > DanielArticle: 29615
Jan wrote:
>
>I consider it such a privilege to have to build and maintain
> .S0 and .S1 versions of all my RPMs.
It looks like they've gone to an XY numbering scheme for Virtex2,
which eliminates the "name-that-slice" problem.
Also, in the event that you need to RLOC to a particular FFX/FFY
within a slice in plain-old-Virtex, the mystery "BEL" attribute is
now documented in the new 3.x library guide, updated ~late Nov.
>module dff16_s1(clk, ce, d, q) /* synthesis syn_hier="hard" */;
"Stupid FPGA Trick" of the day for Verilog users:
Make sure you put that semicolon AFTER the meta-comment, or
your attribute will be silently ignored by the synthesizer...
Ray wrote:
>
>As Jan mentioned, VHDL's generate statements permit parameterized
>construction of elements, something that is harder to do with verilog.
>I stand corrected on the availability of the user attributes in Verilog
>(it has been a while since I last investigated using Verilog).
I saw some Verilog-2000 slides a while ago; IIRC, it looks like
they've added some nice 'generate' type capabilities, but the
attributes are still done with the 'meta-comment' syntax, rather
than being a part of the language. As was pointed out in the other
replies, this makes it harder to do things like:
ram_gen: for i in 0 to 3 generate
attribute RLOC of RAMn : label is calc_rloc(i);
attribute INIT_00 of RAMn : label is calc_init(i,0);
attribute INIT_01 of RAMn : label is calc_init(i,1);
-- etc.
begin
d_we(i) <= ( NOT d_wr_l ) AND ( NOT d_wr_en_l(i));
RAMn : RAMB4_S4_S8
port map
(
DOA => i_dat( (4*i)+3 downto 4*i ),
-- etc.
VHDL RPM's
BTW, a while back (~Oct '99), I posted a link to some example
VHDL RPM code that worked with M1.5 and Synplicity 5.X :
ftp://members.aol.com/fpgastuff/tc_test1.zip
This XC4000 carry chain example code (with nested RLOC's) worked
fine (shows up as a single RPM) with M1.5, almost fine with M2.1,
but gives the M3.x mapper complete indigestion; however, it
should still be useful as a reference.
( I suspect the RPM 'detection' rules have changed in the 3.x mapper,
at least for the older XC4000 families )
That example code was inspired by Evan's webpage at :
http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm
( I'd post a deja archive link to the relevant threads, but the
deja archive seems to have vanished for now. )
Brian Davis
Article: 29616Hi, I think the good answer is to "hide" this library for synthesis : library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; -- synopsys translate_off library unisim; use unisim.vcomponents.all; -- synopsys translate_on And it works fine ! For GSR, you can use the ROC component for simulation... "Qian" <junciu@yahoo.com> a écrit dans le message news: ee6fc84.-1@WebX.sUN8CHnE... > Hi I try to use GSR then I include > --LIBRARY ieee; > library IEEE; > library UNISIM; > use IEEE.STD_LOGIC_1164.all; > use IEEE.std_logic_unsigned.all; > use UNISIM.all; > > I use Xilinx Foundation and try to > check syntax, however it says > > "library logic name UNISIM cannot be mapped to a host directory" > > How to solve it ? > Thanks al ot!Article: 29617
Hi, I think the good answer is to "hide" this library for synthesis : library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; -- synopsys translate_off library unisim; use unisim.vcomponents.all; -- synopsys translate_on And it works fine ! For GSR, you can use the ROC component for simulation... "Qian" <junciu@yahoo.com> a écrit dans le message news: ee6fc84.-1@WebX.sUN8CHnE... > Hi I try to use GSR then I include > --LIBRARY ieee; > library IEEE; > library UNISIM; > use IEEE.STD_LOGIC_1164.all; > use IEEE.std_logic_unsigned.all; > use UNISIM.all; > > I use Xilinx Foundation and try to > check syntax, however it says > > "library logic name UNISIM cannot be mapped to a host directory" > > How to solve it ? > Thanks al ot!Article: 29618
Hi,
I am planning to use the SDRAM controller from xilinx's application note
XAPP134. This question is very specific to the documentation of that
application note !
Figure 5 and 6 show timing diagrams of read and write cycles to the
SDRAM controller. When can I start the next access cycle with that
controller ? At what time can I write the next addr_wr command ? Do I
have to wait until T16 or T17 ? Or is the design strongly pipelined ?
Same question for the read timing !
I need this information to calculate the maximun constant datarate by a
given sdram clk with this sdram controller. My requirements are: 1 data
every 26ns (better 20ns).
Matthias
--
-------------------------------------------------
\ Matthias Fuchs \
\ esd electronic system design Gmbh \
\ Vahrenwalder Straße 205 \
\ D-30165 Hannover \
\ email: matthias.fuchs@esd-electronics.com \
\ phone: +49-511-37298-0 \
\ fax: +49-511-37298-68 \
--------------------------------------------------
Article: 29619Our client is the leading provider of highly integrated silicon solutions that enable broadband digital transmission of voice, video, and data. Using proprietary technologies and advanced design methodologies, the company designs, develops and supplies integrated circuits for a number of the most significant broadband communications markets, including the markets for cable set-top boxes, cable modems, high-speed local, metropolitan and wide area networks, home networking, Voice over Internet Protocol (VoIP), residential broadband gateways, direct broadcast satellite and terrestrial digital broadcast, optical networking, digital subscriber lines (xDSL) and wireless communications. They are currently seeking ASIC Designers with the following... Required Skills and Experiences: BSEE or equivalent; MSEE preferred, plus 5+ years' of VLSI hardware design experience. Position requires working knowledge of Verilog and Synopsys. Experience with back-end CAE, layout tools, 3D, video, and DSP is a plus. Responsibilities: Responsibilities include: definitions of the molecules specifications based on the system specification; RTL development and debugging, test bench development; design validation as part of an overall system, system integration; synthesis of the RTL at a certain clock speed; Implementation of the test strategy, scan insertion, ATPG test vectors generation. PROCOM: Established in 1978, Professional Computer Consultants Group Ltd. (Procom) is a national leader in the provision of Computer personnel on a contract and full-time basis. Our clients are comprised of the largest national and international corporations that utilize technical resources extensively across a wide range of disciplines. In the Financial Post (March 1999) Procom was ranked as the 6th largest professional Services Company in Canada. In November of 1999, Procom was named a Regional finalist in Canada' s 50 Best Managed Private companies. Our track record is proven with more than 180 consultants servicing Ottawa's high tech community and more than 1600 Procom consultants currently on assignment throughout. North America. For further information on this and other opportunities please visit our web site at www.procom.ca. Interested candidates are invited to forward their resumes or questions in confidence to: Derek Weber PROCOM 300 March Rd Suite 600 Kanata, Ontario K2K-2E2 613-270-9339 x231 613-270-9449 (FAX) derekw@procom.ca www.procom.caArticle: 29620
After some practice with PQ208's, you will find that PQ240's can be tackled just as effectively too. Fred Chu -- Posted from porter.avnet.com [12.9.139.170] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 29621
David C. Hoffmeister schrieb: > > I am currently designing a board with a Virtex and a Virtex-E > device. I am hoping to use 200 MHz ZBT SRAM. The Xilinx app note uses > two DLLs, one to deskew the external clock and one to deskew the > internal clock. My question is, does anyone have any experience using > these DLLs with clocks near this frequency? Specifically, I am afraid > that if I use one pair of DLLs to do this and then use the generated > clocks in multiple portions of the chip, I am not sure how well the > clock is deskewed across the entire chip. For instance, all of the AFAIK the skew on the dedicated clock nets is <1ns. No need for additional deskew?! At least there are many DLLs inside the Virtex-E. -- MFG FalkArticle: 29622
This is a multi-part message in MIME format. --------------380478FF6FD1990AA7B6B7AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everyone! What's the difference in the speed-grade between devices? I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which speed grade should I use? -4, -5, -6. Thanks all -Juan --------------380478FF6FD1990AA7B6B7AA Content-Type: text/x-vcard; charset=us-ascii; name="jmrivas.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Juan M. Rivas Content-Disposition: attachment; filename="jmrivas.vcf" begin:vcard n:Rivas;Juan M. tel;home:(617)255-1268 tel;work:(617) 253-5097 x-mozilla-html:FALSE org:Media Lab, M.I.T.;Object Based Media version:2.1 email;internet:jmrivas@media.mit.edu title:Research Assistant adr;quoted-printable:;;20 Ames Street=0D=0A;Cambridge;Massachusetts;02139;U.S.A. fn:Juan M. Rivas end:vcard --------------380478FF6FD1990AA7B6B7AA--Article: 29623
You might want to use the slowest (cheapest) speed grade ( lowest number ) that achieves your performance. But you cannot describe the speed requirements of a complete design with just one number. Pick one speed grade, analyze the performance and look how well it matches your expectations and demands. Then you can easily analyze it for a different speed grade. Every parameter in a faster speed grade is faster, but not all by the same percentage. BTW, I would guess that the slowest available speed grade meets your requirements. And don't forget, if you run into a speed bottleneck, pipelining can often save the day, and it is (almost) free. Peter Alfke, Xilinx Applications "Juan M. Rivas" wrote: > Hi everyone! > > What's the difference in the speed-grade between devices? > > I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which > speed grade should I use? -4, -5, -6. > > Thanks all > > -JuanArticle: 29624
> David C. Hoffmeister schrieb: > > > > I am not sure how well the > > clock is deskewed across the entire chip. > Very well, thank you. You actually get a timing report that takes into account clock routing and loading, and their deltas. The worst-case skew is well below one nanosecond. In Virtex-II with its even more buffered structure, it is below 200 ps. Across the chip ! Almost unbelievable, but true. Falk, are you coming to our seminar, next Thursday (8th) in München, Friday in Frankfurt ? I'll give the 3-hour Virtex-II presentation. In German... 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