Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 145800

Article: 145800
Subject: Re: using an FPGA to emulate a vintage computer
From: Eric Chomko <pne.chomko@comcast.net>
Date: Wed, 24 Feb 2010 11:17:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 23, 5:37=A0pm, Charles Richmond <friz...@tx.rr.com> wrote:
> Charles Richmond wrote:
> > (see below) wrote:
> >> On 23/02/2010 17:48, in article
> >> 4178548f-5618-49dd-ad72-008bdb53e...@z25g2000vbb.googlegroups.com, "Er=
ic
> >> Chomko" <pne.cho...@comcast.net> wrote:
>
> >> =A0 =A0[snip...] =A0 =A0 =A0 =A0 =A0 =A0[snip...] =A0 =A0 =A0 =A0 =A0 =
=A0[snip...]
>
> >>> Speaking of ALGOL parameter passing, what's a "thunk"?
>
> >> A thunk is the anonymous function (pair) described above.
>
> > A "thunk" was a method of implementing "call by name".
>
> http://www.jargon.net/jargonfile/t/thunk.html
>

Thanks for the above reference. It had everything except "throwing
functions" as thunk, which is how I had heard it referenced.


Article: 145801
Subject: Re: using an FPGA to emulate a vintage computer
From: Eric Chomko <pne.chomko@comcast.net>
Date: Wed, 24 Feb 2010 11:31:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 23, 2:07=A0pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> On 23/02/2010 17:52, in article
> 3ec03225-3a0f-4bcd-9db1-51201d1b3...@w12g2000vbj.googlegroups.com, "Eric
>
> Chomko" <pne.cho...@comcast.net> wrote:
> > But an ALGOL "activation record" (stack frame) had a lot more than
> > that. As I recall, they copied a lot more just pointers and parameter
> > values.
>
> Just the usual red tape: return address, frame pointer of caller; and eit=
her
> a static pointer or some housekeeping for 'display' registers (if used) t=
o
> access non-locals. But bear in mind that in decent languages arrays are
> storable values, so a value array parameter gets copied in toto, unlike C=
.
>

Are you saying that C doesn't implement true recursion? I have only
used recursion in college and not with C. ALGOL, SIMPL-T and LISP were
the only languages I used to write recursive algorithms.


Article: 145802
Subject: Re: using an FPGA to emulate a vintage computer
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 24 Feb 2010 12:19:35 -0800 (PST)
Links: << >>  << T >>  << A >>
glen,

"More to the hardware side, an architecture still exists even
if no implementations of it exist.  (Though in most cases at
least one still does.)  "

Can you list them fully? I am interested in them.

Weng

Article: 145803
Subject: Re: using an FPGA to emulate a vintage computer
From: Michael Wojcik <mwojcik@newsguy.com>
Date: Wed, 24 Feb 2010 15:37:30 -0500
Links: << >>  << T >>  << A >>
(see below) wrote:
> 
> Just the usual red tape: return address, frame pointer of caller; and either
> a static pointer or some housekeeping for 'display' registers (if used) to
> access non-locals. But bear in mind that in decent languages arrays are
> storable values, so a value array parameter gets copied in toto, unlike C.

It will be in C if the array is wrapped in a struct. Letting array
parameters decay to pointers was a feature of early C that couldn't be
changed for historical reasons, but when the standardization committee
added support for struct parameters, they made them first-class.

struct (and not the misnamed "typedef") is C's mechanism for creating
new types and ADTs, so if you want a pass-by-value array in C, the
correct thing to do is to put it in a struct.

This is not to say that C's parameter passing doesn't still have a
number of infelicities. Exposing the use of pointers to implement
pass-by-reference (which C lacks, strictly speaking) has some
advantages, but it has led to great confusion over matters like the
const and restrict qualifiers.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Article: 145804
Subject: Re: FPGA platform??
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Wed, 24 Feb 2010 13:47:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On 23 Feb., 15:52, Petter Gustad <newsmailco...@gustad.com> wrote:
> Thomas Stanka <usenet_nospam_va...@stanka-web.de> writes:
> > For normal FPGA Design Windows is common, as some (backend-) FPGA
> > tools are either Windows only or show better performance under
> > Windows.
>
> Which tools do you have in mind here?

AFAIK you get the free Modelsim version only for Windows(32bit) from
Xilinx. The free suite for Altera (Webedition) seems to be windows
only, linux requires licensing.
Several parts of the design suites ISPLever are Windows only,
Programming Actel FPGAs is only possible using Windows...

The versions of ISE I used showed not that good performance on linux.
Quartus Linux is only titled Beta, never worked with, but guess the
same here.
Actel Designer has bad performance on Linux as well.

bye Thomas




Article: 145805
Subject: Xilinx iodelay
From: Chris Maryan <kmaryan@gmail.com>
Date: Wed, 24 Feb 2010 14:21:02 -0800 (PST)
Links: << >>  << T >>  << A >>
Intuitively, the iodelay found in Xilinx parts should be just a tapped
delay line. But the need for a reference clock at a precise frequency
indicates otherwise. Does anyone have any insight into how these are
implemented?

I'm not looking for an exact answer, but any reasonable explanation
would be appreciated. The only idea I had is that it's a chain of FFs
driven on a very fast clock (ref clk multiplied up to give 75ns taps
~13GHz) which seems very improbable).

Any thoughts?

Thanks,

Chris

Article: 145806
Subject: Re: Xilinx iodelay
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 24 Feb 2010 14:41:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 24, 4:21=A0pm, Chris Maryan <kmar...@gmail.com> wrote:
> Intuitively, the iodelay found in Xilinx parts should be just a tapped
> delay line.


Yes, that is what it is.


> But the need for a reference clock at a precise frequency
> indicates otherwise. Does anyone have any insight into how these are
> implemented?

The reference clock is used to calibrate the tapped delay line so that
it has a consistent delay that is resistant to changes in process,
voltage and temperature.


>
> I'm not looking for an exact answer, but any reasonable explanation
> would be appreciated. The only idea I had is that it's a chain of FFs
> driven on a very fast clock (ref clk multiplied up to give 75ns taps
> ~13GHz) which seems very improbable).
>
> Any thoughts?
>
> Thanks,
>
> Chris


