Re: Future architectures [was Re: Intel details future Larrabee ...]
already...@yahoo.com
> On Aug 28, 9:50 pm, already5cho...@yahoo.com wrote:
>
>
>
> > On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote:
>
> > > On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
>
> > > > MooseFET wrote:
> > > > > On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> 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.
>
> 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.
> > 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.
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.
MooseFET
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.