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
Mike Treseler wrote: > Daniel S. wrote: > >> Since I worked mostly with ASIC-minded people up to now, I was always >> asked to write the most plain, boring, simple and flat VHDL possible to >> avoid most language-feature-specific tool bugs elsewhere in the tool chain. > > My comments were intended for FPGA designs > where VHDL source is still in the mainstream. > For some reason VHDL is depreciated for > ASIC designs in the USA. > > -- Mike Treseler This is an FPGA forum so I know most people's comments are primarily FPGA-oriented... but this does not change the fact that most synthesis and simulation tools have had, have and will continue to have weird and totally obscure bugs, diverging or faulty interpretations of some language features that will cause unexpected hardware behavior. Since FPGAs target a much broader engineering public than ASICs, related tools are exposed to more diverse design methodologies and corner-cases, further accelerating the advancement of the tool vendors' test coverage. Since respins cost over a million and have two months turnarounds, ASIC designers avoid corner cases and bleeding-edge language features to reduce unnecessary technological risks - the ASIC bleeding-edge does not have as much material to sharpen itself against. Yes, the situation has improved a lot on both fronts over the years and will continue to improve in the future but bugs and divergences will always exist. ASIC people simply try to stick with the path of least unnecessary pain since doing otherwise is several orders of magnitude more expensive (time+money) than it is with FPGAs. BTW, my last job at an ASIC shop used VHDL as the primary language and translated verilog to run equivalence checks on synthesis tools' output netlists to weed out language-specific synthesis issues. In the process, our validation team whacked Cadence a few times for incorrect gate-level output from VHDL. This sort of risk alone explains a lot of why VHDL is not very popular for ASICs.Article: 116251
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?Article: 116252
You can make both projects to point to the same source files, although the support for external files in ISE is not great either. It will work, but you probably won't be able to use some of the ISE features such as snapshots for example. Also, you might have to set some paths explicitly... /Mikhail "Jean Nicolle" <jean.nicolle@sbcglobal.net> wrote in message news:MP_Gh.5224$M65.4707@newssvr21.news.prodigy.net... > 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? >Article: 116253
On 5 Mar, 18:13, "MM" <m...@yahoo.com> wrote: > Anyone knows when we will be seeing this? > > Thanks, > /Mikhail Several weeks ago. Cheers, JonArticle: 116254
Hi there! @Ben you are certainly right. I got a radar-impuls reshaping prob at 240 Mhz, can you give me the VHDL and the pcb layout? @unknown <http://www.ctrdefense.com/files2/lcd_init.vhd> could be a starting ground? Happy chip burning cu PitArticle: 116255
> Several weeks ago. Is it an early access of some sort you are referring to? I haven't seen any official announcement yet... /MikhailArticle: 116256
On Mar 5, 3: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? If you're using ISE 8.2, I would suggest you create two tcl scripts that just set up the target device and then run your normal build on the same ISE project file. Cheers, Jim http://home.comcast.net/~jimwu88/tools/Article: 116257
I am guessing that this is because the IT dept. at your school limits what the students can do on lab systems. If this is a lab system, you may have to talk to your IT dept and have them (as administrators) make this change. <kaosnannaz@gmail.com> wrote in message news:1172964366.360317.54750@30g2000cwc.googlegroups.com... > On Mar 3, 6:32 am, "Brandon Jasionowski" <killerhe...@gmail.com> > wrote: >> On Mar 3, 12:55 am, kaosnan...@gmail.com wrote: >> >> > I am using these programs in my digital class but do not know how to >> > link modelsim to ISE. In our school lab, after I make my schematic, I >> > can run model sim to simulate it from inside ISE. Does someone know >> > how I would set this up? >> >> Open up ISE. >> >> Edit > Preferences > ISE General > Integrated Tools >> >> Browse to modelsim.exe. >> >> If you change the Sources pulldown to Behavioral Simulation in your >> project, you can select a test-bench, right-click > properties on the >> ModelSim icon to change some properties. > > The ModelSim icom is not available. >Article: 116258
Symon wrote: > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:45ec68c8@clear.net.nz... > >>Of course, the ideal is to have Xilinx put this into the BGA carrier . >> > > Hi Jim, > Right. > I wonder if some of those interposer materials might offer a solution in the > future? Some sort of bypass circuit in between the BGA and the PCB somehow? > Dunno, Syms. Hmm, yes, the largest one is close to die-sized, at ~17x15mm, (a monster, and also 2.5mm thick), but for that you get wideband low-milliohms impedances, and 300uF/1000uF, so imagine a couple of BGA layers made of this stuff.... - probably worth more to customers than putting the boot-prom into the package, measured in practical PCB area cost, and EMC/RFI gains.... Interesting this was driven by the games industry, which also gives us the Cell CPU.. In the short term, I think one of these/rail on the opposite side of the PCB, would be a usefull step, that only needs the Chip & FPGA vendors to talk to each other. Of course, Xilinx's volumes are far less exciting than PS3. It's a little hard to decode the exact footprint/keepouts of these. -jgArticle: 116259
"Symon" <symon_brewer@hotmail.com> wrote > Hey Guys, > It's a been a while since we had a bypass capacitor religious war, so I > thought I'd stir things up a bit! > Seriously, I've been reading about X2Y capacitors, and a search of the > newsgroup revealed that these very interesting parts have only been > mentioned once or twice in passing. (By Austin, natch!) > > 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 > > Steve Weir does a great job of showing why X2Y caps give you more bang for > your buck. As these parts have exceptionally low inductance, they can > substantially reduce the number of capacitors AND vias you need, and they > quote that :- > "Can replace from three to six+ regular caps depending on via and plane > geometries" > "Vias at $0.005/hole / $0.01 / capacitor typical, often COST MORE than the > capacitors they connect!" > > Here's another interesting article:- > http://www.x2y.com/bypass/mount/backside_cap.pdf > > They recommend using small 'puddles' of copper to connect all the bypass > elements together so you can use fewer capacitors but keep the same bypass > network performance. > > Check out http://www.x2y.com/bypass.htm for more articles. > > AFAICS, the main drawback is that X2Y caps are available in a range of > values. This means nutters will use several different values in their > bypass networks to create 'resonances' and the like. :-) > > Anyway, I hope this is of interest, Syms. 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. MarcArticle: 116260
On Mar 5, 3:34 am, "Symon" <symon_bre...@hotmail.com> wrote: > Some in-line stuff about Proadlizer, my other comments at the end. > > "Austin" <aus...@xilinx.com> wrote in message > > news:esev91$st1@cnn.xsj.xilinx.com... > > > Marc, > > > Other than their odd name, they are extremely low impedance t-lines. > > > As such, they are basically falt at 1200 uF from DC to daylinght. > > Unfortunately, once you mount them, they no longer work to infinity (or > beyond). As ever, the design is limited by the physical layout of the parts > and connections, not the devices. > > > > > So, if you put a power supply at one end, and isolate the ground (in other > > words, that is what the slit is for) you transfer power to the other end > > (hot and ground) with a .001 ohm t-line (looks like that very low > > impedance at frequencies up to a few hundred MHz). > > I think this paragraph is wrong, Austin, there are no slits in the ground > plane in the designs shown at:-http://www.nec-tokin.com:80/english/product/cap/proadlizer/test1.html. > The slots are only in the power planes. Ground isn't isolated, that would be > very bad indeed. You've got to get signals in and out as well as power. > > But hold on a minute, I see on this site they show the thing used with a > slot in the ground plane.http://www.chemi-con.co.jp/english/support_e/proadlizer_e.html > Ouch! What happens to all the signals going to and from the device? > I see here:-http://www.nec-tokin.com/english/product/pdf_dl/proadlizer_e.pdf > they still mention the ground plane slot, claiming the ground plane slot > offers "more optimal performance" [sic]. My bullshit sense is tingling! I'd > suggest this is not true for a real system with signals traversing this > ground plane slot. It makes me wonder if they really know for what this > device should be used. > > > > > > > > > So, now you see a AC short, looking either way: from the power asupply to > > the load, or from the load to the power supply. > > > The Playstation 3 uses 8 of them, they isolate each huge ASIC from the > > other huge ASICs, and there are3 NO OTHER CAPS on the pcb.... > > > Yes, that is right. > > > Whereas the Wii has > 300 little caps, PS3 has these 8 "magic" t-line > > structures. > > > Do they work? Well, millions of PS3 aren't chunking away happily for no > > reason at all. > > > We are looking at these seriously to reduce the bypassing requirements > > down to the PS3 limit: a few of these, and NOTHING else (no other bypass > > caps whatsoever). > > > So, it seems the NEC-TOKIN part is the first really new invention in > > bypassing in many many long years of people who just like to ignore that > > power distribution is a real issue, and one that needs some creativity. > > > My hat is off to the engineers who created this wonder. > > > Austin > > OK, what these devices appear to be good at is isolating the power supply > noise from the ASICs/FPGA and stopping it spreading over the board. They > also provide bypassing for the ASICs/FPGA. It's kinda like a series ferrite > and a parallel capacitance at the ASIC/FPGA end. The 'new' bit is that it's > all integrated onto a nice low ESL package. Sadly, the end user then has to > attach this to his circuit which will affect this impedance. The blurb on > the site shows how they localise EMC problems, reducing emissions, more than > what great bypass > capacitors they make. > > I see these parts got a brief mention on SI-list back in Jan '04, so I'd > suggest they're not a 'miracle breakthrough' or we'd have heard more about > them already. I would tend to go for theX2Ystuff we discussed last week on > CAF.http://www.googlefight.com/index.php?lang=en_GB&word1=proadlizer&word... > Or, perhaps slightly more seriously, :-http://www.x2y.com/bypass/measure/comparative_device_only.pdf > > Anyway, whatever else, it's nice to see people doing designs with tiny local > power planes for the FPGA, and not believing all the claptrap about plane > capacitance and resonances to help PDS for big BGA packages. > > Cheers, Syms.- Hide quoted text - > > - Show quoted text - 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. Regards, Steve.Article: 116261
nagaraj wrote: > On Mar 5, 2:57 am, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> > wrote: >> >> In my case, I wanted to infer "True dual-port BRAMs" but copy-pasting >> the guide's template (ISE 8.1/8.2) consistently resulted in XST crashes. >> After wasting a week trying to work this out last summer, I decided to >> give up and used a coregen RAM. >> >> More details about my experience with the true dual-port BRAM template: >> - pasting the code in the module's VHDL causes unrecognized BRAM >> inference warnings, causing XST to attempt implementation with >> distributed RAM >> - whipping up the template into its own module and synthesizing it as a >> top module works as advertised/expected >> - instantiating the BRAM template module in an actual design crashes XST >> > > Try this piece of code..... > > > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_unsigned.all; > > entity BRAM_test is > port (CLOCK : in std_logic; > -- reset : in std_logic; > di : in std_logic_vector(15 downto 0); > do : out std_logic_vector(15 downto 0)); > end BRAM_test; > > architecture syn of BRAM_test is > > type ram_type is array (1023 downto 0) of std_logic_vector (15 downto > 0); > signal RAM : ram_type; > attribute ram_style : string; > attribute ram_style of RAM: signal is "block"; > > type STATE_TYPE is (P1, P2, P3); > signal STATE : STATE_TYPE; > > signal addr : std_logic_vector(9 downto 0); > > begin > main : process (CLOCK) > begin > -- if (RESET = '1') then > -- STATE <= P1; > -- addr <= (others => '0'); > if (CLOCK'event and CLOCK = '1') then > case STATE is > when P1 => > RAM(conv_integer(addr)) <= di; > do<=di; > STATE <= P2; > when P2 => > do <= RAM(conv_integer(addr)); > STATE <= P3; > when P3 => > addr <= addr + '1'; > STATE <= P1; > end case; > end if; > end process main; > end syn; The code above looks like it would infer a single-RW-port BRAM but the intended functionality is unclear: DO is assigned DI at P1, unchanged at P2 since the RAM location is P1's DI already assigned to DO, P3 has no effect... the code's net effect appears to be "do <= di;" every third cycle and thus fails to demonstrate any sort of BRAM functionality. Inferring a BRAM with two independent synchronous read and write ports (as one would for FIFO applications) is pretty straight-forward with ISE/VHDL and has worked well enough at least since 7.1. Where things get complicated is with true dual-port BRAMs - the ones with one RW port and a second R/W/RW one. The XST Coding Style guide has a template for them but it causes XST (ISE 8.1/8.2 - I have yet to try with 9.1) to crash when used in an actual design. This has forced me to use either coregen or explicit primitive instantiation. Coregen is slow, buggy and often inconvenient while primitives lack flexibility - so I would like to find out how to make XST (8.1/8.2) digest true dual-port (and not spit them out as distributed RAM) without having it crash. Until I find out (or get an opportunity to upgrade ISE to a version that has this bug fixed), at least I can still use coregen and primitives.Article: 116262
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.
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.
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().
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.
When clock is low, the data is latched on falling edge of clock.
In the above process(), there is no clock specified. Which clock will
be used if there are multiple clocks in the design ?
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.
Thank you.
Weng
Article: 116263On Mar 2, 7:01 pm, Ray Andraka <r...@andraka.com> wrote: > Weng Tianxiang wrote: > > Hi, > > What is the running frequency for a typical FPGA application using > > Virtex 5? > > > A friend of mine told me long ago that we could expect to get 1/10 > > running frequency of the fastest CPU for a fastest FPGA in market. > > > Now the fastest CPU runs at 4GHz, can a FPGA application using the > > fastest FPGA chip be expected to run at 400MHz, 1/10 of fastest CPU? > > Is Virtex 5 the fastest FPGA so far? > > > For example, DDR2 runs at 333MHz, can a DDR2 application core run > > normally at 333MHz without any trouble such that there is no need to > > reduce application core running frequency to meet 333MHz challenge? If > > so for Virtex 5, it can be claimed that 333MHz is achievable. > > > 1/10 ratio between the fastest CPU and the fastest FPGA chip running > > frequencies is a reasonable expectation or not? > > > Thank you. > > > Weng > > I expect V5 can be run at 400MHz with careful design fairly easily. It > is faster than Virtex4, and I have successfully completed non-trivial V4 > designs that run at 400 MHz. Issue 3 of the Xilinx DSP magazine, which > should be coming out very soon, has an article in it about a 1.2 > GSample/sec Floating point FFT design I did in it. The FFT engines in > that design are clocked at 400MHz. The device is a Virtex4 SX55 -11. > > Clock rate around 1/10 of fastest CPU seems reasonable, but it will > generally take an experienced FPGA designer to achieve that.- Hide quoted text - > > - Show quoted text - Hi Ray, Thank you very much for your good news. WengArticle: 116264
"Weng Tianxiang" <wtxwtx@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. > > 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. > > 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(). > > 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. > When clock is low, the data is latched on falling edge of clock. > > In the above process(), there is no clock specified. Which clock will > be used if there are multiple clocks in the design ? > > 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. > > Thank you. > > Weng >Article: 116265
"Weng Tianxiang" <wtxwtx@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 JenningsArticle: 116266
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 From taileb.mehdi@gmail.com Mon Mar 05 21:43:01 2007 Path: newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!postnews.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 05 Mar 2007 23:43:00 -0600 From: El Mehdi Taileb <taileb.mehdi@gmail.com> Subject: Re: Integrate custom cores within Core Generator Newsgroups: comp.arch.fpga References: <pan.2007.03.05.00.57.08@gmail.com> User-Agent: Pan/0.125 (Potzrebie) Message-Id: <pan.2007.03.06.05.42.38@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Mon, 05 Mar 2007 23:43:01 -0600 Lines: 19 X-Trace: sv3-JsHBucPFF7QZfLHW71zOXIKgbwlL8/DJwYlrwZhtTYhj00kMhcZrc0BfTBtxwS8S9q1eHJLZQ8T/76a!dWjxuDjv/mguC7r1MzzGlZx8eoBVho0TD709eeQEaerYFqoS0IKDO85VBPs= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.34 Xref: prodigy.net comp.arch.fpga:127830 Hi again, Since I didn't got any answer I suppose one of the two: -It's impossible (or possible ONLY in cooperation with Xilinx). -No one knows how. The GUI I would like to develop and integrate with CoreGenerator is for a Reed-Solomon decoder. The GUI should build verilog source code in accordance with the parameters entered by the user, as MIG does. Best regards Mehdi On Sun, 04 Mar 2007 18:57:15 -0600, El Mehdi Taileb wrote: > Is there a way to integrate custom cores into Core Generator. i.e > develop the GUI etc etc??? > > Best Regards > MehdiArticle: 116267
Hi Designers, The website dedicated for we(VLSI Chip designer's discussing about trade-off's /problems solutions/ FAQ's)... vlsi.chip.googlepages.com I found a very good website for VLSI Chip design, which has columns for all the implementation challenges, ASIC FAQ's more relevant to designers, VLSI Design flows, Design checklists, good lectures/courses/ white-papers.... vlsi.chip.googlepages.com check this site out.... more over the Implementation challenges column/ FAQ's will be very helpful and knowledgeable .... Digitally Your'sArticle: 116268
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. -aArticle: 116269
On Mar 1, 9:27 am, "S.T." <s...@iss.tu-darmstadt.de> wrote:
> Hi
>
> Since Version 7.x xilinx xst is able to infer block ram out of appropriate
> vhdl statements. Unfortunately it is not working in the example given
> below. Does anybody have an idea why the code below gives the following
> warning:
>
> WARNING:Xst:1440 - Cannot use block RAM resources. Please check that the RAM
> contents is read synchronously.
>
> Thanks
> ST
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_unsigned.all;
>
> entity BRAM_test is
> port (CLOCK : in std_logic;
> reset : in std_logic;
> di : in std_logic_vector(15 downto 0);
> do : out std_logic_vector(15 downto 0));
> end BRAM_test;
>
> architecture syn of BRAM_test is
>
> type ram_type is array (1023 downto 0) of std_logic_vector (15 downto 0);
> signal RAM : ram_type;
> attribute ram_style : string;
> attribute ram_style of RAM: signal is "block";
>
> type STATE_TYPE is (P1, P2, P3);
> signal STATE : STATE_TYPE;
>
> signal addr : std_logic_vector(9 downto 0);
>
> begin
> main : process (CLOCK, RESET)
> begin
> if (RESET = '1') then
> STATE <= P1;
> addr <= (others => '0');
> elsif (CLOCK'event and CLOCK = '1') then
> case STATE is
> when P1 =>
> RAM(conv_integer(addr)) <= di;
> STATE <= P2;
> when P2 =>
> do <= RAM(conv_integer(addr));
> STATE <= P3;
> when P3 =>
> addr <= addr + '1';
> STATE <= P1;
> end case;
> end if;
> end process main;
> end syn;
Some things:
a) don't do this as a state machine -- you need to make the write
process(es) separate from the read process(es) (or at least keep the
read logic in a process separate from the write logic). One important
point is that an FPGA's "single-port RAM" still has separate data-in
and data-out ports (unlike a regular RAM chip, which has one
bidirectional data port). This means that you don't have to worry
about bus contention, etc., and you don't need a read enable. The read
side code is simply
do <= memarray(address);
b) The read has to be synchronous; otherwise it won't use block RAMs.
c) Don't use an async reset, which are not allowed for block RAMs.
d) std_logic_arith is deprecated and should be replaced with
numeric_std.
-a
Article: 116270On 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. Also, VHDL ist not only used for synthesis. It was intended to model systems and there clearly are systems that behave like a latch so there must be a way to model them. Most synthesis tools issue a warning in the cases that you describe which is an adequate reaction to the situation: The tool accountered legal code of which it knows that it is often written unintentionally. Kolja SulimmaArticle: 116271
Matthew Hicks wrote: > Peter, I totally agree with your points and while writing my post I knew > there would be a huge difference in perspective because of one, the > generation(s) gap, as I am still in graduate school, and two, the > background, as I have a C.S. degree. However, my comments were more for > beginners who shouldn't be overloaded in the infinite amounts of > complexity possible with FPGAs (for an example just read one of Austin's > posts). Newbies who are probably working on some trivial project should > get the fundamentals first (everything is binary, data flow, ...) and > then work towards the actual optimized implementations gradually > building in complexity, if constraints deem it necessary. After all, > you don't learn to swim in the ocean during a hurricane, you start in > the kiddy pool. > > Although, I still believe a lot of work needs to be done to synthesis > engines so they can better abstract the low-level complexity away from > the designer all the while resulting in an optimized implementation. > For a quick example, I still cannot believe you don't optimize across > files during synthesis. For the time being, I prefer the embedded > systems point of view presented in Dave's response. You do not want synthesis tools to make too many guesses. If you let the synthesis tools guess how you meant to handle floating point numbers, you will end up with unknown precision, unknown rounding, unknown range, etc. Maybe you want to do 18x18 multiplies and only keep the 10 MSBs... or maybe you actually only want the 20 LSBs, the synthesis tools are oblivious to application-specific details and it is the designer's responsibility to fit application-specific stuff into HDL constructs. As far as optimizing across hierarchy is concerned, Xilinx's ISE and Altera's Quartus DO have options to enable global optimizations. I mostly work with ISE/XST and there are dozens of options to tell how much optimizing you want XST/PAR to do. If you want XST to do global optimizations, you first have to disable "Preserve hierarchy" and most other similarly minded options - but this may make your life miserable if you ever need to debug using ChipScope or post-PAR simulations. Enabling register balancing and moving FFs along with register duplication can also yield major improvements and further contribute to debugging obfuscation. There are dozens of optimization options you can play with if you want/need to. I would take more robust and efficient synthesis tools over "smarter" ones that try to guess what you want to do any day... XST and other tools already have a hard time correctly processing "dumb" VHDL, the last thing we need is even buggier synthesis tools that try to be smart.Article: 116272
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. ThanksArticle: 116273
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: 116274
On 5 Mar, 22:27, "MM" <m...@yahoo.com> wrote: > > Several weeks ago. > > Is it an early access of some sort you are referring to? I haven't seen any > official announcement yet... > > /Mikhail No, I misread it as ISE 9.1i. EDK usually follows a month or two after. Sorry. Cheers, Jon
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