Regards,

John McCaskill
www.FasterTechnology.com


Article: 145807
Subject: Re: using an FPGA to emulate a vintage computer
From: "(see below)" <yaldnif.w@blueyonder.co.uk>
Date: Wed, 24 Feb 2010 23:20:16 +0000
Links: << >>  << T >>  << A >>
On 24/02/2010 19:31, in article
d902c75e-e33a-4281-a796-7c56c3276066@o16g2000prh.googlegroups.com, "Eric
Chomko" <pne.chomko@comcast.net> wrote:

> On Feb 23, 2:07 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> On 23/02/2010 17:52, in article
>> 3ec03225-3a0f-4bcd-9db1-51201d1b3...@w12g2000vbj.googlegroups.com, "Eric
>> 
>> Chomko" <pne.cho...@comcast.net> wrote:
>>> But an ALGOL "activation record" (stack frame) had a lot more than
>>> that. As I recall, they copied a lot more just pointers and parameter
>>> values.
>> 
>> Just the usual red tape: return address, frame pointer of caller; and either
>> a static pointer or some housekeeping for 'display' registers (if used) to
>> access non-locals. But bear in mind that in decent languages arrays are
>> storable values, so a value array parameter gets copied in toto, unlike C.
> 
>> 
> 
> Are you saying that C doesn't implement true recursion? I have only
> used recursion in college and not with C. ALGOL, SIMPL-T and LISP were
> the only languages I used to write recursive algorithms.
> 

No. I'm at a loss as to how you could put that interpretation on it.

I'm saying that array parameters in C are not called by value, but they are
in Algol 60 and cognate languages, requiring more stack space than C does.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk



Article: 145808
Subject: Re: using an FPGA to emulate a vintage computer
From: Joe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date: Wed, 24 Feb 2010 16:50:54 -0700
Links: << >>  << T >>  << A >>
Eric Chomko <pne.chomko@comcast.net> writes:

> On Feb 23, 2:07 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> On 23/02/2010 17:52, in article
>> 3ec03225-3a0f-4bcd-9db1-51201d1b3...@w12g2000vbj.googlegroups.com, "Eric
>>
>> Chomko" <pne.cho...@comcast.net> wrote:
>> > But an ALGOL "activation record" (stack frame) had a lot more than
>> > that. As I recall, they copied a lot more just pointers and parameter
>> > values.
>>
>> Just the usual red tape: return address, frame pointer of caller; and either
>> a static pointer or some housekeeping for 'display' registers (if used) to
>> access non-locals. But bear in mind that in decent languages arrays are
>> storable values, so a value array parameter gets copied in toto, unlike C.
>>
>
> Are you saying that C doesn't implement true recursion? I have only
> used recursion in college and not with C. ALGOL, SIMPL-T and LISP were
> the only languages I used to write recursive algorithms.

Yes, C does recursion.  Local variables are also on the stack.
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Article: 145809
Subject: Re: using an FPGA to emulate a vintage computer
From: Joe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date: Wed, 24 Feb 2010 16:55:19 -0700
Links: << >>  << T >>  << A >>
"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 24/02/2010 19:31, in article
> d902c75e-e33a-4281-a796-7c56c3276066@o16g2000prh.googlegroups.com, "Eric
> Chomko" <pne.chomko@comcast.net> wrote:
>
>> On Feb 23, 2:07 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>>> On 23/02/2010 17:52, in article
>>> 3ec03225-3a0f-4bcd-9db1-51201d1b3...@w12g2000vbj.googlegroups.com, "Eric
>>> 
>>> Chomko" <pne.cho...@comcast.net> wrote:
>>>> But an ALGOL "activation record" (stack frame) had a lot more than
>>>> that. As I recall, they copied a lot more just pointers and parameter
>>>> values.
>>> 
>>> Just the usual red tape: return address, frame pointer of caller; and either
>>> a static pointer or some housekeeping for 'display' registers (if used) to
>>> access non-locals. But bear in mind that in decent languages arrays are
>>> storable values, so a value array parameter gets copied in toto, unlike C.
>> 
>>> 
>> 
>> Are you saying that C doesn't implement true recursion? I have only
>> used recursion in college and not with C. ALGOL, SIMPL-T and LISP were
>> the only languages I used to write recursive algorithms.
>> 
>
> No. I'm at a loss as to how you could put that interpretation on it.

You forgot to mention local variables are in the activation record.

When I was an undergrad I spent some time programming FORTRAN on a
Harris /6 (I think it was a /6 -- there's something nagging at the back
of my mind that says it may have been a /7).  Anyway, reading the manual
I discovered that return addresses were stacked, and immediately jumped to
the conclusion that it could do recursion.  It turned out that local
variables were static...  which meant I spent a *long* time figuring out
why my program was producing completely nonsensical results.

As Al Stewart once sang, "I was jumping to conclusions, and one of them
jumped back."
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Article: 145810
Subject: Re: using an FPGA to emulate a vintage computer
From: "(see below)" <yaldnif.w@blueyonder.co.uk>
Date: Thu, 25 Feb 2010 00:16:45 +0000
Links: << >>  << T >>  << A >>
On 24/02/2010 23:55, in article
1bmxyy42ag.fsf@snowball.wb.pfeifferfamily.net, "Joe Pfeiffer"
<pfeiffer@cs.nmsu.edu> wrote:

> When I was an undergrad I spent some time programming FORTRAN on a
> Harris /6 (I think it was a /6 -- there's something nagging at the back
> of my mind that says it may have been a /7).  Anyway, reading the manual
> I discovered that return addresses were stacked, and immediately jumped to
> the conclusion that it could do recursion.  It turned out that local
> variables were static...  which meant I spent a *long* time figuring out
> why my program was producing completely nonsensical results.
> 
> As Al Stewart once sang, "I was jumping to conclusions, and one of them
> jumped back."

People who assumed that FORTRAN local variables *must* be static got jumped
on from the opposite direction when they used FORTRAN compilers that
actually did put them on the stack, as the ANS FORTRAN standard was
carefully worded to permit.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk



