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
> The only complications are from the various error and special case > handling of the IEEE-754 format. I doubt the FPGA is implementing that, > but possibly. Altera claims it IS IEEE-754 compliant, but it is surprisingly hard to find any more detailed facts. And we all know how FPGA marketing works, so bit of doubt is very understandable... The best I could find is this: http://www.bogdan-pasca.org/resources/publications/2015_langhammer_pasca_fp_dsp_block_architecture_for_fpgas.pdf In short: It appears that infinite and NaNs are supported, however sub-normals are treated as 0 and only one rounding-mode is supported... Somewhere there is a video which shows that using the floating-point DSPs cuts the LE-usage by about 90%, so if you need floating point, I think Arria/Stratix 10 are really the best way to go... Regards, Thomas www.entner-electronics.com - Home of EEBlaster and JPEG-CodecArticle: 159651
> One of the features I use a lot is Rectangle mode in Emacs. https://www.emacswiki.org/emacs/RectangleCommands I think most reasonable editors support this, mostly by either holding ALT or CTRL pressed during makeing a selection with the mouse-pointer. In Eclipse it is a seperate mode, toggled with ALT-SHIFT-A, IIRC. BTW: I think most mentioned editors will be good for programming and editing, but for VHDL coding they cannot keep up with V3S or (the more expensive) Sigasi. Check out the videos on the respective home-pages...Article: 159652
On 01/24/2017 09:44 PM, Tim Wescott wrote: > This is kind of a survey; I need some perspective (possibly historical) > > Are there any digital systems that you know of that use 1's compliment or > signed-magnitude number representation for technical reasons? > > Have you ever used it in the past? > > Is the world down to legacy applications and interfacing with legacy > sensors? > > TIA. > I have done hardware dividers and multipliers that only work with positive integers, so you have to convert to positive values and track the sign externally. This qualifies as sign magnitude, I think. Also, working in mixed analog/digital systems, sign magnitude is pretty common at the analog/digital boundary. The analog part accepts a magnitude value and a sign bit. Think about a simple R2R DAC and an analog transmission gate for accepting the true or inverted value. 2's complement takes extra work to accept. BobHArticle: 159653
On 1/25/2017 9:15 PM, thomas.entner99@gmail.com wrote: > >> The only complications are from the various error and special case >> handling of the IEEE-754 format. I doubt the FPGA is implementing that, >> but possibly. > > Altera claims it IS IEEE-754 compliant, but it is surprisingly hard to find any more detailed facts. And we all know how FPGA marketing works, so bit of doubt is very understandable... > > The best I could find is this: > http://www.bogdan-pasca.org/resources/publications/2015_langhammer_pasca_fp_dsp_block_architecture_for_fpgas.pdf > > In short: It appears that infinite and NaNs are supported, however sub-normals are treated as 0 and only one rounding-mode is supported... > > Somewhere there is a video which shows that using the floating-point DSPs cuts the LE-usage by about 90%, so if you need floating point, I think Arria/Stratix 10 are really the best way to go... That video may be for the *entire* floating point unit in the fabric. Most FPGAs have dedicated integer multipliers which can be used for both the multiplier and the barrel shifters in a floating point ALU. The adders and random logic would need to be in the fabric, but will be *much* smaller. -- Rick CArticle: 159654
On 1/25/2017 11:50 PM, BobH wrote: > On 01/24/2017 09:44 PM, Tim Wescott wrote: >> This is kind of a survey; I need some perspective (possibly historical) >> >> Are there any digital systems that you know of that use 1's compliment or >> signed-magnitude number representation for technical reasons? >> >> Have you ever used it in the past? >> >> Is the world down to legacy applications and interfacing with legacy >> sensors? >> >> TIA. >> > > I have done hardware dividers and multipliers that only work with > positive integers, so you have to convert to positive values and track > the sign externally. This qualifies as sign magnitude, I think. > > Also, working in mixed analog/digital systems, sign magnitude is pretty > common at the analog/digital boundary. The analog part accepts a > magnitude value and a sign bit. Think about a simple R2R DAC and an > analog transmission gate for accepting the true or inverted value. 2's > complement takes extra work to accept. I don't agree. 2's compliment to a DAC only requires the sign bit to be inverted (same as offsetting by 2**(n-1)) and that the range of the DAC output be biased so the original zero value is at zero volts if that is what is desired. I have seldom seen available analog conversion parts use sign magnitude, but they do exist. -- Rick CArticle: 159655
On Tue, 24 Jan 2017 22:44:32 -0600, Tim Wescott wrote: > This is kind of a survey; I need some perspective (possibly historical) > > Are there any digital systems that you know of that use 1's compliment or > signed-magnitude number representation for technical reasons? > > Have you ever used it in the past? > > Is the world down to legacy applications and interfacing with legacy > sensors? Every time you surf the web you use 1's comp arithmetic for the IP and TCP header checksum calculations. That's just what the spec says. I'm sure someone at one time thought it had some technical advantage over other sorts of checksums, but it's actually quite poor in terms of its error detection capabilities and isn't that fast to calculate. In two different jobs I've designed FPGA-based systems that would alter a field in the IP or TCP header then adjust the checksum to suit rather than recalculating it from scratch. This requires a firm knowledge of 1's comp arithmetic, e.g. you need to know that the +0 and -0 aren't equivalent in this context. As an aside, I once used an HP Ethernet switch didn't do it correctly and would corrupt non-IP frames that happened to have particular values (IIRC it was 0000 or ffff) in the same position as the IP checksum field in the packet header. There are multiple RFCs describing how it's done. Some of them are even correct. Regards, AllanArticle: 159656
thomas.entner99@gmail.com writes: >> I suppose. What I remember of colleagues not using Emacs were using >> Ultraedit in Windows or Nedit in Linux. > > > But I think they do not go much beyond syntax highlighting for > VHDL. Sigasi and V3S go much further, e.g. with automatic instance > generation and "live" error checking. It's possible, I'm not sure if I've ever used Nedit or Ultraedit. But maybe the lack of features is the point? I feel at least some of those colleagues didn't want advanced features in their editor and I suppose also weren't bothered by the monkey work that means with VHDL. I had a Sigasi evaluation license some years ago but in the end the problem was I don't really like Eclipse. I guess Sigasi is still Eclipse, right? OTOH, I liked Sigasi's integration support for Quartus project files but that had more to do with Quartus's clunkiness.Article: 159657
On Thu, 26 Jan 2017 11:07:23 +0000, Allan Herriman wrote: > Every time you surf the web you use 1's comp arithmetic for the IP and > TCP header checksum calculations. That's just what the spec says. I'm > sure someone at one time thought it had some technical advantage over > other sorts of checksums, but it's actually quite poor in terms of its > error detection capabilities and isn't that fast to calculate. The ones-complement sum of the 16-bits words is invariant with respect to byte swapping. That is, it just works on either big-endian or little- endian machines. I've never read anything saying that's why they chose it but it's what I've always suspected.Article: 159658
On Thu, 26 Jan 2017 01:10:14 -0500, rickman wrote: > On 1/25/2017 9:15 PM, thomas.entner99@gmail.com wrote: >> >>> The only complications are from the various error and special case >>> handling of the IEEE-754 format. I doubt the FPGA is implementing >>> that, >>> but possibly. >> >> Altera claims it IS IEEE-754 compliant, but it is surprisingly hard to >> find any more detailed facts. And we all know how FPGA marketing works, >> so bit of doubt is very understandable... >> >> The best I could find is this: >> http://www.bogdan-pasca.org/resources/ publications/2015_langhammer_pasca_fp_dsp_block_architecture_for_fpgas.pdf >> >> In short: It appears that infinite and NaNs are supported, however >> sub-normals are treated as 0 and only one rounding-mode is supported... >> >> Somewhere there is a video which shows that using the floating-point >> DSPs cuts the LE-usage by about 90%, so if you need floating point, I >> think Arria/Stratix 10 are really the best way to go... > > That video may be for the *entire* floating point unit in the fabric. > Most FPGAs have dedicated integer multipliers which can be used for both > the multiplier and the barrel shifters in a floating point ALU. The > adders and random logic would need to be in the fabric, but will be > *much* smaller. Xilinx and Altera both support "DSP blocks" that do a multiply and add (they say multiply and accumulate, but it's more versatile than that). According to the above paper, Altera has paired up their DSP blocks and added logic to each pair so that they become a floating-point arithmetic block. Personally I think that for most "regular" DSP uses you're going to know the range of the incoming data and will, therefor, only need fixed-point -- but it looks like they're chasing the "FPGA as a supercomputer" market (hence, the purchase by Intel), and for that you need floating point just as a selling point. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 159659
On 1/26/2017 11:19 AM, Tim Wescott wrote: > On Thu, 26 Jan 2017 01:10:14 -0500, rickman wrote: > >> On 1/25/2017 9:15 PM, thomas.entner99@gmail.com wrote: >>> >>>> The only complications are from the various error and special case >>>> handling of the IEEE-754 format. I doubt the FPGA is implementing >>>> that, >>>> but possibly. >>> >>> Altera claims it IS IEEE-754 compliant, but it is surprisingly hard to >>> find any more detailed facts. And we all know how FPGA marketing works, >>> so bit of doubt is very understandable... >>> >>> The best I could find is this: >>> http://www.bogdan-pasca.org/resources/ > publications/2015_langhammer_pasca_fp_dsp_block_architecture_for_fpgas.pdf >>> >>> In short: It appears that infinite and NaNs are supported, however >>> sub-normals are treated as 0 and only one rounding-mode is supported... >>> >>> Somewhere there is a video which shows that using the floating-point >>> DSPs cuts the LE-usage by about 90%, so if you need floating point, I >>> think Arria/Stratix 10 are really the best way to go... >> >> That video may be for the *entire* floating point unit in the fabric. >> Most FPGAs have dedicated integer multipliers which can be used for both >> the multiplier and the barrel shifters in a floating point ALU. The >> adders and random logic would need to be in the fabric, but will be >> *much* smaller. > > Xilinx and Altera both support "DSP blocks" that do a multiply and add > (they say multiply and accumulate, but it's more versatile than that). > > According to the above paper, Altera has paired up their DSP blocks and > added logic to each pair so that they become a floating-point arithmetic > block. Personally I think that for most "regular" DSP uses you're going > to know the range of the incoming data and will, therefor, only need > fixed-point -- but it looks like they're chasing the "FPGA as a > supercomputer" market (hence, the purchase by Intel), and for that you > need floating point just as a selling point. If you look around I thing you will find many uses for floating point in the DSP market. It's not just a selling gimmick. I don't think the many floating point DSP devices are sold because they look good in the product's spec sheet. Heck back in the day when DSP was done on mainframes the hot rods of computing were all floating point. Cray-1, ST-100... -- Rick CArticle: 159660
On Thursday, January 26, 2017 at 1:59:09 PM UTC-5, rickman wrote:
> If you look around I thing you will find many uses for floating point in
> the DSP market. It's not just a selling gimmick. I don't think the
> many floating point DSP devices are sold because they look good in the
> product's spec sheet.
>
> Heck back in the day when DSP was done on mainframes the hot rods of
> computing were all floating point. Cray-1, ST-100...
I am attempting to design a 40-bit single and 80-bit double hardware-
expressed form of an n-bit floating point "unum" (universal number)
engine, as per the design by John Gustafson:
http://ubiquity.acm.org/article.cfm?id=3001758
I intend an FPU, and 4x vector FPU for SIMD:
https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/fpu/fpu.png
https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/fpu_vector/fpu_vector.png
In my Arxoda CPU (design still in progress):
https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/overall_design.png
Thank you,
Rick C. Hodgin
Article: 159661On Thursday, January 26, 2017 at 11:44:58 AM UTC+10:30, Tim Wescott wrote: > > > On Wednesday, January 25, 2017 at 3:14:39 PM UTC+10:30, Tim Wescott > > wrote: > >> I need some perspective (possibly historical) > >> > > I'm looking for current practice, not history. > ?????Article: 159662
> I had a Sigasi evaluation license some years ago but in the end the > problem was I don't really like Eclipse. I guess Sigasi is still > Eclipse, right? >=20 Yes, Sigasi is Eclipse based. V3S is Visual Studio based. Both approaches have their pros and cons. I guess it is - like the whole ed= itor topic - a question of personal preferences. (I for my part e.g. do NOT= like the "monkey work" and also like syntax errors to be flagged before co= mpilation process, which is supported by both...) Regards, Thomas www.entner-electronics.com - Home of EEBlaster and JPEG-CodecArticle: 159663
On Thursday, January 26, 2017 at 12:59:09 PM UTC-6, rickman wrote: > On 1/26/2017 11:19 AM, Tim Wescott wrote: > > On Thu, 26 Jan 2017 01:10:14 -0500, rickman wrote: > > > >> On 1/25/2017 9:15 PM, thomas.entner99@gmail.com wrote: > >>> > >>>> The only complications are from the various error and special case > >>>> handling of the IEEE-754 format. I doubt the FPGA is implementing > >>>> that, > >>>> but possibly. > >>> > >>> Altera claims it IS IEEE-754 compliant, but it is surprisingly hard to > >>> find any more detailed facts. And we all know how FPGA marketing works, > >>> so bit of doubt is very understandable... > >>> > >>> The best I could find is this: > >>> http://www.bogdan-pasca.org/resources/ > > publications/2015_langhammer_pasca_fp_dsp_block_architecture_for_fpgas.pdf > >>> > >>> In short: It appears that infinite and NaNs are supported, however > >>> sub-normals are treated as 0 and only one rounding-mode is supported... > >>> > >>> Somewhere there is a video which shows that using the floating-point > >>> DSPs cuts the LE-usage by about 90%, so if you need floating point, I > >>> think Arria/Stratix 10 are really the best way to go... > >> > >> That video may be for the *entire* floating point unit in the fabric. > >> Most FPGAs have dedicated integer multipliers which can be used for both > >> the multiplier and the barrel shifters in a floating point ALU. The > >> adders and random logic would need to be in the fabric, but will be > >> *much* smaller. > > > > Xilinx and Altera both support "DSP blocks" that do a multiply and add > > (they say multiply and accumulate, but it's more versatile than that). > > > > According to the above paper, Altera has paired up their DSP blocks and > > added logic to each pair so that they become a floating-point arithmetic > > block. Personally I think that for most "regular" DSP uses you're going > > to know the range of the incoming data and will, therefor, only need > > fixed-point -- but it looks like they're chasing the "FPGA as a > > supercomputer" market (hence, the purchase by Intel), and for that you > > need floating point just as a selling point. > > If you look around I thing you will find many uses for floating point in > the DSP market. It's not just a selling gimmick. I don't think the > many floating point DSP devices are sold because they look good in the > product's spec sheet. > > Heck back in the day when DSP was done on mainframes the hot rods of > computing were all floating point. Cray-1, ST-100... > > -- > > Rick C ]> If you look around I thing you will find many uses for floating point in ]> the DSP market. There was a rule of thumb in voice compression that floating point DSP took a third fewer operations than fixed point DSP. Plus probably faster code development not having to keep track of the scaling. Jim BrakefieldArticle: 159664
On 01/25/2017 11:15 PM, rickman wrote: > On 1/25/2017 11:50 PM, BobH wrote: >> On 01/24/2017 09:44 PM, Tim Wescott wrote: >>> This is kind of a survey; I need some perspective (possibly historical) >>> >>> Are there any digital systems that you know of that use 1's >>> compliment or >>> signed-magnitude number representation for technical reasons? >>> >>> Have you ever used it in the past? >>> >>> Is the world down to legacy applications and interfacing with legacy >>> sensors? >>> >>> TIA. >>> >> >> I have done hardware dividers and multipliers that only work with >> positive integers, so you have to convert to positive values and track >> the sign externally. This qualifies as sign magnitude, I think. >> >> Also, working in mixed analog/digital systems, sign magnitude is pretty >> common at the analog/digital boundary. The analog part accepts a >> magnitude value and a sign bit. Think about a simple R2R DAC and an >> analog transmission gate for accepting the true or inverted value. 2's >> complement takes extra work to accept. > > I don't agree. 2's compliment to a DAC only requires the sign bit to be > inverted (same as offsetting by 2**(n-1)) and that the range of the DAC > output be biased so the original zero value is at zero volts if that is > what is desired. > > I have seldom seen available analog conversion parts use sign magnitude, > but they do exist. > These are not customer visible interfaces Rick. These are trim DACs used for part parameter trimming that the customer never sees or even knows that they exist. I spent the last 7 years dealing with this at a couple of large semiconductor houses. BobHArticle: 159665
> > > > I think you oversimplify FP. It works a lot better with dedicated hard= ware. >=20 > Not sure what your point is. The principles are the same in software or= =20 > hardware. I was describing hardware I have worked on. ST-100 from Star= =20 > Technologies. I became very intimate with the inner workings. >=20 > The only complications are from the various error and special case=20 > handling of the IEEE-754 format. I doubt the FPGA is implementing that,= =20 > but possibly. The basics are still the same. Adds use a barrel shifter= =20 > to denormalize the mantissa so the exponents are equal, a integer adder= =20 > and a normalization barrel shifter to produce the result. Multiplies=20 > use a multiplier for the mantissas and an adder for the exponents (with= =20 > adjustment for exponent bias) followed by a simple shifter to normalize= =20 > the result. >=20 > Both add and multiply are about the same level of complexity as a barrel= =20 > shifter is almost as much logic as the multiplier. >=20 > Other than the special case handling of IEEE-754, what do you think I am= =20 > missing? >=20 > --=20 >=20 > Rick C It just all works better with dedicated hardware. Finding the leading one = for normalization is somewhat slow in the FPGA and is something that benefi= ts from dedicated hardware. Using a DSP48 (if we're talking about Xilinx) = for a barrel shifter is fairly fast, but requires 3 cycles of latency, can = only shift up to 18 bits, and is overkill for the task. You're using a ful= l multiplier as a shifter; a dedicated shifter would be smaller and faster.= All this stuff adds latency. When I pull up CoreGen and ask for the basi= c FP adder, I get something that uses only 2 DSP48s but has 12 cycles of la= tency. And there is a lot of fabric routing so timing is not very determin= istic.Article: 159666
On 1/26/2017 8:57 PM, BobH wrote: > On 01/25/2017 11:15 PM, rickman wrote: >> On 1/25/2017 11:50 PM, BobH wrote: >>> On 01/24/2017 09:44 PM, Tim Wescott wrote: >>>> This is kind of a survey; I need some perspective (possibly historical) >>>> >>>> Are there any digital systems that you know of that use 1's >>>> compliment or >>>> signed-magnitude number representation for technical reasons? >>>> >>>> Have you ever used it in the past? >>>> >>>> Is the world down to legacy applications and interfacing with legacy >>>> sensors? >>>> >>>> TIA. >>>> >>> >>> I have done hardware dividers and multipliers that only work with >>> positive integers, so you have to convert to positive values and track >>> the sign externally. This qualifies as sign magnitude, I think. >>> >>> Also, working in mixed analog/digital systems, sign magnitude is pretty >>> common at the analog/digital boundary. The analog part accepts a >>> magnitude value and a sign bit. Think about a simple R2R DAC and an >>> analog transmission gate for accepting the true or inverted value. 2's >>> complement takes extra work to accept. >> >> I don't agree. 2's compliment to a DAC only requires the sign bit to be >> inverted (same as offsetting by 2**(n-1)) and that the range of the DAC >> output be biased so the original zero value is at zero volts if that is >> what is desired. >> >> I have seldom seen available analog conversion parts use sign magnitude, >> but they do exist. >> > These are not customer visible interfaces Rick. These are trim DACs used > for part parameter trimming that the customer never sees or even knows > that they exist. I spent the last 7 years dealing with this at a couple > of large semiconductor houses. What does "customer visible" have to do with it? You seem to be talking about rolling your own DAC using a bunch of I/O pins and resistors with analog inversion circuitry after. I'm explaining how it can be done more easily. If you don't need bipolar outputs, why do you need negative binary values at all? I've said there are a few sign magnitude DAC parts out there, but not so many. I can't recall ever using one. -- Rick CArticle: 159667
On 1/26/2017 9:38 PM, Kevin Neilson wrote: >>> >>> I think you oversimplify FP. It works a lot better with >>> dedicated hardware. >> >> Not sure what your point is. The principles are the same in >> software or hardware. I was describing hardware I have worked on. >> ST-100 from Star Technologies. I became very intimate with the >> inner workings. >> >> The only complications are from the various error and special case >> handling of the IEEE-754 format. I doubt the FPGA is implementing >> that, but possibly. The basics are still the same. Adds use a >> barrel shifter to denormalize the mantissa so the exponents are >> equal, a integer adder and a normalization barrel shifter to >> produce the result. Multiplies use a multiplier for the mantissas >> and an adder for the exponents (with adjustment for exponent bias) >> followed by a simple shifter to normalize the result. >> >> Both add and multiply are about the same level of complexity as a >> barrel shifter is almost as much logic as the multiplier. >> >> Other than the special case handling of IEEE-754, what do you think >> I am missing? >> >> -- >> >> Rick C > > It just all works better with dedicated hardware. Finding the > leading one for normalization is somewhat slow in the FPGA and is > something that benefits from dedicated hardware. Using a DSP48 (if > we're talking about Xilinx) for a barrel shifter is fairly fast, but > requires 3 cycles of latency, can only shift up to 18 bits, and is > overkill for the task. You're using a full multiplier as a shifter; > a dedicated shifter would be smaller and faster. All this stuff adds > latency. When I pull up CoreGen and ask for the basic FP adder, I > get something that uses only 2 DSP48s but has 12 cycles of latency. > And there is a lot of fabric routing so timing is not very > deterministic. I'm not sure how much you know about multipliers and shifters. Multipliers are not magical. Multiplexers *are* big. A multiplier has N stages with a one bit adder at every bit position. A barrel multiplexer has nearly as many bit positions (you typically don't need all the possible outputs), but uses a bit less logic at each position. Each bit position still needs a full 4 input LUT. Not tons of difference in complexity. The multipliers I've seen have selectable latency down to 1 clock. Rolling a barrel shifter will generate many layers of logic that will need to be pipelined as well to reach high speeds, likely many more layers for the same speeds. What do you get if you design a floating point adder in the fabric? I can only imagine it will be *much* larger and slower. -- Rick CArticle: 159668
On 27/01/17 05:15, rickman wrote: > On 1/26/2017 8:57 PM, BobH wrote: >> On 01/25/2017 11:15 PM, rickman wrote: >>> On 1/25/2017 11:50 PM, BobH wrote: >>>> On 01/24/2017 09:44 PM, Tim Wescott wrote: >>>>> This is kind of a survey; I need some perspective (possibly >>>>> historical) >>>>> >>>>> Are there any digital systems that you know of that use 1's >>>>> compliment or >>>>> signed-magnitude number representation for technical reasons? >>>>> >>>>> Have you ever used it in the past? >>>>> >>>>> Is the world down to legacy applications and interfacing with legacy >>>>> sensors? >>>>> >>>>> TIA. >>>>> >>>> >>>> I have done hardware dividers and multipliers that only work with >>>> positive integers, so you have to convert to positive values and track >>>> the sign externally. This qualifies as sign magnitude, I think. >>>> >>>> Also, working in mixed analog/digital systems, sign magnitude is pretty >>>> common at the analog/digital boundary. The analog part accepts a >>>> magnitude value and a sign bit. Think about a simple R2R DAC and an >>>> analog transmission gate for accepting the true or inverted value. 2's >>>> complement takes extra work to accept. >>> >>> I don't agree. 2's compliment to a DAC only requires the sign bit to be >>> inverted (same as offsetting by 2**(n-1)) and that the range of the DAC >>> output be biased so the original zero value is at zero volts if that is >>> what is desired. >>> >>> I have seldom seen available analog conversion parts use sign magnitude, >>> but they do exist. >>> >> These are not customer visible interfaces Rick. These are trim DACs used >> for part parameter trimming that the customer never sees or even knows >> that they exist. I spent the last 7 years dealing with this at a couple >> of large semiconductor houses. > > What does "customer visible" have to do with it? You seem to be talking > about rolling your own DAC using a bunch of I/O pins and resistors with > analog inversion circuitry after. I'm explaining how it can be done > more easily. If you don't need bipolar outputs, why do you need > negative binary values at all? > > I've said there are a few sign magnitude DAC parts out there, but not so > many. I can't recall ever using one. > My understanding of Bob's post here is that the "customer" in this case is the hardware design that is buying the chip, not the end-user or even the board's programmer. So when you buy an ADC with a precision 2.5V internal reference, Bob is talking about the trim DAC that is factory calibrated to modify the base reference - /you/ are the customer for whom this interface is invisible.Article: 159669
On 27/01/17 05:39, rickman wrote: > On 1/26/2017 9:38 PM, Kevin Neilson wrote: >>>> >>>> I think you oversimplify FP. It works a lot better with >>>> dedicated hardware. >>> >>> Not sure what your point is. The principles are the same in >>> software or hardware. I was describing hardware I have worked on. >>> ST-100 from Star Technologies. I became very intimate with the >>> inner workings. >>> >>> The only complications are from the various error and special case >>> handling of the IEEE-754 format. I doubt the FPGA is implementing >>> that, but possibly. The basics are still the same. Adds use a >>> barrel shifter to denormalize the mantissa so the exponents are >>> equal, a integer adder and a normalization barrel shifter to >>> produce the result. Multiplies use a multiplier for the mantissas >>> and an adder for the exponents (with adjustment for exponent bias) >>> followed by a simple shifter to normalize the result. >>> >>> Both add and multiply are about the same level of complexity as a >>> barrel shifter is almost as much logic as the multiplier. >>> >>> Other than the special case handling of IEEE-754, what do you think >>> I am missing? >>> >>> -- >>> >>> Rick C >> >> It just all works better with dedicated hardware. Finding the >> leading one for normalization is somewhat slow in the FPGA and is >> something that benefits from dedicated hardware. Using a DSP48 (if >> we're talking about Xilinx) for a barrel shifter is fairly fast, but >> requires 3 cycles of latency, can only shift up to 18 bits, and is >> overkill for the task. You're using a full multiplier as a shifter; >> a dedicated shifter would be smaller and faster. All this stuff adds >> latency. When I pull up CoreGen and ask for the basic FP adder, I >> get something that uses only 2 DSP48s but has 12 cycles of latency. >> And there is a lot of fabric routing so timing is not very >> deterministic. > > I'm not sure how much you know about multipliers and shifters. > Multipliers are not magical. Multiplexers *are* big. A multiplier has > N stages with a one bit adder at every bit position. A barrel > multiplexer has nearly as many bit positions (you typically don't need > all the possible outputs), but uses a bit less logic at each position. > Each bit position still needs a full 4 input LUT. Not tons of > difference in complexity. > A 32-bit barrel shifter can be made with 5 steps, each step being a set of 32 two-input multiplexers. Dedicated hardware for that will be /much/ smaller and more efficient than using LUTs or a full multiplier. Normalisation of FP results also requires a "find first 1" operation. Again, dedicated hardware is going to be a lot smaller and more efficient than using LUT's. So a DSP block that has dedicated FP support is going to be smaller and faster than using integer DSP blocks with LUT's to do the same job. > The multipliers I've seen have selectable latency down to 1 clock. > Rolling a barrel shifter will generate many layers of logic that will > need to be pipelined as well to reach high speeds, likely many more > layers for the same speeds. > > What do you get if you design a floating point adder in the fabric? I > can only imagine it will be *much* larger and slower. >Article: 159670
thomas.entner99@gmail.com wrote: > As X and A's integrated editors are more or less limited, I guess many people will looking for better alternatives. > > The usual suspects will be Emacs (with VHDL mode) and Sigasi. > > For me personally, I never really liked Emacs and found Sigasi just a bit too expensive. > > So some time ago I came across V3S from www.vide-software.at. It is a quite powerful and fair priced VHDL plug-in for Visual Studio (Stand-alone version with Visual Studio redistributable package also available). I could also watch the progress over the last few months and I really like it. > > The only drawback is the missing Linux support. However, there appears to be a Linux version of "Visual Studio Code". I have not checked yet if this works together with the plug-in. Maybe someone else has? > > Regards, > > Thomas > > P.S.: I am in no way related to V3S, just a happy user. I want to sell you EEBlasters, JPEG encoders and cameras at www.entner-electronics.com, however ;-) I do almost all of my work in Verilog, but I do have comments about editors in general. I gave up on using Xilinx built-in editors after the first major update. For no apparent reason, they completely changed the user interface. Im my opinion, the best editor is the one you're most familiar with. You spend a lot of time discovering the easiest way to do each editing task. So it makes no sense to depend on an editor that changes everything you've learned with each major software update. I've been using Med for some time now. Unfortunately it doesn't seem to be maintained anymore, but I'm happy with the functionality of the old version I'm using. It didn't come with a Verilog language template, but gave me the option of making my own. It has some interesting capabilities like column-selection and paste being separate things. That is, regardless of how you copy or cut a piece of text, it can be pasted as a column (rectangular selection) or normally. So you can copy a rectangular selection and paste it in line, or vice versa. Indenting is rather crude, but good enough for my work. I actually tried Sigasi's editor briefly, but found it lacking some of the features I was used to, and I wasn't so interested in the project management portion since I generally work from the Xilinx GUI. At this point, I'm not sure which feature I missed, since it's been a while since I tried it. What I was hoping to find (in any editor) was the ability to automatically re-indent code based on the language structure. This is something that has been in C editors for a long time. I seem to recall the operation called "prettify," as in to make the source look pretty. I like my code in a particular indenting style, and find it easier to read other peoples code after I've re-styled it to match my preferences. -- GaborArticle: 159671
Le vendredi 27 janvier 2017 03:17:21 UTC-5, David Brown a =C3=A9crit=C2=A0: > On 27/01/17 05:39, rickman wrote: > > On 1/26/2017 9:38 PM, Kevin Neilson wrote: > >>>> > >>>> I think you oversimplify FP. It works a lot better with > >>>> dedicated hardware. > >>> > >>> Not sure what your point is. The principles are the same in > >>> software or hardware. I was describing hardware I have worked on. > >>> ST-100 from Star Technologies. I became very intimate with the > >>> inner workings. > >>> > >>> The only complications are from the various error and special case > >>> handling of the IEEE-754 format. I doubt the FPGA is implementing > >>> that, but possibly. The basics are still the same. Adds use a > >>> barrel shifter to denormalize the mantissa so the exponents are > >>> equal, a integer adder and a normalization barrel shifter to > >>> produce the result. Multiplies use a multiplier for the mantissas > >>> and an adder for the exponents (with adjustment for exponent bias) > >>> followed by a simple shifter to normalize the result. > >>> > >>> Both add and multiply are about the same level of complexity as a > >>> barrel shifter is almost as much logic as the multiplier. > >>> > >>> Other than the special case handling of IEEE-754, what do you think > >>> I am missing? > >>> > >>> --=20 > >>> > >>> Rick C > >> > >> It just all works better with dedicated hardware. Finding the > >> leading one for normalization is somewhat slow in the FPGA and is > >> something that benefits from dedicated hardware. Using a DSP48 (if > >> we're talking about Xilinx) for a barrel shifter is fairly fast, but > >> requires 3 cycles of latency, can only shift up to 18 bits, and is > >> overkill for the task. You're using a full multiplier as a shifter; > >> a dedicated shifter would be smaller and faster. All this stuff adds > >> latency. When I pull up CoreGen and ask for the basic FP adder, I > >> get something that uses only 2 DSP48s but has 12 cycles of latency. > >> And there is a lot of fabric routing so timing is not very > >> deterministic. > >=20 > > I'm not sure how much you know about multipliers and shifters. > > Multipliers are not magical. Multiplexers *are* big. A multiplier has > > N stages with a one bit adder at every bit position. A barrel > > multiplexer has nearly as many bit positions (you typically don't need > > all the possible outputs), but uses a bit less logic at each position. > > Each bit position still needs a full 4 input LUT. Not tons of > > difference in complexity. > >=20 >=20 > A 32-bit barrel shifter can be made with 5 steps, each step being a set > of 32 two-input multiplexers. Dedicated hardware for that will be > /much/ smaller and more efficient than using LUTs or a full multiplier. >=20 > Normalisation of FP results also requires a "find first 1" operation. > Again, dedicated hardware is going to be a lot smaller and more > efficient than using LUT's. >=20 > So a DSP block that has dedicated FP support is going to be smaller and > faster than using integer DSP blocks with LUT's to do the same job. >=20 > > The multipliers I've seen have selectable latency down to 1 clock. > > Rolling a barrel shifter will generate many layers of logic that will > > need to be pipelined as well to reach high speeds, likely many more > > layers for the same speeds. > >=20 > > What do you get if you design a floating point adder in the fabric? I > > can only imagine it will be *much* larger and slower. > > If I understand, you can do a barrel shifter with log2(n) complexity, hence= your 5 steps but you will have the combitional delays of 5 muxes, it could= limit your maximum clock frequency. A brute force approach will use more r= esoures but will probably allow a higher clock frequency.Article: 159672
Well, ther's TCP/ip checksumsArticle: 159673
On 27/01/17 16:12, Benjamin Couillard wrote: > Le vendredi 27 janvier 2017 03:17:21 UTC-5, David Brown a écrit : >> On 27/01/17 05:39, rickman wrote: >>> On 1/26/2017 9:38 PM, Kevin Neilson wrote: >>>>>> >>>>>> I think you oversimplify FP. It works a lot better with >>>>>> dedicated hardware. >>>>> >>>>> Not sure what your point is. The principles are the same in >>>>> software or hardware. I was describing hardware I have >>>>> worked on. ST-100 from Star Technologies. I became very >>>>> intimate with the inner workings. >>>>> >>>>> The only complications are from the various error and special >>>>> case handling of the IEEE-754 format. I doubt the FPGA is >>>>> implementing that, but possibly. The basics are still the >>>>> same. Adds use a barrel shifter to denormalize the mantissa >>>>> so the exponents are equal, a integer adder and a >>>>> normalization barrel shifter to produce the result. >>>>> Multiplies use a multiplier for the mantissas and an adder >>>>> for the exponents (with adjustment for exponent bias) >>>>> followed by a simple shifter to normalize the result. >>>>> >>>>> Both add and multiply are about the same level of complexity >>>>> as a barrel shifter is almost as much logic as the >>>>> multiplier. >>>>> >>>>> Other than the special case handling of IEEE-754, what do you >>>>> think I am missing? >>>>> >>>>> -- >>>>> >>>>> Rick C >>>> >>>> It just all works better with dedicated hardware. Finding the >>>> leading one for normalization is somewhat slow in the FPGA and >>>> is something that benefits from dedicated hardware. Using a >>>> DSP48 (if we're talking about Xilinx) for a barrel shifter is >>>> fairly fast, but requires 3 cycles of latency, can only shift >>>> up to 18 bits, and is overkill for the task. You're using a >>>> full multiplier as a shifter; a dedicated shifter would be >>>> smaller and faster. All this stuff adds latency. When I pull >>>> up CoreGen and ask for the basic FP adder, I get something that >>>> uses only 2 DSP48s but has 12 cycles of latency. And there is a >>>> lot of fabric routing so timing is not very deterministic. >>> >>> I'm not sure how much you know about multipliers and shifters. >>> Multipliers are not magical. Multiplexers *are* big. A >>> multiplier has N stages with a one bit adder at every bit >>> position. A barrel multiplexer has nearly as many bit positions >>> (you typically don't need all the possible outputs), but uses a >>> bit less logic at each position. Each bit position still needs a >>> full 4 input LUT. Not tons of difference in complexity. >>> >> >> A 32-bit barrel shifter can be made with 5 steps, each step being a >> set of 32 two-input multiplexers. Dedicated hardware for that will >> be /much/ smaller and more efficient than using LUTs or a full >> multiplier. >> >> Normalisation of FP results also requires a "find first 1" >> operation. Again, dedicated hardware is going to be a lot smaller >> and more efficient than using LUT's. >> >> So a DSP block that has dedicated FP support is going to be smaller >> and faster than using integer DSP blocks with LUT's to do the same >> job. >> >>> The multipliers I've seen have selectable latency down to 1 >>> clock. Rolling a barrel shifter will generate many layers of >>> logic that will need to be pipelined as well to reach high >>> speeds, likely many more layers for the same speeds. >>> >>> What do you get if you design a floating point adder in the >>> fabric? I can only imagine it will be *much* larger and slower. >>> > > If I understand, you can do a barrel shifter with log2(n) complexity, > hence your 5 steps but you will have the combitional delays of 5 > muxes, it could limit your maximum clock frequency. A brute force > approach will use more resoures but will probably allow a higher > clock frequency. > The "brute force" method would be 1 layer of 32 32-input multiplexers. And how do you implement a 32-input multiplexer in gates? You basically have 5 layers of 2-input multiplexers. If the depth of the multiplexer is high enough, you might use tri-state gates but I suspect that in this case you'd implement it with normal logic.Article: 159674
On 1/27/2017 3:17 AM, David Brown wrote: > On 27/01/17 05:39, rickman wrote: >> On 1/26/2017 9:38 PM, Kevin Neilson wrote: >>>>> >>>>> I think you oversimplify FP. It works a lot better with >>>>> dedicated hardware. >>>> >>>> Not sure what your point is. The principles are the same in >>>> software or hardware. I was describing hardware I have worked on. >>>> ST-100 from Star Technologies. I became very intimate with the >>>> inner workings. >>>> >>>> The only complications are from the various error and special case >>>> handling of the IEEE-754 format. I doubt the FPGA is implementing >>>> that, but possibly. The basics are still the same. Adds use a >>>> barrel shifter to denormalize the mantissa so the exponents are >>>> equal, a integer adder and a normalization barrel shifter to >>>> produce the result. Multiplies use a multiplier for the mantissas >>>> and an adder for the exponents (with adjustment for exponent bias) >>>> followed by a simple shifter to normalize the result. >>>> >>>> Both add and multiply are about the same level of complexity as a >>>> barrel shifter is almost as much logic as the multiplier. >>>> >>>> Other than the special case handling of IEEE-754, what do you think >>>> I am missing? >>>> >>>> -- >>>> >>>> Rick C >>> >>> It just all works better with dedicated hardware. Finding the >>> leading one for normalization is somewhat slow in the FPGA and is >>> something that benefits from dedicated hardware. Using a DSP48 (if >>> we're talking about Xilinx) for a barrel shifter is fairly fast, but >>> requires 3 cycles of latency, can only shift up to 18 bits, and is >>> overkill for the task. You're using a full multiplier as a shifter; >>> a dedicated shifter would be smaller and faster. All this stuff adds >>> latency. When I pull up CoreGen and ask for the basic FP adder, I >>> get something that uses only 2 DSP48s but has 12 cycles of latency. >>> And there is a lot of fabric routing so timing is not very >>> deterministic. >> >> I'm not sure how much you know about multipliers and shifters. >> Multipliers are not magical. Multiplexers *are* big. A multiplier has >> N stages with a one bit adder at every bit position. A barrel >> multiplexer has nearly as many bit positions (you typically don't need >> all the possible outputs), but uses a bit less logic at each position. >> Each bit position still needs a full 4 input LUT. Not tons of >> difference in complexity. >> > > A 32-bit barrel shifter can be made with 5 steps, each step being a set > of 32 two-input multiplexers. Dedicated hardware for that will be > /much/ smaller and more efficient than using LUTs or a full multiplier. Yes, I stand corrected. Still, it is hardly a "waste" of multipliers to use them for multiplexers. > Normalisation of FP results also requires a "find first 1" operation. > Again, dedicated hardware is going to be a lot smaller and more > efficient than using LUT's. Find first 1 can be done using a carry chain which is quite fast. It is the same function as used in Gray code operations. > So a DSP block that has dedicated FP support is going to be smaller and > faster than using integer DSP blocks with LUT's to do the same job. Who said it wouldn't be? I say exactly that below. My point was just that floating point isn't too hard to wrap your head around and not so horribly different from fixed point. You just need to stick a few functions onto a fixed point multiplier/adder. I was responding to: "Is this really a thing, or are they wrapping some more familiar fixed- point processing with IP to make it floating point?" The difference between fixed and floating point operations require a few functions beyond the basic integer operations which we have been discussing. Floating point is not magic or incredibly hard to do. It has not been included on FPGAs up until now because the primary market is integer based. Some 15 years ago I discussed the need for hard IP in FPGAs and was told by certain Xilinx employees that it isn't practical to include hard IP because of the proliferation of combinations and wasted resources that result. The trouble is the ratio of silicon area required for hard IP vs. FPGA fabric gets worse with each larger generation. So as we see now FPGAs are including all manner of functio blocks.... like other devices. What I don't get is why FPGAs are so special that they are the last hold out of becoming system on chip devices. >> The multipliers I've seen have selectable latency down to 1 clock. >> Rolling a barrel shifter will generate many layers of logic that will >> need to be pipelined as well to reach high speeds, likely many more >> layers for the same speeds. >> >> What do you get if you design a floating point adder in the fabric? I >> can only imagine it will be *much* larger and slower. -- Rick C
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