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
Jon Elson wrote: > > > Uwe Bonnes wrote: > >> Jon Elson <elson@pico-systems.com> wrote: >> ... >> >> >>> Maybe I made a mistake, but this product uses a pretty small FPGA >>> by today's standards. I can get the XC2S50-something-TQ144C for >>> $12, I know how to mount it to a board myself, etc. A number of the >>> newer stuff is in packages I at least am not so sure I can handle. >>> >> >> >> At digikey, a XC3S100E-4TQG144C costs 7.45EUR and is configurable by >> cheap SPI flash... >> >> > Way too small, if I interpret the # of blocks correctly. The XCS30 > has 576 > LUT cells, the XC3S100E has only 240. I don't think you can compare them > exactly, but if I'm interpreting the numbers right, it means that what > fits > snugly in the XCS30 is far away from fitting in the XC3S100E. After checking the data sheet, I see the Spartan 3E CLB has a LOT more resources than the old Spartan. So, it looks like the 3S100E should, indeed, be big enough. And, it's appetite for config bits is not any worse than the 2S50E. So, I guess this choice is still open. The 3S100E is a bit cheaper than the 2S50E, and should stay available from convenient distributors for a while longer. So, I may have to re-think this. I'm pretty sure my scheme for loading the config from a SST serial flash memory would work as well with the 3S100E as on the 2S50E. I have to look into how well that will work on 2.5 V - it may not. JonArticle: 111351
Peter Alfke wrote: > Questions: > Are the 25 MHz and 200 MHz phase-coherent, or is there a drift between > the frequencies? > Does the 8-bit word have a start-bit? > What is the encoding scheme, I suppose NRZ (High=1, Low=0) > Is the data stream continuous? > These questions are somewhat interdependent. > Food for thought...The learning is yours > Peter Alfke Peter, If I understood his original post correctly, the first question is what he was asking of you, as I believe he intends to derive both clocks from the same DCM. The answer is it depends on the set up of the DCM. if you use the clkdv outputs and supply the DCM with 200 MHz (0r 100MHz using the clk2x output), the clocks will be pretty well aligned in most cases. If you use a 25MHz clock and the clkfx to multiply up, the clkfx will exhibit a bit of jitter and the alignment may not be perfect (assuming the Mand D are set for an integer multiplication of the clock). So in an ideal world, you should be able to cross between the domains... However, it would be prudent to treat the clock domain crossings more carefully. Jitter on the input clock can lead to a greater separation between the edges that could get you into trouble (I ran into a case like this when SpartanII was new, where we saw clock jitter on the DLL input result in a large skew - close to 1ns - between the 1x and 2x clocks out of the same DLL, and most of the clock jitter was not visible at the clock input pin because it was getting introduced by many outputs on the same bank as the clock input switching on the same clock edge).Article: 111352
"daver2" <davidroberts@siemens.com> wrote in message news:1162290502.133488.262030@e64g2000cwd.googlegroups.com... > Thanks for the reply. I found your website previously and have it > bookmarked as a reference! > Well, there is nothing stopping two (or more) people from implementing > the AGC in VHDL!!! In my case, lack of time is stopping me doing much at all... It's an interesting project but it isn't as impressive or fun to the layman as something that plays Pong or MP3 files. Any ideas for other programs it could run? Maybe a simple musical program to play "Ground Control to Major Tom" for instance? > I have implemented the DSKY in 'proper' VHDL and this seems to work > beautifully. Cool. I've not explored all the abilities of VHDL yet, just enough to synthesise the logic I want for my projects. > extremely pretty, large, green, 7-segment LED displays I recall the display took up a large percentage of the power. I'd want to use small, high efficiency LEDs to minimise power. I'm sure they could be smaller than the original machine and yet be just as practical.Article: 111353
Ray, some people my have more patience than I do. I just don't like being jerked around with half-cooked questions. I think he has a 25 MHz clock, and wants to recover a 200 MHz bit stream. But after that it's all very murky. On top of all, it's just a mental exercise for him. He has posted 4 times, and we still do not know what he wants... Peter On Nov 1, 4:21 pm, Ray Andraka <r...@andraka.com> wrote: > Peter Alfke wrote: > > Questions: > > Are the 25 MHz and 200 MHz phase-coherent, or is there a drift between > > the frequencies? > > Does the 8-bit word have a start-bit? > > What is the encoding scheme, I suppose NRZ (High=1, Low=0) > > Is the data stream continuous? > > These questions are somewhat interdependent. > > Food for thought...The learning is yours > > Peter AlfkePeter, If I understood his original post correctly, the first question > is what he was asking of you, as I believe he intends to derive both > clocks from the same DCM. > > The answer is it depends on the set up of the DCM. if you use the clkdv > outputs and supply the DCM with 200 MHz (0r 100MHz using the clk2x > output), the clocks will be pretty well aligned in most cases. If you > use a 25MHz clock and the clkfx to multiply up, the clkfx will exhibit a > bit of jitter and the alignment may not be perfect (assuming the Mand D > are set for an integer multiplication of the clock). So in an ideal > world, you should be able to cross between the domains... > > However, it would be prudent to treat the clock domain crossings more > carefully. Jitter on the input clock can lead to a greater separation > between the edges that could get you into trouble (I ran into a case > like this when SpartanII was new, where we saw clock jitter on the DLL > input result in a large skew - close to 1ns - between the 1x and 2x > clocks out of the same DLL, and most of the clock jitter was not visible > at the clock input pin because it was getting introduced by many outputs > on the same bank as the clock input switching on the same clock edge).Article: 111354
The setup: Virtex ( >= 2 ) Dual-port BlockRAM configured with both ports in "Write first" mode. Both ports have the same (global) clock and the same address, with Enable tied high, so they are both always reading. Part 1: Cycle 0- (init value) WE to port A, with DI = 0. Cycle 1- (change value) WE to port A, with DI = 1. Cycle 2- (cycle 1 results) Output A is 1 because it is in write first mode and 1 was written in cycle 1. What is value at output B during cycle 2? a) 0 because port B is not being written to, and reflects the value it would have read if there was no activity on port A. b) 1 because port A is in write first mode, and the activity on port A interferes with port B. c) x Don't do this, the result is indeterminate. Part 2: same as part 1, with A and B switched Cycle 0- (init value) WE to port B, with DI = 0. Cycle 1- (change value) WE to port B, with DI = 1. Cycle 2- Value at output B is 1 because it is in write first mode and 1 was written in cycle 1. What is the value at output A during cycle 2? a) 0 ... b) 1 ... c) x ... I said don't do this!!! I'm hoping the answer to both Part 1 and Part 2 is a), because it simplifies a 2-D 5x5 Gaussian filter I'm putting together (eliminates muxes and registers external to the RAM, and this is going into an already very tight design). Peter tells me c) for both (I think). Meanwhile, XST user guide gives DPRAM inferring VHDL which sims a result of b) for Part 1, and a result of a) for Part 2. My first instinct is to trust Peter, but the fact that the XST user guide gives deterministic code gives me pause. So I put it to the group, hoping someone has actually used this setup and has some definite answer. I'm a day away from coding up a test circuit to find out what the silicon really does, but if anyone knows of anyplace where operation in this scenario might be documented, it would save me a few hours. Thanks all, Just JohnArticle: 111355
"Peter Alfke" <peter@xilinx.com> wrote in message news:1162418895.253069.240680@f16g2000cwb.googlegroups.com... >I remember the birth of the 22V10 (it's an AMD product, not MMI's) > It had the gestation period of an elephant, and it almost killed the > design engineers. Too complicated... > Times have changed. > Peter Alfke Yes, those 'V' parts were pretty versatile (hence the 'V' in 16V8, 22V10) for those of us around at the birth of the 16R4, 16R6 and 16R8 when great thought had to be applied to decide whether an output should be clocked or combinatorial...and if you got it wrong you had to rewire the circuit board to move it to the appropriate pin....well, that and having to remove and pitch the part because it was fuse based one time programmable. KJ...feeling ooooooold now....where's my hot cocoa?Article: 111356
Is there a good reference for the types of IC packages and their effects on SI? ---Matthew Hicks "Symon" <symon_brewer@hotmail.com> wrote in message news:454928a8$1_1@x-privat.org... > <nnn> wrote in message news:4548ffa9_1@mk-nntp-2.news.uk.tiscali.com... >> Is there a flash adc with a plcc package, anything >> above 24MHz minimum sample rate will suit me. >> tnx >> > You know this is comp.arch.fpga, right? ;-) > > Anyway, go search for yourself :- http://www.interfacebus.com/ > > I doubt anyone would make a high speed ADC in a PLCC package, this type of > package has awful SI properties. > > HTH, Syms. >Article: 111357
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1162345630.497517.281500@h48g2000cwc.googlegroups.com... > KJ, You like standards. > We just finished implementing PCIexpress. When I look at the complexity > of that standard, I just cringe. I cannot fathom why one needs so much > stuff to communicate data. But then I am old frugal and basic guy who > believes in simplicity. But again, you're probably standards compliant on the physical pin side but what about on the 'other' side? A communication's bridge exists because it connects TWO disparate interfaces, so what is the standard interface that is used internal to the FPGA that you're bridging over to PCIexpress? And I agree with you about frugality. The 'internal to the chip' standard interface should be something robust yet something that when used in simple comm situations reduces down (via the magic of synthesis logic optomization) to something darn close to the bare minimum. Certainly there are cases where anything over the bare minimum might be too much, but those tend to be exceptions (i.e. relatively small logic that can be hand optomized in the grand scheme of the entire FPGA design). > Talking about a FIFO, what other standard interface do you want, except > data-in, data-out, 2 clocks, 2 enables, 4 flags and perhaps a reset? > Isn't that about as generic as it can get? Why would Altera do it > differently, except that they don't have a hard-coded 550 MHz one... OK, let's discuss the fifo. Specifically let's take the EIA standard lpm_fifo. That entity defines the input for a hunk-o-code that implements a fifo. If I instantiate an lpm_fifo and target that to the appropriate Xilinx part will I get that 550 MHz performance? If so, then you've provided an example of where standardizing on the interface is a 'good' thing. If not, then can you explain what is so burdensome about the entity definition of lpm_fifo that makes that 550 MHz unachievable? We're not talking about getting extra functionality, we're talking about getting the same function. The synthesis operation, once it saw 'lpm_fifo' and targetting brand X could know that there is a hard coded thingy to implement it....that's what we pay the synthesis tool to do, right? Now granted the 'lpm_fifo' is not necessarily the best and grandest thing to talk about optomizing but you brought up the fifo. Things like controllers come to mind as well (i.e. I2C, DDR, SDRAM, PCI, blah, blah, blah). Many of these are really communication's bridges that hook two different busses together to exchange information. One one side (the physical pin side) we have all the standards, on the other side...well...a bit lacking (IMO) in calling things a standard....and yet things like Wishbone or Avalon or what have you that were all thought through of as being an 'inside the chip' comm bus really do synthesize and logically optomize quite well. After getting over the worry (if there is any) about people jumping ship because their code could now be truly portable to brand A, B, C.... you should also recognize that it would also be a productivity improvement because it would improve code reuse and aid in simply division of labor because you wouldn't have these ad hoc, "let me pass you this signal it will happen two clock cycles before that" type of thing. Perhaps instead of bantering about specific examples that we each seem to think bolster our points you can give us the Xilinx view of - Standardized internal interfaces, good for business? (Xilinx that is) - What standards work for these internal interfaces are you compliant with? - What push for improving these standards are you participating in? In my view this internal interface should scale well (i.e. not get burdensome in wasting logic resources in the synthesized design) if I want to use it inside a VHDL architecture to communicate between processes all the way up to it being an external interface (if I so choose). > I vote for smarter synthesis tool that interprete your intentions in > the best possible way. So do I. KJArticle: 111358
Personally, I would avoid code generators to generate RTL for design. Coding RTL is not a bottleneck for me, even on multi-million gate designs. Some IP is provided by 3rd-party, other IP our developers code. It is fairly easy to write Verilog once you have tried and true coding style. Why would I want to learn a proprietary language to generate a standard language? (and get locked-in?). In addition, I know exactly what hardware I'll generate when I code. For logic circuits that are used often, the HDL addresses that by allowing designers to create modules or primitives. Who knows what a code generator will output. I also wouldn't want to be locked in to a proprietary. System Verilog addresses many of the my department's needs. Even if a big name EDA company were to come out with one, I doubt this type of tool would be purchased. I think if you want to attack something in the area of chip design, you've got to address the parts in the design flow that addresses a company's development bottlenecks such as verification or physical design. "Thomas" <dtsi.india@gmail.com> wrote in message news:1162397407.320469.86740@h48g2000cwc.googlegroups.com... > Generalising the question of this discussion I would like to know what > does the group here think that code generators are worth? > > Say Someone comes out with a code generator which requires some input > data say, D_in and generates a bunch of output code say, C_out. > > Given that C_out is something that you already write for your design > wether the code generator exists or not, when will the code generator > look like a fesible option? > > Given the following man days(Including coding, verfying and debugging > time) for writing D_in and generating C_out VS manual writing of > C_out, what is the price you will be willing to pay for the code > generator in each case? > --------------------------------------------- > Development time in Mandays > --------------------------------------------- > D_in : Manual C_out > --------------------------------------------- > 1 : 10 > 1 : 100 > 1 : 1000 > > If such a code generator appears on the market will your management > wait until a bigname EDA comes out with a me too product or will they > buy it from a noname developer? > Regards > Thomas > > Andy wrote: >> Evan Lavelle wrote: >> > Ok, is it worth any more than $0 now? :) >> >> In a word, no. >> >> Why go to the trouble of learning a new language to try to do things >> like macros, loops, random stimulus, etc. when you have the power of >> the VHDL language at your disposal in a VHDL testbench? Now, if you >> have vectors from an external model/simulation, those can be applied >> with text-io relatively easily from within a vhdl testbench that will >> run on any vhdl simulator. >> >> My "unit level tests" are usually at a high enough level that I need a >> lot more capability than is available in any vector based scripting >> language. >> >> Andy >Article: 111359
"Ben Jones" <ben.jones@xilinx.com> wrote in message news:eia1b7$dfm1@cnn.xsj.xilinx.com... > > "KJ" <Kevin.Jennings@Unisys.com> wrote in message > news:1162320665.907686.101530@h48g2000cwc.googlegroups.com... >> >> Ben Jones wrote: >> >>> There are many problems >>> with wizards and core generators for things like RAMs and arithmetic >>> elements - mostly, they are the wrong level of abstraction for most >>> designs. >> >> Maybe. I find there lack of a standard on the 'internal' side to be >> the bigger issue. > > For the smaller "building block" components, I'd say that's not much of an > issue at all. After all, how many different interfaces can you think of > for an accumulator or shift register? Most of the differences between > vendors seem to be superficial (e.g. naming) at that level. The problem I > have with these low-level blocks is that they go against the basic > principle of abstraction; instead of hiding complex functions behind > simple interfaces, they do the exact opposite. And they hold back > designers by perpetuating the "TTL 7400" design mentality. No, I'm thinking of bigger blocks...the things you wouldn't want to have to write the code for because it is just a sub-function of the overall design. Bridges to SDRAM, DDR, PCI, compression, image processing and security algorithms. Not your simple TTL type of stuff. > >>> they help designers get the most out of the silicon in those cases where >>> synthesis tools are not sophisticated enough to produce optimal results. >> >> I don't believe that a unique entity >> is required in order to produce the optimal silicon. Once the >> synthesis hits a standardized entity name it would know to stop and >> pick up the targetted device's implementation. > > I think that would be great. Of course, vendors' in-house synthesis tools > are unlikely to support that kind of system except for portability between > their own device families. Why not? Once they see the standardized entity called 'ddr_controller' they would instantiate their own hard coded IP algorithm for talking to the bloody thing. I'm not interested in re-inventing the wheel, just in reusing that wheel. >> Tell me what prevents everyone from standardizing on an interface to >> their components in a manner similar to what LPM attempts to do? The >> chip guys do it for their parts, the FPGA vendors don't seem to want to >> do anything similar on the IP core side. > > I don't think anything prevents it, other than whatever all-pervading > force there is in the universe which prevents people from agreeing about > things. :-) But it's not really an all-pervading force. If it were we wouldn't have any standards like PCI, I2C, PCI Express, DDR....on and on and on. So where is the list of interface standards for inside the chip? Wishbone is about it for FPGAs...and it needs some work but it's not bad. So do the big guys all support Wishbone? Build it into their system design tools? Ummmm....well....no....what do they support? Well, here is the Brand A 'standard', brand X standard etc. > > The OpenFPGA initiative have a working group on core interfacing. There's > LPM (obsolete IMHO). There's OCP. There's no shortage of people proposing > ideas for standard interfaces, but there is a shortage of time, money and > energy to do anything about it. I think you'll find most engineers in > favour of standardization to some extent, but there's no one single > driving force for adoption. Some people also see it as a barrier to > innovation. (It isn't, but still, some people see it that way.) I agree > >> Can you list any 'standard' function IP where the code can be portable >> and in fact is portable across FPGA vendors without touching the code? > > No. But I'm willing to bet that any engineer worth their salt would be > able to write the appropriate glue logic to convert one to the other > without working up a sweat. And I'll bet that any engineer worth their salt would also rather not keep re-inventing the wheel and doing needless bus translators. > > In some cases, for example if a customer is using a processor-based system > design environment such as Platform Studio (X) or SOPC builder (A), the > "proprietary" interface to (say) a DDR SDRAM controller is hidden away, to > a great extent, because the tools provide a system-level abstraction. Yes, they all have their own way of making our lives 'easier'....in their minds at least. > > Here's another thought - in many industries (e.g. consumer electronics and > eletricals) the quality of the interface is a big differentiating factor > for the purchaser. Why shouldn't this be true for digital interfacing > standards too? A customer might have a preference for a CoreConnect-based > system over an AMBA-based system, or vice versa, based on which of the > interface's features are relevant to their needs. Choosing a standard based on features and performance that are relevant is exactly the right thing. That's not what you're basing your decision on between 'X' and 'A'. KJArticle: 111360
"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:4qsa4oFoka7cU1@individual.net... > >>> Can you list any 'standard' function IP where the code can be portable >>> and in fact is portable across FPGA vendors without touching the code? > > I can. A synch fifo using one read port and one > write port from an inferred dpram. But you didn't answer the question....reworded to 'What is the name of that standard IP'? lpm_fifo is the only one that I can think of that fits your functional description. Writing the function yourself (while you may want to do it anyway) does not qualify it as a 'standard'. You write good code Mike, but not everything you write is ready to be called a standard ;) KJArticle: 111361
"Peter Alfke" <peter@xilinx.com> wrote in message news:1162418508.842528.165280@k70g2000cwa.googlegroups.com... > Ray Andraka gave the pertinent answer to your question. The rest of us > meandered about... > Peter I was moseying not meandering....and apparently in the mood to spark a discussion KJArticle: 111362
"Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:ulkmv8mwx.fsf@trw.com... > "KJ" <Kevin.Jennings@Unisys.com> writes: > > > More like it was an Altera-driven "standard" that Xilinx never > supported, so it never got to be vendor independent. > But it is a standard issued by a recognized body. But I've yet to hear what is soooo burdensome about LPM that it couldn't be supported...'specially since there aren't that many 'useful' functions in there to begin with. And technically speaking I believe Xilinx 'does' support LPM, but from what I hear, not very well. We should be way beyond standardizing on things as low level as the LPM stuff....but we're not.... KJArticle: 111363
"Ray Andraka" <ray@andraka.com> wrote in message news:wXT1h.25863$v81.58@newsfe18.lga... > KJ, > > This is actually a fairly common usage model for the Xilinx dual port > RAMs. It lets you, for example store two words per clock on one port and > read them one word per clock on the opposite port at perhaps a faster > clock rate. The data width and address width vary inversely so that there > are always 18k or 16K bits in the memory (18K for the widths that <snip> I was misinterpreting the original post as wanting to independently vary address and data widths. Bus resizing for various reasons has many applications, I agree. KJArticle: 111364
The issue is with hard-coded blocks. Soft logic can be changed, manipulated, improved, reduced to your heart's desire. Hard-coded logis is the way it is. If we implement a standard, that's it. Nobody can modify it without seriously affecting performance. If we had not implemented "first-word-fall-through" in the FIFO controller,(we did), it would have been almost impossible to add, without serious performance loss. We do think about these things, but very often there is not "one standard". And if you implement one way, the other method suffers. These designs are not incremental, it is very easy to burn your bridges. And iti srather unlikely that brand A will pick exactly the same size/speed/power/versatility trade-off that we at brand X do. So much for standards. They come with their own bag of trade-offs, usually reduced speed and increased complexity. Very easy to see in memory-related circuits (like FIFOs). We had a self-imposed edict: It has to work at 550 MHz, worst-case at the fastest speed grade. Otherwise we went back to the drawing board. Same thing for the DSP highly-glorified multiplier/accumulators. If you add a 1-ns external gate to a 550 MHz design, the performance drops to 355 MHz. Math is brutal. Very few people like that. Dedicated logic is fast and small, patches are slow and big. That's life. Peter Alfke On Nov 1, 8:02 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Peter Alfke" <a...@sbcglobal.net> wrote in messagenews:1162345630.497517.281500@h48g2000cwc.googlegroups.com...> KJ, You like standards. > > We just finished implementing PCIexpress. When I look at the complexity > > of that standard, I just cringe. I cannot fathom why one needs so much > > stuff to communicate data. But then I am old frugal and basic guy who > > believes in simplicity.But again, you're probably standards compliant on the physical pin side but > what about on the 'other' side? A communication's bridge exists because it > connects TWO disparate interfaces, so what is the standard interface that is > used internal to the FPGA that you're bridging over to PCIexpress? > > And I agree with you about frugality. The 'internal to the chip' standard > interface should be something robust yet something that when used in simple > comm situations reduces down (via the magic of synthesis logic optomization) > to something darn close to the bare minimum. Certainly there are cases > where anything over the bare minimum might be too much, but those tend to be > exceptions (i.e. relatively small logic that can be hand optomized in the > grand scheme of the entire FPGA design). > > > Talking about a FIFO, what other standard interface do you want, except > > data-in, data-out, 2 clocks, 2 enables, 4 flags and perhaps a reset? > > Isn't that about as generic as it can get? Why would Altera do it > > differently, except that they don't have a hard-coded 550 MHz one...OK, let's discuss the fifo. Specifically let's take the EIA standard > lpm_fifo. That entity defines the input for a hunk-o-code that implements a > fifo. If I instantiate an lpm_fifo and target that to the appropriate > Xilinx part will I get that 550 MHz performance? If so, then you've > provided an example of where standardizing on the interface is a 'good' > thing. If not, then can you explain what is so burdensome about the entity > definition of lpm_fifo that makes that 550 MHz unachievable? > > We're not talking about getting extra functionality, we're talking about > getting the same function. The synthesis operation, once it saw 'lpm_fifo' > and targetting brand X could know that there is a hard coded thingy to > implement it....that's what we pay the synthesis tool to do, right? > > Now granted the 'lpm_fifo' is not necessarily the best and grandest thing to > talk about optomizing but you brought up the fifo. Things like controllers > come to mind as well (i.e. I2C, DDR, SDRAM, PCI, blah, blah, blah). Many of > these are really communication's bridges that hook two different busses > together to exchange information. One one side (the physical pin side) we > have all the standards, on the other side...well...a bit lacking (IMO) in > calling things a standard....and yet things like Wishbone or Avalon or what > have you that were all thought through of as being an 'inside the chip' comm > bus really do synthesize and logically optomize quite well. > > After getting over the worry (if there is any) about people jumping ship > because their code could now be truly portable to brand A, B, C.... you > should also recognize that it would also be a productivity improvement > because it would improve code reuse and aid in simply division of labor > because you wouldn't have these ad hoc, "let me pass you this signal it will > happen two clock cycles before that" type of thing. > > Perhaps instead of bantering about specific examples that we each seem to > think bolster our points you can give us the Xilinx view of > - Standardized internal interfaces, good for business? (Xilinx that is) > - What standards work for these internal interfaces are you compliant with? > - What push for improving these standards are you participating in? > > In my view this internal interface should scale well (i.e. not get > burdensome in wasting logic resources in the synthesized design) if I want > to use it inside a VHDL architecture to communicate between processes all > the way up to it being an external interface (if I so choose). > > > I vote for smarter synthesis tool that interprete your intentions in > > the best possible way.So do I. > > KJArticle: 111365
John, as I e-mailed you privately, the Virtex-5 user guide tells you clearly "don't do that". And that same reasoning also applies to the older parts. The two write mechanisms in the two port controllers may be very similar, but they are separate entities, and they may disagree in the timing, pehaps only by picoseconds, but that's enough. In order to do what you want to do, you have to stagger the clocks. BTW: This problem only occurs when both ports use the same address, and one of them writes. Will the other port red the old or the new data? I am convinced that this is really undefined. You may be lucky and it works your way, but I would not bet on it. Peter Alfke On Nov 1, 6:22 pm, "JustJohn" <john.l.sm...@l-3com.com> wrote: > The setup: > Virtex ( >= 2 ) Dual-port BlockRAM configured with both ports in "Write > first" mode. > Both ports have the same (global) clock and the same address, with > Enable tied high, > so they are both always reading. > > Part 1: > Cycle 0- (init value) WE to port A, with DI = 0. > Cycle 1- (change value) WE to port A, with DI = 1. > Cycle 2- (cycle 1 results) Output A is 1 because it is in write first > mode and 1 was written in cycle 1. > What is value at output B during cycle 2? > a) 0 because port B is not being written to, and reflects the value it > would have read if there was no activity on port A. > b) 1 because port A is in write first mode, and the activity on port A > interferes with port B. > c) x Don't do this, the result is indeterminate. > > Part 2: same as part 1, with A and B switched > Cycle 0- (init value) WE to port B, with DI = 0. > Cycle 1- (change value) WE to port B, with DI = 1. > Cycle 2- Value at output B is 1 because it is in write first mode and 1 > was written in cycle 1. > What is the value at output A during cycle 2? > a) 0 ... > b) 1 ... > c) x ... I said don't do this!!! > > I'm hoping the answer to both Part 1 and Part 2 is a), because it > simplifies a 2-D 5x5 Gaussian filter I'm putting together (eliminates > muxes and registers external to the RAM, and this is going into an > already very tight design). > > Peter tells me c) for both (I think). > > Meanwhile, XST user guide gives DPRAM inferring VHDL which sims a > result of b) for Part 1, and a result of a) for Part 2. > > My first instinct is to trust Peter, but the fact that the XST user > guide gives deterministic code gives me pause. > > So I put it to the group, hoping someone has actually used this setup > and has some definite answer. > I'm a day away from coding up a test circuit to find out what the > silicon really does, but if anyone knows of anyplace where operation in > this scenario might be documented, it would save me a few hours. > Thanks all, > Just JohnArticle: 111366
"Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message news:eibouj$d3i$1@news.ks.uiuc.edu... > Is there a good reference for the types of IC packages and their effects > on SI? > > > ---Matthew Hicks > > Hi Matthew, The Amkor website is somewhere to start. For example compare and contrast these two packages:- http://www.amkor.com/Products/all_datasheets/MicroLeadframe.pdf and http://www.amkor.com/Products/all_datasheets/plcc.pdf MLF12 lead inductance ~0.6nH capacitance ~0.2pF PLCC20 lead inductance ~2nH capacitance ~0.6pF HTH, Syms.Article: 111367
Peter Alfke wrote: > John, as I e-mailed you privately, the Virtex-5 user guide tells you > clearly "don't do that". Sorry for my mis-understanding Peter, You said look at the V5 docs, and I didn't. I'll take more time before going to the group next time. > And that same reasoning also applies to the older parts. > The two write mechanisms in the two port controllers may be very > similar, but they are separate entities, and they may disagree in the > timing, pehaps only by picoseconds, but that's enough. > In order to do what you want to do, you have to stagger the clocks. Not possible in this case, the operation has to be symmetric on both ports. > BTW: This problem only occurs when both ports use the same address, and > one of them writes. Yes sir, got that. It turns out that I can re-arrange access ordering to keep the addresses different, operate both ports in read first mode, use the En pins instead of tying them high, still avoid the external muxes/registers, keep the same latency/throughput, and the only overhead is the logic to drive the En pin (<1%). Your comments led me to this solution, thank you! > Will the other port red the old or the new data? I am convinced that > this is really undefined. > You may be lucky and it works your way, but I would not bet on it. > Peter Alfke > What threw me was that the XST DPRAM inference code simulated predictably, in a manner that was inconsistent with the actual circuitry. The whole point of synthesis from simulated code is that the results match. This is one of those cases where they don't. Rare, but it happens. Thanks again for your time, and for bumping me back onto the right path. John L. Smith > > On Nov 1, 6:22 pm, "JustJohn" <john.l.sm...@l-3com.com> wrote: > > The setup: > > Virtex ( >= 2 ) Dual-port BlockRAM configured with both ports in "Write > > first" mode. > > Both ports have the same (global) clock and the same address, with > > Enable tied high, > > so they are both always reading. > > > > Part 1: > > Cycle 0- (init value) WE to port A, with DI = 0. > > Cycle 1- (change value) WE to port A, with DI = 1. > > Cycle 2- (cycle 1 results) Output A is 1 because it is in write first > > mode and 1 was written in cycle 1. > > What is value at output B during cycle 2? > > a) 0 because port B is not being written to, and reflects the value it > > would have read if there was no activity on port A. > > b) 1 because port A is in write first mode, and the activity on port A > > interferes with port B. > > c) x Don't do this, the result is indeterminate. > > > > Part 2: same as part 1, with A and B switched > > Cycle 0- (init value) WE to port B, with DI = 0. > > Cycle 1- (change value) WE to port B, with DI = 1. > > Cycle 2- Value at output B is 1 because it is in write first mode and 1 > > was written in cycle 1. > > What is the value at output A during cycle 2? > > a) 0 ... > > b) 1 ... > > c) x ... I said don't do this!!! > > > > I'm hoping the answer to both Part 1 and Part 2 is a), because it > > simplifies a 2-D 5x5 Gaussian filter I'm putting together (eliminates > > muxes and registers external to the RAM, and this is going into an > > already very tight design). > > > > Peter tells me c) for both (I think). > > > > Meanwhile, XST user guide gives DPRAM inferring VHDL which sims a > > result of b) for Part 1, and a result of a) for Part 2. > > > > My first instinct is to trust Peter, but the fact that the XST user > > guide gives deterministic code gives me pause. > > > > So I put it to the group, hoping someone has actually used this setup > > and has some definite answer. > > I'm a day away from coding up a test circuit to find out what the > > silicon really does, but if anyone knows of anyplace where operation in > > this scenario might be documented, it would save me a few hours. > > Thanks all, > > Just JohnArticle: 111368
Peter Alfke wrote: > There is a difference, 60 years ago, a curious kid could at least try > to understand the world around him/her. > Clocks, carburators, telephones, radios, typewriters, etc. In a talk at the Computer History Museum that Gordon Moore gave on the history of Moore's Law, he was asked about what influenced his interest in science. His answer included playing with chemistry sets and blowing things up. He was later asked about the some of reasons for the decline in US science education. His answer was that nowadays kids couldn't buy "real" chemistry set and blow things up. IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-MArticle: 111369
Thanks for your response, Peter! My favorite carry handling would be a solution with which I don't need to leave the dedicated silicon to save on additional register (and latency) stages which would be necessary to keep the high frequency constraint (500MHz). Additional latency would delay the next computation of a 32bit chunk significantly demanding for a much higher cycle count for the entire 256bit addition. Do you have a good idea how I can pass on the 33rd carry bit (or upper bit if sign extended) between the computations and DSP slices without using the fabric? It would be so easy, if the P[47]/PCIN[47] carry logic wouldn't be inverted...but an inverted carry is probably quite useless for my desire. BTW: what is the reason for the inverted P[47] carry logic? Thanks again ;-) Tim Peter Alfke schrieb: > If you are adding 32 bits, can't you just use the next higher sum bit > as carry? > Maybe that's too obvious... > Peter Alfke > > On Oct 31, 1:13 am, "Tim" <guene...@crypto.rub.de> wrote: > > Hi there, > > > > I am working on a high-speed (500 MHz, Virtex 4, speedgrade -12) and > > multi-precision adder (unsigned) capable to compute 256 bit additions > > using the DSP48 slices. I am using a sequential adder design, thus > > passing a chunk with the lowest bits to a DSP adder slice fist (each > > chunk is only 32 bit for internal reasons), continuing up to the > > highest bits of the input computing a 32 bit result each clock. When > > implementing the carry logic between the chunks, I just came across > > with its funny realization in the DSP slice. You can either use the > > fabric to determine the carry yourself (1) or use the inverted MSB from > > the output P[47]/PCIN[47] (2). Using the fabric (1) for carry > > implementation requires the additional CARRY_IN register to preserve > > the maximum clocking speed of 500MHz making it necessary to wait for > > the carry until the computation of the next chunk can start. Option (2) > > seems not to be applicable to my problem due to the inverted carry > > signal which is useless for my scenario. Does anybody have a good > > solution to this? > > > > Thanks already in advance! > > Cheers, TimArticle: 111370
Hi, MikeD schrieb: > Does anyone know of something more like a "how to" or real design > guidelines for designing rad-hard systems, for system/board-level (ADC, > DAC, power supplies, etc) design, as well as for FPGA and ASIC > hardware? For systemlevel actually no free available howtos, sorry. For FPGA/ASIC, you get information on the websites of the vendors. > were saying. I know that for an FPGA, I should either use a flash or > antifuse based chip, or otherwise use a chip with configuration CRC You will typically have a client, when developing a radhard circuit. First read the requirements from your client. It's a big difference, if your circuit is designed for a mission on Mars or if you need to build equipment intended to be active for 15 years in GEO. In general it could be said, that only fuse based fpgas are acceptable for the second scenario, while you could achieve the first with nearly every fpga. The easiest way to achieve a rad hard fpga design is by using an Actel RT device with a "normal" rtl code. Your design should be bullet proof against deadlocks occuring due to any SEU, which is a good advice for every design, but a necessary condition to sell a rad hard device. > checking and reloading, but how do I select parts like power supplies, > ADC/DACs, and RAMs? Even if my FPGA or ASIC design is solid, I'm > worried that I'm going to end up shooting myself in the foot on the > rest of the system. Again depending on your requirements. Do you need only to be rad-hard against a total dose? Then search devices with given total dose and check wheter this device matches the required total dose. Do you need to be stable against SEE? Thats a bit harder. If you purchase rad-hard devices, you will get a lot of information regarding behavior of this device under radiation. You have to read, understand and verify, that your system accepts this behavior for each devices. E.g a OPAmp might have a transient after hit from a heavy ion, if this opamp feeds your reset circuitry, than you have to deal with this transient by: 1. selling it as a feature 2. removing any unintended influence of this transient Your client will likely accept a shortterm loss of data, but can't accept a loss of equipment. bye ThomasArticle: 111371
Hi everybody, I need to simulate VHDL code using the ISE 8.2i Webpack on Linux. After some investigation, I found out that two simulators were available: - ModelSim, which I have some experience with, would cover all my needs, but the ModelSim Xilinx Starter edition only runs under Windows. - ISE Simulator, which is pretty much unusable from what I've seen so far. The simulation is not interactive (although I could live with that), but I haven't been able to watch internal signal values. It seems only the entity ports can be displayed, which makes debugging much more difficult. Is there any proper simulation solution for the Linux platform ? I know ModelSim has a Linux version, but that's way too expensive for personal projects. Is there any way to run ModelSim Xilinx Starter edition under Linux ? I tried running it in Wine, but it complained about not being able to checkout a valid license, even though the flexlm diagnosis tool reports no problem at all. Any help would be appreciated. Developing VHDL code without a simulator is near to impossible. Best regards, Laurent PinchartArticle: 111372
I am very happy with ghdl, i almost use only that. Also for the post trans/map/p&r simulations. Laurent Pinchart ha scritto: > Hi everybody, > > I need to simulate VHDL code using the ISE 8.2i Webpack on Linux. After some > investigation, I found out that two simulators were available: > > - ModelSim, which I have some experience with, would cover all my needs, but > the ModelSim Xilinx Starter edition only runs under Windows. > > - ISE Simulator, which is pretty much unusable from what I've seen so far. > The simulation is not interactive (although I could live with that), but I > haven't been able to watch internal signal values. It seems only the entity > ports can be displayed, which makes debugging much more difficult. > > Is there any proper simulation solution for the Linux platform ? I know > ModelSim has a Linux version, but that's way too expensive for personal > projects. Is there any way to run ModelSim Xilinx Starter edition under > Linux ? I tried running it in Wine, but it complained about not being able > to checkout a valid license, even though the flexlm diagnosis tool reports > no problem at all. > > Any help would be appreciated. Developing VHDL code without a simulator is > near to impossible. > > Best regards, > > Laurent Pinchart >Article: 111373
On Thu, 02 Nov 2006 03:26:14 GMT, "KJ" <kkjennings@sbcglobal.net> wrote: >"Peter Alfke" <peter@xilinx.com> wrote in message >news:1162418895.253069.240680@f16g2000cwb.googlegroups.com... >>I remember the birth of the 22V10 (it's an AMD product, not MMI's) >> It had the gestation period of an elephant, and it almost killed the >> design engineers. Too complicated... >> Times have changed. >> Peter Alfke > >Yes, those 'V' parts were pretty versatile (hence the 'V' in 16V8, 22V10) >for those of us around at the birth of the 16R4, 16R6 and 16R8 when great >thought had to be applied to decide whether an output should be clocked or >combinatorial...and if you got it wrong you had to rewire the circuit board >to move it to the appropriate pin....well, that and having to remove and >pitch the part because it was fuse based one time programmable. > >KJ...feeling ooooooold now....where's my hot cocoa? Does he take sugar? Me too. The olde original PAL assembler was in FORTRAN, and MMI would give away the source code - it was only a few hundred lines of code, back in the days when PAL16R8s were high-tech. Two separate FORTRAN programs, one for the 20-pin and one for the 24-pin parts. I remember fixing a bug in the 24-pin version, but sadly I've lost all those old 9-track magtapes with the files on them... My VAX DCL script to drive the Data I/O device programmer was almost as long as the PAL assembler! As Ray said, those PALs revolutionized what we could do - as an engineer working for a struggling startup, I couldn't believe my luck. The amazing thing is that we engineers have gone on being at least that lucky, consistently, for the 25 years since then. Betcha the source code for ISE don't fit in a single ring binder, though :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 111374
"KJ" <kkjennings@sbcglobal.net> writes: > "Martin Thompson" <martin.j.thompson@trw.com> wrote in message > news:ulkmv8mwx.fsf@trw.com... > > "KJ" <Kevin.Jennings@Unisys.com> writes: > > > > > > More like it was an Altera-driven "standard" that Xilinx never > > supported, so it never got to be vendor independent. > > > But it is a standard issued by a recognized body. But I've yet to hear what > is soooo burdensome about LPM that it couldn't be supported...'specially > since there aren't that many 'useful' functions in there to begin > with. That's true - my *impression* at the time (which was around 2000) was that Xilinx didn't want to make migration between vendors too easy. That's just my impression mind, I don't know what actually went on. Based on what I read around the LPM website. > And technically speaking I believe Xilinx 'does' support LPM, but > from what I hear, not very well. > That's interesting - any idea how? > We should be way beyond standardizing on things as low level as the LPM > stuff....but we're not.... > In some ways we are - I've never instantiated an LPM_COUNTER, an incrementing variable does the job for me :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
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