Article: 145811
Subject: Re: How a state machine is constructed using latches?
From: rickman <gnuarm@gmail.com>
Date: Wed, 24 Feb 2010 17:33:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 22, 9:41 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 18, 1:13 pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Feb 18, 11:10 am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > On Feb 17, 7:51 pm, rickman <gnu...@gmail.com> wrote:
>
> > > > On Feb 17, 8:05 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > > On Feb 17, 4:29 pm, rickman <gnu...@gmail.com> wrote:
> > > > > > Fight fire with fire!  The two reports below show that both the
> > > > > > missing else and the missing assignment (which is also missing in the
> > > > > > missing else case) produce latches.
>
> > > > > > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
> > > > > > 57:4:57:7|Latch generated from process for signal Latch, probably
> > > > > > caused by a missing assignment in an if or case stmt
> > > > > > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.vhd":
> > > > > > 40:4:40:7|Latch generated from process for signal Comb, probably
> > > > > > caused by a missing assignment in an if or case stmt
>
> > > > > > library ieee;
> > > > > > use ieee.std_logic_1164.all;
> > > > > > use ieee.numeric_std.all;
>
> > > > > > entity LatchSynthTest is
> > > > > >   port(
> > > > > >           CLK                   : in    std_logic ;
> > > > > >           RESET                 : in    std_logic ;
> > > > > >           C01                   : in    std_logic ;
> > > > > >           C02                   : in    std_logic ;
> > > > > >           LatchOutput   : out   std_logic ;
> > > > > >           CombOutput    : out   std_logic
> > > > > >           );
> > > > > > end LatchSynthTest ;
>
> > > > > > architecture behavior of LatchSynthTest is
> > > > > >   SIGNAL Latch          : std_logic;
> > > > > >   SIGNAL Comb           : std_logic;
> > > > > >   SIGNAL LatchReg       : std_logic;
> > > > > >   SIGNAL CombReg        : std_logic;
>
> > > > > > begin
>
> > > > > >   CombOutput    <= CombReg;
> > > > > >   LatchOutput   <= LatchReg;
>
> > > > > >   Process_1 : process(RESET, CLK)
> > > > > >   begin
> > > > > >     if (RESET = '1') then
> > > > > >       LatchReg  <= '0';
> > > > > >       CombReg   <= '0';
> > > > > >     elsif (rising_edge(CLK)) then
> > > > > >       LatchReg  <= Latch;
> > > > > >       CombReg   <= Comb;
> > > > > >     end if;
> > > > > >   end process;
>
> > > > > >   CombProc : process(CombReg, C01, C02)
> > > > > >   begin
> > > > > >     case CombReg is
> > > > > >       when '0' =>
> > > > > >         if (C01 = '1') then
> > > > > >           Comb <= '0';
> > > > > >         elsif (C02 = '1') then
> > > > > >           Comb <= '1';
> > > > > >         else
> > > > > >           -- Here an assignment statement is missing, but it doesn't
> > > > > >           -- generate latch.  It is treated as a null statement. -
> > > > > > Weng
> > > > > >         end if;
> > > > > >       when others =>
> > > > > >         Comb <= '1';
> > > > > >     end case;
> > > > > >   end process;
>
> > > > > >   LatchProc : process(LatchReg, C01, C02)
> > > > > >   begin
> > > > > >     case LatchReg is
> > > > > >       when '0' =>
> > > > > >         if C01 = '1' then
> > > > > >           Latch <= '0';
> > > > > >         elsif C02 = '1' then
> > > > > >           Latch <= '1';
> > > > > >           -- Here the else is missing, and it does
> > > > > >           -- generate latch.  It is treated as a null statement.
> > > > > >         end if;
> > > > > >       when others =>
> > > > > >         Latch <= '1';
> > > > > >     end case;
> > > > > >   end process;
>
> > > > > > end behavior;
>
> > > > > Hi,
> > > > > Thank you, Andy, Rick and everyone, I am wrong in the second point:
> > > > > missing "else" or missing an assignment statement.
>
> > > > > But my first point is how to generate a latch for a compiler. Rick,
> > > > > can you see the floor plan to show how the latch is generated: for the
> > > > > state only or for full states?
>
> > > > > Weng
>
> > > > I'm not clear what you mean by "how".  Are you asking about the detail
> > > > of how it is implemented in the FPGA?  In the Lattice part they used a
> > > > FF as a latch.  A register is between the latch and the output.  They
> > > > drive the latch oddly driving both the clock and the async reset
> > > > inputs with logic, but then if you look at the code what would you
> > > > think is the clock?  I don't see why they did it the way they did, but
> > > > it works correctly according to the VHDL.  With only four inputs I
> > > > would expect they could have just used a single LUT4 and the latch
> > > > with the clock always enabled.
>
> > > > Din == '1'
> > > > Latch Enable == CombReg + C02
> > > > Async Clear  == ~CombReg * C01
>
> > > > Is this what you are asking?
>
> > > > Rick
>
> > > Rick,
> > > Yes, that is what I want.
>
> > > Could you please send the code and a window screen frame using
> > > Window's Paint so that I can see the full picture.
>
> > > Thank you.
>
> > > Weng
>
> > I'm not clear on what you want.  I posted the full code a couple of
> > posts back.  What is it that you want a screen shot of?  The text I
> > quoted was from the Synthesis report.  If you want an image of the
> > chip editor, the latch only shows in the logic block editor dialog
> > box.  It is just a check box on a schematic of the functional elements
> > in the logic block.  Is that of any value to you?
>
> > Rick
>
> Rick,
> Thank you for your help.
>
> This time I really understand what the Lattice does with your source
> code in the previous poster.
>
> Lattice generates a latch for the process of CombProc, paying no
> attention to what is used.
>
> And I think Lattice compiler does a very good job by generating the
> following equations:
>
> Din == '1'
> Latch Enable == CombReg + C02
> Async Clear  == ~CombReg * C01
>
> "With only four inputs I
> would expect they could have just used a single LUT4 and the latch
> with the clock always enabled. "
>
> No. What you suggest may not work. Or it may work, but is not as
> simple as the Lattice equations show.
>
> I would like to see how you would write a LUT4 equation for a latch.
>
> Weng

