Maker Pro
Maker Pro

Re: Intel details future Larrabee graphics chip

M

MooseFET

Jan 1, 1970
0
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.
 
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?
 
M

Muzaffer Kal

Jan 1, 1970
0
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?
 
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.
 
K

krw

Jan 1, 1970
0
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.
 
K

krw

Jan 1, 1970
0
[email protected]>, [email protected]
says...
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.
We were talking of the tools that are free or low cost that come from
the makers of the chips.

Usualy false economics.
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.
 
J

JosephKK

Jan 1, 1970
0
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.
 
J

JosephKK

Jan 1, 1970
0
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?
 
M

MooseFET

Jan 1, 1970
0
[. 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.
 
M

MooseFET

Jan 1, 1970
0
When you assign "Z" to external pin - Quartus compiles it very well,
thank you.

Have you done it? I am surprised if they have fixed it. I had to
recode to use the tri() to get the tri-state pins to work. I had
defined a component with the tristate pins that I connected directly
to the pins of the chip. The compiler would choke on it. The same
code compiled on Cypress's "warp" and produced exactly the tristated
pin I expected.
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?

I didn't do this but yes a compiler could easily turn it into
something like this to send to the fitter:

Y = X1 & EN1 # X2 & EN2 # X3 & EN3;

There is no need to make a full mux because there should only be one
assignment of a non-Z value at a time and thus only one EN# would be
true.
 
M

MooseFET

Jan 1, 1970
0
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.

When the total sales of something is likely to be 10 units, a 100K
tool just for that project does make cost an object but this isn't the
only nor really my biggest problem with them.

Imagine the product has been in production for 10 years and somebody
discovers a (gasp) bug. You now have to fire up that old tool and fix
the bug. With rented software you can't just do that this means that
there will be the urge by management not to fix that bug and a delay
in fixing it.

Imagine that the vendor for a chip is standing in front of you with a
chip that he claims will implement your logic equations. You have
your equations and he has his chip. Until you have compiled them and
put them into the chip, there is no proof that the chip will really do
the job. Needing to pay a lot of money just to find out it won't
work isn't something I like to do.
 
Have you done it?

Of course.
I am surprised if they have fixed it. I had to
recode to use the tri() to get the tri-state pins to work. I had
defined a component with the tristate pins that I connected directly
to the pins of the chip. The compiler would choke on it. The same
code compiled on Cypress's "warp" and produced exactly the tristated
pin I expected.

Did your component had tristate pins defined as out or inout?
The later, indeed, had problems until relatively recently but the
former always worked as expected.
I, personally, always prefer to have separate in and out ports in
internal components, so I wasn't hit by earlier bugs.

Why they fixed it at the end? I think, the main reason was SOPC
builder. They wanted the same SOPC builder output to work both as a
top level project and as a component so they had little choise.
Hopefully, by now, they realized that except for the toy problems no
sane developer will use SOPC builder output as a top level but the
inout fix is done already and there are no reason to go back.
I didn't do this but yes a compiler could easily turn it into
something like this to send to the fitter:

Y = X1 & EN1 # X2 & EN2 # X3 & EN3;

There is no need to make a full mux because there should only be one
assignment of a non-Z value at a time and thus only one EN# would be
true.

As I said in another post, nobody here codes this way so I have no
idea whether the compiler does the right thing.

P.S.
I added comp.arch.fpga to the list. Let's see the opinion of real
experts.
 
W

Wilco Dijkstra

Jan 1, 1970
0
JosephKK said:
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?

IEEE doesn't make any requirements on how you implement languages,
neither does C require a particular FP format (although C99 strongly
recommends IEEE-754 with 32-bit float and 64-bit double).

The IEEE format is pretty well thought out. The exponent bias doesn't
cause any issues - in most cases you don't have to worry about it.
The format allows you to compare floating point numbers without
decoding them into sign, exponent and mantissa. As a result, you can
increment/decrement encoded FP numbers to get the next larger/smaller
value.

Wilco
 
N

Nick Maclaren

Jan 1, 1970
0
|>
|> The IEEE format is pretty well thought out.

That is a matter of opinion. A large number of experts, in many
aspects of numerical computing, disagree.

|> The IEEE format is pretty well thought out. The exponent bias doesn't
|> cause any issues - in most cases you don't have to worry about it.

That is true.

|> The format allows you to compare floating point numbers without
|> decoding them into sign, exponent and mantissa. As a result, you can
|> increment/decrement encoded FP numbers to get the next larger/smaller
|> value.

That isn't. Excluding the fact that they are signed magnitude and
most integers are twos' complement, that won't work at either
extreme or at zero.


Regards,
Nick Maclaren.
 
W

Wilco Dijkstra

Jan 1, 1970
0
Nick Maclaren said:
|>
|> The IEEE format is pretty well thought out.

That is a matter of opinion. A large number of experts, in many
aspects of numerical computing, disagree.

What is wrong in your opinion and how would you improve it?
|> The IEEE format is pretty well thought out. The exponent bias doesn't
|> cause any issues - in most cases you don't have to worry about it.

That is true.

|> The format allows you to compare floating point numbers without
|> decoding them into sign, exponent and mantissa. As a result, you can
|> increment/decrement encoded FP numbers to get the next larger/smaller
|> value.

That isn't. Excluding the fact that they are signed magnitude and
most integers are twos' complement, that won't work at either
extreme or at zero.

You can't count through zero or past Infinity indeed. But you can count up
from zero all the way to infinity without any checks. I use this fact to first
encode the result and then round by just incrementing it - no special case
checking when rounding denormals, or round up to infinity. Comparisons
take just a few instructions despite the difference between sign-magnitude
and 2-complement.

Wilco
 
N

Nick Maclaren

Jan 1, 1970
0
|>
|> > |> The IEEE format is pretty well thought out.
|> >
|> > That is a matter of opinion. A large number of experts, in many
|> > aspects of numerical computing, disagree.
|>
|> What is wrong in your opinion and how would you improve it?

This has been described ad tedium. I would start by defining a
clear, consistent objective and work from there. It doesn't
matter so much WHAT the objective is, provided that it HAS one.


Regards,
Nick Maclaren.
 
M

MooseFET

Jan 1, 1970
0
Of course.


Did your component had tristate pins defined as out or inout?

IIRC: Some were inout because they were bidirectional to the same
part. Others were outputs of one part but inputs to another. This
was a data bus situation.

I had two Cygnal F124 CPUs and a DMAed input sharing 512K * 8 RAM.
The result was that I needed two 8 bit true I/O busses and a MUXed bus
at the RAM.
 
W

Wilco Dijkstra

Jan 1, 1970
0
Nick Maclaren said:
|>
|> > |> The IEEE format is pretty well thought out.
|> >
|> > That is a matter of opinion. A large number of experts, in many
|> > aspects of numerical computing, disagree.
|>
|> What is wrong in your opinion and how would you improve it?

This has been described ad tedium. I would start by defining a
clear, consistent objective and work from there. It doesn't
matter so much WHAT the objective is, provided that it HAS one.

IEEE achieved its objective a long time ago: just about all hardware
and software uses it. So that is not the problem. However it doesn't
explicitly allow a subset of the features to be supported, which is what
almost all implementations do.

Flushing denormals to zero is one key feature that is missing for example.
Similarly round-to-even is the only rounding mode ever used. It would be
easy to fix the standard to make the current defacto situation official.

Wilco
 
N

Nick Maclaren

Jan 1, 1970
0
|>
|> > |> > |> The IEEE format is pretty well thought out.
|> > |> >
|> > |> > That is a matter of opinion. A large number of experts, in many
|> > |> > aspects of numerical computing, disagree.
|> > |>
|> > |> What is wrong in your opinion and how would you improve it?
|> >
|> > This has been described ad tedium. I would start by defining a
|> > clear, consistent objective and work from there. It doesn't
|> > matter so much WHAT the objective is, provided that it HAS one.
|>
|> IEEE achieved its objective a long time ago: just about all hardware
|> and software uses it.

That is a political objective, not a technical one; I was referring
to a technical objective. If your objective is to eliminate all
alternatives, whether or not they are better, as well as potential
for future improvement, then you and I will never agree.

|> So that is not the problem. However it doesn't
|> explicitly allow a subset of the features to be supported, which is what
|> almost all implementations do.

In different ways, which means that it hasn't even achieved its
political objective in full.

|> Flushing denormals to zero is one key feature that is missing for example.
|> Similarly round-to-even is the only rounding mode ever used. It would be
|> easy to fix the standard to make the current defacto situation official.

Which? I know of dozens of variants.


Regards,
Nick Maclaren.
 
W

Wilco Dijkstra

Jan 1, 1970
0
Nick Maclaren said:
|>
|> > |> > |> The IEEE format is pretty well thought out.
|> > |> >
|> > |> > That is a matter of opinion. A large number of experts, in many
|> > |> > aspects of numerical computing, disagree.
|> > |>
|> > |> What is wrong in your opinion and how would you improve it?
|> >
|> > This has been described ad tedium. I would start by defining a
|> > clear, consistent objective and work from there. It doesn't
|> > matter so much WHAT the objective is, provided that it HAS one.
|>
|> IEEE achieved its objective a long time ago: just about all hardware
|> and software uses it.

That is a political objective, not a technical one; I was referring
to a technical objective.

I wouldn't call it political at all - the goals of standards are obvious and
non-political (the *process* of establishing a standard is often political,
but that is a different matter altogether).
If your objective is to eliminate all
alternatives, whether or not they are better, as well as potential
for future improvement, then you and I will never agree.

It is true standards end up targetting the lowest common denominator,
and as such fall short of technical excellence. However the IEEE format
represents a major advance over other formats on almost all aspects,
so it deservedly killed many badly designed formats. If someone comes
up with an even better format then I am all for it - though I doubt it can be
improved much.
|> So that is not the problem. However it doesn't
|> explicitly allow a subset of the features to be supported, which is what
|> almost all implementations do.

In different ways, which means that it hasn't even achieved its
political objective in full.

Well the main goal was to create a common binary format which gives
identical results on all implementations. That is exactly what we have
today, so it is an example of a standard that worked well.
|> Flushing denormals to zero is one key feature that is missing for example.
|> Similarly round-to-even is the only rounding mode ever used. It would be
|> easy to fix the standard to make the current defacto situation official.

Which? I know of dozens of variants.

I know a compiler that supports 5 variants, but there aren't any useful
variants beyond that. Even that is too much, I think just 1 or 2 commonly
used subsets would be sufficient to capture 99% of implementations.

Wilco
 
Top