Intel details future Larrabee graphics chip

MooseFET wrote:
> On Aug 27, 1:16 pm, Kim Enkovaara wrote:
>> Even with FPGAs the code can be quite portable. Usually quite small
>>...
> I have never seen a case of FPGA code going between Xilinx's tools and
> Altera's without some very serious rewriting.

Then you have something wrong in your coding style. Normally if some
portability is taken into consideration during design, porting takes
few days to get first impressions. Usually what is needed is some
tweaking of attributes in inferred memories, new clocking scheme
(PLL etc.) and maybe some IO pin instantiations if DDR or very
high speed signaling is used. For some higher level IP (tranceivers,
PCI express etc.) more effort is needed, but that can be handled
by portability layers.

With third party synthesizer scripts need only minor changes. And even
with the integrated ones usually some editor tweaking can be used
to get most of the scripts converted. STA is the most painful thing
to convert, that will take some time. But that is only loosely part
of the code, and Synopsys SDC format is gaining ground in FPGA tools
also.

It is quite normal to code the FPGA to support many different chips
and keep the vendors fighting with price to the end and select the
one that was the cheapest

--Kim

On Aug 27, 11:11*pm, Kim Enkovaara wrote:
> MooseFET wrote:
> > On Aug 27, 1:16 pm, Kim Enkovaara wrote:
> >> Even with FPGAs the code can be quite portable. Usually quite small
> >>...
> > I have never seen a case of FPGA code going between Xilinx's tools and
> > Altera's without some very serious rewriting.
>
> Then you have something wrong in your coding style. Normally if some
> portability is taken into consideration during design, porting takes
> few days to get first impressions.

I wasn't referring to just my code when I said "seen".

Do you use the assignment of the "Z" value to cause a tri-state?
Quartus doesn't compile them.


> Usually what is needed is some
> tweaking of attributes in inferred memories, new clocking scheme
> (PLL etc.) and maybe some IO pin instantiations if DDR or very
> high speed signaling is used. For some higher level IP (tranceivers,
> PCI express etc.) more effort is needed, but that can be handled
> by portability layers.
>
> With third party synthesizer scripts need only minor changes. And even
> with the integrated ones usually some editor tweaking can be used
> to get most of the scripts converted. STA is the most painful thing
> to convert, that will take some time. But that is only loosely part
> of the code, and Synopsys SDC format is gaining ground in FPGA tools
> also.

We were talking of the tools that are free or low cost that come from
the makers of the chips.


> It is quite normal to code the FPGA to support many different chips
> and keep the vendors fighting with price to the end and select the
> one that was the cheapest

I really don't care which chip is the cheapest. In the market I'm in,
nearly all electronic designs are a "cost is no object" sort of
thing. The first 3 tings on the list are reliability. Then comes low
power and light weight.

On Aug 28, 3:58 pm, MooseFET wrote:
> On Aug 27, 11:11 pm, Kim Enkovaara wrote:
>
> > MooseFET wrote:
> > > On Aug 27, 1:16 pm, Kim Enkovaara wrote:
> > >> Even with FPGAs the code can be quite portable. Usually quite small
> > >>...
> > > I have never seen a case of FPGA code going between Xilinx's tools and
> > > Altera's without some very serious rewriting.
>
> > Then you have something wrong in your coding style. Normally if some
> > portability is taken into consideration during design, porting takes
> > few days to get first impressions.
>
> I wasn't referring to just my code when I said "seen".
>
> Do you use the assignment of the "Z" value to cause a tri-state?
> Quartus doesn't compile them.
>

When you assign "Z" to external pin - Quartus compiles it very well,
thank you.
On the other hand, internal tristate nodes are not supported by Altera
architecture - how would you expect Quartus to synthesize them in this
case? Infer muxes?

On Thu, 28 Aug 2008 06:50:25 -0700 (PDT), already5chosen-at-yahoo.com
wrote:

>On Aug 28, 3:58 pm, MooseFET wrote:
>> On Aug 27, 11:11 pm, Kim Enkovaara wrote:
>>
>> > MooseFET wrote:
>> > > On Aug 27, 1:16 pm, Kim Enkovaara wrote:
>> > >> Even with FPGAs the code can be quite portable. Usually quite small
>> > >>...
>> > > I have never seen a case of FPGA code going between Xilinx's tools and
>> > > Altera's without some very serious rewriting.
>>
>> > Then you have something wrong in your coding style. Normally if some
>> > portability is taken into consideration during design, porting takes
>> > few days to get first impressions.
>>
>> I wasn't referring to just my code when I said "seen".
>>
>> Do you use the assignment of the "Z" value to cause a tri-state?
>> Quartus doesn't compile them.
>>
>
>When you assign "Z" to external pin - Quartus compiles it very well,
>thank you.
>On the other hand, internal tristate nodes are not supported by Altera
>architecture - how would you expect Quartus to synthesize them in this
>case? Infer muxes?

Actually MaxplusII had support for converting internal tri-states to
muxes. That feature is removed in Quartus?

On Aug 28, 6:09 pm, Muzaffer Kal wrote:
> On Thu, 28 Aug 2008 06:50:25 -0700 (PDT), already5cho...@yahoo.com
> wrote:
>
>
>
> >On Aug 28, 3:58 pm, MooseFET wrote:
> >> On Aug 27, 11:11 pm, Kim Enkovaara wrote:
>
> >> > MooseFET wrote:
> >> > > On Aug 27, 1:16 pm, Kim Enkovaara wrote:
> >> > >> Even with FPGAs the code can be quite portable. Usually quite small
> >> > >>...
> >> > > I have never seen a case of FPGA code going between Xilinx's tools and
> >> > > Altera's without some very serious rewriting.
>
> >> > Then you have something wrong in your coding style. Normally if some
> >> > portability is taken into consideration during design, porting takes
> >> > few days to get first impressions.
>
> >> I wasn't referring to just my code when I said "seen".
>
> >> Do you use the assignment of the "Z" value to cause a tri-state?
> >> Quartus doesn't compile them.
>
> >When you assign "Z" to external pin - Quartus compiles it very well,
> >thank you.
> >On the other hand, internal tristate nodes are not supported by Altera
> >architecture - how would you expect Quartus to synthesize them in this
> >case? Infer muxes?
>
> Actually MaxplusII had support for converting internal tri-states to
> muxes. That feature is removed in Quartus?

We never used Altera-provide VHDL or Verilog synthesis on MaxplusII -
only Altera's AHDL or 3rd party synthesis for standard HDLs. So I have
no idea how Altera's synthesis on MaxplussII handled 'Z' - AHDL simply
doesn't have it.
On the other hand, on QuartusII we never ever used 3rd-party VHDL
synthesis tools since Altera's own are good enough. For me, it proves
that VHDL front end was completely redone during M->Q transition. I
vaguely remember reading (on c.a.fpga? ) that they bought a front end
from somebody else.
Does a new synthesis infer muxes for internal 3-state nodes? I don't
know. I nobody here tried to code this way.

In article ,
kim.enkovaara-at-iki.fi says...
> MooseFET wrote:
> > On Aug 27, 1:16 pm, Kim Enkovaara wrote:
> >> Even with FPGAs the code can be quite portable. Usually quite small
> >>...
> > I have never seen a case of FPGA code going between Xilinx's tools and
> > Altera's without some very serious rewriting.
>
> Then you have something wrong in your coding style. Normally if some
> portability is taken into consideration during design, porting takes
> few days to get first impressions. Usually what is needed is some
> tweaking of attributes in inferred memories, new clocking scheme
> (PLL etc.) and maybe some IO pin instantiations if DDR or very
> high speed signaling is used. For some higher level IP (tranceivers,
> PCI express etc.) more effort is needed, but that can be handled
> by portability layers.

Portability is also highly dependent on special features and IP
blocks used. Some can be quite difficult to port. Older
synthesizers didn't infer complex logic functions well so people
relied on IP cores for simple things. There are loads of reasons
designs may be difficult to port, though it's not often necessary
(or considered during design).

> With third party synthesizer scripts need only minor changes. And even
> with the integrated ones usually some editor tweaking can be used
> to get most of the scripts converted. STA is the most painful thing
> to convert, that will take some time. But that is only loosely part
> of the code, and Synopsys SDC format is gaining ground in FPGA tools
> also.
>
> It is quite normal to code the FPGA to support many different chips
> and keep the vendors fighting with price to the end and select the
> one that was the cheapest