Actually, I'm not certain the code you show (that I got from the
Lattice Logic Block Editor) is exactly the same as my VHDL
description.  For them to match, the latch enable would have to have
priority over the reset and that is not a very normal feature in a
latch.

case CombReg is
  when '0' =>
    if (C01 = '1') then
      Comb <= '0';
    elsif (C02 = '1') then
      Comb <= '1';
    else
      -- Here an assignment statement is missing, but it doesn't
      -- generate latch.  It is treated as a null statement. -Weng
    end if;
  when others =>
    Comb <= '1';
end case;

Notice that once the latch is set to a '1' in the VHDL, there is no
way to clear it.  When CombReg is a '1', the "others" clause of the
case is executed which only allows it to be a '1'.  The async clear
can only be asserted when CombReg is a '0'.  Of course, Comb and
CombReg are not the same signals, so there is a window between the
latch being set and the Register output going high where the latch can
be reset by C01.

There are only four inputs to this logic function "Comb".  A LUT4 can
implement ***ANY*** logic function of 4 inputs.  So there certainly is
a way to implement the above VHDL in a single LUT4.  In fact, you
don't even need the latch.

Comb <= CombReg or (C02 and not C01) or (Comb and not C01);

If you want to use the built in Latch in the FPGA, then I guess you
have to use a LUT4 to generate the enable and another to generate the
data (or async clear).

Enable <= CombReg or C01 or C02;
DataIn <= CombReg or not C01;

There is no savings by only using 2 of the 4 inputs on a LUT4 but
there is some advantage to using the reset input to a Latch.  I think
it may avoid potential race conditions when only one input switches.
My logic will have some problems, for example CombReg = 0, C02 = 0 and
C01 = 1.  Bring C01 low and it will either stay clear or set the latch
depending on which of the two paths are faster.  Hmmm, maybe the tools
aren't so stupid after all.  In essence, they are using the enable as
a set and the async reset as a... well, a reset!

Rick

Article: 145812
Subject: Re: using an FPGA to emulate a vintage computer
From: rickman <gnuarm@gmail.com>
Date: Wed, 24 Feb 2010 17:40:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 22, 3:28=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga rickman <gnu...@gmail.com> wrote:
> (big snip)
>
> > A hardware stack for C is a bit of a problem. =A0C tends to need a
> > rather large stack because of the stack frames used. =A0
>
> It depends, somewhat, on the programmer. =A0In K&R C, you couldn't
> pass a struct, but instead a pointer to a struct. =A0That kept
> the stack a little smaller, at least. =A0With C89, as with K&R,
> arrays (including automatic, allocated on the stack) had a
> constant dimension. =A0If I remember right, C99 added the ability
> to dimension local automatic (stack) arrays with variables.
> (Previously, a pointer on the stack and malloc() would have
> been used, along with the requirement to remember free().)
>
> > A language like
> > Forth, on the other hand, can get by with a very small hardware stack
> > because the stack usage tends to be minimal and subroutine nesting
> > does not automatically add to the data stack depth. =A0Instead, often
> > parameters that are passed into one routine are also passed onto the
> > next without duplication until they are consumed by the calculations
> > that need them. =A0In c every call copies every piece of data needed fo=
r
> > the lower level code creating stack "bloat" if you will.
>
> If you only pass pointers, it isn't so bad...
>
> -- glen

The problem is not just that the data on the stack is larger, but that
the data that is passed into one function often has to be passed into
functions that this function calls.  As the routines nest, the data is
typically duplicated on the stack over and over.  In Forth the stack
is normally juggled and duplication is minimal, so hardware stacks can
be as small as 16 words and still be very effective.

Rick

Article: 145813
Subject: Re: How a state machine is constructed using latches?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 24 Feb 2010 18:49:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 24, 5:33=A0pm, rickman <gnu...@gmail.com> wrote:
> On Feb 22, 9:41 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 18, 1:13 pm, rickman <gnu...@gmail.com> wrote:
>
> > > On Feb 18, 11:10 am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > On Feb 17, 7:51 pm, rickman <gnu...@gmail.com> wrote:
>
> > > > > On Feb 17, 8:05 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > > > On Feb 17, 4:29 pm, rickman <gnu...@gmail.com> wrote:
> > > > > > > Fight fire with fire! =A0The two reports below show that both=
 the
