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
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:NKqdnUIskK8lO3HYnZ2dneKdnZydnZ2d@giganews.com... > > "Symon" <symon_brewer@hotmail.com> wrote >> >> Check out :- >> http://www.teraspeed.com/publications.html >> Where they ask you to register for :- >> http://www.teraspeed.com/papers/cap_considerations_fpga_pds.pdf >> > > BTW what about the LLM21 from Murata? 45pH for 4.7µF and not very > expensive... > > http://www.murata.com/articles/ta0581.pdf > http://www.murata.com/catalog/c02e.pdf (page 66) > > OK they are bigger (0805) than X2Y (0603) but 4.7µF seems interesting. > > Marc > Hi Marc, The article above explains why the physical geometry of X2Y is superior to the reverse geometry part you mention. It's all to do with circles that have arrows on them! :-) The reverse geometry parts are good, but make sure the vias are at the ends of the part. (pg.17) Also, be careful of worring about capacitance rather than inductance. Here's an example:- Let's say we have a 100 MHz clocked system where stuff only happens on the rising edge. We'll say our dynamic current (the current used when switching) is 1A. OK, so on each switch of the clock the circuit uses 1A / 100MHz = 10nC. Q=CV, so the ripple this causes on your 4.7U capacitor is about 2mV. Very good. OK, let's say the circuit being run has a 2ns rise time. So, let's say on each switch, for 1ns the current is increasing, and for the next ns it's decreasing. Let's say (for ease of calculation) the current rises and falls linearly at equal rates so the current vs. time graph is an isosceles triangle with a base of 2ns. The area under this triangle represents our 10nC from above. So, the triangle is 10 amps high! Now, V = L dI/dt , dI/dt = 10A / 1 ns = 10 GA/s (!!) and, even ignoring the via and mounting inductance but using your figure of 45pH for the inductor, the ripple voltage due to the capacitor inductance, V = 0.45V. So, the noise from the inductance is about 200 times the noise from the capacitor discharging! You can see that buying cheaper capacitors with less capacititance isn't going to change things very much. (Except the change in your pocket! Ho, ho!) However, fitting two caps will almost halve the problem. HTH, Syms. p.s. I realise this is a simplistic model, but I hope it illustrates the point. And please correct my arithmetic if needed!Article: 116276
<sweir@x2y.com> wrote in message news:1173137413.433634.222140@n33g2000cwc.googlegroups.com... > In the PS3 > application, those mighty ASICs have a lot of bypass under the lid. >>From a system design perspective this is cheaper than trying to make > the PCB do all the work. The PCB just becomes a low frequency power > distribution network. Since Sony isn't asking the PCB to distribute > high frequency, using the Proadlizers to isolate noise is an effective > way to limit EMI propagation. That allows meeting FCC with thicker > dielectric in the power planes of the PCB. > > Regards, > > Steve. > Hi Steve, Firstly, thanks for your post. I lurk on the SI-list (posting is a pain with all those 'out-of-office' replies) which is how I found your stuff on X2Y. The paragraph of yours I've quoted above explains to me what's going on inside a PS3. For a while I was worrying that I'd missed a big trick with my FPGA board designs. If FPGA manufacturers follow this lead of putting even more bypassing on the BGA carrier, and I guess that soon they will have no choice, then the PCB power distribution requirements will become a little less rigorous. Thanks again, Symon.Article: 116277
"comp.arch.fpga" <ksulimma@googlemail.com> wrote in message news:1173170182.291768.316990@8g2000cwh.googlegroups.com... > On Mar 6, 1:25 am, "Weng Tianxiang" <wtx...@gmail.com> wrote: >> 1. Latch is rarily used throughout all VHDL, > That is not true. > While latches are not supported in most modern FPGAs and where > discouraged to use in older families, > in ASIC design it is very common to split D-Flip-Flops into two > latches distributed through > the pipeline. Kolja, good point. To follow up on this point a bit for the other readers. The reason that latches are discouraged FPGA/CPLDs but not so in ASICs is because in the ASIC world they actually have a hard set of logic that gets inferred from the code that generates a latch whereas in the typical FPGA/CPLD world you do not. Instead the latch gets created by cobbling together the LUTs or macrocells. The problem with the cobbling together approach is that you have virtually no control over the timing inside the FPGA/CPLD and yet a latch will have setup and hold timing requirements that you will have no way to guarantee. If FPGA/CPLDs cobbled together LUTs to create flip flops the same argument could be made for not using flip flops. But since FPGA/CPLD/ASICs all have flip flops implemented as hard logic you don't have this issue. Also, if the target device does have a hard latch as a resource that can be used then the use of latches is just fine also. Kevin JenningsArticle: 116278
Hi, I've just installed a brand new machine running Gentoo AMD64 with a 64 bits kernel and a 'multilib' userland. (That is, I have some emulation libraries for 32b apps). Here's my experience at installing ISE. I just want to say before hand that even if that's currently far from perfect, the installation of Xilinx product under linux 32/64 has gotten _MUCH_ better and is still improving In my work, I need ISE 8.2, EDK 8.2 and ISE 9.1 all at the same time. Hopefully, with the 'settings.sh' mechanism of Xilinx installs, switching between version is really easy so no real problems there. * First I installed the ISE 9.1. The install went pretty smooth. I just had to install the 32b emulation libraries which sounded weird but I though maybe it's just the installer that's 32b. However I was wrong and after the install, I realized that I had in fact installed the 32b version ... Apparently, the xilinx script uses `uname -p` and then match to "x86_64", unfortunatly I have a Core 2 CPU so it didn't match. After changing the script, I retry. Little problem, my registration ID is no longer accepted (even though it's the same one as the one I used for the 32b install) ... So I try the other registration ID (one without the simulator) and then it works. The service packs needed the same 'fix' for the install script but once you know about it, it's easy. Finally, not too hard ... * Second, ISE 8.2 & EDK 8.2 There I directly check to see how it detects 32b from 64b and depending on what you install (the base DVD, or the SP or the IP updates), the methods is different ... so need to be careful there as well. Once ISE was fully installed (that's the base DVD install, the service pack, the V5 LX patch, the V5 LXT support add on, the IP update and the IP update add on, quite long sequence !), I start EDK. First I notice there is just no 64 bit version of EDK so ... I fall back and install the 32b version. Unfortunatly the EDK32b _wants_ ISE32b ... So I reinstall ISE32b in another directory (again ... the whole sequence !). Once installed, I then compare both ISE64b and ISE32b to see the difference and I end up copying all files that are in my 32b install and not in the 64b to the 64b install dir. There is apparently no "conflict" (i.e. the 'data' files are the same for 32b and 64b, only the executables and libraries are different and they're in different directory). Then I just rename setting.sh and make a settings_32b.sh and a settings_64b.sh and .. voila ... both version install and both seems to work. What's the point ? Well ... I just wanted to test the 64b version ;p But when I need to use EDK I need the 32b as well so that merged directory allows me to have both without duplicating everything. Now that's done, I'll try the cable driver (both chipscope and impact) ... that's gonna be funny, I feel it ;p Anyway, I certainly hope that EDK 9.1 will come in a lin64 flavour as well so I can drop the 32b install as well as all the 32b libraries I keep on my system "just for ISE" ;p SylvainArticle: 116279
"Symon" <symon_brewer@hotmail.com> wrote > "Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message >> >> "Symon" <symon_brewer@hotmail.com> wrote >>> >>> Check out :- >>> http://www.teraspeed.com/publications.html >>> Where they ask you to register for :- >>> http://www.teraspeed.com/papers/cap_considerations_fpga_pds.pdf >>> >> >> BTW what about the LLM21 from Murata? 45pH for 4.7µF and not very >> expensive... >> >> http://www.murata.com/articles/ta0581.pdf >> http://www.murata.com/catalog/c02e.pdf (page 66) >> >> OK they are bigger (0805) than X2Y (0603) but 4.7µF seems interesting. >> >> Marc >> > Hi Marc, > The article above explains why the physical geometry of X2Y is superior to > the reverse geometry part you mention. It's all to do with circles that > have arrows on them! :-) The reverse geometry parts are good, but make > sure the vias are at the ends of the part. (pg.17) I was not showing reverse geometry parts but IDC ones. They have 10 pins instead on the usual 8 and the inductance is 2 times lower than 8 pins IDC caps. In the paper you mention, they are page 17 except that these ones use 10 instead of 8 vias. As in page 25 it is said that they 8 pins IDC are equivalent to X2Y and as 10 pins IDC are 2 times better that 8 pins ones, it seems that the 10 pins IDC should be 2 times better than X2Y. Another links with lots of infos and measurements: http://home.att.net/~istvan.novak/papers/DC05_TF7.pdf http://home.att.net/~istvan.novak/papers/DC05East_TFMP2_v1.pdf The first one even has a proadlizer test showing it not that good in decoupling mode. > Also, be careful of worring about capacitance rather than inductance. > Here's an example:- > > Let's say we have a 100 MHz clocked system where stuff only happens on the > rising edge. We'll say our dynamic current (the current used when > switching) is 1A. OK, so on each switch of the clock the circuit uses 1A / > 100MHz = 10nC. Q=CV, so the ripple this causes on your 4.7U capacitor is > about 2mV. Very good. > OK, let's say the circuit being run has a 2ns rise time. So, let's say on > each switch, for 1ns the current is increasing, and for the next ns it's > decreasing. Let's say (for ease of calculation) the current rises and > falls linearly at equal rates so the current vs. time graph is an > isosceles triangle with a base of 2ns. The area under this triangle > represents our 10nC from above. So, the triangle is 10 amps high! Now, V = > L dI/dt , dI/dt = 10A / 1 ns = 10 GA/s (!!) and, even ignoring the via and > mounting inductance but using your figure of 45pH for the inductor, the > ripple voltage due to the capacitor inductance, V = 0.45V. Good point and scary numbers ;-). In fact past the cap resonance, you only see the ESL. But this also means that a bigger chip is as good as a smaller one for decoupling in the high frequencies region and much better in the lower ones so you can put a smaller number of bigger ones. Here are some X2Y measurements showing this: http://www.yageo.com/products/presentations/X2Y%20measurement%202006.pdf The question is which part has the lowest inductance. IMO it's the 10 vias ones. > So, the noise from the inductance is about 200 times the noise from the > capacitor discharging! You can see that buying cheaper capacitors with > less capacititance isn't going to change things very much. (Except the > change in your pocket! Ho, ho!) However, fitting two caps will almost > halve the problem. Anyway my pockets are already empty after paying for some big FPGAs and QDR memories. ;-) > HTH, Syms. > p.s. I realise this is a simplistic model, but I hope it illustrates the > point. And please correct my arithmetic if needed! Seems good for me. MarcArticle: 116280
<sweir@x2y.com> wrote > All, Austin's description of the NEC Proadlizer is fairly accurate. > It is a transmission line filter. The really wilde S21 insertion loss > curves occur when the device interrupts both Vcc and Vss ( gnd ). But > it is still quite impressive interrupting just Vcc. When we decouple > power to a device or a node, we are concerned with two issues: S21 > insertion loss which measures the ability of a device to isolate > noise, and Z22 which is the impedance that the filter presents to the > load. While Proadlizers with plane slits are killer at S21, they are > quite pedestrian at Z22 exhibiting about 200pH mounted with a ton of > vias. If you were to try and use these for Virtex 4 or 5 in the 672 > pin or smaller packages, or Altera parts prior to Stratix III that do > not have internal bypass caps on an I/O rail you would set yourself up > for a world of hurt. Using a Proadlizer with larger V4 or V5 or > Altera Stratix III where the chips do have substantial bypass caps in > the package can work to isolate the local bypass from the plane. > > Why do we want to bypass large devices from the planes? Because by > doing so PROPERLY, we can: reduce EMI propagation to the board edges, > raise the SRF of the power cavity to put it well above the cross-over > frequency of power distribution low pass in the package, and isolate > big hungry parts from smaller parts and each other. In the PS3 > application, those mighty ASICs have a lot of bypass under the lid. >>From a system design perspective this is cheaper than trying to make > the PCB do all the work. The PCB just becomes a low frequency power > distribution network. Since Sony isn't asking the PCB to distribute > high frequency, using the Proadlizers to isolate noise is an effective > way to limit EMI propagation. That allows meeting FCC with thicker > dielectric in the power planes of the PCB. > > The last I checked, Proadlizers were in the dollars range / part. But > the capacitor industry is very competitive and this may have improved. > > X2Y's ( I consult for X2Y ) can also be used to effect high frequency > isolation by feeding Vcc through the G1/G2 connection and grounding > the A and B connections. We have seen EMI improvements of 50dB with > carefully designed etch and a pair of 1206 size X2Ys. > > On the load side of things ( your chip ) you need to pay attention to > the local impedance versus frequency, Z22. Problems occur if the > impedance is too high. At audio frequencies this is usually a > resonance problem between the voltage regulator and the bulk bypass > network. Above 1MHz it is either from too much inductance and/or a > resonance. Interesting. Here is a proadlizer test showing this on pages 16-17: http://home.att.net/~istvan.novak/papers/DC05_TF7.pdf It looks like the proadlizer is not that good in decoupling mode though 200pH is still pretty good for 1200µF and that a few low ESL caps are probably needed anyway. MarcArticle: 116281
Symon wrote: > ...............If FPGA manufacturers follow this lead of putting even > more bypassing on the BGA carrier, and I guess that soon they will have no > choice, then the PCB power distribution requirements will become a little > less rigorous. Which cap geometries are used for in-package decoupling?Article: 116282
wojt wrote: > Hi guys > > I'm trying to synthesize processor core with ROM and RAM in the > VirtexE FPGA. > > I've created RAM memory using VirtexE Block RAM resources by means of > 'Single-Port Block Memory Core Generator' in Xilinx ISE. > > My problem is that VirtexE memory supports only 'Read-after-Write' > mode. In this mode, what has been written to the memory is transferred > on the active clock edge to the output port of the memory immediately > after assertion of 'Write Enable' input. > > I need to interface this memory to the processor which accepts all > values coming from the RAM, therefore 'No-Read-on-Write' mode, where > input data are not transferred to the output of the memory after > successful write, should be used. > > 'Read-after-Write' causes invalid values to be transferred to the > processor after each write to the RAM. > > Does anyone know how to overcome this problem? > > Thanks! > Wojt Rearrange the transfer to the processor. Even in the "NO_CHANGE" write mode in the more recent FPGAs, there's SOMETHING on the BlockRAM output. It may be last cycle's data but it's only the data, no address to accompany it. How can having a data word for an unused cycle showing up on the BlockRAM output be a problem in your system? To mimic the NO_CHANGE format, you can always use latches; the latches are clear during reads but maintain the previous value during writes. I still don't see how this "do nothing" state will help you in your quest.Article: 116283
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:V7-dnTN5P_L59HDYRVnygwA@giganews.com... > > > I was not showing reverse geometry parts but IDC ones. They have 10 pins > instead on the usual 8 and the inductance is 2 times lower than 8 pins IDC > caps. In the paper you mention, they are page 17 except that these ones > use 10 instead of 8 vias. As in page 25 it is said that they 8 pins IDC > are equivalent to X2Y and as 10 pins IDC are 2 times better that 8 pins > ones, it seems that the 10 pins IDC should be 2 times better than X2Y. > > Another links with lots of infos and measurements: > http://home.att.net/~istvan.novak/papers/DC05_TF7.pdf > http://home.att.net/~istvan.novak/papers/DC05East_TFMP2_v1.pdf > > The first one even has a proadlizer test showing it not that good in > decoupling mode. > Right, seems logical! Apologies, I misread the Murata part number and came to the reverse geometry ones first. Doh! So, yes, those interdigitated ones are pretty damn good too. Of course, you can fit more small parts in the same space as some big ones, so there's a trade off somewhere. Two parallel caps have about half the inductance of one big one. The papers are interesting too, thanks. Looks like the proadlizer is good for some things, but bypassing parts without on-board capacitance is not one of those things, as Mr. Weir said in his post. > > In fact past the cap resonance, you only see the ESL. But this also means > that a bigger chip is as good as a smaller one for decoupling in the high > frequencies region and much better in the lower ones so you can put a > smaller number of bigger ones. > OK, but again bearing in mind you can fit more small ones into the same space to reduce inductance. > > Here are some X2Y measurements showing this: > http://www.yageo.com/products/presentations/X2Y%20measurement%202006.pdf > > > The question is which part has the lowest inductance. IMO it's the 10 vias > ones. > Yep, they're a good solution also. Thanks for some interesting postings! Cheers, Syms.Article: 116284
[snipped discussion about bypass caps...] Looks like some don't put much caps: http://www.drccomputer.com/pdfs/DRC_RPU110_datasheet.pdf There are a few of them on the back of the FPGA. Maybe they rely on a high capacitance plane and on the PC motherboard bypassing... MarcArticle: 116285
"Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:bbCdnU87CsnHGHDYRVnytQA@giganews.com... > [snipped discussion about bypass caps...] > > Looks like some don't put much caps: > http://www.drccomputer.com/pdfs/DRC_RPU110_datasheet.pdf > > There are a few of them on the back of the FPGA. Maybe they rely on a high > capacitance plane and on the PC motherboard bypassing... > > Marc > > From Steve's post in the other thread it sounds like bigger V4's have significant bypass caps in the package. I guess we'll find out more after those guys out on the West Coast get a morning coffee. :-) From your link, what are those big brown things on the backside? Cheers, Syms.Article: 116286
"Patrick Dubois" <prdubois@gmail.com> writes: > Just to come back on the subject of Scons for a minute... Any input on > that tool? It does look neat, but will require some work to make it do what we want I imagine... It also seems to be solving a more difficult problem that FPGA building, which seems (to me) to be a fairly linear series of events where the only dependency is on the previous process. > Or does anyone have another suggestion for a make > alternative? > Why do you dislike make? Personally, I just use a series of batch files... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 116287
Weng Tianxiang schrieb: > I am very confused with latch generation in VHDL. > > 1. I have been using VHDL for 7 years and I have never met a situation > I need a latch. I do it every day. Latches are only half as big as flipflops and are not triggered by a highly active clock. They only need their enable signal. This makes them then 1st choice for small low-power circuits. Using latches means thinking very well about the behavior of the circuit. Hazards, the common muxed-latch-problem and other stuff has to be considered. > 2. I want to know why VHDL let VHDL programmers guess what is to be > generated in the following situation that I know is only case a latch > may be generated: > > process(a, ...) > begin > -- signalA <= '0'; > case state is > when A_S => > if(a = "000001") then > signalA <= '1'; <--- a latch is generated, why not > generating an error ? > state_ns <= B_S; > else > state_ns <= A_S; > end if; > > ... > end process; signalA is not assigned in the else-branch. Therefore you get a latch, because this process is not clocked. This is a bad way to code a latch (because you easily trap into the muxed-latch pitfall) but why this should be an error? All synthesis tools will report that signalA has inferred a latch. > Because the first line " Latch_A <= '0'; " is easily missed when the > process content is big, signalA is generated by VHDL definition as a > latch. If for the 1st line after the begin the comment "--" is removed you will get combinational logic for signalA. This is _totally_ different behavior, but if you want to avoid a latch a very clean and easy way to do it. RalfArticle: 116288
Pablo, Open a webcase. We supply old versions to customers so they may maintain their older designs. Austin Pablo wrote: > Hello, does anybody know how can I get xilinx ise 6.3i? I have > installed ise v8.1i, but know in my organization I need to install ise > v6.3i. > > Thanks >Article: 116289
Hello, all:
When I did the implementation of my design, the map process gave me
the following error:
---------------------------------------------------------------------------------------------------------
ERROR:PhysDesignRules:1577 - Illegal routing. The DCM_ADV block
<....../dcm3_inst/DCM_ADV_INST> has CLK output pin <CLK0> with
incomplete or incorrect connectivity. Routing from the <CLK0> pin
to a BUFG,
BUFGCTRL or PLL_ADV block type was not found. The DCM_ADV CLK
output pins can
only route to BUFG, BUFGCTRL or PLL_ADV block types.
----------------------------------------------------------------------------------------------------
But I do have the CLK0 port connected with a global buffer :
CLK0_BUFG_INST as shown in the following code.
Can somebody tell me what's wrong here? I have spent a lot of time on
it but still no clue.
Thank you very mucy,
Rebecca
library ieee;
use ieee.std_logic_1164.ALL;
use ieee.numeric_std.ALL;
library UNISIM;
use UNISIM.Vcomponents.ALL;
entity dcm3 is
port ( CLKIN_IN : in std_logic;
RST_IN : in std_logic;
CLKFX_OUT : out std_logic;
CLK0_OUT : out std_logic;
LOCKED_OUT : out std_logic);
end dcm3;
architecture BEHAVIORAL of dcm3 is
signal CLKFB_IN : std_logic;
signal CLK0_BUF, CLKFX_BUF, Locked_out_buf : std_logic;
signal GND1 : std_logic_vector (6 downto 0);
signal GND2 : std_logic_vector (15 downto 0);
signal GND3 : std_logic;
begin
GND1(6 downto 0) <= "0000000";
GND2(15 downto 0) <= "0000000000000000";
GND3 <= '0';
CLK0_OUT <= CLKFB_IN;
CLKFX_BUFG_INST : BUFG
port map (I=>CLKFX_BUF,
O=>CLKFX_OUT);
CLK0_BUFG_INST : BUFG
port map (I=>CLK0_BUF,
O=>CLKFB_IN);
Locked_BUFG_INST : BUFG
port map (I=>LOCKED_OUT_Buf,
O=>LOCKED_OUT);
DCM_ADV_INST : DCM_ADV
generic map( CLK_FEEDBACK => "1X",
CLKDV_DIVIDE => 2.0,
CLKFX_DIVIDE => 5,
CLKFX_MULTIPLY => 3,
CLKIN_DIVIDE_BY_2 => FALSE,
CLKIN_PERIOD => 10.0,
CLKOUT_PHASE_SHIFT => "NONE",
DCM_AUTOCALIBRATION => TRUE,
DCM_PERFORMANCE_MODE => "MAX_SPEED",
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "HIGH",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
FACTORY_JF => x"F0F0",
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE)
port map (CLKFB=>CLKFB_IN,
CLKIN=>CLKIN_IN,
DADDR(6 downto 0)=>GND1(6 downto 0),
DCLK=>GND3,
DEN=>GND3,
DI(15 downto 0)=>GND2(15 downto 0),
DWE=>GND3,
PSCLK=>GND3,
PSEN=>GND3,
PSINCDEC=>GND3,
RST=>'0',
CLKDV=>open,
CLKFX=>CLKFX_BUF,
CLKFX180=>open,
CLK0=>CLK0_BUF,
CLK2X=>open,
CLK2X180=>open,
CLK90=>open,
CLK180=>open,
CLK270=>open,
DO=>open,
DRDY=>open,
LOCKED=>LOCKED_OUT_Buf,
PSDONE=>open);
end BEHAVIORAL;
Article: 116290"Tim" <tim@nooospam.roockyloogic.com> wrote: > Symon wrote: > >> ...............If FPGA manufacturers follow this lead of putting even >> more bypassing on the BGA carrier, and I guess that soon they will have >> no choice, then the PCB power distribution requirements will become a >> little less rigorous. > > Which cap geometries are used for in-package decoupling? According to the following paper (see page 34), they use (used?) 8 pins IDC caps: http://home.att.net/~istvan.novak/papers/DC05East_TFMP2_v1.pdf X2Y and 10 pins IDC caps are much better now so maybe they changed. Marc From invalid@dont.spam Tue Mar 06 08:58:10 2007 Path: newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newsfeed.telusplanet.net!newsfeed2.telusplanet.net!newsfeed.telus.net!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny06.POSTED!933f7776!not-for-mail From: Phil Hays <invalid@dont.spam> Subject: Re: Multiple devices within one ISE project User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.03.06.17.03.57.541537@dont.spam> Newsgroups: comp.arch.fpga References: <MP_Gh.5224$M65.4707@newssvr21.news.prodigy.net> <1173167297.217304.47530@c51g2000cwc.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 63 Date: Tue, 06 Mar 2007 16:58:10 GMT NNTP-Posting-Host: 71.112.133.239 X-Complaints-To: abuse@verizon.net X-Trace: trndny06 1173200290 71.112.133.239 (Tue, 06 Mar 2007 11:58:10 EST) NNTP-Posting-Date: Tue, 06 Mar 2007 11:58:10 EST Xref: prodigy.net comp.arch.fpga:127855 Andy Peters wrote: > On Mar 5, 1:11 pm, "Jean Nicolle" <jean.nico...@sbcglobal.net> wrote: >> Is it possible to use an ISE project to compile for multiple devices? >> >> I happen to have a project that can target two different boards with >> different FPGAs. Most of the files are the same, besides the UCF. Do I >> have to create separate ISE projects? I'd rather have one project with >> different variations. But that doesn't seem supported. Anybody can set >> me wrong? > > Use a Makefile. A makefile for this build can be a fairly good answer with dual core computers becoming more common, as the two map and par jobs can be run in parallel. Write a makefile and use: make --jobs=2 Make is a cool utility. Can be loaded with the Cygwin package on Windows, and is native on Linux. For more information on make: http://www.gnu.org/software/make/ Using make doesn't prevent one from using a Tcl script(s) for the actual builds as Jim suggested. If this was done the makefile might have just two items (it might have more as well): ../bld1/board1.bit : *.vhd *.v board1.ucf build.tcl <tab> xtclsh build.tcl board1 ../bld2/board2.bit : *.vhd *.v board2.ucf build.tcl <tab> xtclsh build.tcl board2 Some explanation of this makefile: 1) The first line of each item is "the target" : "the sources". Make checks to see that the target is newer than the sources. If not newer or if the target does not exist, then make executes the commands on following lines starting with tab characters. 2) " <tab> " is the tab character. Required by make before every command. 3) xtclsh is the Xilinx Tcl shell, used to execute the script. ISE8.2 or later. 4) build.tcl is the script that builds the designs. This script is expecting a parameter to define which board to target. Tcl is not as trivial to multithread as make is. On the other hand, Tcl is a general purpose language, so it can be used for lots of other tasks that make can't do, such as creating revision or timestamp values to be loaded into registers, parsing report files, multiple .ucf files in a design, etc. For more information on Tcl see: http://www.tcl.tk/about/features.html Or the Tcl section in the Xilinx manual. -- Phil Hays (Xilinx, but writing my own words)Article: 116291
On Mar 5, 6:47 pm, Jim Lewis <j...@synthworks.com> wrote: > Weng, > First, 1076.6-2004 introduces an attribute named combinational. > For a compliant tool, when this attribute is applied to a > process label and the process creates a latch then a synthesis > tool shall generate an error. > > So request that your vendor implement the standard (if > they have not already). Vendors will implement what their > user community wants. If you want this, you must make sure > you talk to your vendor. > > > > > > > 2. I want to know why VHDL let VHDL programmers guess what is to be > > generated in the following situation that I know is only case a latch > > may be generated: > > > process(a, ...) > > begin > > -- signalA <= '0'; > > case state is > > when A_S => > > if(a = "000001") then > > signalA <= '1'; <--- a latch is generated, why not > > generating an error ? > > state_ns <= B_S; > > else > > state_ns <= A_S; > > end if; > > > ... > > end process; > > > Because the first line " Latch_A <= '0'; " is easily missed when the > > process content is big, signalA is generated by VHDL definition as a > > latch. > > OTOH, one simple rule for preventing latches: > * Initialize all outputs (except state_ns) to their > inactive value. > * Either fully specify state_ns or assign it to state_reg. > > Or you can follow KJ's rule of always using clocked > processes, however, this is not my preference. > > Cheers, > Jim- Hide quoted text - > > - Show quoted text - Hi Jim, Thank you for your good information. If a compiler does have the attribute capability, it would greatly easy the trouble a lot. For almost any state machine, I have been always using 2-processe method, it is clear and very informative, the only drawback is the missing of signal initial value assignment. With your new definition, I am very encouraged that I expect Xilinx compier will have the ability soon. WengArticle: 116292
You have to make sure that the processor accepts the BRAM data only when the BRAM WE is inactive, i.e. when the BRAM is really meant to read data. Peter Alfke On Mar 6, 2:14 am, "wojt" <wojtek.bo...@gmail.com> wrote: > Hi guys > > I'm trying to synthesize processor core with ROM and RAM in the > VirtexE FPGA. > > I've created RAM memory using VirtexE Block RAM resources by means of > 'Single-Port Block Memory Core Generator' in Xilinx ISE. > > My problem is that VirtexE memory supports only 'Read-after-Write' > mode. In this mode, what has been written to the memory is transferred > on the active clock edge to the output port of the memory immediately > after assertion of 'Write Enable' input. > > I need to interface this memory to the processor which accepts all > values coming from the RAM, therefore 'No-Read-on-Write' mode, where > input data are not transferred to the output of the memory after > successful write, should be used. > > 'Read-after-Write' causes invalid values to be transferred to the > processor after each write to the RAM. > > Does anyone know how to overcome this problem? > > Thanks! > WojtArticle: 116293
On Mar 5, 3:51 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > "Jim Wu" <jimwu88NOOOS...@yahoo.com> writes: > > On Mar 1, 7:03 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > >> "Patrick Dubois" <prdub...@gmail.com> writes: > >> > Hello, > > >> > I have been using batch files to handle the build process with a > >> > Xilinx flow for a while. Now I want to move to a more sophisticated > >> > approach to handle dependencies better. > > >> This has just reminded me of something I discovered recently: > > >> Neither PAR nor TRCE return an error if the design fails timing, so > >> any script/makefile which relies on the return code being non-zero as > >> an error (like... well... just about anything sane!) will carry on > >> through it's script as if everything is OK! > > >> You have to parse the PAR logfile for "No timing errors found" if you > >> want to be sure. > > >> I have a change request in to fix this, please add your weight to the > >> request (unless you think I'm bonkers for thinking that failing timing > >> is an error!) > > > Failing timing is an error, but personally I don't want the tool to > > return an error code just because of timing errors: > > OK< I can see people want to work in different ways, but to have the > *default* situation of "no error on error" is counter-intuitive! > > > * I have seen people over-constraining designs. If par doesn't meet > > the over-constrained timing but meets the desired timing, I don't want > > my script to stop. > > I do :-) Why overconstrain? If they want some margin on the design, > are they be happy with less margin than you asked for? Some people overconstrain designs to get more margin. Some do it just to get the design to meet the target frequency. (e.g. if my design needs to run at 100Mhz and it never meets the timing if I put a 10ns period constraint. If I put a 9ns period constraint, the design doesn't meet the 9ns timing, however if it shows the design can run at 9.7ns period, I am happy.). I am NOT suggesting people overconstrain their designs though as it may hurt the timing result as well.. > > > * If I am in the lab debugging my design and want to quickly try out a > > few things, I don't want my script to stop just because one net failed > > timing by several ps. > > Maybe, that's why one of my suggestions to Xilinx is that they return > the timing score, so you can decide how much failure is acceptable > (from "0" upwards). I use Makefile most of time. A return value of non-zero will cause make to exit unless I put some checking into my Makefile. Your suggestion solves one problem, but creates another. Grepping timing score from the par report is pretty easy, so why bother to change the behavior of the tool, which would make "make" users unhappy. Cheers, Jim http://home.comcast.net/~jimwu88/tools/Article: 116294
On Mar 5, 6:01 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > news:1173140726.435538.84620@30g2000cwc.googlegroups.com...> Hi, > > I am very confused with latch generation in VHDL. > > > 1. I have been using VHDL for 7 years and I have never met a situation > > I need a latch. > > In FPGAs and CPLDs there is not much need for a latch because a flip flop > will do just fine. > > > > > 2. I want to know why VHDL let VHDL programmers guess what is to be > > generated in the following situation that I know is only case a latch > > may be generated: > > There is no guessing involved. Certain coding styles infer a latch, just > like others infer a flip flop and still others infer a block of memory. > > > > > > > > > process(a, ...) > > begin > > -- signalA <= '0'; > > case state is > > when A_S => > > if(a = "000001") then > > signalA <= '1'; <--- a latch is generated, why not > > generating an error ? > > state_ns <= B_S; > > else > > state_ns <= A_S; > > end if; > > > ... > > end process; > > > Because the first line " Latch_A <= '0'; " is easily missed > > Yeah, I missed it too. I don't even see anything called "Latch_A". > > > when the > > process content is big, signalA is generated by VHDL definition as a > > latch. > > That's why many people (myself included) discourage the use of processes > that are not synchronously clocked (i.e. the sensitivity consists of one > signal...'Clock'). Doing so completely avoids the above coding situation > which can (if you're not careful) infer an unintended latch. > > > > > Here are my questions: > > 1. Latch is rarily used throughout all VHDL, why doesn't VHDL > > introduce a latch() statement to specially be used for this purpose > > while generating an error in the above process(). > > Maybe you should read what you wrote again. "Latch is rarily used ..." and > "introduce a latch() statement to...". The obvious questions here are > - Why clutter the language for something you claim would rarely be used? > - For those that do use latches, are you suggesting that there code should > no longer be accepted, resulting in an error? > > My guess is that there would not be much support for a 'rarely used' > addition that also breaks legacy code. If you want such a function then > VHDL allows you to write it yourself and incorporate it wherever you like > inside your own code. > > > > > 2. Here is a latch function definition true table: > > Enable = 1: > > CLK = H, D = H, OUT = H > > CLK = H, D = L, OUT = L > > CLK = L, D = X, OUT = Q0 (latched data). > > > It means when clock is high, data is transparent. Input is directed > > into output. > > If you say so, it leaves a bit to the imagination, like why is the magic > signal 'Q0' the latched version of 'OUT'....personally I find the following > to be much more descriptive and easy to read if I ever did want to infer a > transparent latch. > if (CLK = '1') then > Q <= D; -- Chose not to call it 'OUT' as you did so as to not use a > VHDL keyword > end if; > > > When clock is low, the data is latched on falling edge of clock. > > The falling edge of a clock that is low? There's another logic oddity. > > > > > In the above process(), there is no clock specified. Which clock will > > be used if there are multiple clocks in the design ? > > VHDL doesn't have 'clocks', it has 'signals'. The logic is almost > completely specified by the plain text code that is written. The only thing > VHDL leaves to the imagination (i.e. it's in the LRM and you must learn > this) is that if you don't specify the value for a signal then it will > remain at it's current value. In the above mentioned latch process that I > wrote, if the 'if condition' is not met (i.e. "CLK = '1'" is not true), > since I haven't specified anything for the 'else' branch, the VHDL LRM says > that signal 'Q' would remain unchanged. > > Much like the say all software languages are defined I might add so it's not > at all peculiar. > > > > > 3. In the above example, condition: K = (state = A_S and a = "000001") > > should be true to set signalA. What is K role? If K is used as the > > latch enable signal, half clock the latch is transparent and its > > stored data would be destroyed if there is a glitch with K and could > > not keep signalA true value unchanged. > > > 4. I don't know how to design the latch for signalA with K input? > > > If you know the answers, please help. > > 1. Don't use latches. > 2. Don't use coding styles that can result in unintended latches. > 3. Concentrate on the functionality and performance of your design while > remaining within whatever I/O, logic resource, power, etc.constraints that > your design might have. > > Kevin Jennings- Hide quoted text - > > - Show quoted text - Hi Kevin, In my first posting, there are 3 questions: 1. Why doesn't compiler generate an error for unintended latch generation? This question is satisfactorily answered: there is a new attribute to give errors if an unintended latch is to generate. It says that some other people had already observed the situation long time ago. 2. If the above error is given an error, VHDL may include a special statement to generate a latch. This is another big problem: I don't know how ASIC people generate a real latch using VHDL? I think they may most likely use latch library to generate special latch instead of using VHDL statements. I read an article about asynchronous FIFO written by two engineers one of whom is Pete Alfke of Xilinx (it is the best article I have read in my life). In the paper they say that they fail to generate two or 3 latches in their design using Xilinx chip. If so, it seems to me that there is no reliable statement in VHDL to generate a latch for a FPGA chip. 3. If the example would generate a latch for signalA, how it is generated? KJ answered the question. If the equation KJ suggested is true, it would like the following: if (state = stateA_S and a = "000001") then signalA <= '1'; end if; Finally I realized KJ saying is correct. Thank you, KJ and Lewis. WengArticle: 116295
On Mon, 05 Mar 2007 15:08:40 -0500
"Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote:
> In the process,
> our validation team whacked Cadence a few times for incorrect
> gate-level output from VHDL.
Don't tell me that you are surprised that Cadence Verilog
synthesis is better than their VHDL synthesis? They were
the ones who promoted Verilog for the last 15 years after all.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
Article: 116296> Why do you dislike make? > > Personally, I just use a series of batch files... > > Cheers, > Martin I don't like make mainly because of its obscure "language" and because I found it very hard to debug a makefile. Granted, I'm no expert on makefiles and that might be why I have trouble with it but others seems to agree: http://freshmeat.net/articles/view/1702/ Now the reason I'm looking for something more powerful than batch files is because my project is modular. I compile most modules (10 at the moment) into its own separate ngc file that I combine together later in the flow. Compiling all these modules each time takes too much time (which is why I separated them in the first place). Right now I just keep track mentally of which file I changed and rebuild the corresponding module manually (by launching its batch file). I would prefer a tool that keep tracks of file changes automatically and rebuilds only the modules that are necessary, which is what Make or SCons could do for me. Thanks for you interest. PatrickArticle: 116297
Attila Kinali wrote: > On Mon, 05 Mar 2007 15:08:40 -0500 > "Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote: > >> In the process, >> our validation team whacked Cadence a few times for incorrect >> gate-level output from VHDL. > > Don't tell me that you are surprised that Cadence Verilog > synthesis is better than their VHDL synthesis? They were > the ones who promoted Verilog for the last 15 years after all. My point was simply to illustrate that not only do tool vendors often disagree on specific language features, one vendor's tools may also show major (design-breaking) disagreements on netlists synthesized from exact HDL equivalent in different languages, hence the need to do equivalence checks to catch probable language-specific issues before ordering masks and wafers. The path of least pain when dealing with one specific vendor would be to stick with that vendor's preferred language... but things are not quite that simple when the complete tool chain includes software and IP cores from over a dozen different providers. Surprised that Cadence prefers Verilog? Not really... after seeing so many ISE VHDL bugs suggesting Verilog as the work-around until ISE v90.87 (many of these fixes keep getting pushed back to the next revision), I might decide to switch to Verilog for my future projects - VHDL 200X (which promises significant nonsense reduction) is getting nowhere and it'd be years until ISE gets it right anyhow.Article: 116298
On Mar 6, 3:59 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > My point was simply to illustrate that not only do tool vendors often > disagree on specific language features, one vendor's tools may also show > major (design-breaking) disagreements on netlists synthesized from exact > HDL equivalent in different languages, hence the need to do equivalence > checks to catch probable language-specific issues before ordering masks > and wafers. > > The path of least pain when dealing with one specific vendor would be to > stick with that vendor's preferred language... but things are not quite > that simple when the complete tool chain includes software and IP cores > from over a dozen different providers. > > Surprised that Cadence prefers Verilog? Not really... after seeing so > many ISE VHDL bugs suggesting Verilog as the work-around until ISE > v90.87 (many of these fixes keep getting pushed back to the next > revision), I might decide to switch to Verilog for my future projects -VH= DL 200X(which promises significant nonsense reduction) is getting > nowhere and it'd be years until ISE gets it right anyhow. Instead of ditching VHDL for Verilog, you might want to consider Synplify instead of xst. I am using some tidbits of VHDL-200x in my current design and xst produced a wrong netlist from that vhdl. I have access to Synplify for my master's degree (thankfully) and I ran that piece of code through Synplify. The post-synthesis simulation showed that the result from Synplify was correct, contrary to xst (v9.1 btw). I have been bitten a few times by wrong netlists for using slightly "advanced" features of VHDL that xst didn't handle properly. Now I do much more post-synthesis simulations than before (and I learned the hard way that using records in ports causes problem in that case, but that's another story...). My 2=A2. PatrickArticle: 116299
Patrick Dubois wrote: > I am using some tidbits of VHDL-200x in my > current design and xst produced a wrong netlist from that vhdl. Which bits?
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