You may think it's normal, but I've not seen it actually done. The
project I've been involved with are heavily weighted towards
engineering costs. The cost of the FPGA, while pretty impressive on
the face of it, is peanuts compared to the total system cost.

--
Keith

In article 51584affba5f-at-a8g2000prf.googlegroups.com>, kensmith-at-rahul.net
says...
> On Aug 27, 11:11*pm, Kim Enkovaara wrote:
> > MooseFET wrote:
> > > On Aug 27, 1:16 pm, Kim Enkovaara wrote:
> > >> Even with FPGAs the code can be quite portable. Usually quite small
> > >>...
> > > I have never seen a case of FPGA code going between Xilinx's tools and
> > > Altera's without some very serious rewriting.
> >
> > Then you have something wrong in your coding style. Normally if some
> > portability is taken into consideration during design, porting takes
> > few days to get first impressions.
>
> I wasn't referring to just my code when I said "seen".
>
> Do you use the assignment of the "Z" value to cause a tri-state?
> Quartus doesn't compile them.

Does it have a way to direct the synthesizer to infer muxes? Last
time I ran into this (I no longer code 'Z's for anything other than
I/Os) was moons ago when I was using Synplify. Synplify could be
directed to infer tristates or muxes.

> > Usually what is needed is some
> > tweaking of attributes in inferred memories, new clocking scheme
> > (PLL etc.) and maybe some IO pin instantiations if DDR or very
> > high speed signaling is used. For some higher level IP (tranceivers,
> > PCI express etc.) more effort is needed, but that can be handled
> > by portability layers.
> >
> > With third party synthesizer scripts need only minor changes. And even
> > with the integrated ones usually some editor tweaking can be used
> > to get most of the scripts converted. STA is the most painful thing
> > to convert, that will take some time. But that is only loosely part
> > of the code, and Synopsys SDC format is gaining ground in FPGA tools
> > also.
>
> We were talking of the tools that are free or low cost that come from
> the makers of the chips.

Usualy false economics.

> > It is quite normal to code the FPGA to support many different chips
> > and keep the vendors fighting with price to the end and select the
> > one that was the cheapest
>
> I really don't care which chip is the cheapest. In the market I'm in,
> nearly all electronic designs are a "cost is no object" sort of
> thing. The first 3 tings on the list are reliability. Then comes low
> power and light weight.

Do you really care about the cost of the tools then? BTW, so far
I've been in the same boat (cost is no object) but it seems that
I'll have to try on the other boot soon.

--
Keith

On Wed, 27 Aug 2008 06:15:36 -0700 (PDT), MooseFET
wrote:

>On Aug 27, 1:54 pm, JosephKK wrote:
>> On Wed, 27 Aug 2008 00:05:47 +0100, "Wilco Dijkstra"
>>
>>
>>
>> wrote:
>>
>> >"MooseFET" wrote in message
>> >news:ac9d3411-d83d-49d5-8310-bd649ed43a69-at-n33g2000pri.googlegroups.com...
>> >> On Aug 26, 7:51 pm, Terje Mathisen
>> >> wrote:
>> >>> JosephKK wrote:
>> >>> > On 25 Aug 2008 18:32:43 GMT, n...@cus.cam.ac.uk (Nick Maclaren) wrote:
>> >>> >> That doesn't help with denormals, though! You can't always use them
>> >>> >> in denormalised form, and can rarely use the same code as for normal
>> >>> >> numbers unless you normalise them.
>>
>> >>> >> Regards,
>> >>> >> Nick Maclaren.
>>
>> >>> > Would you kindly explain to me how to normalize a denormal without
>> >>> > expanding the exponent range?
>>
>> >>> You don't.
>>
>> >>> I.e. a sw library will almost certainly choose to work in an internal
>> >>> exponent format with a lot more bits, like a 32-bit int.
>>
>> >>> To follow the spec you have to denormalize (if needed) the result again
>> >>> after each operation, unless you can fake it exactly.
>>
>> >>> One possible idea would be to mask away (with proper rounding) the
>> >>> bottom bits that would have been shifted away during the conversion to
>> >>> external exponent range.
>>
>> >> If I was coding such a library I would most likely convert to an
>> >> internal format with a longer mantissa and a base 256 exponent. While
>> >> the numbers are being held in the internals, a few extra bytes needed
>> >> for such a format would be a low price to pay for the greater speed.
>>
>> >> A base 256 number with a longer mantissa speeds up adding and
>> >> subtracting at the cost of some speed in the multiply and divide.
>> >> Making the mantissa a multiple of the natural word length of the
>> >> processor, gets you most of that back.
>>
>> >The mantissa would normally already be 32-bit or 64-bit internally.
>> >Addition is already as simple as:
>>
>> >res = manta + (mantb >> (expa - expb));
>>
>> >I can't see how rebasing the exponent could possibly simplify this.
>>
>> >Wilco
>>
>> Would the both of you try reading IEEE 754 please?
>
>Yes, I know that he didn't show the right operation for the alignment
>before the add, but I don't think it matters to my disagreement with
>him since the right one requires an extra bit of "if" logic and
>depending on the exponent the prepending of a one.