> > > > > > > missing else and the missing assignment (which is also missin=
g in the
> > > > > > > missing else case) produce latches.
>
> > > > > > > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.=
vhd":
> > > > > > > 57:4:57:7|Latch generated from process for signal Latch, prob=
ably
> > > > > > > caused by a missing assignment in an if or case stmt
> > > > > > > @W: CL117 :"C:\arius\boards\tdc_upgrade\tests\latchsynthtest.=
vhd":
> > > > > > > 40:4:40:7|Latch generated from process for signal Comb, proba=
bly
> > > > > > > caused by a missing assignment in an if or case stmt
>
> > > > > > > library ieee;
> > > > > > > use ieee.std_logic_1164.all;
> > > > > > > use ieee.numeric_std.all;
>
> > > > > > > entity LatchSynthTest is
> > > > > > > =A0 port(
> > > > > > > =A0 =A0 =A0 =A0 =A0 CLK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :=
 in =A0 =A0std_logic ;
> > > > > > > =A0 =A0 =A0 =A0 =A0 RESET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : i=
n =A0 =A0std_logic ;
> > > > > > > =A0 =A0 =A0 =A0 =A0 C01 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :=
 in =A0 =A0std_logic ;
> > > > > > > =A0 =A0 =A0 =A0 =A0 C02 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 :=
 in =A0 =A0std_logic ;
> > > > > > > =A0 =A0 =A0 =A0 =A0 LatchOutput =A0 : out =A0 std_logic ;
> > > > > > > =A0 =A0 =A0 =A0 =A0 CombOutput =A0 =A0: out =A0 std_logic
> > > > > > > =A0 =A0 =A0 =A0 =A0 );
> > > > > > > end LatchSynthTest ;
>
> > > > > > > architecture behavior of LatchSynthTest is
> > > > > > > =A0 SIGNAL Latch =A0 =A0 =A0 =A0 =A0: std_logic;
> > > > > > > =A0 SIGNAL Comb =A0 =A0 =A0 =A0 =A0 : std_logic;
> > > > > > > =A0 SIGNAL LatchReg =A0 =A0 =A0 : std_logic;
> > > > > > > =A0 SIGNAL CombReg =A0 =A0 =A0 =A0: std_logic;
>
> > > > > > > begin
>
> > > > > > > =A0 CombOutput =A0 =A0<=3D CombReg;
> > > > > > > =A0 LatchOutput =A0 <=3D LatchReg;
>
> > > > > > > =A0 Process_1 : process(RESET, CLK)
> > > > > > > =A0 begin
> > > > > > > =A0 =A0 if (RESET =3D '1') then
> > > > > > > =A0 =A0 =A0 LatchReg =A0<=3D '0';
> > > > > > > =A0 =A0 =A0 CombReg =A0 <=3D '0';
> > > > > > > =A0 =A0 elsif (rising_edge(CLK)) then
> > > > > > > =A0 =A0 =A0 LatchReg =A0<=3D Latch;
> > > > > > > =A0 =A0 =A0 CombReg =A0 <=3D Comb;
> > > > > > > =A0 =A0 end if;
> > > > > > > =A0 end process;
>
> > > > > > > =A0 CombProc : process(CombReg, C01, C02)
> > > > > > > =A0 begin
> > > > > > > =A0 =A0 case CombReg is
> > > > > > > =A0 =A0 =A0 when '0' =3D>
> > > > > > > =A0 =A0 =A0 =A0 if (C01 =3D '1') then
> > > > > > > =A0 =A0 =A0 =A0 =A0 Comb <=3D '0';
> > > > > > > =A0 =A0 =A0 =A0 elsif (C02 =3D '1') then
> > > > > > > =A0 =A0 =A0 =A0 =A0 Comb <=3D '1';
> > > > > > > =A0 =A0 =A0 =A0 else
> > > > > > > =A0 =A0 =A0 =A0 =A0 -- Here an assignment statement is missin=
g, but it doesn't
> > > > > > > =A0 =A0 =A0 =A0 =A0 -- generate latch. =A0It is treated as a =
null statement. -
> > > > > > > Weng
> > > > > > > =A0 =A0 =A0 =A0 end if;
> > > > > > > =A0 =A0 =A0 when others =3D>
> > > > > > > =A0 =A0 =A0 =A0 Comb <=3D '1';
> > > > > > > =A0 =A0 end case;
> > > > > > > =A0 end process;
>
> > > > > > > =A0 LatchProc : process(LatchReg, C01, C02)
> > > > > > > =A0 begin
> > > > > > > =A0 =A0 case LatchReg is
> > > > > > > =A0 =A0 =A0 when '0' =3D>
> > > > > > > =A0 =A0 =A0 =A0 if C01 =3D '1' then
> > > > > > > =A0 =A0 =A0 =A0 =A0 Latch <=3D '0';
> > > > > > > =A0 =A0 =A0 =A0 elsif C02 =3D '1' then
> > > > > > > =A0 =A0 =A0 =A0 =A0 Latch <=3D '1';
> > > > > > > =A0 =A0 =A0 =A0 =A0 -- Here the else is missing, and it does
> > > > > > > =A0 =A0 =A0 =A0 =A0 -- generate latch. =A0It is treated as a =
null statement.
> > > > > > > =A0 =A0 =A0 =A0 end if;
> > > > > > > =A0 =A0 =A0 when others =3D>
> > > > > > > =A0 =A0 =A0 =A0 Latch <=3D '1';
> > > > > > > =A0 =A0 end case;
> > > > > > > =A0 end process;
>
> > > > > > > end behavior;
>
> > > > > > Hi,
> > > > > > Thank you, Andy, Rick and everyone, I am wrong in the second po=
int:
> > > > > > missing "else" or missing an assignment statement.
>
> > > > > > But my first point is how to generate a latch for a compiler. R=
ick,
> > > > > > can you see the floor plan to show how the latch is generated: =
for the
> > > > > > state only or for full states?
>
> > > > > > Weng
>
> > > > > I'm not clear what you mean by "how". =A0Are you asking about the=
 detail
> > > > > of how it is implemented in the FPGA? =A0In the Lattice part they=
 used a
> > > > > FF as a latch. =A0A register is between the latch and the output.=
 =A0They
> > > > > drive the latch oddly driving both the clock and the async reset
> > > > > inputs with logic, but then if you look at the code what would yo=
u
> > > > > think is the clock? =A0I don't see why they did it the way they d=
id, but
> > > > > it works correctly according to the VHDL. =A0With only four input=
s I
> > > > > would expect they could have just used a single LUT4 and the latc=
h
> > > > > with the clock always enabled.
>
> > > > > Din =3D=3D '1'
> > > > > Latch Enable =3D=3D CombReg + C02
> > > > > Async Clear =A0=3D=3D ~CombReg * C01
>
> > > > > Is this what you are asking?
>
> > > > > Rick
>
> > > > Rick,
> > > > Yes, that is what I want.
>
> > > > Could you please send the code and a window screen frame using
> > > > Window's Paint so that I can see the full picture.
>
> > > > Thank you.
>
> > > > Weng
>
> > > I'm not clear on what you want. =A0I posted the full code a couple of
> > > posts back. =A0What is it that you want a screen shot of? =A0The text=
 I
