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
"Paul Leventis (at home)" <paul.leventis@utoronto.ca> wrote in message news:Zf6Wb.13961$Ovt.8380@news04.bloor.is.net.cable.rogers.com... > > If you've data in parallel with > > the valid signal you can pipeline it into the 90MHz clock domain > > one extra time to compensate. > > You can't use this method for more than one signal crossing a clock domain. > There is no guarentee that your control signal (valid_48) and data signals > will arrive at their synchronizers at the exact same moment in time, and > thus you could have some signals sampled before they transition and others > sampled afterwards. This depends on the interface and relationship of the valid_48 signal to the data. You can't say "> You can't use this method for more than one signal crossing a clock domain" without knowing more about the implementation. Nial ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 65951
Maybe you have a bug in your sdram controller. You need to supply a bit more info. if you want some help. :) "Antti" <antti1000@yahoo.com> wrote in message news:%m%Vb.8944$g4.183754@news2.nokia.com... > Hi, > > I've implemented an sdram controller on an fpga (to micron 128 MB memory) > and tested it with a sequence of write and subsequent read bursts. In around > 1 in 5 attempts, the correct read data appears on the dq[31..0] data bus, > otherwise the memory read just returns 0xFFFFFFF. Could someone please give > pointers to why might this be? > > Thanks, > Antti > >Article: 65952
[this is deviating pretty far from FPGAs...] > There are a few benifits of the AMD-64 architecture beyond the 64-bit width > (in general I agree with most of what you've written here - it's a good > explanation). In particular, the larger number of registers is a help in > many types of application. Good point -- I forgot to mention the doubling of the integer and SSE register files. And moving to other 64-bit platforms could bring even more architectural advantages (x86-64 still doesn't have that many registers available), though its sounding like x86-64 is going to be the primary 64-bit architecture (Intel has indicated they plan to release a 64-bit x86-based chip too, though aren't saying if it is same instruction set as Athlon64). > Also, for some types of application, convenient > 64-bit data items can lead to other benifits - for example, povray runs > slightly faster in 64-bit mode than 32-bit mode on an Athlon-64, but more > importantly it runs more accurately, giving finer detail. I don't know > whether this could apply to tools like Quartus (povray deals with > approximations to reality rather than absolute logic), but perhaps it might > have benifits for simulation. I don't think x86-64 brings any additional accuracy to floating-point based code. x87 always had 32-bit and 64-bit floating point available, and internally operates on 80-bit floating point numbers for increased accuracy especially for things like sin(x) function it supports. Intel now encourages programmers (and more importantly, compilers) to use SSE/SSE2 for general floating point computation and hence x86-64 brings no update to the older stack-based floating-point unit. Instead, it adds another 8 128-bit SSE registers to bring the total up to 16. Floating point representations continue to be 64-bit double precesion in x86-64. One way that the move to 64-bit integers can result in improved accuracy is when programs employ fixed-point representations. For example, say I know that some value will vary from 0 to 1. I could represent that value as a 32-bit integer "x", and implicitly know that the actual number is x / 2^32. Programmers used to do this sort of thing a lot back in the 386/486 days when integer operations were significantly faster than floating-point ops. This is less true than it used to be since integer multiplication/division is now handled by the same unit that does floating-point multiplies (well, except in the 90 nm version of the P4). But still there could be some advantage since processors have more integer ALUs than floating-point/SSE ALUs and are generally geared towards processing integer data faster than floating-point data, especially for addition/subtraction/shift operations (since they are needed for addressing in addition to integer math). On the other hand, if you turn all your floating-point into fixed-point, then your floating-point units go unused -- if you kept operations in floating-point, then you can get parallelism inside the cpu with it using integer ALUs at same time as FPU. So the net effect of using fixed-point these days is unclear to me. Anyway, I digress. After digging around a bit in google, it looks to me like povray uses floating-point representations, so I'm not sure why it would be more accurate. Do you have a link I could follow that claims increased accuracy? As for Quartus -- we don't have many cases of approximations which would benefit from increased accuracy. Place and route is a mix of integer and floating point code -- but most floating-point calculations don't need to be terribly precise. Floating point is used (for example) when coming up with a "score" for a given placement choice or to express how badly a signal wants to use a wire during routing. We rarely even need double-precision, since by their nature optimization decisions don't need to be super-precise since you're really just trying to figure out which resource/configuration is better than another. If we got to the point that our cost functions were so good at predicting the right configuration that double-precision round-off was detrimintaly affecting our optimization decisions, I think the CAD optimization problem would be solved :-) For things like post p&r simulation and delay annotation, the accuracy provided by greater-than-double-precision would not be needed since we can't hope to ever model the exact workings the chip to that fine level of accuracy anyway. If we are ps accurate, that's pretty good -- and compared to a critical path of (say) 100 Mhz, that's 1/10000 accuracy, which is easily handled by single-point precision. Of course, I'm glossing over other benefits of increased precisions, such as reducing accumulation of error when adding up many small numbers (like in a post p&r timing sim), but still I doubt double-precision loses steam... Regards, Paul Leventis Altera Corp.Article: 65953
> This depends on the interface and relationship of the > valid_48 signal to the data. > > You can't say "> You can't use this method for more > than one signal crossing a clock domain" without knowing > more about the implementation. I don't know what I was thinking. This was an overly strong statement. Obviously, if the data is guarenteed to be held in a state for the entire duration of valid being asserted (a common way of communication), then it's perfectly safe to sample the data. Ugh. Must wait until all brain cells wake up before posting... Regards, Paul Leventis Altera Corp.Article: 65954
Mike Treseler <tres@fluke.com> wrote in message news:<40254829.5090400@fluke.com>... > Andy Peters wrote: > > > It's great if you have > > a relationship with a distributor, but once they find out that you > > only want to build a handful of prototypes or whatever, they're not > > interested. There has to be a way for the small garage shop guys to > > get parts. > > > try this: http://www.arrow.com/ > (o) Part Description > enter "acex" in the box > click (Search) > > On page two there are qty=1 parts for under $20 you can order Online. > Ground shipping is $8 > > I have never used acex or online ordering, > but it looks like a viable option not requiring > any relationship with a distributor. Actually, Mike, Arrow is pretty good. They have much better prices than DigiKey, even for small quantities, and the online ordering is easy. It's just that I chose a Xilinx CPLD for a project, and Brand X is not in Arrow's line card. In retrospect, the EPM7128AE in 100-pin TQFP would've done the job as well as the XCR3128 in the same package, although the CoolRunner is almost half the (onesy-twosy) price. Too bad the footprints aren't compatible. --aArticle: 65955
bknpk@hotmail.com (pini) wrote in message news:<ca9059d7.0402062200.501f626f@posting.google.com>... > reg [7:0] TYPEFIL_REG=uno; > You can initialize when targeting to synthesis (only for > verification). Use reset instead. My point was that if you don't have a reset, the initialize will fool you. -aArticle: 65956
"John_H" <johnhandwork@mail.com> wrote in message news:<Q1PVb.3$sR4.6932@news-west.eli.net>... > "Steve" <steve41@totalise.co.uk> wrote in message > news:4d3ee211.0402090355.49f7aa40@posting.google.com... > > So Xilinx /do/ fix their prices. Surely this is against competition laws?? > > If Xilinx colluded with other FPGA manufacturers to have a fixed price where > each competitor agrees not to undercut the other, they would be guilty of > price fixing -- this is not the case. There's different forms of price-fixing; collusion with competing companies is one form, like this: http://www.guardian.co.uk/business/story/0,3604,899174,00.html that's not the type of price-fixing I'm on about. This is the kind of price-fixing I'm on about: http://news.bbc.co.uk/1/hi/business/the_company_file/389962.stm which is price-fixing by ordering distributors to charge certain prices or face the consequences, such as loss of the right to sell that car manufacturer's cars or worse trade terms. > When you go to the store to buy > Tostitos (a different form of chips) you often see the price is pre-marked > on the bag - surely this is a form of price fixing! You have to look at each situation within the context in which it is in. Crisps selling in a supermarket are hardly just one of two brands that are available, and I have *never* seen a pre-priced packet of anything in a supermarket that wasn't a decent price, and I used to work in a supermarket. > In reality, this is > setting a suggested price; some stores have a different price sticker on top > of the pre-printed amount. Semiconductor manufacturers provide their > distributors and sales people with price books that give parts and grades > for what is available. There is no harm in this. Better prices can be had, > but only if you TALK with the people involved, either the Xilinx sales folks > or the distributor's sales people. And what volume per annum would TALKING to the people start getting you discounts? 50k per annum or some such ridiculously high figure that start-ups cannot get to? -- SteveArticle: 65957
filippdavid@yahoo.com (filippo) wrote in message news:<18add487.0402071604.6589ebbe@posting.google.com>... > I made a lot of changes: > - split IO_control in two modules : an io buffer (iobuf) and the > contoller (IO_Async) > > always @(negedge NRD) > if (ADDR == 8'b0000_0000)obuf <= {7'b0,rst}; > else if (ADDR == 8'b0000_0001)obuf <= SEL; > else if (ADDR == 8'b0000_0010)obuf <= TYPEFIL; > else if (ADDR == 8'b0000_0100)obuf <= AMPLIF; > else if (ADDR == 8'b0000_1000)obuf <= DIVFRQ; > else if (ADDR == 8'b0001_0000)obuf <= MIN; > else if (ADDR == 8'b0010_0000)obuf <= MAX; > else obuf <= obuf; Use a case statement. Also, there's no reason for the readback mux to be sensitive to an edge of the read enable; it can be purely combinatorial based on the address. Of course, I assume that the address remains valid (and therefore the data being read back remains valid, too) so as to meet hold time requirements on the micro inputs. --aArticle: 65958
"Fredrik" <fredrik_he_lang@hotmail.com> wrote in message news:77a94d51.0402100656.26670ade@posting.google.com... > You have the RTL view in Quartus that will short of do this for you. > RTL means that you will see it at a very basic level, flip-flops, > Luts,muxs and soforth. Alltough the RTL viewer build up a hirachy from > your VHDL files so you are going to see the top enties in the first > view anyhow. This is the only thing I want right now. >I think also some 3:party tools have this features.(simplify?) > This is a new feature as of Quartus2_ver4 so it > might not be avalible in the free version of the tool. I have version 3, so I guess I need to request an upgrade. Thanks.Article: 65959
You can improve the capture from the 48 MHz domain to 90 MHz domain by using both edges of the clock to sample the valid signal. As an alternative use an internal DLL / PLL to multiply the 90 MHz to 180 MHz and use the 180 MHz to increase sampling resolution. The basics of this method are to have enough samples of the valid signal to work out when the data would actually be valid. With this method you going also need a lot of timing or placement constraints to ensure that nothing changes significantly between builds. Also be careful that the mark/space ration of the clock is better than 40:60. Always check that you technology can handle the clock rates. 180 MHz for most recent FPGAs isn't usually too much of an issue. We run some things at double that clock rate. If you are using the both edges approach - sample the valid signal using 2 shift registers, one positive edge, one negative edge. By interleaving the shift registers outputs you can create a signal that you can identify where a edge occurs. For this to work reliably you need to ensure that skew between front end registers is very small. If you have the 180 MHz available make a single double size shift register to get your timing, or edge, timing point. The 180 MHz shift register is also easier to get right. Given your relative clock rates you probably need to sample the data on both edges, or use 180 MHz, and decide afterwards which edge you take the data from. Sounds complicated but it is mostly basic arithmetic. I will try and schedule a article to be put on our TechiTips page but it might be 2 or 3 months before it gets there. John Adair Enterpoint Ltd. This message is the personal opinion of the sender and not that necessarily that of Enterpoint Ltd.. Readers should make their own evaluation of the facts. No responsibility for error or inaccuracy is accepted. "ALuPin" <ALuPin@web.de> wrote in message news:b8a9a7b0.0402100103.2134de7a@posting.google.com... > Hi everybody, > > I have a question concerning the following: > > > The signal 'valid_48' is one clock_cycle (48MHz) high. > Now I want to use it in a clock domain which has a clock of 90MHz. > > How can I synchronize it correctly? > > I have thought of the following: > > > process(Clk_90) > begin > if Reset='1' then > valid_90 <= '0'; > valid_h1 <= '0'; > valid_h2 <= '0'; > > elsif rising_edge(Clk_90) then > > valid_h1 <= valid_48; > valid_h2 <= valid_h1; > valid_90 <= valid_h1 and (not valid_h2); > end if; > end process; > > Are there some problems arising because of the clock-relation factor 48/90 ? > > Thank you very much. > > Kind regards > > AndreArticle: 65960
Steve, If you never ask, you will never know (how many is 'enough'). I had an email from someone on this group, who asked, and was pleased with the result. If you are going to order 25 a month, for the next year, that is a lot more useful information than a single order of 25! Austin Steve wrote: > "John_H" <johnhandwork@mail.com> wrote in message news:<Q1PVb.3$sR4.6932@news-west.eli.net>... > >>"Steve" <steve41@totalise.co.uk> wrote in message >>news:4d3ee211.0402090355.49f7aa40@posting.google.com... >> >>>So Xilinx /do/ fix their prices. Surely this is against competition laws?? >> >>If Xilinx colluded with other FPGA manufacturers to have a fixed price where >>each competitor agrees not to undercut the other, they would be guilty of >>price fixing -- this is not the case. > > > > There's different forms of price-fixing; collusion with competing > companies is one form, like this: > > http://www.guardian.co.uk/business/story/0,3604,899174,00.html > > that's not the type of price-fixing I'm on about. This is the kind of > price-fixing I'm on about: > > http://news.bbc.co.uk/1/hi/business/the_company_file/389962.stm > > which is price-fixing by ordering distributors to charge certain > prices or face the consequences, such as loss of the right to sell > that car manufacturer's cars or worse trade terms. > > > >> When you go to the store to buy >>Tostitos (a different form of chips) you often see the price is pre-marked >>on the bag - surely this is a form of price fixing! > > > > You have to look at each situation within the context in which it is > in. Crisps selling in a supermarket are hardly just one of two brands > that are available, and I have *never* seen a pre-priced packet of > anything in a supermarket that wasn't a decent price, and I used to > work in a supermarket. > > > >>In reality, this is >>setting a suggested price; some stores have a different price sticker on top >>of the pre-printed amount. Semiconductor manufacturers provide their >>distributors and sales people with price books that give parts and grades >>for what is available. There is no harm in this. Better prices can be had, >>but only if you TALK with the people involved, either the Xilinx sales folks >>or the distributor's sales people. > > > > And what volume per annum would TALKING to the people start getting > you discounts? 50k per annum or some such ridiculously high figure > that start-ups cannot get to? > > > -- > SteveArticle: 65961
"Paul Leventis (at home)" <paul.leventis@utoronto.ca> wrote in message news:EC7Wb.15521$Ovt.10005@news04.bloor.is.net.cable.rogers.com... > Ugh. Must wait until all brain cells wake up before posting... You should like here in the UK, then it would already be late afternoon and you'd be well awake. :-) Nial.Article: 65962
Hi, I'm trying to used the primitive ROM128X1 in my design and I want to initialise the attribute INIT of this primitive. This is working fine when I use only one primitive like : ---------------------------- architecture ... component ROM128X1 -- synthesis translate_off generic (INIT : bit_vector := X"128"); -- synthesis translate_on port ( O : out std_ulogic; A0 : in std_ulogic; A1 : in std_ulogic; A2 : in std_ulogic; A3 : in std_ulogic; A4 : in std_ulogic; A5 : in std_ulogic; A6 : in std_ulogic ); end component; attribute INIT : string; attribute INIT of U : label is ".."; begin U : ROM128X1 port map( O => data_out, A0 => addr_in(0), A1 => addr_in(1), A2 => addr_in(2), A3 => addr_in(3), A4 => addr_in(4), A5 => addr_in(5), A6 => addr_in(6) ); end; ---------------------------- but in the case I used a generate statement like : ---------------------------- begin t : for i in 0 to 1 generate U : ROM128X1 port map( O => data_out(i), A0 => addr_in(0), A1 => addr_in(1), A2 => addr_in(2), A3 => addr_in(3), A4 => addr_in(4), A5 => addr_in(5), A6 => addr_in(6) ); end generate; end; --------------------------- what name of instance do I have to use to declare the attributes INIT. ThanksArticle: 65963
Let me blame T.I. for inventing (in the late 'sixties) the stupid name "Hold Time", when we are really talking about the latest possible instant of Set-Up Time. Any D-flip-flop has an extremely tiny timing window (femtoseconds wide), where it takes a snapshot of the D-input and generates either Q or Qbar. The exact position (in time) of this tiny window with respect to the clock edge is a function of processing, temperature and Vcc. The earliest possible position is specified as Set-up-time. The latest possible position is (unfortunarely) specified as Positive Hold Time if it is later than the clock edge, and as Negative Hold Time if it is before the clock edge. It would be so much nicer if we used only one parameter name, and called the two extremes the max and the min value of the set-up time. I lost that battle 30 years ago. It still smarts every time I hear "Hold Time" . :-( Peter Alfke ======================= "Charles B. Cameron" wrote: > > Muzaffer Kal wrote: > > > On 10 Feb 2004 01:32:42 -0800, praveenkn123@yahoo.com (prav) wrote: > > > > > >>What is negative hold time and what does it specify physically? > > > > > > Hold is, as you might know, how long data needs to be stable after the > > edge of the clock. There is nothing tricky about a negative hold value > > which suggests electrons going back in time. It just means that > > internally to the flop, the data has much more delay to the sampler > > than the clock. If you think about how you fix a hold violation, it > > becomes clearer: you add a delay to the data input of the flop. A flop > > with negative hold requirement has some delay added to the data path > > already. > > > In case it's not obvious, the implication of this is that the input signal can change _before_ the flip-flop is clocked. The difference in time between doing this and receiving the clock is the same as the magnitude of the negative hold time. > > Charles B. CameronArticle: 65964
Does anyone know how to utilize MULTAND and CARRY-CHAIN (XOR,MUX) in Lattice XPGA devices ? Regards, Nick.Article: 65966
This is really simple, Capitalism 101: Manufacturer invents and makes part. Uses seval competing distributors to sell the part to the public. Manufacturer optimizes his profit by charging distributor a certain price, and also publishes a pricebook with "Manufacturer Recommended Resale Price" MSRP. Distributor can sell in any quantity and for any price he wants, high or low, but he will try to optimize his profit. Customer will buy at the lowest possible price consistent with the desired level of service and support. This is true for food, shirts, cars, and ICs. For Tiffany's, Nordstrom, Safeway and CostCo. But rest assured that we are seriously looking at ways to improve the plight of the low-volume customer. Some of your complaints did not fall on deaf ears. Peter Alfke =========================== Austin Lesea wrote: > > Steve, > > If you never ask, you will never know (how many is 'enough'). > > I had an email from someone on this group, who asked, and was pleased > with the result. If you are going to order 25 a month, for the next > year, that is a lot more useful information than a single order of 25! > > Austin > > Steve wrote: > > "John_H" <johnhandwork@mail.com> wrote in message news:<Q1PVb.3$sR4.6932@news-west.eli.net>... > > > >>"Steve" <steve41@totalise.co.uk> wrote in message > >>news:4d3ee211.0402090355.49f7aa40@posting.google.com... > >> > >>>So Xilinx /do/ fix their prices. Surely this is against competition laws?? > >> > >>If Xilinx colluded with other FPGA manufacturers to have a fixed price where > >>each competitor agrees not to undercut the other, they would be guilty of > >>price fixing -- this is not the case. > > > > > > > > There's different forms of price-fixing; collusion with competing > > companies is one form, like this: > > > > http://www.guardian.co.uk/business/story/0,3604,899174,00.html > > > > that's not the type of price-fixing I'm on about. This is the kind of > > price-fixing I'm on about: > > > > http://news.bbc.co.uk/1/hi/business/the_company_file/389962.stm > > > > which is price-fixing by ordering distributors to charge certain > > prices or face the consequences, such as loss of the right to sell > > that car manufacturer's cars or worse trade terms. > > > > > > > >> When you go to the store to buy > >>Tostitos (a different form of chips) you often see the price is pre-marked > >>on the bag - surely this is a form of price fixing! > > > > > > > > You have to look at each situation within the context in which it is > > in. Crisps selling in a supermarket are hardly just one of two brands > > that are available, and I have *never* seen a pre-priced packet of > > anything in a supermarket that wasn't a decent price, and I used to > > work in a supermarket. > > > > > > > >>In reality, this is > >>setting a suggested price; some stores have a different price sticker on top > >>of the pre-printed amount. Semiconductor manufacturers provide their > >>distributors and sales people with price books that give parts and grades > >>for what is available. There is no harm in this. Better prices can be had, > >>but only if you TALK with the people involved, either the Xilinx sales folks > >>or the distributor's sales people. > > > > > > > > And what volume per annum would TALKING to the people start getting > > you discounts? 50k per annum or some such ridiculously high figure > > that start-ups cannot get to? > > > > > > -- > > SteveArticle: 65967
Steve wrote: > > "John_H" <johnhandwork@mail.com> wrote in message news:<Q1PVb.3$sR4.6932@news-west.eli.net>... > > In reality, this is > > setting a suggested price; some stores have a different price sticker on top > > of the pre-printed amount. Semiconductor manufacturers provide their > > distributors and sales people with price books that give parts and grades > > for what is available. There is no harm in this. Better prices can be had, > > but only if you TALK with the people involved, either the Xilinx sales folks > > or the distributor's sales people. > > And what volume per annum would TALKING to the people start getting > you discounts? 50k per annum or some such ridiculously high figure > that start-ups cannot get to? I have found that a 1k per year quantity will get you discounts. Actually, I got a decent discount once when I was saying I would buy in lots of 100 and I was quoted a price for 100 per year! That was on an Altera part if I remember correctly. In another case, I was given the qty 50,000 price when I was promising 1k per year. Both Xilinx and Altera have lots of room to discount from the list price. But if you are only buying 100 total, I don't see how the parts cost you will get standard will affect your competitiveness. At low volumes there are much larger costs that dominate your pricing; NRE (design and prototyping), support, even the cost of sales. If you aren't making 1000 or more of something the cost of the parts is not going to break you. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 65969
"Antti" <antti1000@yahoo.com> ha scritto nel messaggio news:%m%Vb.8944$g4.183754@news2.nokia.com... > I've implemented an sdram controller on an fpga (to micron 128 MB memory) > and tested it with a sequence of write and subsequent read bursts. In around > 1 in 5 attempts, the correct read data appears on the dq[31..0] data bus, > otherwise the memory read just returns 0xFFFFFFF. Is there any pattern ? Is it time related ? Did you do a good time budget analysis ? Tried to lower the clock ? Worth trying even if some delays are specified in clock cycles, not time... But, more important: did you simulate your design using the right Micron HDL model ? I found that very very useful. I stressed the controller + sdram model very heavily, with a nice testbench; On hardware, it passed all tests at first shot. Really. Surely I was lucky, but, nevertheless, that was HIGHLY rewarding, and a huge time saver. Samsung also has models online, and I suppose others, too.Article: 65971
In case anyone is interested I posted some results of a new commercial Cyclone/Nios board on altera.openchip.org. http://altera.openchip.org/forum/viewtopic.php?t=4 Basically shows a table of different configurations showing maximum stable clock rates. KenArticle: 65973
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