Perhaps you have read it. That is one strange format though.
Essentially using the sign bit in combination with the mantissa to
squeeze one more bit of resolution out.

On Wed, 27 Aug 2008 10:17:15 +0100, "Wilco Dijkstra"
wrote:

>
>"JosephKK" wrote in message news:62r9b4hafqbn5nuaiu4379prqguunokgqt-at-4ax.com...
>> On Tue, 26 Aug 2008 23:56:47 +0100, "Wilco Dijkstra"
>> wrote:
>>
>>>
>>>"Terje Mathisen" wrote in message news:PKydnRanqZPHcy7VnZ2dnUVZ8srinZ2d-at-giganews.com ...
>>>> JosephKK wrote:
>>>>> On 25 Aug 2008 18:32:43 GMT, nmm1-at-cus.cam.ac.uk (Nick Maclaren) wrote:
>>>>>> That doesn't help with denormals, though! You can't always use them
>>>>>> in denormalised form, and can rarely use the same code as for normal
>>>>>> numbers unless you normalise them.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Nick Maclaren.
>>>>>
>>>>> Would you kindly explain to me how to normalize a denormal without
>>>>> expanding the exponent range?
>>>>>
>>>> You don't.
>>>>
>>>> I.e. a sw library will almost certainly choose to work in an internal exponent format with a lot more bits, like a
>>>> 32-bit int.
>>>>
>>>> To follow the spec you have to denormalize (if needed) the result again after each operation, unless you can fake it
>>>> exactly.
>>>>
>>>> One possible idea would be to mask away (with proper rounding) the bottom bits that would have been shifted away
>>>> during the conversion to external exponent range.
>>>
>>>You can often use unnormalized denormals but with the exponent forced
>>>to 1. This gives the correct result for add/sub and multiply but it's usually
>>>better to normalize division and square root.
>>>
>>>When you normalize you just need an extra exponent bit to allow for
>>>negative exponents. I often bias the exponent by 1 so that the largest
>>>denormal has exponent -1 (rather than 0). This allows the overflow
>>>and underflow tests to be done using a single compare. It also makes
>>>recombining the exponent and mantissa easier.
>>>
>>>You can use a wider internal format for the calculations as long as no
>>>rounding is done to the internal format. You can only round once when
>>>you create the final result with the reduced exponent/mantissa (ie.
>>>rounding must be done on the final denormal value).
>>>
>>>Wilco
>>>
>>
>> And what actual hardware are taking about?
>
>We were talking about emulating IEEE in software, so it works on any
>hardware. My C implementation requires a 32-bit type, so as long as your
>compiler has one, it will work.
>
>Wilco
>

The compiler itself does not need to define one, the language itself
allows you to define one. IIRC the IEE-754 also requires definition
of the 64-bit form as well. Aren't the exponent offsets fun as well?

On Aug 29, 8:05 pm, JosephKK wrote:
[. IEEE 754 ....]
[...]
> Perhaps you have read it. That is one strange format though.
> Essentially using the sign bit in combination with the mantissa to
> squeeze one more bit of resolution out.

I had seen the implied bit idea elsewhere. The idea of using up codes
to specify things like NAN, +INF and -INF are things that I have found
myself disagreeing with. I have never liked "in band signaling".
That is the only part of the standard I found to be strange.

I had to convert some all positive fixed point numbers to IEEE so that
is the only part I really spent much time on.