> > > quoted was from the Synthesis report. =A0If you want an image of the
> > > chip editor, the latch only shows in the logic block editor dialog
> > > box. =A0It is just a check box on a schematic of the functional eleme=
nts
> > > in the logic block. =A0Is that of any value to you?
>
> > > Rick
>
> > Rick,
> > Thank you for your help.
>
> > This time I really understand what the Lattice does with your source
> > code in the previous poster.
>
> > Lattice generates a latch for the process of CombProc, paying no
> > attention to what is used.
>
> > And I think Lattice compiler does a very good job by generating the
> > following equations:
>
> > Din =3D=3D '1'
> > Latch Enable =3D=3D CombReg + C02
> > Async Clear =A0=3D=3D ~CombReg * C01
>
> > "With only four inputs I
> > would expect they could have just used a single LUT4 and the latch
> > with the clock always enabled. "
>
> > No. What you suggest may not work. Or it may work, but is not as
> > simple as the Lattice equations show.
>
> > I would like to see how you would write a LUT4 equation for a latch.
>
> > Weng
>
> Actually, I'm not certain the code you show (that I got from the
> Lattice Logic Block Editor) is exactly the same as my VHDL
> description. =A0For them to match, the latch enable would have to have
> priority over the reset and that is not a very normal feature in a
> latch.
>
> case CombReg is
> =A0 when '0' =3D>
> =A0 =A0 if (C01 =3D '1') then
> =A0 =A0 =A0 Comb <=3D '0';
> =A0 =A0 elsif (C02 =3D '1') then
> =A0 =A0 =A0 Comb <=3D '1';
> =A0 =A0 else
> =A0 =A0 =A0 -- Here an assignment statement is missing, but it doesn't
> =A0 =A0 =A0 -- generate latch. =A0It is treated as a null statement. -Wen=
g
> =A0 =A0 end if;
> =A0 when others =3D>
> =A0 =A0 Comb <=3D '1';
> end case;
>
> Notice that once the latch is set to a '1' in the VHDL, there is no
> way to clear it. =A0When CombReg is a '1', the "others" clause of the
> case is executed which only allows it to be a '1'. =A0The async clear
> can only be asserted when CombReg is a '0'. =A0Of course, Comb and
> CombReg are not the same signals, so there is a window between the
> latch being set and the Register output going high where the latch can
> be reset by C01.
>
> There are only four inputs to this logic function "Comb". =A0A LUT4 can
> implement ***ANY*** logic function of 4 inputs. =A0So there certainly is
> a way to implement the above VHDL in a single LUT4. =A0In fact, you
> don't even need the latch.
>
> Comb <=3D CombReg or (C02 and not C01) or (Comb and not C01);
>
> If you want to use the built in Latch in the FPGA, then I guess you
> have to use a LUT4 to generate the enable and another to generate the
> data (or async clear).
>
> Enable <=3D CombReg or C01 or C02;
> DataIn <=3D CombReg or not C01;
>
> There is no savings by only using 2 of the 4 inputs on a LUT4 but
> there is some advantage to using the reset input to a Latch. =A0I think
> it may avoid potential race conditions when only one input switches.
> My logic will have some problems, for example CombReg =3D 0, C02 =3D 0 an=
d
> C01 =3D 1. =A0Bring C01 low and it will either stay clear or set the latc=
h
> depending on which of the two paths are faster. =A0Hmmm, maybe the tools
> aren't so stupid after all. =A0In essence, they are using the enable as
> a set and the async reset as a... well, a reset!
>
> Rick

Rick

Actually it is not the fault of Lattice, but of your VHDL code.

In your example,

case CombReg is
  when '0' =3D>
    if (C01 =3D '1') then
      Comb <=3D '0';
    elsif (C02 =3D '1') then
      Comb <=3D '1';
    else
      -- Here an assignment statement is missing, but it doesn't
      -- generate latch.  It is treated as a null statement. -Weng
    end if;
  when others =3D>
    Comb <=3D '1'; 		<-- lock here by VHDL, not by Lattice compiler
end case;

  Process_1 : process(RESET, CLK)
  begin
    if (RESET =3D '1') then
      LatchReg  <=3D '0';
      CombReg   <=3D '0';
    elsif (rising_edge(CLK)) then
      LatchReg  <=3D Latch;
      CombReg   <=3D Comb; <-- lock here by VHDL, not by Lattice
compiler
    end if;
  end process;

Weng

Article: 145814
Subject: Re: using an FPGA to emulate a vintage computer
From: Charles Richmond <frizzle@tx.rr.com>
Date: Wed, 24 Feb 2010 22:27:44 -0600
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> In comp.arch.fpga Charles Richmond <frizzle@tx.rr.com> wrote:
>> (see below) wrote:
>>> On 23/02/2010 17:48, in article
>>> 4178548f-5618-49dd-ad72-008bdb53ed3b@z25g2000vbb.googlegroups.com, "Eric
>>> Chomko" <pne.chomko@comcast.net> wrote:
>>>    [snip...]            [snip...]            [snip...]
>>>> Speaking of ALGOL parameter passing, what's a "thunk"?
>  
>>> A thunk is the anonymous function (pair) described above.
>  
>> A "thunk" was a method of implementing "call by name".
> 
> Much of the discussion about ALGOL, including this, is in the
> past tense.  As ALGOL60 hasn't changed recently, and the compilers
> still exist, even if new ones aren't being written, it seems to
> me that present tense is fine.
> 
> A "thunk" is a method of implementing "call by name".
> 
> More to the hardware side, an archetecture still exists even
> if no implementations of it exist.  (Though in most cases at
> least one still does.)   The PDP8 still IS a 12 bit machine,
> even if you implement it in an FPGA.
> 

A "thunk" was *and* is a method for implementing "call by name". 
But a compiler providing "thunks" has *not* been written for some 
time now. So there is *some* justification for using past tense.

Once something exists, the *potential* for actually re-creating it 
continues to exist. I accept that; indeed, I *celebrate* that!!!

