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
Chip Designing Made easy To Understand the "World of Miniaturization" and Appreciate the "Art of Chip Design" a senior citizen in the field of Chip Design Industy Shares his Design Expertise. Explains to Understand in a Birds Eye View point analogy of VLSI Chip Architecture with an Building Construction Architecture, Detailed VLSI Chip Design Flow, Enables Architectural Discussions and Thoughts in Us, by querying ourselves if we are playing a role of a Chief Architect, Best Design Practices in Front end & Backend world, Discusses Todays hot topics and design issues, Checklists and lessons learnt, Learn the concepts of chip designing by visiting for free http://www.vlsichipdesign.com/knowledgehome.html I found this link, http://www.microchip.com/wiki/Article: 123651
On Aug 30, 2:19 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > siliconbluetechnol...@yahoo.com wrote: > > Hello, > > > Silicon Blue Technologies is an FPGA startup located in Sunnyvale CA. > > The FPGA product it is developing has ultra low power consumption and > > is targeted to low power applications. > > > The company is seeking some commercial designs in the form of Verilog > > and/or VHDL designs to test its software and FPGA architecture. > > > Please provide your input if you are interested in the product or have > > testcases which can be useful to test both FPGA hardware and software > > capabilities. > > > Thank you. > > > Silicon Blue Technologies > >http://www.siliconbluetech.com > > This is a little light on information. > No mention of size/pincount of the FPGAs, so no one knows if their > app is too small, or too large. > > There are plenty of Open Source designs out there, so why not grab > a USB core, an Ethernet core, and a 32 Bit uC core (Mico32?), > and then run up a power prediction on that and compare it with > both other RAM FPGAs, and also devices like > Atmel's Mid-volume CAP7/CAP9 series, and higher volume Microcontrollers. > > I did see this news : ["QuickLogic Corp. is backing away from the FPGA > market, saying it will instead focus on an ASSP-like sector called > customer specific standard products (CSSPs)"] > > -jg- Hide quoted text - > > - Show quoted text - The company is seeking some designs in the range of 100 k gates and 200 I/OsArticle: 123652
On Aug 31, 8:52 pm, PeteS <axk...@dsl.pipex.com> wrote: > vasile wrote: > > On Aug 29, 5:50 pm, PeteS <axk...@dsl.pipex.com> wrote: > >> Gabor wrote: > >>> On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote: > >>>> The spec says all _transmitters_ shall be AC coupled. You just lead the > >>>> RX line directly to your component. > >>>> In terms of your a) b) c) options, the answer is therefore c) but only > >>>> the TX line(s). > >>>> By the way as far as I remember, there is some Intel doc recommending > >>>> placing the cap at 1/3 of the distance from plug to component (i.e. > >>>> closer to the plug than to the component). > >>> Also if you're designing a PCIe plug-in card, remember that the signal > >>> names on the connector are based on the motherboard. So you need to > >>> connect your transmitter to the receive signals (PERP0/PERN0 ...) and > >>> your receiver to the transmit signals (PETP0/PETN0 ...). Since the Rx > >>> and Tx signals are on the opposite board surface, it is very hard to > >>> correct swapped signals using wires! I got bit by this on my first > >>> PCIe design. > >> It is very important to make sure your coupling capacitor is large > >> enough to handle the 30kHz beacons, so *if* (as I do on occasion) you ac > >> couple at _each end of the link_, make sure you used double the > >> recommended value of capacitor if it's a short (in the transmission line > >> sense) link. > > > This is new for me. What do you mean with 30KHz beacon at 3.1Gbps ? > > The 0.1uF impedance is large enough for a Ghz signal. > > PCIe (as with most high speed links) uses beacon signals to determine if > the 'other end' of the link is active. That beacon is a relatively low > frequency pulse to minimise EMC/EMI. 0.1uF is easily sufficient, but at > 2.5Gb/s (1.25GHz fundamental) a 100pF cap would be sufficient - the cap > recommended in the PCIe spec (you do have a copy right?) is sufficient > for the beaconing. (I don't have a copy in front of me, but I seem to > remember it's 0.075uF). > > Cheers > > PeteS .075uF (75nF) is the minimum spec. There is also a maximum of 0.2uF (200nF) so theoretically 0.1uF -25/+100 % is good. Z5U or Y5U bypass quality caps won't give you this tolerance. X7R or X5R will. The 1.1 specification talks about 0603 components, but I would think 0402 would work better.Article: 123653
Is this a legitimate post? It comes across as an intelligent phrase generator that has some sense of electronics but in general the phrases don't come across as cohesive concepts. If it is legit, robin, please consider what you're trying to communicate. Maybe rereading the post will make you realize your phrasing leaves too much to the readers' imagination. "robin" <robinhood143@gmail.com> wrote in message news:1188589451.821393.49110@i38g2000prf.googlegroups.com... > Chip Designing Made easy To Understand the "World of Miniaturization" > and Appreciate the "Art of Chip Design" a senior citizen in the field > of Chip Design Industy Shares his Design Expertise. > > Explains to Understand in a Birds Eye View point analogy of VLSI Chip > Architecture with an Building Construction Architecture, Detailed VLSI > Chip Design Flow, Enables Architectural Discussions and Thoughts in > Us, by querying ourselves if we are playing a role of a Chief > Architect, Best Design Practices in Front end & Backend world, > Discusses Todays hot topics and design issues, Checklists and lessons > learnt, > > Learn the concepts of chip designing by visiting for free > http://www.vlsichipdesign.com/knowledgehome.html > > I found this link, > http://www.microchip.com/wiki/ >Article: 123654
There are many sorts of engineers in the world. There is no problem in my posting. Be ignorant instead of posting these offensive jokes.Article: 123655
"PeteS" <axkz70@dsl.pipex.com> wrote in message news:A_ydnSr8fcvE7kXbnZ2dnUVZ8sqjnZ2d@pipex.net... > John_H wrote: <snip> >> Thanks to everyone for devining what PeteS means. >> I understand skin effect. >> I understand the confinement of return current for high frequencies. >> I don't understand the statement that "there is no such thing as >> 'ground'." >> >> I was hoping Pete could conjecture what Pete meant. >> >> - John_H > > Hi John > > Let's first define what 'ground' means. For power, it's the 'zero > potential' path for return currents. For RF radiation, it's literally the > ground (where we get the name) which has a nominal '0' potential. > > For high speed signalling, there isn't really a thing that has zero > potential across it's length, be it signal or reference. The return > currents in a nominal ground plane for high speed returns will induce > significant potential gradients across the plane. As a 'ground plane' is > usually used as a description of an area of equipotential, the term ceases > to have meaning when it is no longer equipotential - as is the case when > it is a high speed signal reference/return path. > > That's really what I mean by the comment that at high speeds, ground > doesn't really exist. > > Cheers > > PeteS The fact that return current is confined tightly around the signal for high frequencies doesn't make the ground plane cease to be nearly equipotential. The confined return current will not raise the voltage of the ground plane significantly but instead flow the current through a low impedance path due to any induced voltage. If the voltage changes under the high frequency trace due to the return current and the finite HF plane impedance, the current will flow out around that area to the lower potential - a voltage difference on a ground plane doesn't last long; this is why the return current path is several widths of the distance to the conductor above. If the ground reference were not a ground but a strip that was the same width we identified for the return current, the characteristics would probably be a bit different since the voltage difference from under the signal to the edge of this region isn't tied down to the same potential as the rest of a plane, but isolated. Current and voltage are two parts of the power flow. Impedance (resistance, capacitance, inductance) affects the overall picture. The confinement of the return path the way we've defined it is because of the planes - because of the impedances involved - in addition to the other high frequency issues such as skin depth. I'd love to see the difference between a plane reference and a strip reference that *should* contain the entire return current. It may be the two solutions are the same. But it may present very different results. I haven't done studies on the return current issue, but my gut says that if we ditch the ground plane, the assumptions we make at high frequency also go out the window. - John_HArticle: 123656
> Adam, [sic] > I don't dispute your claim that if mutually exclusive group is > declared, they have their advantages over 'orif'. In my paper in 2002, > I declared two methods, one for 'orif', another for keyword > 'Exclusive' to declare not only a group of signals, but a group of > state machines. At that time, I knew both had their own advantages in > different situations. I tend to prefer one method over two, as long as the one method handles every situation that the second method does, and already exists within the syntax of the language. If I write a zero_one_hot() function today, and use it in my code, there is not a single tool out there that will fail on it. Synthesis tools may not yet know how to use it, but they'll just ignore it and go on. On the other hand, if I put 'orif' in any of my code, then every tool (editor, simulator, formal analyzer, synthesis, etc.) I use it on will have to be updated to accept it, or they will error out. That takes a lot longer to happen, and no tool can effectively support it until most/all tools do. That would be acceptable if a keyword/statement change were the only effective way to get the capability we desire, but it's not. > > Now the problems are: > 1. Jim's method uses assertion function(); Why don't we use attribute? > No precedent example can be found by using a assertion function() > structure to transfer information to VHDL compiler. An assertion (psl or native vhdl) is verified during simulation and/or formal analysis. An attribute is a piece of information that is assumed to be true, but not verified. If we used attributes, then there would be no way to determine that we had correctly specified the attribute. > > 2. Including a group mutually exclusive method shouldn't expel another > on-line programming method 'orif'. That is my point !!! Get two > methods and let engineers to determine what best fit their demand. I think the engineers here have spoken (not that this forum is a/the standardization authority); you're just not listening. I'm not in favor of adding a statement/keyword to the language for a purpose that is better served within the bounds of the existing language, when there has been essentially no support for it from anyone except you. > > 3. There are a lot of situations that your variable counter method > fails, but 'orif' method best fits. > > I will re-post my longest 'orif' code segment from my coding to show > you the other alternative way to do the same things. > > Please count how many conditions contained in if() and elsif() whose > equations in any of your project you use loop structure to generate, > and tell me the ratio. > > My ratio is 95/5 in favor of on-line programming. I can tell. > > In my opinion, your mutually exclusive situations should be expected > to have the same ratio. Nope, I use arrays and loops closer to 95% of the time. I hate typing and checking long if/elsif statements to make sure I have the right suffixes matched up. If I find myself using one, I back up and figure out where I went wrong. > > 4. Your coding has a big and fatal problem and never should be used in > any situations like that: > assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'), > (TWindowLoad_E0_H_H and nC_BE_R0(7) = '0'))); > > Why? I will tell you later. Think of it yourselves and you should know > why. Look, I'm not here to play games with you, nor is anyone else. If you see a bug, tell us; we've all got better things to do that wait for you to enlighten us. AndyArticle: 123657
On Aug 30, 6:53 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> And no, the LUTs don't glitch. The LUTs are made
> of a tree of MUXes which select one of sixteen configuration bits. If the
> input EN signal is '0', all the thrashing in the world on the other inputs
> should have no effect, because the EN input guarantees the LUT to be
> selecting a '0' configuration bit.
Hmmm... I gave the LUT as an example of what could go wrong, and now
we have a Xilinx engineer claiming that the LUT doesn't glitch, and
neither of us can find an official confirmation for that in Xilinx'
docs. Which means that nothing stops Xilinx from shipping devices with
a new LUT design, which doesn't have this quality.
Regardless, the next stage is to check whether any possible logic path
combination could glitch, but I have to admit that this sounds a bit
paranoid even in my own terms.
So I suppose I'll leave my extra constraint just to be safe, and in
case it bugs me too much, I could always remember that there are good
excuses to let go...
Thanks for the clarifications. This discussion shed light on issues
which have bothered me for quite some time.
Eli
Article: 123658On Aug 31, 1:32 pm, Pasacco <pasa...@gmail.com> wrote: > There are many sorts of engineers in the world. > There is no problem in my posting. Be ignorant instead of posting > these offensive jokes. Symon was not offensive, and he was not joking. If you don't like the hammer approach, then go to your dentist and have him take an Xray picture of a plastic-packaged FPGA. He has the perfect equipment for that. Serious! You keep asking these weird questions without ever telling us about their relevance. Peter AlfkeArticle: 123659
Dear Peter Please understand that people sometimes find it offensive though they did not mean it. I mentioned that "need to know some technology data, for example, die size and LUT size, in order to compare different designs". Someone who is doing research on different technologies, these data are interesting and relavant, though it is weird for you.Article: 123660
Hi, I would like to create a system like below: uBlaze <=one pair of FSL=> customized IP <=another pair of FSL=> uBlaze Could anyone tell me whether it is possible to do that? Is there any constraint about the number of FSL pairs each customized IP can have? I modified the .mpd by simply duplicating the ports'' names like below. I also duplicated the ports and HDL in IP''s HDL file. Then connecting the system like: uBlaze_0 <=MFSL,SFSL=> customized IP <=M2,S2=> uBlaze_1 Synthesizing, par, generating Bitstream seem to be ok. while I have an error when I wanted to compile hello-world programs on both processors. Could anyone give me some advice that where can be the wrong part? Thanks a lot. David ================================= BEGIN custom_ip ## Peripheral Options OPTION IPTYPE = PERIPHERAL OPTION IMP_NETLIST = TRUE OPTION HDL = VERILOG OPTION CORE_STATE = DEVELOPMENT OPTION IP_GROUP = MICROBLAZE:PPC:USER ## Bus Interfaces BUS_INTERFACE BUS = SFSL, BUS_TYPE = SLAVE, BUS_STD = FSL BUS_INTERFACE BUS = MFSL, BUS_TYPE = MASTER, BUS_STD = FSL BUS_INTERFACE BUS = S2, BUS_TYPE = SLAVE, BUS_STD = FSL BUS_INTERFACE BUS = M2, BUS_TYPE = MASTER, BUS_STD = FSL ## Generics for VHDL or Parameters for Verilog ## Ports PORT FSL_Clk = "", DIR = I, SIGIS = CLK, BUS = SFSL:MFSL PORT FSL_Rst = OPB_Rst, DIR = I, SIGIS = RST, BUS = SFSL:MFSL PORT FSL_S_Clk = FSL_S_Clk, DIR = O, SIGIS = Clk, BUS = SFSL PORT FSL_S_Read = FSL_S_Read, DIR = O, BUS = SFSL PORT FSL_S_Data = FSL_S_Data, DIR = I, VEC = [0:31], BUS = SFSL PORT FSL_S_Control = FSL_S_Control, DIR = I, BUS = MFSL PORT FSL_S_Exists = FSL_S_Exists, DIR = I, BUS = SFSL PORT FSL_M_Clk = FSL_M_Clk, DIR = O, SIGIS = Clk, BUS = MFSL PORT FSL_M_Write = FSL_M_Write, DIR = O, BUS = MFSL PORT FSL_M_Data = FSL_M_Data, DIR = O, VEC = [0:31], BUS = MFSL PORT FSL_M_Control = FSL_M_Control, DIR = O, BUS = MFSL PORT FSL_M_Full = FSL_M_Full, DIR = I, BUS = MFSL PORT FSL_Clk_2 = "", DIR = I, SIGIS = Clk, BUS = S2:M2 PORT FSL_Rst_2 = OPB_Rst, DIR = I, BUS = S2:M2, SIGIS = RST PORT FSL_S_Clk_2 = FSL_S_Clk_2, DIR = O, SIGIS = Clk, BUS = S2 PORT FSL_S_Read_2 = FSL_S_Read_2, DIR = O, BUS = S2 PORT FSL_S_Data_2 = FSL_S_Data_2, DIR = I, VEC = [0:31], BUS = S2 PORT FSL_S_Control_2 = FSL_S_Control_2, DIR = I, BUS = S2 PORT FSL_S_Exists_2 = FSL_S_Exists_2, DIR = I, BUS = S2 PORT FSL_M_Clk_2 = FSL_M_Clk_2, DIR = O, SIGIS = Clk, BUS = M2 PORT FSL_M_Write_2 = FSL_M_Write_2, DIR = O, BUS = M2 PORT FSL_M_Data_2 = FSL_M_Data_2, DIR = O, VEC = [0:31], BUS = M2 PORT FSL_M_Control_2 = FSL_M_Control_2, DIR = O, BUS = M2 PORT FSL_M_Full_2 = FSL_M_Full_2, DIR = I, BUS = M2 ENDArticle: 123661
On Aug 31, 2:29 pm, Pasacco <pasa...@gmail.com> wrote: > Dear Peter > Please understand that people sometimes find it offensive though they > did not mean it. > I mentioned that "need to know some technology data, for example, die > size and LUT size, in order to compare different designs". Someone who > is doing research on different technologies, these data are > interesting and relavant, though it is weird for you. If you had started with something like: "I am doing university research on the relative area efficiency of SRAM-based vs antifuse-based FPGAs..." We would have respected you and tried to help. But just a series of (very) naive questions does not create that same urge to help... Peter Alfke Peter AlfkeArticle: 123662
"Pasacco" <pasacco@gmail.com> wrote in message news:1188595791.717599.11220@k79g2000hse.googlegroups.com... > Dear Peter > Please understand that people sometimes find it offensive though they > did not mean it. > I mentioned that "need to know some technology data, for example, die > size and LUT size, in order to compare different designs". Someone who > is doing research on different technologies, these data are > interesting and relavant, though it is weird for you. It is interesting and relevent to sincerely too few individuals to make this data practical to disseminate by any FPGA manufacturer. To ask "what is the tolerance on the exhaust pipe diameter at bends" might be interesting and relavant to some engineers considerations on exhaust back pressure, but it's really not of interest to virtually any and all automotive engineers, including those designing exhaust systems! You may be asking the wrong question and we're completely unaware of what you are really trying to understand. You ask questions which do not appear to be the least bit relevant to working with FPGAs or even designing them. In your own view, this information may be relevant but we cannot for the world understand why! Your research may be based on assumptions that could be valid when comparing NAND gates to NAND gates but not relevant in the FPGA world. Or maybe it is, but we cannot see it so there's no reason for us to help you pursue senseless pursuits. Unless maybe you can get me those exhaust bend diameter tolerance values. - John_HArticle: 123663
Peter Alfke wrote: > On Aug 31, 1:32 pm, Pasacco <pasa...@gmail.com> wrote: > >>There are many sorts of engineers in the world. >>There is no problem in my posting. Be ignorant instead of posting >>these offensive jokes. > > > Symon was not offensive, and he was not joking. > If you don't like the hammer approach, then go to your dentist and > have him take an Xray picture of a plastic-packaged FPGA. He has the > perfect equipment for that. Serious! > You keep asking these weird questions without ever telling us about > their relevance. Well, he was half-joking :) I mean, sheesh a Hammer, what was Syms thinking! ?! - a better workshop tool is a Vice and a file/grinder. I've done this with quite good results, with the right amount of care in the final material removal stages, the 'wreckage' can tell you quite a lot. I've actually had serious discussions with chip makers, following this 'advanced reverse engineering' :) -jgArticle: 123664
On Aug 31, 1:52 pm, Andy <jonesa...@comcast.net> wrote: > > Adam, [sic] > > I don't dispute your claim that if mutually exclusive group is > > declared, they have their advantages over 'orif'. In my paper in 2002, > > I declared two methods, one for 'orif', another for keyword > > 'Exclusive' to declare not only a group of signals, but a group of > > state machines. At that time, I knew both had their own advantages in > > different situations. > > I tend to prefer one method over two, as long as the one method > handles every situation that the second method does, and already > exists within the syntax of the language. If I write a zero_one_hot() > function today, and use it in my code, there is not a single tool out > there that will fail on it. Synthesis tools may not yet know how to > use it, but they'll just ignore it and go on. On the other hand, if I > put 'orif' in any of my code, then every tool (editor, simulator, > formal analyzer, synthesis, etc.) I use it on will have to be updated > to accept it, or they will error out. That takes a lot longer to > happen, and no tool can effectively support it until most/all tools > do. That would be acceptable if a keyword/statement change were the > only effective way to get the capability we desire, but it's not. > > > > > Now the problems are: > > 1. Jim's method uses assertion function(); Why don't we use attribute? > > No precedent example can be found by using a assertion function() > > structure to transfer information to VHDL compiler. > > An assertion (psl or native vhdl) is verified during simulation and/or > formal analysis. An attribute is a piece of information that is > assumed to be true, but not verified. If we used attributes, then > there would be no way to determine that we had correctly specified the > attribute. > > > > > 2. Including a group mutually exclusive method shouldn't expel another > > on-line programming method 'orif'. That is my point !!! Get two > > methods and let engineers to determine what best fit their demand. > > I think the engineers here have spoken (not that this forum is a/the > standardization authority); you're just not listening. I'm not in > favor of adding a statement/keyword to the language for a purpose that > is better served within the bounds of the existing language, when > there has been essentially no support for it from anyone except you. > > > > > 3. There are a lot of situations that your variable counter method > > fails, but 'orif' method best fits. > > > I will re-post my longest 'orif' code segment from my coding to show > > you the other alternative way to do the same things. > > > Please count how many conditions contained in if() and elsif() whose > > equations in any of your project you use loop structure to generate, > > and tell me the ratio. > > > My ratio is 95/5 in favor of on-line programming. > > I can tell. > > > > > In my opinion, your mutually exclusive situations should be expected > > to have the same ratio. > > Nope, I use arrays and loops closer to 95% of the time. I hate typing > and checking long if/elsif statements to make sure I have the right > suffixes matched up. If I find myself using one, I back up and figure > out where I went wrong. > > > > > 4. Your coding has a big and fatal problem and never should be used in > > any situations like that: > > assert zero_one_hot(((TWindowLoad_E0_L_H and nC_BE_R0(3) = '0'), > > (TWindowLoad_E0_H_H and nC_BE_R0(7) = '0'))); > > > Why? I will tell you later. Think of it yourselves and you should know > > why. > > Look, I'm not here to play games with you, nor is anyone else. If you > see a bug, tell us; we've all got better things to do that wait for > you to enlighten us. > > Andy Andy, 1. Thank you for your response. I learn something very important from you through this topics discussion. 2. Why? Never copy any dynamic code segment to other place. Because code is changing and you have two code copied at two different places. When you change one copy, most of time, you would forget the 2nd copy. The fatal error is a timing bomb, not now. 3. I really don't understand how you reach 95% ratio to use loop to write data bus. For example, a data bus (63-0) loading, you have 5 cases, how can you use loop to implement the code? because each loading condition equations are different. It is unbelievable that you would 1) define a unsigned(4-0) in the definition area; 2) assign each condition to each bit at concurrent area; 3) then do a loop in a sequential area; 4) don't forget assert function(). That is why Verilog introduce unique keyword. Now you favors one over another, it is OK, but it doesn't guarantee that you will never use another alternative method if it is available. All side kick signals, 1 bit each, they are very short, but very important to control data flow, most of them must be written in separate conditional equations, how can you do them in a loop? In one of my designs, there are 2,500 lines for signal definition part, there may be 500 side kick signals, their coding is very short, but most of time the loading is mutually exclusive. It would be very pain to use 3 steps to define mutually exclusive situations if only one definition is used. Thank you. WengArticle: 123665
John_H wrote: > "PeteS" <axkz70@dsl.pipex.com> wrote in message > news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net... > <snip> >> I have a number of pretty pics I made to illustrate the issue. I'll put >> 'em on a.b.s.e tomorrow sometime. >> >> As an aside, at high speeds (which I define as having a track longer than >> 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. The >> ground plane is a signal layer insulated by copper ;) >> [Although it helps to keep large power currents away from the high speed >> return paths]. >> >> Cheers >> >> PeteS > > Since without a ground one has a dipole antenna, could you qualify what you > mean? The impedance of the plane is measured in units of picoHenry per > square so it's not a solid ground, certainly, but without a ground we'd be > in a world of hurt at these high frequencies. > > Wow. Didn't know I would set off such a discussion :) At high speeds, return currents flow virtually exclusively on the reference layer at not much more than the width of the signal track; it also flows only in the skin area, the depth of which depends on a number of things. It won't flow elsewhere [subject to normal current distribution laws] (unless it has to because there is no return path, which was alluded to in the first response) because of the high impedance involved. (At ~4nH / inch there's a high energy barrier, although that value is highly topology dependent). As such, if you have a signal track on a single layer point to point, then the return current will flow immediately adjacent on the nearest reference layer (so make sure it really *is* a reference layer), and for a 6 thou track, the return current will have ~95% in 6 thou on the reference layer. As I said, at high frequencies, the notion of 'ground' as used in power, does not really exist; there are only signals and reference, whatever it happens to be. Cheers PeteSArticle: 123666
On Aug 30, 7:28 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> On 28 Aug., 13:23, Marcus Harnisch <marcus.harni...@gmx.net> wrote:> Weng Tianxiang <wtx...@gmail.com> writes:
>
> Weng, take a step back.
>
> First, not under all circumstances the carry chain implementation is
> the most efficient of the gated OR selector.
> For small number of inputs it fits into a single 6-LUT, for very large
> number of inputs the logarithmic delay of the tree will be better than
> the linear delay of the carry chain, even though the constants for the
> carry chain are better.
>
> Second, the only thing that your orif keyword thos, is a hint to the
> synthesizer that the behaviour is undefined for certain input
> combinations. You restrict the domain of the function. The following
> code has the same semantics:
>
> if E1 + E2 + E3 > 1 then -- (Lazy and incorrect VHDL type handling to
> shorten example, you will get the point)
> result <= (others => '-');
> elsif E1 = '1' then
> result <= input1;
> elsif E2 = '1' then
> result <= input2;
> elsif E3 = '1' then
> result <= input3;
> else
> result <= (others => '0');
> end if;
>
> You will however notice, that most synthesis tools will not utilize
> the optimization potential available from '-'.
> I am often annoyed by this. For example if you write an instruction
> decoder for a CPU, you do not care about the behaviour of the ALU for
> all instructions that use no ALU result. Specifying don't cares would
> greatly reduce the amount of logic for the decoder. This is an
> improvement that is far more versatile than your proposal and it is
> allready in the language.
>
> However most synthesis tools will replace all occurences of '-' with
> '0'. The reason behind this is that verification guys hate don't
> cares. For regression testing you wan't the hardware to behave the
> same if the specification did not change. '-' might be synthesized
> differently every time. For formal verification you definitely can't
> allow the freedom of don't cares.
> In most contexts verification is a far bigger problem then efficient
> implementation.
>
> If you really want the most efficient implemetation you should specify
> the detailed behaviour.
>
> assert (PSL formulation to guarentee mutual exclusiveness goes here);
> result <= (input1 and (result'range => E1) or (input2 and
> (result'range => E2) or (input3 and (result'range => E3);
>
> Telling the synthesis tool to implement wide ORs in carry chains is
> simpler than to introduce a new keyboard.
> This way other uses of wide ORs benefit aswell, as do users of other
> languages.
>
> Kolja Sulimma
>
> P.S.: Xilinx has a patent on implementing a wide OR using carry logic.
> There is no explicit license that grants you the right to distribute
> bitstreams that use that trick. Xilinx says, they do not want to sue
> anybody about that. But I bet Unisys had no intent to sue GIF users in
> the 80ies. But intentions can change. Do you want to bet your business
> on an informal declaration by Austin in a newsgroup?
Hi Kolja,
This topics has two groups of people, one for how to best define
mutually exclusiveness in VHDL, another who don't believe it may
provide any benefits to design.
You are the one of second group.
I would like to repeat a famous English sentence from Altera I learned
when I wan installing Altera software: What you can do, we can do
better.
My opinion is when VHDL compilers get more information about mutually
exclusive information, what you can do, the VHDL compilers can do
better.
VHDL compilers can generate all coding you showed for one level of
mutually exclusiveness. You may not write efficiently for code with
two levels or even three levels of mutually exclusiveness. Personal
power is limited and VHDL compilers can be trained to do more
mechanical things than any human.
-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;
I don't know which VHDL version permits the operation: (E0 and
Data0),
even though It is not a problem here
-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E2 = '1') then
OutBus <= Data2;
orif(E3 = '1') then
OutBus <= Data3;
orif(E4 = '1') then
OutBus <= Data4;
orif(E5 = '1') then
OutBus <= Data5;
else
OutBus <= OutBus;
end if;
end if;
end process;
The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'
It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running
frequency
would drop dramatically and would kill a otherwise successfu design.
LUT is less than a cent in a FPGA.
The above two example show that with mixed 'elsif' and 'orif'
language
branch statement structure, HDL will provide more powerful and
concise
way to deal with mutually ...
You are a doubtor of the technology, Verilog has formally introduced
the technology, and VHDL will follow.
It is a trend.
I prefer writing 'if...end if' statements than your and Jim's coding.
Why? It is really not a VHDL language, but an ASM language and there
are many pains.
I am fighting for an alternative, concise and simple method to do the
same job as Jim has suggested.
Thank you.
Weng
Article: 123667Bob Perlman wrote: > Hi - > > On Fri, 31 Aug 2007 13:38:11 +0100, Brian Drummond > <brian_drummond@btconnect.com> wrote: > >> On Fri, 31 Aug 2007 11:02:13 +0100, "Symon" <symon_brewer@hotmail.com> >> wrote: >> >>> "John_H" <newsgroup@johnhandwork.com> wrote in message >>> news:13de6b5q88e3ke1@corp.supernews.com... >>>> "PeteS" <axkz70@dsl.pipex.com> wrote in message >>>> news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net... >>>> <snip> >>>>> I have a number of pretty pics I made to illustrate the issue. I'll put >>>>> 'em on a.b.s.e tomorrow sometime. >>>>> >>>>> As an aside, at high speeds (which I define as having a track longer than >>>>> 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. The >>>>> ground plane is a signal layer insulated by copper ;) >>>>> [Although it helps to keep large power currents away from the high speed >>>>> return paths]. >>>>> >>>>> Cheers >>>>> >>>>> PeteS >>>> Since without a ground one has a dipole antenna, could you qualify what >>>> you mean? The impedance of the plane is measured in units of picoHenry >>>> per square so it's not a solid ground, certainly, but without a ground >>>> we'd be in a world of hurt at these high frequencies. >>>> >>> I think Pete means that at high frequencies the skin effect means that the >>> current in the plane is all on one surface of the plane. Thus the bulk of >>> the plane might as well be an insulator. Or something like that? >> I think he means the return current is mostly localised directly under >> the signal track; the copper under the "space" between tracks carries >> relatively little current and could *almost* be replaced by insulator. >> >> - Brian > > Seems to me you're both right: the return current is bunched up under > trace, on the side of the ground plane adjacent to the trace. This > "path" is surrounded by copper. To paraphrase Doug Smith, a local EMC > consultant, the other side of the plane might as well be on the moon. > > Bob Perlman > Cambrian Design Works > http://www.cambriandesign.com Absolutely. The other side of the plane doesn't really exist to the return currents. There is some speculation that return currents take the lowest energy state return path, which seems intuitively true, but I'm not sure we have proper evidence for. There is a great deal of misunderstanding in the area of reference layers, planes and high speed signalling in general. When we take a signal through the board, we have to make sure we also take the return path through the board. I spent a long time doing calculations on diff pairs of varying topologies to figure out the optimal via sizes (and spacing, annular ring size etc) to take signals from one layer to another with minimal loss (and therefore minimal radiation). I got the loss down to < 0.3dB / via on a rather dense high speed board. Cheers PeteSArticle: 123668
On Aug 31, 1:08 pm, siliconbluetechnol...@yahoo.com wrote: > On Aug 30, 2:19 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > > > > > siliconbluetechnol...@yahoo.com wrote: > > > Hello, > > > > Silicon Blue Technologies is an FPGA startup located in Sunnyvale CA. > > > The FPGA product it is developing has ultra low power consumption and > > > is targeted to low power applications. > > > > The company is seeking some commercial designs in the form of Verilog > > > and/or VHDL designs to test its software and FPGA architecture. > > > > Please provide your input if you are interested in the product or have > > > testcases which can be useful to test both FPGA hardware and software > > > capabilities. > > > > Thank you. > > > > Silicon Blue Technologies > > >http://www.siliconbluetech.com > > > This is a little light on information. > > No mention of size/pincount of the FPGAs, so no one knows if their > > app is too small, or too large. > > > There are plenty of Open Source designs out there, so why not grab > > a USB core, an Ethernet core, and a 32 Bit uC core (Mico32?), > > and then run up a power prediction on that and compare it with > > both other RAM FPGAs, and also devices like > > Atmel's Mid-volume CAP7/CAP9 series, and higher volume Microcontrollers. > > > I did see this news : ["QuickLogic Corp. is backing away from the FPGA > > market, saying it will instead focus on an ASSP-like sector called > > customer specific standard products (CSSPs)"] > > > -jg- Hide quoted text - > > > - Show quoted text - > > The company is seeking some designs in the range of 100 k gates and > 200 I/Os We release our designs in FPGAs. So all our logic resource usage is in form of LE/LC count. Low power sounds very appealing. Can you provide any more info on the devices, etc?Article: 123669
vasile wrote: > On Aug 29, 5:50 pm, PeteS <axk...@dsl.pipex.com> wrote: >> Gabor wrote: >>> On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote: >>>> The spec says all _transmitters_ shall be AC coupled. You just lead the >>>> RX line directly to your component. >>>> In terms of your a) b) c) options, the answer is therefore c) but only >>>> the TX line(s). >>>> By the way as far as I remember, there is some Intel doc recommending >>>> placing the cap at 1/3 of the distance from plug to component (i.e. >>>> closer to the plug than to the component). >>> Also if you're designing a PCIe plug-in card, remember that the signal >>> names on the connector are based on the motherboard. So you need to >>> connect your transmitter to the receive signals (PERP0/PERN0 ...) and >>> your receiver to the transmit signals (PETP0/PETN0 ...). Since the Rx >>> and Tx signals are on the opposite board surface, it is very hard to >>> correct swapped signals using wires! I got bit by this on my first >>> PCIe design. >> It is very important to make sure your coupling capacitor is large >> enough to handle the 30kHz beacons, so *if* (as I do on occasion) you ac >> couple at _each end of the link_, make sure you used double the >> recommended value of capacitor if it's a short (in the transmission line >> sense) link. > > This is new for me. What do you mean with 30KHz beacon at 3.1Gbps ? > The 0.1uF impedance is large enough for a Ghz signal. > > PCIe (as with most high speed links) uses beacon signals to determine if the 'other end' of the link is active. That beacon is a relatively low frequency pulse to minimise EMC/EMI. 0.1uF is easily sufficient, but at 2.5Gb/s (1.25GHz fundamental) a 100pF cap would be sufficient - the cap recommended in the PCIe spec (you do have a copy right?) is sufficient for the beaconing. (I don't have a copy in front of me, but I seem to remember it's 0.075uF). Cheers PeteSArticle: 123670
On Aug 29, 12:50 pm, Gabor <ga...@alacron.com> wrote: > On Aug 29, 12:05 pm, fpgabuilder <fpgabuilder-gro...@yahoo.com> wrote: > > > > > On Aug 28, 6:35 am, Paul Leventis <paul.leven...@gmail.com> wrote: > > > > Hello Sanjay, > > > > Our experience is that the PLL's power consumption is fairly low as > > > compared to the clock network it is driving in most cases. To get a > > > sense for the amount of power the PLL consumes as a function of the > > > VCO frequency, download a copy of the Early Power Estimator > > > spreadsheet for the device you are interested in (http://www.altera.com/support/devices/estimator/pow-powerplay.jsp). > > > > For a more detailed analysis, grab a copy of Quartus and fire up a toy > > > design with the PLL in it, and run it through the PowerPlay Power > > > Analyser. The PLL models for 90 nm and 65 nm devices take into > > > account your VCO frequency, M/N values, and counter settings. > > > > Regards, > > > > Paul Leventis > > > Altera Corp. > > > I tried to use the Altera spreadsheet for Stratix3 device as that is > > what I am targetting at present. It seems like the PLL power > > requirement changes only with the VCO frequency. But I am guessing > > this does not say much as the VCO frequency will change depending upon > > the input frequency assuming output frequency is kept the same. > > I think you mean to say "will _not_ change ... assuming output > frequency is kept the same"? > > Normally the VCO frequency is the desired output frequency multiplied > by the required output divider. Since your two input frequencies are > related (4:1) I would not expect you to change the output divider, and > therefore to end up with the same VCO frequency and (roughly) the same > power usage in either case. > > Regards, > Gabor I guess that makes sense in this case because to generate the output frequency we only need to divide the vco frequency. If the input frequency would be required to be multiplied before the vco frequency can be divided, I would think the power consumed would change. Maybe I didn't think through this...Article: 123671
John_H wrote: > "Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message > news:st8gd39018b9sr1aqur727crpgdqjc2nbf@4ax.com... >> Hi - >> >> On Fri, 31 Aug 2007 13:38:11 +0100, Brian Drummond >> <brian_drummond@btconnect.com> wrote: >> >>> On Fri, 31 Aug 2007 11:02:13 +0100, "Symon" <symon_brewer@hotmail.com> >>> wrote: >>> >>>> "John_H" <newsgroup@johnhandwork.com> wrote in message >>>> news:13de6b5q88e3ke1@corp.supernews.com... >>>>> "PeteS" <axkz70@dsl.pipex.com> wrote in message >>>>> news:H-ydnSZMEttzlkrbnZ2dnUVZ8vidnZ2d@pipex.net... >>>>> <snip> >>>>>> I have a number of pretty pics I made to illustrate the issue. I'll >>>>>> put >>>>>> 'em on a.b.s.e tomorrow sometime. >>>>>> >>>>>> As an aside, at high speeds (which I define as having a track longer >>>>>> than >>>>>> 1/4 rising/falling edge, YMMVG), there is no such thing as 'ground'. >>>>>> The >>>>>> ground plane is a signal layer insulated by copper ;) >>>>>> [Although it helps to keep large power currents away from the high >>>>>> speed >>>>>> return paths]. >>>>>> >>>>>> Cheers >>>>>> >>>>>> PeteS >>>>> Since without a ground one has a dipole antenna, could you qualify what >>>>> you mean? The impedance of the plane is measured in units of picoHenry >>>>> per square so it's not a solid ground, certainly, but without a ground >>>>> we'd be in a world of hurt at these high frequencies. >>>>> >>>> I think Pete means that at high frequencies the skin effect means that >>>> the >>>> current in the plane is all on one surface of the plane. Thus the bulk of >>>> the plane might as well be an insulator. Or something like that? >>> I think he means the return current is mostly localised directly under >>> the signal track; the copper under the "space" between tracks carries >>> relatively little current and could *almost* be replaced by insulator. >>> >>> - Brian >> Seems to me you're both right: the return current is bunched up under >> trace, on the side of the ground plane adjacent to the trace. This >> "path" is surrounded by copper. To paraphrase Doug Smith, a local EMC >> consultant, the other side of the plane might as well be on the moon. >> >> Bob Perlman >> Cambrian Design Works >> http://www.cambriandesign.com > > Thanks to everyone for devining what PeteS means. > I understand skin effect. > I understand the confinement of return current for high frequencies. > I don't understand the statement that "there is no such thing as 'ground'." > > I was hoping Pete could conjecture what Pete meant. > > - John_H > > Hi John Let's first define what 'ground' means. For power, it's the 'zero potential' path for return currents. For RF radiation, it's literally the ground (where we get the name) which has a nominal '0' potential. For high speed signalling, there isn't really a thing that has zero potential across it's length, be it signal or reference. The return currents in a nominal ground plane for high speed returns will induce significant potential gradients across the plane. As a 'ground plane' is usually used as a description of an area of equipotential, the term ceases to have meaning when it is no longer equipotential - as is the case when it is a high speed signal reference/return path. That's really what I mean by the comment that at high speeds, ground doesn't really exist. Cheers PeteSArticle: 123672
Weng, > I am fighting for an alternative, concise and simple method to do the > same job as Jim has suggested. You are taking the wrong approach. Your arguments are repetitive and you keep thinking there is a win-lose situation. At the risk of repeating myself: "Write a paper that is composed of two sections: Part 1: Identify the problem you are trying to solve. Since this is hardware centric, it would be appropriate to show schematics or block diagrams and code. With respect to the code, there should be several examples. Part 2: Explain how your proposed solution solves the problems at hand and why it is as good as or better than other solutions. Show what it fails to do." To adopt any proposal into the language, this work must be done. I am not sure anyone else feels passionate enough about it to volunteer to do it. You feel passionate about it. If you do the work and work out the issues, you may be able to breathe some life into it - although I am not convinced of its value unless you can show a compelling use case as I do not know of one myself. I would use the newsgroup to bounce your ideas off of - and listen to the advice you get. Bye, JimArticle: 123673
Gabor wrote: > On Aug 31, 8:52 pm, PeteS <axk...@dsl.pipex.com> wrote: >> vasile wrote: >>> On Aug 29, 5:50 pm, PeteS <axk...@dsl.pipex.com> wrote: >>>> Gabor wrote: >>>>> On Aug 29, 2:55 pm, "Charles, NG" <site_blackh...@trellisys.ie> wrote: >>>>>> The spec says all _transmitters_ shall be AC coupled. You just lead the >>>>>> RX line directly to your component. >>>>>> In terms of your a) b) c) options, the answer is therefore c) but only >>>>>> the TX line(s). >>>>>> By the way as far as I remember, there is some Intel doc recommending >>>>>> placing the cap at 1/3 of the distance from plug to component (i.e. >>>>>> closer to the plug than to the component). >>>>> Also if you're designing a PCIe plug-in card, remember that the signal >>>>> names on the connector are based on the motherboard. So you need to >>>>> connect your transmitter to the receive signals (PERP0/PERN0 ...) and >>>>> your receiver to the transmit signals (PETP0/PETN0 ...). Since the Rx >>>>> and Tx signals are on the opposite board surface, it is very hard to >>>>> correct swapped signals using wires! I got bit by this on my first >>>>> PCIe design. >>>> It is very important to make sure your coupling capacitor is large >>>> enough to handle the 30kHz beacons, so *if* (as I do on occasion) you ac >>>> couple at _each end of the link_, make sure you used double the >>>> recommended value of capacitor if it's a short (in the transmission line >>>> sense) link. >>> This is new for me. What do you mean with 30KHz beacon at 3.1Gbps ? >>> The 0.1uF impedance is large enough for a Ghz signal. >> PCIe (as with most high speed links) uses beacon signals to determine if >> the 'other end' of the link is active. That beacon is a relatively low >> frequency pulse to minimise EMC/EMI. 0.1uF is easily sufficient, but at >> 2.5Gb/s (1.25GHz fundamental) a 100pF cap would be sufficient - the cap >> recommended in the PCIe spec (you do have a copy right?) is sufficient >> for the beaconing. (I don't have a copy in front of me, but I seem to >> remember it's 0.075uF). >> >> Cheers >> >> PeteS > > > .075uF (75nF) is the minimum spec. There is also a maximum of 0.2uF > (200nF) > so theoretically 0.1uF -25/+100 % is good. Z5U or Y5U bypass quality > caps > won't give you this tolerance. X7R or X5R will. The 1.1 > specification > talks about 0603 components, but I would think 0402 would work better. > A major issue is parasitics. 0402 is ok, 0603 is marginal. As to type, I wouldn't use anything less than X5R anyway for a signal path. Cheers PeteSArticle: 123674
On Aug 31, 6:01 pm, Jim Lewis <j...@synthworks.com> wrote: > Weng, > > > I am fighting for an alternative, concise and simple method to do the > > same job as Jim has suggested. > > You are taking the wrong approach. Your arguments are repetitive > and you keep thinking there is a win-lose situation. > > At the risk of repeating myself: > > "Write a paper that is composed of two sections: > Part 1: > Identify the problem you are trying to solve. Since this is > hardware centric, it would be appropriate to show schematics or > block diagrams and code. With respect to the code, there should > be several examples. > > Part 2: > Explain how your proposed solution solves the problems at > hand and why it is as good as or better than other solutions. > Show what it fails to do." > > To adopt any proposal into the language, this work must > be done. I am not sure anyone else feels passionate enough > about it to volunteer to do it. You feel passionate about > it. If you do the work and work out the issues, you may be > able to breathe some life into it - although I am not convinced > of its value unless you can show a compelling use case as I > do not know of one myself. > > I would use the newsgroup to bounce your ideas off of - and > listen to the advice you get. > > Bye, > Jim Jim, 1. I have quited my job since last October to devote my full energy to develop other adventure personally. Since then I have been kept in pay roll with full pay to do some maintenance work part time. Today is my last pay day. My company was bought by another company this week. 2. So I don't have time to do the job you asked now. First I have to make money out of my current home project. If the project is finished (expected to finished within 3-6 months from now), I will publish them on this group to sell and stir another round of discussions. 'orif' project is my amateur project only when I have time to do it. 3. I know nothing about PSL and just printed VHDL-1993 and VHDL-2002 today and started reading them. I have no interest to learn PSL. I am more interested in algorithms and circuit development, not the VHDL language. For my personal use, VHDL-1993 standard plus 'orif' is enough. That I am pushing for 'orif' adoption is only for my personal use. Now I don't need it as desperately as before. 4. I am not qualified in any sense to write the report. I would like to have some big canon to co-sponsor the 'orif' work and I would like to provide examples and drawings, but not full report, especially English text part that is my weakest point. The reason is I am not a good English writer, not a good persuader, even though many times I have many creative ideas, but am not good at writing them systematically and quickly. All ideas about 'orif' are on this topics, I have no any ambition in my life to fight it forever. 5. With 'unique' keyword introduced in Verilog domain, the scientists and engineers over there have demonstrated why they were. VHDL should provide the same tool as 'unique' without doubt. Are specialists in Verilog group so stupid that they created two new tools to do the same things without a good reason? The reasons are plentiful, but none in VHDL world shows full support of it. What a pity ! The reason is what I have presented in my posting: in-line programming capability for a very important feature that was considered only after 2002. Duplication of two fundamental tools is less a issue if they can provide convenience, no matter your personal favors are. Now persons' favor is more important than facts and become deciding factor. 6. 'orif' cannot provide more information than what members of a mutually exclusive group are. Your method provides the message and there is no more message to provide to VHDL compilers. 7. The only advantages of 'orif' are a. in-line programming capability; b. mixing 'elsif' and 'orif' language structure. No more. 8. The advantage of 'orif' over 'unique' is that 'orif' can be selectively used to replace 'elsif' at any place and at any levels in a 'if' statement. 9. Sorry for using word 'fight' in previous posting. There is no fight, just exchange ideas and I got a very special gift from the discussions. Thank you. Weng
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