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
OK.
I copied your code into my machine.
And I recopied it at the end of this message
with my own fomatting. I assume you are
using the default library declarations that
I have at the top?
Could you also send the seven_segment code
so that I can run the whole thing?
Still not too clear on what you are doing with the
AN inouts. Are you trying to walk a hot 0 around.
Your AN3 turns on AN0 and AN0 turns on AN3.
Is that what you intended?
Brad Smallridge
b r a d @ a i v i s i o n . c o m
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity Display is
port (
clk : in std_logic;
rst : in std_logic;
d0 : in integer range 0 to 9;
d1 : in integer range 0 to 9;
d2 : in integer range 0 to 9;
d3 : in integer range 0 to 9;
seven_seg : out std_logic_vector(6 downto 0);
AN3 : inout std_logic;
AN2 : inout std_logic;
AN1 : inout std_logic;
AN0 : inout std_logic);
end Display;
architecture Behavioral of Display is
component countdecoder is
port( count: in integer range 0 to 9;
seven_seg : out std_logic_vector(6 downto 0));
end component;
signal count : integer range 0 to 9;
signal CTR : std_logic_vector(12 downto 0);
begin
-- make a copy of the decoder
decoder1: countdecoder
port map(
count => count,
seven_seg => seven_seg );
Display_left_to_right: process(rst,clk)
begin
if rst = '1' then
count <= 0;
AN3 <= '0';
AN2 <= '0';
AN1 <= '0';
AN0 <= '0';
elsif clk'event and clk = '1' then
if (ctr = "0000000000000") then
if AN3 = '0' then
AN3 <= '1';
count <= d3;
AN0 <= '0';
elsif AN2 = '0' then
AN2 <= '1';
count <= d2;
AN1 <= '0';
elsif AN1 = '0' then
AN1 <= '1';
count <= d1;
AN2 <= '0';
elsif AN0 = '0' then
AN0 <= '1';
count <= d0;
AN3 <= '0';
end if;
end if;
ctr <= ctr + "0000000000001";
if (ctr > "1000000000000") then
ctr <= "0000000000000";
end if;
end if;
end process Display_left_to_right;
end Behavioral;
Article: 79201Paul, OK. So they do not runaway (in silicon). Should really fix the spreadsheet so it doesn't look like it does. In a similar situation, our web based tool does not "blow up." It will report the actual junction temperature (say 108 C) which will let the designer know that they have exceeded the temp, and also give them an idea by how much they have exceeded the temp. A matter of personal preference perhaps? By stopping all data reporting beyond 100C, you hide the leakage current vs. temperature curve (beyond this point), which makes it harder to see just how bad it can get. At least we show the whole curve. And, as for the surge, the statement you made below is the best description (perhaps the only description) of 'no surge': if the tool says I need X amperes for the design, and I supply X amperes, the design will power on, configure, and work. (Since that is what you clearly said below.) Sincere congratulations on fixing the surge. Our customers have been very happy that we did that six years ago for Virtex II (and kept it out of subsequent product). Austin Paul Leventis wrote: > Hi Austin, > > >>Not only is the static Iccint current > 7.568 amperes at 100C, but > > the > >>device is clearly doing a thermal runaway (in Excel!). > > > The particular case you point out is not thermal runaway. But with no > cooling solution at 36 degrees ambient, the junction temperature will > be out of spec (the spreadsheet indicates this with 100+). The reality > is that anyone using 180,000 Logic Elements and 1000 I/O pins toggling > at a couple hundred Mhz will be dissipitating a lot more dynamic power > than static, and a cooling solution of some sort will be necessary > irrespective of static power. > > BTW, we test our chips without heatsinks. They do not go into thermal > runway. > > >>It looks as if the solution is iterative, and it keeps >>trying to converge with the formula for the Iccint being exponetial > > with > >>T, and the T just getting hotter, and hotter ...) > > > This iteration is a fundamental based on the physics at work here. > Static power is made up of a few components, but at 90 nm sub-threshold > leakage is the one that dominates. This occurs because transistors > aren't really "off". This is especially true on units that come out at > the fast end of the process spread (our Worst-Case numbers... you guys > don't seem to publish worst-case numbers), since these transistors are > leakier (due to lower threshold voltages, narrower channel lengths, > etc.). This sub-threshold leakage power increases exponentially with > junction (transistor) temperature. > > But junction temperature (Tj) is a function of overall power > dissipation and the cooling solution employed. Cooling solutions > (package, thermal compound, heat sink, and air flow) can be represented > in the end by a "thermal resistance" expressed in degrees/Watt. This > thermal resistance times the total power consumed gives the temperature > gradient from Ambient (surrounding air) to the Junction. The parameter > used to express this resistance is ThetaJA -- the thermal resistance > between junction and ambient. > > So we have: > Power = DynamicPower + StaticPower(Tj) > Tj = Ta (ambient) + Power * ThetaJA > > As you can see, solving for the junction temperature requires > iteration. Let's say you've got a chip that burns 1 W of static power > @ 25C, and is generating 3W of dynamic power (temperature insensitive). > This is a total of 4W at 25C. With no cooling solution, let's say > there is a thermal resistance of 10 degrees per Watt between the > junction (transistors) and ambient (surrounding air). Let's say the > ambient temperature is 25C. > > Iteration 1: Tj = 25C (ambient) > --> Static Power is 1W > Iteration 2: Tj = 25C + 4W * 10 deg/Watt = 65C > --> Static Power is now (say) 2W > Iteration 3: Tj = 25C + 5W * 10 deg/Watt = 75C > --> Static Power is now (say) 2.3W > Iteration 4: Tj = 25C + 5.3W * 10 deg/Watt = 78C > --> Static Power is now 2.4W > Iteration 5: Tj = 25C + 5.4W * 10 deg/Watt = 79C > --> ... > > As you can see, we converge on a Tj of ~80C in this hypothetical > example. > > Thermal runaway occurs when the this iteration reaches a point where > the incremental amount of static power for a 1 degree change in > temperature is greater than the cooling solution's ability to dissipate > that power. For example, with a 10 degrees per Watt ThetaJA solution, > if we were to ever reach a junction temperature where the Static Power > increased by more than .1 W/deg, then the static power would increase > faster than we could dissipate and this iteration would result in an > infinite junction temperature. In practice, the chip would release the > magic smoke that keeps it working. > > >>Sure, when the worst case static current is less than the surge, then > > >>there is no "surge...." >>Sure. So if the worst case static is 6 ameres, what is the 'surge' > > at > >>25C? Less than 6 amperes, but still there? > > > At any temperature, worst-case or typical or best-case silicon, there > is no surge current. A power supply designed to meet operating > conditions will result in succesful device power-up. > > - Paul >Article: 79202
Peter Sommerfeld wrote: > Hi Ken, > > I've done this before by writing my own fifo using the altsyncram > megafunction. altsyncram has a parameter MAXIMUM_DEPTH which allows > non-power-of-2 depths. Adding single-clock FIFO functionality (read and > write ptr management at a minimum) shouldn't be more than 20 lines of > HDL. You can go one step further and implement "stacked" memory > yourself, but then you have to write the muxing yourself, which > altsyncram does implicitly with MAXIMUM_DEPTH. > > -- Pete If you need asynchronous operation (2 clocks) you could mix both methods using a synchronous (single clock) FIFO after the async one. Of course cascading FIFO's will increase the latency.Article: 79203
I'm trying to interface a Centronics to send text to printer with OPB Bus. I have used the wizard of EDK. I have realized Centronics protocol with 3 registers: 1 for datas, 1 for reading signal from printer, 1 for sending signal to printer. But when I try to sintetize I receive the following error message: Error:Xst:528 Many sources on the signal <signal name> I have used the following code to send datas from printer to fpga:: signal_name <= port_name; register <= signal_name; (port_name would be connected to 25pin connector) Where is the mistake????? Many Thanks MarcoArticle: 79204
"Brad Smallridge" <bradsmallridge@dslextreme.com> schrieb im Newsbeitrag news:1114hkl50qr0gc0@corp.supernews.com... > What is the best software for post place and route problems? NO Post P&R Sim. If you have a clean synchronous design, just run a Behavioral sim and let the static timing analyzer see if you hit the desired clock frequency or not. No hazzle with Post P&R Sim. Regards FalkArticle: 79205
"newman5382" <newman5382@yahoo.com> schrieb im Newsbeitrag news:uRrQd.43626$pc5.36254@tornado.tampabay.rr.com... > >> Any chance that there is a missing process sensitivity item missing? > > > > Would that not effect the Behavior model as well? > > Typically, the synthesis tool will issue a warning, and insert the missing > item in the sensitivity list. Yes, the synthesizer will do so, but NOT Modelsim. If something is missing in the sensitivity list you will get funky results :-0 Regards FalkArticle: 79206
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:cutibd$baf1@cliff.xsj.xilinx.com... > Paul, > > OK. I'll reserve my judgement until I see the scope pictures. You believe in scope pictures in the age of Photoshop?? ;-)) Regards FalkArticle: 79207
> But let's look at the so-called reduction of 47% in the Altera
leakage
> current specs:
It was an "up to" number. You should be familiar with these ;-). The
biggest change was in the typical specs.
> Here is the change in worst-case 85 degree static power (the only
> static parameter that really matters)
Speaking of which, where are the V-4 worst-case static power numbers?
They are the only numbers that matter, but somehow you still haven't
published any for V4...
> 2S15 increased (!) by 48 %
> 2S30 reduced by 1 %
> 2S60 increased by 4 %
> 2S90 unchanged
> 2S130 decreased by 6 %
> 2S180 decreased by 14 %
Old data was pre-silicon data for many family members. Icc was based
on projections. Turns out the curve is flatter than expected, so
smaller devices have more current than expected and larger devices have
much less current. This is even more evident in the new typical
numbers:
25C 85C
2S15 +63% +10%
2S30 -14% -24%
2S60 -17% -19%
2S90 -31% -28%
2S130 -38% -34%
2S180 -38% -38%
Now, I think I did my math wrong somewhere in here because I know there
is one that decreased by 47%. But you get the idea.
> It takes creative marketing to call that a 47% reduction in leakage
> current !
Righteous indignation from Xilinx for use of an "up to" number? Give
me a break.
Paul Leventis
Altera Corp.
Article: 79208Paul Leventis wrote: >>If you mean this one, from 14 Feb >> > > http://www.altera.com/corporate/news_room/releases/products/nr-powerplay.html > >>that's a harder call. Are these actually the SAME numbers, (press >>released twice) or has two weeks resulted in another improvement ?. > > > I don't expect Xilinx to include these numbers. They were after all > just released yesterday. > > >>They don't quite overlay, as the Jan spec says 45%, but the Feb one >>is 47%, or is that 'really the same number' to marketing ? > > > Two seperate releases for two seperate improvements. EPE 2.0 had a up > to 45% reduction vs. 1.0, and EPE 2.1 has a up to 47% reduction vs. EPE > 2.0. Sorry for the up to numbers -- the results do vary a lot across > process, temperature and device used. Wow - all I can say, is I am looking forward to the March numbers, and EPE v2.2 ! Point to ponder: Given the real 'hot button' that power has become, and the huge commercial pressure to 'work the numbers', does that mean the margins are being eroded. What happens if the next batch of chips from the foundries (or a different foundry) nudge these finely tuned numbers upwards ? Will we see power-bin devices, like we now see Speed-Bin ones, or will prices increase as vendors take the yield hit, or will the EPE v2.71.201 simply quietly change the numbers, and designers find they have to enter the date code of the devices as well ? :) -jgArticle: 79209
Hello I have been writing some VHDL code for my CoolRunner CPLD. I am a beginner. I have made a project that counts events and sends them to a 16-bit counter. Currently I just look at the binary output. I would like to latch the counts and serially shift the counts out as SPI In hardware I would use a latching shift register like a 74HCT165 and would use /PL as a chip select and tie CP to SPI_CLK and Q7 to a buffer then to SPI_MISO Nothing fancy. So I guess I am asking if anybody has some VHDL code for a parallel in SPI out latch, or a SPI output counter. Any help is appreciated. MartinArticle: 79210
I recently purchased an Avnet Spartan 3 Evaluation Board but the supplied EDK *.xbd file doesn't have anything in it with PCI. Has anyone out there modified the *.xbd file to allow the Xilinx Base System Builder to create a PCI Bridge?Article: 79211
yes i con buit it too.. When I look at the system.pbd, I expected to to see a new bus for the wb. But i did'nt see it. I don't know if we need to see it or not. But i see that the wrapper is connected to the opb bus as a slave. The other question that i have is how to built a edk-core compatible with verilog file ? As i can see ther is only the vhdl file that can be use to make an edk core compitible. so if anyone have any idea of what we have to do to plug a simple wishbone GPIO connected to opbbus via the wrapper.... Jonathan "Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> a écrit dans le message de news: 42124499$0$2614$ba620e4c@news.skynet.be... > >> I also create a edk core from the wizard and take a look in the mpd file. >> I see in the mpd file under ## Generics for vhdl or Pa... >> >> PARAMETER C_FAMILY = virtex2p, DT = STRING >> >> This is probably what they need to the ncg build error ... And again i'm >> not shure >> > > Nope > > look at the additionnal step I posted today a few hour ago. > It now builds fine. > > But it doesn't seem to work ... > Has someone ever managed to use it ? > > > SylvainArticle: 79212
"Jonathan Dumaresq" <jdumaresq@cimeq.qc.ca_nospam> schrieb im Newsbeitrag news:N_sQd.23200$6f.6401@charlie.risq.qc.ca... > yes i con buit it too.. > > > When I look at the system.pbd, I expected to to see a new bus for the wb. > But i did'nt see it. I don't know if we need to see it or not. no it would not show. pretty much any not directly supported bus would now show in PBD diagram > But i see that the wrapper is connected to the opb bus as a slave. > > The other question that i have is how to built a edk-core compatible with > verilog file ? both verilog and vhdl can be used, VHDL support in EDK is a bit better but verilog is useable too AnttiArticle: 79213
Jonathan Dumaresq wrote: > yes i con buit it too.. > > > When I look at the system.pbd, I expected to to see a new bus for the wb. > But i did'nt see it. I don't know if we need to see it or not. No you won't see a new bus. This wrapper just export all wishbone bus signals as port. Then you need to connect them manually. > But i see that the wrapper is connected to the opb bus as a slave. Yes, the opb2wb wrapper translate OPB access to WishBone access. So it's an OPB Slave and a WishBone master. > The other question that i have is how to built a edk-core compatible with > verilog file ? > > As i can see ther is only the vhdl file that can be use to make an edk core > compitible. > > so if anyone have any idea of what we have to do to plug a simple wishbone > GPIO connected to opbbus via the wrapper.... Just use the wizard and you can use a verilog design. But AFAIK, you can't easily use a mixed verilog/vhdl ... SylvainArticle: 79214
> Wow - all I can say, is I am looking forward to the March numbers, and > EPE v2.2 ! Hey, if we get another 45% next month, I too will be happy :-) Wouldn't count on it though. > Point to ponder: Given the real 'hot button' that power has become, > and the huge commercial pressure to 'work the numbers', does that mean > the margins are being eroded. Nope. The numbers are still conservative. Just when we don't have data we have to be more conservative than when we've measured oodles of chips. > What happens if the next batch of chips > from the foundries (or a different foundry) nudge these finely tuned > numbers upwards ? We publish two sets of data -- Typical and Worst-Case. Typical reflect where the process is targetted. The actual "typical" value for a given lot varies, but the median over all chips we ever ship should be around the typical value. We don't plan on changing our process targets. The worst-case numbers are much trickier. We need to set them to a limit that we guarentee such that we don't kill our yields and at the same time don't leave too much on the table. That's part of why it takes so long to come up with the worst-case numbers. We have to have a real handle on the process to make the call. > Will we see power-bin devices, like we now see Speed-Bin ones, or will > prices increase as vendors take the yield hit, > or will the EPE v2.71.201 simply quietly change the numbers, and > designers find they have to enter the date code of the devices as well ? :) Hopefully none of the above. But only time will tell. Paul Leventis Altera Corp.Article: 79215
You should be able to get better than 160 MHz from a 19 bit counter
using the carry chain in spartan3. I am assuming you tried to implement
it, and are getting poor results. Look at the implementation (ie, what
the synthesis actually produced). The counter should be one layer of
logic, and any controls, especially controls leading into the carry
chain, should come from a flip flop without going through any
combinatorial logic other than the LUT for the carry chain. A common
pitfall is with the expression of either a reset or load signal. If you
have a synchronous reset you can't also have an asynch reset without
forcing to two layers (unless you are clever about the implementation,
which the tools generally are not). Likewise, a load signal coded as an
if then else will infer a mux between the carry chain and flip-flops.
Even if the implementation is going to two levels, you may still be able
to get 100MHz with a little bit of floorplanning. The automatic
placement is notoriously bad at placing a second level of logic. Would
probably help if you'd post your code.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 79216
Ray Andraka wrote:
> Likewise, a load signal coded as an
> if then else will infer a mux between the carry chain and flip-flops.
> Even if the implementation is going to two levels, you may still be able
> to get 100MHz with a little bit of floorplanning. The automatic
> placement is notoriously bad at placing a second level of logic. Would
> probably help if you'd post your code.
What's the preferred style for counters then? It sounds like this is
suboptimal:
reg [N:0] counter;
always @(posedge clk)
if (reset || count == MAX) // Assuming a non-power of 2
counter <= 0;
else
counter <= counter + 1;
It really like to see the preferred style with manual placement for both
Xilinx and Altera.
Thanks,
Tommy
Article: 79217The example 'Digital Clock using Multiplexed 7-Segment Display' has VHDL code on how to do the multiplexed seven segment display. The example can be downloaded from: http://www.xilinx.com/s3boards Cheers, Shalin- fpgawizz wrote: > I am trying to understand the working of the multiplexed seven seg. > displays on the xilinx spartan 3 board.the manual does not give me > detailed info. I am trying to write a simple program where I switch a > switch to the on position and it should display "0012" on the displays. > Any suggestions please? > > thanks >Article: 79218
I admit, I had been worried by Altera's press release, which claimed a
47% reduction in static current. Looked like it might severely erode
our advantage. Well, I should not have worried. It was just the usual
Altera marketing flim-flam.
Here are the numbers Altera published for the worst-case 85 degree
static power changes.
> 2S15 increased (!) by 48 %
> 2S30 reduced by 1 %
> 2S60 increased by 4 %
> 2S90 unchanged
> 2S130 decreased by 6 %
> 2S180 decreased by 14 %
It really takes creative marketing to interpret this as a 47%
reduction. :-(
And here is how an otherwise smart and nice guy like Paul L interprets
it:
"Old data was pre-silicon data for many family members. Icc was based
on projections. Turns out the curve is flatter than expected, so
smaller devices have more current than expected and larger devices have
much less current. This is even more evident in the new typical
numbers:
25C 85C
2S15 +63% +10%
2S30 -14% -24%
2S60 -17% -19%
2S90 -31% -28%
2S130 -38% -34%
2S180 -38% -38%
Now, I think I did my math wrong somewhere in here because I know there
is one that decreased by 47%. But you get the idea. "
end of quote.
So, somewhere in this meaningless "25 degree static power" set of
numbers, there might possibly be a hidden 47%, but Paul could not find
it.
Now you know why I detest marketing bullshit. "Lies, Damn Lies, and
Marketing Deceptions"
There was no need to worry...The race is not even close, for Xilinx
beats Altera by a long shot.
To those who listened to our WebSeminar: Thanks for participating.
Peter Alfke, Xilinx Applications
Article: 79219"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:37f40gF5cje20U1@individual.net... > "Brad Smallridge" <bradsmallridge@dslextreme.com> schrieb im Newsbeitrag > news:1114hkl50qr0gc0@corp.supernews.com... > >> What is the best software for post place and route problems? > > NO Post P&R Sim. > > If you have a clean synchronous design, just run a Behavioral sim and let > the static timing analyzer see if you hit the desired clock frequency or > not. No hazzle with Post P&R Sim. > > Regards > Falk > Falk, When I do my behavioral testbenches, I fashion it so I can do a quicky post place and route sanity check of the results against the behavioral simulation. Most of the time, the results match, and all it cost me was running a simulation overnight. I was involved with one design that had a Coregen Async FIFO. One side interfaced with a state machine where the timing analyzer said everything was OK, but did not simulate correctly with a DCM FX clock multiplication value of 3, but sim'd OK with a value of 2. . Also, if the design has multi cycle delay constaints, it might be prudent to cross check it against a post place and route simulation. To each his own. I know one guy that does not even do a behavioral simulation. He says he might do a visual recheck of his HDL design a second time if he is burning it into an OTP part, and he rarely makes a mistake. -Regards NewmanArticle: 79220
A limiting amp should make your sine wave much more square. If limiting amps aren't your thing, a simple external ECL stage cleans up the clocks quite nicely without the expense of a super-fast comparator since you can keep the noise introduced into this stage at very low levels, something you couldn't do with an internal differential input. "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote in message news:curmki$4pa$1@news.dialog.net.pl... > Hello, > > I have a source of extremely stable and clean clock > signal. Its frequency is about 64 MHz. I would like to > use it as the main clock for a Cyclone FPGA chip > (1C6, to be exact). The problem is that the signal > is a sine wave with the amplitude of about 1Vpp. > The exact level is not an issue, I can amplify or attenuate > it appropriately, but the shape bothers me: may I feed > the FPGA clock input with this signal directly? If yes, > then what is the optimal level of the signal? But if this, > unfortunately, is not allowed, then what solution would > you recommend me? > > Best regards > Piotr Wyderski >Article: 79221
Austin, You railed against Altera and your comments on the tool and their parts were obscured by the sheer volume of sarcasm. Maybe if I knew you, I'd take extreme sarcasm as appropriate critique; I just wasn't brought up that way. There are those who believe triple oxide is the way to go. There are those who believe low-K dielectric is golden. There are others in the industry stepping away from low-K because they see a path to 65 nm and beyond without the need for the exotic materials. As with politics and religions, there are data to back up the claims by both camps, not just "I'm right, you're stupid." I find it difficult to ignore "attacks" from any vendor. I've been primarily using Xilinx devices over the last decade having first cut my teeth on the Altera devices. I prefer brand X because of problems I had getting appropriate I/O performance on brand A as little as 5 years ago. For me, brand X was a superior technical solution for my needs. I don't like to see anyone "disrespecting my parts" out of spite nor do I like to see someone in "my camp" producing a virtually useless discourse on how much the competition lies and cheats. If someone believes in their product - or religion, or politics - I don't mind listening to their discourse when it's not offensive. When their message degrades to mud slinging and name calling - as it appeared to be when an Altera marketing VP posted here several months ago - it brings the whole forum down a notch or two. It appears Altera's power estimators have some bugs. It appears Xilinx hasn't published worst-case numbers on all power figures. It appears Triple Oxide is a win for Xilinx. It appears Low-K is a win for Altera. It appears that most marketing messages are more politics and religion than fact. It appears Engineers on both sides of the camp believe their marketing. That's fine. It appears I get annoyed when people turn argumentative for the sake of argument. I've been a hardware engineer at Xerox Corp since '99 - john dot handwork at office dot xerox dot com - and use my home email to limit spam. There's typically no reason for my work email on this forum. I made Telecomm test equipment at TTC (Telecommunications Techniques Corp, now Acterna) in Germantown, Maryland for a dozen years before switching to color laser printers here in Wilsonville, Oregon. FPGAs are my daily work. Thanks for your continued contribution of useful information. I appreciate all the folks on this board that help expand my horizons with respect to FPGA design. I don't want to be sorry about respecting my field. - John Handwork "austin" <austin@xilinx.com> wrote in message news:curnam$baj2@cliff.xsj.xilinx.com... > Well, > > John, the issue is "what is the leakage current of the new 90nm > technology node?". > > Xilinx has claimed (and we think we have proved it) that the use of > triple oxide (basically keeping memory cells and pass gates at 130 nm in > 90nm) gives us both speed, and a 3X leakage advantage. Not to mention > an SEU advantage (we haven't even started on that weakness in the > competition, yet). > > They claim that their simpler process is more cost effective (? where > are the $ quotes ?) and more producable (we are both shipping), and have > similar or better leakage, and better speed. > > These claims are false. Physics is physics. No smoke and mirrors 6 lut > is going to work. > > They may have solved the surge issue, but we have yet to see any parts > where that is true. It is also true they do not make it easy for Xilinx > to buy their parts. We are oblidged to pay for them like any customer, > so there is a fair and level playing field. So we admit we may not > have seen their fixed parts. Have you? > > The engineering community is a group of very well educated professionals > who deserve to know what is going on. Most of them have a sense of > humor, and appreciate the banter, some do not. If you are one who does > not appreciate my postings, please ignore them. > > If you objected to the tone of my posting, I am very sorry: I can't > help it when I see such total nonsense being presented (IMHO). > > If the gentlemanly thing to do is to respond in a "proper" fashion (in > your humble opinion), then I will leave that to others, as I am not > going to live long enough to tolerate such nonsense. Life is far too > precious to me to waste. Perhaps if you knew me better you would > understand. Since you do not, please feel free to ignore me. > > Again, my intent is to say it like it is, and not to gloss over the fine > points, as it is the fine points that leave customers' systems broken > and worthless. > > Let me know what you are objecting to specifically: the truth of the > matter, or the tone I take. I can and do apologize, and I am able to > learn, grow, and change. > > austin@xilinx.com > > Austin > > PS: from the raw message, I can not see exactly where (or who) you are. > I respect that, as I too am inundated with spam, and I understand you > wishing to avoid that. <snip>Article: 79222
"samplify" <awegener@samplify.com> wrote in message
news:1108309348.145280.184230@z14g2000cwz.googlegroups.com...
Announcement
------------
Samplify Systems announces the availability of Samplify for Windows, a
new PC compression application that demonstrates Samplify's unique
lossless and lossy compression capabilities for sampled (numerical)
data, such as samples from A/D (or for D/A) converters. Samplify for
Windows compresses at 10+ Msamp/sec on a 2 GHz Pentium and achieves 2:1
compression on many bandlimited signals, regardless of center
frequency. Samplify for Windows demonstrates the performance of
Samplify's compression engine, which will be available in FPGAs and
DSP chips in 2005.
Samplify for Windows is available for free (full functionality during a
30-day evaluation) and as shareware ($49.95) from
http://www.samplify.com/page8.html.
[BIG SNIP]
Since you've chosen to post this message in comp.arch.embedded, you are
obviously aware that most of us here don't use Windows [in fact most of the
readers of this NG don't even use Intel x86 architecture CPUs] -- you are
aware of it, aren't you???
Anyway, since you've chosen to advertise this in a newsgroup dedicated to a
very large variety of CPU architectures and operating systems, I'd like to
know when you'll have a generic version (preferably source code) available ?
Norm
Article: 79223Brian Davis wrote: > Elder Costa wrote: > >>> There seem to be various typos in those code snippets you posted- >>> did you cut and paste, or re-type them, into your post? >> >> Cut and pasted. >> > > Your attribute example needs underscores in the label name (U_RAM...) > and proper spelling of "lable". O damn!!! I thought you meant the code in the first part of the message. You're right, I typed the bottom code snippet at home but i think office's version was right (I mean no typos). Not sure though. > > Your first example parses & elaborates OK in VHDL-Simili if I fix the > offending semicolon as follows: > > generic ( WRITE_MODE_A : string := "WRITE_FIRST" ; WRITE_MODE_B : > string := "WRITE_FIRST" ); > Yes, I have already fixed this. > > Other suggestions: > > - if you're using unisim.vcomponents, there's no need to redefine the > RAMB16_S2_S4 component here, as it's already defined in the unisim > library > Hum... I followed Xilinx app notes and some of their example code (perhaps some old ones). This kind of code (that is, code that deploys more sofisticated - from a newbie point of view - resources from VHDL such as attributes and generic mapping) is kind of black magic for me. I just tend to follow code examples and perform minor changes needed to solve my problem. In the process I might end not using the language in the best way. Anyway I wiped out the redundant declaration as your suggested. > - if using XST, the last few versions of XST understand generics - > you can just use a generic map without the translate on/off stuff, I had done so. > and skip the attributes. ( See the "Virtex Primitive Support" section > of the XST manual for examples of each method ) Oh my. RTFM is always wise. Still I insist in forgetting it. :-) Too much to learn and just 24h a day. :-) > > - if you still want to use attributes, make sure they match the > generics, or your synth and sim results will differ It turned out using the generic map in the instantiation (after the aforementioned wipe out) worked in simulation and generated the expected result at least as shown by FPGA editor (I played with different write modes just to check it out in both simulation and FPGA editor.) Thanks a lot for your hints. I really appreciated. ElderArticle: 79224
Really, I think nit-picking about an up to number from a press release
is getting kind of old. How many "up to" numbers were in your seminar
today?
I might as well complete the discussion by providing the complete data,
with no more errors (looks best in fixed point font).
Typical Worst-Case
25C 85C 100C 25C 85C 100C
2S15 +64% +10% -5% +63% +42% +43%
2S30 -13% -24% -34% -9% -7% -6%
2S60 -17% -19% -30% -17% 0% +1%
2S90 -31% -29% -38% -32% -3% -2%
2S130 -37% -34% -43% -28% -9% -8%
2S180 -38% -39% -47% -28% -16% -16%
Typical - Median unit of the process (if you sample 100 chips from many
lots, that's the static power you'd see)
Worst-case - The worst unit we could ever ship (highly unlikely; <1%).
Peter, where are the worst-case leakage specs for V4? I would like to
at least be able to quantify how long this "long shot" is that you
refer to above.
Regards,
Paul Leventis
Altera Corp.
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