These things are now curiosities... and I *am* curious about them. 
Unfortunately, they have long ago lost their "gee whiz" value. 
ISTM that it is sad how quickly new technology is absorbed into 
the psyche and loses its "gee whiz" value.   :-(


-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Article: 145815
Subject: Re: using an FPGA to emulate a vintage computer
From: Charles Richmond <frizzle@tx.rr.com>
Date: Wed, 24 Feb 2010 22:32:04 -0600
Links: << >>  << T >>  << A >>
Eric Chomko wrote:
> On Feb 23, 2:07 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> On 23/02/2010 17:52, in article
>> 3ec03225-3a0f-4bcd-9db1-51201d1b3...@w12g2000vbj.googlegroups.com, "Eric
>>
>> Chomko" <pne.cho...@comcast.net> wrote:
>>> But an ALGOL "activation record" (stack frame) had a lot more than
>>> that. As I recall, they copied a lot more just pointers and parameter
>>> values.
>> Just the usual red tape: return address, frame pointer of caller; and either
>> a static pointer or some housekeeping for 'display' registers (if used) to
>> access non-locals. But bear in mind that in decent languages arrays are
>> storable values, so a value array parameter gets copied in toto, unlike C.
>>
> 
> Are you saying that C doesn't implement true recursion? I have only
> used recursion in college and not with C. ALGOL, SIMPL-T and LISP were
> the only languages I used to write recursive algorithms.
> 

C does *not* support passing an array "by value", only "by 
reference". You can encapsulate an array in a struct and pass the 
struct "by value".

C *does* support recursion.

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Article: 145816
Subject: Re: using an FPGA to emulate a vintage computer
From: Charles Richmond <frizzle@tx.rr.com>
Date: Wed, 24 Feb 2010 22:38:52 -0600
Links: << >>  << T >>  << A >>
Joe Pfeiffer wrote:
>
>       [snip...]             [snip...]           [snip...]
> 
> You forgot to mention local variables are in the activation record.
> 
> When I was an undergrad I spent some time programming FORTRAN on a
> Harris /6 (I think it was a /6 -- there's something nagging at the back
> of my mind that says it may have been a /7).  Anyway, reading the manual
> I discovered that return addresses were stacked, and immediately jumped to
> the conclusion that it could do recursion.  It turned out that local
> variables were static...  which meant I spent a *long* time figuring out
> why my program was producing completely nonsensical results.
> 
> As Al Stewart once sang, "I was jumping to conclusions, and one of them
> jumped back."

I am *not* familiar with a Harris /6 or Harris /7. In the early 
80's, I worked on a Harris 800 using the VOS operating system and 
FORTRAN 77. ISTR that each user-written subroutine and function 
reserved a word of memory at the beginning of the routine. This 
word was used to store the return address, and an indirect branch 
was done through this word to affect the return.

Harris bought out the Datacraft computer company, and had a 500, 
an 800, and a 1200 with similar instruction sets. ISTR that the 
CPU's were implemented with bit-sliced microprocessors.


-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Article: 145817
Subject: Re: using an FPGA to emulate a vintage computer
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 25 Feb 2010 06:38:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
(snip)
 
> You forgot to mention local variables are in the activation record.
 
> When I was an undergrad I spent some time programming FORTRAN on a
> Harris /6 (I think it was a /6 -- there's something nagging at the back
> of my mind that says it may have been a /7).  Anyway, reading the manual
> I discovered that return addresses were stacked, and immediately jumped to
> the conclusion that it could do recursion.  It turned out that local
> variables were static...  which meant I spent a *long* time figuring out
> why my program was producing completely nonsensical results.

I did it once on the PDP-10.  Fortran kept the return address on
the stack, but variables were static.  I made local variables arrays
with another variable to increment/decrement with recursion depth.
That was for testing only, I didn't try it for any real problem.

The OS/360 compilers keep the return address in static storage.
 
> As Al Stewart once sang, "I was jumping to conclusions, and one of them
> jumped back."

-- glen

Article: 145818
Subject: antti alive message
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 25 Feb 2010 02:18:38 -0800 (PST)
Links: << >>  << T >>  << A >>
just to let all know I'm fine and not forgotten the brain release, not
given up but the time til embedded is just crazy all things happening
at worst time.. as usual :)

and as usual, i'd be around the same stand as last year, if anyone
drops by..

Antti

Article: 145819
Subject: Re: FPGA platform??
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Thu, 25 Feb 2010 11:21:41 +0100
Links: << >>  << T >>  << A >>
Thomas Stanka <usenet_nospam_valid@stanka-web.de> writes:

> On 23 Feb., 15:52, Petter Gustad <newsmailco...@gustad.com> wrote:
>> Thomas Stanka <usenet_nospam_va...@stanka-web.de> writes:
>> > For normal FPGA Design Windows is common, as some (backend-) FPGA
>> > tools are either Windows only or show better performance under
>> > Windows.
>>
>> Which tools do you have in mind here?
>
> AFAIK you get the free Modelsim version only for Windows(32bit) from
> Xilinx. The free suite for Altera (Webedition) seems to be windows
> only, linux requires licensing.

Yes this is true, even though some of the reasons are political.
Modelsim ASE is included with Quartus under Linux at no extra cost.
Altera has to pay royalties for their Mainwin library hence they will
not give it away, but they have a Qt based GUI now so I would expect
to see a free Quartus Webedition for Linux soon. 

The free Modelsim versions are running at a reduced speed under both
Windows and Linux.

On the other hand the Synopsys VCS simulator is not available for
Windows. 

> Several parts of the design suites ISPLever are Windows only,
> Programming Actel FPGAs is only possible using Windows...

Does that mean you can't generate a SVF file either?

> The versions of ISE I used showed not that good performance on linux.

Hmm. I don't use the GUI that much (other than for floorplanning and
signaltap/chipscope) so most of my builds are done in batch and I have
not noticed any reduced performance under Linux.

> Quartus Linux is only titled Beta, never worked with, but guess the
> same here.

Quartus for Linux is not beta. The recently released Qt GUI front-end
is beta, but not the regular Quartus version. The performance of Linux
(Quartus 9.x) is the same as for Windows.


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 145820
Subject: Altera data sheets.
From: Symon <symon_brewer@hotmail.com>
Date: Thu, 25 Feb 2010 11:04:03 +0000
Links: << >>  << T >>  << A >>
If anyone from Altera reads this forum, can they please email/call their 
manual writing & publishing department and complain from me that their 
stupid PDF manuals have occasional pages turned at 90 degrees, e.g. the 
Stratix4 Handbook, page 1-11. This is very annoying, as it means my 
reader displays all the other pages narrower than they would be. I'm 
getting on a bit now, my eyesight isn't what it was, and I'm too 
cantankerous to piss about with the magnifying glass tool. I'm perfectly 
capable of using the special rotate button that the reader provides for 
the odd occasion when the page needs to be turned, in the same way I 
used to be able to turn a book in the good old days. Those dumbasses 
(probably) wouldn't print a book with occasional pages sticking out, why 
do they feel the need to do it with their PDF manuals.

