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
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
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
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. WengArticle: 145803
(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 UniversityArticle: 145804
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 ThomasArticle: 145805
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, ChrisArticle: 145806
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.comArticle: 145807
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.ukArticle: 145808
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
"(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
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.ukArticle: 145811
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: 145812On 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. RickArticle: 145813
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: 145814glen 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
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
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
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." -- glenArticle: 145818
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.. AnttiArticle: 145819
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
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
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. RickArticle: 145822
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.comArticle: 145823
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.comArticle: 145824
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:
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