The stupid thing is, doing what they have done, doesn't make the table 
any easier to read on a computer screen than if they'd made the table 
smaller and printed it across the page. It just makes all the other 
pages harder to read. The only time it helps is if some bozo decides 
he's gonna print out 27MB of file, in which case they're probably a 
student and have good eyesight anyway.

This is the only reason stopping me from designing in Altera parts. 
Xilinx have nice PDF files.

Love, Syms.

p.s. There's no charge for this free advice.

Article: 145821
Subject: Re: How a state machine is constructed using latches?
From: rickman <gnuarm@gmail.com>
Date: Thu, 25 Feb 2010 03:49:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 24, 9:49=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> =A0 =A0 =A0 CombReg =A0 <=3D Comb; <-- lock here by VHDL, not by Lattice
>
> Weng

Who said anything about it be the fault of the tools?  I said that it
appeared there was a difference, but then I realized that the async
reset must have priority over the latch enable because it can still be
reset once set up to the point that the value of Comb is captured by
CombReg.  Then there is no longer a way to reset the latch.

This is the sort of stuff that makes working with latches difficult.
If the combinatorial logic had been described in the sequential
process, there would have been no possibility of generating a latch.

Rick

Article: 145822
Subject: EDK spi ip core
From: "lakshmi3489" <lakshmi.doravari@n_o_s_p_a_m.gmail.com>
Date: Thu, 25 Feb 2010 05:51:10 -0600
Links: << >>  << T >>  << A >>

1. If I look at the spartan 3a 3400 dsp evaluation board schematic there is
as SPI EEPROM. Looking at the part number it is a part number for a FLASH
by Microchip(M25P16-VMW6G).

2. Looking at this example xspi_stm_flash_example.c though he mentions the
same part number M25P16. 
  Then why the name SPI EEPROM??????

  	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145823
Subject: Scrubbing in Virtex-4
From: "xabi" <xiturbe@ikerlan.es>
Date: Thu, 25 Feb 2010 06:30:40 -0600
Links: << >>  << T >>  << A >>
Hi all,

I am experimenting with Scrubbing in Xilinx Virtex-4 devices.

According to XAPP1088, pag.18:
"For scrubbing operations, there are special considerations for designs
utilizing distributed RAMs and SRL16s. When a LUT is configured as either
SRL16 or distributed RAM (LUT RAM), scrubbing can corrupt the contents of
such primitives if GLUTMASK_B bit is left at its default setting of
‘1’. Therefore, it is important to ensure the GLUTMASK_B bit is set to
‘0’. Block RAM content, however, is not covered by the GLUTMASK_B
setting. Therefore, block RAM content configuration columns still need to
be avoided during scrubbing."

Based on this information, I have carried out two experiments:

1) I have generated a bitstream in which all the LUTs of a whole CLB column
have been used as SRL16, initialized to a given value. I have checked in
this bitstream that the computed ECC codes (in the 21st word of the
configuration frame for this CLB column) were equal to 0x000!! As expected,
this confirms that LUTs configured as SRL16s are not considered when
computing the ECC.

2) I have generated a bitstream in which some of the LUTs of a CLB column
have been used as SRL16 and others as LUTs. In this situation the generated
bitstream incorporates ECC codes which are not equal to 0 in the 21st word
of the configuration frame for this CLB column.

Consequently, I have confirmed that when computing the ECC codes for the
configuration frames, only those LUTs not configured as SRL16s or LUT-RAMs
are taken into account. This creates me a question:

How can we know if a LUT is configured in one of these modes? I suppose
this information is encoded in the bitstream... Do anyone have any clue
about this?
I would really appreciate any information.

Thanks in advance.

Xabi

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145824
Subject: Scrubbing in Virtex-4
From: "xabi" <xiturbe@n_o_s_p_a_m.ikerlan.es>
Date: Thu, 25 Feb 2010 06:42:23 -0600
Links: << >>  << T >>  << A >>
Hi all,

Iam experimenting with Scrubbing in Xilinx Virtex-4 devices.

According to XAPP1088, pag.18:
"For scrubbing operations, there are special considerations for designs
utilizing distributed RAMs and SRL16s. When a LUT is configured as either
SRL16 or distributed RAM (LUT RAM), scrubbing can corrupt the contents of
such primitives if GLUTMASK_B bit is left at its default setting of
‘1’. Therefore, it is important to ensure the GLUTMASK_B bit is set to
‘0’. Block RAM content, however, is not covered by the GLUTMASK_B
setting. Therefore, block RAM content configuration columns still need to
be avoided during scrubbing."

Based on this information, I have carried out two experiments:

1) I have generated a bitstream in which all the LUTs of a whole CLB column
have been used as SRL16, initialized to a given value. I have checked in
this bitstream that the computed ECC codes (in the 21st word of the
configuration frame for this CLB column) were equal to 0x000!! As expected,
this confirms that LUTs configured as SRL16s are not considered when
computing the ECC.

2) I have generated a bitstream in which some of the LUTs of a CLB column
have been used as SRL16 and others as LUTs. In this situation the generated
bitstream incorporates ECC codes which are not equal to 0 in the 21st word
of the configuration frame for this CLB column.

Consequently, I have confirmed that when computing the ECC codes for the
configuration frames, only those LUTs not configured as SRL16s or LUT-RAMs
are taken into account. This creates me a question:

How can we know if a LUT is configured in one of these modes? I suppose
this information is encoded in the bitstream... Do anyone have any clue
about this?
I would really appreciate any information.

Thanks in advance.

Xabi	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search